Strona główna > Gry i konsole, Informatyka i Zarządzanie, Słówka > O zarządzaniu projektami i nonsensach korporacyjnych

O zarządzaniu projektami i nonsensach korporacyjnych

Inspiracją do powstania tej notki był kolejny, świetny, wpis Jacka Wesołowskiego prowadzącego bloga Inżynieria Wszechświetności. Autor jest zawodowym projektantem gier komputerowych i zdaje relacje z tegorocznej Game Developers Conference odbywającej się w San Francisco. Jako człowiek z branży miał okazję być tam osobiście i opisał najciekawsze, jego zdaniem, fragmenty z prelekcji w których uczestniczył. Ponieważ pod zawartymi tam spostrzeżeniami i wnioskami mógłbym podpisać się obydwoma rękoma postanowiłem przytoczyć te najbardziej ogólne z nich, które można zastosować nie tylko do środowiska game developerów ale do wszelkich projektów informatycznych. Dodałem do nich kilka własnych przykładów i komentarzy bazujący na swoich doświadczeniach.

Jeżeli więc chcecie dowiedzieć się czegoś o tworzeniu zespołów, znaczeniu ich stabilności, współczynniku autobusowym, kiepskim pomyśle na wykorzystanie rozkładu Gaussa, a ostatecznie o kontekście i jego znaczeniu dla wiedzy, zapraszam do dalszej części wpisu.

Pierwszy z fragmentów, który zamierzam przytoczyć i skomentować, jest wypowiedź Nathana Martza z Double Fine dotycząca budowania zespołów.

Zalecił, by tworząc zespół skupić się przede wszystkim na zatrudnianiu właściwych ludzi: niekoniecznie najbardziej doświadczonych czy utalentowanych, za to najlepiej dopasowanych. Gdy zachowa się w tym względzie odpowiednio ścisłą dyscyplinę, powstaje zespół zdolny do podejmowania zgodnych, wspólnych decyzji, nierozsadzany konfliktami.

Dla zobrazowania tego twierdzenia posłużę się przykładem z autopsji dotyczącym 2 teamów. Zespół A jest zarządzany “silną ręką”, a dobór liderów podzespołów oparty jest na ich charyzmie. Zespół B to z kolei ludzie, którzy byli dobierani pod kątem przypasowania do będących już w zespole ludzi, gdzie konkretne umiejętności techniczne nie były kluczowe (wynikało to z faktu, że i tak mało kto znał technologię, którą się tam posługiwano) stawiano raczej na ogólną chęć zdobywania wiedzy, możliwość adaptacji oraz bezproblemową komunikację interpersonalną.

Jakie były konsekwencje pracy tych ekip? Zespół B, pomimo zmian składu wynikających z naturalnych rotacji, potrafił funkcjonować przez długi okres praktycznie bezkonfliktowo, co przekładało się na bardzo dobrą atmosferę w pracy i efektywne wyniki pomimo dosyć wymagającego środowiska, napiętych terminów i nie zawsze wystarczającej liczby zasobów. Udało się to osiągać rzadko doprowadzając do przeciążenia teamu.

Zespół A natomiast, pomimo świetnych specjalistów nie potrafi działać efektywnie. W celu poprawienia komunikacji postanowiono generować coraz to większą liczbę spotkań, które w założeniach miały doprowadzić do dyskusji i wspólnego konsensusy. Niestety ponieważ poszczególni liderowie posiadają cechy dominujące, ostatecznie prowadzi to do niekończących się kłótni polegających, nie na słuchaniu argumentów innych i wspólnym ustalaniu priorytetów, ale na przeciąganiu korzyści na swoją stronę za wszelką cenę.

Przykład z życia wzięty. Powstaje nowy produkt P, który ma za zadanie pomóc kilku innym zespołom w zautomatyzowaniu ich pracy. Zespół X nagle chce funkcję, której zaimplementowanie wymaga dużego nakładu pracy i z punktu widzenia innych zespołów nie wnosi nic innego oprócz niepotrzebnej komplikacji produktu P, natomiast dla zespołu X nagle stał się on kluczowy i nie pozwalający na wykonywanie ich codziennej pracy… podczas gdy do tej pory – przed powstaniem produktu P – i tak musieli ją wykonywać.

Brak zwykłej, dobrej woli i przełożenia swoich wymagań na późniejszy okres, doprowadza do nieefektywnej pracy kilku innych grup i straty czasu na kolejne spotkania synchronizacyjne (które zaczynają wypełniać większość tygodniowego czasu pracy dużej grupie osób).

Następny temat to stabilność czyli kolejna cecha o której zapomina spora liczba menadżerów.

Stabilność studia Martz zdefiniował jako zdolność do pracy w stałym tempie przez nieskończenie długi czas. Przeciwstawił ją zdolności do heroicznych zrywów, które przynoszą korzyści na krótką metę, ale trwale rujnują zespół.

Dosyć często spotykany problem, szczególnie u kierowników wyższego szczebla, którzy nieustannie próbują wycisnąć „maksa” z aktualnie posiadanych zasobów nie zdając sobie sprawy, że na dłuższą metę doprowadzają do pogorszenia atmosfery w zespole. Skutkuje to spadkiem jego motywacji i wydajności. W dalszej kolejności dochodzi do opuszczania teamu przez kolejne, często doświadczone osoby, co prowadzi do zwiększenia kosztów związanych z rekrutacją nowych, świeżych ludzi, a następnie wyszkoleniem i wdrożeniem ich do projektu. Summa summarum zamiast mieć stały, doświadczony, dobrze zorganizowaną zespół, co chwilę trzeba tracić czas i pieniądze na uzupełnianie składu.

