Ten trochę przydługi wpis z jednej strony mówi o tym, co sądzę o zespołach IT. Z drugiej strony mówi jak taki zespół wybudować w taki sposób, aby był efektywny, pragmatyczny i lubiany przez resztę firmy.

Trzynaście lat temu zacząłem pracę jako programista. Miałem wtedy 14 lat i chciałem pisać gry komputerowe. Zacząłem uczyć się programowania w C (udało mi się napisać jedną grę komputerową w trybie 13h w DOS’ie :)). Później zacząłem przygodę z programowaniem Windows (Delphi – programy Zajączek, CyTaT …). Potem pojawiały się projekty aplikacji enterprise – portale webowe, systemy VoIP a w końcu zaczęliśmy z Tomkiem tworzyć własne startupy internetowe (blogfrog.pl, znam.to z Agorą) i .. założyliśmy Divante.

Jeszce 2 lata temu sam programowałem. Szczerze mówiąc, ciągle staram się być na bieżąco i gdyby była taka potrzeba mogę otworzyć edytor i coś popisać :) Po co to piszę?

Bo uważam, że programowanie i praca programistów jest bardzo ważna. Zwłaszcza w e-Commerce, gdzie jak mało gdzie, dobrze napisany kod potrafi zarabiać pieniądze. Niestabilna aplikacja potrafi generować straty. Pomysłowe rozwiązanie może oszczędzać koszty (np. serwerów).

Sam tworzyłem wiele projektów i programów – od zera, od projektu, do programowania i testów. Zatrudniamy jako programistów tylko bardzo mądre i bystre osoby. Nie zatrudniamy klepaczy kodu ani „swetrów” :-) Nasi ludzie mogą mieć i mają duży wpływ na finalny wygląd i działanie oprogramowania które tworzymy.

Zawsze byliśmy zwolennikami open source. Używamy głównie Magento – bo jest dobrze zaprojektowane i pozwala pisać kod korzystając z dobrych inżynierskich praktyk. Nie zmienia to faktu, że nigdy nie chciałem, żeby nasz dział IT był „działem wdrożeniowym” w rozumieniu instalowania i konfigurowania programów, „tworzenia skórek” :) Staramy się aby w projekcie było wyzwanie technologiczne. Na różnych poziomach. Staramy się pracować w mądry sposób (systemy kotroli wersji, checklisty, procedury testowania).

Gdy patrzę na to jakie realizujemy projekty, jestem mega-dumny z naszego teamu. Wdrażamy duże projekty oparte na Magento, które czasami trwają kilkanaście miesięcy. Zespoły składają się z kilku programistów (+ webmasterzy, projektanci). Chłopaki tworzą integracje z najróżniejszymi systemami ERP, wykorzystują systemy kolejek (np. Gaerman), tworzą rozproszone aplikacje (load balancery, replikacja bazy danych, serwery proxy, rozproszony cache, optymalizacje Magento). Wiele razy pokazywaliśmy, że Magento daje radę i że potrafimy tworzyć niestandardowe rozwiązania.

Programiści często odczuwają presję – spadają na nich terminy, poprawki, zmiany wymagań. To ciężki zawód i pewnie nie każdy dał by sobie w nim radę. Oprócz tego wymaga mega-przekrojowej wiedzy której zdobycie wymaga dużej ilości czasu. Cieszę się, że zatrudniamy takich świetnych developerów.

Jak zbudować team developerski?

Każdy ma swoje zasady. Nie mam monopolu na wiedzę więc opiszę co sprawdziło się w Divante

Przede wszystkim – jeden cel i szacunek dla pracy innych

Działy technologiczne tworzone są i obsadzane przez bardzo inteligentnych ludzi posiadających wiedzę i umiejętności niedostępne dla pozostałych członków organizacji. Taka sytuacja może prowadzić z jednej strony do braku zrozumienia i szacunku dla prac technicznych przez działy biznesowe. Z drugiej strony często prowadzi do „zamykania się” działów IT, które zaczynają wyżej wartościować swoje prace i tajemną wiedzę niż cele tzw. biznesu.

Taki dualizm prowadzi do bardzo niebezpiecznego rozwarstwienia. Dział IT traci poczucie jedności celów z celami działów biznesowymi. Pracownicy coraz mniej się rozumieją i zaczynają pokazywać kto jest ważniejszy. Skutki dla oprogramowania zaczynają być opłakane.

