Często obserwuję przydzielanie ludzi do projektów za pomocą algorytmu round-robin, czyli w zasadzie losowo. Nowo rekrutowanych czy kończących inne zadania pracowników wrzuca się w projekt, w którym aktualnie jest największe zapotrzebowanie. Czy to na prawdę najlepsza metoda? Jak można to zrobić lepiej, dowiesz się z poniższego artykułu.

Model rozwoju kompetencji

Współcześnie funkcjonuje wiele różnych modeli rozwoju kompetencji. Warto wspomnieć choćby o modelu czterech etapów nabywania kompetencji. Jest on bezpośrednio powiązany z efektem Dunninga-Krugera, który w zasadzie stanowi temat na osobny wpis. Tutaj natomiast chciałbym szerzej omówić model braci Dreyfus. Zakładają oni, że możemy wyróżnić pięć poziomów kompetencji:

  1. Novice (nowicjusz)
  2. Competence (kompetentny)
  3. Proficiency (biegły)
  4. Expertise (ekspert)
  5. Mastery (mistrz)

Nowicjusz. Dopiero zaczynamy przygodę z daną dziedziną. Działamy tylko w oparciu o teorię, wymagamy pełnej dekompozycji złożonych zadań, pozbawienia ich kontekstu (do analizy którego potrzebne jest doświadczenie) i ustalenia prostych reguł działania. Wszystkie decyzje podejmujemy analitycznie, ślepo podążając za regułami. Aby się rozwijać, potrzebujemy nadzoru – zewnętrznego i/lub opartego o własne obserwacje. W IT to ktoś, kto właśnie zaczyna pierwszą pracę. Szybko dowiaduje się, że może zapomnieć o tym, co umie, bo „tam były studia, a tu jest życie”. Często nie może zrozumieć, jak baza danych może działać bez trzeciej postaci normalnej.

Kompetentny. Nabraliśmy już trochę doświadczenia. Nadal, podobnie jak nowicjusz, decyzje podejmujemy analitycznie, wymagamy nadzoru i dekompozycji złożonych zagadnień, ale uczymy się już dobierać reguły w zależności od sytuacji oraz aplikować powtarzalne wzorce. W środowisku pilotów mówi się, że gdy zaczynamy latać, mamy dwa worki – pusty z doświadczeniem i pełny ze szczęściem. I cały problem polega na tym, żeby napełnić worek z doświadczeniem, zanim opróżni się ten ze szczęściem. W IT osoby kompetentne często są podatne na wpływ prostych przykładów i konferencyjnych prezentacji. Ponieważ nie znają szerszego kontekstu, nie potrafią przewidzieć długoterminowych konsekwencji podejmowanych decyzji. „Wdrożyłem transakcje rozproszone, bo na prezentacji człowiek mówił, że rozwiążą wszystkie nasze problemy”.

Biegły. Żadna typowa sytuacja nie jest już dla nas zaskoczeniem. Potrafimy odnaleźć się w zmieniających się okolicznościach. W IT oznacza to, że zaczynamy myśleć długofalowo. Wiemy, że pisanie testów i wykorzystanie architektury hexagonalnej szybko przyniesie wymierny efekt.

Ekspert. Nareszcie decyzje zaczynamy podejmować intuicyjnie. Do gry weszła pasja. Każdą wolną chwilę poświęcamy na zgłębianie tajników technologii. Już nie zastanawiamy się nad każdym krokiem, choć dalej potrzebujemy monitorowania postępów. Reguły zaczynają być dla nas transparentne. Nie skupiamy się już nad tym, jakie wzorce projektowe stosujemy – chcemy po prostu rozwiązać zadanie w najlepszy możliwy sposób.

Mistrz. Najwyższy stopień wtajemniczenia. Intuicja i pełne zatracenie się w realizowanych zadaniach. Teraz reguły nas ograniczają. Świadomie zaczynamy je łamać, aby zmaksymalizować efekty. W IT ciężko nam powiedzieć, jaką architekturę ma nasz system. Jest to miks wielu różnych elementów. Łamiemy popularne reguły lub zaczynamy tworzyć własne. Baza danych dawno nie ma postaci normalnej, często ma nawet kilka równoległych modeli. Do efektywnego działania potrzebujemy znajomości całego spektrum działań.

Podział na domeny

Zgodnie z podejściem Domain Driven Design, systemy dowolnego przedsiębiorstwa możemy podzielić na trzy rodzaje domen:

  • domena główna (core) – krytyczna dla działania firmy. To ona decyduje o naszej przewadze względem konkurencji i ma wpływ na podstawowe procesy biznesowe.  W przypadku portalu aukcyjnego to tutaj będzie mechanizm prowadzenia licytacji czy opisu przedmiotów;
  • domena wspierająca (supporting) – to, co pomaga nam prowadzić biznes, ale bez czego bylibyśmy w stanie się (przynajmniej czasowo) obejść. To tutaj trafią oceny sprzedających czy systemy rekomendacji dodatkowych produktów;
  • domena generyczna (generic) – wszystko, co możemy kupić gotowe i nie musimy tego pisać od podstaw. Systemy płatności, aplikacje CRM, live-chat z klientami etc.

Świadomość tego, jakie systemy wchodzą w skład jakich domen, pozwala nam świadomie zarządzać jakością. Wiadomo, że mimo najszczerszych chęci, nie wszystko będziemy w stanie zrobić idealnie. Całą mądrość polega na tym, żeby wiedzieć, w którym miejscu można odpuścić. Jeżeli gdzieś mamy zrezygnować z jakości, róbmy to w domenie wspierającej. Świadome dopuszczanie długu w głównej domenie to proszenie się o kłopoty. Można to porównać do brania kredytu we frankach szwajcarskich. Początkowo efekty są super, ale później okazuje się trudny bądź niemożliwy do spłacenia.

Warto wiedzieć, że wykorzystanie domeny generycznej zawsze jest dobrym pomysłem. W IT trwa permanentna rekrutacja, bo brakuje rąk do pracy. Jaki jest zatem sens wykorzystywania tych rąk do tworzenia czegoś, co już istnieje? Co więcej, istnieje jako główna domena działalności innej firmy, w związku z czym możemy założyć, że ktoś poświęci jej znacznie więcej czasu niż my kiedykolwiek będziemy mogli to zrobić. A do tego, prawie na pewno w dłuższej perspektywie wyjdzie taniej.

Kompetencje a domeny

Mamy już świadomość różnych poziomów kompetencji naszych pracowników, a także różnych potrzeb w zależności od działających w naszej firmie domen. Możemy zatem połączyć obie informacje i dokonać świadomego przydziału ludzi do projektów.

Ci najlepsi (poziom 4 i 5) powinni zająć się rozwojem właśnie domeny głównej. Będziemy stosowali takie techniki, jak Domain Driven Design, Test Driven Development, CQRS etc. Nie ukrywajmy, że nie każdy programista jest w stanie biegle wykorzystywać te podejścia. Oczywiście, nie da się obsadzić całego rozwoju (nawet ograniczonego do głównych procesów) ekspertami. Uzupełniamy zespół kompetentnymi pracownikami (poziom 3), ale nie zapominajmy, na kim spoczywa ciężar odpowiedzialności.

Domena wspierająca, poza tym, że obejmuje mniej newralgiczne części naszego biznesu, jest też ciekawym miejscem do eksperymentów. Jeżeli rozważamy wejście w nową, niesprawdzoną technologię, powinno ono mieć miejsce właśnie tutaj. Kto się tym zajmie? Całe grono mało lub średnio doświadczonych (poziomy 1-3) programistów, pilotowanych przez kilku ekspertów poziomu czwartego.

Serce nie sługa

Niewątpliwie, podejmowanie decyzji jedynie na podstawie merytorycznych przesłanek jest inżynierską utopią. Niestety, w prawdziwym życiu, pojawia się wiele zewnętrznych, trudno kontrolowanych czynników.

  • „X nie chce pracować z Y”
  • „Z nie chce się uczyć nowej domeny”
  • „W napalił się na Kafkę i zrobi wszystko, żeby wylądować w projekcie AnonimowyKafkoholik”

Pominięcie powyższych aspektów może, delikatnie mówiąc, doprowadzić do ogólnozakładowej katastrofy. Pamiętajmy zatem, że kompetencje techniczne, są oczywiście bardzo ważne, ale nie najważniejsze.

A może ktoś zna jeszcze lepszy sposób na alokowanie developerów? Zapraszam do podzielenia się nimi w komentarzu.

3
Dodaj komentarz

avatar
2 Comment threads
1 Thread replies
1 Followers
 
Most reacted comment
Hottest comment thread
3 Comment authors
Jakub KubryńskiGrzegorzKoziołek Recent comment authors
  Subscribe  
najnowszy najstarszy oceniany
Powiadom o
Koziołek
Gość

Na początku było TDD, a na końcu spaghetti.

Grzegorz
Gość
Grzegorz

Podejście wydaje się być bardzo przemyślanym i logicznym. Jednak mam wrażenie, że metoda ta powinna zostać zmodyfikowana przez uwzględnienie „czynnika ludzkiego”. Nie możemy zawsze ekspertów (4-5) alokować jedynie do zadań core. Oni też chcą eksperymentować, co według zaproponowanego modelu odbywa się w dziedzinie support. Jeżeli nie chcemy stracić ludzi to musimy i im urozmaicić projekty. Jednak wszystko oczywiście zależy od domeny.