Zarządzanie projektem IT – komunikacja w zespole
28 Paź


O tym jak ważna jest komunikacja w pracy – nie musimy nikomu mówić. Po prostu jest ważna i tego należy się trzymać. Ten fakt jest oczywisty, ale już mniej oczywista wydaje się „jakość” owej komunikacji, a to od niej w dłuższej perspektywie zależą sukcesy firmy oraz jej efektywność. Komunikacja jest szczególnie istotna w przypadku projektów inżynierskich takich jak np. IT. W grę wchodzą często bardzo duże pieniądze inwestora przeznaczone na dowiezienie projektu w określonym czasie i (jeśli jest to model Fixed Time&Cost) budżecie. Od tego jak projekt będzie prowadzony, na kiedy oddany, z jaką ilością błędów oraz jaką jakością kodu – zależy często forma i jakość komunikacji pomiędzy interesariuszami projektu. W kilku zdaniach postaram się przybliżyć najbardziej „czułe punkty” komunikacji w zespole projektowym tworzącym oprogramowanie dla klienta.

1. Po pierwsze – narzędzia

Istotnym elementem całej komunikacji jest odpowiedni dobór narzędzi projektowych takich jak narzędzia do komunikacji wewnętrznej (np. Slack.com), narzędzia do przechowywania informacji o projekcie, plików graficznych, dokumentacji itd. (np. Basecamp.com), repozytorium z kodem (np. Bitbucket.org) czy wreszcie sam system do zarządzania projektami z tablicą Kanban (np. Jira). Odpowiednie narzędzia to jednak za mało. Muszą być też poprawnie uzupełnione, tak aby żadna osoba zaangażowana w projekt nie musiała męczyć PM’a o tak trywialne sprawy jak: „gdzie mamy pocięte png pod andka?” lub „daj mi dostęp do repo, uprawnienia write bo nie mogę zrobić commita”. Wszystko musi być uporządkowane – dokumentacja, elementy graficzne i inne, muszą znajdować się w odpowiednio opisanych folderach w konkretnym systemie. Repozytorium z kodem musi być stale aktualizowane, na bieżąco powinny być tworzone jego kopie zapasowe, a sama tablica w Jirze musi być aktualna oraz na bieżąco weryfikowana przez Project Managera. Narzędzie do komunikacji wewnętrznej ma służyć do usprawnienia pewnych procesów np. pomysłów na szybsze oprogramowanie danego algorytmu lub w celu zwiększenia postępów w projekcie – nie jest to bynajmniej skupisko internetowych memów.

2. Block’i

Kolejnym elementem wzorowej komunikacji jest eliminacja tzw. „wąskich gardeł” czyli sytuacji, w których nie możemy iść dalej z projektem gdyż coś lub ktoś nas blokuje. Typowym wąskim gardłem jest często sam klient, który opóźnia zespół projektowy np. z powodu niedostarczania konkretnych elementów graficznych do aplikacji (w przypadku gdy design jest w gestii klienta). Tutaj sam project manager musi wykazywać się nie tylko uprzejmością (bo przecież klient nam płaci), ale też stanowczością i zdecydowaniem. Bardzo częstym zjawiskiem są taski oznaczone w systemie do zarządzania projektami, etykietą „Blocked by API”, które są niczym innym jak konkretnymi endpointami w API i często to klient powinien je dostarczyć w określonym czasie. Przecież oprogramowanie trzeba też testować, nie tylko manualnie…

3. Testy i współpraca z działem QA

Odnośnie samych testów i współpracy z testerami można by pisać godzinami. To tutaj dochodzi często do największych opóźnień i najczęściej nie z winy programistów. Brak dobrej komunikacji swoich potrzeb przez testera skutkuje niezrozumieniem tych potrzeb przez programistę co może skutkować (w najlepszym przypadku) niepotrzebnym „dopytywaniem się” co autor miał na myśli lub (co gorsza) niewłaściwą implementacją rozwiązania. Jedynym sposobem na uniknięcie problemów na tym etapie jest skrupulatne i bardzo dokładne opisanie błędów w działaniu danej aplikacji oraz stworzenie odpowiednich ticket’ów w systemie, tak aby programista bez problemu i zadawania zbędnych pytań mógł przystąpić do naprawy bug’ów. Każdy błąd musi mieć swój szczegółowy opis zawierający markę, model telefonu, na którym dokonywano testów manualnych, system i jego wersję oraz inne znaczące elementy ułatwiające programiście diagnozę i naprawę błędu w jak najkrótszym czasie.