Wszyscy w organizacji powinni znać cel do którego dążą. Jeśli tworzymy system e-commerce celem tym najprawdopodobniej jest duża sprzedaż. Programiści, webmasterzy powinni brać udział w spotkaniach z projektantami, z działami sprzedaży i przede wszystkim rozmawiać po co tworzone są dane rozwiązania. Taka współpraca nie tylko podnosi obustronne zrozumienie – pozwala też zaangażować się i spojrzeć na problem z perspektywy drugiej strony.

Zaangażowanie działu IT w tworzenie oprogramowania od momentu samej koncepcji biznesowej  daje bardzo dobre efekty.  Jego członkowie nie tylko nie będą negowali  nieciekawych czy niewygodnych z jego punktu widzenia rozwiązań technicznych ale też sami będą sugerowali rozwiązania optymalne ora zadawali trafne pytania. O to tak naprawdę chodzi. Działy biznesowe nie mają czasami wiedzy technicznej i algorytmicznej która przydaje się do sprawdzenia samych założeń niektórych decyzji biznesowych.

Dobra współpraca w ramach działu IT i z tym działem wymaga poszanowania jego prac przez wszystkich innych pracowników organizacji. Wymaga też otwarcia się na innych – przez pracowników technicznych.

Wydaje się, że kluczową rolę odgrywa tutaj kierownik techniczny – CTO. To on powinien rozmawiać z programistami, mediować z biznesem, umawiać spotkania i zwiększać wspólne zrozumienie. Jeśli sam staje się zamkniętym w sobie koderem, który boi się rozmawiać z ludźmi – wszyscy w dziale zaczną takie zachowania kopiować

Dobra atmosfera

Dobra atmosfera jest ważna na każdym stanowisku. Jeśli jej brakuje ludzie stają się nieufni i zamiast współpracować, okopują się na swoich pozycjach. Dobrą atmosferę łatwo zepsuć – szukaniem winnym w razie awarii, niekonsekwencją lub faworyzowaniem członków zespołu bez jasnego, merytorycznego powodu.

Bardzo trzeba uważać z wyciąganiem konsekwencji i karaniem pracowników. Jeśli dana sytuacja nie jest spowodowana złą wolą czy ewidentnym dyletanctwem – warto poprzestać na rozmowie i wspólnie zastanowić się nad wnioskami na przyszłość. Da to lepsze efekty niż niewspółmierna do przewinienia kara, która w przyszłości spowoduje brak zaangażowania i strach przed podjęciem ryzyka.

Praca w dziale IT często wiąże się ze stresem – zdarzają się awarie i usterki na które trzeba reagować błyskawicznie i pod presją. Dobra atmosfera w dziale IT powinna budować chęć współpracy i pomocy. Dobre działy IT działają trochę jak drużyny komandosów – np. Rangersów którzy nigdy nie zostawiają swoich na polu bitwy i nigdy się nie cofają. Wiedza wszystkich pracowników jest rozproszona pomiędzy nimi, w sytuacji kryzysowej często koledzy niezwiązani z danym projektem podsuwają najlepsze rozwiązania i pomagają wyjść z opresji.

Elitarność i autorytet

Porównanie do drużyny komandosów w przypadku pomocy w sytuacjach kryzysowych to nie jedyna analogia wiążąca IT z wojskiem. Tutaj również jak w siłach zbrojnych liczy się autorytet oraz elitarność.

Działy IT to często zbiory twardych charakterów o dużej wiedzy. Aby być rozumianym i szanowanym trzeba samemu dysponować dużą wiedzą i autorytetem. Często kierownikami IT zostają najbardziej doświadczeni programiści. To jest dobre rozwiązanie o ile osoby te nie mają problemów komunikacyjnych oraz potrafią patrzeć na problemy w oderwaniu od kodu. Z biznesowego punktu widzenia. W takiej sytuacji autorytet rodzi się sam – koledzy wiedzą jakie osiągnięcia ma nowy kierownik i chętniej będą słuchali jego porad czy czasami … reprymend.

Elitarność jest bardzo ważna ponieważ pozwala budować jakość. Elitarność może być  budowana w ramach rekrutacji. Warto angażować członków zespołu do spotkań rekrutacyjnych i analizy zadań testowych. Oczywiście nie pozwalając na wyśmiewanie się z kandydatów i krzywdzące oceny. Chodzi o podkreślanie tego, że jeśli ktoś do nas dołącza to tylko dlatego, że jest najlepszy. Tak jak i my. Dlatego też trzeba uważać podczas rekrutacji. Zatrudnianie osób odstających (na niekorzyść) z doświadczeniem i wiedzą doprowadzi do zwątpienia pozostałych członków zespołu. Stracą też autorytet do osoby podejmującej decyzje.

