Jak powstaje produkt IT, czyli od pomysłu do przemysłu

4 maja 2018
Mikołaj Lehman

Chcesz wiedzieć, jak to jest, że zupełnie luźny pomysł klienta zamienia się po pewnym czasie w doskonały produkt? Zastanawiasz się, co trzeba zrobić, żeby aplikacja mobilna lub webowa narodziła się szybko i bezboleśnie? W poniższym artykule zdradzimy ci kilka sekretów z naszej firmowej kuchni.

1. Na początku zawsze jest pomysł

Schemat zawsze jest podobny. Na początku przychodzi do człowieka pomysł. A potem człowiek z nowo narodzonym pomysłem przychodzi do nas.

Jak wygląda taki pomysł? Czasami to tylko jedno zdanie, ogólny zarys idei. Innym razem jest to dosłownie kartka papieru lub plik zawierający coś w rodzaju wstępnej dokumentacji projektu. Zdarza się jednak i tak, że klient przychodzi do nas doskonale przygotowany, przynosząc ze sobą dokładny opis działania przyszłej aplikacji.

Podejmujemy wyzwanie

Co dzieje się potem? Podpisujemy NDA, czyli umowę o zachowaniu poufności, aby nasz przyszły klient mógł być w pełni spokojny, że jego pomysł nie wpadnie w niepowołane ręce. Zanim na dobre rzucimy się w wir kodowania i innych zajęć, musimy poznać potrzeby klienta, żeby mieć stuprocentową pewność, że nadajemy na tych samych falach. Najważniejsze dla nas jest rozumienie wizji klienta. Gruntowne poznanie jego pomysłu na projekt. Dzięki temu będziemy wiedzieć, co klient chce osiągnąć. Pomoże nam to nie tylko zaplanować prace, lecz także ustalić priorytety działań.

O co pytamy klienta?

Podczas szczegółowej rozmowy zadajemy klientowi między innymi następujące pytania:
Do kogo konkretnie ma być adresowana jego aplikacja?

  • Jakie potrzeby ma zaspokajać?
  • Jakie będą jej główne funkcje?
  • Jak będzie działać – krok po kroku?
  • Jaki jest pomysł na jej monetyzację, czyli model biznesowy?
  • Jak i gdzie będzie dystrybuowana i promowana?
  • Jak będzie wyglądał proces wsparcia klienta?
  • Jak aplikacja będzie prezentować się od strony wizualnej?
  • Podsumowując, pytamy o to wszystko po to, by nasz zespół rozumiał wizję klienta, cel aplikacji i plan jej rozwoju w przyszłości.

Ścisła współpraca z klientem na każdym etapie projektu

Tego rodzaju rozmowy z klientem powtarzać się będą na każdym etapie projektu. Przez cały czas trwania umowy. W naszym software house klient jest bowiem aktywnym uczestnikiem całego procesu produkcji oprogramowania i to z nim – lub z jego przedstawicielem – konsultujemy na bieżąco wszystkie kolejne etapy naszej pracy.

2. Etap przedprojektowy: zanim rozpoczniemy prace

Jeśli pierwszy etap zakończy się sukcesem – to znaczy wspólnie z klientem dojdziemy do wniosku, że „możemy sobie pomóc” – przechodzimy do fazy przedprojektowej. Ma ona najczęściej formę warsztatów przeprowadzanych u klienta w firmie lub online. Dokonujemy wówczas wyboru metodyki pracy (agile lub waterfall – różnicę między nimi wyjaśnimy później). Tworzymy również listę funkcji niezbędnych, by powstała minimalnie funkcjonująca wersja produktu (MVP), czyli taka, która będzie działała w podstawowym zakresie i będzie ją można udostępnić przyszłym użytkownikom, mimo że nie będzie ona zawierać jeszcze wszystkich planowanych funkcji.

Q&A, czyli pytania i odpowiedzi

