Byłem liderem zespołu, który zajął 3. miejsce w konkursie programistycznym. Zapamiętałem z tego więcej o zarządzaniu niż o kodzie

W ramach studiów na UMK prowadziłem zespół w projekcie programistycznym, który ostatecznie zajął 3. miejsce i przyniósł nagrodę pieniężną. Spodziewałem się, że największym wyzwaniem będzie kod. Największym wyzwaniem okazało się to, żeby pięć różnych osób patrzyło na ten sam problem w ten sam sposób.

Techniczna strona była w zasadzie łatwa

Podział na moduły, wybór stacku, ustalenie interfejsów między częściami systemu - to wszystko dało się rozwiązać w jedno popołudnie z resztą zespołu przy tablicy. Trudność zaczęła się później, kiedy okazało się, że "skończone" znaczy coś innego dla każdej osoby w zespole: dla jednej - działa u mnie lokalnie, dla innej - przeszło testy, dla jeszcze innej - jest w ogóle zintegrowane z resztą systemu.

Czego się nauczyłem jako lider (nie jako programista)

Konkretność ponad entuzjazm. "Zrobię to na jutro" nic nie mówi o tym, czy chodzi o szkic, czy o gotowy, przetestowany kod. Nauczyłem się pytać wprost: co dokładnie będzie gotowe i jak to sprawdzimy razem, zanim uznamy zadanie za zamknięte.

Blokery trzeba wyciągać, a nie czekać, aż same wypłyną. Największe opóźnienie w projekcie wzięło się z tego, że jedna osoba utknęła na integracji dwa dni przed deadline'em i nie powiedziała o tym wcześniej, bo miała nadzieję, że sama to rozwiąże. Od tamtej pory pytałem o postępy zanim ktoś zdążył się zablokować na tyle długo, żeby to było niewygodne do przyznania.

Decyzja podjęta na czas jest ważniejsza niż decyzja idealna. W kilku miejscach spieraliśmy się o szczegóły architektury, które ostatecznie nie miały żadnego wpływu na wynik konkursu. Nauczyłem się rozpoznawać, kiedy dyskusja przestaje dotyczyć czegoś, co faktycznie wpłynie na wynik, i kiedy czas na podjęcie decyzji i przejście dalej.

Co z tego zostało

Kiedy dziś pracuję nad własnymi projektami - czy to rozbijaniem monolitu na mikroserwisy w Ordered, czy integracją AI w Unordered - korzystam z tej samej zasady: zanim ogłoszę, że coś działa, sprawdzam to w sposób, który nie zostawia miejsca na "chyba działa". To jedyna rzecz z tego projektu, która okazała się bardziej przydatna niż sam kod, jaki wtedy napisaliśmy.