Battle for Agility

Zamach na zespoły?

November 6th, 2006 Marcin Niebudek

Od dłuższego czasu obserwujemy wzmożony wzrost popularności zjawiska nazywanego “leasingiem pracowniczym”. Mam nawet wrażenie (być może związane tylko z lokalnym rynkiem IT, z jakim mam kontakt), że firm wynajmujących programistów jest już więcej niż firm tworzących oprogramowanie na własne potrzeby. Wynajmują pracowników duże korporacje, wynajmują banki.

Kiedyś wystarczał “outsourcing” samej usługi do firmy zewnętrznej. Teraz firma IT ma fizycznie wstawić swoich pracowników do firmy klienta na kilka tygodni/miesięcy, żeby tam w ramach zespołu klienta wykonali (czy raczej podgonili) jakąś część projektu. Co to wszystko ma wspólnego z agile? No więc dla mnie agile to między innymi silne zespoły. Silne ze względu na swoją niezależność, samowystarczalność, zdolność adaptacji i utrzymania wysokiej jakości produktów - takie samojezdne, samonapędzające się machiny do zadań specjalnych. Tylko co dzieje się z zespołami kiedy zaczynamy fizycznie delegować naszych pracowników? Co z wydajnością takich zespołów. Co z jakością ich pracy?

Popularność leasingu/wynajmu pracowników ma kilka dość łatwych do odgadnięcia powodów. Od strony klienta to pewna mutacja outsourcingu z tą małą różnicą, że skoro wynajmuje firma IT, to woli dostać ludzi, nad którymi będzie miała kontrolę zamiast podpisywać kontrakty na wykonanie podsystemu i kontroli nie mieć. Posiadanie dodatkowych ludzi, których po skończonym projekcie/etapie można odesłać do ich własnej firmy pozwala ograniczyć koszty utrzymywania własnego rozbudowanego zespołu IT na stałe, ale także jest chyba mniej ryzykowne niż tradycyjny outsourcing.

Powodami ekonomicznymi kieruje się zapewne także firma wynajmująca swoich ludzi. Coraz trudniej jest znaleźć wykwalifikowanych i doświadczonych pracowników, więc wrosła cena pracy programistów, a skoro tak, to pojawiło się dużo firm, które z tej “górki” chcą w prosty sposób wziąć coś dla siebie. Często firmy działające jako tradycyjne software house są narażone na chwilowy przestój w zleceniach, co powoduje, że mają część zespołu, który przez moment może nie mieć co robić. Wtedy lepiej wynająć tych ludzi (i przy okazji na tym zarobić) niż ponosić koszty trzymania pracowników przez ten jałowy okres, czy zwalniać ich (bo potem będzie problem z odbudową zespołu).

Wydaje się, że nie ma co polemizować z takimi przesłankami. Ciekaw jestem tylko czy wynajmując programistów, osoby za to odpowiedzialne rozważają następujące czynniki:

Czas aklimatyzacji programisty w zespole. Tworzenie oprogramowania nie jest czynnością mechaniczną tylko umysłową. Ĺťeby ją wykonywać człowiek musi mieć do tego odpowiednie warunki i predyspozycje. Pisali o tym już DeMarco i Lister w “Czynniku ludzkim” (ang. tytuł: Peopleware), przypominał także ostatnio na JDD2006 Bruce Eckel - programistów nie można dowolnie między sobą wymieniać. Ponadto każdy programista ma zupełnie inną wydajność w pierwszym tygodniu pracy, a inną po miesiącu. A czy wynajmując pracownika różnicuje się stawki w zależności od jego “stażu” w nowym miejscu pracy? Zatrudniając pracownika na stałe ponosimy koszt aklimatyzacji raz. Okresowo wynajmując pracowników koszt jest częstszy chyba, że mamy szczęście wynajmować za każdym razem tych samych ludzi.

