Jednym z największych wyzwań stojących przed zespołami zajmującymi się rozwojem produktów jest po prostu to, jak zdecydować, jaki produkt zbudować. W przypadku zespołów, które pracują w oparciu o specyfikację produktu, szczególnie w przypadku rozwoju sprzętu, inżynierowie zazwyczaj nie mogą rozpocząć pracy, dopóki specyfikacja nie zostanie ukończona i zatwierdzona. A biorąc pod uwagę, że większość linii czasowych rozwoju jest niewiarygodnie krótka, często nie ma wystarczająco dużo czasu, aby rozważyć alternatywne rozwiązania, gdy pojawią się nowe informacje.
Jeden ze sposobów patrzenia na to wyzwanie jest pokazany tutaj. Można sobie wyobrazić, że okrąg to każdy możliwy sposób, w jaki zespół może zbudować produkt. A ta malutka niebieska kropka to specyfikacja dla jednego konkretnego produktu. Ta specyfikacja produktu definiuje dokładnie, na którym produkcie programiści powinni się skupić i go zbudować.
W tym poście najpierw opiszę niektóre z powszechnych metod używanych do uzgodnienia specyfikacji produktu. Następnie zbadam problemy związane z tymi metodami oraz to, w jaki sposób mogą one prowadzić do budowania produktów na podstawie specyfikacji, która w rzeczywistości nie rozwiązuje problemów klienta.
Powinienem powiedzieć, że moja perspektywa pochodzi z 10 lat doświadczenia w pracy w branży półprzewodników analogowych i mixed-signal, najpierw jako inżynier aplikacji, a później jako osoba definiująca produkt. Obecnie jestem konsultantem w firmie Jama.
Najgorsze sposoby tworzenia specyfikacji produktu:
Zapytaj klienta, co chce, abyś zbudował
Jednym ze sposobów rozpoczęcia jest zapytanie klienta, czego potrzebuje. Można to zrobić, czekając na zapytanie ofertowe (RFQ) wystawione przez klienta lub mniej formalnie, poprzez spotkania i dyskusje. Zazwyczaj to, czego dowiesz się dzięki temu podejściu, to jakie rozwiązanie lub produkt wykorzystują obecnie i co chcieliby zmienić w najbliższej przyszłości. W pewnym sensie działasz jako wykonawca, a twój klient jest odpowiedzialny za wszystkie szczegóły specyfikacji.
Zważywszy, że ten scenariusz wzywa do iteracji na istniejącym produkcie, istnieje duże prawdopodobieństwo, że skończysz z bardzo konkretnym pomysłem, który zdecydowanie możesz wdrożyć.
Jednakże z tym podejściem wiąże się kilka problemów:
- To, co twój klient mówi ci o swojej strategii produktu, prawdopodobnie mówi również twojej konkurencji, a kluczowym celem projektu jest prawdopodobnie stworzenie czegoś tańszego niż istniejące rozwiązanie. Znajdziesz się w wojnie cenowej.
- Twój klient jest już nastawiony na pewien typ rozwiązania, bazując na tym, co kupił wcześniej, co utrudnia zasugerowanie czegoś, co może lepiej zaspokoić jego potrzeby.
- Harmonogram jest prawdopodobnie bardzo agresywny, pozostawiając niewiele okazji do zbudowania czegoś nowego lub pozwalając na prawdziwą innowację.
- Twój klient może nie być świadomy nowych technologii lub po prostu może nie wiedzieć, czego potrzebuje.
W tym przypadku polegasz na swoim kliencie, aby przetłumaczył swoje wewnętrzne wymagania na specyfikację dla ciebie, zamiast pisać wymagania dla produktu, który szerszy rynek potrzebuje i kupi.
Podczas rozwijania produktu twój zespół nieuchronnie będzie musiał dokonać kompromisów z różnych powodów. Jedynym sposobem, aby upewnić się, że dokonano najlepszego wyboru, jest przegląd zmian w specyfikacji produktu wynikowego z klientem. Jeśli tego nie zrobisz, ryzykujesz, że zbudujesz produkt, którego klient nie zaakceptuje. Ponieważ jednak zespół projektowy będzie znajdował się pod ogromną presją związaną z realizacją agresywnego harmonogramu, istnieje duże prawdopodobieństwo, że dokona kompromisów dotyczących produktu bez wszystkich najlepszych informacji. To jeszcze bardziej zwiększa ryzyko zbudowania niewłaściwego produktu.
Takie podejście działa w tym, że produkt jest dostarczany. Jeśli jesteś w biznesie dostarczania komponentów towarowych, to jest to w porządku. Jeśli szukasz unikalnego rozwiązania, które broni marży brutto, to nie jest to najlepsze podejście.
RELATED POST: How to Perform Better Impact Analysis on Upstream and Downstream Relationships
2. Have an Engineer Write the Entire Spec
Innym częstym scenariuszem jest ten, w którym inżynier lub inny członek zespołu zajmującego się obsługą klienta, wyobraża sobie rozwiązanie na podstawie rozmów, które przeprowadził z jednym lub kilkoma klientami. Zespół gromadzi się wokół tego pomysłu, a dzięki wewnętrznemu rozpędowi wymagania są szybko dokumentowane i wysiłki zespołu szybko przechodzą do pisania specyfikacji produktu i opracowywania rozwiązania.
Gdy rozwiązanie jest już kompletne i gotowe do wprowadzenia na rynek, niektóre zespoły walidują swój pomysł z klientami, ale ponieważ zespół prezentuje rozwiązanie, a nie bada potrzebę, dyskusja toczy się wokół szczegółów w specyfikacji produktu. Zespoły te nie będą miały okazji dowiedzieć się, czy rozwiązanie rozwiązuje problem.
Typowo, w tym scenariuszu, wymagania dotyczące produktu pochodzą prosto z głowy jednej osoby, a następnie są uchwycone w długim arkuszu specyfikacji, a reszta zespołu dokonuje transakcji przy użyciu udokumentowanej specyfikacji. Za każdym razem, gdy zespół napotyka na konflikt, w którym trzeba dokonać kompromisu, osoba, która była autorem wymagań, musi podjąć decyzję o prawidłowych kompromisach niezależnie, z niewielką lub żadną nową informacją. W dodatku, jeśli ta osoba nie zbadała ani nie zweryfikowała wymagań, to zespół zbuduje zły produkt.
Dlaczego te podejścia nie prowadzą do sukcesu
Wspólną cechą obu poprzednich podejść jest to, że koncentrują się one na jak najszybszym uzyskaniu specyfikacji gotowego produktu. Zespoły tak się spieszą, aby zacząć coś budować i dotrzymać terminu klienta, że nie upewniają się najpierw, że to coś jest tym właściwym czymś.
Dodatkowo, wiedza o wymaganiach istnieje tylko u jednej osoby w zespole. Ta osoba jest albo osobą kontaktującą się z klientem sponsorem, albo jest to osoba, która wpadła na pomysł produktu. W obu przypadkach, reszta zespołu nie ma żadnego kontekstu dla rozwiązania, dlaczego budują ten produkt, a zatem nie może dokonać zaleceń.
Wynikiem jest często produkty są zabijane później niż powinny mieć, po dużo czasu i pieniędzy zostało zmarnowanych, lub zespoły tworzą produkty, które są nieudane lub me-too produktów, które konkurują głównie na cenę. Żadna z tych rzeczy nie jest dobra dla biznesu.
RELATED POST: 8 Do’s and Don’ts for Writing Requirements
Najlepsze sposoby na tworzenie specyfikacji produktu:
Najlepszym sposobem na budowanie produktów, które klienci będą kupować, jest wyjście na zewnątrz i rozmowa z rynkiem docelowym na długo przed rozpoczęciem pisania specyfikacji. Po pierwsze, musisz wyartykułować swój problem statement.
A product problem statement jest kilka zdań lub akapitów, które opisują potrzebę rynku. Są one napisane z perspektywy osoby, która ma problem i – co jest krytyczne – nie mówią nic o tym, jak faktycznie rozwiązać ten problem. Celem tego etapu eksploracji jest przekazanie zrozumienia problemu i poczucia wartości związanego z jego rozwiązaniem.
Stwierdzenie problemu generalnie składa się z trzech części:
- Pierwszą z nich jest persona, czyli opis tego, kto ma problem. Pomocne jest opisanie persony bardzo szczegółowo osobno, a następnie odniesienie się do konkretnej persony w stwierdzeniu problemu, aby nie powtarzać tego samego opisu persony.
- Następnie jest opis problemu. Im więcej szczegółów, tym lepiej. Chcesz się upewnić, że potrzeba jest krystalicznie czysta. Należy również nadać problemowi nazwę. Ułatwia to zespołom odnoszenie się do niego w trakcie projektu.
- Na koniec napisz opis tego, jak często problem występuje. Jeśli problem występuje rzadko i ma mały wpływ, to jego rozwiązanie ma małą wartość. Jeśli problem występuje często i ma duży wpływ, wówczas wartość jego rozwiązania będzie wysoka.
Możesz zacząć od zapytania klientów, jakie mają problemy, które ich zdaniem możesz rozwiązać, ale musisz kopać głębiej, aby dotrzeć do naprawdę wartościowych stwierdzeń problemów lub złotych samorodków. Te złote samorodki zazwyczaj pochodzą z rozwijania głębokiego zrozumienia rynku i łączenia informacji z szerokiego zakresu źródeł.
Jeśli zrobisz to z powodzeniem, skończysz identyfikując problem, który możesz rozwiązać i za który klient zapłaci.
Podczas tego procesu uważaj, aby nie natknąć się na fałszywe pozytywy lub negatywy. Zbyt częste słuchanie ludzi wewnątrz firmy lub tylko niewielkiej liczby klientów może doprowadzić do fałszywego zatwierdzenia lub porzucenia problemu. Porozmawiaj z jak największą liczbą klientów i zbierz jak najwięcej danych.
Powróćmy do naszego diagramu wszystkich możliwych produktów, które możemy zbudować.
Tym razem dodaliśmy przecinające się linie, które reprezentują ograniczenia. Jeśli pomyślimy o stwierdzeniu problemu jako o liniach przecinających okrąg, to dobre stwierdzenie problemu oparte na zrozumieniu rynku ograniczy obszar w okręgu, który reprezentuje wszystkie dopuszczalne rozwiązania. Wszystko w tym obszarze rozwiązuje problem i byłoby akceptowalne dla klienta.
Zauważysz, że rozmiar tego obszaru jest znacznie większy niż poprzednich kręgów RFQ i pomysłów na produkt. Jest tak dlatego, że te stwierdzenia problemu i kontekst celowo związały rozwiązanie tak luźno, jak to tylko możliwe, aby umożliwić pojawienie się nowych pomysłów.
Pomysł polega na tym, aby dać zespołowi projektowemu maksymalną elastyczność w tworzeniu najbardziej innowacyjnego rozwiązania możliwego w ramach ograniczeń.
RELATED POST: Checklist: Wybór narzędzia do zarządzania wymaganiami
Jak dojść do ostatecznego opisu problemu?
Oto moje zalecenia:
- Zacznij od przydzielenia komuś w każdym projekcie odpowiedzialności za bycie głosem klienta.
- Następnie, zleć tej osobie identyfikację problemów rynkowych wyłącznie w oparciu o informacje zebrane z rynku.
- Zapewnij, że te problemy rynkowe są udokumentowane i udostępnione w miejscu, do którego cały zespół ma dostęp.
- Zapisz uzasadnienie dla każdego stwierdzenia problemu rynkowego, które wyjaśnia, dlaczego jest to problem i jak ważne jest jego rozwiązanie
- Dodaj kamień milowy w planie projektu, w którym stwierdzenia problemów muszą zostać przejrzane i zatwierdzone przez zespół wraz z uzasadnieniem biznesowym.
- Gdy zespół zacznie opracowywać rozwiązanie, okresowo powracaj do listy stwierdzeń problemów, aby przypomnieć wszystkim, co jest celem.
- Dla każdego problemu uchwyć listę cech produktu, które rozwiążą problem.
- Jeśli jakiegoś problemu nie można w pełni rozwiązać, ponownie przejrzyj przypadek biznesowy, aby upewnić się, że produkt jest nadal opłacalny.
Od stwierdzenia problemu do specyfikacji
Teraz, gdy masz już swoje stwierdzenia problemu, a zespół się z nimi zapoznał, zacznij wspólnie opracowywać specyfikację produktu. Ponieważ wszyscy w zespole rozumieją rozwiązywany problem, każdy może wnieść wkład do specyfikacji.
Ponieważ wykonałeś wstępną pracę polegającą na zidentyfikowaniu problemu, który rozwiązujesz, w ramach określonych ograniczeń, a zespół rozważył wiele sposobów dostarczenia rozwiązania, masz wystarczająco dużo informacji, aby napisać specyfikację produktu.
Wydawaj specyfikację produktu małymi partiami
Najlepszym podejściem jest wydawanie małych fragmentów specyfikacji zespołowi tak wcześnie, jak to możliwe, aby szybko uzyskać informacje zwrotne. Pomoże to uniknąć marnowania czasu na podążanie złą drogą i znacznie ułatwi zespołowi dostarczenie wysokiej jakości informacji zwrotnej.
Nie jesteś przekonany? Zastanów się nad tym: Co się stanie, jeśli otrzymasz do przejrzenia 200-stronicowy arkusz specyfikacji? Prawdopodobnie przejrzysz kilka pierwszych stron, a następnie pominiesz resztę.
A co się stanie, jeśli otrzymasz jednostronicowy dokument? Prawdopodobnie przejrzysz go w całości. Dwieście jednostronicowych dokumentów zaowocuje znacznie lepszą informacją zwrotną niż pojedynczy 200-stronicowy dokument.
Refer to the Problem Statement to Ensure You’re on Track
Również, w miarę rozwijania specyfikacji, sprawdzaj, czy produkt jest nadal ważnym rozwiązaniem problemu. Łatwo jest zaplątać się w kompromis nieodłącznie związany z rozwojem produktu i zapomnieć o sprawdzeniu, czy nadal jesteś na dobrej drodze.
Takie podejście zarządza również oczekiwaniami interesariuszy. Ponieważ proces jest kontrolowany, istnieją ramy i przejrzystość, które uniemożliwiają komukolwiek podważanie decyzji. W każdym momencie projektu będziesz w stanie dokładnie wyjaśnić, jaką wartość oferuje Twój produkt i dlaczego musi on posiadać funkcje, które określił zespół.
Projektowanie produktów zgodnie z potrzebami rynku jest kluczowe dla sukcesu
Uznaję, że w niektórych branżach jest to duża zmiana w stosunku do tego, jak produkty były projektowane i budowane. Jednak w miarę jak rynki stają się coraz bardziej konkurencyjne, a produkty coraz bardziej złożone, dostarczanie kolejnej iteracji czegoś, co już zbudowałeś, nie utrzyma Cię w biznesie na długo.
Aby dowiedzieć się więcej o tym, jak pisać wymagania w taki sposób, aby wszyscy interesariusze mieli jasne zrozumienie potrzeb rozwojowych, pobierz nasz eBook, Najlepsze praktyki pisania wymagań.
Przeczytaj EBOOK