Nie wierzcie w osobomiesiące
Od dłuższego czasu czytam regularnie
[joelonsoftware.com](joelonsoftware.com). Joel Spolsky jest
właścicielem niewielkiej firmy programistycznej w Nowym Jorku; na
swoich stronach www pisze na różne tematy dotyczące tworzenia
oprogramowania – o projektowaniu, interfejsach użytkownika,
szacowaniu czasu, wyznaczaniu cen i innych przydatnych sprawach.
Dwa dni temu opublikował nowy artykuł, ["Hitting the high
notes"][hitting], o oszczędzaniu poprzez zatrudnianie tańszych
programistów. W skrócie:
1. Różnice produktywności w grupie programistów potrafią być ogromne.
Ta informacja, nawet poparta bardzo wiarygodnymi danymi, jeszcze
nie jest niczym odkrywczym, pisał już
o tym Brooks w "The Mythical Man-Month" (["Mityczny
osobomiesiąc"][tmmm_pl]) i Lister z DeMarco w "Peopleware"
(["Czynnik ludzki: Skuteczne przedsięwzięcia i wydajne
zespoły"][pw_pl]). Co jest ciekawsze, to że nawet jeśli
ograniczymy grupę do programistów tworzących kod najlepszej
jakości (w artykule – górne 25% studentów), to różnice w
produktywności będą podobne.
Najszybsi potrafią pracować ponaddziesięciokrotnie szybciej od
najmniej wydajnych pracowników. I nie chodzi o tempo produkowania
kolejnych linii kodu, ale o czas potrzebny na rozwiązanie tych
samych zadań.
2. Programiści różnią się nie tylko produktywnością. Ważna jest
też kreatywność, talent, zdolność rozwiązywania problemów
z którymi nie zetknęli się wcześniej. Pomysłowość dziesięciu
marnych programistów nie zastąpi jednego, bardzo dobrego.
Oba punkty są bardzo istotne. Z pierwszego wynika, że nie warto
oszczędzać zatrudniając większą grupę gorszych programistów, nawet
jeśli zignorować fakt że rosną wtedy koszty komunikacji między nimi.
Różnice w wydajności znacznie przewyższają różnice w wynagrodzeniach
– według [raportu serwisu wynagrodzenia.pl][wynagrodzenia] najwyższe
wynagrodzenie jest mniej więcej pięciokrotnie wyższe od najniższego w
tym samym mieście. Ale to tylko jeśli wrzucić wszystkie firmy do jednego worka; jeśli ograniczymy się tylko do firm o podobnej wielkości, poniżej 30 osób,
z polskim kapitałem, to różnica w Warszawie jest trzykrotna.
Do drugiego punktu niewiele można dodać. Tworzenie oprogramowania to
nie jest praca fizyczna, tu nie chodzi o przeniesienie sterty śrubek z
jednego końca hali produkcyjnej na drugi. Rzadko sprawdza się podział
na "ludzi z pomysłami" i "ludzi do pracy", bo przytłaczająca większość
pracy nie wymagającej kreatywności została już dawno przerzucona na
maszyny.
Z tych informacji wynika jeszcze jeden wniosek, na inny temat niż artykuł Joela:
ostrożnie z szacowaniem czasu. Zgadywanie, ile czasu może komuś
innemu zająć zaimplementowanie danej funkcjonalności na podstawie
własnych doświadczeń jest zawsze ryzykowne, chyba że jest to osoba
bardzo dobrze znana albo dopuszczalne jest założenie marginesu
bezpieczeństwa nawet dziesięciokrotnie większego od początkowej oceny.
A już bardzo złym pomysłem jest wycenianie projektu bez wiedzy kto
będzie go realizował.
[Nie wierzcie w osobomiesiące][tmmm_pl].
[hitting]: http://www.joelonsoftware.com/articles/HighNotes.html
[tmmm_pl]: http://www.wnt.pl/wnt/ksiazki.nsf/uid/000216103245CBAMR4GKD88?OpenDocument
[pw_pl]: http://www.wnt.pl/wnt/ksiazki.nsf/uid/050204134508wPROS69AGY8?OpenDocument
[wynagrodzenia]: http://wynagrodzenia.pl/index.php?page=article&id=754
O autorze: nazywam się Marcin Kaszyński i od ponad 10 lat zajmuję się tworzeniem oprogramowania, od projektowania przez programowanie do zarządzania projektami włącznie. Prowadzę warsztaty Django, będące szybkim i łatwym sposobem na poznanie tego środowiska i rozpoczęcie pracy z pełnym wykorzystaniem jego możliwości.
