wtorek, lipca 01, 2008

Projekty Informatyczne - Mity ;-)

Z wykształcenia jestem fizykiem, z zawodu i zamiłowania programistą, ostatnio pełnię jeszcze rolę development leada [mówiąc prosto jestem tym na którego wszyscy mogą krzyczeć ;-), dokładniej zaś sprawę ujmując jestem kimś kto łączy developerów z product managerem [używam nazw anielskich bo lepiej oddają znaczenie]]. Moja wiedza więc o programowaniu i prowadzeniu projektów jest mieszanką praktyki nabytej w paru firmach, własnych lektur oraz pewnych szkoleń. Po tym przydługim wstępie przejdźmy do mitów :-)Harmonogramy.
Idea jest piękna i słuszna - każdy wie co, kiedy i w jakim czasie ma zrobić, dzięki temu można podać daty tego kiedy produkt będzie dostępny, można planować kolejne releasy i tego typu sprawy.
Rzeczywistość jest taka, że gdy harmonogramy są ułożone przez kogoś kto je rozumie cały zespół zaczyna grać na harmonogram ;-) Nic nie robisz od dwóch tygodni i przez następne dwa nic nie będziesz robić? Chcesz iść w takiej sytuacji na urlop? Nie możesz, bo jak wprowadzi się Twój urlop do super programu okazuje się, że data zakończenia przesunie się o tydzień....
Częściej jest jednak tak, że harmonogram układa się dla ułożenia. Wiemy, że klient życzy sobie produktu za 3 miesiące więc tak budujemy harmonogram by na papierze trwało wszystko 3 miesiące ;-)Z moich doświadczeń widzę, że najlepszy model w tym przypadku to coś podobnego do Scrum'a [choć bez dodatków które tylko denerwują ludzi]. Developerzy to zwykle dość inteligentni ludzie i potrafią zarządzać swoją pracą tak by zmieścić się w terminach. Wtedy product manager musi wyznaczyć tylko ogólne ramy czasowe, a wszystko się samo ułoży. Dodatkowo developerzy widzą zwykle zależności czasowe i starają się samo-organizować tak by jedyną osobą na którą trzeba czekać z wykonaniem kolejnej czynności była osoba która ją wykona ;-). Jak zauważyłem takie podejście świetnie działa w małych zespołach do 5-6 osób, w większych nie miałem okazji oglądać takiego podejścia.
Zarządzanie.
Jest ważne, sęk w tym że z uporem maniaka wszędzie uczy się takiego prowadzenia projektów w którym developer sprowadzany jest do niezbyt rozgarniętego trybika. Mówiąc inaczej - do zarządzania inteligentnymi i odpowiedzialnymi ludźmi stosuje się metody stworzone do zarządzania normalnymi ludźmi. Taka mała dygresja, przeciętny developer choć w swojej grupie jest przeciętny, to w ogóle populacji utrzymuje się w górnych stanach populacji [im firma lepiej płaci tym wyższe stany to są :-)], mówiąc jeszcze inaczej częsta może być sytuacja w której szeregowi podwładni są inteligentniejsi od menadżera prowadzącego projekt. Dobrzy menadżerowie to wiedzą [i tu też zasada im firma lepiej płaci tym więcej menadżerów którzy to wiedzą :-)] i cieszą się z tego.
Konsekwencją tego stanu jest to, że w większości przypadków developerzy tym lepiej pracują im więcej wiedzą o projekcie, ale w standardowym zarządzaniu gdzie traktowani są jak tribiki nikt im nic nie mówi ponad to co muszą wiedzieć.
Rozwiązanie jest proste - Agile - czyli w najbardziej skrajnym przypadku ;-) totalna samoorganizacja, ludzie sami wprowadzają procedury i standardy. Wystarczy dać im tylko ramy, które stanowi system do bug-trackingu i repozytorium kodu. Wtedy działa to tak, że z jednej strony, poprzez system bug-trackingowy, wrzuca się oczekiwania, a z drugiej strony odbiera się produkt :-)Z doświadczenia powiem, że dla małych projektów z 5-6 developerami to działa na pewno :-)Configuration Management.
Tak naprawdę nikt do końca nie wie co to jest.... oczywiście są ludzie którzy się tym zajmują i wiedzą więcej, ale i tak dla przeciętnego zjadacza obwarzanków sprowadza się to do tego, że jakoś trzeba pracować na aktualnym kodzie jednoczenie mogąc pracować w kontekście "historycznym" ;-)Rozbuchane zasady z mnóstwem gałęzi, splitów, integracji i tym podobnych świetnie wygląda na papierze, ale zwykle jest całkowicie niepotrzebne.
Continous Integration i to w wersji najprostszej, czyli pracy na wspólnym kodzie nawet bez build centerów, automatycznych testów i podobnych pozwala na obejście większości problemów. W końcu jak duża jest szansa, że 2 lub więcej ludzi z 6 osobowego zespołu dotknie tego samego kodu i sobie będzie wzajemnie przeszkadzać? Niewielka, choć szacunkowo zdarza się to w 10-15% przypadków ;-) i narzut wynikły z opóźnień tym spowodowanych jest o wiele mniejszy niż ten wynikły z walki z gałęziami.
Dokumentacja.
To jeden z największych mitów ;-) Wszyscy chcą dokumentację do projektów [sam nieraz chciałem], ale nikt jej nie tworzy ;-) A gdy wymogi każą ją tworzyć to jest traktowana po macoszemu i nikomu nie chce się jej później aktualizować [co zwykle oznacza przepisywanie].
Sens ma dokumentowanie punktów styku między podsystemami, interfejsów, protokołów komunikacji i zamotanych algorytmów, do tego dochdzą jeszcze sytuacje gdy coś jest regulowane przez prawo i trzeba to zaimplementować, wtedy też dobrze napisać dokumentację jak to ma działać. Dobrze jest jeszcze udokumentować pewne szkielety rozwiązań i zrobić listę przykładów do naśladowania i do unikania. Choć może się okazać, że i to by było zbyt dużą liczbą dokumentów. Zwykły JavaDoc wystarcza ;-)Podsumowując mogę stwierdzić, że do developmentu próbuje się wprowadzać formalizm, ale on często zamiast pomagać zabija twórcze podejście. Brak formalizmu jest zły, ale życie dla formalizmów jest jeszcze gorsze. Najzdrowszym podejściem jest podejście rozsądne ;-) Które można wyrazić jako niedogmatyczne trzymanie się zasad ;-)