Elitarność powoduje, że pracownicy nie pozwolą sobie na kiepską jakość. To wartość, którą mogą przywołać na każdym etapie i zawsze zapytać się siebie „Czy taki zespół jak nasz powinien zrobić coś takiego?”.

Budowaniu jakości pomaga też tworzenie różnego rodzaju kodeksów i list wartości przestrzeganych przez działa IT. Mogą być spisywane w luźnej formie, ale zawsze zawierają wiedzę gromadzoną przez cały zespół. O tym jak pisać kod, jak tworzyć nowe wersje, jak zbierać wymagania. Nowi członkowie zespołu zapoznając się z takimi materiałami od razu wiedzą jak będzie wyglądać ich praca i łatwiej integrują się z pozostałymi członkami.

Odpowiedzialność

Odpowiedzialność jest bezpośrednio związana z rozumieniem celów całego przedsięwzięcia. Rzadko kiedy programiści którzy dobrze rozumieją cele – brali udział w ich definiowaniu i projektowaniu rozwiązań – nie będą zaangażowani w ich realizację.

Odpowiedzialność za błędy i  dobre wykonanie swoich zadań jest bardzo ważna. Błędy i poprawki są na stałe wpisane w cykl tworzenia oprogramowania a często zajmują największą ilość jego czasu. Jakkolwiek trzeba uważać z wyciąganiem konsekwencji – zwłaszcza z karaniem (które pamięta się dużo dłużej niż nagradzanie) to odpowiedzialność musi być podkreślana na każdym etapie.

Warto nagradzać za dobre posunięcia, za pozostanie po godzinach i poprawianie wykrytych błędów lub własny pomysł na monitorowanie lub testowanie systemu. Zespół musi wiedzieć, co jest premiowane.

Nowe technologie

Osoby pracujące w działach IT lubią zazwyczaj technologie. Powinny lubić to czym się zajmują.

Projekty ciągnące się latami często korzystają z technologii które obecnie są już nierozwijane lub uważane, za przeterminowane. Świat IT również rządzi się w pewnym zakresie modami i trendami. Nie ma sensu zabraniać korzystania z nowych rozwiązań jeśli są uzasadnione i przyniosą korzyść.

Nowy system kontroli wersji, nowy edytor programistyczny, nowe biblioteki – może nowy framework. Warto wykorzystać tego typu zmiany do przeprowadzenia prezentacji o nowym rozwiązaniu – która poszerzy też wiedzę pozostałych członków zespołu.

Udział w konferencjach albo szkoleniach – bardzo wiele jest darmowych spotkań typu barcamp gdzie można posłuchać o nowych rozwiązanych. Wspólne wyjście na tego typu imprezy integruje zespół ale też go rozwija. Pracownicy mogą poczuć, że też są cały czas na topie jeśli chodzi o rozwój techniczny. O to przecież chodzi.

Premiowanie i docenianie rozwoju pracowników i ich szukania nowych rozwiązań bywa najtańszym sposobem rozwoju dla całej firmy. Często wystarczy słuchać i wyłapywać rozwiązania które mogą pomóc całemu przedsiębiorstwu.

Zbyt duże skupienie się na technologii i nowinkach samych w sobie może prowadzić do zapominania o celach biznesowych. Nie można do tego dopuścić.

Wymiana wiedzy

Mało jest tak dynamicznie rozwijających się segmentów rynku jak technologia. Dlatego wymiana wiedzy jest kluczowa.

Jeśli ktoś z naszego zespołu zainteresował się nową biblioteką i zrobił przez weekend jej testy – może warto wygospodarować 30 minut lub godzinkę aby przedstawił wnioski w formie prezentacji całemu zespołowi? Może rozwiąże to problem z którym pozostali członkowie się borykają? Takie wystąpienia budują też umiejętności komunikacyjne i pozwalają nabrać odwagi w kontaktach z ludźmi.

Po co to wszystko piszę?

Tomek opisał jaki jest idealny PM wg. Divante. To jest bardzo powiązane. Chcemy zatrudnić dodatkowych 8 programistów. Jeśli znasz kogoś lub sam szukasz pracy w dobrym zespole (gwarantuję przestrzeganie powyższych zasad) to napisz do mnie na pkarwatka@divante.pl. Nie pożałujesz.