6 grzechów głównych liderów technicznych

Pewnie bym nie napisał tego postu, gdyby mnie Michał nie namówił.
Ostatnie kilka miesięcy to czas, w którym generalizował mi się jeden wniosek, którego chyba nie chciałem przyjąć do wiadomości, choć z drugiej strony wydaje się być całkiem zrozumiały.

Jaka jest rzeczywistość projektowa w dużej części firm? Jest tzw. biznes tudzież klient, który nie wie czego chce i jednocześnie jest generatorem oraz sponsorem projektów. Zazwyczaj biznes dość nieprecyzyjnie określa zakres projektu, oczekując dość precyzyjnego oszacowania kosztów projektu. I tak zwane IT jakoś to szacuje (!). A później musi się z tego wywiązać. Oczywiście z czasem się okazuje, że jednak nie wszystko zostało uwzględnione w oszacowaniu oraz klient zmienił zdanie w międzyczasie, więc często nie ma szans na wykonanie projektu w czasie - pozostają nadgodziny lub przesunięcia terminów.
Ponieważ nastąpiło wyraźne niedoszacowanie, toteż nie "ma czasu" na dobre praktyki projektowe, a w zasadzie jest czas na wszelkie możliwe antywzorce programowania. W efekcie robi się coraz większy burdel i jest coraz gorzej. Można wylewać pomyje na biznes, jacy to są nierozgarnięci, niezorganizowani i nie wiedzą czego chcą... ale hola hola spójrzmy na siebie. Coraz więcej przykładów, z którymi się spotykam, prowadzi do następujących wniosków, odnośnie tego, co jest źródłem problemów... a raczej kto! Wiecie kto? Liderzy i/lub kierownicy, którzy wywodzą się z backgroundu technicznego, gdyż zwyczajnie sobie nie radzą w drapieżnym świecie biznesowym i tu się zaczynają problemy. Gdybym miał wymienić główne grzechy to byłyby one następujące:
* za bardzo ciągnie do technikaliów - a wiadomo, że jak pojawiają się trudne sytuacje, to wolimy się zajmować tym, co lepiej znamy; zatem w kryzysowym momencie lider techniczny, zamiast ratować zespół, projekt, rozwiązuje niezwykle istotny problem z najnowszym frameworkiem;
* procesy wytwórcze są mało istotne - niestety my, osoby techniczne, mamy mylne przekonanie, że jak będziemy mieli świetny koncept techniczny to reszta w projekcie sama się ułoży. Gówno prawda! Nic się samo nie układa. Trzeba się nieźle narobić, żeby utrzymać w ryzach zespół, klienta, projekt...;
* ulegamy biznesowi - powszechne tłumaczenie, dlaczego IT zgodziło się na realizację projektu, na który nie ma wystarczających zasobów oraz czasu, to że biznes naciska; tak kochani, jesteśmy za MIĘTCY, biznes rządzi, biznes wykłada pieniądze, my nie mamy nic do powiedzenia... bzdura, to zwykły brak asertywności i umiejętności szukania korzystnych dla obu stron rozwiązań; z drugiej strony rzadziej spotykana postawa NIE BO NIE, to też nie jest rozwiązanie;
* nie potrafimy rozwiązywać trudnych tematów personalnych - wielokrotnie widziałem ciągnące się miesiącami sytuacje, kiedy ktoś z zespołu się obraża, bo jego zdanie nie zostało uwzględnione lub gdy mu się zwraca uwagę, mało kto ma odwagę i umiejętności podjąć temat i rozwiązać problem;
* zamykamy się w boxach - lubimy jak nikt nam nie przeszkadza, gdy zaszywamy się w bezpiecznym kącie i klepiemy... do tego jeszcze słuchawki na uszy; kiedy stajemy się liderami, niestety ten nawyk pozostaje; bycie liderem to przede wszystkim interakcje i rozwiązywanie problemów - tego się nie da zrobić chowając się w boxie;
* brak informowania - złota zasada projektowania zwinnego mówi - podejmuj decyzje projektowe najpóźniej, kiedy to możliwe; wiele osób wzięło sobie to do serca, ale w innym kontekście - najczęściej informują o problemach w projekcie, najpóźniej kiedy to możliwe, a zazwyczaj wtedy jest już za późno...