Co zrobić, żeby zdobyć jak najwięcej precyzyjnych informacji na temat przyszłego produktu? Należy przeprowadzić z klientem sesję Q&A, czyli rundę pytań i odpowiedzi. Okazuje się, że nic tak nie otwiera głowy, jak odpowiednio zadane pytanie. Nawet jeśli jest ono pozornie proste. Podczas rozmowy, staramy się zrozumieć całe tło projektu. Definiujemy wówczas między innymi:
moduły produktu
kategorie użytkowników aplikacji
procesy zachodzące w aplikacji (od strony biznesowej i od strony użytkownika)

User stories, czyli wymagania użytkownika

Tworząc aplikację, trzeba postawić się w roli jej użytkownika. Zastanowić się, czego będzie od niej oczekiwał i co będzie chciał zrobić za jej pomocą. W tym celu tworzymy wraz klientem tzw. user stories. Każda z takich historii odpowiada jednej funkcji aplikacji.

Dwa przykłady user stories:
Użytkownik aplikacji chce mieć możliwość edytowania swojego zdjęcia profilowego poprzez załadowanie pliku z dysku komputera, dzięki czemu wprowadzi szybko zmianę.

Administrator aplikacji wymaga, by oferowała ona sprzedażowy raport miesięczny, dzięki czemu będzie mógł on zweryfikować liczbę płatności przychodzących z PayU.

A jeśli produkt już istnieje?
Może się zdarzyć, że tematem rozmowy jest produkt już istniejący. Wówczas poddajemy analizie technicznej:

  • dokumentację
  • kod
  • bazę danych

Pytamy również o współpracę z poprzednim teamem projektowym. Staramy się uzyskać od klienta informacje dotyczące ewentualnych problemów, z jakimi zespół musiał się do tej pory zmagać. Dalsze prace wyglądają analogicznie jak w przypadku nowego projektu.

Budżet klienta

Następnym krokiem jest poznanie budżetu, jaki klient może przeznaczyć na projekt. Jest to o tyle istotne, że każdy z procesów w aplikacji można zaprojektować i wykonać na kilka różnych sposobów. Znając szacunkowy budżet, możemy zaproponować różne rozwiązania, biorąc pod uwagę czasochłonność ich wykonania, priorytety oraz wymagania.

Jak wygląda proces wyceny?

Jeżeli na podstawie wstępnej analizy stwierdzimy, że jesteśmy w stanie pomóc klientowi, przystępujemy do procesu wyceny. Na podstawie aktualnie posiadanej wiedzy wykonujemy kosztorys, w którym szacujemy liczbę roboczogodzin potrzebnych do wykonania aplikacji. Przykładowo, 2 tygodnie pracy dwuosobowego zespołu to koszt od 15 do 20 tysięcy złotych.

Dalszy rozwój aplikacji

W kolejnych etapach bierzemy pod uwagę informację zwrotne pochodzące od użytkowników końcowych produktu oraz ustalony wcześniej plan wprowadzania funkcjonalności.

Jak rozliczamy projekty?

Stosujemy dwa rozwiązania:

  • fixed price + flexible scope
  • Fixed price oznacza sztywną, z góry ustaloną cenę za wykonanie konkretnego projektu. Flexible scope pozwala nam podchodzić zwinnie do zakresu projektu.
    time and material

W modelu time and material wyceniamy czas faktycznie poświęcony na pracę nad aplikacją – to model, który jest przejrzysty oraz korzystny zarówno dla klienta, jak i dla nas, ponieważ liczba roboczogodzin może zmieniać się w trakcie trwania projektu wraz z ewolucją pomysłu.

Wybieramy sposób projektowania: waterfall lub agile

Jeszcze kilka lat temu głównym sposobem współpracy było podejście typu waterfall. Polegało ono na spisaniu przed rozpoczęciem prac wszystkich funkcji wraz ze szczegółami. Niestety, w większości przypadków okazywało się, że po trzech miesiącach wytężonej pracy nad projektem finalny produkt mniej lub bardziej różnił się od tego, czego na początku oczekiwał klient.

