Czy twórca oprogramowania jest odpowiedzialny za zrozumienie, co klient miał na myśli?

Rodzaj pytania typu „tak / nie” i dlaczego?

Czy to deweloper oprogramowania jest odpowiedzialny za zrozumienie, co klient rozumie przez swoją prośbę, czy też to klient jest odpowiedzialny za prawidłowe wyjaśnienie swojej prośby twórcy oprogramowania?

Sytuacja w pracy polega obecnie na tym, że „klient już nas wyjaśnił, czego chce. Twoim obowiązkiem jest zrozumieć prośbę, a nie zadawać więcej pytań”.

Chociaż angielski nie jest moim mocnym zestawem, wszystkie prośby są napisane w niejasnym języku angielskim ze źle umieszczonymi słowami i trudnymi do zrozumienia zdaniami, niektóre wnioski zakładają wcześniejsze zrozumienie systemu z mojej strony.

Jestem trzecim lub czwartym programistą systemu (ostatni programiści zrezygnowali z pracy) i może to być powód, dla którego klient oczekuje pewnej wiedzy po stronie programistów.

Sam system jest dość niechlujny zarówno w interfejsie użytkownika, jak i na poziomie kodu źródłowego. Dla mnie wygląda to na kodowanie małpy - kod i mam nadzieję, że poprawnie otrzymałeś żądanie, ale tak naprawdę go nie rozumiesz.

Właściwie to myślę o odejściu z pracy, ale jeszcze tego nie zrobiłem, biorąc pod uwagę, że nie jestem pewien, kto ma rację, a kto nie.

Jeśli Twoim zadaniem jest zrozumieć, Twoim zadaniem jest zadawanie pytań, dopóki tego nie zrobisz

Osoba, o którą pytasz, może być osobą niebędącą klientem (często rozmawiałem z pośrednikiem, który był w kontakcie z klientem), więc osoby, które zabraniają ci rozmowy z klientem, powinny same odpowiedzieć na pytania lub skierować Cię na ktoś, kto może.

Ale w końcu musi być jakiś rodzaj komunikacji. Jeśli odmówią (a dostarczenie pewnych dokumentów, których nie rozumiesz, skutecznie odmawia komunikacji), powinieneś zrobić tak, jak to zrobili twoi poprzednicy: szybko uciekać.

Kiedy twoi klienci i przełożeni zostawiają cię z brudnym papierowym śladem, jedyne, co możesz zrobić, to zebrać jak najwięcej rozsądku z tego, co masz i zacząć pisać scenariusze zwykłym angielskim, próbując uporządkować posiadaną wiedzę na temat tego, w jaki sposób system ma się zachowywać.

Scenariusze podane / Kiedy / To umożliwiają szczegółowe zapoznanie się z tym, co musi się wydarzyć, a ponieważ są napisane prostym językiem angielskim i mają uporządkowaną strukturę, możesz ich użyć do komunikacji z przełożonym i klientem: „Słuchaj, Dotarłem do tego punktu i nie mam pojęcia, co system ma tutaj zrobić ”.

Jeśli po prostu unikniesz, gdy poprosisz o dodatkowe wyjaśnienia, nawet jeśli zainwestowałeś wysiłek w udokumentowanie wszystkiego, co robisz i czego nie rozumiesz, to poprzedni programiści ponieśli porażkę nie dlatego, że nie wiedzieli, jak przekazać specyfikacje, ale ponieważ nie da się tego zrobić.

Moim zdaniem oba (klienta i dewelopera) muszą uzyskać taką samą zrozumienie problemu i jego rozwiązania.

Jeśli nie rozumiesz żądania, nie możesz utworzyć rozwiązania.

Musisz więc przeczytać specyfikację. Jeśli specyfikacja nie jest wystarczająco jasna (lub nie ma specyfikacji na piśmie), powinien być ktoś, kto może udzielić odpowiedzi.

Pracuję w zespołach, które mają jedną osobę, która może odpowiedzieć na pytania biznesowe. Ten właściciel firmy jest członkiem firmy deweloperskiej, dla której pracuję, która zna firmę klienta lub członkiem zespołu klientów.

Wydaje się, że w twojej konkretnej lokalizacji kierownik projektu obawia się, że klient będzie zirytowany, jeśli zostanie zadany kilka razy te same pytania (konieczne ze względu na obrót programistów) i że będzie to źle wpływać na niego i jego firmę.

Oczywiście, jeśli nie zadajesz tych pytań, ukończenie / modyfikacja systemu zajmie ci dużo więcej czasu, a wynik może nie być tym, czego oczekiwał klient, co spowoduje więcej opóźnień, a także źle wpłynie na kierownika projektu i jego kierownika firma, przynajmniej w oczach klienta.

Istnieje kilka powodów, dla których kierownik projektu może nie pozwalać zadawać pytań:

1. Tak naprawdę nie rozumie negatywnych konsekwencji lub zaprzecza im.
2. Jest świadomy alternatyw, ale wie, że klient jest bardziej skłonny zaakceptować opóźnienia i słabą jakość niż irytujące pytania.
3. Gra w gry polityczne: być może wie, że wkrótce odchodzi z projektu i do tego czasu chce ukrywać problemy, albo planuje obwinić cię za problemy spowodowane brakiem komunikacji.

