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.

Wdrożenia nowych metod - zadanie domowe

W środowisku osób zajmujących się wdrożeniami systemów zarządzania projektami (chodzi tu o systemy rozumiane jako zestawy procesów a nie oprogramowanie) do rangi anegdoty kultowej urosło podobno prawdziwe zdanie, wypowiedziane przez jednego z konsultantów pod koniec długiego i kosztownego projektu wdrażania nowej metody zarządzania projektami w pewnej firmie (XXX - nazwa metody zarządzania projektami):

“Jak na dziś to wszyscy już rzygają tym naszym XXX, w związku z czym wdrożenie uważam za w pełni zakończone sukcesem!!!”

Hmm. Przypadek wręcz kliniczny, który przypomniał mi się w ramach kolejnej rundy rozważań nad pewnym nieudanym wdrożeniem metod agile. Pytanie brzmi następująco. Jeżeli wdrażamy coś (cokolwiek) nowego w organizacji i jako efekt dostajemy aktywne niezaangażowanie osób do których adresowane było wdrożenie tego czegoś, to o czym to świadczy? Hipoteza jest taka, że po prostu nie odrobiliśmy pracy domowej i wdrożyliśmy rzecz, która jest absolutnie niepotrzebna z punktu widzenia osób zaangażowanych lub mimo, że rzecz jest potrzebna, to sposób jej wdrożenia jest nieadekwatny. Przez rzecz niepotrzebna rozumiem nie pozwalająca jednostkom na osiąganie lepszych rezultatów. Rezultatów mierzonych w sposób taki w jaki się je mierzy dla każdego konkretnego człowieka w tej konkretnej organizacji. Innymi słowy, mówiąc kolokwialnie z wprowadzonej przez nas zmiany człowiek “nic nie będzie miał”.

Oczywiste pytanie to czy każdy musi z tego wdrażanego rozwiązania coś mieć. Jasne, że tak! Bo skoro organizacja jako całość ma na danej nowości zyskać, to dlaczego nie mieliby zyskać poszczególni uczestnicy tej organizacji? Wszyscy uczestnicy. Z jakiego powodu tak często zakładamy, że wdrożenie czegoś nowego musi być robione przeciw ludziom a nie z ludźmi? Czy naprawdę jeżeli wdrażamy coś nowego to musi być tak, że ktoś będzie "rzygał" tym rozwiązaniem? Moja hipoteza jest taka, że absolutnie nie. Jeżeli rozwiązanie jest dobre dla całości organizacji, to musi być sposób, aby skonstruować je tak, aby było dobre dla wszystkich osób w nią zaangażowanych (odwrotnie nie działa). Powtarzam wszystkich. Tylko trzeba ten sposób znaleźć, dokładnie analizując sytuację.

Przed wdrożeniem trzeba odrobić pracę domową i zobaczyć jak zmiany proponowane przez agile mogą pomóc wszystkim innym interesariuszom projektów w organizacji. Ta pomoc musi zwłaszcza być sprawdzona w odniesieniu do miar, którymi mierzona jest efektywność pracy poszczególnych kierowników. Chodzi o to, aby tak skonstruować system zarządzania, że wprowadzenie nowych reguł spowoduje z punktu widzenia poszczególnych jednostek zmiany pozytywne. Bo na przykład będzie łatwiej osiągać właściwe cele lub choćby prezentować wyniki. Jeżeli nie zadbamy o to, aby wszystkim ważnym interesariuszom było łatwiej to osiągniemy efekt podobny do wyrażonego w przytoczonym cytacie. I osoby aktywnie niezaangażowane we wdrożenie, powodujące realne zagrożenie jego powodzenia.

Stąd, jak już kiedyś pisałem, jednym z większych błędów jakie można zrobić przy wdrażaniu agile jest wdrożenie samych tylko procedur. Trzeba zmienić jeszcze także inne elementy organizacji. A to jak je zmienić i na jakie, tak aby spowodować z jednej strony akceptację, a z drugiej zakładany efekt biznesowy to już jest zadanie domowe dla tych, którzy agile wdrażać będą. I gwarantuję dwie rzeczy:

1. nie jest to proste
2. nie ma gotowych rozwiązań (porównaj).

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...