Dwa typy developerów – którym jesteś?
Od dłuższego czasu po głowie chodziła mi pewna myśl – w ostatnich dniach udało mi się ją wyklarować. Chodzi o dwa rodzaje developerów – biznesowych i technicznych. Jakkolwiek absurdalnie to brzmi w tym momencie, pozwól mi wyjaśnić. Warto też zaznaczyć, że pojęcia developer biznesowy i developer techniczny istnieją wyłącznie w mojej nomenklaturze – przedstawię więc jak ja je rozumiem.
Developer techniczny
Wcześniej wspomniane pojęcia przyszły mi do głowy podczas pracy na zróżnicowanych projektach. W jednych z nich lepiej odnajdowali się developerzy biznesowi, w innych techniczni. Zacznę od wyjaśnienia w jakich projektach lepiej czuli się developerzy techniczni. Były to projekty z wysoką higieną projektową. Rozumiem przez to, że architektura systemu była dokładnie przemyślana. W ramach prac nad projektem istniały ściśle określone zasady pomagające zachować porządek w projekcie. Kod był pokryty testami, sposób używania repozytorium zaplanowany z wymyślonym „flow”. Zaciągnięty dług technologiczny był w miarę możliwości regularnie spłacany. Przed każdym R&D była tworzona analiza przedwykonawcza – w ramach, której zostawało wybrane najlepsze rozwiązanie (nie zawsze najszybsze / najtańsze). Mógłbym tak wymieniać w nieskończoność – mam nadzieję, że wiesz co mam na myśli. W wielkim skrócie: projekty były prowadzone „po bożemu” jeśli chodzi o kwestie techniczne. Wcześniej opisane procedury uważam za tzw. wysoką higienę projektową. W takich projektach doskonale odnajdują się developerzy, których określam „technicznymi”. Są to tzw geeks 🙂 Projekty tego typu mają wadę – proces wytwarzania oprogramowania trwa zdecydowanie dłużej (w odróżnieniu do typu projektu, który opiszę za moment). Z moich obserwacji wynika, że developerzy techniczni nie rozumieją zbyt dobrze potrzeb biznesu, a znaczna ich część nie chce w nim uczestniczyć (w biznesie). Pomimo to, że nie chcą – uczestniczą.
Developer biznesowy
Drugi rodzaj developerów to developerzy biznesowi – zapewne domyślasz się czym odróżniają się od technicznych 😉 Istnieje wiele projektów (głównie w korporacjach lub większych firmach), które są przeciwieństwem opisanego poprzedniego przykładu projektu. Liczą się w nich głównie KPI i „targety”. Droga jaką są osiągane jest już mniej istotna – dlatego właśnie higiena projektowa nie jest utrzymywana. W takich projektach często wybierane jest rozwiązanie, które jest najszybsze / najtańsze – nie zawsze najlepsze (mając na uwadze rozwój produktu). Developerzy w nim uczestniczący często nie znają celu projektu – co wpływa na to, że często nie widzą sensu jego tworzenia. W tych projektach najważniejsze jest by nie przekroczyć terminu lub budżetu 🙂 W skrócie: business first. W takich projektach developerzy techniczni nie czują się zbyt dobrze. Zazwyczaj zmieniają projekt lub pracę. Natomiast w takim środowisku dobrze odnajdują się developerzy biznesowi. Często nie przerażają ich wyzwania (mała znajomość technologii). Zaciągają dług technologiczny, żeby skończyć zadanie tak szybko jak to możliwe. Rozumieją biznes i się w niego wpasowują. Z moich obserwacji wynika, że developerzy biznesowi szybciej szukają rozwiązań problemów. Często dostrzegają większą analogię między wcześniejszymi problemami i rozwiązaniami – to pozwala im się szybko adoptować do nowych projektów i szybciej stają się w nich produktywni. Zauważyłem również, że developerzy biznesowi w projektach z wysoką higieną projektową są postrzegani jako niedokładni. Ich kod zazwyczaj trzeba dokładniej testować ponieważ zawiera więcej błędów w porównaniu do kodu developerów technicznych.
Podsumowanie
Nie chcę generalizować na temat typów ludzi pracujących przy projektach – są to moje obserwacje, z których wynika, że można wyodrębnić dwie grupy. Absolutnie nie mówię, że któryś typ jest bardziej wartościowy od drugiego. Nauczyłem się, z perspektywy czasu, że trzeba przypisywać właściwe zadania, właściwym osobom. Gdy rozmawiałem z programistami o moich spostrzeżeniach, pytałem, o to, do której grupy się zaliczają – większość z nich twierdziła, że zdecydowanie czują się developerami technicznymi. Mówiły to nawet osoby, które uważałem za skrajnie „biznesowych” developerów. Wydaje mi się, że jest to spowodowane tym, że postawa developera technicznego jest postrzegana jako „jedynie słuszna” – z czym nie do końca się zgadzam. Jeśli jesteś programistą – spróbuj się określić – daj znać w komentarzu. Mam nadzieję, że pomogłem ci skategoryzować projekty w twojej głowie – szukając nowych projektów / pracy możesz wypytać o specyfikę prowadzenia projektu i tym samym określić czy będziesz się w nim dobrze czuł. Natomiast jeśli jesteś kierownikiem projektu i przypisujesz zasoby do projektu – staraj się dopasowywać typ osobowości developera do typu projektu. Będzie łatwiejsza współpraca – większa wydajność, mniej konfliktów i nieporozumień.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
Sytuacja z autopsji: zespół „technicznych” purystów (w tym nie tylko developerów) zarządzany przez biznesowego leada. Efekt – wszyscy członkowie zespołu zwolnili się z pracy w trakcie trwania projektu (oczywiście nie jednocześnie, ale projekt kończył zupełnie inny zespół niż go rozpoczynał ;))
a zespół, który go dokończył był bardziej „biznesowy”?
Ciężko powiedzieć, bo składał się prawie z samych studentów 😉
Karolu, świetne spostrzeżenie, dzięki za nie.
Czuję się bardziej deweloperem biznesowym niż technicznym, i to mimo spędzenia w przeszłości 3 lat w Kalifornii i pracy w Google’u.
Bardziej cenię sobie dojście do celu przy pomocy oprogramowania niż żmudne i superdokładne dbanie o spełnianie wszystkich punktów metodyki, pisanie testów do każdej funkcjonalności itd.
Jak się już gdzieś dojdzie w szybki sposób i jest potrzebne „utwardzanie” kodu, to wtedy to dopiero robić.
Pozdrowienia!
Dzięki za komentarz – cieszę się, że mogłem pomóc 🙂
Dawno nie czytałem wpisu, który wzbudziłby we mnie takie emocje, kompletnie się z tym podziałem nie zgadzam.
Dla mnie synonimem kategorii, którą opisałeś jako deweloperzy biznesowi są deweloperzy niedoświadczeni i słabi. Oczywiście nie ma znaczenia, kto napisze projekt, który trwa 3 lub 6 miesięcy, bo jest to małe rozwiązanie i nawet duży dług techniczny takiego projektu nie zabije. Ale przy projektach dużych z olbrzymim biznesem, trwających latami, jak nie będzie się zważać na standardy i minimalizować długu technicznego, to prędzej czy później dochodzisz do ściany, przy której nie jesteś już w stanie szybko lub w ogóle wprowadzać nowych funkcjonalności (byłem tam, brałem udział w tych upadających projektach). Z drugiej strony do kategorii deweloperów technicznych zaliczyłbym tych programistów, którzy są doświadczeni i słabi (albo bez zdolności dostosowywania się). Z takimi też pracowałem, szybko zmieniają pracę, starają się na siłę wszystkim wciskać swoje ideologie i stosują się tylko do standardów przyjętych przez siebie (np. zawsze najświeższa biblioteka, nawet w wersji beta).
Więc przepraszam, ale w moim mniemaniu mamy słabych deweloperów, którzy idą szybko do celu nie zważając na dług techniczny i na krótką metę to działa. Po drugiej stronie mamy innych słabych deweloperów, którzy mają doświadczenie, ale mają de facto gdzieś biznes, liczy się dla nich tylko zabawa z najnowszymi technologiami. A gdzieś po środku są poważni deweloperzy, którzy wiedzą jak robić oprogramowanie, stosują się do wzorców projektowych, do ogólnie przyjętych standardów, jak i do tych przyjętych w projekcie. Tacy deweloperzy są blisko biznesu, wiedzą też kiedy trzeba olać pisanie unit testów, czy przepisanie jakiejś części aplikacji, bo nie ma na to czasu, a jednocześnie tworzą kod wysokiej jakości, dlatego projekt jest w stanie przetrwać nawet i bez tego.
Dzięki za komentarz 🙂
Każdy projekt ma pewien limit długu technicznego jaki da się w nim zaciągnąć – po przekroczeniu pewnego progu nie da się go rozwijać. Wiele osób najchętniej by go wtedy „zaorało” i napisało od nowa. Wbrew pozorom w większości projektów ten moment tak szybko nie nadchodzi. Jest na pewno wiele projektów z ogromnym długiem technologicznym, ale wciąż działających. Klient często rozumie tą sytuację i da się mu wyperswadować, że „tego się nie da zrobić bo [xyz]”. Te projekty biznesowe są kompromisem z obu stron – mam wrażenie, że inaczej to rozumiesz. W takich projektach developerzy techniczni z chęcią powołali by się na klauzulę sumienia podczas rozwiązywania zadań „bo da się to zrobić lepiej”. Natomiast druga grupa lepiej rozumie sytuację i potrafi się w niej odnaleźć 🙂
Zgadzam się z spostrzeżeniem co do zachowań sa developerzy. Develper businessowy powinien chyba byc podzielony na 2 rodzaje tacy którzy patrzą tylko na to aby zakończyć zadanie jak najszybciej, nie przejmuje sie długiem itd. oraz takich, którzy potrafią połączyć technologiczna stronę z oczekiwaniami biznesu. Starają się wykonać zadanie optymalnie przy zachowaniu jak najmniejszego długu technologicznego a jednocześnie tak zeby biznes byl zadowolony. Wiadomo czasem przeoranie jakiejś części kodu jest konieczne, ale biznes musi o tym wiedzieć, znac powód dlaczego dany feature tego wymaga i podjąć decyzje czy akceptuje wydłużony czas realizacji czy rezygnuje z danej funkcjonaliści. Komercyjne programowanie to nie sztuka dla sztuki, ktoś zamawia „usługę” i za nia płaci.
@Przemek:
mi się wydaje, że ten podział, o którym mówisz istnieje wszędzie – są to tzw profesjonaliści i nieprofesjonaliści 😉
Od prawie 2 lat pracuję w zespole dwu osobowym gdzie ja jestem tym biznesowym a drugi programista jest techniczny. Dostrzegłem to już na początku naszej współpracy, ale uważam że świetnie razem się uzupełniamy.Ja szybko „ogarniam” tematy biznesowe i rzucam wiele pomysłów szefostwu, a drugi programista czuwa nad architekturą systemu. Moje tematy są kończone 2-3 razy szybciej, jednak wcale nie produkuję więcej bugów, raczej mamy po równo – co jest odmienne z tym co piszesz. Wynikać to może z mojego większego doświadczenia (7 lat) w stosunku do 4 kolegi. Niemniej, uważam że jesteśmy świetnym „zespołem” i pracuje mi się w takim układzie najlepiej jak dotychczas.
Ja jestem developerem zdecydowanie biznesowym. I nie zgadzam się z tym, co napisał @rz, że developer biznesowy, to ktoś, który zrobi sieczkę w kodzie (ale działa!). Tutaj trzeba umieć równoważyć i być po środku, tzn. dbać o kod, ale też wiedzieć, do czego dążymy.
to czego jako dev biznesowy nie lubię, to przerostu formy nad treścią, podam przykład z życia: zastosowałem switcha, który miał 5 case’ów. Na code review to nie przeszło i stwierdzono, że tutaj by wypadało strategię zrobić. Westchnąłem i zrobiłem. Strategię, fabrykę, jeszcze jedną strategię do walidatorów itd. Efekt? Z jednego switch’a z 5 case’ami powstało 8 klas, a logika w jakiej to wszystko pływało była jak dla mnie średnio przejrzysta. Fakt, na pewno bardziej elastyczna i modyfikowalna, ale serio? GDYBY ktoś kiedyś potrzebował to JESZCZE BARDZIEJ zmodyfikować, to wtedy można było myśleć nad strategiami, fabrykami i innymi singletonami ;). Na tamtą chwilę switch wystarczał. No ale koniec końców wszyscy byli zadowoleni. Tylko nie ja.
pozdrawiam 🙂
Chyba słowem klucz jest „umiar” i „złoty środek” 🙂