niedziela, 2 września 2012

O tym co robić, kiedy nie ma nic do roboty

Załóżmy, że jesteś Product Ownerem. Twój zespół realizuje projekt, który jeszcze chwilę mu zajmie. Oczywiście cały czas na bieżąco wspierasz zespół i przyglądasz się pracy, ale osiągnęliście już takie zrozumienie, że zajmuje Ci to nie więcej niż 30% Twojego czasu. Co robić z resztą?

Odpowiedź jest w zasadzie prosta: przygotowywać się do następnego projektu. Przecież on nadejdzie. I to zwykle szybciej niż się wszyscy spodziewają. To jest oczywiste i większość product ownerów to robi. Co jednak, jeżeli jest już stworzona lista historii użytkownika? Czy można sobie odpuścić? Moim zdaniem nie. Co więc robić? Na początek dwie odpowiedzi ogólne.

Pierwszym obszarem, którym powinien zająć się product owner jest odpowiednie zarządzenie ryzykiem projektu. Jeżeli projektu jeszcze nie ma a wiadomo już o czym będzie to warto zrobić sobie porządną analizę ryzyka, zdecydować jakie będzie podejście w ramach projektu do poszczególnych ryzyk i zacząć wprowadzać w życie elementy strategii zarządzania poszczególnymi ryzykami. Może się okazać, że do projektu dojdzie cała masa zadań, które trzeba zrobić nie dlatego, że stanowią jego zasadniczą treść, ale dlatego że będą efektem przyjętej strategii zarządzania ryzykiem. Aha, oczywiście ponieważ rozmawiamy tu o product ownerze, to ryzyka te będą ryzykami biznesowymi i takie też będą działania na nie odpowiadające. Przykład? Może w ramach projektu trzeba bardzo wcześnie zrobić release do klienta? Może trzeba zrobić MVP? Może trzeba zarządzić kwestią wydajności rozwiązania? Itp.

Drugą odpowiedzią ogólną jest pojęcie wzięte z teorii ograniczeń i nazywające się "full kitting". Na polskie nie mam pojęcia jak się tłumaczy. Generalnie koncepcja polega na tym, aby zapewnić osobom zajmującym się daną czynnością absolutnie wszystkiego, co jest im potrzebne do wykonania tej czynności zanim zaczną się prace. Chodzi o to, aby sama czynność została wykonana bez przestojów spowodowanych brakami. Czyli czas pracy był maksymalnie efektywnie wykorzystany. W teorii ograniczeń o full kittingu mówi się zwykle w kontekście zadania w projekcie, jednak samą koncepcję można przenieść o jeden logiczny poziom wyżej i przyłożyć do całego projektu. Chodzi o to, aby zespół mógł od pierwszego dnia spędzać czas w projekcie w pełni efektywnie. Przykłady? Czy w ramach projektu będzie potrzeby dostęp do jakichś systemów? Czy są jakieś dane biznesowe/marketingowe/operacyjne, które dane zespołowi spowodowałyby szybsze i sprawniejsze prace?

Jeżeli zaś chodzi o szczegóły to poniżej kilka czynności, które mi szczególnie utkwiły w pamięci, a które wykonywałem w "czasie wolnym" kiedy aktualny projekt nabrał już rozpędu a do następnego było całkiem dużo czasu:

  • rozmowy z architekatmi - generalnie jeżeli pisałem user stories zawsze starałem się pokazać je architektom zanim zobaczył ją zespół. Dlaczego? Żeby się upewnić o ich technicznej wykonalności. Architekci też, to zwykle bardzo inteligentni ludzie z zupełnie inną perspektywą spojrzenia na projekt i produkt. Warto ich posłuchać. Jak nie ma architektów to zawsze warto się zwrócić do senior programistów czy kogokolwiek technicznego, kto rozumie stronę biznesową.
  • doszczegóławianie user stories - tak, to nie zawsze jest zgodnie z duchem metod agile, ale z praktyki wynika, że doszczegóławianie user stories często pomaga. Jeżeli na etapie przed projektem wyjdzie, ze user stories są niejasne albo zbyt ogólne, to nie ma co się łudzić - jak projekt ruszy i tak trzeba będzie to doszczegółowić. Po co czekać? Jeżeli jest czas można to zrobić wcześniej.
  • projekty graficzne - doświadczenie wskazuje, że jeden obraz jest wart więcej niż tysiąc słów. Generalnie pokazanie rozwiązania na projekcie graficznym (albo nawet na wystarczająco szczegółowej makiecie) powoduje, że product owner musi sobie przemyśleć dużo więcej rzeczy niż jak tylko stosuje opis słowny. Po drugie natomiast wprowadzenie dodatkowego projektu powoduje, że osoby, które będą wykonywały projekt mogą zobaczyć wizję w postaci obrazka. I bardzo często zgłosić trafne uwagi na temat wykonalności tej wizji.
  • zapewnienie dostępów - tzw. krótka piłka: jeżeli potrzebny jest do czegoś dostęp, to trzeba go załatwić i tyle. Im większa organizacja tym trwa to dłużej. Choć są wyjątki potwierdzające tę regułę. Wyjątki w obie strony.
  • zapewnienie zasobów współdzielonych - jeżeli będą potrzebne jakieś zasoby, czy to ludzie czy sprzęt, które nie są normalnie "na stanie" zespołu to trzeba się odpowiednio wcześniej zatroszczyć, aby były dostępne. I potem odpowiednio często się dopytywać i potwierdzać, czy to aby na pewno jest zagwarantowane. To typowa część "full kittingu" przedprojektowego...

