Programista vs. Zleceniodawca – jak to jest? [cz. 2]

Ostatni wpis o zlecaniu prac programistom pokazał jak ciężko dyskutować o sposobach prowadzenia projektów z zasobami developerskimi. Połowa komentarzy prezentowała poziom, który był dla mnie nie do zaakceptowania (skasowane i zablokowane, moje podwórko i moje zabawki). Nic nie wnoszące ataki i wycieczki osobiste pozostały jak widać, dla niektórych, jedynym sposobem „rozmowy”. Jednak są tacy, którzy rozmawiają. Taki programista jest warty zatrudnienia… czyli dobra komunikacja to podstawa. Więcej w kolejnym wpisie! Zapraszam 🙂

W poprzednim wpisie wiele osób założyło, że sam stosuję takie uproszczone metody rekrutacji. Nie. Daję zadanie testowe (1h) + rozmowa sprawdzająca predyspozycje komunikacyjne kandydata. Nieważne czy jest to freelancer czy osoba na etat. Natomiast dla osoby, która nie ma pojęcia o programowaniu czy takich zleceniach było to swoiste ABC od czego zacząć. Nie każdy tak ja ja siedzi od kilkunastu lat w IT (jako programista i project manager).
Mniej uprzejmi programiści zaprezentowali w komentarzach następujące tezy (ekstremalne przypadki, które w większości usunąłem):

• jeśli mnie obrazisz na początku zbyt niską stawką to obrażę się na Ciebie i nie mamy o czym rozmawiać,
• pomyłka klienta w tematach technicznych to dobry temat do żartów (zjawisko „lamera”) lub ostrej krytyki,
• klient musi mieć prawie wiedzę programisty aby było w ogóle o czym gadać,
• wszelka dyskusja o sposobach kontroli pracy programisty jest porównywalna do kar cielesnych… i z pewnością ja takowe stosuję,
• tylko zatrudnianie najdroższych ma sens,
• to klient musi przekonać programistę aby mu się chciało cokolwiek zrobić,
• generalnie przygotuj się mało kulturalną rozmowę, przecież to Tobie ma zależeć,

Powyższego nie zamierzam komentować. Odpowiecie sobie sami czy z osobami z takim nastawieniem warto zaczynać współpracę. Powodem takiego podejścia prawdopodobnie jest to, że podaż zasobów programistycznych na polskim rynku jest mała, więc takie osoby dyktują warunki. Jednak powoli się to zmienia dzięki kursom online typu Codeschool.com i projektom takim jak Devbootcamp.com. Dlatego wierzę, że pewnego dnia umiejętność programowania nie będzie bardzo trudno dostępnym dobrem i wróci trochę pokory dla cudzych pieniędzy. Jednak taka sytuacja jak obecnie nie powinna pozwalać Wam na uprawianie tej patologii we własnym projekcie. O sposobach później.
Dodatkowo odniosłem wrażenie, że dla niektórych, poza stawką godzinową, nic nie ma znaczenia. Włącznie z udowadnianiem czy kandydat na zlecenie coś w ogóle potrafi. Bardzo jednostronne podejście.
Na szczęście tacy programiści są w mniejszości (mam nadzieję). Tym samym pojawiły się też cywilizowane komentarze, z którymi można dyskutować i za nie dziękuję:

