Mówiąc o programistach i właścicielach produktów, wydaje mi się, że nie masz żadnej pośredniej osoby odpowiedzialnej za funkcje w swojej organizacji.
Cóż, w mojej organizacji jestem tą osobą. Jestem inżynierem wymagań, tym, który nauczył się robić dobre specyfikacje i wybierać funkcje, które dają wysokiej jakości oprogramowanie z przyjaznym dla użytkownika projektem interakcji. (W innych organizacjach to osoba z UX dostaje tę samą pracę, możesz być bardziej zaznajomiony z tym terminem).
I mogę powiedzieć: uzyskanie dobrej specyfikacji jest trudne. Oczywiście programiści nie lubią tego robić. Jest to dla nich ciężar - mają oni zbudować oprogramowanie, a nie myśleć o grze sił wśród interesariuszy i modelach mentalnych leniwych użytkowników. Ale wiesz co? Jest to również ciężar dla właścicieli produktów. Nie wiedzą lepiej, jakie funkcje powinny zawierać ich oprogramowanie niż deweloperzy lub użytkownicy. Tworzenie realnej specyfikacji jest wyuczoną umiejętnością, a jeśli nigdy się jej nie nauczyłeś, nie możesz być w tym dobry. Pewnie, jest wielu programistów i właścicieli produktów, którzy mogą to zrobić, ponieważ musieli to zrobić w poprzednich projektach. Ale przeciętny właściciel produktu lub programista ma z tym problem, ponieważ oczywiście nie jest to ich zadaniem. Nie każdy, kto umie prowadzić samochód, może zaprojektować samochód; podobnie,
Czy potrafisz opracować oprogramowanie bez inżyniera wymagań? Oczywiście że możesz. Ale umieszczenie całej wagi specyfikacji na barkach właściciela produktu jest niesprawiedliwe i nie jest dobre dla wyniku projektu. Zwłaszcza, że staje przed niezwykle trudnym zadaniem, bardzo pomocne jest uzyskanie wkładu i wsparcia od innych. Jeśli jesteś w takiej sytuacji, nie patrz na swojego biednego właściciela produktu i powiedz „powiedz mi, co mam dla ciebie zrobić, a ja cię stworzę”, on naprawdę nie wie, czego potrzebuje. Ale dyskusja z tobą pomoże mu wyartykułować swoje myśli i zbadać jego pomysły.
Gdy w strukturze projektu nie ma inżyniera wymagań, pojawia się inny problem: nie ma moderatora. Wszyscy programiści są po stronie technicznej, wszyscy właściciele produktów po stronie biznesowej. Kiedy zderzają się obie kultury, mogą powstać konflikty, a każda ze stron ocenia drugą głupią i nierozsądną (ponieważ używa własnego systemu wartości do oceny). Porozmawiaj więc z właścicielem produktu na temat możliwych funkcji, ale bądź uprzejmy i cierpliwy, nawet jeśli uważasz, że na to nie zasługuje; sukces projektu zależy od tego, jak dobrze się dogadacie, a czasem podjęcie decyzji suboptymalnej jest lepsze niż niepodjęcie żadnej decyzji z powodu konfliktu. Pomocne może być ustanowienie hierarchii i podanie jednemu z was ostatniego słowa, ponieważ zapobiega to zakleszczonym konfliktom. Jeśli dostanie ostatnie słowo, odłóż je na później, nawet jeśli uważasz, że to niesprawiedliwe.
O części „pasywnej”: jeśli nie masz pomysłów, nie próbuj wymyślić czegoś tylko po to, by pokazać aktywność. Jeśli właściciel produktu jest już niepewny i nie zna dobrych kryteriów oceny swoich lub twoich pomysłów, dziwne pomysły „po prostu coś mieć” jeszcze bardziej utrudnią i tak trudną sytuację. Wymyślanie dobrych pomysłów na funkcje nie jest magią, ale wymaga wiedzy. Jeśli nie nauczyłeś się tego z podręczników, prawdopodobnie będziesz potrzebować kilku lat doświadczenia programisty, szczególnie w projektach, w których jesteś narażony na użytkowników lub dane użytkowe generowane przez użytkowników (analizy, pomiary satysfakcji), zanim twój mózg sam uporządkuje wzorce dla siebie i zaczynasz zauważać: istnieje problem, który możemy rozwiązać. Wygląda na to, że użytkownikom brakuje czegoś na tej stronie, co to może być? Będziesz miał dobre pomysły do podzielenia się.
Wniosek 1: W projektach bez inżyniera wymagań dobrze jest sugestie, gdy je masz. Rób to z wyczuciem i taktem - konieczne jest unikanie konfliktu, nawet jeśli oznacza to, że twój dobry pomysł zostanie ugryziony w zarodku.
A jeśli pracujesz w zespole z inżynierem wymagań?
Uwielbiam słyszeć pomysły od wszystkich! Tak, czasami pomysły deweloperów są okropne (kiedy chcą, aby interfejs użytkownika działał zgodnie z logiką programowania). Pomysły właścicieli produktów są również często okropne (gdy chcą słońca i księżyca w zawrotnym budżecie - och, a użytkownik powinien wprowadzić strony danych osobowych w najwyższej jakości danych, nie otrzymując nic w zamian). Ale moim zadaniem jest opracować specyfikację, która jest dobra dla wszystkich członków zespołu. I nawet jeśli twój pomysł nigdy nie zadziała, usłyszenie go uświadamia mi, że masz obawy. Być może wybrałeś niewłaściwe rozwiązanie do zasugerowania, ale to nie oznacza, że twoje obawy są mniej aktualne. Jeśli to zauważyłeś, prawdopodobnie należy się nim zająć (lub muszę podać powód, dla którego nie jest to zagrożenie). Jeśli masz inżyniera wymagań odpowiedzialnego za specyfikację, nie wahaj się iść do nich z sugestiami. Jeśli cię nie wysłuchają, robią coś złego (zauważ, że „rozważ” nie oznacza „zaakceptuj”).
Inżynier wymagań musi spojrzeć na projekt z punktu widzenia każdego interesariusza osobno (a czasem jednocześnie). Jesteśmy tylko ludźmi i często zawodzimy. Jeśli jesteś tam, aby dostarczyć swój prawdziwy punkt widzenia, zamiast punktu widzenia, który naszym zdaniem masz, to twój wkład jest bardzo cenny.
Możesz być bardziej wolny w swoim zachowaniu tutaj. Moim zadaniem jest wykonywać taniec wrażliwości. Nie bądź otwarcie agresywny, to utrudnia mi pracę, ale potrzebujesz mniej samokontroli i świadomości kulturowej / komunikacyjnej, ponieważ mogę wziąć luz. Nie unosisz się również w sytuacji, gdy istnieją dwa sprzeczne pomysły i nikt nie może ocenić, co jest lepsze. Powinienem to wiedzieć, a jeśli to się nie uda, to moja głowa w pętli.
Wniosek 2: Jeśli w zespole jest inżynier wymagań, przejdź do niego z sugestiami dotyczącymi funkcji produktu. Tym razem nie potrzebujesz aksamitnych rękawiczek.
I na koniec, co jeśli nie ma inżyniera wymagań, właściciel produktu jest przytłoczony i walczy o pomysły, szef patrzy na ciebie, a ty nie masz pomysłów do zaoferowania?
Masz kilka opcji. Jak już wspomniałeś, jednym z nich jest wyjście. Nie wszystkie organizacje działają w ten sposób, a jeśli to środowisko nie jest dla Ciebie odpowiednie, znajdź lepsze. W dłuższej perspektywie będzie to dla ciebie dobre.
Możesz także poczekać i sprawdzić, czy coś się zmieni. Kolejny projekt może mieć bardziej doświadczonego właściciela produktu (lub takiego z większym przywództwem). Ale nie możesz utknąć na zawsze.
Trzecią opcją jest samodzielne nauczenie się inżynierii wymagań. Jest to umiejętność bardzo poszukiwana w dzisiejszych czasach. Nawet jeśli nigdy nie planujesz zajmować stanowisk, w których jesteś pełnoetatowym inżynierem wymagań, posiadanie tej umiejętności zwiększa twoją wartość jako programisty, ponieważ pozwala lepiej zrozumieć innych członków zespołu (i użytkowników) oraz sprawia, że proces rozwoju przebiega sprawniej. I nie musisz wchodzić w całą jego głębię. Podręcznik na poziomie podstawowym, który wyjaśnia zadania, przepływy pracy, modele mentalne i modele danych zorientowane na użytkownika, już pozwala dostrzec wiele możliwości ulepszeń w oprogramowaniu zaprojektowanym przez zespół biznesmenów i programistów. Don' sięgnij po najgrubsze książki przeznaczone jako odniesienie dla nauczycieli akademickich (jak ostatnie tłumaczenie Pohla na angielski) - są raczej listą wszystkich możliwych metod dla każdego małego kroku, bez wyjaśnienia, jak to zrobić. Wybierz coś zorientowanego na praktykę.
Jeśli spróbujesz i okaże się, że nie interesujesz się tym obszarem, nadal będzie dobrze. Nie zmuszaj się do robienia czegoś, czego nie lubisz. Ale prawdopodobnie powinieneś szukać pracy w organizacji o innej strukturze zespołu.
Wniosek 3: Zamiast czekać przez lata na intuicyjne zrozumienie, przeczytaj książkę lub dwie, a będziesz już miał dobre pomysły na dostarczenie