Konflikt interesów. Cele pracownika wynajmowanego nie są zgodne z celami firmy klienta. W interesie klienta jest szybkie zakończenie pracy, ale dłuższy czas gra na korzyść firmy wynajmującej pracownika, bo przecież wystawi ona fakturę za czas wynajęcia a nie za zadania (zadania to już sprawa klienta). Oczywiście aby firma świadcząca usługi wynajmu programistów mogła się utrzymać u klienta i liczyć na kolejne zlecenia, musi zapewnić odpowiedni poziom kwalifikacji swoich pracowników. Wydaje mi się jednak, że siłą rzeczy nie osiągną oni w swojej pracy 100% tego co mogliby osiągnąć dla swojej firmy, w swoim zespole. A co jeśli będą mieli nawet polecenie “z góry”, żeby się specjalnie nie spieszyć, bo są w końcu zatrudnieni na godziny. Ten konflikt interesów wydaje mi się najpoważniejszą wadą w stosunku do tradycyjnego modelu outsourcingu, gdzie na czasie zależy zarówno zleceniodawcy jak i wykonawcy, a wszyscy pracują u siebie.

Ograniczona odpowiedzialność. Wpuszczamy do firmy programistów z zewnątrz, którzy niedługo nas opuszczą i pójdą do innych firm. Siłą rzeczy ograniczamy im możliwość podejmowania jakichkolwiek istotnych decyzji, ograniczamy dostęp do pewnych krytycznych dla firmy zasobów itd. To ogranicza im swobodę tworzenia oprogramowania, do którego ich zatrudniliśmy. Taka sytuacja albo spowoduje przestoje w ich pracy, albo zaangażuje dodatkowo członków naszych rodzimych zespołów pogarszając ich wydajność. No bo skoro tamci nie mają prawa wykonać pewnych rzeczy, to ktoś inny będzie to musiał zrobić w ich imieniu. Czy w rachunku ekonomicznym bierzemy pod uwagę takie koszty? Jak je uwzględnić? Taka organizacja pracy przeczy zasadzie samo organizujących się zespołów (chyba, że ich kierownik w firmie klienta pozwoli im się organizować w ramach ich ograniczonych możliwości). Z resztą chyba najczęstszym podejściem zarządzającego takim zespołem będzie jednak ścisła kontrola poczynań jego członków. Widzę tutaj także istotny problem umotywowania takich ludzi do pracy, skoro są niejako pracownikami trochę gorszej kategorii.

Podkopywanie własnych zespołów. Jeśli zamiast tworzyć z wynajętych programistów odrębnego zespołu wcielimy ich do istniejących u nas zespołów, to po pierwsze zadziałają efekty przytaczane przez Brooks’a w “Mitycznym osobomiesiącu” - nasi ludzie zamiast zajmować się pracą zaczną zajmować się nowymi ludźmi. Poza tym jeśli mamy w zespole programistów “tymczasowych”, to możemy mieć do czynienia z sytuacją, kiedy zespół nie będzie chciał wziąć odpowiedzialności za kod ludzi z zewnątrz. Z resztą tymczasowi pracownicy także nie są skłonni do przyjmowania celów grupy jako własnych. A wspólna własność kodu to jedna z ważnych i wartościowych zasad stosowanych w praktykach agile. Ludzie będą raczej mieli skłonność do obwiniania tych, których nie ma już w firmie, za wszelkie zło w projekcie. Oczywiście ta sama zasada wspólnej własności kodu mogłaby pomóc w tym przypadku, ale jakoś ciężko mi to sobie wyobrazić.

To pewnie tylko kilka sytuacji, jakie mogą się wiązać z nowym pomysłem na życie coraz większej liczby firm w naszej branży. Wydaje mi się, że jest to jeden z trybów pracy jaki wyjątkowo nie sprzyja używaniu agile. Ale może się mylę i da się agile pogodzić czy wręcz wykorzystać na korzyść leasingu programistów (o czym chętnie usłyszę). Tymczasem namawiam do inwestycji we własne zespoły, bo silny kilkuosobowy zespół da radę dużo większej liczbie często przypadkowych ludzi.

Dobrze byłoby gdyby przynajmniej rachunek zysku i strat nie ograniczał się wyłącznie do przeliczenia stawki godzinowej, ale uwzględniał także tą drugą stronę medalu.

Kategorie: Agile dla managerów

(2 votes, average: 4.5 out of 5)

Loading ...