4. Świadomość klienta

Kolejnym ważnym elementem jest uświadomienie klienta jak ważny (jeśli mówimy o pracy projektowej na zlecenie klienta) jest on sam w całym procesie tworzenia oprogramowania. Projekty IT są często bardzo skomplikowane oraz ryzykowne – w grę wchodzą zazwyczaj duże budżety, a więc każdy powinien stanąć na wysokości zadania, klient także – mimo, że często jest inwestorem i wykłada pieniądze na stół. Tutaj wysiłek leży po stronie dobrego i stanowczego PM’a, który poprzez skuteczne naciski, uzyska niezbędne informacje od klienta w szybkim czasie, zapewniając tym samym ciągłość pracy swoim inżynierom. Ponadto, musimy zdawać sobie sprawę, że klient nie musi znać się na programowaniu lub zarządzaniu projektem – w tym przypadku to celem biznesu jest odpowiednie wytłumaczenie, że w takiej sytuacji pieczę nad całym projektem klient powinien oddać w ręce doświadczonego zespołu, który poprowadzi projekt (wraz z jego odpowiednim budżetowaniem).

5. Daily stand’upy, weekly demo calls, ustalanie harmonogramu sprint’ów

Zarządzając projektem w oparciu o metodykę Agile/SCRUM i chcąc wyeliminować tym samym sytuacje opóźniające nasz projekt musimy zwrócić szczególną uwagę na strukturę pracy, jej wewnętrzną organizację. I nie mam tu na myśli bynajmniej rozproszenia zespołu czyli pracy zdalnej – ta jest jak najbardziej ok jeśli inne elementy są odpowiednio ustrukturyzowane. Jednym z takich elementów są daily standupy czyli spotkania zespołu organizowane najczęściej rano, po „zalogowaniu” się wszystkich interesariuszy projektu. To moment, w którym podsumowujemy co zostało zrobione wczoraj lub przed weekendem, a jakie zadania czekają na nas dziś. Notatkę ze spotkania, PM powinien umieścić w odpowiednim systemie np. w Basecamp co pozwoli na śledzenie postępów prac przez klienta oraz nada samym spotkaniom pewnego porządku. Weekly demo calls to spotkania, organizowane zazwyczaj w formie wideorozmów z klientem, który na bieżąco, z tygodnia na tydzień, śledzi postęp prac zespołu. Ważnym elementem są także spotkania dot. ustalania harmonogramu sprintów – etapów rozwoju projektów, jego kolejnych kamieni milowych. Do przygotowania takiego harmonogramu potrzebna jest wiedza analityczna oraz doskonała znajomość założeń projektowych.

Powyższe 5 punktów to tylko zalążek tego co spotyka nas w projekcie i wpływa na komunikację, jednak bazując na swoim doświadczeniu przytoczyłem te (w mojej opinii) najważniejsze. Pewnym jest jednak, że wiele problemów projektowych, nie wyrabiania się przez firmy w określonym budżecie (np. niedoskonała komunikacja działu QA z programistami) lub deadline (np. konflikt z klientem, zmiana założeń projektu w trakcie trwania danego sprintu, brak uświadomienia klienta o potencjalnych zagrożeniach) to często powód słabej komunikacji.

Na koniec ostatnia myśl, która przyszła mi do głowy – komunikować się dobrze, nie znaczy często mówić/pisać. Jeśli nikt nie zadaje pytań to znaczy, że każdy wie co ma robić. I to jest chyba najefektywniejsza komunikacja.

Dobra agencja rekrutacyjna IT – jaka powinna być? Rekrutacje IT nie dla każdego.
10 Paź


