Komunikacja w projektach IT to niezwykle istotne zagadnienie. Właśnie dlatego postaram się przybliżyć ten wątek. A w zasadzie nie ja, tylko niekwestionowany ekspert w tym temacie CTO Divante – Piotr Karwatka.
Marta Bąk, Marketing i Biznes: Od jak dawna jesteś związany z programowaniem?
Piotr Karwatka, Divante: Oj, od dawna 🙂 Pierwsze kroki stawiałem w końcówce lat 90, ale można powiedzieć, że od 17 lat zajmuje się tym bardziej na poważnie. To wtedy, w 2000 roku zaczęliśmy z moim bratem Tomkiem wydawanie darmowych aplikacji (freeware) na komputery Windows PC. To były czasy 🙂 Płyty CD dołączane do czasopism (np. CHIP albo CD Action) generowały wtedy większą ilość instalacji programów niż portale internetowe – czasy przed Neostradą 🙂 Później tworzyliśmy komercyjne programy dla Windowsa, wydawane na płytach CD a dopiero mniej więcej od 2002 roku zacząłem na poważnie tworzyć rzeczy związane z Internetem.
W jakiej technologii lubisz pracować i dlaczego?
Jest dużo technologii, które szanuję. W Divante stawiamy na sprawdzone rozwiązania open source – Magento, Pimcore, Symfony3, React, Vue.js. W wolnym czasie staram się pilnie śledzić rozwój ekosystemu technologii i frameworków dla języka JavaScript. Tam dzieje się obecnie naprawdę dużo. Polecam też lekturę kwartalnego raportu Technology Radar (https://www.thoughtworks.com/radar) wydawanego przez Thought Works, gdzie co wydanie znajduję nową wartą uwagi technologię do poznania.
Jednym z głównych zadań CTO jest budowanie dobrego zespołu. Czy udało Ci się wypracować model rozwoju takiego teamu?
To chyba najtrudniejsze zadanie. Mnie osobiście kosztowało to sporo wysiłku, aby nauczyć się zarządzać i tworzyć zespoły. Myślę, że dużo osób, które swoje korzenie mają w technologii, nie w zarządzaniu – tak ma. Kiedy zaczynasz prowadzić firmę, nie masz problemu ze zdefiniowaniem ról w zespole. Każdy zajmuje się tym, czym potrzeba (często wszystkim!), zespół jest mały i nie ma problemu z efektywnością. Jest bardzo efektywnie. Wszystko zaczyna się komplikować, gdy ilość osób wzrasta – w Divante przy prawie 200 osobach kilka razy zmienialiśmy strukturę firmy, by dopasować się do wyzwań – koniec końców zaaplikowaliśmy znaną np. ze Spotify strukturę opartą na Plemionach.
Nasza firma obecnie praktycznie nie ma działów (oprócz działów administracyjnych typu HR, FIN. Jesteśmy podzieleni na zespołu – tzw. Plemiona. Każdy zespół jest samowystarczalny, czyli w swoich ramach posiada wszystkie role potrzebne do realizacji projektów: Team Leadera technicznego, Project Managera/wodza, programistów, testerów, analityków, projektantów. Trudno jest zbudować zgrany zespół większy niż – to zależy – ale ok. 20 osób. Dlatego dużo firm, gdy rośnie, napotyka pierwsze problemy gdzieś w tych granicach. Ważne jest, żeby Twój zespół był stały, żeby ludzie się znali i wiedzieli kto jest w czym dobry. Warto inwestować też w komunikację – my pracujemy w SCRUM i mamy dużo rytuałów jak daily meetings, podsumowania po sprintach itd. To nigdy nie jest stracony czas. Wspólny zespołowy kanał Slack itd. Komunikacja to podstawa.
Jak wspomniałeś problem tworzy się, gdy firma wzrasta, do tego doszły u Was zmiany w strukturze. Takie rozwiązania mogą wywołać niemały chaos. Jak było w Waszym przypadku? Jak sobie z tym poradziliście? Czy slack to jedyne narzędzie, które używacie do komunikacji?
My rośniemy cały czas od 8 lat, więc chaos wywołany wzrostem to norma 🙂 Najbardziej uporządkowane są firmy na krok przed upadkiem (taki upadek może trwać wiele lat – np. taka Nokia). Tak więc, zmiany w strukturze były odpowiedzią na wyzwania, żeby firma była bardziej elastyczna a ludzie bardziej zgrani. Slack to jedno z wielu narzędzi – używamy bardzo mocno JIRY, Confluence (narzędzie typu Wiki do tworzenia baz wiedzy), jesteśmy uzależnieni od Google Suite, Hangouts od rozmów zdalnych – tych jest bardzo dużo.
Myśląc o programistach przez pryzmat mitów mamy obraz osoby, która raczej nie przepada za ludźmi. Z kim powinna umieć pracować osoba pisząca kod?
Zupełnie się z tym nie zgadzam 🙂 Uważam, że każdy powinien pracować nad umiejętnościami komunikacyjnymi, bez tego tak generalnie trudno się pracuje. Na rekrutacji zwracamy na to dużą uwagę, żeby osoby, które przychodzą do pracy, pasowały do naszej kultury organizacyjnej, i aby nam się z nimi dobrze pracowało. Generalnie osoby techniczne lubią mieć jasno ustalone, co mają zrobić. Rozwiązaniem na to jest dyskutowanie z nimi i włączanie ich do omawiania zadań, opisywanie kryteriów akceptacyjnych w zadaniach i dzielenie zadań na dość szczegółowe. My robimy to tak, że analityk po warsztatach z klientem spisuje wymagania biznesowe (BRD – Business Requirements Documents) w postaci User Stories, a programiści je jeszcze bardziej rozdrabniają na konkretne zadania programistyczne. Więc komunikacja i precyzyjność jest ważna. Osoby nietechniczne często też mają tendencję do zbyt dużego upraszczania i niechęć do słuchania / zrozumienia tego jak coś działa albo dlaczego, z czym może być problem. Warto zainwestować trochę uwagi z dwóch stron, porozmawiać f2f, żeby obie strony zrozumiały, z jakimi problemami się borykają.
Dużo w swoich prezentacjach mówisz o właściwej komunikacji w projektach IT. Jakie są najczęściej popełniane błędy przez managerów?
Nie wiem, czy jestem w stanie tutaj generalizować. Na pewno dużym problemem jest unikanie konfliktów, zbyt duży optymizm. Na wszystkich szczeblach od managerów wysokiego szczebla, przez product ownerów do programistów. Objawia się to tym, że ktoś coś obieca, a później, nawet gdy jest już w 99% pewne, że to się nie uda – nie przekazuje informacji na bieżąco, bo boi się oceny, konsekwencji itd. To zazwyczaj prowadzi do jakiegoś rodzaju tragedii 🙂 Konstruktywny konflikt to chyba najlepszy i najbardziej produktywny sposób rozmowy. Kiedyś czytałem bdb. książkę Patricka Lencioni pt. „Dead by meeting” gdzie porównuje on agendę spotkania do fabuły filmu. Powinno być jakieś rozwinięcie, punkt kulminacyjny, czyli konflikt – coś co trzyma w napięciu i dzięki i czemu nie zmieniamy kanału 😉 – a potem rozwiązanie. Faktycznie, najgorsze spotkania, na których byłem to te nudne. Zazwyczaj nic się też na nich nie ustala.
Ok, jest problem to znajdzie się i rozwiązanie, o ile go skonfrontujemy z innymi ludźmi w zespole. A jakie masz patenty, jeśli problemem jest przedłużający się projekt? Wydaje mi się, że większość osób, które lubi programować, to podaje powód zmienności projektów i nowe wyzwania.
Przedłużający się projekt to faktycznie jest częsty problem w IT 🙂 Tutaj najlepszym rozwiązaniem są częste dema z odbiorcą systemu (klientem albo działem w firmie jeśli to wewnętrzny produkt) połączone z uzmysławianiem tego, ile już spaliliśmy budżetu. Wtedy zdecydowanie szybciej podejmowane są – często trafne – decyzje: tak, można już uruchamiać, nie ma co czekać na idealny system. Projekty IT z definicji bardzo trudno się szacuje na początku, wg różnych teorii prawidłowe oszacowanie terminu zakończenia projektu IT jest możliwe po zakończeniu 50% prac. Bardzo naiwne jest w informatyce wyliczenie liczby godzin z otrzymanych od programistów estymacji i kurczowe trzymanie się tego terminu. Kiedyś pisałem o tym na naszym blogu (Divante.co/blog) kilka wpisów: doświadczony manager powinien operować umiejętnie buforami, ryzykiem i mieć plan B. Kiedyś też spotkałem się z fajną alegorią szacowania projektów IT, która porównuje ten proces do szacowania czasu dojścia z punktu A do B na mapie satelitarnej: ok 2 km. Ale po drodze okazuje się, że nie ma dróg. O, i jest kanion. A, jeszcze pasmo Alpejskie 🙂 Tak to po trochu wygląda w praktyce. W informatyce jest mało standardów i każde zadanie można zrealizować na 10 różnych sposobów, dlatego ta precyzja w komunikacji jest taka ważna.
Styczeń to czas podsumowań 2017 roku. Jakie było Twoje największe ubiegłoroczne wyzwanie?
Hmm trudne pytanie, bo nie lubię podsumowań 🙂 Dużo nauczyłem się o tym jak splatać Open Source z biznesem. Rozwijamy dwa własne produkty, które są też dostępne na licencji Open Source – Open Loyalty (http://openloyalty.io) i Vue Storefront (http://vuestorefront.io). Tworzenie własnych produktów to pole, gdzie naprawdę sporo się uczę i mam do nauczenia! 🙂
Jakie macie plany na 2018 rok. Jakie zmiany technologiczne padną w Divante?
Nie planujemy żadnych rewolucyjnych zmian, będziemy dalej trzymać się naszego kursu. Pewnie będziemy eksperymentować z nowymi technologiami i umacniać naszą pozycję na rynkach Europy. Dużo też będziemy inwestować w technologie Open Source i nasze własne produkty.
Czego mogę Ci życzyć?
Osobiście? 1000 gwiazdek dla naszego projektu Vue Storefront na Githubie (https://github.com/DivanteLtd/vue-storefront). A dla Divante – oczywiście realizacji celów, jakie założyliśmy dla firmy na 2018 rok!
Artykuł powstał dzięki:
Coders Lab
Łącząc doświadczenie edukacyjne ze znajomością rynku pracy IT, Coders Lab umożliwia szybkie i efektywne zdobycie pożądanych kompetencji związanych z nowymi technologiami. Skupia się się na przekazywaniu praktycznych umiejętności, które w pierwszej kolejności są przydatne u pracodawców.
Wszystkie kursy odbywają się na bazie autorskich materiałów, takich samych niezależnie od miejsca kursu. Dzięki dbałości o jakość kursów oraz uczestnictwie w programie Career Lab, 82% z absolwentów znajduje zatrudnienie w nowym zawodzie w ciągu 3 miesięcy od zakończenia kursu.
Zostaw komentarz