7 komentarzy Dodaj komentarz

1. Jacek Rybicki | November 7th, 2006 at 22:39

Twoje spostrzeżenia są bardzo trafne, co może potwierdzić każdy pracownik firmy zajmującej się bodyshopping. Najbardziej mnie zaskoczyło to, że przedstawiłeś na początku obserwację przeciwną temu z czym ja się ostatnio spotykam. W moim “ogródku” odchodzi się od handlu ciałami na rzecz przejmowania całych kontraktów do siebie. Ale nie słyszałem motywowania tego czymś innym niż względy ekonomiczne.

Ĺťeby zilustrować opisane przez Ciebie przemyślenia:
Wyobraź sobie jakie uczucia może w Tobie wzbudzić współpracownik, który pochodzi z obcego kraju, mówi w innym języku (np. po angielsku i przez którego trzeba się wysilać na spotkaniach). Do tego nie zna zwykle dokładnie kultury firmy, procedur pracy, może w każdej chwili zmyć się (kontrakty kończą się “bo tak wynika z planu który obowiązuje od wczoraj”) i zostawić Ciebie z tym co namieszał. I na dodatek zarabia więcej od Ciebie :)

A druga strona? Jesteś na wyjeździe o którym dowiedziałeś się trzy dni przed wylotem. Pracujesz z ludźmi którzy nie zawsze rozumieją słowo “network”, nazywają zmienne w kodzie z użyciem znaków diakrytycznych swojego języka, którzy mają motywację do tego żeby zrzucić na ciebie odpowiedzialność za swoje błędy - bo przecież kogo w pierwszej kolejności wysłucha przełożony? (pół biedy jeżeli wiesz kto jest twoim przełożonym). Siedzisz przy wejściu z korytarza, tak żeby przechodziło obok ciebie jak najwięcej ludzi. Dowolnego dnia możesz dowiedzieć się że jutro wyjeżdżasz, a firma macierzysta stara się nie interesować tobą bardziej niż to abslutnie konieczne do dotrzymania warunków kontraktu.

Jak to możliwe że takie rozwiązanie jest w ogóle przyjmowane przez firmy? Przede wszystkim menedżerowie nie starają się budować zespołów, ale wyrobić odpowiednią ilość osobomiesięcy ;) No może nie zawsze jest tak strasznie. Przecież nie jest rozsądne zakładanie że planiści są bezmyślni. Pracownik wynajmowany ma swoje ogromne zalety.
Przede wszystkim w rozrachunku jest tańszy i to do tego stopnia że warto zaryzykować.
Często jest to jedyny sposób na otrzymanie osoby doświadczonej w potrzebnej dziedzinie, gdy rekrutacja albo odpowiednie przeszkolenie zamują miesiące. Jeżeli jest wynajmowany często to znikają problemy ze znajomością metod pracy (można zresztą firmie wynajmującej nakazać odpowiednie przeszkolenie ludzi) i zwiększa się akceptacja w zespole. Z odpowiednim motywowaniem może są problemy, ale ze stałymi pracownikami wcale nie są mniejsze.

Podumowując, “a jednak się kręci” i działać będzie do czasu gdy komukolwiek będzie się opłacać. Mam na myśli robienie bilansu przez ludzi którzy nigdy nie rozmawiali z programistami (bo i po co), może nie zdają sobie sprawy ze szczegółów mechanizmów które działają w zespołach, ale widzą najróżniejsze wyniki. Ogromne wady są rekompensowane przez ogromne zalety.

W przypadku wyboru formy ałtsorsingu wydaje mi się że można przyjąć następujący wzór:
- jeżeli firma ma sprawne procedury produkcji, bez niepotrzebnej nadbudowy, kierujący projektami wiedzą jak to robić (i czytali ksiązki deMarco /Lister ;) to najlepszy jest bodyshopping - pracownik przeniesiony z gorszego środowiska często doszlusuje w górę (albo szybko będzie można się go pozbyć), a ten z lepszego też sobie poradzi ;)
- jeżeli firma jest zesztywniała w swoim wyrafinowanym procesie produkcji, z wielopoziomowym zarządzaniem, z brakiem przepływu informacjami pomiędzy działami które muszą ze sobą współpracować, to lepszym rozwiązaniem wydaje się zlecenie wykonania na zewnątrz - o ile znajdzie się wystarczająco pewny dostawca, co nie jest wcale proste. Poza tym jest nadzieja że w tej drugiej (często mniejszej) firmie stosuje się praktyki agile na poziomie zapewniającym pewne terminy dostaw i ogólną niesamowitą satysfakcję ;)

