Własność funkcjonalności

W projektach informatycznych zdarza się bardzo często sytuacja kiedy projekty jest na tyle duży, że do poprawnego zdefiniowania wymagań potrzeba więcej niż jednej osoby. Po prostu wiedza dziedzinowa dotycząca projektu nie jest możliwa do zgromadzenia przez jedną osobę. W takim wypadku szczególnej uwagi nabiera kwestia tego, kto jest "właścicielem" poszczególnych funkcjonalności.

Przez właściciela funkcjonalności rozumie się osobę, która jest w pełni odpowiedzialna za zdefiniowanie danej funkcjonalności i zwykle będzie osobą używającą jej w przyszłości (odbiorcą korzyści biznesowej dostarczanej przez daną funkcjonalność). Zdefiniowanie takiej osoby jest niezmiernie ważne w kontekście mogących się pojawić wątpliwości dotyczących tego jak ma działać zdefiniowana funkcjonalność. Musi być ktoś, kto ma ostateczny głos w sprawie zdefiniowania pożądanego sposobu zachowania się systemu. W mniejszych systemach tą osobą jest właściciel produktu, w większych często właściciel produktu nie ma wystarczającej wiedzy aby decydować o każdej funkcjonalności i dlatego warto wyznaczać właścicieli poszczególnych funkcjonalności. Najlepiej właściciela po prostu zapisać na karcie funkcjonalności.

Powyższy system działa dobrze, do czasu kiedy nie zajdzie sytuacja w której dwie funkcjonalności zdefiniowane przez różne osoby stoją w konflikcie ze sobą. Wbrew pozorom często tak jest. Na przykład w systemach kompleksowo obsługujących przedsiębiorstwa proces sprzedaży zakłada zwykle udział działów sprzedaży, magazynu, księgowości a często także produkcji. Każdy z tych działów może mieć różną koncepcję tego jak proces sprzedaży wyglądać powinien. W takich sytuacjach osobą rozstrzygającą powinien być właściciel produktu. Niezależnie bowiem od właścicieli poszczególnych funkcjonalności musi istnieć ktoś, kto jest odpowiedzialny za całość definiowania wymagań i w związku z tym za ostateczny kształt projektowanego systemu. Tą osobą jest właśnie właściciel produktu. W przypadku dużych systemów, gdzie występuje wielu właścicieli funkcjonalności brak właściciela produktu jest bardzo często spotykanym błędem.

I na koniec: w takich sytuacjach jak opisana bardzo ważne jest, aby właściciel produktu był mocno "umocowany" w strukturze organizacji. Jest to konieczne, gdyż prędzej czy później będzie musiał on godzić wymagania różnych działów i forsować rozwiązania korzystne dla całości przedsiębiorstwa a nie dla poszczególnych kierowników. Osoba nisko stojąca w hierarchii, bez odpowiedniego autorytetu formalnego i nieformalnego nie ma szans w starciu z kierownikami "silosów". Wyznaczenie mało znaczącego właściciela produktu jest drugim bardzo często popełnianym błędem w opisywanych sytuacjach.

Księga procedur a 15 minut

Dzisiaj będzie stricte o projektach IT. Kiedyś dawno temu przeczytałem, że programista pracując nad nowym kodem średnio co 15 minut podejmuje ważną decyzję technologiczną. Fakt ten przypomniał mi się w zeszłym tygodniu, kiedy zaangażowałem się w ciekawą dyskusję nad procedurami w firmie.

Ogólnie pytanie brzmi: jak dokładnie można opisać procedury, które powinien stosować pracownik. Istnieje pewna grupa przekonań, według których procedury mogą i powinny opisywać każdą istotną czynność wykonywaną przez pracownika. Założenie stojące za takimi stwierdzeniami jest takie, że można przewidzieć i opisać każdą jedną sytuację wobec której stanie pracownik. A jak już będzie to opisane to pracownikowi będzie łatwiej pracować, bo zamiast myśleć (?!) sięgnie tylko do odpowiedniej procedury. Hmm, ciekawe, ale na pewno nie w projektach IT. Być może w budownictwie, którego tradycje sięgają kilku tysięcy lat można skatalogować i opisać każdy jeden przypadek. Ale w programowaniu? Gdzie każdą rzecz można wykonać na przynajmniej kilka sposobów? Gdzie decyzje technologiczne podejmuje się co 15 minut? Nawet gdyby teoretycznie było to możliwe księga wzorców projektowych musiałaby liczyć tysiące stron. A gdzie procedury decydowania, który wzorzec użyć? Po pierwsze nikt nie byłby w stanie tego opisać, a jeżeli nawet to potem nikt nie byłby się w stanie tego nauczyć :-)

Co więc zamiast ścisłych procedur? Po pierwsze określone ramy postępowania, czyli np. pracownicy wiedzą co jest ważne w danym rozwiązaniu: elastyczność czy wydajność. Po drugie właściwi pracownicy, którzy potrafią użyć swojej inteligencji do wybrania spośród znanych im rozwiązań tego najlepszego akurat w zadanych ramach. Co 15 minut :-) Tu problem jest większy, ale cóż za to w końcu firma płaci programiście albo innemu administratorowi, żeby to ON się znał na rzeczy. Jeżeli firma uważa, że ON się nie zna, to czemu go jeszcze zatrudnia? Pracownik musi być na tyle inteligentny i proaktywny, żeby potrafić zastosować w danym momencie rozwiązanie najlepiej realizujące cel postawiony dla danego oprogramowania. Jeżeli firmie uda się zbudować taki zespół i ustalić wspierającą go strukturę zarządzania to będzie ona na pewno bardziej "agile" (zwinna) niż firmy starające się opisać każdą decyzję pracownika w opasłym tomie procedur.

Dyspozytor vs. Delegujący

