Coaxing wymagania od ludzi biznesu?

Jakie metody wydają się działać najlepiej w celu nakłonienia pracowników do niezwiązanych z nimi technologii? Współpracuję z zespołem, który próbuje zebrać specyfikację dla projektu. Za każdym razem, gdy się spotykamy i sprowadza się to do oczekiwań na kolejne spotkanie, prosimy biznesmenów o przywrócenie ich wymagań. Zwykle odpowiadają mniej więcej tak: „Czy sądzisz, że moglibyście ulepszyć prototyp, abyśmy mogli zobaczyć, co lubimy w przyszłym tygodniu… no wiesz, bez żadnych danych lub czegokolwiek, ponieważ jest to prototyp, tylko funkcjonalność”. to ponad 6-miesięczny projekt, więc jest to oczywiście niewykonalne (musielibyśmy opracować całość!), a nawet nie wiemy, co prototypować bez jakiejś specyfikacji. Szczerze mówiąc, myślę, że jak większość ludzi, mają pewne pojęcie o tym, czego chcą, po prostu nie myślą o tym w skoncentrowany sposób niezbędny do spełnienia prawdziwych wymagań. Zamiast po prostu powiedzieć im, „Daj nam to, czego chcesz, a my nie możemy / nie będziemy wykonywać żadnej pracy” (chcemy, aby byli zadowoleni z wyników), czy istnieją sposoby, aby pomóc im zdecydować, czego chcą? Na przykład możemy im powiedzieć:

„Narysuj kilka ekranów (w programie Powerpoint, na serwetce, cokolwiek), które pokazują interfejs użytkownika ze wszystkimi danymi, które chcesz zobaczyć, oraz opis funkcji na marginesach. Na tej podstawie dopracujemy go i zbudujemy backend w oparciu o ten zestaw wymagań zachowania. ”

LUB

„Nie martw się tym, jak teraz będzie wyglądać (rozłączanie się z numerem 1). Po prostu podaj nam listę wszystkich danych, które chcesz o każdej rzeczy, którą program śledzi. Tak więc w przypadku „Klienta” możesz podać: imię i nazwisko, adres, numer telefonu, zamówienia itp. Nie musi to być idealna struktura bazy danych, ale możemy coś z tego wypracować i dowiedzieć się, czego szukasz ”

Czy którekolwiek z tych alternatywnych podejść, aby ludzie biznesu skoncentrowali się na tym, czego chcą, ma sens? Czy są jakieś alternatywy, które widziałeś w akcji?

Ostatnie 3 miesiące spędziłem w wyczerpującej - i wyczerpującej - fazie zbierania wymagań dużego projektu i nauczyłem się przede wszystkim, że nie ma jednego uniwersalnego rozwiązania . Nie ma żadnego procesu, żadnego sekretu, który działałby w każdym przypadku. Analiza wymagań to prawdziwa umiejętność i właśnie wtedy, gdy wydaje ci się, że w końcu wszystko to rozgryzłeś, zostajesz narażony na zupełnie inną grupę ludzi i musisz wyrzucić wszystko, co znasz.

Kilka lekcji, których się nauczyłem:

• Różni interesariusze myślą na różnych poziomach abstrakcji.

  Łatwo jest powiedzieć „Dyskusja na poziomie biznesowym, nie techniczny”, ale nie jest to koniecznie, że łatwo zrobić . System, który projektujesz, jest słoniem, a twoimi interesariuszami są ślepi badający go . Niektórzy ludzie są tak głęboko zanurzony w procesie i rutyny, że nie zdają sobie nawet sprawy, że nie jest biznes. Inni mogą pracować na poziomie abstrakcji, który chcesz, ale mogą być skłonni do przesadzania, a nawet fałszywych twierdzeń lub angażowania się w pobożne życzenia.

  Niestety, musisz po prostu poznać wszystkie osoby jako jednostki i zrozumieć ich zdanie, nauczyć się interpretować to, co mówią, a nawet zdecydować, co zignorować.

• Dziel i rządź

  Jeśli nie chcesz, aby coś zostało zrobione, wyślij je do komitetu.

  Nie spotykaj się z komisjami. Utrzymuj te spotkania tak małe, jak to możliwe. YMMV, ale z mojego doświadczenia wynika, że ​​idealny rozmiar to 3-4 osoby (włączając ciebie) na sesje otwarte i 2-3 osoby na sesje zamknięte (tj. Kiedy potrzebujesz odpowiedzi na konkretne pytanie).

  Staram się spotykać z ludźmi, którzy mają podobne funkcje w biznesie. Naprawdę niewiele można zyskać i bardzo wiele do stracenia po rzuceniu marketingowców w pokoju z licznikami fasoli. Poszukaj ludzi, którzy są ekspertami w jednym temacie i poproś ich o rozmowę na ten temat.

