Czy programista powinien „pomyśleć” o kliencie?

Dotarłem do punktu, w którym nienawidzę zbierania wymagań. Klienci są zbyt niejasni dla własnego dobra. W zwinnym środowisku, w którym możemy pokazać klientowi pracę do końca, nie jest tak źle, ponieważ możemy wprowadzać niewielkie regularne poprawki / aktualizacje funkcjonalności.

W środowisku typu „wodospad” (najpierw wymagania, a potem prawie kompletny produkt) może być brzydko. Takie środowisko doprowadziło mnie do ciągłego kwestionowania wymagań. Klient EG chce „automatycznie przekonwertować dane wejściowe na liczbę 1” (odnosząc się do ilości w zamówieniu). Ale nie myślą o tym, że „dane wejściowe” mogą być prostym typem. Znak „x” w polu tekstowym może być „woops”, nie chcę 1 z tych „past do zębów”. Ale jest tak wiele w powietrzu z wymaganiami, że mogłem wytrzymać i korygować godzinami, niszcząc to, czego chcą. To po prostu nie jest zdrowe.

Pracując dla korporacji, mogłem spróbować dopasować kulturę do zwinnego modelu, który by nam pomógł (nie jest to drobna praca, wyższa niż moja płaca). Lub zmieść brzydkie detale pod dywan i miej nadzieję na najlepsze. Może mój klient próbuje zbliżyć się do kodu?

Jak radzić sobie z problemem „myślenia o kliencie” bez wkurzania go zbyt dużą liczbą pytań?

W większości przypadków klient nie wie, co jeszcze można zrobić. Nigdy nie musieli opisywać tego, czego potrzebują w sposób, który sprawia, że ​​jest to dla nas jednoznaczne. Ich zdaniem jest jasne. Nawet fakt, że zastanawiają się nad konwersją danych wejściowych użytkownika na numer 1, wykracza poza sposób, w jaki są przyzwyczajeni do myślenia.

Tak naprawdę powinno być. Gdyby naprawdę wiedzieli, jak dokładnie opisać to, czego chcieli, nie potrzebowaliby od nas tego dla nich. W rezultacie naszym obowiązkiem jest pomóc im w tym procesie. Proces ten wymaga podjęcia decyzji, dlatego potrzebują również naszych zaleceń, aby ułatwić proces decyzyjny.

Niech więc klient będzie niejasny i mówi na wysokim poziomie. Znają swoją działalność i w tym są dobrzy (mam nadzieję, że nie będą w stanie zapłacić rachunków ...). Weź to, o czym rozmawiali i pomyśl o tym przez chwilę. W końcu dostajesz kilka świetnych pomysłów, aby uzyskać to, czego chcą i potrzebują, jednocześnie upewniając się, że to, czego potrzebujesz, jest sprawdzalne i spójne.

Bardzo polecam pracę w kawałkach. Kiedy spotkasz się z klientem, masz zestaw wymagań, które są ze sobą powiązane, a następnie wyjaśnij, w jaki sposób zamierzasz robić to, czego chcą. Wyjaśnij także, dlaczego dokonałeś wyborów. Klient może następnie sprawdzić, co dostarczyłeś i dokładnie go dostroić. Jeśli otrzymasz odpowiedź typu: „Nigdy o tym nie myślałem, ale to naprawdę by pomogło”, wiesz, że masz wyczucie, jak myśli klient. UWAGA: że nie jest to zapalenie Featuritis, to wybór odpowiednich funkcji, które najlepiej pasują do problemu biznesowego klienta.

Jeśli masz coś, co może wyglądać na sprzeczne z tym, co wyraźnie powiedział ci klient, czas wyjaśnić, dlaczego. Będziesz musiał wyjaśnić niektóre kwestie, o których klient nigdy nie pomyślał, oraz o tym, w jaki sposób alternatywa wciąż zapewnia im to, czego chcą / potrzebują, ale także pozwala uniknąć tych potencjalnych problemów. Może pojawić się niewielka reakcja, ale także buduje zaufanie klientów, ponieważ zdają sobie sprawę, że próbujesz dać im produkt, z którego naprawdę mogą skorzystać. Jeśli odpychają, to zmusza ich do wyjaśnienia, dlaczego chcieli czegoś w określony sposób. Pomoże Ci to lepiej zrozumieć klienta i odpowiednio dostosować wymagania.

Najszybszym sposobem na zmęczenie klienta jest zadawanie kolejnych małych pytań. Chcesz zaplanować i zaplanować serię spotkań, aby sprawdzić swoje podejście. Tak długo, jak posiadasz wymagania techniczne (to, czego używa Twój zespół do budowy produktu), a twój klient jest właścicielem wymagań biznesowych i możesz je ze sobą powiązać, masz sposób na uzupełnienie luki.

Jeśli „wkurzasz ich” na zbyt wiele pytań, zdobądź lepszego klienta.

Klienci nie wiedzą, czego chcą. Nie zawsze rozpoznają swoje rozwiązanie, gdy je zobaczą. To jest problem i to jest praca, którą rozwiązujesz: przełożenie ich wymagań na coś, co można dostarczyć jako pakiet oprogramowania.

Aby to zrobić, musisz dowiedzieć się, co robisz. Nie powinieneś pytać „co powinno się stać, gdy wstawią liczbę w polu tekstowym”, powinieneś zapytać „dlaczego ten numer jest ważny? Do czego służy?” Niech nauczy Cię, jak wykonują swoją pracę. I nie słuchaj tego, co mówią, ponieważ nie wiedzą, czego chcą, ale obserwuj, co robią i dokąd zmierzają ich oczy .