• Kontrola 3 razy dziennie? Ja zwariuję 🙂 – przesadziłem, ja stosuję 2 razy dziennie przez pierwszych kilka dni aby upewnić się, że zleceniobiorca czai w ogóle co robi. Jeśli się dotarliśmy i ja i on mamy spokój.
• Po co w ogóle iteracje i kontrola? Umawiamy się na całość i nie wnikasz. – takie podejście mogę zastosować dla firmy z dużym portfolio oraz dla ludzi, których dobrze już znam. Jeśli w przeszłości w 80% przypadkach przejechałem się na pseudo developerach, to wolę na początku uważać i mieć możliwość wczesnego rozstania się.
• Jak zatrudniasz z łapanki to się nie dziw – bardzo często jest tak, że wolę programistę o mniejszych umiejętnościach, ale takiego który potrafi się komunikować, zamiast człowieka z 10-letnim doświadczeniem, który co chwila ma muchy w nosie. Często dla MVP naprawdę nie trzeba super umiejętności.
• A może problemem jest słaby manager a nie programiści? – tak jak są słabi programiści (nie tylko technicznie), tak samo są słabi zarządzający. Jednak dobry manager nie tylko dba o przyjazne i efektywne środowisko pracy (nie o tym był wpis), ale także musi optymalizować koszty wychwytując osoby, które dużo mówią a mało robią.
• Dlaczego nie zatrudniłeś kodera do szablonu w swoim zleceniu? – ja jestem PM-em, potrafię działać w Photoshop, narzędziach do prototypowania, HTML/CSS/JS (kiedyś .NET), znam UML i napisałem już kilkadziesiąt specyfikacji zmian. Ta wiedza pozwala lepiej mi się komunikować w zespole aby ludzie wiedzieli o czym mówię. Analogicznie od programisty internetowego wymagam co najmniej umiejętności zastosowania gotowych komponentów front-end, to chyba nie jest jakaś czarna magia. Elementarna wiedza o innych warstwach aplikacji jest niezbędna. A mnożenia zasobów przy MVP (bootstrap) raczej nie będę ludziom doradzał, choć oczywiście nie dam programiście zadania z zakresu webdesign. 🙂
• Skąd ty bierzesz takie ciężkie przypadki? – z życia… prawdopodobnie zlecam więcej projektów niż przeciętny (samodzielny) developer wykonuje dla innych. Jeśli sam jesteś dobrym programistą ten tekst nie jest kierowany do Ciebie, ale niestety nie wszyscy pracują tak dobrze jak Ty.
• Programista to nie tylko programowanie – zgadzam się w 100%. Dla mnie obligatoryjną cechą kandydata jest umiejętność KOMUNIKACJI. Potem umiejętności techniczne.
• Darmowe zlecenie próbne?!? – pojawiły się takie komentarze, ale nigdzie czegoś takiego nie napisałem. Płatne, próbne i małe zlecenie (pierwsza krótka iteracja) może być testem i dla programisty i dla zleceniodawcy. Oboje zdecydują czy chcą ze sobą pracować dalej. Koszt próby ponosi zleceniobiorca i często się na tym zawodzi.
• Dlaczego PHP jest gorsze? (tańsze) – pomyliłem się, stawki programisty nie muszą być niższe, ale sama technologia tak, np. tańsza od .NET.
• Startupowcy chcą wszystko za bezcen – nie chodzi o ciśnięcie stawek w dół, chodzi o mądrzejsze wydawanie własnych pieniędzy. Nie można dać się zakrzyczeć, że „tak jest” i koniec.
• Weź po prostu firmę i przestań biadolić – nie wiem czy to reklama własnej działalności czy szczera chęć pomocy. Ale płacenie w Bootstrapie 1600 zł za dzień to trochę nieporozumienie, szczególnie przy MVP. To moje zdanie.
• To programista decyduje czy stosuje komponenty – i tak i nie. Jeśli mu ufam a wycena za całość jest sensowna to niech stosuje co chce. Jeśli koniecznie chcą rozliczać się godzinowo (tak! jest dużo takich co tak chce!) to decyzja, że zastosuje coś bo tak mu lepiej niekoniecznie musi iść w parze z rozsądkiem w kosztach.

Poza tym wielu chyba nie zrozumiało czym jest Bootstrap i czym jest MVP. Pisałem o ABC dla ludzi (nie mających pojęcia jak pracuje programista), którzy za własne pieniądze chcą wypuścić wersję alpha. Minimum funkcjonalności, brak rozważań na tematy wydajności, bezpieczeństwa i właściwej architektury. To był wpis o tym jak ruszyć z miejsca z pierwszą wersją serwisu i nie zbankrutować. Jeśli pomysł wstępnie wypali (przed skalowaniem), wtedy możemy zlecić napisanie od nowa po bożemu. Jeśli MVP upadnie, to szkoda kasy na piękne rzeczy.
A teraz kolejne przypadki problemów przy zleceniach programistycznych…

Zleceniodawco, co zdarza się mówić programistom? 🙂

Tak samo jak praca Webdesignera jest rzemiosłem tak i programowanie ma być efektywne. Z jakimi problemami możesz się spotkać w trakcie realizacji zlecenia? Przykłady tekstów:

