Moje dotychczasowe doświadczenia brały się z firm skoncentrowanych na realizacji projektów na zamówienie. Pracę w firmach utrzymujących i rozwijających produkty wyobrażałam sobie jako mniej interesującą dla analityka, bo mniej wymagającą. Skoro mamy już jakiś produkt, pewnie dodajemy niewielkie zmiany i nie można wykazać się inwencją taką jak podczas projektów startujących od zera. Zweryfikowałam swoje zdanie.
Praca w firmie z produktem
Czym się różni praca w firmie skoncentrowanej na projektach od tej skupionej na produktach? Różnic jest wiele. Można by wymieniać długo, ale skupię się na tych najbardziej rzucających się w oczy oraz tych, które w największym stopniu wpływają na charakter pracy analityka.
Nie da się nie zauważyć różnic już na poziomie struktury organizacyjnej. Oto pojawiają się takie byty jak pełnoetatowy właściciel produktu, obsługa zmian, usuwanie usterek. Struktura organizacyjna może (bo to zależy od planu i inwencji zarządzających) wskazywać na opiekę nad produktem i jego rozwój bardziej niż na formowanie zespołów projektowych. Ludzie nie żyją od projektu do projektu, ale mają mnóstwo innej pracy przy pielęgnacji, wdrażaniu produktu. Pojawiają się takie pojęcia jak: wydawanie wersji, licencje, pytania: „Na jakiej wersji jest klient?”. Życie toczy się nieco innym tempem. Żyje się nie z każdej godziny projektowej, ale także z licencji, które „same wpadają”. Jest nieco więcej przestrzeni na zajmowanie się usprawnieniami.
Wymagania z perspektywy firmy i klienta
Wymagania w projekcie opartym o produkt mogą zostać spełnione na kilka sposobów:
- Potrzebny mechanizm już istnieje, więc wystarczy o nim wiedzieć, sprawdzić czy na pewno pasuje i zastosować,
- Potrzebny mechanizm istnieje częściowo, więc produkt wymaga rozbudowy,
- Potrzebny mechanizm nie istnieje, więc trzeba go przygotować od nowa.
Z perspektywy firmy wygląda to następująco:
- Świetnie! Nic tylko się cieszyć, sprzedawać i uszczęśliwiać klienta 😉
- Jeśli chcemy rozwijać produkt w tym kierunku, zróbmy to! Lub nie, jeśli nie chcemy.
- Czy chcemy rozwijać w ten sposób produkt? Czy to nasza kluczowa funkcjonalność? Jeśli tak, doróbmy to sobie, jeśli nie, nie róbmy. Dochodzi jeszcze opcja integracji z zewnętrznym rozwiązaniem, aby spełnić tylko wymaganie z tego projektu, lub dodatkowo, jeśli jest szczególnie użyteczne, wszystkich następnych.
Z perspektywy klienta wygląda to tak, że niektóre rzeczy ma gotowe od ręki, inne otrzyma jako rozszerzenie, pozostałe w nieco innej formie, np. przez integrację z gotowym rozwiązaniem, a jeszcze innych nie otrzyma wcale.
Czy to znaczy, że tacy klienci mają gorzej niż w projektach szytych na miarę? Wydaje mi się, że nie, bo choć przy niektórych wymaganiach spotkają się z oporem, tak samo rzecz się ma z nowym oprogramowaniem i funkcjami, które są szczególnie skomplikowane czy czasochłonne, a ich wycena nie jest przyjmowana w podskokach. Z drugiej strony mają za „tańsze pieniądze” to, co w produkcie jest już gotowe, a przygotowanie zajęło kiedyś mnóstwo wysiłku. Jeśli chodzi o wymagania, zależy jak bardzo są typowe i czy da się uszczęśliwić klienta typowymi rozwiązaniami.
Analiza w firmie z produktem
Jeśli doświadczyłeś już projektu „z wolnego wybiegu”, gdzie całość wymyślana jest i projektowana od zera, wiesz na ile przeróżnych aspektów musisz zwracać uwagę podczas określania wymagań. Czy z produktami jest łatwiej?
Poza sprawnym lawirowaniem w meandrach celów, procesów, interesariuszy, wymagań i innych typowych dla projektów, przy produkcie dochodzą nowe źródła zmartwień, tudzież wyzwań:
- Właściciel produktu,
- Produkt – jego możliwości i ograniczenia.
Właściciel produktu to kolejny, szalenie ważny interesariusz. Decyduje on o „być albo nie być” biznesowych wymagań klienta. Od niego zależy, czy wymaganie będziemy zaspokajać (bo jest zgodne z wizją rozwoju produktu) czy nie. W kontekście niejako „przebranych” wymagań, wyzwaniem analityka jest takie skomponowanie rozwiązania jako całości, aby spełnić potrzeby klienta. Jeśli odpadają wymagania poboczne – pół biedy. Gorzej, jeśli wymaganie, którego nie zamierzamy spełnić, leży na krytycznej linii do spełnienia celu całego przedsięwzięcia. Wtedy pozostaje ratować się wykorzystaniem dodatkowych rozwiązań lub po prostu jasne przekazanie informacji i konsekwencji klientowi. Choć pewnie nie będzie szczęśliwy, część jego pracy wykonaliśmy dla niego – przeprowadziliśmy analizę brakujących potrzeb do spełnienia.
W epicentrum projektowego świata stoi sam produkt. Majestatycznie zaznacza swoje istnienie poprzez bycie właśnie takim, jakim jest i nie daje o tym zapomnieć. Chcę przez to powiedzieć, że do analizy potrzebne jest jak powietrze dobre poznanie produktu – z jego możliwościami i ograniczeniami. Nie da się z sukcesem dodać nawet takiego niewinnego jednego małego pola, jeśli nie poznasz kontekstu, w jakim działa cała funkcjonalność i przy okazji 50 powiązanych. Im bardziej skomplikowany system, im mniej wygląda, a więcej robi – tym więcej zabawy. Ale cóż kręci Ciebie, analityka, tak bardzo, jeśli nie nauka nowych rzeczy i rozgryzanie zagmatwanych powiązań?
Czy zatem analiza w projektach z produktem w centrum jest łatwiejsza?
Powiedziałabym, że wymaga więcej wiedzy, precyzji, dokładności. Nieco mniej kreatywności (choć nie całkiem, bo nowe funkcje pozwalają się kreatywnie „wyżyć”). Jeśli nie mamy porządnego modelu referencyjnego (AS-IS systemu), pisanie wymagań zajmuje więcej czasu, bo trzeba odwzorować ten cały kontekst. Trzeba sprawdzić wszystkie ograniczenia. Trzeba przeanalizować wpływ zmian, na X istniejących powiązanych kontekstów. Powiem tak – jest co robić 😉