Przeczytaj to, aby uzyskać więcej informacji: http://www.joelonsoftware.com/articles/fog0000000356.html

Zakładając, że jesteś pracownikiem jakiejś korporacji, brzmi to tak, jakbyś potrzebował dobrego analityka biznesowego, który pomógłby w mediacji między tymi danymi a klientem. Domyślam się, że nie masz wystarczającego wpływu, aby tak się stało, więc moją następną najlepszą radą byłoby dowiedzieć się więcej o domenie, w której pracują Twoi klienci. Dzięki zrozumieniu biznesu i procesów, z którymi pracują, możesz „ Będę miał lepsze pojęcie o tym, co naprawdę chcą zrobić, pomimo luźnego i prawdopodobnie niewłaściwego sposobu, w jaki to opisują. To pozwala przeanalizować to, o co prosili, i możesz później wrócić na osobne spotkanie z interpretacją tego, czego chcą, i możliwą sugestią, by dać im to, czego naprawdę chcą. Jeśli konsekwentnie pracujesz z tymi samymi klientami, „

Jeśli wydaje się to bardzo trudne, bolesne, wyjątkowo nieprzyjemne lub nierealne, moją ostatnią radą byłoby zacząć szukać nowej pracy gdzieś, gdzie mają analityków biznesowych, ponieważ nie będzie ci łatwiej bez wkładania wysiłku.

Jeśli zbierasz wymagania, Twoim zadaniem jest zadać te pytania.

Tak, klient może się zdenerwować, ale w takim przypadku musisz wyjaśnić, dlaczego zadajesz „wszystkie te pytania”. Zanim napiszesz kod, który zautomatyzuje ten biznes, musisz zrozumieć ich działalność. Klinkier byłby taki, że gdybyś tego nie zrobił, wydaliby dużo pieniędzy na opracowanie systemu, który tak naprawdę nie robi tego, czego chcą.

Efektem ubocznym tego jest to, że powinieneś pomóc klientowi doprecyzować jego wymagania.

Dotyczy to niezależnie od tego, czy robisz duży projekt z góry, czy zręcznie.

Niestety, Twoim zadaniem jest myśleć o kliencie, jeśli nie może lub nie zrobi tego sam.

Mam oba możliwe wyniki:

• klient jest szczęśliwy, że tak naprawdę myślisz o tym, co ci mówi, czuje, że jest w dobrych rękach, lub

• klient jest zirytowany, ponieważ zmuszasz go do ponownego przemyślenia swoich wymagań. Ale wtedy ten typ klienta irytuje cię, prędzej czy później. Z pewnością będzie bardzo zirytowany, jeśli dowie się zbyt późno, że nie pomyślałeś o nim na początku. Powiedziałbym: unikaj tego typu klientów, jeśli to możliwe :-)

Rapid Application Development (RAD) rozwiązuje ten problem również.

Zacznij od „myślenia dla klienta”, tworząc bardzo szorstki, niefunkcjonalny interfejs użytkownika dla programu w oparciu o twoje najlepsze przypuszczenia, czego potrzebują. Następnie pokaż im to i pracuj iteracyjnie, aż zaspokoisz ich rzeczywiste potrzeby.

Nie chodzi o to, że nie wiedzą, czego chcą. Chodzi o to, że nie wiedzą, czego chcą, dopóki tego nie zobaczą, a czasem możesz określić, czego chcą, przez wykluczenie. To znaczy pokazując im coś, czego NIE chcą i zwracając uwagę na to, jak krytykują.

Głównym problemem związanym z BFUD (projekt Big Up Front) jest to, że izoluje dewelopera od winy, zmuszając klienta do zawarcia umowy, która wyraźnie opisuje, co otrzyma. I niestety dzieje się tak w momencie, gdy nikt z projektu nie ma pojęcia, co jest naprawdę potrzebne. Ostatecznie sprawia to, że klient akceptuje to, co zbudowałeś, ponieważ się podpisał, ale niechętnie.

Jeśli klient nie jest zadowolony z rezultatu, jest to tylko zwycięstwo Pyrrhic.

Klient ma za zadanie przekazać ci to, czego potrzebuje. Twoim zadaniem jest zrozumienie, czego potrzebują na tyle dobrze, aby móc zaprogramować to, czego potrzebują. Oczywistym pytaniem w kwestii zmiany wszystkich danych wejściowych na jedno byłoby pytanie „Dlaczego chcesz, aby zmieniła wszystkie dane wejściowe na 1?” Następnie klient może wyjaśnić uzasadnienie, abyś zrozumiał potrzebę, a następnie był w stanie podać niekoniecznie to, o co prosi, ale czego potrzebuje. Jeśli masz pewność, że wiesz, czego potrzebują, nie sądzę, że musisz koniecznie „poprawić” ich sposób myślenia. Użyją produktu i rzeczy „Och! To idealne”. Ale jeśli nie masz pewności, że wiesz, czego potrzebują, musisz wyjaśnić, co myślisz, i uzgodnić to z klientem. Niestety tam nie ma możliwości wykonania tej części procesu bez dużej komunikacji, która wymaga prawdziwego słuchania w obu częściach. Uważaj, aby nie zirytować się sytuacją i mówić rzeczy, które możesz lub nie chcesz naprawdę powiedzieć.

Szczerze mówiąc: chyba że jest to „duża funkcjonalność”, to osoba o największej wiedzy domenowej najlepiej zgaduje, co się stanie, i wdroży to. Zostanie dopracowany w testach akceptacyjnych - po to właśnie jest.