Biorąc pod uwagę fakt, że możliwości pracy dla informatyków aktualnie są bardzo duże (w porównaniu do innych zawodów) zniechęcanie do swojej firmy ludzi nie jest dobrą strategią długoterminową.

Oczywistością wydaje się kolejny z przytoczonych fragmentów, choć po raz pierwszy spotkałem się z jego nazwaniem, a chodzi o:

…współczynnik autobusowy, czyli liczbę osób niezastąpionych, których nagła utrata (na przykład na skutek przejechania przez autobus) sparaliżowałaby zespół. Oczywiście współczynnik ten należy starać się sprowadzić do zera.

Tutaj przypomina mi się zasłyszany przypadek z jednego z największych polskich serwisów społecznościowych, gdzie to firma postanowiła zwolnić admina ponieważ nie zgodziła się na jego nowe warunki finansowe. Po dwóch tygodniach musiała zmienić zdanie gdyż nikt nie potrafił przejąć jego obowiązków będących kluczowymi dla działalności tej organizacji.

Skoro już pastwię się nad organizacjami kilka słów jeszcze o HR (human resources) czyli dziale kadr. W dużych korporacjach często przeprowadzana jest okresowa ocena pracownika. Problem, który w niej występuje bazuje na statystycznym podejściu do tego procesu. Np. że w każdym zespole musi znaleźć się 10% pracowników, którzy podlegają najniższej ocenia, co dla takiego delikwenta skutkuje np. brakiem podwyżki lub znacznie obniżoną premią.  Niestety, w praktyce prowadzi to niejednokrotnie do takiej sytuacji, że w 10 osobowym zespole, gdzie każdy przykłada się do pracy, kierownik musi wytypować jedną osobę, której postawi taką ocenę “na siłę”.

Nie muszę chyba mówić jak “motywująco” działa to na pracownika oraz na resztę zespołu, który niezależnie jak dobrze wykonuje swoją pracę musi poddać się odgórnej statystyce.

“Na pocieszenie” mogę powiedzieć, że w innej bardzo znanej informatycznej korporacji, podobno (takie słyszałem pogłoski) znalezienie się w X% najsłabiej ocenionych pracowników skutkuje utratą pracy.

Na zakończenie pozostaje bardzo dobre podsumowanie wpisu Jacka.

GDC nie powiększyło znacząco posiadanego przeze mnie zasobu informacji, ale to, co już wiem, wyposażyło w nowe konteksty. Kontekst jest właśnie tym, co zmienia informację w wiedzę.

Wszystkie z przytoczonych w tym tekście prawdy są powszechnie znane, i mam nadzieję menadżerowie są ich uczeni (nie mam wykształcenia menadżerskiego ale zakładam, że tak jest). Jednak jak pokazuje praktyka w wielu organizacjach tak oczywiste prawdy, wydają się nie być znane, a na pewno nie stosowane.

Co chwila zaskakuje mnie natomiast jak to możliwe, że te organizacje nadal funkcjonują…

Zachęcam do zapoznania się z oryginalnym źródłem inspiracji dla tej notki na “Inżynierii Wszechświetności”.

Reklamy
  1. 7 kwietnia 2013 o 12:03

    Z terminem „bus factor” pierwszy raz spotkałem się czytając książkę „Team Geek” (http://shop.oreilly.com/product/0636920018025.do – gorąco polecam). To niesamowite jak wiele projektów funkcjonuje ze współczynnikiem autobusowym równym 1, w przeszłości zdarzało mi się nawet być tą jedną osobą. Z punktu widzenia pracownika miewa to swoje plusy ;), z punktu widzenia projektu to katastrofa.

    • 7 kwietnia 2013 o 12:17

      O dzięki za linka… właśnie zastanawiałem się skąd pochodzi to pojęcie.

  2. 7 kwietnia 2013 o 12:09

    Jeśli zaś mowa o budowaniu zespołu, to uważam, że to nadmierne uproszczenie tematu – zespół zgrany, ale ogólnie mierny jeśli chodzi o poziom umiejętności, nie jest wiele lepszy od teamu który zawiera kilku „developerów alfa” 😉 Oczywiście osoby o niewielkich kompetencjach i rozbuchanym ego są najgorszym, co może się zespołowi przytrafić.

    • 7 kwietnia 2013 o 12:20

      Ok, masz rację nie można popadać w skrajności i pewien stopień kompetencji jest wymagany ale chodzi i większy nacisk na pracę zespołową niż pojedyncze umiejętności. Generalnie dobrze jest mieć kilku wymiataczy w teamie 😉
      No i zazwyczaj da się znaleźć osoby które są wystarczające dobre, które potrafią dogadać się z resztą zespołu zamiast super wymiatacza który jest sobie panem, sterem, okrętem…

  1. No trackbacks yet.

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Wyloguj / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Wyloguj / Zmień )

Connecting to %s

%d blogerów lubi to: