Ten wpis stworzyłem razem z Maćkiem Rudnickim – najlepszym liderem technicznym jakiego miałem okazję poznać:)
Budując zespół IT trzeba dużą przykładać do komunikacji. Niezrozumienie bywa tragiczne w skutkach – zwłaszcza, jeśli zespół projektowy nie zrozumie co jest do zrobienia, lub jeśli zespół biznesowy nie zrozumie co zostało zrobione.

Brzmi śmiesznie, ale to codzienność w projektach IT. Lider techniczny / architekt  to osoba która odpowiada na to komunikacyjne wyzwanie w projektach wdrożeniowych.

Kierownik techniczny powinien separować swój zespół od informacji biznesowych które mogą go zdemotywować (np. nadmierna presja, ignorancja techniczna) a zespołowi biznesowemu dostarczać informacji o tym jak projekt postępuje, w sposób dla biznesu zrozumiały. Do tego taka osoba powinna zdefiniować prace zespołu programistów oraz czuwać nad techniczną jakością tego, co jest wytwarzane.

Słowem, być odpowiedzialna za techniczną stronę projektu.

Czasami pojawia się pytanie jaka jest różnica między project managerem a liderem technicznym? Przyznam szczerze, że nie zawsze jest ona bardzo jasna. To zależy od tego jak techniczną osobą jest project manager. Z naszego doświadczenia wynika, że różnica przypomina tę zdefiniowaną w idealnym SCRUMie między Project Managerem a SCRUM Masterem lub Product Ownerem a SCRUM Masterem. Project manager wie co, lider techniczny musi wiedzieć jak. W największym uproszczeniu :)

W poprzednim wpisie pisałem o tym, że kluczowe jest spisywanie zadań i odpowiedzialności ról w zespole bo to buduje framework wzrostu firmy. W Divante wspólnie z project managerami i liderami technicznymi pokusiliśmy się o sformułowanie opisu idealnego lidera technicznego.

Jeśli budujesz zespół lub szukasz takiej osoby to może będzie to dla Ciebie przydatne.

Co należy do obowiązków lidera technicznego?

1. Zorganizować czas zespołu na zadania nieprogramistyczne jak:

  • Codzienne rozmowy o postępach (standupy),
  • Demonstracja oraz weryfikacja postępów prac (demo) przynajmniej raz na dwa tygodnie,
  • Godziny planowania, statusy (przynajmniej raz na dwa tygodnie)

2. Zadbać aby backlog był zawsze kompletny / aktualny.

3. Określać terminy w jakich spodziewa się skończyć dane funkcjonalności z harmonogramu. Jeśli terminy w harmonogramie są nierealne należy o tym mówić.

4. Wyszukiwanie i zgłaszanie zagrożeń projektowych na podstawie harmonogramu dostarczanego przez PMa (wyjątkiem są projekty t&m, które nie zawsze mają harmonogram gdyż minimalny efekt nie został jeszcze określony).

5. Oddelegowywanie zadań logistycznych do innych członków zespołu. Lider nie jest bogiem projektu, lider wierzy w swoich ludzi i wykorzystuje ich potencjał. Lider dba o to by programiści czuli się odpowiedzialni za projekt w którym uczestniczą.

6. Kontakt z osobami technicznymi po stronie Klienta jest wskazany, Klient często widzi to czego zespół nie jest w stanie.

7. Zadbanie o dokumentacje użytkową funkcjonalności tworzonych przez developerów.

Co pomaga liderowi i zespołowi odnosić sukces?

Dobre zrozumienie projektu i branży w której operujemy. Dobre zrozumienie z zespołem i zaangażowanie jego członków. Dlatego, warto przy okazji rozmów z zespołem i liderem pomóc w zwiększeniu zaangażowania w tych obszarach, przez zadawanie trafnych pytań.

Najkrótsza możliwa lista pytań poniżej :)

Lider

  • Branża (czy lider wie na czym Klient zarabia, co jest Jego produktem?)
  • Klient (czy Lider zna Klienta, z kim po stronie klienta rozmawia? jak komunikować się efektywnie z osobą na takim stanowisku?)
  • Zespół (lider musi znać dobrze wój zespół, czy są już jakieś wątpliwości odnośnie osób czy może lider ma pełne zaufanie (do tego trzeba dążyć)? )

Zespół

  • Branża (bardzo ważne jest by programiści wiedzieli wiele o branży w jakiej pracuje Klient. Wystarczy zwykłe pytanie: hej co będziemy sprzedawać w sklepie Klienta? Znacie jakieś produkty?)
  • Środowisko deweloperskie: w jaki sposób wprowadzacie nowych programistów? Jak mogę odpalić Wasz projekt lokalnie? Gdzie jest instrukcja?
  • Dokumentacja funkcjonalności czy każdy ją zna i wie co będzie robił? Czasem wystarczy spytać: hej widziałem w Waszym sklepie funkcjonalność półki z płytami CD. Wyślijcie mi na maila link do dokumentacji użytkowania tej funkcjonalności (jeśli programiści nie prowadzą wiki dla trudnych funkcjonalności to bardzo źle – nie myślą o projekcie tylko o funkcjach które robią, a to oznacza że lider nie dba o projekt)

Niezależnie od tego czy pracujemy w projekcie t&m (większość) czy fixed-price (mniejszość) korzystamy z kilku narzędzi jakie daje SCRUM. Poniżej opis dwóch i ich sposobu użycia przez lidera i zespół.

Lider, Zespół a Backlog

Backlog to zbiór wszystkich zadań jakie wymagane są do ukończenia projektu / etapu projektu.

W backlogu należy uwzględnić minimum trzy typy zagadnień:

  1. Zadanie określone – zadanie niewymagające dodatkowych czynności przygotowawczych aby możliwe było rozpoczęcie prac programistycznych.
  2. Zadanie do wyjaśnienia – zadania o które należy dopytywać Klienta zanim zostaną rozpoczęte prace programistyczne.
  3. Epic – zadania, które należy rozbić na podzadania określone (nie jest możliwe aby programista rozpoczął programowanie nie rozbijając wcześniej Epica na podzagadnienia).

Do backloga można wprowadzić kilka dodatkowych elementów jak na przykład Kontekst – powiązanie zadań z backloga z odpowiednikiem w harmonogramie (przykładowo funkcjonalność wygasania hasła może zostać powiązana kontem użytkownika)

Jak stworzyć backloga?

Jedyną pewną opcją jest zorganizowanie spotkania zespół (tak chodzi o programistów oraz lidera) < – > Klient. Tylko w taki sposób można określić komplet zadań (przynajmniej epiców), który będzie miarodajny. Drugim sposobem jest kontakt lidera z Klientem oraz spisywanie backloga na podstawie analizy (mniej dokładne). Backlog zawsze powinien być weryfikowany oraz omawiany przez cały zespół.

Daily standup

Poniżej kilka zasad codziennych spotkać zespołu:

1. Standup jest organizowany w każdy dzień pracy !!!

2. Standup trwa 15 minut.

3. Standup prowadzony jest przez jedną osobę. Zmieniamy osoby prowadzące daily.

4. Każdy członek zespołu musi odpowiedzieć na trzy pytania:

  • Co mnie blokuje w wykonaniu zadeklarowanych zadaniach?
  • Co zrobiłem wczoraj?
  • Co zrobię dzisiaj?

5. Standup niekoniecznie jest miejscem dla PMa (bo generuje to presję)

6. Lider na standupach?

  • Lider jest członkiem zespołu, powinien jak każdy odpowiedzieć na 3 pytania
  • Opcjonalnie powinien prowadzić dziennik spotkań (ważne stwierdzenia ze standupów dokumentowane w dowolny sposób są naprawdę pomocne)

7. Standup jest organizowany w każdy dzień pracy !!!

 

Zasady są bardzo proste. Kluczowe jak zawsze jest ich wdrożenie w życie, co czasami wymaga już sporo wysiłku. Mam nadzieję, że jeśli jesteś lub szukasz lidera technicznego to takie krótkie podsumowanie jego roli może być przydatne.

Jeśli było lub jeśli masz pytania – daj znać :)