Jak wiadomo instytucję szefa wymyślono między innymi po to, aby zarządzać zestawami zadań zbyt dużymi do zrealizowania przez jedną osobę. Istnieją dwie metody w ramach których szef może podzielić się swoim zadaniem. Umownie nazwijmy to byciem dyspozytorem bądź delegującym. Dyspozytor to osoba, która przekazuje konkretną instrukcję do wykonania. Rozdziela pracę rozumianą jako zadania do wykonania. To znaczy każdy z członków zespołu otrzymuje listę rzeczy do wykonania a następnie rozliczany jest z tego czy postąpił zgodnie z przekazaną instrukcją.

Delegowanie natomiast to zupełnie inne podejście. Zamiast przekazywać zadania przekazuje się odpowiedzialność. Czyli określa się pożądany cel i jego parametry jakościowe, natomiast nie przekazuje się wprost instrukcji jakie zadania i w jakiej kolejności należy wykonać, aby określony cel uzyskać. W tym podejściu zakłada się, że sposób dojścia do celu najlepiej znany jest osobom faktycznie wykonującym daną pracę a nie menedżerom. Rolą menedżera jest przekazać odpowiedzialność, zapewnić pracownikowi środowisko, w którym może wykonywać swoją pracę bez przeszkód a następnie odebrać prace sprawdzając czy założone cele zostały osiągnięte.

W metodach zwinnych zarządzania projektami tak naprawdę możliwa jest do zastosowania tylko i wyłącznie metoda druga. Próba zastosowania metody pierwszej (dyspozytora) prowadzi bardzo szybko do powstania wąskich gardeł zarządczych na poziomie kierowników. W środowiskach agile za dużo rzeczy dzieje się zbyt szybko, aby kierownik mógł panować nad nimi na poziomie zadań do wykonania. Jeżeli chcemy aby w naszym środowisku osiągać szybko rezultaty to jedyną opcją jest przekazywanie odpowiedzialności. Fakt, menedżer traci kontrolę nad sposobem wykonywania pracy i musi swoim ludziom zaufać. Ale jednocześnie zyskuje możliwość osiągnięcia końcowego rezultatu wielokrotnie szybciej niż przy użyciu bardziej tradycyjnej metody dyspozytorskiej.

Należy tylko pamiętać, aby razem z odpowiedzialnością wydelegować uprawnienia. Najgorszą sytuacją, którą można zafundować swoim podwładnym jest dać im odpowiedzialność za coś, ale bez uprawnienia do decydowania o wszystkich zasobach i środkach potrzebnych do wykonania danej pracy. Stawiamy wówczas pracowników przed koniecznością wykonania pracy na którą nie mają wpływu. Nie mogą więc sami decydować o jej sukcesie bądź porażce. Taka sytuacja prowadzi wprost do dużej i narastającej frustracji osób zaangażowanych w projekty.

Last but not least wypadałoby jeszcze pamiętać o różnicach kulturowych. Ci z Was, którzy mieli przyjemność pracować z Hindusami dokładnie wiedzą, że zastosowanie znajduje tylko i wyłącznie jedna z opisywanych metod.

Obciążenie systemu

Ludzie instynktownie rozumieją, że jeżeli obciążymy serwer do 100% jego mocy spowoduje to nagły spadek wydajności, drastyczne zwiększenie czasu oczekiwania na odpowiedź oraz ogólnie rozumiany brak stabilności. Jednocześnie tak bardzo dziwią się jak Google może utrzymać krótki czas reakcji na zmiany na rynku, bardzo dużą wydajność pracy oraz stabilność, pozwalając swoim programistom na 20% pracy na rzecz zadań nie związanych z ich aktualnymi projektami.

Przecież to jest to samo. Tak jak serwer, aby utrzymać maksymalną wydajność i krótki czas odpowiedzi nie powinien być przeładowany pracą na więcej niż 80% tak samo pracownik, aby utrzymać maksymalną wydajność i krótki czas reakcji nie powinien być przeładowany powyżej 80% swojego czasu. Co ciekawe jeżeli obciążenie serwera zaczyna w zwykłej firmie oscylować w okolicach 80% to zwykle dyrektor działu IT natychmiast występuje z wnioskiem o zakup nowego serwera. Z drugiej strony jeżeli pracownik jest obciążony na 80% to w zwykłej firmie dyrektor (nawet ten sam) zwykle... dorzuci mu jeszcze jeden projekt. A potem bardzo się będzie dziwił, że czas oczekiwania na efekt gwałtownie rośnie a wydajność spada. Gdzie tu logika?

(temat zaczerpnięty z książki “Implementing Lean Software Development”)

Budowanie dla utrzymania

W nawiązaniu do tego, co kiedyś napisałem o wyzwaniach związanych z tworzeniem dokumentacji wdrożeniowej i utrzymaniowej oprogramowania napiszę jeszcze o jednym pokrewnym rozwiązaniu. W znanym tekście “The New New Product Development Game”* autorzy jako jeden z głównych powodów znaczącej poprawy efektywności producentów stosujących opisywane nowe metody tworzenia produktów podali korzystanie z zespołów wielofunkcyjnych. W szczególności w skład zespołów opracowujących nowe produkty wchodziły osoby z produkcji, czyli te, które później będą odpowiedzialne na wytworzenie w setkach tysięcy sztuk pomysłów inżynierów. Idea, która za tym stała była prosta i oczywista - często to, co jest optymalne z punktu widzenia inżyniera projektującego nowy produkt, wcale nie jest optymalne z punktu widzenia osoby, która ten produkt będzie musiała wykonać w tysiącach sztuk. Celem tworzenia takich zespołów miało być projektowanie takich nowych produktów, które nie tylko będą spełniały marzenia inżynierów (i marketingowców), ale jednocześnie będą proste w produkcji. Stąd zaangażowanie osób za nią odpowiedzialnych w rozwój produktu od samego początku projektu.