Wiele firm powstaje i powstanie jeszcze na rynku polskim działając w obszarze rekrutacji IT. To łatwy i dobry kawałek chleba – jak mawiają amatorzy branży. Działalność ta przecież to „wysokie marże” i niekończące się profity. To co najważniejsze to według wielu „zarobić i się nie narobić” dlatego firmy rekrutujące programistów wyrastają jak grzyby po deszczu ulegając złudzeniu szybkiej możliwości zarobku. Jak jest jednak naprawdę? Kto rekrutuje dobrze, a kto zamyka firmę po 3 miesiącach? Kto ma szansę zaistnieć na dłużej, budując długofalowe relacje? Na te pytania odpowiem Ci w poniższych zdaniach.

1. „Liczy się ilość, a nie jakość drogi Panie!”

Wiele firm uważa, że skuteczna rekrutacja programisty polega na wysłaniu jak największej liczby CV do klienta, zwiększając tym samym prawdopodobieństwo, że któryś z kandydatów (mówiąc językiem branży) „wpadnie” czyli zostanie pomyślnie zrekrutowany. Nie ma tu miejsca na myślenie w kategoriach budowania pozytywnych i długofalowych relacji z klientem – programistów podajemy jak na taśmie. Szybka sprzedaż – szybki zysk. To krótkowzroczne myślenie hamuje rozwój – patrzymy na to co jest tu i teraz nie zastanawiając się nad tym, że klient „zmęczony” przeglądaniem CV nie pasujących do jego wymarzonego kandydata przestanie się w przyszłości nami interesować i pójdzie do konkurencji. Zauważ, że tak jak Ty cenisz sobie swój czas tak i klient nie ma czasu na rozmowę z każdym. Interesuje go konkretny profil zawodowy. Nie można więc kazać mu zapoznawać się z 20 osobami, które okażą się niekompetentnymi. To jeden z elementarnych błędów popełnianych przez słabe firmy rekrutacyjne.

2. „A po co sprawdzać CV? Przecież programista to programista…”

Kolejnym błędem, bezpośrednio związanym z tym o czym piszę powyżej jest brak wiedzy rekrutera zajmującego się rekrutacją danego specjalisty (danej technologii). Często słabe firmy rekrutacyjne zatrudniają (jeśli zatrudniają to i tak pół biedy, często są to wolontariusze działający na prowizji) studentów, praktykantów, stażystów do tego, aby te osoby reprezentowały firmę rekrutacyjną przed potencjalnym kandydatem. Faktycznie – student może studiować informatykę i być biegły np. w technologii JAVA. Załóżmy również, że owy student jest urodzonym geniuszem jeśli chodzi o programowanie w JAVIE – sam napisał już kilka ambitnych aplikacji. To wszystko jednak nadal nie daje mu wiedzy niezbędnej do tego, żeby rekrutować bo jego wiedza kończy się na studiach, a o prawdziwym życiu nie ma pojęcia. Przykład studenta informatyki jest i tak modelem prawie doskonałym – w prawdziwym życiu, zatrudniane są osoby po technikum gastronomicznym, osoby studiujące geodezję i inne kompletnie niepowiązane z branżą persony. Domyślasz się zapewne dlaczego tak się dzieje, a jeśli nie to podam Ci główny powód – oszczędność i krótkowzroczność. Brak wiedzy biznesowej właścicieli agencji (często są to rekruterzy, którzy opuścili mury korporacji usiłując za wszelką cenę spełnić swój american dream rodem z Silicon Valley) oraz chęć szybkiego zarobienia pieniędzy nie pozwala im na zatrudnienie poważnej i doświadczonej kadry rekruterskiej przez co szybko wypadają z „gry” i nie stać ich na trwałe relacje i stałych klientów. „Po co wydawać na dobrego rekrutera skoro student zrobi to samo?” – te słowa to powód klęski wielu firm rekrutacyjnych.

3. Wiedza techniczna

