blog.testowka.pl

Zbyt wiele osób a za mało kompetencji.

opublikowany przez 19, Gru, 2011, w kategoriach Agile, Scrum

Jakiś czas temu znalazłem ogłoszenie w którym ogłoszeniodawca szukał między innymi testerów do dużego projektu jakim miało być przepisanie systemu wspierającego bankowość elektroniczną pewnego banku.

Poniżej fragment ogłoszenia:

„Projekt ma trwać ok. 4-5 lat i jest organizowany przez 6 krajów: Polskę, Chiny, Brazylię, Stany Zjednoczone, Singapur i Indie. Na całym świecie do tego projektu ma być zatrudnionych 2000 osób”

Jestem w stanie zrozumieć, że systemy bankowe są dosyć skomplikowane (miałem z nimi trochę do czynienia) niemniej jednak 4-5 lat dla jakiegokolwiek projektu IT to perspektywa niesamowicie abstrakcyjna (przynajmniej dla mnie). Jeśli już na wstępie pomysłodawcy zakładają taki okres czasu to w jaki sposób uwzględnią zmiany jakie przez ten okres mogą się pojawić. Przez „zmiany” mam na myśli chociażby zmiany prawne, nie wspominając już o tym, że w takim okresie czasu mogą powstać zupełnie nowe technologie, które zrewolucjonizują tą branżę etc. Kolejny element ogłoszenia – 2000 osób [SIC!] – a po co aż tyle? – co oni chcą cały system operacyjny (albo cztery) do tego napisać, czy co? (a może… kto wie…). Skład narodowy zaangażowany w ten projekt też o czymś mówi – czyżby dewiza „zróbmy to tanio”?

Nie mówię, że się nie uda – w 5 lat można na prawdę wiele zrobić. Nawet jeśli 3/4 albo 9/10, a nawet 95/100 z tych ludzi będzie robiło rzeczy zupełnie bez sensu i zbyteczne to powinno się udać stworzyć ww. system bankowości elektronicznej, który być może będzie nawet działał lepiej od tego, który ów bank posiada obecnie. Pytanie tylko „Po co angażować tyle osób skoro prawdopodobnie można by było to zrealizować przy udziale kilkunastu do kilkudziesięciu osób?”.

Pozostaje mi tylko życzyć powodzenia. A gdyby przypadkiem zajrzał tutaj któryś ze szczęśliwie zatrudnionych do tego projektu to z chęcią usłyszę jakieś relacje z postępów prac.

Powyższe ogłoszenie najprawdopodobniej wynika z podejścia do wytwarzania oprogramowania i zarządzania projektami zawierającego taki termin jak „zasoby ludzkie” – wspomniane podejście zakłada, że jeśli praca postępuje zbyt wolno to należy dostarczyć więcej „zasobów” w postaci programistów/testerów/stażystów/praktykantów/whatever. Takie „zarządzanie zasobami ludzkimi” w wielu organizacjach doprowadziło do niesamowitego wzrostu liczby pracowników tworzących (z punktu widzenia funkcjonalności) względnie proste rzeczy, pracujących w środowisku w którym narzut komunikacji z tak dużą ilością osób na około jest tak duży, że praktycznie nie da się zrobić nic. Z zaszłości historycznych systemów wytwarzanych przez jakiś czas przez tak dużą ilość osób wynika nadzwyczajne skomplikowanie tych systemów – każdy programista pisze po swojemu i rozwija system w swoją stronę, z problemów komunikacyjnych wynika rosnąca ilość duplikacji i kierunków (wizji) w jakich system podąża etc. do większej ilości kodu potrzeba więcej osób, które w jakiś magiczny sposób posiądą tajemną wiedzę przynajmniej o jakimś wycinku funkcjonalności tworzonych produktów i w ten sposób spirala sama się nakręca.

Na jednej z prezentacji na konferencji ALE w Berlinie przedstawiono ciekawą teorię na temat tego, że Agile może wydajnie działać w organizacjach nie przekraczających 200 osób, gdyż średnio właśnie tyle osób każdy człowiek jest w stanie poznać, zapamiętać i z tyloma osobami jest w stanie utrzymywać mniej lub bardziej bliskie kontakty, a przede wszystkim jest w stanie spamiętać czym dana osoba się zajmuje. Podobnie liczba optymalna osób w zespole 5-12 to liczba wynikająca z naszej natury – mniej więcej tyle jest średnio liczba osób w rodzinie (powyższe wynika z uwarunkowań genetycznych, historycznych i ewolucyjnych).

Ponadto żeby skutecznie wdrożyć Agile w organizacji potrzeba przekonać do tego jak największą ilość osób, w tak dużych organizacjach przekonanie do czegokolwiek nawet połowy osób jest z góry skazane na niepowodzenie (lub zajmie nieskończoną ilość czasu).

Agile stawia na małe zespoły, które potrafią w krótkim czasie przy minimalnym narzucie komunikacyjnym dostarczyć działające oprogramowania wytworzone w sposób prosty. Niektórzy mówią nawet o ekstremalnie prostym programowaniu – stąd właśnie termin Extreeme Programming (XP). Przeważnie skomplikowanie rozwiązań wynika z problemów komunikacyjnych w organizacji, traktuje o tym między innymi Prawo Conway’a które obrazuje to jak problemy komunikacyjne między ludźmi wpływają na problemy integracji systemów tworzonych przez tych ludzi.

Powyższy post jest rozwinięciem kolejnej części prezentacji na temat przyczyn niepowodzeń wdrożeń Agile w organizacjach, którą od czasu do czasu wygłaszam przy różnych okazjach. Wkrótce pojawią się kolejne części opisujące kolejne problemy. Prezentacja oraz notka powstały na podstawie obserwacji moich i moich koleżanek i kolegów zajmujących się na co dzień wdrożeniami Agile, a także wielu godzin rozmów z różnymi ludźmi na tematy mniej lub bardziej związane z wdrożeniami Agile. Cały cykl możecie znaleźć tutaj.


3 Comments for this entry

  • Ceti

    Może oni wszystko będa robić in house – sprzątanie, pieczenie pizzy dla deweloperow, wytwarzanie Coca Coli…..

  • Krystian

    Nie znałem Prawa Conway’a. Tak jak mówisz projekt wygląda na zbyt rozdmuchany i ciekawi mnie na jakiej podstawie te wymagania stworzyli. Jako konsultant, który trafia czasem na podobne projekty mam zawsze dylemat, czy od razupowiedzieć im, że to nie będzie działać i zaryzykować, że na podstawie różnicy zdań odpadnę z rekrutacji, czy przytaknąć, a potem dokopać się do wizji projektu i zobaczyć jak można ją na prawdę zrealizować.

  • marta

    Przekrój geograficzny przez skład zespołu sugeruje nie tylko, że zleceniodawca chce ‚tanio objechać’, ale że produkt ma być wytwarzany 24h/dobę.
    No i pewnie w US będą siedzieli wszelkiego typu architekci/analitycy/managerowie a reszta krajów dostarczy trybiki pracujące w pocie czoła.
    Nad-zatrudnienie wynika też często z tego, że najpierw zatrudniane są osoby na wyższe szczebelki, a potem okazuje się, że nie mają kim kierować i się ludzi dokooptowuje.

Skomentuj