Przekładając to co zostało napisane na temat produkcji na rozwój oprogramowania wydaje się, że odpowiednikiem produkcji (wytwarzania) jest tutaj (wbrew pozorom) wdrożenie/utrzymanie. Sytuacja wygląda bowiem tak, że zespół rozwoju projektuje nowy system, który później trafia do zespołów wdrożeniowych i utrzymaniowych, które muszą zadbać o to, aby produkt działał bezbłędnie u każdego z klientów firmy. Podobnie jak produkcja w fabryce, tak wdrożeniowcy wytwarzają gotowe, działające u klient produkty firmy software’owej, oczywiście na bazie produktu stworzonego przez inżynierów odpowiedzialnych za rozwój.

Ciągnąc tą analogię dalej w niektórych projektach warte zainteresowania jest włączenie osób odpowiedzialnych za wdrożenia i utrzymanie (maintenance) do zespołów wytwarzających produkt, czyli zespołów rozwijających nowe oprogramowanie. Taka koncepcja wygląda na pierwszy rzut oka dość karkołomnie, ale im dłużej się nad tym zastanawiam tym większy ma sens. Wiadomo, że włączenie tych osób do zespołu spowoduje, że system będzie inaczej zaprojektowany. Zarówno te osoby, które muszą system zainstalować u klienta jak i te, które potem muszą odpowiadać na klienckie zapytania i/lub radzić sobie z błędami zgłaszanymi przez klienta będą miały mnóstwo pomysłów na usprawnia. Oczywiście jedną ze strategii jest je po prostu zbyć, ale... Ale tak naprawdę to one wystawiają swoją głowę klientowi na ścięcie i to od efektywności ich pracy zależy postrzeganie firmy przez organizację klienta. I nawet pomijając to jaki jest cel tej gry, to jak wiadomo każdemu z nas pensje tak naprawdę płaci... klient naszej firmy.

* Tekst znany jest głównie z tego, że w nim jako w pierwszym w literaturze pojawiło się określenie SCRUM na zespół pracujący zgodnie z metodami “lekkimi” - pojęcie agile jeszcze wtedy nie istniało. Sam artykuł ukazał się w Harvard Business Review, ale jak to kogoś interesuje to można go sobie wygooglać w formie PDFa. W tytule nie ma błędu.

Zespoły - na co zwrócić uwagę

Projekty realizowane metodami agile/zwinnymi wymagają zupełnie innych zespołów niż takie realizowane metodami tradycyjnymi. Jak wiadomo zespół powinien być maksymalnie 10-12 osobowy, idealnie przebywać w jednym miejscu fizycznym, sam się zarządzać + parę innych cech, bardzo często wymienianych w literaturze. Ja natomiast dzisiaj napiszę o tych czynnikach, które mogą być potencjalnym zagrożeniem dla sprawnego działania zespołu realizującego projekt przy użyciu metod zwinnych. Na te czynniki powinno się zwrócić szczególną uwagę podejmując decyzję o realizowaniu projektu metodami zwinnymi.

Po pierwsze należy to jasno powiedzieć, choć może nie jest to twierdzenie politycznie poprawne: skuteczność zespołu pracującego metodami zwinnymi zależy w dużym stopniu od kultury miejsca pracy. Chodzi tu zarówno o kulturę organizacyjną jak i kulturę państwa/narodu, którego przedstawicielami są osoby uczestniczące w projekcie. Kultura musi wspierać prace grupowe i jednocześnie deprymować lansowanie się jednostek kosztem grupy. Praca metodami zwinnymi jest pracą grupową i na to poradzić nic nie można. I tak jak z innymi zajęciami grupowymi (na przykład sport) często zdecydowanie lepszy jest zespół składający się z osób o przeciętnych zdolnościach, ale zdolnych do współpracy od zespołu składającego się z geniuszy, którzy nie potrafią ze sobą porozmawiać, bo każdy chce tylko udowodnić swoją wyższość. To jaki charakter pracy jest uprawiany w danej organizacji zależy właśnie od kultury organizacji. I niestety zmiana tego jest bardzo trudna.

Po drugie zespoły pracujące metodami zwinnymi powinny w czasie trwania projektu móc pracować tylko i wyłącznie nad tym projektem. To niestety jest bardzo trudne do zrobienia w przypadku organizacji posiadających silną strukturę macierzową. Taka struktura zakłada bowiem, że w każdy członek zespołu projektowego ma jeszcze swojego przełożonego "liniowego", który w znaczącej większości przypadków decyduje o takich rzeczach jak awanse czy podwyżki. To oznacza, że praktycznie w każdej sytuacji niejasnej pracownicy będą słuchać swojego przełożonego liniowego a nie osób z projektu. W tradycyjnie zarządzanych projektach powoduje to duże problemy i jest m.in. jedną z przyczyn notorycznych opóźnień. W projektach zarządzanych metodami zwinnymi takie podejście jest całkowicie destrukcyjne i projekty praktycznie nie mogą się toczyć. Projekt zwinny bardzo podobny jest do wspomnianego już kiedyś przypadku operacji w szpitalu. Na czas operacji cały zespół ma być tylko i wyłącznie na sali operacyjnej. Przecież nikt nie wyobraża sobie, że nagle anestezjolog wyjdzie z sali i zajmie się sporządzaniem raportu, którego akurat bardzo potrzebuje jego przełożony "liniowy". Ciekawe, że w projektach, takie zachowanie jest uważane za coś normalnego.

Po trzecie i ostatnie (na dzisiaj) należy sobie zdawać sprawę, że zupełnie inna jest rola kierownika projektu w projekcie zarządzanym metodami tradycyjnymi a zupełnie inna jest ta rola w projektach zarządzanych metodami zwinnymi. Do tego stopnia, że niektórzy puryści zajmujący sie agile twierdzą wręcz, że w tych metodach stanowisko kierownika projektu istnieć nie powinno i nazywają je inaczej (np. SCRUM Master). Tak naprawdę nie ważne jak się ono nazwa, ważne jest, że osoba wyznaczona do kierowania powinna mieć zupełnie inne umiejętności i na co innego zwracać uwagę niż w projektach tradycyjnych. Typowym przykładem jest kwestia rozdziału zadań i podejmowania decyzji. W metodach tradycyjnych zwyczajowo to kierownik projektu podejmuje wszystkie decyzje sam, podobnie on rozdziela zadania do wykonania. Takie podejście jest zaprzeczeniem metod zwinnych. Tutaj zadaniem kierownika jest tak pokierować (przewodzić) pracy zespołu, aby decyzje były podjęte wspólnie a zadania rozdzielone na zasadzie swobodnego wyboru przez członków zespołu. To oznacza również, że kierownik stosujący zwinne metody zarządzania musi być ekspertem w dziedzinie, której dotyczy projekt. W odróżnieniu od tradycyjnego podejścia, gdzie parafrazując pewną bardzo znaną książkę "nawet pielęgniarka może poprowadzić projekt budowlany, byleby miała dobrze zdefiniowany system zarządzania projektami". W metodach zwinnych takie podejście gwarantuje porażkę.

Metody zwinne w organizacji "stabilnej" cz. 4

Dzisiaj po raz ostatni napiszę o tym dlaczego stabilne organizacje przechodzą na zwinne zarządzanie projektami. Powód, który zostawiłem na koniec jest dość kontrowersyjny, choć jednocześnie jest dość często wymieniany przez managerów z firm, które wdrożyły zarządzanie zwinne projektami.

Powodem, dla którego przechodzi się na zarządzanie zwinne jest często chęć przestawienia organizacji z nastawienia czysto technicznego na nastawienie biznesowe. Tradycyjny paradygmat zarządzania przyłożony do organizacji produkujących bardzo zaawansowane technicznie produkty takie jak na przykład oprogramowanie powoduje bowiem, że wewnątrz organizacja zaczyna skupiać się na technice podczas gdy na zewnątrz powinna skupiać się na zaspokajaniu biznesowych potrzeb klienta. Inżynierowie pracujący w organizacjach zarządzanych tradycyjnie przez większość swojego czasu zastanawiają się jak rozwiązać problem techniczny a nie problem biznesowy klienta. Wbrew pozorom to nie to samo. W niektórych firmach powstają wręcz specjalne działy analityków, których jedynym zajęciem jest przekładanie wymagań biznesowych na wymagania techniczne. Założenia za tym stojące są takie, że inżynierowie nie mogą zrozumieć wymagań biznesowych a z drugiej strony, że klient nie jest w stanie pojąć techniki. O ile to drugie być może jest prawdziwe to zarządzanie zwinne projektami całkowicie odrzuca założenie pierwsze.

Całe proces zarządzania zwinnego został tak stworzony by na każdym etapie dbać o klienta. Inżynier pracujący nad projektem głównie rozwiązuje problemy klienta i spełnia jego wymagania. Każde działanie zespołu projektowego jest podporządkowane wypełnieniu wymagania funkcjonalnego klienta. Wymagania funkcjonalne zaś są reprezentacją wartości dodanej dla klienta, czyli tego, za co firma realizująca projekt dostaje pieniądze. Takie podejście pomaga inżynierom skupić się na rozwiązywaniu realnych problemów klientów a nie problemów technicznych, które często są ciekawe i interesujące ale w żadnym razie nie przyczyniają się do znacznej poprawy funkcjonalności produktu.

Kolejną cechą pomagającą zespołowi projektowemu nastawić się na rozwiązywanie potrzeb klienta jest sposób zapisywania wymagań i idący za tym stały kontakt z klientem. W projektach zwinnych zakłada się, że wymagania pierwotnie spisywane są na dość dużym poziomie ogólności. Następnie są one uszczegółowiane podczas bieżących kontaktów z przedstawicielami klienta. Jak już kiedyś wspominałem rozwiązuje to problem kodowania i dekodowania informacji – osoby implementujące wymagania na bieżąco i bezpośrednio od klienta dostają informację o tym jak będzie wykorzystywana zlecona funkcjonalność. Otrzymywanie tych informacji bezpośrednio od klienta z pominięciem zespołu analityków oznacza lepszy kontakt z rzeczywistym światem klienta i zdecydowanie lepszą komunikację. Doświadczenie projektów prowadzonych metodami zwinnymi wskazuje, że ilość niepoprawnie (z punktu widzenia klienta) działających funkcji produktu jest nieistotnie mała. Oczywiście wszystko to pod warunkiem, że klient zgodzi się poświęcić swój czas na intensywną komunikację z zespołem projektowym – zwykle nie ma z tym jednak problemu, gdyż w zamian uzyskuje zdecydowaną korzyść w postaci lepiej przemyślanego produktu.

Dużą rolę w skupieniu na kliencie odgrywają przeprowadzane po każdej iteracji prezentacje działającego produktu. Podczas tych prezentacji klient może i powinien sam używać produktu wytworzonego do tej pory w projekcie. Najłatwiej jest to zrobić w przypadku oprogramowania komputerowego, gdzie po prostu klient dostaje do ręki klawiaturę i myszkę. Może w pełni korzystać ze wszystkich funkcji, które miały być wyprodukowane we właśnie zakończonej iteracji. NA tym samym spotkaniu obecni są także członkowie zespołu projektowego, którzy na żywo widzą, w jaki sposób klient używa ich produktu. Takie spotkania bardo pomagają ustawić właściwą perspektywę biznesową wśród zespołu. Szczególnie, że odbywają się relatywnie często. Zdarzało się wielokrotnie, że zespół widząc jak ich klient używa produktu proponował rewolucyjne zmiany w produkcie wielokrotnie upraszczające sposób użycia i w efekcie pozwalające klientowi pracować dużo bardziej efektywnie.

Na koniec mała uwaga: w żaden sposób nie chcę tutaj dowieść, że tradycyjnie zarządzane projekty nie są nastawione pro-kliencko. Twierdzę jedynie, że metody zwinne wydatnie pomagają skupić się na rozwiązywaniu faktycznych problemów klienta, komunikacji z klientem oraz na sposobie, w jaki faktycznie będzie wykorzystywany produkt końcowy.

Metody zwinne w organizacji "stabilnej" cz. 3