Niestety, ale działając w tak „delikatnej” branży jak IT trzeba liczyć się z konsekwencjami – nasz brak kompetencji będzie surowo wytknięty przez niejednego kandydata, którego usiłujemy zrekrutować. Programiści to osoby ambitne, często po dobrych uczelniach, mające na swoim koncie wiele tysięcy zapisanych linii kodu, setki godzin kursów uzupełniających oraz wiele dni spędzonych za granicą jako uczestnicy eventów oraz szkoleń. Jeśli zatem próbujesz rekrutować taką osobę, musisz wiedzieć, że Twój brak przygotowania oraz wiedzy technicznej może skutkować niższą konwersją – będziesz rekrutował znacznie mniej i znacznie słabszych programistów. Oczywiście, że nie każdy musi być programistą, ale nawet w tym przypadku dobra firma rekruterska weryfikuje programistów pod kątem danej technologii – posiada wyspecjalizowane osoby, niekiedy zatrudnione na stałe, które na bieżąco weryfikują kandydatów, odciążając rekruterów z części stricte technicznej rozmowy. Taki proces pozwala utrzymywać dobre relacje z kandydatem, które są tak samo istotne jak relacje budowane z klientami.

4. Feedback

Każdy lubi otrzymywać informacje zwrotne na tematy, które go interesują. Idąc do sklepu i prosząc o garnitur na zamówienie, oczekujemy od sprzedawcy informacji, kiedy takowy będzie dostępny, uszyty, i będziemy mogli do odebrać. Brak tej informacji przyczyni się do postrzegania sprzedawcy jako nieprofesjonalnego oraz niegodnego zaufania. Skutek – wybierzemy garnitur u konkurencji mimo iż może okazać się droższy. Ta sama sytuacja odnosi się do programisty – brak szybkiej informacji o przebiegu procesu rekrutacyjnego, informacji kiedy kandydat może spodziewać się odpowiedzi od potencjalnego pracodawcy czy wreszcie jak wyglądają warunki współpracy, skutkuje tym, iż programista zacznie szukać pracy omijając nas jako pośrednika – znajdzie inną agencję, która dostarczy mu te informacje w znacznie krótszym czasie. To kolejny przykład słabo zarządzanej firmy rekrutującej specjalistów IT – firmy, która uważa, że klient jest najważniejszy, a programista może poczekać.

5. Brak wyróżnika na tle konkurencji

Posiadam agencję rekrutującą programistów – czym jednak się ona wyróżnia? Jaka będzie za 5,10 czy 15 lat gdy zmieni się koniunktura? Jaki mam plan na „gorsze chwile” kiedy nie mam zbyt wielu umów z klientami? Co się stanie gdy nie mam programistów, a mam umowy z klientami? Jak to wpłynie na reputację moją i mojej firmy? Jak zatrudnić profesjonalnych rekruterów skoro nie posiadam kapitału? To pytania, które pozostają bez odpowiedzi jeśli odpowiadać próbuje przeciętna agencja rekrutacyjna. Liczy się tu i teraz – brak modelu na przyszłość, brak wizji, a zarazem perspektyw. Brak planowania doprowadza wiele biznesów do bankructwa i upadku (o czym pisał szerzej Peter Thiel w książce zatytułowanej „Zero to One”, którą szczerze Ci polecam). Dobra firma rekrutacyjna w porównaniu do słabej czymś się wyróżnia, coś wnosi, jest inna niż wszystkie. Samsung i Apple produkują smartfony, jednak na tyle różne, iż potrafią zaspokoić potrzeby rozłącznych grup docelowych na tyle skutecznie, że zarabiają przy tym krocie. Jaka jest Twoja agencja? Czym się wyróżnia?

To tylko niektóre, z wielu kwestii wartych poruszenia w kwestii zatrudniania programistów przez słabe i dobre firmy rekrutacyjne. Problem jest daleko zakorzeniony w rynku, ale i w naszej kulturze i edukacji, która nie wykształciła w nas dobrych manier biznesowych – ponad 27 lat wolności to za mało by zdobyć wiedzę, którą inne narody kształciły w sobie od wielu dekad, a nawet stuleci. Jesteśmy jednak na dobrej drodze.