O trudnej sztuce kierowania IT

Dzisiaj publikujemy test pt: „czy wiesz, jak kierować zespołem IT”. Przeczytaj poniższy opis i odpowiedz na pytania na końcu testu.

Ponieważ nasza poprzednia próba napisania programu „Hello, world!” zakończyła się niepowodzeniem, zostało powołanych kilka niezależnych zespołów, które miały wykonać to zadanie. A każdy z tych zespołów ma oczywiście swojego kierownika… Przyjrzyjmy się im dokładniej:

Zespołem A dowodzi Kierownik Strateg. Każda rozmowa z tym kierownikiem kończy się odwołaniem do wartości i misji firmy, ogólnej strategii oraz wizji przyszłości. Zadając mu konkretne pytanie może nie uzyskujesz dokładnej odpowiedzi, ale za to wychodzisz ze spotkania z pełną wiedzą o koncepcji rozwoju produktu w perspektywie pięciu najbliższych lat oraz możliwych implikacji rozwoju Unii Europejskiej na cykl dostaw waszego oprogramowania.

Na czele zespołu B stoi Kierownik Biurokrata. Wszystko musi być udokumentowane! Każda zmiana wymagań musi być odzwierciedlona w dokumentacji, każde zadanie musi być dokładnie opisane, na każdą decyzję musi być odpowiedni mail, który będzie można wyciągnąć w razie ewentualnej potrzeby. Nie ważne jest to, co robimy – ważne jest to, żeby w szufladzie lub skrzynce mailowej były odpowiednie kwity.

Kolejnym zespołem C zarządza Kierownik „Pokażę Ci Jak To Zrobić (Albo Najlepiej Zrobię To Sam)”. Temu kierownikowi nie wystarcza powiedzenie, co masz zrobić – musi dokładnie pokazać ci, jak to zrobić. Palcem wskazuje, które linie w kodzie masz zmienić i jak masz je skompilować. Przed przystąpieniem do zadania jesteś dokładnie poinstruowany co masz zrobić i w zasadzie cała praca sprowadza się do wykonania otrzymanych poleceń. Jedyny mały problem polega na tym, że ze względu na ilość udzielanych instrukcji, czasami trzeba długo stać w kolejce pracowników oczekujących na audiencję do kierownika.

Zespół D posiada Kierownika Którego Nie Ma. Trudno coś powiedzieć o tym kierowniku, ponieważ go… nie ma. Przebywa obecnie na bardzo ważnym spotkaniu. Na konferencji. Na szkoleniu. Akurat przez chwilę jest, ale musi właśnie teraz i natychmiast zrobić Coś Szalenie Ważnego, także niestety nie może z tobą porozmawiać.

Zespołem E zarządza Kierownik Mistrz Delegowania. Proszę nie mylić tego pojęcia ze „spychologią” – żaden z kierowników nie wie, co to jest „spychologia”, kierownik zawsze deleguje. Tak, ten kierownik zawsze ma czas na spotkanie. Tak, zawsze chętnie porozmawia o twoim problemie. Ale dziwnym trafem zawsze wychodząc ze spotkania zawsze uświadamiasz sobie, że to sam ty musisz rozwiązać problem, z którym do niego przyszedłeś…

Pora na zespół F i jego Kierownika Dyktatora. Tutaj wszystko chodzi jak w zegarku: „masz na to czas do jutra”, „nie przyjmuję do wiadomości innej odpowiedzi” oraz „nie obchodzi mnie jak to zrobić – ma być zrobione i już”.  Nie ma czasu na zbędne debaty, dyskusja jest niewskazana – są zadania do wykonania i trzeba je wykonać!

I zakończmy przegląd zespołów na literce G oraz Kierowniku Filozofie. Na każde postawione pytanie zawsze znajduje dwie alternatywy. Nad każdą decyzją trzeba się długo i dogłębnie zastanowić. Na każdą sytuację można spojrzeć z dwóch różnych widzenia. Można zrobić to tak – albo inaczej. I można długo rozważać i debatować kwestię przyczyn, skutków oraz implikacji.

A teraz spróbuj odpowiedzieć na pytania:

1. Który zespół przestał konsultować się ze swoim kierownikiem i sam zaczął podejmować decyzje?
2. W którym zespole pracownicy realizowali zadania jedynie w ściśle wyznaczonym przez przełożonego zakresie?
3. Który zespół nie robił żadnej poprawki w kodzie co najmniej 4-stronicowej analizy i podpisaniu zamówienia przez klienta?
4. W którym zespole pracownicy byli szalenie kreatywni w wymyślaniu obiektywnych przyczyn, dla którego zadanie nie mogło być zrealizowane w terminie?
5. Który zespół przed zamówieniem pizzy na obiad rozmawiał o strategii wyboru dostawcy?
6. Który zespół na propozycje dowolnej zmiany odpowiadał „ale muszę to jeszcze skonsultować”?
7. Który zespół wykonał zadanie?

* * *

A teraz kilka akapitów zupełnie serio. Z powyższych opisów może wynikać, że kierownicy w IT są beznadziejni – tak oczywiście nie jest. Ale nie jest też zupełnie dobrze.

Kierowanie mniejszym czy większym zespołem IT jest o tyle trudne, że wymaga zestawu bardzo odmiennych umiejętności. Idealny kierownik zespołu informatycznego powinien mieć:

• wiedzę technologiczną, która pozwoli mu efektywnie planować oraz oceniać pracę swoich podwładnych;
• wiedzę merytoryczną o systemie, nad którą pracuje zespół – a w przypadku dużych systemów taką wiedzę nabywa się przez długi okres czasu…
• zdolności menedżerskie, czyli dobre komunikowanie się, słuchanie, przekazywanie informacji zwrotnej, planowanie i organizowanie zadań, umiejętność przydzielania pracy, definiowanie sposobów mierzenia indywidualnych wyników pracy, umiejętność i chęć podejmowania trafnych decyzji;
• powinien również być liderem zespołu – a to znaczy dzielenie się wspólną wizją, umiejętność wspólnego ustalania celów, wyrażanie uznania i nagradzanie, dbanie o rozwój zespołów, umiejętność negocjowania i efektywnego rozwiązywania problemów interpersonalnych, budowanie zaangażowania pracowników, umiejętność wykorzystania właściwych stylów interpersonalnych.

Czasami od kierownika wymaga się również umiejętności strategicznych oraz podejmowania decyzji architektonicznych. A do tego dochodzi często jeszcze żmudna papierkologia i przeróżne sprawy formalne. Uff,  bardzo dużo tego… Ale sedno problemu polega na tym, że bardzo niewiele osób jest naturalnie uzdolnionych w dwóch przeciwstawnych kierunkach – zarówno w obszarze „twardych” zdolności technicznych i „miękkich” zdolności menedżersko-przywódczych.

Dość powszechną praktyką w zespołach IT jest awans wewnętrzny – szefem zespołu zostaje osoba, która pracowała w tym zespole i wyróżniała się skutecznością, komunikatywnością, czy też zdolnością szerszego spojrzenia na pracę zespołu. Najczęściej mamy więc do czynienia z osobami, które wychodzą od ścieżki technologicznej i powoli zdobywają umiejętności menedżerskie. W skrajnie pesymistycznych przypadkach bywa też tak, że po awansie zespół traci dobrego programistę i zyskuje kiepskiego menedżera… Do tego awans na kierownika z grupy, w której były relacje symetryczne, jest przeważnie trudny dla obu stron – i dla kierownika który musi nauczyć się wymagać od swoich dawnych kolegów, i dla zespołu, który musi zaakceptować to, że dotychczasowe relacje się zmieniły.

Niektóre organizacje radzą sobie w ten sposób, że rozdzielają te role – w zespole jedna osoba pełni rolę lidera technologicznego, czyli osoby do której można zwracać się z problemami technicznymi, natomiast inna jest menedżerem, który zajmuje się planowaniem, rozliczaniem oraz wszystkimi sprawami formalnymi takimi jak urlopy czy zwolnienia. Tak też można zrobić – trzeba tylko zadbać o to, aby te role były dość jasno rozdzielone.

Kolejną rzeczą, która też bywa trudna i może być różnie rozwiązywana, jest rozdział obowiązków pomiędzy kierownika zespołu (kierownika liniowego) a kierownika projektu (project managera) – oczywiście w sytuacji, kiedy mamy projekty oraz ich kierowników.

A jaki jest kierownik Twojego zespołu?