Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Zła organizacja w dobrych projektach

Rafał Kotusiewicz Co-Owner / nexonIT
Dowiedz się, jak uniknąć czterech krytycznych błędów organizacyjnych w projektach, na podstawie realnych doświadczeń.
Zła organizacja w dobrych projektach

W pierwszej części opisałem cztery główne powody, dla których projekty szybują wprost do kosza (to oczywiście tylko moja opinia, powzięta na podstawie obserwacji). W tej części opiszę problemy natury organizacyjnej, które przewijały się niejako „przy okazji” w tekście Kiedy i czy w ogóle zatrudnić konsultanta zewnętrznego w firmie. Dwa z nich dotyczą środowiska pracy, a dwa stylu. I o ile te ostatnie są dość łatwe do zmiany, to z dwoma pierwszymi może być dość trudno walczyć.

Zaczynajmy więc, oto lista wstydu:

  1. Nazywanie stanowisk i hierarchia vs. struktura płaska
  2. Polityka ponad kompetencje i fakty
  3. Brak cyklicznego "ostrzenia siekiery", czyli brak retrospektywy
  4. Brak zarządzania wiedzą i rozwojem w zespole


Nazywanie stanowisk - hierarchia vs. struktura płaska

Obłęd dopadający (w szczególności korporacyjne) zespoły - nazywanie stanowisk „junior”, „senior”, „architect” itd.. Oczywiście jest cenne wiedzieć, kto jest kim w zespole, ale staje się to także niebezpieczne. Często za stanowiskiem idzie władza, która - jak wiemy - deprawuje.

Problem polega na niedopasowaniu człowieka do stanowiska. Osoba o niskiej samoocenie, gdy dostaje władzę, najczęściej pozbywa się osób, które mogą podważyć (choćby przypadkiem) jej rolę do wypełniania. Gdy władzę dostanie człowiek niekompetentny, szybko pozbywa się ze swojego otoczenia osób, które mogłyby te niekompetencje obnażyć. To problem zdecydowanie korporacyjny, gdzie wewnętrzne rozgrywki polityczne decydują o podwyżkach i awansach. Jeśli komuś się wydaje, że to przeszłość, to zapewniam, że tak nie jest.

Widziałem sytuację, gdy solidny developer traci pracę, żeby ukryć niedopatrzenie jednej z osób zajmujących się planowaniem pracy. Byłem także świadkiem tego, że niekompetentny kierownik zespołu rozstaje się z zewnętrznym konsultantem, gdy ten zadaje za dużo trudnych pytań o powody wybranych rozwiązań (nie wiedząc, że autorem tych potworków jest ów kierownik). Niestety, to wciąż codzienność.

Jak to powinno wyglądać?

Z moich obserwacji płaskie struktury, w których role są zmieniane w czasie i nigdy nieprzypisane pojedynczej osobie lub grupie osób, mają tendencję do rozwijania kompetencji zespołowych. Co oczywiste, nowa osoba, która zostaje architektem, uczy się od swoich poprzednich (niejako staje na ramionach gigantów :)), ale jednocześnie wnosi coś od siebie. Często coś więcej niż nowe spojrzenie. W takich zespołach juniorzy rozwijają się szybko i stają  się pełnoprawnymi programistami, mającymi nawyk samodoskonalenia i dzielenia się wiedzą w grupie.

REASUMUJĄC: Nie rozdzielaj ról w zespole na stałe, niech będą one przechodnie. Stawiaj na płaską strukturę, inicjując samodoskonalenie w zespole.


Polityka ponad kompetencje i fakty

Pozostajemy w świecie korporacji. Polityka to słowo często przewijające się w korporacyjnych dokumentach. Każdy aspekt pracy korporacji opisuje jakiś dokument z polityką w tytule, np. „Korporacyjna polityka zatrudnienia”, „Korporacyjna polityka równości płci” itd… Ich istnienie oczywiście nie jest złe (często wprost koniecznie), jednak za wspomnianymi „politykami” często idą niezbyt rozsądne decyzje. Czasami są one po prostu uzasadnieniem prywatnych porachunków lub po prostu zasłonami ukrywającymi czyjąś niewiedzę. Jak to wpływa na konkretne projekty?