• Spotkanie bez przygotowania jest spotkaniem bez celu.

  Kilka innych odpowiedzi / komentarzy odnosiło się do techniki słomianego człowieka, która jest doskonała dla tych kłopotliwych ludzi, z których po prostu nie można uzyskać żadnych odpowiedzi. Ale nie polegaj zbytnio na ludziach ze słomy , bo inaczej ludzie zaczną czuć się, jakbyś ich szynował. Musisz delikatnie popychać ludzi we właściwym kierunku i pozwolić im sami wymyślić szczegóły, aby czuli, że są ich właścicielami (i, w pewnym sensie, są ich właścicielami).

  To, co musisz mieć, to jakiś mentalny model tego, jak myślisz, jak działa biznes i jak powinien działać system . Musisz zostać ekspertem w dziedzinie , nawet jeśli nie jesteś ekspertem w danej firmie. Wykonaj jak najwięcej badań dotyczących swojej firmy, jej konkurentów, istniejących systemów na rynku i wszystkiego, co może być nawet zdalnie powiązane.

  Kiedyś w tym momencie uznałem, że najbardziej efektywna jest praca z konstrukcjami wysokiego poziomu, takimi jak przypadki użycia, które wydają się być zgodne dla wszystkich, ale nadal bardzo ważne jest zadawanie konkretnych pytań. Jeśli zaczniesz od „Jak wystawiać rachunki swoim klientom?” jesteś na bardzo długim spotkaniu. Zadawaj pytania, które sugerują proces, zamiast eliminować go od samego początku: Jakie są elementy zamówienia? Jak są obliczane? Jak często się zmieniają? Ile jest różnych rodzajów sprzedaży lub umów? Gdzie są drukowane? Masz pomysł.

  Jeśli przegapisz krok, ktoś zwykle ci to powie. Jeśli nikt nie narzeka, klepnij się po plecach, ponieważ właśnie niejawnie potwierdziłeś ten proces.

• Odkładaj dyskusje poza tematem .

  Jako analityk wymagań odgrywasz również rolę facylitatora i chyba, że ​​naprawdę lubisz spędzać cały czas na spotkaniach, musisz znaleźć sposób, aby utrzymać porządek. Jak na ironię, to problem staje się najbardziej złośliwa, kiedy wreszcie nie dostać ludzie rozmawiają. Jeśli nie będziesz ostrożny, może wykoleić pociąg, na który tyle czasu spędziłeś układając tory.

  Jednak - i nauczyłem się tego na własnej skórze dawno temu - nie możesz po prostu powiedzieć ludziom, że problem jest nieistotny . Jest to oczywiście dla nich istotne , inaczej nie rozmawialiby o tym. Twoim zadaniem jest zmusić ludzi, by mówili „tak” tak często, jak to możliwe, a postawienie takiej bariery po prostu powali cię na terytorium „nie”.

  Jest to delikatna równowaga, którą wiele osób jest w stanie utrzymać dzięki „przedmiotom akcji” - w zasadzie ogólna kolejka dyskusji, do której obiecałeś kiedyś wrócić , zwykle oznaczona nazwiskami interesariuszy, którzy uważali to za bardzo ważne. Nie tylko ze względu na dyplomację - jest to również cenne narzędzie, które pomoże ci zapamiętać, co się działo podczas spotkań i z kim porozmawiać, jeśli będziesz potrzebować wyjaśnień w późniejszym terminie.

  Różni analitycy traktują to na różne sposoby; niektóre jak bardzo publiczna tablica lub tablica flip-chart, inni po cichu podłączają ją do swoich laptopów i delikatnie segregują inne tematy. Z czymkolwiek czujesz się komfortowo.

• Potrzebujesz agendy

  Jest to prawdopodobnie prawdą w przypadku prawie każdego rodzaju spotkania, ale podwójnie dotyczy to spełnienia wymagań. Gdy dyskusje ciągną się, ludzkie umysły zaczynają błądzić i zaczynają się zastanawiać, kiedy dojdziesz do rzeczy, na których im naprawdę zależy. Posiadanie planu zapewnia pewną strukturę, a także pomaga określić, jak wspomniano powyżej, kiedy trzeba odroczyć dyskusję, która wychodzi poza temat.

  Nie wchodź tam bez jasnego pojęcia, co dokładnie chcesz i kiedy chcesz . Bez tego nie możesz ocenić własnego postępu, a użytkownicy będą cię nienawidzić za to, że zawsze biegasz długo (zakładając, że nie nienawidzą cię z innych powodów).