Wady tej pozbawiona jest metodyka agile, w której tworzy się najpierw prototyp rozwiązania, aby na jak najwcześniejszym etapie zweryfikować, czy rozwiązanie ma działać w określony wstępnie sposób, czy też należy zmodyfikować założenia. Budując prototyp, a następnie MVP, sprawiamy, że proces weryfikacji założeń jest skrócony do minimum. To ważne, gdyż im krótsza praca nad produktem, tym niższy jej koszt dla klienta i tym szybciej aplikacja może trafić na rynek.

Czym jest MVP (Minimum Viable Product)?

Na etapie projektowym ważne jest nadanie wszystkim funkcjom aplikacji odpowiednich priorytetów. Razem z klientem decydujemy, które z nich są absolutnie konieczne, a które tylko opcjonalne. MVP (Minimum Viable Product) to zestaw funkcji, które podczas takiej właśnie analizy są określane jako niezbędne z punktu widzenia użytkownika końcowego.

Przykład aplikacji MVP dla branży e-commerce:
Zamiast wdrażać w takiej aplikacji rozbudowane funkcje (np. skomplikowane raporty sprzedażowe), kładziemy nacisk na to, by użytkownik był w stanie wykonać niezbędne czynności: zakupić produkt, opłacić go i otrzymać. Dopiero gdy okaże się, że liczba zamówień, które obsługuje system, przekracza na przykład 50 dziennie, zaczynamy pracę nad automatyzacją procesów oraz przygotowaniem modułu raportowania.

3. Realizacja projektu

Kiedy wszystko jest już ustalone, ruszamy do pracy. Tworzenie aplikacji odbywa się etapowo w tzw. sprintach (są to stosunkowo krótkie, następujące po sobie przedziały czasowe).

Zalety sprintów:

  • sprawniejsza kontrola nad zmianami w aplikacji
  • ułatwiony proces testowania nowych funkcji
  • możliwość wprowadzania zmian już na wczesnym etapie prac
  • możliwość szybszego zebrania informacji zwrotnej od użytkowników
  • krótki deadline (termin oddania projektu), co przyczynia się do zwiększenia koncentracji zespołu

Termin „sprint” wywodzi się z metodyki wytwarzania oprogramowania zwanej Scrum. Zgodnie z jej założeniami, w pracach nad produktem biorą udział trzy strony:
klient lub jego przedstawiciel (product owner)
scrum master, czyli lider, który pomaga zmaksymalizować efekty pracy
interdyscyplinarny zespół deweloperski (development team)

Scrum i zaangażowanie klienta

Tak jak już wspominaliśmy, kluczem do sukcesu przy tworzeniu aplikacji jest pełne zaangażowanie klienta w cały proces, na każdym etapie prac. Dlatego też wspólnie z nim planujemy zakres wszystkich sprintów.

Co robimy podczas pierwszego sprintu?

Zanim weźmiemy się za pierwszy sprint, podpisujemy dwie umowy z klientem:
umowę ramową (precyzującą ogólne zasady współpracy)
umowę projektową na pierwszy sprint

Czym zajmujemy się w pierwszym sprincie?

  • projektujemy makiety i wybieramy wzór stylu (szablon), który następnie będzie
  • modyfikowany zgodnie z potrzebami
  • wykonujemy prace programistyczne związane z interfejsem aplikacji
  • wykonujemy prace programistyczne związane z backendem („wnętrzności” aplikacji – czyli
  • to, czego użytkownik nigdy nie zobaczy)
  • zajmujemy się pracami organizacyjnymi
  • przeprowadzamy wewnętrzne testy

Projekt makiet

Najkrócej rzecz ujmując, makieta jest graficznym przedstawieniem pomysłu klienta. Ma ona formę klikalną i nawigowalną, co oznacza, że poszczególne ekrany są ze sobą połączone w taki sam sposób, jak w aplikacji docelowej. Choć jest statyczna, pozwala klientowi zobaczyć, jak jego produkt będzie finalnie wyglądać (przynajmniej w zarysie).

