Czy użytkownicy mogą samodzielnie zbierać wymagania lub prowadzić je?

Jestem pewien, że każdy doświadczył czegoś takiego. Idziesz na spotkanie z klientem, który ma projekt. Nie mają na uwadze / mało wymagań i niejasne zrozumienie tego, czego chcą / potrzebują. W tym momencie wydają się być dwie opcje:

1) Powiedz użytkownikom: „Ok, więc nie mogę zbudować dla ciebie czegoś, jeśli jeszcze nie potrafisz tego opisać. Dlaczego nie spotkamy się za kilka tygodni, kiedy będziesz wiedział, czego chcesz”.

2) Spotkaj się z użytkownikami kilka razy i pomóż im dowiedzieć się, czego chcą, prowadząc ich dobrą metodą Socratic. „Czy potrzebujesz śledzić X?”, „A co z Y?”, „Czy potrzebujesz funkcjonalności Z?”

W przypadku pierwszej opcji nie utkniesz, wykonując czyjąś pracę lub zyskując moce psychiczne, jednak użytkownicy mogą nigdy nie przedstawić ci spójnej specyfikacji lub mogą trwać wiecznie w miarę upływu terminu. Dzięki drugiej opcji tracisz mnóstwo czasu, stając się analitykiem biznesowym, i musisz wcisnąć sobie do głowy sporo wiedzy biznesowej, której prawdopodobnie nigdy więcej nie wykorzystasz, ale znacznie bardziej prawdopodobne jest, że wyjdziesz ze specyfikacją, która ma jakikolwiek sens.

Dla mnie jest to jeden z najtrudniejszych aspektów rozwoju i mam wrażenie, że nie jestem sam w tym nastroju. Z własnego doświadczenia, która z tych opcji działa lepiej?

Muszę przyznać, że czasami wybieram opcję 3)

3) Słuchaj klientów niejasnych pomysłów, zbledź na myśl o spędzaniu tygodni, pomagając im w znalezieniu dokładnie tego, czego chcą ... więc dowiedz się, czego potrzebują, zbuduj to i refaktoryzuj zgodnie z wymaganiami.

Działa to szczególnie w przypadku małych prac, ponieważ pomaga uniknąć sytuacji, w których klienci mają w głowie ten genialny pomysł, który jest niepraktyczny w prawdziwym świecie.

Cały czas mi się to zdarza; „na pewno moglibyśmy zrobić ...” to bardzo przerażające zdanie. Zwłaszcza, że ​​wspomniane rzeczy to prawie zawsze dzwony, gwizdy i „miło mieć” klasę funkcji. Nie do końca rozumieją to w stwierdzeniu „no cóż, oczywiście narzędzie do śledzenia błędów, a potem ...” większość potencjalnych prac opiera się na pierwszych czterech słowach.

Czasami miło jest przyjąć wizję klienta , zastosować przyzwoitą dawkę programistów - zdrowy rozsądek i zbudować coś, co odpowiada ich potrzebom.

Pod względem pierwotnego pytania; Uważam, że wiele zależy od kontekstu. Jeśli utknąłem z klientem (tj. Jest to związane z umową o pracę, z którą jestem związany lub nie ma innej pracy), to # 2 jest najmądrzejszym podejściem. W przeciwnym razie istnieje duże prawdopodobieństwo, że za tydzień otrzymasz wspaniałą i szczegółową specyfikację ... która jest całkowicie bezużyteczna jako programista.