• Mock It

  Jeśli użyjesz programu PowerPoint lub Visio jako narzędzia do makiety, będziesz cierpieć z powodu problemu, że będzie wyglądał na zbyt dopracowany . To prawie niesamowita dolina interfejsów użytkownika; ludzie będą czuć się komfortowo dzięki rysunkom na serwetkach (lub rysunkom generowanym komputerowo, które wyglądają jak rysunki na serwetkach, za pomocą narzędzia takiego jak Balsamiq lub Sketchflow ), ponieważ wiedzą, że to nie jest prawdziwe - z tego samego powodu ludzie mogą oglądać postacie z kreskówek. Ale im bardziej zacznie wyglądać jak prawdziwy interfejs użytkownika, tym więcej osób będzie chciało go wybrać i łapać, i tym więcej czasu spędzą na kłótni o szczegóły, które ostatecznie są nieistotne.

  Zdecydowanie więc wykonuj makiety, aby sprawdzić swoje zrozumienie wymagań ( po wstępnych etapach analizy) - to świetny sposób na uzyskanie bardzo szybkiej i szczegółowej informacji zwrotnej - ale zachowaj je w trybie lo-fi i nie spiesz się z wyśmiewaniem, dopóki nie „ jesteś całkiem pewien, że widzisz oko w oko ze swoimi użytkownikami.

  Pamiętaj, że makieta nie jest rezultatem , jest narzędziem ułatwiającym zrozumienie. Tak jak nie spodziewałbyś się, że będziesz trzymany w niewoli podczas próby projektowania interfejsu użytkownika, nie możesz zakładać, że projekt jest w porządku, po prostu dlatego, że dali twoją makietę kciuki do góry. Widziałem drwiny używane jako kula lub, co gorsza, pretekst do całkowitego ominięcia wymagań; upewnij się, że tego nie robisz. Wróć i zamień tę próbkę w prawdziwy zestaw wymagań.

• Bądź cierpliwy.

  Wielu programistom trudno w to uwierzyć, ale w przypadku większości nietrywialnych projektów nie można po prostu usiąść raz i opracować pełną funkcjonalną specyfikację. Nie mówię tylko o cierpliwości podczas jednego spotkania; analiza wymagań jest iteracyjna w taki sam sposób jak kod. Grupa A mówi coś, a następnie grupa B mówi coś, co całkowicie zaprzecza temu, co usłyszałeś od grupy A. Następnie grupa A wyjaśnia niekonsekwencję i okazuje się, że grupa C zapomniała o tym wspomnieć. Powtórz 500 razy, a masz coś mniej więcej przypominającego prawdę .

  Jeśli nie tworzysz małej aplikacji CRUD (w takim razie po co w ogóle męczyć się z wymaganiami?), Nie spodziewaj się, że dostaniesz wszystko, czego potrzebujesz na jednym spotkaniu, dwóch lub pięciu. Będziesz dużo słuchał, dużo mówił i dużo powtarzał. Co nie jest okropne, pamiętajcie; jest to szansa na nawiązanie kontaktu z ludźmi, którzy nieuchronnie będą podpisywać się na twoim produkcie.

• Nie bój się zmieniać techniki lub improwizować.

  Różne aspekty projektu mogą wymagać różnych technik analizy. W niektórych przypadkach klasyczny UML (użycie przypadku / diagram aktywności) działa świetnie. W innych przypadkach możesz zacząć od biznesowych KSI, burzy mózgów z mapą myśli lub zanurkować w makiety pomimo mojego wcześniejszego ostrzeżenia.

  Najważniejsze jest to, że musisz sam zrozumieć domenę i odrobić pracę domową, zanim zmarnujesz czas kogoś innego. Jeśli wiesz, że określony dział lub komponent ma tylko jeden przypadek użycia, ale jest to niezwykle skomplikowany przypadek, pomiń analizę przypadku użycia i zacznij mówić o przepływach pracy lub przepływach danych. Jeśli nie używałbyś tego samego narzędzia do każdej części implementacji aplikacji, to dlaczego miałbyś używać tego samego narzędzia do każdej części wymagań?

• Trzymaj ucho na ziemi.

  Ze wszystkich wskazówek i porad, które przeczytałem na temat analizy wymagań, jest to prawdopodobnie jedna z najczęściej pomijanych. Szczerze mówiąc, nauczyłem się więcej podsłuchiwania i od czasu do czasu zawieszania rozmów z fajniejszą wodą niż z zaplanowanych spotkań.

  Jeśli jesteś przyzwyczajony do pracy w izolacji, postaraj się znaleźć miejsce, gdzie jest akcja, aby usłyszeć paplaninę. Jeśli nie możesz, po prostu rób częste obchody, do kuchni, łazienki lub gdziekolwiek. Dowiesz się różnego rodzaju interesujących rzeczy na temat tego, jak naprawdę działa firma, od słuchania tego, co ludzie chwalą się lub narzekają podczas przerw na kawę i dym.

