Tym, co naprawdę tworzy produkt, jest praca ludzi. Wiele pisze się o metodykach zarządzania przedsięwzięciami i budowie systemów jakości. Przyjrzyjmy się 'miękkiej stronie informatyki' - temu, czego nie da się ująć w metody i wzory, a mimo to ma kluczowe znaczenie dla sukcesu przedsięwzięć informatycznych.

Z badań wynika, że większość problemów, z którymi borykają się firmy informatyczne, nie ma przyczyn technologicznych, lecz społeczne. Dawno skończyły się czasy, kiedy dojrzałe produkty rynkowe były tworzone przez jedną lub dwie osoby. Dziś firmy informatyczne zatrudniają nawet kilkaset osób, a w jednym projekcie może uczestniczyć nawet kilkadziesiąt. Budowa takiego zespołu, przeprowadzenie go przez rafy i mielizny aż do szczęśliwego zakończenia to zadanie bardziej złożone i znacznie bardziej ambitne niż tworzenie aplikacji, projektowanie struktury baz danych czy budowa interfejsu użytkownika.

Wstępem do dobrego projektu jest budowa planu opartego na "czynnikach twardych" - zasobach, budżecie, czasie trwania, dostępnych technologiach i wytyczonych celach. "Czynniki miękkie", ludzkie, nie mogą zastąpić "twardych", natomiast mogą, a nawet muszą, je uzupełniać. Na sukces przedsięwzięcia informatycznego składa się bowiem jedno i drugie - ekonomika przedsięwzięć i procesy społeczne w zespołach.

Władza, przywództwo, autorytet

Menedżer w firmie informatycznej musi posiadać władzę, być dobrym przywódcą i mieć autorytet. Władza oznacza zdolność podejmowania decyzji i wcielania ich w życie. Zasadniczą zaletą osoby posiadającej władzę jest to, że jest wiarygodna. Przywódca to osoba, która stoi na czele grupy. Ma jasno wytyczony cel, nie traci go z oczu w każdej sytuacji. Umie łagodzić konflikty, potrafi rozmawiać z ludźmi, a oni czują się przy nim bezpiecznie. I wreszcie autorytet, czyli głęboka wiedza i doświadczenie. To autorytet sprawia, że członkowie zespołu chcą słuchać jednych, a nie chcą słuchać innych.

Dobrego lidera poznaje się po tym, że odpowiednio równoważy te cechy. Szef, który koncentruje się na władzy, jest tylko satrapą, jego narzędziem pozostaje strach, a dominującą postawą wobec niego są albo posłuszeństwo, albo skrywana pogarda. Zespół kierowany przez takiego szefa nie wyprodukuje nic dobrego, bo nie funkcjonują w nim mechanizmy zespołowe: współpraca, zaufanie i wzajemne wsparcie. Menedżer, który koncentruje się na przywództwie, może mieć problemy z wcielaniem w życie swoich wizji. Przywództwo nie poparte władzą i autorytetem owocuje chaotycznym zarządzaniem i wszystkimi problemami, które z takiego zarządzania wynikają. Menedżer, który ma autorytet bez władzy i przywództwa, nie buduje zespołu. Staje się jedynie ekspertem, z którym co prawda poszczególni informatycy konsultują swoje decyzje (najczęściej tylko techniczne), ale który nie jest w stanie prowadzić zespołu ku sukcesowi.

Podstawowy błąd firm informatycznych w wyborze kierowników polega na tym, że nie szukają "złotego środka" między tymi trzema cechami menedżerów, a stawiają na osoby mające tylko jedną z nich, ale rozwiniętą wyjątkowo mocno. Szefami stają się osoby z największym autorytetem technicznym (najczęściej), ludzie o dużej władzy wewnątrz firmy (rzadziej) albo ci, którzy mają charyzmę i rokują nadzieje na dobre przywództwo. Tymczasem dobrym menedżerem w firmie informatycznej będzie osoba łącząca władzę, cechy przywódcze i autorytet. Pierwszy z "miękkich czynników" zarządzania to zachowanie równowagi między tymi trzema.

Program i rozmowa

Czy jakość tworzonego oprogramowania zależy od umiejętności rozmowy z drugim człowiekiem? Na pierwszy rzut oka wydaje się, że w niewielkim stopniu, ale w rzeczywistości to właśnie umiejętności komunikacyjne mają zasadnicze znaczenie dla jakości tworzonego produktu.

Po pierwsze analiza, polegająca na przygotowaniu zestawienia wymagań zleceniodawcy zrozumiałego dla zespołu informatyków, to nic innego jak umiejętność rozmowy. Zasadnicza trudność w dokonaniu takiej analizy polega na tym, że trzeba umieć skłonić klienta do precyzyjnego określenia potrzeb. Trzeba więc najpierw wczuć się w jego sytuację, zrozumieć jego problemy, cele i zmartwienia. Na tym etapie pomocna jest empatia, czyli umiejętność wczuwania się w sytuację drugiego człowieka. Potem trzeba nauczyć się języka klienta, aby rozmawiać z nim w kategoriach, którymi posługuje się na co dzień. I wreszcie zapisać w dokumentacji analitycznej wymagania w sposób zrozumiały zarówno dla klienta (aby je zatwierdził), jak i programisty (by to zakodował).