Wczoraj podczas spotkania, miałem ciekawą rozmowę z przedstawicielami jednego z producentów systemów ERP. Okazało się, że mają bardzo podobne do moich doświadczenia i wnioski: podczas wdrożenia systemu ERP potrzebny im jest ktoś, jeden, kto zna i rozumie jak działa dana firma, a nie setki stron dokumentacji czy stenogramy z dziesiątków godzin warsztatów z przyszłymi użytkownikami. Do tego firma ta – nabywca systemu ERP – powinna mieć, nie szczegółowo opisane dziesiątki detalicznie opisanych procesów i ich wariantów, procedur czy setki i tysiące nie raz wymagań, a strategię i taktykę, z której wynika (da się wyczytać) rola oprogramowania ERP w firmie: taktykę czyli opis realizacji strategii firmy z pomocą planowanego do wdrożenia systemu ERP. Ta taktyka, to opis tego kiedy i po co oprogramowanie ma wspierać pracownikw organizacji. To, jak się to będzie odbywało w szczegółach, zostanie opracowane przez dostawcę (wykonawcę) konkretnego produktu, to dostawca gotowego oprogramowania opracowuje koncepcję wdrożenia, na podstawie dokumentu opisującego taktykę użycia tego oprogramowania i wymagania biznesowe (oprogramowanie dedykowane wymaga dodatkowo zaprojektowania i udokumentowania logiki biznesowej jaką ma ono realizować).
I co teraz? Teraz potrzebne jest źródło spójnej wiedzy o organizacji, jej strategii i taktyce w którą ma się wpasować oprogramowanie ERP. Któż jest tym źródłem? [[Product owner]].
Pytane teraz brzmi: kim jest i członkiem czyjego zespołu jest (powinien być) “product owner”? Tu zacytuję ostani akapit mojej ciepłej jeszcze recenzji książki:
…na ile wizja produktu uprawnia jej posiadacza do aktywnego kierowania projektem wraz z kierownikiem projektu (Scrum Master), ale to pozostawiam czytelnikom i praktykom. Jedno moim zdaniem jest pewne: nie ma sensu by zespół developera kontaktował się, z tabunem przyszłych ?userów?, ma sens by dostawał spójną wiedzę o tym co tak na prawdę ma powstać.
Źródło: Agile Product Management with Scrum | Jarosław Żeliński IT-Consulting
Autor powyższej książki nie daje wprost odpowiedzi na to pytanie, jednak milcząco zakłada też, że to zespół dostawcy “walczy” ze zjawiskiem i product owner jest członkiem tego zespołu, nie zmienia to faktu, że wymagana od niego wiedza i zrozumienie tego, do czego user będzie używał oprogramowania, powinna być taka jak opisałem wyżej.
Co usłyszałem po raz kolejny (podobne rozmowy z dostawcami oprogramowania nie raz już prowadziłem) od przedstawicieli dostawcy systemu ERP? Potrzebują bardzo zwięzłej i spójnej dokumentacji (ale raczej 50-ciu stron niż setek, że nie wspomnę o kilku tysiącach (tak – widywałem takie) i po stronie klienta (jednej) osoby, która ten dokument zna, rozumie, ma dostęp do kluczowych osób w organizacji. Najchętniej do autora tego dokumentu… Dostawcy oprogramowania jak dostają listę setek pozycji wymagań podzielonych w mało zrozumiały sposób na funkcjonalne i poza funkcjonalne (i inne) raczej sobie z tych specyfikacji dworują niż cieszą się z ich otrzymania (pomijam, ze nie czytają w całości). Po co są więc robione? Bo zamawiający postrzega swoją pracę przez pryzmat jej złożoności, wariantowości, nie patrzy z perspektywy narzędzia a tym właśnie jest oprogramowanie. To tak jak by cieśla lub stolarz opisał wymagania na młotek ciesielski w postaci setek stron “user story” o tym jak, do czego i kiedy używa(łby) młotka.. dla analityka projektanta taki opis (a konkretnie jego skąpa część) ma sens, dla konstruktora – żadnego, ten raczej oczekuje rysunku technicznego wykonawczego.
Powyższy diagram to poglądowy model roli product ownera (PO) autorstwa jednego z moich ulubionych “zwinnych analityków”: Scott’a Amblera (Scott Ambler). Niewątpliwie można dywagować czy PO to “pracownik” dosatwcy czy kupującego ale tu chyba część wątpliwości rozwieją słowa jednego z moich klientów, postrzegam go jako jednego z lepiej zarządzających ryzykiem biznesowym, znanych mi, prezesów firm: “Panie Jarku nie wiem czy jest Pan lepszym czy gorszym specjalistą od ludzi dostawcy, zatrudniłem Pana bo przełożonym tamtych jest Prezes tamtej firmy”.
Where Do Product Owners Come From? The goods news is that there are several viable options for where Product Owners may come from: Business analyst. Although a traditional business analyst could fill the role of product owner, there is a risk that they will fall into their old habits of communicating via documentation. Keep in mind that what agile teams really need are people with agile analysis skills who are empowered to make decisions. So, a better option is an empowered agile business analyst. (za The Product Owner Role: A Stakeholder Proxy for Agile Teams).
Tak więc nasuwa się wniosek, że rolę PO powinien pełnić ten człowiek, który właśnie skończył analizę biznesową i napisał raport z niej. Raport, który zawiera specyfikacją wymagań (najlepiej w formie jak opisana powyżej). W zasadzie nadzór autorski nad realizacją taktyki wdrożenia systemu ERP (oprogramowania w ogóle) to nic innego jak “bycie product ownerem” w projekcie na etapie jego realizacji a SCRUM faktycznie, na dzisiejsze czasy, wydaje się być najlepszą metodą zarządzania takimi projektami a utrzymywanie aktualności dokumentu analizy biznesowej i wymagań w toku projektu prowadzi do tego, że po zakończeniu projektu mamy “niechcący” kompletną i aktualną dokumentacje stanu uzyskanego w toku wdrożenia.
(książki Scotta Amblera czekają na recenzję ;))