• Na koniec przeczytaj między wierszami .

  Jednym z moich największych błędów w przeszłości było tak skoncentrowanie się na efekcie końcowym, że nie poświęciłem czasu, by usłyszeć, co mówią ludzie . Czasami - przez większość czasu - może się wydawać, że ludzie nie zwracają uwagi na nic lub wymyślają jakieś procedury, które brzmią dla ciebie zupełnie bezcelowo, ale jeśli naprawdę skoncentrujesz się na tym, co mówią, zrozumiesz, że tak naprawdę jest zakopany tam wymóg - lub kilka.

  Choć brzmi banalnie i mdle, Five Whys jest tutaj bardzo przydatną techniką. Ilekroć pojawia się ta „głupia” reakcja na kolana (nie żebyś kiedykolwiek powiedział to głośno), zatrzymaj się i zmień to w pytanie: dlaczego? Dlaczego ta informacja jest czterokrotnie przepisywana, a następnie drukowana, kopiowana, skanowana, drukowana ponownie, przypinana do płyty wiórowej, fotografowana cyfrowym aparatem i wreszcie wysyłana pocztą elektroniczną do kierownika sprzedaży? Nie jest to powód , a oni nie mogą wiedzieć, co to jest, ale jest to zadanie, aby dowiedzieć się. Powodzenia z tym. ;)

Jeśli nie możesz czegoś z nich wyciągnąć, napisz coś i poproś o zatwierdzenie. Dużo łatwiej jest osobom nietechnicznym powiedzieć „nie, nie podoba mi się to” niż „tak właśnie należy to zrobić”.

Często to, czego chcą i co ci mówią, to dwie bardzo różne rzeczy. Poświęć trochę czasu, aby napisać pierwszy szkic specyfikacji z informacjami, które obecnie znasz. Poproś zainteresowane strony o przeczytanie i zatwierdzenie. Kiedy to przeczytają, bardziej niż prawdopodobne zobaczą rzeczy, które im się nie podobają lub z którymi się nie zgadzają. Uzyskaj ich opinie, a następnie popraw.

Jeśli jest coś, na co możesz pójść w jedną lub drugą stronę, skorzystaj z obu opcji online i poproś osobę podejmującą decyzję o dokonaniu wyboru. Nie zostawiaj ich samych, dopóki tego nie zrobią.

Jeśli chodzi o prototypy, wykonaj makiety ekranów i wyjaśnij, jak to by działało. Ponownie, widząc coś, pomaga im wizualizować, co się dzieje. Zabierz ze sobą nowe makiety ekranowe na spotkania i uzyskaj odpowiedzi.

W przeszłości otworzyłem FireBug i dodałem zmianę, o którą klient prosił tuż przed nimi, aby mogli zobaczyć, jak to będzie wyglądać. Wyrazili swoją opinię, zrobiłem zrzut ekranu i wprowadziłem zmiany. Naprawdę podobało im się, że mogą zobaczyć, jak będzie wyglądać zmiana, i podobało mi się to, ponieważ było szybkie i otrzymałem odpowiedź na tym spotkaniu ... nie na następnym.

Niech rozmawiają więcej o swojej firmie, a mniej o aplikacjach. Dowiedz się, jakie są prawdziwe problemy: raportowanie na koniec miesiąca trwa zbyt długo, błędy wprowadzania danych, przerosły obecną aplikację, rozwój firmy wymyka się spod kontroli.

Zgaduję, że te spotkania odbywają się z osobami dokonującymi zakupów, ale nie z ludźmi, którzy faktycznie wykonają pracę związaną z aplikacją. Zapytaj, czy możesz spotkać się z kilkoma wybranymi osobami. Mogą pokazać ci, jak rzeczy są naprawdę zrobione. Upewnij się, że masz do czynienia z klientami, którzy zaplanowali swój czas i koszty.

Sprawdź, czy mają jakieś raporty, których obecnie używają lub chcą z nich korzystać. Oczywiście nie możesz utworzyć raportu, jeśli nie zbierzesz danych poprawnie. Muszą coś robić, chyba że jest to biznes, którego jeszcze nie rozpoczęli.

Wielu ma ogólne wyobrażenie, że jesteś programistą, więc wiesz, jak zbudować wszystkie programy. Strony eCommerce są takie same, prawda?

Zacznij od małego. Niestety, dopóki nie pojawi się coś przed nimi, proces po prostu się nie rejestruje. Jeśli nie masz nic do przejścia, po prostu sfałszuj to.

Wiele ma to związek z ogólnymi umiejętnościami interpersonalnymi i przede wszystkim z tym, jak komunikujesz się z klientem. Niewiele mogę o tym powiedzieć, poza tym - upewnij się, że wyjaśnisz ten proces jako interaktywny, w którym oczekujesz również opinii i wysiłku ze strony klientów.