pozdrawiam,
2. Marcin Niebudek | November 13th, 2006 at 22:05

Nieco późno się obudziłem z odpowiedzią, ale cóż :-)

Zgadzam się, że wynajęcie pracownika ma sens w przypadku trudno dostępnych specjalistów, chociaż tutaj już raczej mówi się o consultingu (o ironio :-). To jest chyba tak, że sama idea jak zwykle nie jest taka straszna, tylko problem jest w tym, że więcej można znaleźć przykładów jej nadużycia lub użycia przy zupełnie wypaczonych założeniach.

Niemniej jeśli, któregoś z managerów nasze przemyślenia skłonią kiedyś do zajrzenia do deMarco/Listera lub jakiejkolwiek innej książki z dziedziny, którą zajmują się na co dzień, to będę z tego niezmiernie zadowolony :-)

Zespoły przede wszystkim i do następnych wynurzeń…
3. Marek Kwiecień | November 17th, 2006 at 09:54

A ja się zgadzam z tezą o zamachu na grupy projektowe. Nie udało mi się jak dotąd pracować przy kolejnym projekcie z tymi samymi osobami co w poprzednim (no, ale przyczyn było wiele ;) ), czego czasem żałuje, a czasem nie. W praktyce największy problem w “nowym” zespole jest taki, że musisz dużo czasu spędzić, żeby poznać kolegów, ich umiejętności no i przede wszystkim ich osobowiści, które chyba są istotniejsze często niż umiejętności.
Ogólnie bardzo dużo zależy od kierownika projektu - jeśli ta osoba potrafi pociągnąć za sobą ludzi, to można bardzo dużo zrobić, ale jeśli jest to osoba, która dostała awans przez “zasiedzenie”, to raczej będzie kiepsko z zespołem tej osoby. No i są i tacy, którzy w korporacjach pną się w górę i dla nich pracownicy, to “zasoby” (o zgrozo!).
Do tej pory spotkałem tylko jednego dobrego PM-a na swojej drodze i niestety już z nim nie pracuję. A mi staranie się czasem wychodzi a czasem nie ;).
4. Thomas Ochmann | June 19th, 2007 at 22:01

Czesc,
sam jestem wlascielem firmy zajmujacejsie wynajmowaniem moich pacownikow do projektow.
Nie widze osobiscie zadnego konfliktu do metod agile.
Wrecz przeciwnie, udalo mi sie juz wrzuc do projektow od razu pracownniow parami :-) Analogicznie wyglada sprawa ze specjalistami: jesli zleceniodwca nie mysli, to sciaga sobie takowego i nie dba o to, zeby nastapil transfer know-how (co moim zdaniem jeden z atutow agil programming).

Moja rada: nie dac sie, walczyc o agility i probowac obojetnie w jakim sie projekcie znajduje przekonywac NIE kierownika zespolu programistow ALE zleconiodawce. Ci ktorzy rzeczywiscie decyduja, na co wydaja kase moim skromnym zdaniem najlatwiej rozumieja zasady agility :-)

Pozdrowienia
Thomas
5. Marcin Niebudek | June 19th, 2007 at 22:28

Ha! Ale chyba jednak mówimy o dwóch stronach barykady :-) Bo Ty dajesz pracowników, którzy używają praktyk agile i ich zadaniem (jak i Twoim) będzie przekonanie reszty zespołu u zleceniodawcy (który o agile ledwo co słyszał, a już na pewno nie używa) do przestawienia się też na te techniki. Ja natomiast mówię głównie o firmie, która tych pracowników bierze.