Zupełnie taki sam problem jak wspomniany powyżej (# 3) i taki, który sprawia, że ​​i tak musisz zrobić # 2.

jeśli chcesz być tylko programistą, zaczekaj, aż ktoś inny zorientuje się, czego potrzebuje klient, a następnie zakoduj to

jeśli chcesz zostać deweloperem , a to jest twój klient, to weź go za rękę i delikatnie spaceruj po gęstym, przerażającym lesie możliwości, aż razem znajdziesz szczęśliwą, wypełnioną króliczkiem łąkę na przecięciu Wants and Needs.

DODATEK: proces ten nazywa się „analizą i projektowaniem systemów”, czyli Doradztwem, i nigdy nie powinien być wykonywany za darmo

Programowanie polega przede wszystkim na rozwiązywaniu problemów użytkowników. Więc dla mnie wkładanie „dodatkowego” wysiłku i bólu w celu uzyskania działającego, satysfakcjonującego rozwiązania dla naszych użytkowników prawie zawsze wygrywa, unikając „dodatkowych” kłopotów i nie dostarczając niczego przydatnego w końcu.

(Oczywiście, istnieją prawdziwi użytkownicy, którzy tak naprawdę nie mają pojęcia, czego chcą, i żaden wysiłek nie może doprowadzić ich do stanu, w którym mogliby podjąć jakąkolwiek sensowną decyzję. Ale wierzę, że w większości przypadków mają prawdziwy problem, są gotowi poświęcić wysiłek i pieniądze, aby go rozwiązać, i będą szczęśliwi, jeśli pomożemy im zbliżyć się do działającego rozwiązania).

Podsumowując, naszym celem powinno być rozwiązywanie problemów użytkowników. Czasami może to wymagać zadawania ukierunkowanych pytań i dawania im więcej czasu na znalezienie odpowiedzi. Czasami wymaga sporządzenia wykresu domeny razem, w ścisłej współpracy. Czasami wymaga poświęcenia czasu na wykonanie prostych szkiców / prototypów / makiet, a następnie pokazanie im wyniku i zadanie pytania „czy to wygląda na to, co miałeś na myśli?” (potem wyrzucając prototyp, gdy mówią „właściwie, myślałem o czymś zupełnie innym ...” i zaczynam od nowa… :-)

Prawdziwą umiejętnością jest wybór odpowiedniego podejścia we właściwym czasie.

Wreszcie, z mojego doświadczenia, dobre rozwiązania prawie zawsze wymagają przynajmniej pewnej wiedzy domenowej ze strony dewelopera. Bez tego nie ma prawdziwego wspólnego języka z użytkownikiem, dlatego nie ma żadnej gwarancji, że to, co dostarczysz, będzie dla niego naprawdę przydatne. Użytkownicy zazwyczaj nie mają pojęcia o technologii, więc nie mają pojęcia o tym, co jest i nie jest możliwe oraz jaki jest koszt różnych podejść / funkcji. Ponieważ nie możemy racjonalnie oczekiwać, że nauczą się technologii z wystarczającą szczegółowością, powinniśmy zrobić ten dodatkowy krok od końca mostu.

Może to być postrzegane jako „dodatkowy” wysiłek, który się nie zwraca - jednak wolę postrzegać to jako inwestycję z dwóch powodów:

• pomaga mi dostarczać dobre rozwiązania, które w dłuższej perspektywie zwiększają moją wartość rynkową jako programisty, oraz
• różne domeny nie są całkowicie odrębne, więc przynajmniej część tej wiedzy będzie prawdopodobnie mogła być wykorzystana w przyszłości.

Jako programista częścią twojego zadania jest uzyskanie wystarczającej wiedzy na temat dziedziny, w której oprogramowanie będzie używane. Dlatego bycie częścią początkowej fazy projektu jest niezwykle cenne (pod względem czasu i doświadczenia klienta) . Tak, oznacza to przeprowadzenie dokładnej analizy domeny i wymagań. To idealny czas na włączenie docelowych użytkowników, przesłuchanie ich lub obejście miejsca, w którym będzie używane oprogramowanie.

Ale zdobycie tej umiejętności jest niemal formą sztuki, szczególnie gdy dziedzina nie jest związana z dyscypliną inżynieryjną. Twoje oczywiste pytania mogą wydawać się zniechęcające dla klienta, Twoja obecność na miejscu może nie być pożądana, twoje niezrozumienie struktury społecznej odbiorców docelowych może zniszczyć wciąż kruche połączenia.

Niezrozumienie zawiłości tej fazy często prowadzi do rozczarowania zarówno twórcami oprogramowania, jak i klientem. Chcielibyśmy szybciej przejść przez tę fazę lub całkowicie ją zlikwidować. Rezultaty są często katastrofalne: po przyspieszonym starcie, podczas rozwoju stawka sukcesu rośnie, a powrót do deski kreślarskiej jest coraz trudniejszy. Kiedy system zostanie ostatecznie ukończony i wydane zostaną miliony, ani klient, ani firma inżynierska nie są skłonni przyznać się do jego awarii, co prowadzi do wymuszonego wprowadzenia uszkodzonego systemu.

Alternatywą jest umożliwienie analitykowi biznesowemu wykonania pracy za Ciebie. Może to mieć sens w przypadku niektórych produktów, a analityk często może być pośrednikiem, ale stworzy tylko więcej kanałów komunikacji (a tym samym większą szansę na błąd).

W każdym razie: przepisywanie fragmentu kodu nigdy nie przeważa przepisywania fragmentu wymagań.

ps może myślisz, że zalecam metodę wodospadu. Nie jestem zwolennikiem „dużego projektu z góry”, ale uważam, że wysiłek analizy domeny powinien być proporcjonalny do wysiłku wdrożenia. Można wykonać wiele cykli (prototyp, kandydaci do wydania itp.).

Zdecydowanie opcja 2, chyba że Twoi użytkownicy są programistami (nawet wtedy opcja 2 może być potrzebna).

Większość cykli życia oprogramowania skupia się na zbieraniu wymagań. Większość użytkowników nie tylko nie wie, czego chce, ale także nie wie, co jest możliwe, dlatego też praca z użytkownikiem w celu zrozumienia, czego potrzebuje użytkownik, jest kluczowym zadaniem w zakresie tworzenia oprogramowania.

Myślę, że musisz wybrać obie opcje. Pozwól im odejść i zdecyduj, czego chcą. Następnie, gdy istnieje konkretny pomysł, który można wykorzystać jako punkt wyjścia, poprowadź go, aby dopracować wymagania dotyczące czegoś użytecznego.

Nie chcesz przeskakiwać do Opcji # 2, gdy ledwo potrafią wyrazić to, czego chcą, ponieważ spowoduje to spowolnienie całego procesu i bardziej frustrację (chyba że mają już bardzo jasne wyobrażenie o tym, czego chcą, kiedy do ciebie przyjdą, ale z mojego doświadczenia wynika, że ​​jest to bardzo rzadkie). Spraw, by zebrali swoje pomysły. Poproś, aby coś zapisali na papierze, jeśli to możliwe, opisz to, czego chcą w odniesieniu do istniejących systemów (np. „Chcemy strony internetowej takiej jak blahblah.com, ale z tymi różnicami ... chcemy narzędzia, które wykonuje Zadanie A jak Produkt X , ale interfejs użytkownika musi również wykonać zadanie B ... ”). To dobry moment, aby zacząć zawężać to, czego chcą, do bardzo konkretnych wymagań, których możesz użyć do zbudowania systemu.

Ogólnie rzecz biorąc, klienci przychodzą do Ciebie, wiedząc dokładnie, czego potrzebują. Niestety, to właśnie ci powiedzą, zamiast opisywać problem (y), które prowadzą do rozwiązania, które według nich dostarczysz.

Aby zaprojektować coś, co zaspokoi ich potrzeby, musisz zidentyfikować te potrzeby, a aby to zrobić, ktoś będzie musiał przytrzymać klienta i wyodrębnić te potrzeby. Jeśli nikt inny nie może tego zrobić, musisz. (Jeśli ktoś inny uważa, że ​​może, być może będziesz musiał usiąść z nim i wydobyć prawdziwe potrzeby później ...)

Dzięki opcji 2 podczas wielu spotkań możesz, mam nadzieję, przeszkolić klienta w dzieleniu się z Tobą problemami, a nie rozwiązaniami. (Nawet jeśli klient ma zdolność techniczną - na przykład nie ma możliwości wykonania tej pracy i musi to zrobić zamiast tego - może nadal koncentrować się na implementacji, która nie jest idealna dla klienta końcowego). bez względu na to, jakiego procesu rozwoju używasz, nadal będziesz musiał kilka razy przewijać do przodu i do tyłu, aż będą mogli odpowiedzieć na pytania w sposób, który określi dla Ciebie specyfikację.

Pamiętaj, że chcesz wychwycić defekty na jak najwcześniejszym etapie cyklu programowania. Jeśli złapiesz je podczas wymagań, a nie podczas kodowania lub testowania, zaoszczędzisz sobie dużo czasu.

Opcja 1 to doskonały sposób na uniknięcie pracy. Użyłem go, gdy uważałem, że praca jest niepotrzebna lub miałem ważniejsze rzeczy do zrobienia.

Po pierwsze, użytkownicy nie wiedzą, co potrafią komputery. Większość z nas przez lata uczyła się rozumieć komputery i obliczenia, a to, co dla nas oczywiste, może nie być łatwo zrozumiałe dla kogoś, kto spędził te lata na nauce innych rzeczy.

Po drugie, użytkownicy niekoniecznie wiedzą, czego potrzebują i zwykle nie wiedzą, czego chcą, w jakimkolwiek sensownym sensie.

Aby dać analogię, kiedy kupiłem mój obecny dom, projektant wnętrz wybrał kolory ścian dla pokoi na parterze głównym (pierwszy w USA, w Wielkiej Brytanii). Sam nigdy nie wybrałbym tych kolorów. Chciałem dom, który wyglądałby dobrze i dostałem go. Gdyby projektant mnie wysłuchał i dał mi wszystko, co mógłbym wypowiedzieć, nie wyszedłoby to równie dobrze.

Jedynym sposobem, aby dać użytkownikom coś, co robi w sposób, który im się podoba, jest praca z nimi samemu.