Oto kilka porad dotyczących konkretnie opisanego scenariusza: Zacznij od opisania tego, co uznasz za przydatne, i zapewnij pojazdy do opisu informacji w kategoriach, które nie wymagają specjalizacji technicznej ani know-how:

• Historie użytkowników / przypadki użycia Zapytaj o szczegółowe opisy tego, czego użytkownicy oczekują, jakich informacji potrzebują, aby to zrobić, a także tego, czego powinieneś i czego można oczekiwać od użytkowników. Gdy zdobędziesz te informacje, przejrzyj je razem z nimi i upewnij się, że wszystko jest pokryte historiami - nie powinno być niczego, co wejdzie do aplikacji, w której nie ma opowieści obejmujących to, co zrobi użytkownik.

• Ciekawe pokazy Co jest ważniejsze, aby zdobyć klientów? Które części programu lub funkcjonalności muszą się wyróżniać i muszą być całkowicie dopracowane? Czy możesz mi dostarczyć próbną wersję demonstracyjną, używając notatek pocztowych, kartonów lub innych stand-ins, które chciałbyś mieć?

• Informacje rynkowe / konkurencyjne Co robimy dla każdej historii użytkownika, która jest podobna do naszych konkurentów? Różne? Jaką historię opowiadają nasi konkurenci i czy staramy się kopiować / emulować / ulepszać / wprowadzać innowacje / celowo się różnić?

• Pytania otwarte Co do wymagań i projektu są informacje, których jesteś pewien i co to jest eksperyment? Gdzie wypróbujemy alternatywy, aby zobaczyć, która z nich działa? Jeśli zastanawiasz się nad wieloma alternatywami i powiedziałeś nam tylko jedną, jakie inne rozważasz?

Następnie narysuj kilka granic:

• Nie nakładaj na mnie ograniczeń technicznych . Przedsiębiorca nie powinien mówić ci „korzystaj z systemu Windows, ponieważ jest lepszy niż Linux”. Mogą jednak przekazywać instrukcje w stylu: „nasz cały rynek docelowy korzysta z systemu Windows, nasza aplikacja będzie musiała działać w systemie Windows, aby odnieść sukces”

• Nie martw się o projekt Zwłaszcza jeśli masz do czynienia z ludźmi zorientowanymi na sprzedaż lub marketing, będą mieli problemy z projektowaniem. Ponownie zawęź zakres informacji do tego, w czym się specjalizują - „niebieski jest tu piękniejszy” prawdopodobnie nie jest odpowiedni. „Nasz konkurent używa motywu koloru niebieskiego i istnieje już od lat 80., w przypadku części naszego programu, w których nie wprowadzamy innowacji, powinniśmy użyć niebieskiego schematu, aby poinformować, że nie jesteśmy nowi”, prawdopodobnie jest to właściwe. „Nazwa powinna znajdować się na górze ekranu” prawdopodobnie nie jest odpowiednia, ale „najważniejszą informacją na tej stronie jest nazwa użytkownika i saldo konta bankowego”, prawdopodobnie tak jest. Upewnij się, że projektant jest zaangażowany w tłumaczenie tych wymagań na interfejs użytkownika.

• Zapisz decyzje Najlepiej wbuduj je w umowy lub inne zobowiązania, które podejmujesz. Pamiętaj jednak, że decyzja, której klient nie rozumie, nie jest warta papieru, na którym jest napisana. Klient wylogowujący się na „aplikacja będzie działać na porcie 1521” nie jest wart tyle, co klient wylogowujący się na ”aplikacja będzie działać na niestandardowym, konfigurowalnym porcie, który może wymagać specjalnej konfiguracji zapory ogniowej i bezpieczeństwa podczas wdrażania „

Z Twojego punktu widzenia, aby zachęcić proces do kontynuowania:

• Przekaż opinię na tym samym poziomie abstrakcji Dotyczy to na przykład jednostek - jeśli klient mówi miesięczny wolumen użytkowników, nie reaguj gigabitami przepustowości. Lub w przypadku przypadków użycia - opisz funkcjonalność w kategoriach działających przypadków użycia, a nie modułów lub poprawek błędów lub funkcji.

• Przekaż sensowną komunikację Zwróć uwagę na pytania i dodatkowe informacje, które odkryłeś lub których szukasz, w zakresie informacji, które zostały ci dostarczone. „Jedziemy z linuksem” to prawdopodobnie źle napisane informacje zwrotne, a „nasze testy pokazują, że aplikacja działa płynniej, gdy jest hostowana na komputerach z linuksem i dostępna w IE w systemie Windows” może być bardziej odpowiednia.