Na koniec jeszcze jedna sprawa. Jeżeli zespół pracuje teraz nad projektem n, to szczegółowe przygotowania warto prowadzić tylko dla projektu n+1. Projekty n+2, n+3 i kolejne, mogą być opisane i przygotowane na dużym stopniu ogólności. Nie ma sensu zajmować się nimi w szczegółach. Dlaczego? Ano dlatego, że do ich rozpoczęcia jest jeszcze dużo czasu. I w tym czasie mogą pojawić się zmiany, które wymuszą kolejne, dokładne planowanie. Tak więc szczegółowe przygotowania dzisiaj mogłyby się obrócić w czysty przypadek waste, czyli straty. Czerpiąc znów z teorii ograniczeń można powiedzieć, że do projektów powinno się szczegółowo przygotowywać tak późno jak to jest możliwe, ale nigdy nie później.

4 komentarze:

Paweł Kowalski pisze...

Być może mój komentarz nie będzie do końca związany z omawianym tematem, ale chciałbym o to spytać kogoś doświadczonego na stanowisku product ownera.
Jestem programistą z doświadczeniem zarówno w dużej korporacji i małej firmie realizujących zlecenia dla klietów zewnętrznych jak i rozwijających autorskie produkty. Moim zdaniem wielkim błędem dużych przedsiębiorstw IT jest to, że tam programiści, czyli osoby faktycznie wytwarzający oprogramowanie spełniające potrzeby klienta, są izolowani od negocjacji i rozmów biznesowych. Ostatecznie spływają do nich tylko pojedyńcze zadania, często w tej postaci wydające się zupełnie oderwane od całości.
Moim zdaniem programista również powienien znać szerszy (biznesowy) aspekt implementowanych funkcjonalności oprogramowania. Często dopiero taki programista wchodząc w szczegóły konkretnego zadania dopatruje się pewnych nieścisłości w otrzymanych wymaganiach. Mając szerszą perspektywę byłby w stanie szybciej zaproponować rozwiązanie problemu lub przeprojektowanie fragmentu realizowanego system tak, aby lepiej spełniał oczekiwania klienta.
Jednakże w większości przypadków programiści odsuwani są od klienta i aspekt biznesowy do nich nie dociera. Zdarza się to zarówno w dużych firmach jak i mniejszych, ale w tych pierwszych jest to nagminne.
Czy zgadza się Pan z moją opinią na ten temat?

Szymon Włochowicz pisze...

Na początek proponuję używać bardziej zgodniej z kulturą internetową formy "na Ty". Zawsze będzie trochę luźniej.

Odpowiedź krótka jest "tak". Natomiast niestety nie wszystko i nie zawsze jest tak proste i nie zawsze można upraszczać pewne problemy. W tym konkretnym przypadku zawsze powinno być tak, że programiści (czy ogólnie wszyscy zaangażowani w projekt, testerzy też) powinni wiedzieć o tym jakie są cele biznesowe projektu i mieć kontakt albo z samym klientem, albo z jego najbliższym możliwym "proxy" w organizacji. Natomiast na pewno członkowie zespołów wykonawczych nie będą angażowani w negocjacje biznesowe, bo po pierwsze jest ich za dużo a po drugie kwestie poufności biznesowej często nie pozwalają na uczestniczenie w takich negocjacjach osobom nie będącym odpowiedzialnymi za biznes po stronie wykonawcy. Podobnie ze względu na poufność czasami nie wszystkie elementy biznesowe mogą być przekazane wszystkim zaangażowanym w projekt. Natomiast to co może być przekazane powinno być i to w jak największej ilości. Tak jak kiedyś już pisałem, znajomość celów bardzo ułatwia zaproponowanie najlepszej drogi do ich osiągnięcia.

Lukaszow pisze...

30% to chyba jednak przesada, ale rzeczywiscie PO moze miec jakis czas do dyspozycji. Pytanie czy nie mozna by wykorzystac tego czasu na "full kittingu" w biezacym projekcie... taki "backlog grooming", albo "full kitting backlog grooming". Sorry za to ostatnie okreslenie, ale nie moglem sie powstrzymac :-)

Szymon Włochowicz pisze...

To zależy w dużej części od tego jak pracuje zespół, jak bardzo rozumie priorytety biznesowe i właśnie od tego jak dobrze został projekt przygotowany. Moim zdaniem osiągnięcie 30% jest ambitne i trudne, ale realne ;) I oczywiście masz rację - pierwszeństwo powinno mieć ułatwianie pracy w OBECNYM projekcie. Było to dla mnie tak jasne, że o tym nie wspomniałem.