• Ta funkcjonalność jest bez sensu – to nic, że zleceniodawca (a czasem też profesjonalni ludzie od produktu) zrobili X badań i spotkali się z Y osobami aby opracować koncepcję. Zleceniobiorca wie swoje (jest mądrzejszy od badań na 1000 użytkownikach?).
• Znowu zmiana?! – jeśli programista bierze kasę to jaka różnica? Jednak warto uzasadnić sensownie dlaczego zmiana pojawiła się dopiero teraz. Nikt nie lubi 50 razy poprawiać tej samej rzeczy.
• Napiszę to od nowa… – jeśli w rezultacie zajmie to mniej czasu dla MVP niż gotowiec, proszę bardzo.
• Wziąłem inne zadanie bo tam stanąłem – „jeśli zadanie jest nudne to wezmę jakieś inne”. Może zarządzanie projektem pozostaw mi?
• Zrobię to inaczej – to może wcześniej mów mi o tym? 🙂
• Ja inaczej zinterpretowałem zadanie – cóż, za poprawność komunikacji odpowiadają obie strony. Upewnij się, że rozmawiacie o tym samym. Dobra specyfikacja i prototyp to podstawa.
• Miałem wypadek i jestem w szpitalu – dziwne, kiedyś co drugi freelancer mówił mi to w połowie projektu. Pewnie jestem straszny i dlatego chorują na serce. :)))
• Jest do testu! – wchodzę na produkt, a tam tabula raza. Przyznajcie developerzy, że Wam się to zdarza 🙂 Warto wtedy powiedzieć programiście „jak oddajesz do testu to weź zajrzyj raz czy cokolwiek działa, ja będę testował szczegóły”.

Powyższe nie ma na celu szkalowania programistów, ale poznanie głównych problemów przy współpracy z nimi. Każdy w swoim zawodzie ma jakieś wady i zalety.

Zleceniodawco, co zdarza się palnąć Tobie? 🙂

Niektórzy napisali, że jestem tendencyjny i że piszę, że programiści to całe zło tego świata. NIE. Znam zajebistych programistów. Rozwiązują problemy, a nie ich tylko szukają (ktoś zna to zjawisko?). Zrozumcie też mnie, że ten blog nie jest kierowany do programistów, ale ludzi raczkujących w e-biznesie. Daję rady im a nie programistom. Wiem jacy potrafią być klienci, o tym parę słów poniżej:

• Jezu, czemu tak drogo? – może warto znaleźć analogiczny produkt i spytać właściciela ile za niego zapłacił? Nie jest to łatwe, ale w końcu znajdzie się człowiek, który nie ma schorzenia na punkcie poufności. Wtedy zaprezentuj takie dane programiście, on też nie lubi niskich stawek „z palca” i opowieści o zaciągniętych kredytach.
• Ale to nie miało być tak – jak już wspominałem za komunikację odpowiadasz także Ty, jeśli jesteś leniwy zatrudnij analityka systemowego (spisuje m.in. wymagania na język zrozumiały dla programistów), ale to nie będzie tanie. Lepiej poczytać istniejące już specyfikacje i zapoznać się z narzędziami do prototypowania (czasem obraz mówi to samo co 1000 słów).
• „Dzień dobry, mam X zmian na dziś” – wszystkie zmiany dokumentuj w specyfikacji bo one kosztują. Bądź tego świadom. Jednak masa zmian może powodować, że aplikacja stanie się mocno niespójna pod względem technicznym i użytecznościowym. To pierwszy krok do przesunięcia końcowego terminu prac o 500% i braku motywacji programisty do dalszej współpracy z Tobą.
• No weź tam daj jakiś wygląd – moi programiści nie mają z tym problemu, ale wiem, że nie mogę oczekiwać cudów, oni nie są projektantami UI. Jednak programista obcującymi z dobrymi projektami, bywa, że ma fajny feeling. Do tego ja stawiam na programistów, którzy potrafią coś tam we front-end zrobić, np. w JS. Choć są tacy którzy uważają, że tych zakresów obowiązków nie należy łączyć, ja mam inne zdanie. Po prostu ustal na początku zakres tego co zleceniobiorca ma robić. Dokładnie. Wyjdzie Wam obu na zdrowie.
• Inne fajne teksty… – znajdziecie na Brand Junior Manager na Facebooku.

Dobre praktyki we współpracy programista – klient (głównie dla zleceniodawcy)