• Iteruj szybko Aby utrzymać zaangażowanie klienta, zapewniaj szybkie, znaczące aktualizacje i iteracje. Specyfikacje i informacje, które nie były dostępne lub łatwe do uzyskania na początku procesu, mogą wymagać dużego wysiłku od klienta, który prawdopodobnie płaci ci, podczas gdy nie płacisz im za jakąkolwiek pracę. Zaangażowanie i zainwestowanie klienta w proces może pomóc, gdy praca stanie się czymś, na co będzie musiał poświęcić czas i wysiłek.

Twoi klienci, ludzie biznesu, mogą mieć jakiś problem, chcą jakiegoś rozwiązania technicznego, ale nie mają pojęcia, jak to rozwiązanie może działać, a tym samym nie mają pojęcia, jak określić potencjalne rozwiązanie. Jeśli tak, brakuje roli analityków rozwiązań biznesowych, którzy mogą badać klienta, jego problemy, przepływy pracy itp., A także to, w jaki sposób wszelkie możliwe rozwiązania mogą pasować do ich procedur korporacyjnych, kultury itp., A także czy konkretne rozwiązanie może być możliwe do wdrożenia na czas, w ramach budżetu itp. Może to być bardzo interdyscyplinarna rola, wymagająca pewnej wiedzy zarówno o praktykach biznesowych (prawo, rachunkowość, logistyka itp.), psychologii użytkownika, jak i technologii oprogramowania.

Wygląda na to, że chcesz zmusić klienta do bycia własnym analitykiem rozwiązań biznesowych. Może nie być to rola, w której mają wystarczającą wiedzę specjalistyczną, aby zapewnić rozsądną specyfikację. I wygląda na to, że ty też nie chcesz wziąć tej roli. Jeśli ani ty, ani twój klient nie jesteście w stanie wypełnić tej roli, możesz nie mieć wszystkich ludzi potrzebnych do udanego projektu.

Czasami garść szybkich prototypów, z którymi klient może się bawić, może być jedynym sposobem na eksperymentalne odkrycie i połączenie pewnego użytecznego rozwiązania dla potrzeb klienta (dźwięcznych i bezdźwięcznych). Może to być, ale nie musi, odpowiednie dla każdego rodzaju umowy na czas nieokreślony.

DODANO: Jeśli spróbujesz wymusić dokument wymagań od klientów, którzy nie mają wymaganej wiedzy specjalistycznej, może to być ogromna czerwona flaga wskazująca zbliżającą się katastrofę.

Nie pytaj o interfejs użytkownika ani wymagania dotyczące danych, pytaj o wymagania dotyczące funkcjonalności.

Zapytaj ich o to, co ma zrobić aplikacja. Poproś, aby przejrzeli, w jaki sposób chcieliby korzystać z aplikacji. Zostaw na początku szczegóły, takie jak interfejs użytkownika, dane itp.

Odkryłem, że często użytkownicy nie wiedzą, czego chcą w zakresie interfejsu użytkownika lub danych, ale wiedzą, czego chcą, jeśli chodzi o funkcjonalność. Na przykład powiedzą mi: „Chcę się zalogować i wyświetlić wszystkie informacje o kliencie”. Nie wchodź w to, jak będą wyglądać ekrany ani jakie dane chcą, po prostu skorzystaj z ich funkcji.

Gdy to zrobisz, zrób szybki makieta (lubię Balsamiq ). Po prostu załóż, jaki będzie interfejs użytkownika / dane i nie poświęcaj na to dużo czasu. Następnie zanieś makietę do klienta. Stamtąd mogą powiedzieć „nie potrzebujemy tych pól” lub „Tak naprawdę chcemy listy numerów telefonów, a nie tylko jednego”, lub „To powinna być lista rozwijana, a nie lista”.

Gdy masz już punkt początkowy, o wiele łatwiej jest wdrożyć dane i interfejs użytkownika, a moim zdaniem określenie funkcjonalności jest najlepszym punktem wyjścia.

Sugeruję, abyś skupił się przede wszystkim na procesach biznesowych. Poproś, aby zdefiniowali, w dokumencie lub w dyskusji, jak obecnie wykonują zadania, które byłyby obsługiwane przez twoje oprogramowanie. Następnie skoncentruj się na tym, które części procesu chcieliby zmienić (powód, dla którego chcą twojego oprogramowania). Wykorzystaj to jako punkt wyjścia do dyskusji na temat tego, które inne części procesu można ulepszyć, a nawet całkowicie usunąć za pomocą oprogramowania.

Jeśli Twój klient nie jest przyzwyczajony do dostarczania wymagań dotyczących oprogramowania, Twój zespół powinien przygotować dla nich wymagania. Spodziewaj się, że przejdziesz wiele poprawek, ale powinieneś przynajmniej dostarczyć im wstępny dokument, aby pomóc przekazać to, czego szukasz.

