Wspólnik technologiczny to ważny zasób. Warto go mieć. Jeśli go nie masz to poszukaj, podziel się z nim udziałami. To się opłaca. Jeśli nie jesteś w stanie znaleźć wspólnika, to wynajmij konsultanta - musisz mieć w projekcie co najmniej jedną osobę, która zna się świetnie na technologii, umie zastosować tę wiedzę do budowy produktu, a przede wszystkim - jest po Twojej stronie!
Jest kilka dobrych praktyk, których warto się trzymać tworząc produkt w internecie. Jak każde dobre praktyki - nie gwarantują sukcesu, ale redukują problemy i nerwy.
Często wydawaj, testuj, testuj i jeszcze raz testuj
Od początku istnienia programów komputerowych software wydaje się w wersjach. Soft internetowy ma tę cudowną cechę, że można go wydawać bardzo często i od razu trafia do wszystkich użytkowników. Nie trzeba pilnować kompatybilności ze starszymi wersjami i innych tego typu kosztownych narzutów. Można wydawać, wydawać i jeszcze raz wydawać. Każdego dnia.
Co daje częste wydanie?
1. Umiesz wydawać - wydawanie raz na pół roku sprawia, że jest to dla ciebie proces stresujący, nowy, nieprzetrenowany. Wydając raz na tydzień cały zespół nabiera doświadczenia. Programiści wiedzą co może pójść nie tak i jak to naprawić, a support wie, jak gasić ewentualne pożary w kontaktach z klientem.
2. Automatyzujesz wydawanie - zmniejszasz sobie ilość wajch, które trzeba przekręcić, żeby nowa wersja kodu wyszła na produkcje. To sprawia, że robisz to lepiej i rzadziej się mylisz. Idealnym scenariuszem jest w pełni automatyczne wydawanie, które odpalasz jednym kliknięciem, lub nawet, które uruchamia się samo po każdej zmianie w kodzie lub co określony interwał czasu.
3. Inwestujesz w testy automatyczne - częste wydawanie wymaga automatyzacji testów. Nie ma możliwości, żeby poświęcać czas na przeklikanie całej złożonej aplikacji by sprawdzić czy wszystko działa jeśli nowa wersja pojawia się raz dziennie lub nawet raz na tydzień. Automatyzowanie testów daje Ci dużo większą pewność, że nowy kawałek kodu nie popsuł starego. Nie ma nic bardziej frustrującego jak pojawiający się po raz kolejny ten sam błąd.
Planuj pracę na maksymalnie 2 tygodnie do przodu
design, development, implement, analyze Fot. Shutterstock
Ponieważ działasz szybko, szybko dostajesz opinie zwrotne z rynku, od użytkowników. Nie ma sensu planować na dłużej niż na 1-2 tygodniowe iteracje do przodu . Po każdej iteracji dowiadujemy się nowych rzeczy, każda iteracja to też lista błędów, które pojawią się nawet jeśli twój soft piszą programiści z NASA.
Jako szefowa lub szef projektu musisz mieć w głowie wizję całości, ale już Henry Ford zauważył, że skomplikowane zadanie podzielone na drobne elementy staje się dużo prostsze do wykonania. Plan na tydzień to plan wytworzenia jednego elementu, który jest albo elementem większej całości albo fundamentem, na którym powstanie coś większego i bardziej skomplikowanego.
Rób proste funkcjonalności, które potem rozbudujesz. Jeśli zrobienie czegoś trwa dłużej niż tydzień to zrób to prościej. W 99% przypadków da się to zrobić.
Komunikuj się i wyciągaj esencję z opinii zwrotnych
Planowanie nie oznacza jednak siedzenia w "pokoju prezesa" i dumania nad "jedyną słuszną drogą". Optymalny plan powstaje tylko jako wynikowa Twojej znajomości rynku i potrzeb klientów z możliwościami technicznymi Twojego zespołu i technologii.
Pamiętaj o zasadzie Pareto - często 80% potrzeb można spełnić 20% nakładów pracy zespołu . To wspólnik techniczny powinien wiedzieć i doradzić Ci jak najbardziej optymalnie wykorzystać czas i zasoby jakie macie dostępne. Często najlepsze rozwiązania pojawiają się po największych "kłótniach". Coś co wcześniej było "niemożliwe technicznie" albo "nierealne w sensownym czasie" po drobnych modyfikacjach i uproszczeniach jest do zrobienia w tydzień.
Bądź "fanatykiem produktowym"
Pamiętaj jednak, że czasami trzeba postawić na swoim. Nie ma nic gorszego niż interfejs zaprojektowany przez zapracowanego programistę . W 99% przypadków jedynie robot będzie zadowolony z interakcji z zaprojektowanym na szybko formularzem rejestracyjnym lub zamówienia. Szczególnie tak kluczowe dla każdego serwisu wąskie gardła powinny powstawać pod czujnym okiem projektanta UI lub chociaż kogoś komu, tak jak Tobie, prawdziwie zależy na zadowoleniu użytkownika.
Soft ma sens tylko wtedy gdy ktoś będzie chciał go używać. W interesie programisty jest zrobić coś szybko. To absolutnie normalne i naturalne. Interesem firmy jest jednak stworzenie czegoś czego chcą używać ludzie .
Łatwy w obsłudze software to zwykle software w którego zaprojektowanie i stworzenie ktoś włożył bardzo dużo pracy. Prostotę osiąga się skomplikowanymi środkami. Prostotę i wygodę lubią wszyscy. Wszyscy! Twoi klienci też.
Twórz procedury i sam ich przestrzegaj
Praca z osobami technicznymi jest trudna dla umysłów bardziej humanistycznych - to często dwa różne światy, dwa sposoby myślenia. Jedna strona nie rozumie problemów drugiej i na odwrót. Dlatego warto z biegiem czasu zbierać i spisywać dobre praktyki, które często dla nas mogą wydawać się oczywiste, ale dla "drugiej strony" może to być tylko jeden z możliwych i nie koniecznie najbardziej optymalny sposób działania. Buduj własną bazę wiedzy.
Oczywiście równie ważne są dobre praktyki techniczne. Dopilnuj, żeby Twój partner techniczny działał wg wybranego wcześniej schematu (frameworku) i żeby nowe pojawiające się funkcjonalności nie przypominały doklejonej do budynku koślawej przybudówki, ale raczej kolejne piętro budynku na solidnych fundamentach.
Każdy wytworzony kod to inwestycja, oprócz początkowego czasu włożonego w napisanie go zawsze pozostaje często dłuższy etap "utrzymania". Pójście na skróty , "cutting corners" to dług, który zaciągasz - dług technologiczny, który trzeba kiedyś spłacić. Jakiś poziom długu jest zdrowy, ale nierozważne zadłużanie technologiczne doprowadzi cię do bankructwa tak samo brutalnie jak dług w banku. Tu znowu nieoceniony będzie Twój partner (wspólnik) techniczny. To on powie Ci czy warto zaoszczędzić dzisiaj jeden tydzień, czy może ten tydzień będziesz potem "spłacać" przez kolejne pół roku o połowę wolniejszym tempem pracy.
To oczywiście tylko kilka najważniejszych w naszym przekonaniu zasad w prowadzeniu projektu, którego produktem jest serwis lub aplikacja internetowa. Na każdy z tych tematów powstała pewnie osobna książka. Jeśli macie podobne doświadczenia i chcielibyście dodać swoje uwagi zapraszamy do komentowania, możecie też do nas napisać na netguru@netguru.pl.
Kuba Filipowski - zarządza firmą oferującą system do rekrutacji pracowników Humanway , jest również współzałożycielem Netguru - spółki, która tworzy aplikacje internetowe.
Wiktor Schmidt - zarządza zespołem developerów w firmie oferującej system do rekrutacji pracowników Humanway oraz w firmie Netguru - tworzącej aplikacje internetowe.