Projekt graficzny i wzór stylu

Tworząc projekt graficzny, bierzemy pod uwagę wytyczne klienta i przygotowujemy 2–3 przykładowe widoki przyszłej aplikacji. Wypracowujemy wzór stylu graficznego, który od tej pory będzie obowiązywał „na terenie” całej aplikacji, uwzględniający kolorystykę, czcionki, styl projektowania ikon i inne elementy.

Prace programistyczne związane z interfejsem

W tym etapie przenosimy ustalony układ elementów oraz wygląd (kolory, czcionki) do samej aplikacji. Ustalamy kwestie interakcji (reakcje aplikacji i jej elementów na działania użytkowników).

Prace programistyczne związane z backendem

To niewdzięczny i mało efektowny, choć kluczowy element projektu. Kosztuje wiele pracy, a efekty nie są zbyt spektakularne. Przygotowywanie backendu można porównać do prac ziemnych lub instalacyjnych podczas budowy domu. Nie są widoczne, ale bez nich budynek nie będzie w stanie prawidłowo funkcjonować. Na czym polegają prace backendowe? Między innymi na wprowadzeniu funkcji przetwarzania danych, zastosowaniu algorytmów obsługujących rozmaite procesy czy wreszcie na wdrożeniu zewnętrznych integracji (np. z systemami płatności).

Prace organizacyjne

To innymi słowy project management. Dbamy o stałą i sprawną komunikację. Rozwiązujemy problemy i minimalizujemy ryzyko opóźnień w harmonogramie prac.

Wewnętrzne testy

Działanie każdej funkcji aplikacji musi zostać gruntownie przetestowane. Podczas wykonywania wewnętrznych testów sprawdzamy, czy zachowuje się ona zgodnie z przyjętymi wcześniej założeniami.

Jak komunikujemy się podczas prac projektowych?

Wszystko zależy od etapu:

  • do momentu rozpoczęcia prac projektowych komunikujemy się przez e-mail, telefon, skype lub podczas spotkań z klientem
  • na etapie projektowym klient (lub project manager po stronie klienta) staje się członkiem zespołu projektowego, dzięki czemu komunikacja ulega maksymalnemu skróceniu

Naszym zdaniem najlepszą formą komunikacji są narzędzia online działające w czasie rzeczywistym. Jednym z nich jest Trello. Używamy go, pracując przy projektach dla naszych klientów. Tak wygląda przykładowy projekt:

Trello a user stories

Jak pisaliśmy wcześniej, na etapie wyceny projektu powstaje cała lista user stories opisujących funkcje aplikacji dostępne dla użytkowników. Co dzieje się z nimi dalej? Otóż na etapie projektowym są one importowane do Trello. Dzięki temu każdy z członków zespołu może zadać pytanie lub skomentować daną funkcję.

Jak komunikujemy się wewnątrz software house?

Codzienna komunikacja odbywa się za pośrednictwem Slacka. Narzędzie to pozwala stworzyć platformę komunikacyjną dla całego zespołu. Najczęściej uruchamiamy osobny kanał dla każdego projektu.

Udostępnianie plików

Z doświadczenia wiemy, że nie ma płynnej komunikacji bez możliwości sprawnego udostępniania plików członkom zespołu oraz klientowi. Używamy w tym celu narzędzi Google’a wchodzących w skład G Suite (są to między innymi: czat Hangout, poczta Gmail, dysk Drive, Kalendarz i wiele innych).

Jak monitorujemy postęp prac?

O co najczęściej pytają klienci? O postęp prac nad aplikacją. Dlatego też już na samym początku udostępniamy środowisko testowe na zewnętrznym serwerze. W przypadku aplikacji mobilnych dajemy klientowi dostęp do odpowiednich narzędzi, które pozwalają mu na bieżąco śledzić wprowadzane przez nas zmiany.

Jak monitorujemy czas wykonania konkretnego zadania?