Po zapoznaniu się z wymaganiami funkcjonalnymi oczekiwanego procesu końcowego, który będzie obejmował oprogramowanie, możesz rozpocząć tworzenie makiet interfejsów. Jeśli chcesz najpierw pozwolić im zadać cios, możesz, ale zwykle lepiej jest podać początkowe pomysły i pozwolić im je ulepszyć. Nie potrzebujesz do tego kodu funkcjonalnego. Zrzuty ekranu opracowywanych interfejsów użytkownika, reprezentacje HTML układów za pomocą statycznego tekstu wypełniającego, a nawet rysunki (jeśli masz przyzwoitego artystę na personelu) mogą być wykorzystane do wstępnych dyskusji na temat interfejsu użytkownika

Po przejściu kilku poprawek i wszyscy zgadzają się z tym, co zostało przedstawione, uzyskaj pisemną zgodę klienta! Bez względu na to, jak bardzo się opierają, ten krok ma kluczowe znaczenie. Być może będziesz musiał ich uspokoić, że podpisanie się pod wymaganiami nie oznacza, że ​​nie mogą oni wnieść dalszych wkładów w projekt (w zależności od charakteru relacji z klientem), w którym to przypadku powinieneś opisać, w jaki sposób zmiany wymagań zostaną obsłużone (np. podlegają przeglądowi i zatwierdzeniu, zostaną przeniesione do kolejnej wersji, wycenione osobno jako rozszerzenie itp.).

Powiedziałbym im, że rozwiniesz funkcję programu według funkcji. Aż do następnego spotkania powiedz, że za 1-2 tygodnie będziesz pracować X liczby funkcji. Może to być 1, 2, 3 lub więcej.

Załóżmy, że zaczniesz od opracowania najważniejszej funkcji. Musisz zacząć od podstawowych funkcji. Powiedzmy, że robisz bankomat (dla argumentu). Powiedz im, ok, pierwszą (lub następną) na liście najważniejszych funkcji jest proszenie użytkownika o datę urodzenia jako potwierdzenie przy dokonywaniu dużej wypłaty (zastępując fonctionnality w projekcie, o którym wiesz, że nie jest jedną z głównych funkcji, która: zostanie zaimplementowany następnie).

To naiwne stwierdzenie powinno wywołać reakcję klienta. Kiedy zapyta ich, co by zrobili dalej? Jaka jest najważniejsza funkcja, która nie została jeszcze wykonana w projekcie i która jest lepsza niż ta, o której wspomniałeś.

Korzystając z poprzedniego przykładu, klient może powiedzieć ci, że sprawdza poprawność karty użytkownika, dokonuje wpłat itp. Następnie poproś, aby ją zdefiniował. Nie bój się zadawać wielu pytań, nawet naiwnych w razie potrzeby.

Po omówieniu tego z klientem powinieneś mieć pewne wymagania dotyczące tego jednego elementu funkcjonalności. Można zdefiniować więcej niż jeden element fonctionality, ale utrzymałbym liczbę bardzo niską.

Za 1-2 tygodnie spotkaj się ponownie z klientem, aby przedstawić mu, co zrobiłeś, i uzyskać od niego informacje. Przedstaw to klientowi i uzyskaj jego wkład, jeśli coś trzeba zmienić lub dodać.

Następnie powtórz poprzednie ćwiczenie dla następnej grupy funkcji. Kontynuuj ten proces w sposób iteracyjny do końca projektu, upewniając się, że pozostajesz w kontakcie z klientem i spotykasz się w regularnych odstępach czasu, aby pokazać swoją pracę i zaplanować, co będzie dalej (zawsze z małymi kawałkami).

Mówisz o rozmowach inżynieryjnych i według mnie to nie obchodzi; nie chcą też nic robić (zwłaszcza na piśmie) i tak naprawdę nie chcą wykonywać żadnej pracy, choć nie dotyczy to w szczególności firm - nikt nie chce wykonywać pracy w domenie nie wiem i nie chcę wiedzieć. To twoja praca (ich zdaniem).

To, co robię, to: rozmawiaj z nimi o tym, czego chcą, w swoim języku domeny. Nie będą w stanie lub nie będą chcieli być precyzyjni w sposób, jakiego oczekujesz (przypadki użycia, projektowanie na podstawie umowy itp.), Ale możesz być precyzyjny w tłumaczeniu ich niejasnej i przewiewnej listy dezyderat na rzeczywisty projekt, i w konsekwencji dokument projektowy. Jeśli zaplanują ci czas na zrobienie tego formalnie, tym lepiej. Jeśli nie, utwórz improwizowany, nieformalny, na którym możesz iterować.

