Rozmawiając o projektach programistycznych, czy kiedykolwiek zastanawiałeś się, jak różne firmy zajmujące się rozwojem oprogramowania i projektowaniem usług oprogramowania opisują swoje projekty? Czy po przeczytaniu ich opisów możesz szybko zrozumieć konkretne wymagania i tło projektu?

Typowy sposób opisywania projektów programistycznych zazwyczaj obejmuje cztery punkty:

Wprowadzenie do branży klienta

Klienci obsługiwani przez projekty programistyczne pochodzą z różnych branż. Aby przedstawić projekt osobom z różnych branż, należy zacząć od tła branżowego. Opis tła branżowego obejmuje, w jaki sposób branża łączy się z życiem ludzi, jakie są jej cele sprzedaży lub usług na rynku, jaką rolę odgrywa firma lub osoba klienta w tej branży, jakie ma przekonania lub cechy oraz jaka jest wizja przyszłości firmy. Dzięki temu wprowadzeniu do branży klienta, zespół deweloperski lepiej zrozumie perspektywę klienta.

Problemy w procesie biznesowym (gdzie leżą potrzeby)

To jest główny powód, dla którego klient się pojawia. Jakie problemy napotyka klient w swoim środowisku pracy? Czy istniejący proces pracy wymaga cyfryzacji, czy obecny system informatyczny wymaga reorganizacji po latach użytkowania, czy też trzeba wprowadzić cyfrowe środki w odpowiedzi na nowe trendy w branży? Ważne jest, aby obiektywnie i empatycznie zrozumieć sytuację, z jaką boryka się klient.

Proponowane rozwiązanie

Po osiągnięciu porozumienia z klientem, firma programistyczna dostosowuje odpowiednie plany i wdrożenia, które mogą być skutecznie zastosowane w procesie pracy klienta.

Wyniki

W porównaniu do starych rozwiązań, jakie różnice i zmiany przyniosło nowe rozwiązanie dla klienta? Na przykład: poprawa efektywności procesów produkcyjnych, skrócenie czasu na integrację informacji, zapewnienie nowych kanałów dotarcia do klientów...

Podsumowując te cztery aspekty opisu projektu programistycznego, możemy uzyskać wstępne zrozumienie projektu. Podczas dyskusji z klientem, kierownik projektu musi upewnić się, że te opisy są dla nas jasne. Opis projektu programistycznego jest elastyczny, może być krótki, jak jedno zdanie, które mówi, co projekt robi, lub długi, jak raport opisujący zawartość projektu. W tym momencie można spróbować:

Utworzyć „wartość podstawową”, która określi zakres projektu

Projekt jest projektem, ponieważ w ograniczonych zasobach osiąga określony cel. Jednak w procesie osiągania tego celu, jeśli nie ma ograniczeń zakresu, mogą pojawić się „powiązane” funkcje. Pojawienie się tych powiązanych funkcji może znacznie poprawić całe rozwiązanie, ale może również wydłużyć czas rozwoju, co uniemożliwi terminowe wdrożenie; może się też okazać, że nie przynoszą one konkretnych korzyści dla całego rozwiązania.

Przykład:

Klient chce stworzyć funkcję „naciśnij przycisk start, aby automatycznie uruchomić zadania harmonogramu” dla systemu informacyjnego przedsiębiorstwa. Intuicyjnie może to wymagać tylko połączenia kolejnych procesów pracy, jednak w rzeczywistości rozwój może wymagać uwzględnienia różnych logik biznesowych, takich jak uprawnienia do wykonywania, stan poprzedniego wykonania, stabilność połączenia systemu, w zależności od zastosowania systemu. W tym momencie klient nagle mówi w grupie dyskusyjnej: „Chcę, aby po naciśnięciu przycisku start, pojawiło się uczucie życia i ruchu.”

Podczas rozwoju oprogramowania, planując funkcje na podstawie pojedynczej historii użytkownika, często musimy uwzględniać scenariusze i różne logiki biznesowe. Gdy klient nie ma innych zastrzeżeń co do funkcji, może skupić się na kolorach interfejsu, układzie, zachowaniu przycisków, przejściach między stronami i zaczyna mieć różne wymagania, zawsze chcąc, aby interfejs był bardziej żywy.

Co zrobić, gdy w ograniczonym czasie rozwoju funkcje rozwoju i oczekiwania klienta dotyczące interfejsu systemu są sprzeczne?

W tym momencie należy wrócić do podstawowej „wartości podstawowej”, aby potwierdzić konieczność i priorytet tych funkcji w kontekście dostępnego czasu i zasobów ludzkich. Wartość podstawowa jest często krótkim, zwięzłym hasłem, które działa jak potężne zaklęcie, pomagając nam w rozważaniu dodawania lub usuwania historii użytkowników, powtarzając je trzy razy, aby uzyskać jasną odpowiedź w naszych umysłach!

W przykładzie powyżej, gdy klient staje się uparty, możemy skierować dyskusję na myślenie „Jakie korzyści dla operacji systemu informacyjnego przedsiębiorstwa przynosi bardziej żywy interfejs?” „Jeśli chcemy, aby interfejs był bardziej żywy, musimy zacząć od projektowania, co dodatkowo wydłuży czas planowania, co może opóźnić harmonogram wdrożenia, czy to dobrze?” Następnie proponujemy „Sugerujemy, aby zgodnie z 'wartością podstawową' zmodyfikować i uporządkować zgłoszone wymagania według priorytetów, aby umożliwić terminowe wdrożenie w ramach harmonogramu.”

W każdym projekcie, podczas dyskusji z klientem, wspólnie określajcie najbardziej odpowiednią „wartość podstawową”

Wartość podstawowa projektu pozwala nam, niezależnie od tego, czy prowadzimy dyskusje w zespole deweloperskim, czy przeprowadzamy wywiady z klientem lub odbiory, działać jak latarnia morska, prowadząc nas w morzu dyskusji, aby nie zbaczać z tematu i wracać do głównej osi projektu. Jeśli dziś czytasz ten artykuł i również masz trudności z wymaganiami klienta, spróbuj wypisać wartość podstawową projektu, aby przekonać siebie i klienta!