2. Pomysł na projekt

Zacznijmy od tego, że masz pomysł na projekt, który wymaga udziału branży programistycznej.

Obecnie coraz więcej osób myśli nad własnym biznesem opartym o technologię związaną z kodem. Jeśli chciałbyś pójść o krok dalej i zdecydować się na jego realizację to zawitasz w świecie, w którym, jak już pisałam, niczym jak w książce fantasy, można stworzyć… a raczej zakodować wszystko.

Pomysł na projekt, który zrodził się w Twojej głowie, już na wczesnym etapie powinieneś zweryfikować pod względem przyszłego modelu budowania. Taka klasyfikacja jest tak samo istotna, jak analiza rynku przed wprowadzeniem na niego produktu lub usługi. Z pewnością innowacje, ze względu na brak gotowego wzorca, mogą się okazać najtrudniejszymi modelami biznesowymi.

Określ charakter swojego projektu:

1. Wzorowany na tym, co jest już dostępne na rynku

2. Podobny do tego, co już powstało, ale wzbogacony o dodatkowe funkcjonalności

3. Zupełnie nowe rozwiązanie

Jeśli chcesz pójść szlakiem, który już ktoś w mniejszym lub większym stopniu przetarł, czyli wybrałeś opcję 1 lub 2, to wystarczy wskazać wykonawcy przykład takiego rozwiązania. Chęć dodania lub zmiany poszczególnych funkcjonalności powinna znaleźć się na przygotowanej liście.

W przypadku rozwiązań zupełnie nowych, na tym etapie najtrudniejsze jest wytłumaczenie wykonawcy projektu, czy to bezpośrednio – jeśli współpracujecie z programistą freelancerem, czy pośrednio – poprzez firmę programistyczną, tego, co dokładnie zamierzasz zbudować. Błąd w jasnym przekazaniu czym Twój projekt ma być i jakie dokładnie ma mieć funkcje, potrafi na dalszym etapie skutkować wieloma nieporozumieniami, a co za tym idzie, również błędami w częściowo napisanym już kodzie. Co wtedy z takim kodem? W tym momencie zaczynają się ciągłe zmiany, które często zdają się nie mieć końca.

Kto jest winien? Wykonawca czy Ty?

Wykonawca może być winny tylko za to, że nie domagał się jasno rozpisanej instrukcji, co krok po kroku ma się dziać w Twoim systemie (i nie dziać również). Jak, w najmniejszych szczegółach, ma wyglądać interfejs użytkownika itd. Ty ponosisz winę za to, że tego nie dostarczyłeś. Jeśli decydujesz się na projekty innowacyjne, to jasna wizja takiego rozwiązania jest wyłącznie w Twoim umyśle i nikt do końca nie jest w stanie tego wiernie odtworzyć. Nie wystarczy samo przedstawienie ogólnego pomysłu i stworzenie prostej listy. Wybór sposobu rozpisania instrukcji krok po kroku zależy od Ciebie. To może być zwykły dokument Word, ale są też gotowe rozwiązania online (listę takich narzędzi znajdziesz na końcu e-booka).

Żeby lepiej to zobrazować, podam przykład.

Wyobraź sobie, że mówisz wykonawcy XY, że chcesz zachód słońca na pustyni na Dzikim Zachodzie. Po jakimś czasie dostajesz dzieło – zachód słońca na pustyni. Zgadza się. Problem w tym, że w projekcie oprócz zachodu słońca jest również mała ikona Lucky Luck’a, który konno podąża w stronę chowającej się za horyzontem gwiazdy, a gdzieniegdzie rosną kaktusy. Czy ktoś powiedział, że tego ma nie być? Zatem polecenie powinno brzmieć: słońce zachodzące nad pustynią na Dzikim Zachodzie i nic więcej. Skuteczne przekazanie informacji to wszystko, co chcemy żeby było zawarte w projekcie. Trzeba jednak pamiętać, że żeby rzeczywiście przekaz był precyzyjny, to musi zawierać również informacje o tym, czego ma nie być w finalnym produkcie. W branży programistycznej liczy się zatem absolutna dokładność w komunikacji.