Istnieje w świecie zarządzania projektami pojęcie „liczby autobusu”. Jakkolwiek brzmi dziwacznie, to ma sens. Chodzi o liczbę osób z projektu, które musiałyby zginąć w wypadku autobusu, która doprowadzi do tego, że projekt nie może być kontynuowany ze względu na brak wiedzy projektowej. Im liczba ta jest wyższa, tym oczywiście lepiej. Jak ma się to do polityki? Rozgrywki polityczne w korporacji często doprowadzają do gwałtownej wymiany kadry projektowej. W połączeniu z „niską liczbą autobusu” doprowadza to do rozmywania się wiedzy projektowej i - w wyniku tego - degradacji jakości. A to z kolei prowadzi wprost na śmietnik historii.

REASUMUJĄC: Trudno tutaj dać radę wprost skierowaną do programistów. Jedyna, która ma sens, to: unikaj zespołów, w których polityka jest ważniejsza niż kompetencje. Jeśli dostrzeżesz, że coś takiego ma sens, rozejrzyj się za nową pracą.


Brak cyklicznego "ostrzenia siekiery", czyli brak retrospektywy

Tylko na krótkich dystansach można biec bez oglądania się za siebie. Dłuższy bieg wymaga spojrzenia wstecz i przeanalizowania przebytej drogi, aby kolejne kroki stawiać świadomie. Może ta metafora jest trochę naciągnięta, ale myślę, że dobrze oddaje myśl. Projekt, który trwa dłużej, niż dwa-trzy tygodnie, wymaga stałej korekty. Między innymi do tego służą retrospektywy. Pochodzą wprost z procesu zwinnego, ale nawet jeśli projekt nie jest rozwijany w takim duchu, to z retrospektyw będziemy mieli na tyle duży zysk, że warto je wprowadzić w najdrobniejszym chociaż zakresie.

W ustalonych odstępach czasu (raz na dwa tygodnie, nie rzadziej, niż raz na miesiąc) zespół (także zespoły utrzymaniowe) zbiera się na naradzie i ocenia swoje procesy i ich wykonanie. Oczywiście zaczynamy od oceny wykonania wniosków z poprzedniej retrospektywy. Czym w trakcie takiej narady należy się zająć? Oto moje propozycje:

  • Jakie problemy developerskie wystąpiły?

    Dzięki odpowiedzi na to pytanie dowiemy się, gdzie (jeśli w ogóle) trzeba zmienić strukturę lub architekturę aplikacji, żeby łatwiej pracowało się z nią w przyszłości.
  • Jakie problemy wystąpiły podczas deploymentu?

    Dzięki odpowiedzi na to pytanie poznamy rozbieżności pomiędzy środowiskami (dev & test & prod) lub braki w skryptach.
  • Jakie pojawiały się problemy podczas code review?

    Odpowiedź na to pytanie pozwoli z kolei popracować nad spójnym rozumieniem aplikacji lub całego systemu oraz wyrównać wiedzę i umiejętności w obrębie zespołu.
  • Jakie inne niedogodności wstrzymywały lub po prostu utrudniały pracę?

    Tutaj nic nie trzeba wyjaśniać.


Nie traktujmy tych retrospekcji jak prawdziwie scrumowych. W zależności od wielkości zespołu taka retrospektywa powinna zająć od 30 minut do kilku godzin. To oczywiście są koszty. Odpowiedzi, które się pojawią podczas takich spotkań, wygenerują kolejne koszty. Są to jednak niewielkie koszty w porównaniu do tych, które pojawią się, jeśli ciągłe udoskonalanie zostanie zaniechane w ogóle.

REASUMUJĄC: Korzystaj z możliwości cyklicznej refleksji nad środowiskiem pracy i samym projektem oraz zespołem, aby ciągle doskonalić proces wytwarzania.


Brak zarządzania wiedzą i rozwojem w zespole

To właściwie dwa różne problemy. Pierwsza część zarządzanie wiedzą dotyczy wprost samego projektu. W idealnych sytuacjach wiedza o projekcie jest dobrze opisana w dokumentacji (np. strona wiki projektu) i na bieżąco aktualizowana. Braki w tej materii sprawiają, że osoby dołączające do zespołu muszą tę wiedzę odkrywać i po prostu odrywać od zajęć pozostałych członków zespołu. Czasami zdarza się coś przegapić, co sprawia, że jakaś informacja znika wraz z członkami opuszczającymi zespół (wracamy do koncepcji „liczby autobusu”).

