Programista ma znać się na programowaniu. Ale czy to wystarczy do rozwijania stabilnych projektów? Czy programista bez umiejętności miękkich jest wartościowy?

Nie.

Po pierwsze, bardzo rzadko zdarza się, aby projekt był rozwijany przez jednego jajogłowego, który w piwnicy wyprodukuje cały kod. Jeżeli pracujesz nad czymś większym niż kalkulator z 4 operacjami, prawdopodobnie robisz to we współpracy z innymi programistami. Od ustalania wspólnego technicznego kierunku projektu, aż po codzienne prace na repozytorium, wszystko wymaga dyscypliny i jedności wszystkich członków zespołu. Jedna czarna owca może skutecznie zabić motywację kolegów i korkować pracę.

Po drugie, projekty IT są tworzone dla biznesu. Za wszystkimi działaniami programistów stoją potrzeby i cele interesariuszy. Nawet w projektach kaskadowych (waterfall), na którymś etapie natkniesz się na kogoś niemówiącego językiem technicznym. Nie ma znaczenia, czy to będzie klient, czy kierownik projektu. Jeżeli nie umiesz wyjaśnić działań technicznych używając języka nietechnicznego, redukujesz swoją wartość do małpy klepiącej w klawiaturę.

Czym jest zespół?

Zespół jest zbiorem ludzi mających za zadanie zrealizowanie potrzeb interesariuszy. Nie muszą to być wyłącznie programiści. Właściciel produktu, menedżer projektu, scrum master lub ktokolwiek inny powiązany z celem projektu może być jego częścią. Ludzie w zespole znają się wzajemnie - wiedzą o mocnych i słabych stronach kolegów. Każdy w zespole pomaga innym, aby przybliżyć zespół do wspólnego celu. Członkowie zespołu wzajemnie uzupełniają swoje kwalifikacje. Zespół może ulegać zmianom w trakcie trwania projektu. Zmieniają się jakość i sposoby komunikacji.

Kilka rzeczy może wskazywać na to, że nie jesteś częścią zespołu:

  • należysz do kilku “zespołów” jednocześnie,
  • każdy w “zespole” pracuje nad innym projektem,
  • “zespół” nie ma wspólnego celu,
  • członkowie “zespołu” mają sztywno przydzielone zadania lub fragmenty projektu i nie wchodzą w silosy kompetencyjne innych.

Na twardo czy na miękko?

Zespoły są mniej lub bardziej zgrane. Mają mniej lub więcej wpływu na kształt projektu. Zwykle jest to związane z wybraną metodyką. Metodyki twarde (np. Waterfall, XPrince) faworyzują formalizację i sztywny podział prac. Najważniejsze jest zrobienie własnego kawałka. Resztą zajmą się inni. Z kolei metodyki miękkie (np. Scrum, Kanban) stawiają na współpracę grupy ludzi w celu wypracowania jak największej wartości.

Metodyki twarde są z pozoru prostsze we wdrożeniu. Sztywne powiązania między ludźmi, dedykowane osoby do tłumaczenia potrzeb biznesu na zadania programistyczne, niezmienny zakres i wizja projektu. Niestety, projekty mają się nijak do założeń metodyk twardych: zakres i wizja projektów nie są stałe. Czasem wynika to ze zmieniających się potrzeb rynku, czasem ze zbyt powierzchownej analizy przed podpisaniem kontraktu.

Metodyki miękkie stawiają na gotowość na zmianę, dzięki czemu są dostosowane do świata rzeczywistego. Wizja projektu jest płynna. Dużo łatwiej sprawdzić pomysł, zanim wejdziemy w niego z pełnym budżetem. Ciągła zmiana jest wyzwaniem i wymaga dużo częstszej i dokładniejszej komunikacji.

Oliwienie trybików

To nie jest tak, że powiecie sobie raz: mamy proces, teraz każdy może się zająć swoją robotą. Proces, podobnie jak kod, rozpada się z upływem czasu. Musicie go nieustannie naprawiać i dostosowywać do obecnych warunków.

Do poprawiania procesu przydatna jest retrospektywa. Jest to spotkanie, na którym omawiacie ostatnie problemy, ale także sukcesy. Dobra retrospektywa pozwala na podnoszenie jakości spotkań, dlatego powinniście ją wykonywać przy zachowaniu wzajemnego szacunku i przestrzegając dodatkowych zasad, np. ustrukturyzowanie spotkania, głosowanie na tematy, wyznaczanie ram czasowych na pojedynczy temat.

Jakość procesu zależy od tego, jak dobrze się rozumiecie. Im lepiej się znacie, tym lepiej się dogadujecie i wspieracie w realizacji projektu. Dlatego warto się czasem wyrwać po pracy i zrobić coś razem. Poza konwencjonalnym piwem w barze, masz szeroki wachlarz możliwości. Najlepiej sprawdzają się gry wymagające zgrania. Możecie pograć w planszówki lub postrzelać do siebie na paintballu albo laser tagu. Nakłoń innych do spróbowania czegoś nowego.

Podsumowanie

Nie ma znaczenia, czy robisz software na twardo, czy na miękko. Tylko rozmowa z ludźmi poprawi Twoje zrozumienie tego co i dlaczego robisz. Wraz z zespołem zdołacie wykonać rzeczy, na które w pojedynkę nie macie szans.

Czy czujesz się częścią zespołu?