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.