Podobne postybeta
Starzeję się ;-)
Kiedy zmieniać pracę i po co? (w IT)
"Ja? Niech ktoś inny płaci" ;-)
Mam milion rzeczy na głowie... co robić?
Teoria biurokracji ;-)

2 komentarze:

  1. Zacznę od końca.
    Dokumentacja - na nią nie zawsze jest czas. Jednak im większa forma tym większa szansa na dokumentację. Wynika to z faktu, że wypadnięcie jednego zespołu produkcyjnego do roboty papierkowej nie będzie wtedy zagrożeniem dla terminów.
    CM - Warto sięgnąć po ITIL. Najlepiej drogą losowania / wyboru ochotnika niech tą rolę przejmie któryś z programistów. Jej istotą nie jest zarządzanie konfiguracją na etapie produkcji, ale późniejszego wsparcia. CM jest zazwyczaj najlepiej zaznajomioną z aplikacją osobą.
    Zarządzanie - Procedura wdrożenia aplikacji na produkcji rozpoczyna się od złożenia PM w ofierze duchom serwerów. To zazwyczaj rozwiązuje problem zarządzania. Na serio. Dobrzy PM zazwyczaj mają w życiu przygodę z kodowaniem i rozumieją na czym to polega. Problem w tym, że wielu szefów chętnie widzi na tym stanowisku gościa po Marketingu i Zarządzaniu, a nie programistę/admina. Zobacz, że największymi firmami IT rządzą programiści :)
    Harmonogramy - a czytałeś "Zdążyć przed terminem". Fajna książka z zakresu zarządzania. Samo organizacja zespołu też jest możliwa, ale wymaga by ludzie się ze sobą dogadali i nie było konfliktów.

    OdpowiedzUsuń
  2. Podoba mi się pomysł z ofiarą z PMa ;-)
    Choć akurat miałem to szczęście, że w większości projektów w których pracowałem [i pracuje :-)] PM był lub jest sensowny.

    Z dokumentacją jest ten problem, że nikt jej nie utrzymuje. Nawet jeżeli są takie wymogi. Często zmiana jednej linii kodu przekłada się na zmianę całej koncepcji i pociągałaby za sobą zmianę całej dokumentacji.

    Co do CM i ITIL to ten drugi termin jest dla mnie nieznany. Za to zauważyłem, że zwykle CMem nie jest ktoś kto zna najlepiej aplikację, ale specjalista od CMowania. W wielkich korporacjach są przecież całe działy zajmujące się Configuration Managementem, których pracownicy są "wynajmowani" do projektów. Na szczęście jak widzę coraz więcej projektów przenosi się z potężnych kolumbryn pokroju ClearCase'a na SVN'a. SVN jest gorszy, ale dużo lżejszy ;-) Np. w obecnym projekcie mamy zasadę, że aktualna praca odbywa się zawsze na trunku, a za aktualną pracę uznajemy najwyższy release który w danym momencie realizujemy, wszystkie wcześniejsze releasy dostają swoje gałęzie i na nich idzie development do releasów.

    W zarządzaniu widzę to tak, Product Manager powinien być kimś kto rozumie dziedzinę produktu, Project Manager zwykle jest niepotrzebny ;-), do tego powinien być development lead i test lead, a im coś większe to przyda się jeszcze architekt. Z tych wszystkich stanowisk nietechniczny może i powinien być tylko product manager.

    Nie czytałem "Zdążyć przed terminem", ale widać trzeba będzie sięgnąć :-)

    OdpowiedzUsuń