• Unikaj pracy na odległość – powiem krótko, w większości przypadków z przeszłości ludzie z innych miast (praca na odległość) miała poważne problemy z zegarkiem oraz używaniem maila, żeby poinformować, że o danej godzinie nie będzie ich jednak na czacie. Jeśli freelancer nie chce przychodzić do Ciebie do biura niech przynajmniej będzie z tego samego miasta. Cykliczne spotkania na żywo pozwolą lepiej go motywować. Oczywiście są osoby z daleka z przykładami prac i raczej nie mam im nic do zarzucenia, więc potraktuj ten punkt jako moją subiektywną opinię i preferencje.
• Wymagaj portfolio – jest wielu przeciwników tego podejścia, tylko ja się pytam jak inaczej możesz zweryfikować umiejętności programisty? Wydawanie 10 razy kasy na próbne zlecenie to słaby sposób na dłuższą metę. Ktoś zaproponował np. Codility (narzędzie weryfikacji umiejętności programistów). Ale to narzędzie wymaga od zleceniodawcy również wiedzy programistycznej, a ja nie kieruję tego wpisu do takich osób.
• Szukaj sam komponentów – jeśli choć trochę się orientujesz pokaż przykłady programiście (np. komponenty front-end), będzie łatwiej. On też ma swoje przyzwyczajenia, ale niektórzy z nich lubią nowinki.
• Rozmawiaj o problemach – jeśli na mailach iskrzy, spotkaj się z programistą i spróbuj z niego wyciągnąć co go boli. Ty też może robisz coś nie tak.
• „Chcę zobaczyć co zrobiłeś” (jedna z zasad Scrum) – dla programisty aspekty związane z UI mają często trzeciorzędne znaczenie. Powiedz mu dlaczego to dla Ciebie takie ważne. Ja dzięki takiemu feedbackowi mogę lepiej planować kolejne iteracje. Interakcja z wczesnym produktem pozwala mi go lepiej poczuć i ewentualnie zmodyfikować nie rozpoczęte jeszcze zadania.
• Ucz się kodowania samemu – im więcej umiesz tym lepiej orientujesz się w pracach. Nie wymagam wielkich rzeczy, ale podstawy front-end nie są super wyzwaniem. Piszę o tym tutaj.
• Unikaj ciężkich charakterów (to rada dla obu stron) – ludzie są różni, ale jeśli Twoja współpraca z drugą stroną jest tylko walką, to nie ma sensu.
• Wysoka stawka za godzinę? Zróbmy test! – umów się na 1-2 dni płatnego wykonania jakiejś małej funkcjonalności. Jeśli efektywność i komunikacja Ci się spodoba, zatrudnij człowieka.
• Spóźniasz się? To kosztuje – +1 dzień opóźnienia = -1% z wypłaty, a także -1 dzień wcześniej oddane, a niech będzie 2% więcej w wypłacie :),
• Szanuj pracę programisty – wprowadzanie wielkich i nieprzemyślanych zmian każdego dnia zniechęci każdego programistę. Także mnie. Postaraj się także unikać władczego podejścia. Sprawdź czy możecie być partnerami, to tak mało i tak wiele zarazem.
• Płać na czas – jak będziesz miał opóźnienia to on szybko znajdzie inne zlecenie. Poza tym warto być uczciwym.
• Szukaj ludzi do dłuższej współpracy – już w trakcie tworzenia MVP warto identyfikować osoby, z którymi nadajecie na tych samych falach. Jeśli produkt zażre to masz człowieka na etat (o ile się zgodzi).

Co sam kiedyś robiłem źle w zleceniach jako PM

