90% pieniędzy w Twoim startupie idzie na zarobki programisty? A gdzie środki na marketing, biuro i inne? Uwierz mi, że sam produkt nie wystarczy. A więc jak ograniczyć koszty implementacji? Zapraszam na 2 wpisy w tym temacie.
W ostatnim czasie dostałem kilka zleceń remodelowania nieudanych e-biznesów. Kiedy klient (nietechniczny) opowiada mi o dotychczasowych kosztach developmentu jego produktu to włosy mi się jeżą na głowie. Ludzie biorą kredyty na projekt, a zarobki programisty konsumują je w ekspresowym tempie, dostarczając marnej jakości witrynę. Na inne działania nie zostaje nic.
Zarobki programisty – krótka historia krótkiej współpracy…
Sam kiedyś popełniałem te same błędy i bezkrytycznie przelewałem pieniądze osobom programującym stronę, bez wnikania czy rzeczywiście na to wynagrodzenie zasługują. Moje podejście zmienił kilka lat temu niżej opisany projekt.
Swego czasu zleciłem programiście PHP wykonanie serwisu parentingowego (rozliczenia co tydzień). Przygotowałem dokładną specyfikację i prototyp dla MVP. Umówiliśmy się na używanie istniejących komponentów np. dla warstwy front-end. Zaczęliśmy od implementacji rejestracji i logowania (E-mail, Facebook).
Po pierwszym tygodniu przyszedł czas rozmowy i wypłaty. Programista poinformował mnie, że na razie przygotowuje środowisko dla aplikacji i rozplanowuje funkcjonalności (jedną?). Jakoś przełknąłem brak jakichkolwiek efektów, które mógłbym zobaczyć. Kasa poszła.
Na koniec drugiego tygodnia zobaczyłem stronę główną i rozpocząłem proces rejestracji zarówno e-mailem jak i Facebookiem. Pomimo dokładnego wyspecyfikowania, na formularzu nie było walidacji (sprawdzanie poprawności wypełnienia pól). Zero informacji o złym formacie e-mail, brak podświetlania niewypełnionych pól, a formularz generalnie wyglądał jakby spadła na niego bomba.
Programista powiedział, że walidacja to pikuś a reszta poprawek zajmie góra 1-2 godziny. Jednak następnej niedzieli wiele się nie zmieniło. Zapytałem w końcu czy zastosował jakiś komponent (kontrolkę) formularza rejestracji/logowania (w specyfikacji podano przykłady). Odpowiedział „NIE”. Dlaczego? Bo pomyślał, „że JEDNAK napisze to sam od nowa”… Wypłaciłem ostatnią tygodniówkę i pożegnałem się.
I tak kasa na zarobki programisty poszła de facto na nic.
Jeśli mówię Ci MVP to nie wymyślaj koła na nowo…
Pisząc ten artykuł mam na myśli projekty głównie typu boostrap (własne finansowanie) z ograniczonym budżetem, które współpracują zdalnie z programistami-freelancerami czy pracownikami innych firm, którzy świadczą usługi po godzinach.
Po pierwsze, przy małej kasie opłaca się stosować Lean Startup (nauka potrzeb userów w krótkich iteracjach). Dlatego jak najszybciej wypuść minimalną wersję produktu (MVP). Ma to na celu szybki feedback, ale także minimalizację środków przeznaczonych na zarobki programisty. Ale jak nie zbankrutować przy wydatkach na implementację samego MVP?
Mów programiście, że zależy Ci na podstawowej funkcjonalności (mały zakres), ale żeby UI i zdarzenia na nim były zgodne z konwencjami usability (np. wspomniana walidacja), które stanowią o jakości i są ważne dla użytkownika. Jeśli zajmie się tzw. „pierdołami”, bo fajnie mu się to robi, to jest to pierwszy krok do plajty.
Kilka zasad, które musisz stosować aby programista robił to co trzeba (przy MVP):
- Każ mu stosować komponenty – czyli gotowce. Jeśli nie wie o czym mówisz to albo zatrudnij kogoś innego albo sam je wyszukaj i wyślij mu link, np. do Twitter Bootstrap.
- Rozmawiaj z nim 2-3 razy dziennie – bez takiej kontroli i z rozliczeniami godzinowymi Twoje pieniądze skończą się bardzo szybko na zarobki programisty, a MVP dalej będzie w powijakach.
- Zarządzaj priorytetami – pytaj często programisty nad czym aktualnie pracuje, jeśli 2 dni już siedzi nad kompletnie dla Ciebie nieistotnym elementem, przerwij to i daj mu ważniejsze zadanie.
- Każ mu pokazywać efekty jego prac we front-end – jeśli Twoja witryna posiada funkcjonalność zbieżną z tą, które ma połowa witryn w Internecie (tylko inaczej nazwaną), głównie opcje społecznościowe, to po tygodniu prac nie ma żadnego uzasadnienia aby dalej grzebać wyłącznie w back-end i raportować o pracach, których nie możesz zobaczyć (skontrolować). No chyba, że planujesz budowę kalkulatora online do liczenia leasingu kapitałowego w walucie obcej. 🙂
- To ma działać i się nie wywalać dla ruchu X – kwestie bezpieczeństwa, skalowalności, elastyczności są w MVP nieważne. Określ maksymalny ruch, który chcesz obsłużyć. Jeśli MVP wypali (ludzie to pokochają) dopiero wtedy zainwestuj w refactoring kodu np. pod większą wydajność.
- Rozliczaj się na akord lub za całość – podziel zakres na 5 sprawdzalnych w UI części i umów się na kasę po każdej z nich. Jednak najlepiej płać za całe MVP. Wtedy musisz mieć dokładną specyfikację. Uzupełniaj ją o prototyp.
- Karz za opóźnienia – ja stosuję: +1 dzień opóźnienia = -1% z wypłaty. O ile nie wprowadzam zmian w trakcie projektu, które kosztują dodatkowy czas i pieniądze. Ale staram się to minimalizować.
Zarobki programisty
Skoro rozmawiamy o kosztach wspomnę o stawkach w najtańszej technologii back-end dla projektów internetowych, czyli PHP/MySQL. Możesz zastosować taki cennik (NETTO):
- 15 zł – początkujący bez portfolio (co najmniej jeden projekt akademicki).
- 40 zł – programista, który ma dostępne portfolio (np. 3 projekty do sprawdzenia),
- 60 zł i więcej – doświadczony programista, kilka lat + sprawdzalne portfolio.
Każdemu klientowi, przy okazji zmian biznesowych, doradzam lepsze zarządzanie operacjami (w tym zasobami programistycznymi), dla optymalizacji kosztów i ich zrównoważenia np. dla uzyskania większych środków na marketing. Jeśli nie dbasz o kasę, to nawet najlepszy pomysł nie urośnie. Te działania są podstawową częścią zarządzania projektami. Nie zapomnij o niej.
Już teraz dbaj o częstą komunikację przy produkcji MVP i zlecaj najważniejsze zadania bez wyważania otwartych drzwi (komponenty).
A tutaj znajdziesz kolejny wpis z serii o developerach.
Dodaj komentarz