Aplikacja Alegratka - lesson learned

Parafrazując Benedykta Chmielowskiego: jaka Alegratka jest, każdy widzi. A właściwie może zobaczyć, znajdując ją we właściwym sklepie z aplikacjami i pobierając na swój telefon. A co doprowadziło do tego, że wygląda tak, a nie inaczej? W tym poście będziesz miał, drogi czytelniku, okazję zajrzeć za kulisy powstawania aplikacji.

Jak to się zaczęło?

Ciekawie byłoby, gdybym zaczął od "za siedmioma górami, za siedmioma lasami...". Ale cóż, zaczęło się bez magii, nie będę jej na siłę dorabiał. Mógłbym co najwyżej napisać: "Za Tablicą, za Gumtree, była sobie Alegratka". Konkurencja miała już aplikacje mobilne. Mi powierzono zadanie wykonania takowych dla serwisu ogłoszeń drobnych Polskapresse. Co dostałem na wejściu? Temat, budżet i, o zgrozo, termin. Przeciwko terminom zwykle nie mam nic, o ile te są realne. A co jeśli nie są? Cóż, po prostu warto i trzeba rozmawiać. Merytorycznymi argumentami można uzyskać brakujący czas, zapewniający spokojniejszą pracę i lepsze rezultaty.

Jest pomysł, co dalej?

Pomysł to dopiero początek. Zgodzicie się chyba, że hasło "zróbcie aplikację dla serwisu" to nieco za mało, aby siąść do makietowania? Pomysł trzeba skonkretyzować i zamienić na specyfikację. Zająć się tym powinien nie kto inny, jak analityk. W przypadku Alegratki analitykiem byłem ja. Nadeszła więc pora poznać bliżej produkt, jego użytkowników, ustalić jakie cele przed projektem stawia product manager oraz jakie widzi w nim nadzieje. Trzeba zapoznać się z dostępną dokumentacją, przejrzeć i opracować dane z systemów analitycznych, rozmawiać, pytać, dociekać. A gdy zbierze się już dostateczną ilość informacji, można zacząć ją syntetyzować w postaci specyfikacji wymagań oprogramowania. Ta w przypadku Alegratki nie była od razu perfekcyjna. Tworzyłem ją w kilku iteracjach, za każdym razem zwiększając precyzyjność dokumentacji, oraz szukając słabych elementów i uzupełniając braki. W ten sposób określony został zakładany zakres funkcjonalny, będący solidną podstawą do dalszej pracy.

Ok, wiemy, co to będzie robiło, ale jak?

Gdy mamy specyfikację swoich wymagań, możemy właściwie już udać się do firmy zewnętrznej i zlecić jej przekucie naszych pomysłów w aplikację. Jeśli jednak tak zrobimy, wydamy sporo pieniędzy i stracimy część kontroli nad kształtem aplikacji. Może więc przygotować makiety i userflow samodzielnie? Moim zdaniem warto. Mi dało to wiele satysfakcji, pozwoliło także pracować iteracyjnie. Wstępne makiety można konsultować, dojrzalszą wersję można skonfrontować z użytkownikami. Wszystko po to, by stworzyć bardziej intuicyjny interfejs.

Moim ulubionym pierwszym narzędziem pracy przy makietowaniu są kartka papieru, ołówek i gumka. Pozwalają sprawnie tworzyć i wizualizować ogólną koncepcję. Później można naturalnie sięgać po bardziej wysublimowane narzędzia, ale moim zdaniem kartka i ołówek mogą zostać zastąpione jedynie przez białą tablicę i pisak. Czasem warto na całość rzucić zawczasu nieco koloru, tylko po to, by bardziej pobudzić naszą wyobraźnię i jeszcze kreatywniej podejść do tworzenia.

Co jest istotne na tym etapie? Nie bać się krytyki i nie przywiązywać się zanadto do swoich pomysłów. Trzeba pogodzić się z tym, że pierwsza wersja, albo nawet kilka pierwszych wersji będzie musiało trafić do kosza po drodze do optymalnego rozwiązania.

No to startujemy!

Mamy specyfikację, mamy makiety, mamy specyfikację API, słowem wiemy, czego chcemy. Teraz, o ile nie zrobiliśmy tego wcześniej, przychodzi pora wybrać dewelopera, omówić z nim projekt, wyjaśnić z nim wszelkie wątpliwości, doprecyzować szczegóły, wynegocjować korzystne warunki umowy i podpisać ją. I wszytko zaczyna się dziać...
A co dokładnie trzeba omówić z deweloperem? Otóż może się okazać, że realizacja części z naszych pomysłów może być niesamowicie kosztowna. Jeśli zaprojektowany przez nas interfejs opiera się na niestandardowych kontrolkach, wycena projektu może pójść znacząco w górę. Dlatego po pierwsze dobrze jest, jeśli projektant interfejsu owe standardowe kontrolki zna, po drugie, jeśli coś jest drogie, a można to zastąpić tańszym rozwiązaniem o zbliżonej użyteczności, to dlaczego by z tego nie skorzystać?
Jeśli myślicie, że w tym miejscu możecie odetchnąć, przynajmniej do czasu otrzymania wersji beta, to jesteście w wielkim błędzie. Dlaczego? Bo wypracowany i zatwierdzony interfejs trzeba jeszcze dokładnie pokolorować. Pora więc popracować z grafikiem i poszukać z nim wymarzonego wyglądu aplikacji. A uwierzcie mi, że ten sam szkielet różniący się grafiką potrafi zupełnie zmieniać postrzeganie aplikacji. Ewolucja w przypadku Alegratki była naprawdę długa i wyczerpująca. Spójrzcie sami, jak zmieniała się aplikacja. Wstępne propozycje graficzne były takie:

Ładne prawda? Oglądając i akceptując grafiki, domagajcie się zamiast pięknych wizualizacji zobrazowania skrajnie brzydkiego przypadku. Źle wykadrowane zdjęcie, błąd w treści ogłoszenia, w ogłoszeniu obok brak zdjęcia. To wszystko wpłynie na ogólny odbiór interfejsu.
Tutaj mały dowód:

Hmm, jak to wygląda teraz? Gorzej? A zmieniliśmy tylko zdjęcia, wybierając kilka prawdziwych z serwisu.
Wszystko naturalnie zależy od celu, który chcecie osiągnąć, musicie mieć jednak na uwadze, że czasem warto przyćmić grafiką niedoskonałości prezentowanych przez nas treści. Może kosztować to nieco czasu i energii, oraz nerwów grafika, ale skoro znamy swój cel, to nie odpuszczajmy. W końcu uda nam się wypracować pożądane rozwiązanie.

Grafiki zaakceptowane! Teraz zostało "tylko" programowanie.

Chyba nie zdążymy...

Choć prace nad serwerem aplikacji trwały od chwili zatwierdzenia finalnych makiet, to jednak nie udało się stworzyć kompletnego, stabilnego API nim rozpoczęły się prace programistyczne przy aplikacji. Jak wpłynęło to na projekt? Cóż, z całą pewnością nie pomogło. Pojawiały się zgrzyty, szczególnie wtedy, gdy coś, co powinno działać, w praktyce działać przestawało. Zapas czasu w projekcie niknął w oczach, a tymczasem pojawiały się kolejne komplikacje. Awaria środowiska testowego, kłopoty z certyfikatami SSL, choroba głównego programisty. Trzeba było w końcu uczciwie przyznać, że nie zdążymy. I co zrobić w takiej sytuacji? Można pójść, posypać głowę popiołem i postarać się odwlec zakładaną premierę w czasie. To jednak rozwiązanie nie tylko mało przyjemne, ale i leniwe.
Przecież złoty trójkąt to nie tylko czas... Może trzeba więc poszukać więcej środków? Nie zawsze może to cokolwiek przyspieszyć (nie jestem jednym z tych PMów, którzy wierzą, że 9 kobiet jest w stanie dostarczyć dziecko w miesiąc ;) ). Pozostaje nam więc jeszcze zakres. Nikt nie lubi ciąć, ale cóż, bywa że to najrozsądniejsza opcja. Czasem można odnaleźć funkcje, których brak nie zostanie odnotowany zbytnio przez użytkownika, a które mogą pojawić się wraz z pierwszą aktualizacją. Tak też stało się w przypadku Alegratki. Świat ujrzał nieukończony projekt i nie skończył się z tego powodu... A pierwsza aktualizacja zamknęła planowany zakres funkcjonalny.
Tutaj jeszcze mała rada. Jeśli coś macie ograniczać, nie ograniczajcie drastycznie testów, szczególnie w przypadku platformy Android. Pokusa może być spora, ale to byłoby trochę jak gra w rosyjską ruletkę.

Mamy to!

Build produkcyjny gotowy, wszystko przetestowane, w bugtrackerze czysto. Niby wszystko powinno się udać, ale trema i tak jest. Premiera jest wyjątkowym, pełnym emocji dniem. Jak się na niego przygotować? Przede wszystkim warto zrobić dzień przed rachunek sumienia i pomyśleć, czy aby na pewno nic nie zostało zamiecione pod dywan. W huku towarzyszącym premierze trupy z szaf wykazują niezwykłą tendencję do wypadania. Jeśli poznamy i zrozumiemy słabości i zagrożenia, będziemy mogli przygotować plan działania. To wszystko tak naprawdę elementy zarządzania ryzykiem, ale warto o nich w przedpremierowej gorączce pamiętać.
Dobrze jest też ponownie spojrzeć na naszych interesariuszy. Czasem ktoś może mieć ukryte intencje, czasem komuś mogą zwyczajnie puścić nerwy. Postarajmy się więc uniknąć zaskoczenia, które okazał Cezar, gdy Brutus wiercił mu dziurę w brzuchu ;). Zarówno falę krytyki jak i pochwał przyjmujcie godnie, chłodno i przede wszystkim ze stosownym dystansem. Nie dajcie się nikomu sprowokować, nie popadajcie też w samozachwyt. Po prostu róbcie swoje. A osądy i rozliczenia zostawcie na dzień, w którym emocje będą mniejsze.

Sprzątamy

Hurra! Znowu nic nie wybuchło. Wszystko działa, do tego tak, jak zakładaliśmy. Naturalnie nie obyło się bez małych błędów i jednej poważnej awarii serwera. Kurz i wrzawa po bitwie opadają, świat wraca do normy. Teraz jest dobry czas na to, by podsumować projekt. Warto przeanalizować co było dobre, a co można było zrobić lepiej. Warto porozmawiać z członkami swojego zespołu, udzielić feedbacku i feedback otrzymać. Jeśli macie kolegów po fachu, warto wymienić się z nimi doświadczeniami. Wszystko po to, by kolejne projekty były jeszcze lepsze i dawały jeszcze więcej radości, kosztując przy tym mniej siwych włosów na głowie.