Wiele zależy od kilku pierwszych spotkań. Jest to czas, aby wszystko dopracować przed przystąpieniem do działania. Dlatego też istnieje duża presja na fazę odkrywania . To tylko jedna z części procesu dostarczania oprogramowania. Ale czego można oczekiwać od fazy odkrywania? A co ważniejsze, co można zrobić, aby wspomóc ten proces?
W dzisiejszym blogu przeprowadzę Cię przez fazę odkrywania i odpowiem na pytania dotyczące tego procesu. Podam również wskazówki i triki, które pomogą ci w pełni wykorzystać ten proces.
Przedstawię również kilka studiów przypadków i pokażę, jak niemal pominięcie fazy odkrycia mogłoby spowodować złą sytuację.
Spis treści:
- Spotkanie zapoznawcze: Znalezienie odpowiedniego dopasowania dla obu stron
- Pięć kroków fazy odkrywania w projekcie
- Etap 1: Badania użytkowników i wymagania
- Etap 2: Lista funkcji i sesje burzy mózgów w fazie odkrywania
- Etap 3: Przegląd projektu i niskopoziomowy dokument projektowy
- Etap 4: Plan techniczny
- Etap 5: Szkielety i projekt wizualny
- Pokusa pominięcia fazy odkrywania i dlaczego to zły pomysł
- Decyzje podejmowane w fazie odkrywania nie zawsze są ostateczne
- Nie lekceważ potęgi fazy odkrywania
- Jaki jest główny cel aplikacji?
- Opisz wszystkich aktorów (role), na przykład Administrator, Konstruktor itp.
- Przedstawienie głównych przepływów (przypadków biznesowych).
- Opisz główny model domeny.
- Opisać wymagane i przyszłe interfejsy zasilania danymi
- Ich produkt był przeładowany funkcjami. W porównaniu do swoich konkurentów byli liderami i mogli robić rzeczy, które ich konkurenci dopiero planowali w swoich mapach drogowych.
- System był niezwykle elastyczny i można było uzyskać niemal wszystko, o czym się pomyślało.
- Ze względu na dziesiątki funkcji i elastyczność, był tak złożony i nieintuicyjny, że był prawie niemożliwy do zrozumienia dla nowych klientów.
- Według statystyk, które zebraliśmy, 80% klientów , którzy zaczęli korzystać z ich produktu, usunęło swoje konto w ciągu pierwszych 15 minut!
Spotkanie zapoznawcze: Znalezienie odpowiedniego dopasowania dla obu stron
Krótka uwaga: przed fazą odkrywania ma miejsce spotkanie odkrywcze. Chociaż na tym blogu omówiono je bardziej szczegółowo, dzieląc się poradami, jak się do niego przygotować, omówię je w kilku krótkich szczegółach.
To nie to samo, co faza odkrywania. Celem spotkania jest odkrycie wizji i rozpoczęcie wymiany informacji, aby lepiej się zrozumieć. Jest to pierwszy punkt kontaktu. Informacje pomagają zbudować lepszy obraz tego, jak projekt może wyglądać. Dzięki temu możemy przekazać informacje na temat kolejnych kroków i usług.
Uzyskując jaśniejszy obraz Twoich celów, możemy zrozumieć, jakie usługi najbardziej Ci odpowiadają. Spotkanie daje nam również możliwość sprawdzenia, czy dobrze do siebie pasujemy. Sprawdzimy, czy nasze osobowości, style pracy i oczekiwania są zgodne. Jeśli nie jesteśmy na tej samej stronie, to w porządku. Chodzi o znalezienie odpowiedniego dopasowania, które będzie działać dla nas obojga.
Po zakończeniu spotkania wyjaśniającego i potwierdzeniu wszystkich szczegółów, przechodzimy do fazy odkrywania.
Pięć kroków fazy odkrywania w projekcie
Podczas opracowywania niestandardowego rozwiązania ważne jest, aby stworzyć produkt, który robi wszystko, czego chcesz, bez żadnych rzeczy, których nie potrzebujesz. W tym miejscu do gry wkracza faza odkrywania. Faza ta daje nam możliwość dogłębnego zrozumienia twoich celów, wyzwań i wymagań technicznych (jeśli takie istnieją). Możemy podzielić ten proces na 5 głównych części. Każda sekcja pomaga nam odkryć właściwe rozwiązanie.
Etap 1: Badania użytkowników i wymagania
Pierwszym krokiem jest zebranie wszystkich wymagań.Obejmuje to zestawienie wszelkiej istniejącej dokumentacji, przypadków użycia, opisów projektów i dostarczonej dokumentacji API innych firm. Następnie organizujemy spotkanie inauguracyjne, aby przedstawić nasz zespół i dogłębnie zrozumieć Twój produkt.
Naszym celem jest nauka:
Jak najlepiej wykorzystać wczesne etapy?
Po 20 latach pracy w branży mogę podzielić się kilkoma praktycznymi wskazówkami, jak najlepiej wykorzystać tę sytuację. Najważniejszą radą, jakiej mogę udzielić, jest przygotowanie. Przychodź na spotkania z jak największą ilością informacji. To nie jest ulica jednokierunkowa. Im bardziej zaangażujesz się w proces, tym lepsze wyniki i produkt końcowy uzyskasz.
Aby jak najlepiej rozpocząć projekt, należy poświęcić czas na określenie jego podstawowych cech. Każda dodatkowa funkcja to dodatkowy koszt. Koncentrując się na podstawowych funkcjach i nadając im priorytet, można uruchomić projekt w krótszych ramach czasowych i uzyskać lepszy zwrot z inwestycji w pierwszych dniach. Ale nie martw się, tworzenie produktu wokół podstawowych funkcji oznacza, że uwaga skupia się na tym, na czym powinna. Mając już główną architekturę, zawsze istnieje możliwość rozszerzenia projektu w późniejszym terminie.
Etap 2: Lista funkcji i sesje burzy mózgów w fazie odkrywania
W oparciu o zebrane wymagania, nasz zespół przeprowadza wewnętrzną sesję eventstorming. Ten wspólny warsztat ma na celu zbadanie domeny biznesowej i osiągnięcie kilku celów,w tym gromadzenie, potwierdzanie i porządkowanie wymagań, odkrywanie potencjalnych luk, zagłębianie się w przepływy biznesowe oraz godzenie różnych perspektyw i celów. Rezultatem jest wizualna reprezentacja wymagań zbudowana przy użyciu oprogramowania Miro.
Oznacza to dla Ciebie mapa drogowa dla twojego produktu, który w pierwszej kolejności nadaje priorytet głównym funkcjom.
Etap 3: Przegląd projektu i niskopoziomowy dokument projektowy
Aby dopracować architekturę projektu, tworzymy dokument przeglądu projektu, znany również jako dokument Low-Level Design (LLD). Dokument ten zawiera kompletny projekt na poziomie komponentów i podąża krok po kroku za wymaganiami i procesem udoskonalania. Obejmuje on architekturę systemu, opisy komponentów, modele baz danych, szkic architektury wdrożenia itp. Mówiąc prościej, wszystko, czego zespół wdrożeniowy potrzebuje do zbudowania rozwiązania.
Celem jest informowanie użytkowników o przebiegu całego procesu. Na każdym etapie chcemy mieć pewność, że wiesz, co się dzieje i dlaczego podejmujemy takie, a nie inne decyzje. Nie jest to jednak ulica jednokierunkowa, decyzje dotyczące kluczowych aspektów projektu są omawiane i potwierdzane z tobą po drodze.
Etap 4: Plan techniczny
Równolegle z dokumentacją LLD przygotowujemy plan techniczny, który nakreśla podejście wdrożeniowe. Plan ten może zawierać Architectural Decision Record (ADR), który rejestruje ważne decyzje architektoniczne, ich kontekst i konsekwencje. Plan techniczny identyfikuje również frameworki, biblioteki i usługi SaaS, które zostaną włączone do rozwiązania.
Każde podjęte działanie będzie rejestrowane. Nawet na wczesnych etapach jest to ważne, ponieważ pozwala wszystkim na weryfikację ważnych decyzji.
Etap 5: Szkielety i projekt wizualny
Aby zapewnić namacalną reprezentację rozwiązania, tworzymy szkielety i projekty wizualne. Celem jest dostarczenie kompletnych projektów wizualnych podczas samej fazy odkrywania. Te makiety i projekty oferują wgląd w wygląd i styl produktu końcowego, zapewniając zgodność z oczekiwaniami użytkownika.
Dzięki zebranym informacjom możemy dokładnie oszacować czas realizacji projektu, zaproponować odpowiedni stos technologiczny, określić wielkość zespołu, a nawet zidentyfikować członków zespołu o bardzo konkretnych umiejętnościach, co zwiększa szanse na sukces projektu. A potem? Przechodzimy do etapu kick-off, w którym wszystkie decyzje wchodzą w życie.
Chociaż poruszyłem 5 głównych etapów etapu odkrywania, chciałbym pokazać, jak to działa w praktyce i podzielić się dwoma przykładami.
Pokusa pominięcia fazy odkrywania i dlaczego to zły pomysł
Pewnego razu otrzymaliśmy prośbę od klienta, aby pomóc jego zespołowi w rozbudowie produktu, który tworzyli (i sprzedawali) przez około 2 lata. Firma odniosła spory sukces, miała stabilną bazę klientów, ale wciąż był to niewielki udział w rynku.
Chcieli się rozwijać, więc potrzebowali partnera programistycznego, który wspierałby ich w szybszym dostarczaniu nowych funkcji. Uważali, że to najlepszy sposób na pozyskanie nowych klientów. Brzmiało to bardzo logicznie. Co więcej, byli tak przekonani co do tego i planu kolejnych kroków , że prawie zgodziliśmy się pominąć fazę odkrywania. Byliśmy gotowi przejść bezpośrednio do procesu wdrażania (ponieważ czas bez nowych funkcji to pieniądze utracone od nowych klientów).
Ostatecznie zdecydowaliśmy się na bardzo ograniczoną fazę odkrywania. Zaprojektowany, aby uzyskać przegląd istniejącego systemu i jego funkcji. Jak są one wykorzystywane? A także, które funkcje są najważniejsze dla klientów? I jak wygląda ich produkt w porównaniu do konkurencji. I to był przełom.
Dowiedzieliśmy się:
Jaki był wynik fazy odkrywania?
Szybko doszliśmy do wniosku, że brak funkcji nie był ich głównym problemem. Problemem było zbyt wiele funkcji. A raczej skupienie się na funkcjach bez zwracania uwagi na doświadczenie użytkownika. Byli tak skupieni na dodawaniu nowych funkcji, że przegapili wszystkie raporty i statystyki dotyczące użytkowania i nie korzystali z nich. Po prostu potrzebowali pary zewnętrznych oczu, by na to spojrzeć i je zrozumieć. To nie była fizyka jądrowa. Wniosek był prosty dla zewnętrznego obserwatora.
Zamiast dodawać nowe funkcje, klient zdecydował się całkowicie przebudować UX/UI swojego systemu. Wraz ze stroną internetową zainwestowaliśmy w podręczniki użytkownika. Wprowadziliśmy kilka kreatorów konfiguracji, które prowadziły klientów przez najczęściej używane funkcje. W rezultacie liczba klientów opuszczających platformę spadła z 80% do mniej niż 15%. To wyraźnie pokazuje, jak świeże spojrzenie z innej perspektywy może zmienić sposób, w jaki postrzegamy rzeczywiste potrzeby produktu.
Decyzje podejmowane w fazie odkrywania nie zawsze są ostateczne
Jedną rzeczą, na którą należy zwrócić uwagę w fazie odkrywania, jest to, że nic nie jest ustalone. Decyzje podejmowane po drodze mają na celu maksymalne wykorzystanie projektu, nawet jeśli oznacza to wprowadzenie zmian.
Niedawno mieliśmy fazę odkrywania platformy AI opartej na chmurze. Na początku zaangażowaliśmy w proces decyzyjny zarówno liderów Java, jak i .Net.
Klient zdecydował się na .Net, ponieważ w tamtym czasie był to lepszy wybór. Rozpoczęła się faza odkrywania, a architekci .Net podjęli się zadania dostarczenia i stworzenia całej dokumentacji.
W miarę postępu fazy odkrywania odkryliśmy, że firma ma grant na Amazon Web Services (AWS), specjalność lidera Java. Budując go w .Net, prawdopodobnie wybralibyśmy Azure Cloud, podczas gdy przejście na Javę przyniosło oszczędności liczone w tysiącach dolarów miesięcznie. Wyjaśniliśmy nasze ustalenia, a klient zdecydował się przenieść własność projektu.
Dla większości brzmiałoby to jak moment na gigantyczne westchnienie, ale w rzeczywistości wszystkie badania przeprowadzone przez zespół .Net, od tego, co projekt powinien zrobić, po funkcje, których oczekiwał klient, były nadal aktualne.
Zmiana ta pozwoliła na kontynuowanie projektu z właściwym specjalistą na czele.
Nie lekceważ potęgi fazy odkrywania
Faza odkrywania odgrywa kluczową rolę w procesie tworzenia oprogramowania. Pomaga odkryć ważne spostrzeżenia, dostosować cele i zapewnić właściwe rozwiązanie. Pominięcie tej fazy może prowadzić do niewykorzystanych możliwości i słabych doświadczeń użytkowników. W Inspeerity rozumiemy wartość fazy odkrywania i jej wpływ na sukces projektu. Jeśli szukasz więcej informacji na temat tego, jak faza odkrywania może znaleźć odpowiednie rozwiązanie programowe, skontaktuj się z nami już dziś.
Pozwól nam poprowadzić Cię w kierunku udanej podróży rozwoju oprogramowania.