Skąd wiemy, ile czasu zajęło danemu programiście wykonanie konkretnego zadania? Dzięki zastosowaniu narzędzia o nazwie Toggl, które zintegrowane jest z Trello. Rozpoczynając wykonywanie zadania, programista wciska przycisk Start, a kończąc je – przycisk Stop. Klient otrzymuje potem przejrzysty raport z wyliczonymi czasem i kosztami pracy.

Ups… mamy problem

W wyjątkowych przypadkach może się zdarzyć, że wykonanie danej funkcji okaże się bardziej czasochłonne, niż wskazywały na to pierwotne szacunki. Dlatego tak ważne jest to, o czym pisaliśmy na wstępie: ustalenie priorytetów w projekcie. Jeśli bowiem zdarzy się, że budżet projektu zostanie wykorzystany szybciej niż planowano, to jedynymi „poszkodowanymi” będą funkcje oznaczone niskim priorytetem, które są mniej istotne dla użytkownika.

Jak zapobiegamy opóźnieniom?

Na szczęście jest sposób, by zminimalizować ryzyko opóźnień. Wszystkie funkcje oprogramowania dzielimy na możliwie najmniejsze zadania (trwające np. do ośmiu roboczogodzin). Dzięki temu szybciej wychwytujemy problemy i możemy na nie reagować odpowiednio wcześniej.

A jeśli pojawi się pomysł na nową funkcję?

Może się zdarzyć, że już w trakcie prac nad projektem pojawi się pomysł na nową funkcję. Co wówczas robimy? Dokonujemy jej estymacji (oszacowania) oraz określamy priorytet. Jeśli okazuje się wysoki, funkcja trafia do kolejnego sprintu. Jeśli niski, funkcja ląduje w tzw. backlogu, czyli na liście zadań przeznaczonych do późniejszego wdrożenia.

4. Release: wypuszczenie produktu na rynek

Nadchodzi wreszcie dzień, w którym aplikacja trafia do użytkowników. Dzięki temu, że ma ona postać MVP, klient może zminimalizować koszty. Ma okazję również zebrać niezwykle cenne informacje zwrotne z rynku, dzięki którym będzie mógł dokonać w aplikacji korekt i ulepszeń.

Feedback: klucz do sukcesu

Branża IT jest szalenie dynamiczna. Nowość goni nowość. Dlatego też wypuszczenie aplikacji na rynek powinno odbywać się możliwie jak najsprawniej. Jednak samo pokazanie światu naszego produktu to dopiero połowa sukcesu. Ważne jest coś jeszcze: uważne wsłuchanie się w opinie użytkowników, czyli zebranie tzw. feedbacku.

Feedback to informacje na wagę złota. Warto być otwartym na wszelkie uwagi, sugestie i komentarze. Również te najsurowsze i najbardziej krytyczne. To właśnie one pomagają znaleźć słabe punkty projektu. Dzięki tym informacjom wydatnie wzrasta szansa na stworzenie produktu, który podbije serca użytkowników.

Jak zbiera się feedback?

Zbierając opinie, pytania dotyczące aplikacji kieruje się do możliwie różnorodnych grup osób:

  • partnerów biznesowych
  • dotychczasowych klientów
  • znajomych
  • osób zaangażowanych w tworzenie produktu
  • użytkowników testowych
  • użytkowników końcowych
  • inwestorów

Feedback z rynku

Ogromnie ważny i cenny jest feedback pochodzący z rynku. Istnieje wiele możliwości zebrania informacji na temat aplikacji. Od ankiet, poprzez heatmapy, aż po opinie w social media i bezpośrednią komunikację z użytkownikami. Warto zbierać pomysły pochodzące od tych ostatnich, ale należy uważać, by nie ulec pokusie wprowadzania wszystkich żądanych funkcji. Praca nad aplikacją właściwie nigdy się nie kończy – te, które faktycznie mają działać i spełniać oczekiwania użytkowników, są stale ulepszane i rozwijane.

cta.intresting
btn.yes
btn.no