A co jeśli wynajmiesz ludzi do firmy, która takich praktyk nie stosuje (np. banki) i gdzie wszystko musi być oparte bardziej o model Command and Control? Jak Twoi ludzie raz zasmakują agile, to wynajęci na kontrakt do jakiegoś zastygłego molocha wrócą sfrustrowani albo odejdą.

Poza tym dla mnie istotny jest jeszcze jeden element. Większość programistów utożsamia się mocno z tym co robi, lubi widzieć w tym cel. Programista będzie także chciał widzieć realizację jakiegoś celu firmy za swoją pracą. Wydaje mi się, że praca najemna nie sprzyja w przejmowaniu takich celów i powoduje szybsze wypalanie się ludzi.

Idealnie jest kiedy firma wynajmująca pracowników i zleceniodawca używają agile. Wtedy faktycznie możesz wstawiać ludzi nawet parami do większych zespołów, a inne techniki pozwolą się tym połączonym zespołom scalić szybciej. Ale ciągle jeszcze mamy przewagę klientów nie rozumiejących agile i patrzących na firmy leasingujące pracowników jako na dodatkowych dostawców osobogodzin. A w agile liczą się ludzie i zespoły a nie osobogodziny :-)

A walczyć będę do upadłego :-)
6. Thomas Ochmann | July 17th, 2007 at 11:53

hehe,
zgadzam sie z Toby jesli chodzi o zlecniodawcow ktorzy nie wiedza o co w agile bbiega. Rowniez zgadzam sie z Toba jesli chodzi o pracownikow, ktorzy z reguly chca miec Spass=frajde podczas pracy==w projekcie.

OK, niestety prosze tylko nie zapominac o tym ze kazdy kij ma dwa konce==skad sie biora pieniazki na wyplaty….

No chyba ze zapominamy o wyplacie/osobogodzinach poniewaz mamy w jako zatrudniony w firmie XYZ w agilnym projekcie ABC tyle frajdy, ze nie potrzebujemy zarobkow ;-)))

Serdeczne pozdrowienia
oryz kupe frajdy w pracy
Thomas
7. Marcin Niebudek | July 17th, 2007 at 18:20

Oczywiście nie zapominam o pieniądzach. Tylko po pierwsze w przypadku programistów pieniądze to nie wszystko - oczywiście każdy woli zarabiać więcej jeśli może, ale wysokość wypłaty nie zawsze jest głównym czynnikiem przy wyborze pracodawcy.

Poza tym typowy leasing pracowniczy w żaden sposób nie buduje zespołu wewnątrz firmy, bo ludzie są rzucani w różne miejsca do różnych projektów i nie mają okazji popracować ze sobą. Moim zdaniem firma, która żyje głównie z leasingu pracowników korzysta tylko z chwilowej mody i popytu, ale to się skończy a firma zostanie tylko wydmuszką bez prawdziwego zespołu. Ludzie w takich firmach szybciej się wypalają i szybciej myślą o zmianie pracy. Co tylko dodatkowo odbiera wartość firmie, bo ci ludzie zabierają ze sobą to co wiedzą, a firma potrzebuje nowego mięsa armatniego, które można rzucić na front.

Utrzymanie własnego zespołu w ciekawych projektach wcale nie spowoduje, że ludzie przestaną pracować a zaczną się bawić. Wręcz przeciwnie, dobry zespół trzyma ludzi w firmie równie dobrze jak wypłata, są oni bardziej wydajni, bo lubią to co robią.

Wydaje mi się, że sam leasing podobnie jak outsourcing miał swoje źródła w tym, że była grupa firma, która nie chciała na dłużą metę utrzymywać własnego działu IT. Ale obecnie często obserwujemy pod tym samym hasłem inną praktykę - firma A ma większy problem ze zdobyciem programistów niż firma B, albo firma B już ich ma. Firma A decyduje się więc na ich wynajęcie.

Tylko wynajęty programista nie jest głupi… skoro firma A jest skłonna do zatrudniania, a wynajem jest tylko sposobem na powiększenie własnych zasobów, to po co takiemu wynajmowanemu programiście pośrednik w formie firmy B. Skoro ma on świadomość, że mógłby być zatrudniony bezpośrednio w firmie A na lepszych warunkach, to prędzej czy później nawieje z firmy B.