Powód 2 IMO jest mało prawdopodobny. Aby wyeliminować przyczynę 1, spróbuj wyjaśnić mu alternatywy i poproś go o dokonanie wyraźnego wyboru między nimi - zasugeruj klientowi wyjaśnienie problemu, aby zmniejszyć irytację. Aby wyeliminować przyczynę 3, zrób to na piśmie, abyś mógł wcześnie udowodnić potencjalne problemy i próbował je naprawić. Ale szczerze mówiąc, jeśli podejrzewasz, że jest to konieczne, prawdopodobnie powinieneś się tam jak najszybciej wydostać.

Myślę, że to na usługodawcy zawsze spoczywa obowiązek upewnienia się, że zrozumieli intencje klientów.

Jako eksperci w naszej dziedzinie nie tylko wykonujemy briefy, ale także pomagamy naszym klientom przeprowadzać proces korzystania z naszych usług, a to polegało na edukowaniu ich na temat oferowanych przez nas możliwości i tego, co robimy teraz.

Wierzę, że podejście zorientowane na klienta jest absolutnie sposobem na zrobienie czegoś, jest to wypróbowany i przetestowany model biznesowy.

Klient i programiści muszą współpracować, aby lepiej zrozumieć system.

Firma produkująca oprogramowanie musi dojść do porozumienia z klientem co do wymagań każdej ze stron, co jest podstawowym aspektem umowy. Jeśli nie ma „spotkania umysłów”, to w bardzo realnym sensie nie ma kontraktu.

Zakładając, że jesteś kompetentnym programistą, jeśli specyfikacja nie jest jasna, to po prostu powiedzenie „To twoja odpowiedzialność za zrozumienie żądania, nie zadawanie więcej pytań” jest raczej głupie.

Jest to oparte na nowych informacjach zawartych w komentarzach do pierwotnego pytania.

Oświadczenie, że

klient już nam wyjaśnił, czego chce. Twoim obowiązkiem jest zrozumieć prośbę, a nie zadawać więcej pytań

pochodzi od lidera projektu; podanym uzasadnieniem jest

że ponieważ nie jestem pierwszym programistą w systemie, nie powinniśmy zawracać sobie głowy przedstawicielem klienta większą liczbą pytań, ale postaraj się iw razie potrzeby poświęć dodatkowy czas na interpretację pytania

To, czego konkretnie powiedziano ci, to przeszkadzanie klientowi pytaniami .

Pytanie o „poświęcenie dodatkowego czasu na interpretację pytania” niekoniecznie jest nierozsądne. Powinieneś podjąć rozsądny wysiłek, a może nawet nieco nieuzasadniony wysiłek, aby dowiedzieć się, jakie wymagania są oparte na tym, co faktycznie powiedział klient. Jeśli nic więcej, jest to cenna umiejętność.

Jeśli to się nie powiedzie (i z różnych powodów wygląda na to, że już ma), poproś o pomoc lidera projektu. Staraj się być jak najbardziej szczegółowy w swoich pytaniach, pokazując, że odrobiłeś lekcje. Na przykład zamiast

czego chcą ci ludzie ??? "

zapytaj coś w stylu

W paragrafie 17 dokumentu wymagań jest napisane, że foobar musi zwijać frozzle; do której z tych trzech dysz się odnosi? ”

Lub, jeśli wymagania są tak źle napisane, że nie można ich rozszyfrować, powiedz mu o tym.

Powiedziałbym, że ostatecznie odpowiedzialność lidera projektu polega na upewnieniu się, że wymagania są właściwie rozumiane (z pewnością leży to w jego najlepszym interesie, aby projekt się powiódł). Ale jako członek zespołu ponosisz część tej odpowiedzialności. Jeśli wykażesz, że sam poczyniłeś wysiłek, a lider projektu odmawia ci pomocy, oznacza to, że ponosi on całkowitą odpowiedzialność. Jeśli dojdzie do tego punktu, upewnij się, że on to wie.

W idealnym świecie powinna być gdzieś lista funkcji i specyfikacji, coś napisanego na umowie łączącej Twoją firmę z klientem.

Aby odpowiedzieć na twoje pytanie, programista powinien naprawdę zrozumieć, czego chce klient, i mieć pisemny dokument, aby obie strony zgodziły się na tę samą wizję.

Oczywiście nie jest to idealny świat i często nie ma specyfikacji, a jeśli nie masz żadnej specyfikacji na piśmie, to będzie ciężko. Czy w Twojej firmie jest ktoś, kto pracuje jako przedstawiciel relacji z klientem, który mógłby pomóc Ci zrozumieć, czego chce klient?

Jeśli nie, na twoim stanowisku postaram się uzyskać informacje od poprzednich programistów, zakładając, że oczywiście rozumieli to zadanie.

Myślę, że faktyczna rola określająca, kto zajmuje się zrozumieniem wymagań, różni się w zależności od niektórych z tych zmiennych

• Wielkość drużyny
• Standardy firmy
• Sposób, w jaki szef jest przyzwyczajony do pracy
• Różna wiedza specjalistyczna członków zespołu

Więc jeśli jesteś tylko drużyną jednoosobową, powinieneś dołożyć wszelkich starań, aby dotrzeć do sedna próśb. jeśli jesteś nowy w trwającym projekcie, powinieneś spróbować ponownie omówić prośby z klientem.

EDYCJA: Co najważniejsze, klient może nie wiedzieć, że złożył tak złe wymagania, a proces gromadzenia wymagań jest często długi i żmudny, ale jest to ważny proces, a jeśli spadnie na ciebie, ponieważ nikt inny tego nie robi, powinieneś zrób to z nimi.