Drugi rodzaj wiedzy to wiedza, która pozwala lepiej rozwijać projekt. Innymi słowy - nieustanne podnoszenie kompetencji zespołu. Robimy to na kilka sposobów (sprawdź także wcześniejszy fragment o hierarchii): inwestując w literaturę w formie papierowej - książki na półce są świetną inspiracją lub dostęp do serwisów pozwalających czytać książki online (właściwie większość wydawców oferuje taką usługę), a także organizując warsztaty, szkolenia i hackatony.

Brak rozwoju sprawia, że programiści odczuwają nudę i tracą skupienie. Podam przykład - uczestniczyłem w projekcie, który powstał jako mały proof of concept napisany przy użyciu Javy i Springa. Po drodze zmieniło się tak wiele rzeczy wokół, że dziś jest to konglomerat mniejszych projektów napisanych w różnych językach (Java, Scala, Clojure, Go, Elixir). Nie byłoby to możliwe, gdyby nie ciągłe dbanie o aktualność kompetencji w zespole (choćby małym, jak w tym konkretnym przypadku) i tzw. „trzymanie ręki na technologicznym pulsie”.

REASUMUJĄC: Zawsze szukaj lepszego rozwiązania (pamiętając jednak o złotej zasadzie done is better than perfect), zawsze szukaj okazji do nauki i rozwijania kompetencji swoich i kolegów z zespołu. Każde nietypowe rozwiązanie w projekcie dokumentuj w wiki i wracaj do niego regularnie, aby sprawdzić, czy nie da się czegoś uprosić.


Podsumowanie

Pracuję już długo i widziałem naprawdę dziwne rozwiązania. Miałem też okazję obserwować, do czego prowadzi stosowanie niewłaściwych praktyk, w jaki sposób degradują się projekty prowadzone wbrew zdrowemu rozsądkowi i jak rozpadają się zespoły, na które wpływ ma polityka, a nie kompetencje.

Im więcej dziwacznych rozwiązań w projekcie tym trudniej go rozwijać. Większym problemem staje się znalezienie kompetentnych osób, które zechcą do niego dołączyć. Gdy już się znajdą, to onboarding okazuje się sporym wyzwaniem (dobry onboarding to kolejny temat zasługujący na oddzielne omówienie). Gdy inżynierowie po kilku miesiącach od dołączenia do projektu rezygnują, to dość jasny sygnał, że coś złego się dzieje. Warto wtedy zatrzymać się i przyjrzeć projektowi, zespołowi czy procesom w ogóle i poszukać przyczyny. Im później się za to zabierzemy, tym mniejsza szansa, że uda się uratować projekt (lub zespół).

Podziękowania kieruję do wszystkich zespołów, z którymi pracowałem, za zaufanie i cierpliwość przy wyjaśnianiu zawiłości czegoś, co powinno być proste, a także za inspirację do lepszej pracy i ciągłego doskonalenia. Z tego miejsca przepraszam także wszystkich, którzy poczuli się urażeni moim słowami, że ich rozwiązania są do ... Jednocześnie swoje zdanie podtrzymuję :)


Książki warte uwagi:

  • R. Martin “Czysty kod”
  • R. Martin “Czysta architektura”
  • J. Bloch “Java. Efektywne programowanie”
  • E. Gamma, R. Helm, R. Johnson, J. Vlissides “Wzorce projektowe”
  • J. O. Coplien, G. Bjornvig "Architektura Lean w projektach Agile "
  • J. Jettka “Bez hierarchii” (ciekawe spojrzenie na koncepcję struktury organizacji nie opartej na hierarchii… plusy i minusy - chociaż głównie plusy)
  • B. W. Fitzpatrick, B. Collins-Sussman “Debugging Teams” (o rozwiązywaniu problemów w pracy zespołowej, komunikacji, przywództwie… niewielka książka niosąca ze sobą mnóstwo wartości)
  • J. Spolsky “Programista poszukiwany” (klasyka, sporo mówi o wyszukiwaniu odpowiednich osób do zespołu)


Jest ich znacznie więcej. Bądź czujny, szukaj nowych pozycji, sprawdź co czytają inni, czytaj, wyciągaj wnioski, dziel się nimi i dyskutuj. Doskonałość to proces, a nie chwila w czasie.

Zobacz więcej na Bulldogjob

Masz coś do powiedzenia?

Podziel się tym z 80 tysiącami naszych czytelników

Dowiedz się więcej
Rocket dog