Dzisiaj kolejny powód, dla którego organizacje stabilne wdrażają zwinne metody zarządzania projektami. Powodem tym jest przejrzystość prac, którą zapewniają metody zwinne.

Przejrzystość prac jest widoczna na dwóch ogólnych poziomach. Po pierwsze przejrzyste jest to co kto robi i jaki jest stopień zaawansowania prac. Podczas codziennych spotkań zespołu uczestnicy projektu opowiadają nad czym pracowali wczoraj i co będą robić dzisiaj, co skutkuje bardzo szybkim rozpowszechnianiem się informacji. Prowadzi to do jasnej sytuacji na temat tego, jakie jest aktualne zajęcie wszystkich członków zespołu. Innym, jeszcze ciekawszym narzędziem są wszelkiego typu „radiatory informacji” wykorzystywane przez zespoły do graficznej prezentacji zaawansowania prac. To temat na osobny post, ale w skrócie narzędzia te są „analogowe” (np. tablica z żółtymi karteczkami) a nie elektroniczne i mogą zawierać najważniejsze informacje zarządcze dotyczące projektu: co zostało zrobione, co jest robione, co będzie robione, a także informacje o tym jak aktualny status ma się do planu. Wszystko to jest przedstawione wizualnie. To narzędzie jest genialne w swojej prostocie a jednocześnie przekazuje zadziwiająco dużo informacji.

Drugim poziomem przejrzystości jest przejrzystość w stosunku do klienta. W tradycyjnych metodach zarządzania projektami często jest tak, że klient nie ma najmniejszej wiedzy, co się dzieje w projekcie, za który przecież płaci, aż do dnia ostatecznego odbioru produktu. Techniki zwinne zakładają inne podejście. Po pierwsze klient musi być zaangażowany cały czas. W każdej chwili zespół pracujący nad projektem ma prawo zapytać się klienta o uszczegółowienie wymagań lub potwierdzić, że wymagania zostały zaimplementowane poprawnie. Takie zaangażowanie samo w sobie daje klientowi wgląd w to, nad czym aktualnie pracuje zespół projektowy i wystarcza, aby klient nie miał pretensji, co do stopnia informowania go o stanie projektu. Jednak techniki zwinne mają jeszcze jedno potężne narzędzie: krótkie iteracje zakańczane działającą wersją produktu. Po każdej z iteracji klient może wypróbować nowe funkcjonalność stworzone podczas tej iteracji. W związku z tym klient ma cały czas poczucie, że wie, za co płaci. Wie też, kiedy pojawią się kolejne funkcjonalności do przetestowania (na koniec aktualnej iteracji). To z punktu widzenia klienta zapewnia pełną przejrzystość i pozwala na utrzymanie bardzo dobrych relacji z dostawcą. Uwaga!!! Trzeba być jednak świadomym, że taka sytuacja nie powstanie od razu i jej wypracowanie będzie wymagało włożenia odpowiednio dużej ilości czasu w ustalanie zasad współpracy z klientem.

Inną stroną przejrzystości prac jest to, o czym wspomniał jakiś czas temu w komentarzach Marcin (tutaj). Przejrzystość może być bowiem bardzo niewygodna dla tych, którzy mówiąc delikatnie „nie lubią” pracować. Częste sprawdzanie postępu prac i konieczność wyraźnego informowania o tym co się zrobiło powoduje, że nie ma mowy o ukrywaniu się przez kilka dni nic nie robiąc. Poza ewidentnym pokazaniem szefom, że taki pracownik jest zbędny w środowiskach pracujących według metod zwinnych pojawia się bardzo silna presja ze strony grupy. Podczas wspomnianych codziennych spotkań wszyscy współpracownicy słyszą i widzą kto pracuje mało. Doświadczenie wskazuje też, że da się wyczuć kto po prostu się obija a kto rzeczywiście tworzy mało bo ma jakieś problemy. Osoby ewidentnie się obijające są pod bardzo dużą presją grupy aby zabrać się do pracy.

I w ten sposób ujawnia się jeszcze jedna duża zaleta metod zwinnych: znacząco wzrasta wydajność zespołów pracujących przy użyciu tych metod w porównaniu do zespołów stosujących metody tradycyjne. Rzecz nie do przecenienia w biznesowym świecie nastawionym na efektywność prac. Co więcej wzrost tej efektywności nie ma żadnego negatywnego wpływu na atmosferę prac. Wręcz przeciwnie ma wpływ pozytywny.

Wdrażanie metod zwinnych

Metody zwinne jak wielokrotnie wskazywałem na tym blogu i w każdych innych źródłach są niezwykle proste. Pełen proces zarządzania projektem zwinnym przy odrobinie szczęścia można zapisać na kilku kartkach A4. To prowadzi do przekonania, że wdrożenie metod zwinnych w firmie jest równie proste. Ostrzegam. Wcale tak nie jest.

Główny problem polega na tym, że aby poprawnie zarządzać projektami nie zmienić i wystarczy wdrożyć samych procesów zarządczych. W większości wypadków natomiast zmiana sposobu realizacji projektów polega mniej więcej na tym, że pewnego pięknego dnia szef daje pracownikom książkę lub zbiór instrukcji i mówi „od dziś tak będziemy pracować”. Niestety tak się nie da. Być może w ten sposób można zmienić metodę zarządzania projektami z PMI na Prince2 lub odwrotnie. Natomiast jest to zdecydowanie za mało, aby przestawić firmę na zarządzanie zwinne.

Wdrożenie zarządzania zwinnego musi być skupione nie na zmianie samych procesów, ale na zmianie przynajmniej trzech elementów w firmie:

1. Procesu – tak, to jest ważne, aby wszyscy zainteresowani wiedzieli, według jakiego procesu pracują i co jest od nich wymagane. Ten element jest najprostszy – jest to czysta wiedza, którą trzeba sobie po prostu przyswoić. Są do tego książki, są szkolenia, nie ma problemu.
2. Umiejętności ludzi – zarządzanie zwinne niesie za sobą konieczność używania zupełnie innego zestawu umiejętności, zwłaszcza w obszarze międzyludzkim, niż tradycyjne zarządzanie projektami. Ze względu na bardzo duże znaczenie komunikacji międzyludzkiej i odstąpienie od dokumentowania najmniejszych szczegółów uzyskuje się z jednej strony dramatyczny wzrost wydajności, z drugiej zaś duże pole do psucia stosunków między ludźmi. Tylko osoby posiadające odpowiednie umiejętności będą mogły z sukcesem prowadzić projekty zwinne. Nabycie tych umiejętności nie jest już takie proste jak zmiana procesu. Umiejętności z definicji oznaczają, że coś się umie zrobić – to już jest praktyka a nie teoria.
3. Kultura pracy (tzw. kultura organizacyjna) – rzecz ostania, ale bardzo ważna, aby zarządzanie zwinne pokazało wszystkie swoje zalety i zapewniło oczekiwany wzrost efektywności. Kultura pracy, czyli zestaw postaw prezentowanych przez wszystkich pracowników organizacji. Tutaj musi nastąpić wielka zmiana. Choćby dlatego, aby "szefostwo" nie wymagało na początku dokładnego planu całego przedsięwzięcia a z drugiej strony sprzedaż nie próbowała usilnie sprzedać klientowi efektu końcowego drugiej iteracji (w momencie kiedy wersja produktu miała pojawić się po iteracji ósmej). Kulturę pracy zmienić najtrudniej. Nie można tego zrobić oddolnie, zawsze musi to przyjść od strony wyższej kadry kierowniczej. Podkreślam to, gdyż jest to jasna wskazówka, że bez zaangażowania i przekonania wyższego kierownictwa wdrożenie metod zwinnych nigdy nie zakończy się pełnym sukcesem a metody te nie pokażą swojego pełnego potencjału.

Podsumowując wypada mi tylko powtórzyć, że jeżeli ktoś twierdzi, że można „wdrożyć agile” poprzez danie do przeczytania książki programistom i kierownikom projektów to się bardzo grubo myli. Przeprowadzenie wdrożenia metod zwinnych tylko na jednej płaszczyźnie zamiast na wszystkich w pesymistycznym przypadku może spowodować w organizacji więcej szkody niż pożytku.

Szacowanie przy użyciu prędkości

Pytanie, które pojawia się dość często jest następujące: jak oszacować kiedy zakończy się projekt (rozumiany w sensie dostępnej kolejnej wersji produktu)? Jak wszystkie inne problemy w sztuce zwinnego zarządzania projektami jest to proste, choć niekoniecznie zgodne z tym czego oczekiwaliby specjaliści od tradycyjnych metod zarządzania projektami.

Podstawą szacowania jest tzw. prędkość pracy zespołu. Prędkość ta określa ile jednostek funkcjonalności zespół jest w stanie ukończyć w trakcie jednej iteracji. To ile "warta" jest każda z funkcjonalności jest określane zgrubnie przez zespół na etapie planowania wersji. Później jest to doprecyzowane przy poszczególnych etapach planowania i/lub retrospekcji. W każdym razie po etapie planowania wersji powinno być dostępne oszacowanie ile jednostek funkcjonalności liczy cała zaplanowana wersja. Później sprawa jest już wybitnie prosta. Otóż po wykonaniu kilku (zwykle trzech) iteracji można z dużą dozą prawdopodobieństwa powiedzieć ile jednostek funkcjonalności produkuje zespół w jednej iteracji - tzw. prędkość zespołu. Następnie należy podzielić ilość jednostek, które zostały do zrealizowania przez prędkość zespołu i otrzymujemy ile iteracji pozostało do końca. Uwaga, iteracji a nie dni czy miesięcy. W zwinnym zarządzaniu projektami iteracja jest najmniejszą niepodzielną jednostką, więc to jej będziemy używać do określania ile jeszcze pozostało do końca. Przeliczenie iteracji na konkretne daty może już być zadaniem dla kogoś spoza zespołu projektowego.

Proste? Tak, pojawia się jednak pewne "ale". Co zrobić, jeżeli z jakichś powodów koniecznie musimy mieć oszacowanie przed pierwszą iteracją i nie możemy czekać do trzeciej iteracji aby określić prędkość zespołu? Cóż - po pierwsze trzeba spróbować wytłumaczyć tej osobie, która "nie może" czekać, żeby jednak zaczekała. Argumentacja jest prosta: czy lepsze są dane rzeczywiste dostępne za trzy iteracje czy dane wysoce niepewne (a.k.a. wróżenie z fusów) dostępne dzisiaj? Jeżeli nie uda się wyperswadować to też można sobie poradzić, choć jest to utrudnione. W takim wypadku należy jedną, dwie lub trzy iteracje po prostu bardzo dokładnie zaplanować. Rozbić na zadania i razem z zespołem dokładnie zaplanować co ile czasu zajmie. Na postawie planowania podaje się przybliżoną prędkość zespołu a potem liczy się już tak jak we wcześniejszym akapicie.

Proste? Wiem, że nie do końca. Ten temat jest akurat takim tematem, który rewelacyjnie tłumaczy się przy użyciu kartki papieru i dwóch, trzech wykresów. Niestety blog takich możliwości interakcji nie daje. W przypadku, gdyby ktoś był bardzo zainteresowany zapraszam do kontaktu.

Metody zwinne w organizacji "stabilnej" cz. 1

Ostatnimi czasy metody zwinne zarządzania projektami stają się coraz bardziej popularne. Metody te najlepiej sprawdzają się w środowiskach bardzo dynamicznych, w projektach, w których występuje duża doza niepewności. Okazuje się jednak, że duża część firm działających w bardziej stabilnych środowiskach również wdraża zarządzanie zwinne. Jakie są powody tego? Na pewno swoista „moda”, ale czy tylko? Ze względu gwałtownie narastający charakter zjawiska napiszę w kilku postach, jakie mogą być powody, dla których organizacje pracujące w środowisku stabilnym wdrażają zwinne zarządzanie projektami.

Uzasadnienia nie będą w żadnej logicznej kolejności, dlatego na pierwszy ogień pójdzie powód bardzo ważny dla większości osób zaangażowanych we wdrożenia zwinnego zarządzania projektami, choć z drugiej strony być może mniej interesujący dla kierownictwa. Otóż skutkiem wprowadzenia zwinnych metod zarządzania projektami, jest to, że zespołom realizującym projekty pracuje się... przyjemniej.

Przyjemność ta wynika z kilku czynników. O jednym pisałem już kiedyś, przy okazji omawiania tematyki zmian w projekcie – w projektach zarządzanych metodami zwinnymi zespół pracuje nad zestawem funkcjonalności, które nie mają prawa się zmienić (w danej iteracji). To powoduje duży spokój psychiczny zespołu, jako że jasno określone są reguły, na podstawie których dokonywane są zmiany i nikt nie zaskakuje członków zespołu. Wbrew pozorom stabilność (choćby w ramach jednej iteracji) jest jednym z podstawowych wymogów zachowania przyjemności z wykonywania pracy.

Kolejnym bardzo dobrze wpływającym na pracę czynnikiem jest fakt, że ze swojej natury zespoły pracujące zgodnie z metodami zwinnymi są zespołami relatywnie małymi położonymi w jednej fizycznej lokacji. Bardzo częsta komunikacja między członkami zespołu powoduje dobrą atmosferę pracy choćby dlatego, że wszelkie niezrozumienia są błyskawicznie usuwane a problemy są komunikowane przynajmniej raz dziennie podczas spotkań. Poza tym w takim zespole ze względu na charakter spotkań (zarówno codziennych jak i podsumowujących iterację) każda z osób czuje się dowartościowana, bo jej zdanie jest brane pod uwagę.

Uwaga. Powyższe jest prawdą tylko o ile osoby zajmujące się koordynacją zespołów posiadają odpowiednie umiejętności komunikacyjne!!!

Praca w projektach zwinnych jest przyjemna również dlatego, że każdy z członków zespołu ma poczucie odpowiedzialności i szybką nagrodę w postaci osiągnięcia sukcesu – działający produkt na koniec iteracji. Mała wielkość zespołu w połączeniu z krótkimi iteracjami oraz tym, że na koniec każdej iteracji trzeba dostarczyć produkt wzbogacony o konkretną wartość dodaną dla klienta powoduje, że każdy z członków zespołu jest zaangażowany w dostarczanie tej wartości. Krótki czas realizacji sprawia, że każdy widzie efekty swojej pracy podczas prezentacji dla klienta. Człowiek natomiast skonstruowany jest tak, że lubi jak mu coś wychodzi.

Jak to się ma do zarządzania firmą jako całością? Ma się, gdyż jeżeli pracownikom pracuje się przyjemniej to pomaga im to pracować efektywnie. Poza tym pracownicy, którzy mają przyjemną atmosferę w pracy zwykle rzadziej myślą o zmianie pracodawcy. Jeżeli idzie to w parze z efektywnością (a idzie) to oczywistym jest, że lepiej mieć pracownika zadowolonego niż zdegustowanego.

Wielkość zespołu zwinnego

Temat wielokrotnie poruszany, tym razem doczeka się mojego komentarza. Zwykło sie uważać, że zespół pracujący metodami zwinnymi nie powinien mieć więcej niż 10-12 osób (maksymalna górna granica). Mało kto jednak pisze dlaczego tyle a nie więcej. Co prowadzi, do usilnych prób implementowania metod zwinnych w większych zespołach.

Historię trzeba zacząć od zasad podstawowych. Jedną z wartości zarządzania zwinnego jest "people and interactions over processes and tools", czyli "ludzie i interakcje ponad procesy i narzędzia". Czy to oznacza, że narzędzia i procesy nie są ważne? Nie. Narzędzia i procesy są ważne (zarządzanie zwinne to też proces) ale ważniejsi od nich są ludzie i interakcje miedzy nimi. Każdy kto pracował nad jakimkolwiek bardziej złożonym problemem w grupie ludzi doskonale wie, że choćby nie wiadomo jak dokładne były procesy i narzędzia zawsze zdarzają się sytuacje, kiedy lepiej pójść do kogoś do pokoju i wyjaśnić coś w 2 minuty zamiast (zgodnie z procesem) robić eskalację przez zarząd. Oczywiście mówimy tu o projektach a nie o np. produkcji leków - w przypadku produkcji leków raczej trzeba dokumentować, bo się kończy jak w Jelfie.

Interakcje między ludźmi są najszybszą znaną formą przekazywania informacji. Jakiekolwiek narzędzie spowalnia przekaz informacji, gdyż wymusza zakodowanie informacji do postaci akceptowalnej przez narzędzie (np. zapisanie) a następnie odkodowania przez osobę, która to odbiera (odczytanie). Dlatego w projekty realizowane zwinne cechują się często dużo wyższą efektywnością niż realizowane metodami tradycyjnymi. Po prostu to co jest oczywistością, czyli bezpośrednie przekazywanie informacji zostało tam wbudowane w metodykę zamiast jak to proponuje wiele innych metod udawać, że da się lepiej komunikować przy użyciu narzędzi - głównie dokumentów tworzonych tonami w niektórych projektach.

Dobrze, więc skoro jest tak dobrze się komunikować bezpośrednio to skąd ograniczenie na wielkość zespołu? Jak to w życiu bywa wszystko w nadmiarze szkodzi. Utrzymywanie efektywnego zespołu polegającego na komunikacji interpersonalnej oznacza w skrócie, że członkowie zespołu muszą mieć możliwość swobodnego rozmawiania każdy z każdym i wymiany informacji. Problem w tym, że ilość kanałów komunikacyjnych w zespole rośnie wykładniczo w stosunku do liczby osób w tym zespole. I tak dla zespołu 5 osobowego mamy 10 kanałów komunikacyjnych, dla 8 osób kanałów jest 28, dla 10 osób 45, dla 12 osób 66 kanałów. I tu jest granica, której przekraczać nie należy. Przy 15 osobowym zespole jest już ponad 100 kanałów komunikacyjnych - ponad dwukrotny wzrost w stosunku do 10 osobowego zespołu. Czas poświęcony na dogadywanie się pomiędzy członkami zespołu zaczyna przewyższać wszelkie zyski z wykorzystania szybkich metod komunikacyjnych.

Do wszystkiego należy podchodzić w sposób zgodny z rosądkiem. Ostatnio słyszałem o przypadku firmy X, gdzie wdrożono zwinne zarządzanie projektami a zespoły "po optymalizacji" liczą 20 osób (190 kanałów komunikacyjnych w zespole). Wydaje mi się, że to będzie jeden z tych nielicznych przypadków, kiedy na koniec stwierdzone zostanie, że metody tradycyjne były lepsze. A może to nie stare metody były lepsze, tylko wprowadzenie nowych nieprofesjonalne?

Metody zwinne a struktura organizacyjna

Czy struktura organizacji może mieć wpływ na zdolność do działania z wykorzystaniem metod zwinnych? Mogłoby się wydawać, że nie bo co ma struktura organizacji do metod wykorzystywanych w konkretnym projekcie. A jednak...

Dla uproszczenia przyjmijmy, ze mamy cztery podstawowe struktury organizacyjne:

• Liniowa - organizacja dzieli się na działy, które realizują poszczególne elementy projektu. Każdy dział dostaje do realizacji ten kawałek projektu który odpowiada jego specjalizacji. Cała władza skupia się w rękach kierowników liniowych.
  
• Macierzowa słaba - do organizacji liniowej wprowadza się koordynatorów projektów, którzy koordynują pracę osób w poszczególnych działach. Ich zadaniem jest jednak jedynie koordynacja prac, bez możliwości realnego wpływania na pracowników. Bezpośrednimi przełożonymi pracowników są kierownicy liniowi.
  
• Macierzowa silna - różni się od macierzowej słabej tym, że pojawia się pełnowartościowy kierownik projektu, który ma odpowiedzialność za projekt ale również uprawnienia do władzy na członkami zespołu projektowego. Kierownicy liniowy pełnią funkcje pomocnicze dbając o zapewnienie personelu, bieżące zarządzanie kompetencjami, sprawy formalne itp.
  
• Projektowa - organizacja całkowicie projektowa nie posiada struktur liniowych a tylko pulę pracowników, z których wybiera się członków zespołów projektowych. Kierownik projektu ma pełną odpowiedzialność i uprawnienia do zwierzchnictwa nad członkami zespołu projektowego.
  

Którą należałoby wybrać dla realizacji projektów metodami zwinnymi? Zanim się na to pytanie odpowie najpierw kilka słów o tym czym powinien charakteryzować się zespół pracujący nad projektem metodami zwinnymi. Poniżej tylko cechy właściwe dla tej dyskusji:

1. Zespół jest interdyscyplinarny - skupia ludzi o różnych umiejętnościach ale jednocześnie każdy członek zespołu może wchodzić w różne role
   
2. Zespół ponosi pełną odpowiedzialność za wykonywaną pracę
3. Zespół ma wszelkie uprawnienia potrzebne do wykonywania zadanej pracy
4. Kluczowy członkowie zespołu pracują tylko i wyłącznie nad jednym projektem
   

W przypadku organizacji o strukturze liniowej żadna z tych cech nie mogłaby być spełniona. Nie ma interdyscyplinarności - w ramach jednego zespołu linowego osoby posiadają prawie identyczne umiejętności. Zespół nie może ponosić pełnej odpowiedzialności za całość prac, bo z definicji wykonuje tylko ten jej kawałek za który odpowiada komórka organizacyjna w której pracuje. Zespół nie ma uprawnień do wykonywania całej pracy a jedynie tego kawałka, który dotyczy ich części organizacji. Ponieważ organizacja jest liniowa a nie projektowa najczęściej pracuje "nad zagadnieniem", które jest w wielu projektach. Cecha czwarta też nie jest spełniona. W takich warunkach nie można prowadzić projektu metodami zwinnymi!!!

W przypadku organizacji macierzowej słabej cecha pierwsza ma się trochę lepiej. Zespół pochodzi z różnych działów, więc jest interdyscyplinarny. Cecha druga jednak nie jest już spełniona, gdyż nadal zespół nie posiada odpowiedzialności - posiadają ją kierownicy liniowi. Podobnie z uprawnieniami - mimo iż jest zespół projektowy to nie ma on możliwości podejmowania decyzji, która leży w gestii kierowników liniowych. Co do cechy czwartej to w tej strukturze organizacyjnej często jest możliwe osiągnięcie stanu kiedy członkowie zespołu projektowego pracują nad jednym i tylko jednym projektem.

Wszystkie cechy zespołu zwinnego są możliwe do osiągnięcia tylko w organizacjach projektowych i macierzowych silnych. Macierzowe silne muszą być na tyle silne, aby rola kierowników liniowych faktycznie ograniczała się tylko do spraw administracyjnych. Trzeba mieć możliwość traktować ich jako wsparcie administracyjno-logistyczne. Jeżeli w rękach kierowników liniowych pozostanie możliwość podejmowania (blokowania) decyzji to okaże się, że zespół zwinny nie będzie miał ani uprawnień ani odpowiedzialności za projekt.

Co z tego wszystkiego wynika? Otóż jeżeli jakaś organizacja będzie chciała wdrożyć zwinne zarządzanie projektami to musi się też zastanowić nad tym, czy jednocześnie nie należy zmienić struktury organizacyjnej. Bardzo często może to powodować spięcia. Przejście z organizacji liniowych czy macierzowych słabych do bardziej zorientowanych projektowo oznacza bowiem, że kierownicy liniowi tracą część swojej władzy. To zaś zawsze jest dla ludzi trudne...