Wiem, że to nie jest super szczęśliwa odpowiedź, ale odkryłem, że życie jest łatwiejsze, kiedy przestałem próbować nakłonić klientów (lub kogokolwiek, naprawdę), aby wkroczyli do mojego wszechświata i mówili moim językiem. Mimo że ciągle powtarzam te same pytania, gdy uzgadniam z domeną i wymaganiami (które klient często nie rozumie), sprzeczne z intuicją jest to, że dyskusje nie są frustrujące. W rzeczywistości relacje z klientami stają się silniejsze, jak sądzę, ponieważ ludzie lubią rozmawiać o tym, co wiedzą, a ty rozumiesz ich POV bardziej okrągłe, niż gdybyś pozostawił bardziej rygorystyczne podejście.

Bez menedżera, który zna się na programowaniu, nigdy nie miałem w tym odrobiny sukcesu. Raczej jedynym podejściem, które znalazłem, które działa, jest obserwowanie, co się właściwie dzieje.

Wydaje mi się, że programiści mają lepszą możliwość wyobrażenia sobie, jak będzie wyglądał program przed jego zbudowaniem. Prototypowanie papieru może być skuteczną techniką do pokonania tego. Papierowe prototypy są stosunkowo „tanie” w budowie. Przeprowadzając klientów przez prosty papierowy prototyp, demonstrujesz potrzebę myślenia „w skoncentrowany sposób niezbędny do spełnienia prawdziwych wymagań”. I daje konkretny sposób na skupienie się: próbowanie użycia aplikacji, która jest w twojej głowie!

Ponadto możesz bardzo szybko iterować od najlepszego odgadnięcia, co klient chce do aplikacji, której naprawdę chce, ale ma trudności z przesyłaniem. Łatwiej jest spojrzeć na prototyp i zdecydować, dlaczego nie pasuje on do idealnej aplikacji w twojej głowie, niż wymienić wszystkie wymagania tej aplikacji.

Pracowałem na stronie internetowej, na której inni partnerzy byli bardziej zorientowani na biznes. Pytałem o konkretne wymagania na wiele różnych sposobów. Odpowiedzieli w zasadzie: „Jesteś facetem od komputera, oczekujemy, że to rozwiążesz. Wolimy robić rzeczy biznesowe”. Nie zajmowali się szczegółowymi szczegółami ... aż do wydania pierwszej wersji! Byli o wiele bardziej entuzjastycznie nastawieni do wymagań po wydaniu, udzielając wszelkiego rodzaju informacji zwrotnych, które pozwoliłyby mi zaoszczędzić sporo czasu , gdy początkowo o to poprosiłem.

Uznałem więc, że kluczem jest iteracja: zbuduj minimalną możliwą do wykonania wersję i ulepsz ją w oparciu o opinie. Jeśli wymagania są zbyt niejasne i ogólne, podejmuj decyzje na podstawie „Jaka jest najprostsza i najszybsza implementacja?” (z wyjątkiem podstawowego projektowania / architektury systemu). Nie waż się zbytnio na założeniach opartych na tym, co uważasz za „właściwe”. Skończy się to marnowaniem czasu, ponieważ istnieje duże prawdopodobieństwo, że twój proces myślowy różni się od twoich klientów.

Na przykład: klient prosi o przesłanie obrazu; nie opracuje żadnych bardziej szczegółowych wymagań. Zbuduj go tak naiwnie, jak to możliwe. Nawet jeśli uważasz, że tego właśnie będzie chciał klient, nie dodawaj funkcji automatycznego przycinania, zmiany rozmiaru i przewijania. Pozwól klientowi zobaczyć minimalną wykonalną wersję (którą możesz opracować znacznie szybciej niż nie naiwną wersję), a wymagania zaczną pojawiać się jako „To jest nie tak z bieżącą wersją”. Zanotuj każde z tych nowych wymagań jako „błędy”. Możesz ustalić, które z nich są najłatwiejsze / najbardziej korzystne.

Właściwie przydarzyło mi się: prośba o formularz rejestracji ze specjalnym kodem zaproszenia. Pomysł polegał na stworzeniu procesu rejestracji wirusów, w którym każdy nowy użytkownik otrzymał kilka zaproszeń. Spędziłem dużo czasu, upewniając się, że kody są unikalne i mogą być użyte tylko raz. Włożyłem również wiele wysiłku w uczynienie tego procesu tak bezproblemowym, jak to możliwe, poprzez włączenie opcjonalnych pól imienia i nazwiska. Na koniec partnerzy poprosili o te zmiany: imię i nazwisko są obowiązkowe, „kod” rejestracyjny jest ważny, jeśli cokolwiek w ogóle zostało wprowadzone w pole ... westchnienie ~