Jak CEO powinien pracować z programistami 👨💻
Zacznijmy od rekrutacji
Jeżeli nie masz wiedzy w tym zakresie, nie rekrutuj ludzi z IT. Lepiej poszukaj zaprzyjaźnionego programistę, który pomoże Ci w tym problemie. Tylko nie może to być osoba flegmatyczna bez umiejętności interpersonalnych. Takie osoby z reguły mają rozbudowaną wiedzę w swojej dziedzinie, ale niekoniecznie będą zwracać uwagę na umiejętności miękkie swoich kandydatów. Jeżeli nie znasz takowej osoby w swoim najbliższym otoczeniu proponuję przejrzeć Linkedina, możesz użyć swojej sieci kontaktów, albo poszukać programistów z dużym doświadczeniem i ich zaczepić na serwisie. Możesz także skorzystać z firm IT oferujących tego typu usługi lub odezwać się do nas.
Kiedy posiadasz już swój zespół programistów możliwe, że wyznaczysz osobę (co bardzo rekomenduję) odpowiedzialną za dalszy rozwój zespołu, produktu od strony technicznej oraz jego utrzymaniu, czyli tzw. CTO. Natomiast jeżeli nie masz takiego kandydata, albo po prostu posiadasz zespół samo organizujący się, będziesz musiał o wiele częściej komunikować się team’em. Co zapewne już robisz i przeklinasz każdy dzień z nimi 😉.
Przecież jak to możliwe, że programiści nie są w stanie określić ile zajmie im zaprogramowanie danej funkcjonalności, albo dlaczego ten soft wiesza się za każdym razem, gdy masz demo z klientem!? Powodów jest wiele i nie zawsze występują one wszystkie na raz, ale zapewne przeszedłeś to w swojej firmie.
Wiem że ci się uda
Programiści często ulegają presji kierownictwa. Nie wiedzą, że mogą powiedzieć “Nie”, “Nie jesteśmy w stanie tego zrobić”. Bo, czy nie zdarzyło ci się powiedzieć “Ten termin jest wyjątkowo ważny, wierzę, że ci się uda”, a niekiedy nawet ostrzej?
Programista z mniejszym doświadczeniem, przytaknie i powie “ok, spróbuję”, ale on już w duchu wie, że szanse są marne. Natomiast programista, który jest profesjonalistą, wytłumaczy ci dlaczego dana funkcjonalność nie może zostać wykonana w danym czasie oraz powinien poszukać z tobą alternatywnego rozwiązania.
Dobrą praktyką jest kilkukrotne upewnienie się, czy programista zdąży na czas, czy termin jest możliwy oraz dowiedzenie się jakie problemy mogą wystąpić w danym rozwiązaniu.
Chęć zrozumienia
Jak wspomniałem powyżej dobry programista powinien przedstawić ci alternatywne rozwiązania oraz plusy i minusy każdego z nich. A ty na tej podstawie powinieneś podjąć decyzje biznesowe. Tą kwestię można przyrównać do pracy lekarza, albo prawnika. Przedstawia on swojemu klientowi różnego rodzaju wyjścia z sytuacji, czy też leczenia na daną chorobę. Mówi o ryzyku jaki się z tym wiąże, sugeruje najlepsze rozwiązanie, ale ostateczną decyzje podejmuje pacjent/klient.
Porozmawiaj z programistą o alternatywnych rozwiązaniach. Nie zawsze muszą być strikcie techniczne, niekiedy okazuje się że można dany problem rozwiązać na poziomie procesów biznesowych. A to niejednokrotnie jest tańsze niż implementacja skomplikowanej funkcjonalności.
Po co wam te testy, przecież to niepotrzebny koszt!
Niekiedy programiści proszą, aby przeznaczyć pewien czas na pisanie testów, czy to jednostkowych, funkcjonalnych, czy ogólnie jakichkolwiek automatycznych. Lecz ty uważasz, to za zbędny koszt. Przecież czas pisania funkcjonalności wydłuży się. Nic bardziej mylnego! Czy ty chciałbyś jeździć samochodem, albo lecieć samolotem, którego podzespoły, albo oprogramowanie nie przeszło restrykcyjnych testów!? Jestem pewien, że dwa razy zastanowił byś się przed wejściem do takiego pojazdu. Na dodatek, jest to złudne wyobrażenie. Długoterminowo pisanie testów jest o wiele tańsze.
Załóżmy, że masz średnio rozbudowany system (ok. 50 przypadków testowych), który po każdym wdrożeniu trzeba przetestować. A to logowanie, a to tworzenie nowego konta, wystawienie faktury i wiele wiele więcej. Załóżmy też, że potrzeba minimum 3 środowisk dla twojego systemu (lokalny u programisty, testowy i produkcyjny). Jeżeli masz większy zespół musisz doliczyć jeszcze testy pomiędzy programistami (środowisko lokalne u programisty * ilość programistów). Dla większej pewności powinno testować się cały serwis. A to daje naprawdę pokaźną ilość testów!
Załóżmy, że mamy 50 testów dla całego systemu oraz 3 programistów w zespole.
50 testów * 3 programistów = 150 testów na środowisku lokalnym powinien wykonać programista każdego dnia importując zmiany kolegi, aby mieć pewność, że wszystko działa.
Te same 50 testów trzeba pomnożyć przez kolejne dwa środowiska.
50 testów * 2 środowiska = 100 testówZałóżmy, że każdego dnia mamy wdrażanie systemu na produkcję to daje nam:
150 testów u programistów * 20 dni w miesiącu + 20 dni * 100 testów na teście i produkcji = 5000 testów wykonywanych manualnie przez testerów.
Czy nie lepiej więc oddać tą monotonną czynność w “ręce” maszyny. Nie dość, że w mniejszym tempie będziesz musiał rozbudowywać zespół testerski to i programiści będą mieli większą pewność w działaniu systemu. Test pisze się tylko raz, a będzie on działał, tak samo, czy to przez 6, czy 12 miesięcy.
Dlatego jeżeli programista prosi o możliwość pisania testów, pomyśl o tym jako o inwestycji w firmę. Wiadomo zwiększy się czas na tworzenie testu, lecz tym samym zredukujesz ilość etatów działu QA.
Znowu nie działa
Tworzenie testów ma jeszcze jedną wielką zaletę. Programiści nie boją się poprawiać stary kod, a i dodawanie nowych funkcjonalności jest o wiele przyjemniejsze. To z kolei przyśpiesza ich tworzenie, co przekłada się na mniejsze koszty (w długoterminowym aspekcie). Wiem, że może ci się wydawać dziwne poprawianie czegoś, co już zostało zrobione i za co zapłaciłeś. Lecz jest to naturalna kolei rzeczy. To tak jak by mieć ogród. Jeżeli nie będziesz o niego nieustannie dbał, przyjdzie czas, gdy chwasty przejmą nad nim kontrolę, a ty usłyszysz — “trzeba przepisać cały system od nowa”.
Jeżeli więc programiści dysponują grupą testów, które nieustannie sprawdzają działanie systemu oraz tworzą nowe, wraz z rozwojem produktu, twój ogród jest nieustannie pielęgnowany. Tym samym oddalasz wizję przepisania wszystkiego na nowo lub nawet pozbywasz się jej całkowicie. A i stabilność działania systemu będzie o wiele większa.
Porozmawiaj z programistami na ten temat. Dowiedz się czy używają testów. Jeżeli nie, zachęć ich do tego. Na początku może iść im trochę wolniej, lecz w dalszej wizji rozwoju ma to nieocenioną wartość. A i ty będziesz spał spokojniej wiedząc, że dostarczacie swoim klientom produkt o wyższej jakości.
Jest to tylko niewielka ilość przykładów, które poprawią twoje stosunki z programistami. Oni zobaczą, że rzeczywiście interesujesz się ich pracą, chcesz jak najlepiej dla produktu i swojego biznesu. Podejmiecie wspólny dialog, dzięki, któremu obie strony zrozumieją swoje stanowiska lepiej. Ty zrozumiesz zmagania techniczne, a programiści zobaczą z jakimi problemami zmaga się biznes. Rezultatem tego wszystkiego będzie zmniejszenie ilości błędów w systemie oraz podniesienie jakości produktu. Typowe win-win.
Posiadasz startup i nie wiesz w którym kierunku udać się dalej. Zgłoś się do nas.
Mamy za sobą 10 lat pracy przy 15 startupach, postanowiliśmy stworzyć inicjatywę, która na celu ma wspomagać startupy od strony biznesowej, brandingowej, marketingowej oraz technologicznej. Wspomożemy Cię naszym know-how! 🚀
Nasza grupa składa się z:
Dariusz Ciesielski — Skapiec.pl, Grupa NK.pl, Chatpirate, TeamRock i inne
Błażej Szperlinski — Livechat, CrankWheel, Chatpirate, TeamRock i inne
Anna Rakoczy — Career Expo, DevCamp, TeamRock