• Generalnie jako były programista wtryniałem się w prace techniczne, które robił zleceniobiorca (w mojej firmie czy zewnętrzny). Generalnie chciałem pomóc. Kilka lat zajęło mi zrozumienie, że nie tędy droga i zarządzanie naprawdę jest pracochłonne i energochłonne. Sam wcześniej myślałem, że PM-i leżą i nic nie robią więc dlaczego nie mieli by kodować? Dzisiaj ja robię swoje oni swoje. Podejrzewam jednak, że moje samodzielne modyfikacje front-end, które dalej uskuteczniam, są im na rękę (włącznie z koderem css) zamiast zadań typu „przesuń ten przycisk 20px w lewo”. Ale głębiej już nie wchodzę.
• Dobre pisanie specyfikacji wymagań to unikalna umiejętność. To taka umowa na zakres prac. Pracowałem jakiś czas jako analityk systemowy, bezcenne. Teraz rzadko programiści mają wątpliwości o co mi chodzi. Taki atut daje mi pewność a programiście spokój.
• Kiedyś przychodziłem do programisty kilka razy dziennie (w ramach pomocy :). Dzisiaj twierdzę, że najlepszy manager to taki, który oliwi maszynę, uruchamia ją i zamyka paszczę. Wszyscy wiedzą co mają robić i na kiedy. Jedynie okres oliwienia wymaga głębszej analizy i dyskusji (włącznie z tym czy ten freelancer to uniesie?). Do tego spotkania scrumowe co kilka dni. W przypadku freelancerów zdalnie i codziennie, aby nie zapomnieli, że mój projekt istnieje.
• Jest jeszcze życie poza pracą. Nigdy nie zmuszałem nikogo do nadgodzin. Jednak nie potrafiłem rozmawiać o czym innym niż o kodowaniu. Po części dlatego przestałem być programistą, ale nie mówię, że każdy ma tak jak ja. Dzisiaj sam namawiam ludzi do przerw, wyjść, ale coś nie bardzo im się chce (zasiedzenie i wkręt). A na freelancera nie mam zupełnie wpływu.

Trochę mieszam obserwacje ze współpracy z freelancerami i programistami na etat, ale moim zdaniem te obserwacje bardzo mocno się pokrywają.
Akord czy płaca za godziny?
Zależy. Ale mocno generalizując jeśli widzę ryzyko, że programista trochę „ukwieca” swoje dokonania, to decyduję się na akord. Ale jeśli pracuję już jakiś czas z fajnym kolesiem, to czasem bywa tak, że robimy coś mocno innowacyjnego i nie wiemy czy to się uda. Wtedy nie obciążam go tym ryzykiem niewypału, bo wiem, że zrobił co mógł i płacę za poświęcony czas. Jednak nie mam jednoznacznego zdania, które podejście jest lepsze, może wy macie fajniejsze pomysły na złotą regułę dla początkujących (która oczywiście nie zadziała w 100% przypadków)?
Co do etatu/freelance… Zasadę mam prostą, jeśli jednorazowy projekt to zlecenie zewnętrzne, jeśli projekt chwyta biznesowo to ktoś go musi rozwijać, wtedy etat (np. ta sama osoba). Mam też freelancerów, którzy robią dla mnie wiele jednorazowych zleceń. Ale jeśli dalej współpracujemy to znaczy, że sobie ufamy i forma nie ma wielkiego znaczenia. Do freelancerów zaliczam też osoby pracujące na etat w innej firmie i robiące zlecenia po godzinach.
Stawki, stawki, stawki…
U niektórych osób kombinacja słów „programista”, „zarobki”, „zł”, „netto/brutto” wywołuje duże podniecenie, a to nie służy rzeczowej dyskusji. Więc pominę próbę oszacowania stawek (masz z tym problem, pisz na priv). Poza tym ile ludzi tyle opinii. Pewna firma doradcza w IT nosi koszulki z napisem „to zależy…”. Racja, wszystko jest względne, ale zanim projekt ruszy warto odpowiedzieć sobie na X pytań (do zapisania w specyfikacji) i zminimalizować ilość elementów, których jedynym opisem jest słowo „zależy”.
Powtarzając, ten wpis jest kierowany do zleceniodawców MVP, bez wiedzy technicznej. Co do innych przypadków musiałbym chyba napisać encyklopedię. 🙂 Kilka osób prosiło mnie również o napisanie konkretnego przykładu ze specyfikacją i prototypem. W moim zespole jesteśmy już na tyle dotarci, że wystarcza sam prototyp z notkami tekstowymi na nim. Ale jak odkopię jakąś to postaram się coś naskrobać.
Poza tym cały tekst dotyczy zarządzania projektami, warto wiedzieć cokolwiek o tym (czytaj tutaj).
Rzeczowe komentarze, które proponują alternatywne sposoby współpracy przy tworzeniu MVP mile widziane.
Poprzedni wpis w temacie developerów znajduje się tutaj.