Stworzenie dobrej aplikacji społecznej nie jest proste, z kilku powodów jest nawet trudniejsze od przygotowania aplikacji biznesowych. Poniżej przedstawiamy najczęstsze błędy popełniane podczas ich projektowania, tworzenia i wdrażania wraz z krótką receptą co zrobić aby ich uniknąć. Oczywiście nie wszyscy twórcy tego typu aplikacji je popełniają. To krótkie podsumowanie nie ma na celu wystraszenia chętnych do realizacji społecznych aplikacji, ale ma zachęcić do krótkiej refleksji i pomóc w ograniczeniu ryzyka podczas ich powstawania.
Aplikacje społeczne przyczyniają się do rozwoju społecznego i rozwiązywania społecznych problemów. Z założenia posiadają pewną misję i angażują użytkowników do jej realizacji lub zainteresowania się określonymi kwestiami społecznymi. Pozwalają, z wykorzystaniem nowoczesnych technologii, wpływać na otaczająca nas rzeczywistość. Często są też tworzone społecznie, czyli bez finansowych korzyści i są pozbawione biznesowego celu. Przykładowe aplikacje społeczne można znaleźć np. w katalogu aplikacji ApSy stworzonym przez ChomONto: http://aplikacjespoleczne.pl/aplikacje.
A oto nasza lista 12 najczęściej popełnianych błędów:
Przed rozpoczęciem pracy nie robimy rozpoznania, nie sprawdzamy czy istnieją już podobne rozwiązania oraz jaką mają popularność wśród społeczności, do której adresujemy aplikację. Czas i wysiłek potrzebny na uniknięcie tego błędu nie jest duży a pomoże zaoszczędzić wiele pracy i rozczarowań. Tworzenie konkurencyjnych rozwiązań nie jest oczywiście pozbawione sensu, ale warto to robić z pełnym przekonaniem, po przeanalizowaniu już istniejących aplikacji, upewnieniu się, że kolejna jest potrzebna i określeniu istotnych wyróżników. Jest to szczególnie istotne dla aplikacji tworzonych społecznie, lepiej nasz wysiłek skierować tam gdzie gotowych rozwiązań jeszcze nie ma i wspierać istniejące, niż z nimi konkurować.
Pytania kontrolne:
Czy istnieją rozwiązania realizujące mój pomysł? Czym się mogę od nich odróżnić lub czy jest szansa na współpracę?
Widzimy problem i tworzymy rozwiązanie zgodnie z naszym wyobrażeniem, nie próbując poznać opinii tych, których problem również dotyczy. Nieokreślenie lub złe określenie grupy docelowej naszej aplikacji, a w konsekwencji nie poznanie jej cech, oczekiwań i przyzwyczajeń skutkuje stworzeniem rozwiązań, które nie będą adresowane do właściwych osób, będą dla nich niezrozumiałe lub nieadekwatne do potrzeb. Upewnienie się, że podobne rozwiązania jeszcze nie istnieją problemu nie rozwiązuje – może to nie jest przypadek i takich aplikacji nie ma ponieważ się nie sprawdziły, a nie dlatego, ze nikt wcześniej nie wpadł na taki genialny pomysł jak my.
Pytania kontrolne:
Do kogo adresuję moją aplikację? Czym charakteryzuje się ta grupa?
Nawet po właściwym określeniu grupy docelowej możemy źle zdiagnozować jej potrzeby i problemy, z którymi się boryka. W konsekwencji stworzona aplikacja nie będzie się skupiać na kluczowym problemie lub będzie wręcz generować kolejne. Zweryfikujmy problem z innymi zainteresowanymi, może widzą go w szerszym świetle, inaczej określają jego przyczyny lub tak na prawdę leży on gdzieś indziej. Zapytajmy adresatów jak często by korzystali z aplikacji i w jakich sytuacjach.
Pytania kontrolne:
Jaki jest kluczowy problem, który chcę rozwiązać? Czy faktycznie jest on istotny dla grupy docelowej?
Właściwa identyfikacja grupy docelowej oraz określenie jej potrzeb i prawidłowa definicja problemu nie gwarantują jeszcze pełnego sukcesu. Wykorzystanie nieodpowiedniej technologii może być przyczyną porażki, gdy adresaci z uwagi na wiek, lokalizacje, bariery technologiczne, brak umiejętności czy inne czynniki nie będą w stanie skorzystać z naszego rozwiązania. Aplikacje wykorzystujące najnowsze technologie nie zawsze będą najlepszym rozwiązaniem. Chociaż często jest to kuszące, zwłaszcza gdy rozwijanie aplikacji może być okazją do rozwoju, poznania nowych rozwiązań i wypróbowania ich w praktyce w życiowym projekcie, nietworzonym „do szuflady”. Przy wyborze technologii warto wziąć pod uwagę również jej popularność wśród programistów. Społeczne projekty cechują się sporą rotacją składu zespołu, wybranie technologii, którą w kraju interesuje się kilka osób, w tym połowa z nich obecnie pracuje z nami może być bardzo ryzykowne dla dalszego rozwoju projektu.
Pytania kontrolne:
Jakie ograniczenia muszę wziąć pod uwagę projektując aplikację? Czy wybrane technologie nie będą dyskryminowały kluczowych odbiorców?
Często powielanym błędem jest zaczynanie od końca, a precyzyjniej mówiąc nie od początku. Tworzenie każdego większego projektu, a społecznego w szczególności powinno zacząć się od analizy, weryfikacji pomysłu i rozwiązania, projektu a nie od programowania. Jest to częsta cecha zespołów składających się głownie z osób technicznych, gdzie dopracowanie pomysłu oraz przygotowanie interfejsu spada na drugi plan lub jest w ogóle pomijane. Chętnie idziemy na skróty do tego etapu projektu, który da nam najwięcej radości ale takie skróty często niepotrzebnie wydłużają drogę lub prowadzą na manowce. Spróbujmy poświecić więcej czasu na dopracowanie pomysłu i jego dyskusje z innymi zanim zasiądziemy do kodowania.
Pytania kontrolne:
Czy zweryfikowaliśmy nasz pomysł, przeprowadziliśmy konsultacje? Czy kładziemy równy nacisk na kwestie techniczne jak na projekt i wygodę korzystania?
Projekty społeczne często mają mniej liczną i ściślej określoną grupę docelową niż aplikacje biznesowe. Ich wdrożenie wymaga uzyskania akceptacji ze strony tych społeczności (co łatwiej uzyskać włączając je w proces tworzenia) oraz często współdziałania z partnerami instytucjonalnymi np. organizacjami pozarządowymi czy władzami samorządowymi. „Zrobimy aplikacje do zgłaszania dziur w drogach”, ale co dalej? Brak wiedzy gdzie te zgłoszenia będą przekazywane i pewności, że ktoś na nie zareaguje to prosta droga do porażki projektu. Podobnie wygląda sytuacja w momencie gdy korzystamy z danych udostępnianych lub publicznych – upewnijmy się w jakim formacie te dane są udostępniane, jak często są aktualizowane (czy na pewno są aktualizowane, może dostępny jest tylko raport sprzed kilku lat), kto za nie odpowiada i czy może nam udzielić wsparcia – unikniemy wtedy niemiłych zaskoczeń w momencie startu projektu.
Pytania kontrolne:
Czy w ścieżce prowadzącej do rozwiązania problemu nie ma luk? Czy w obszarach, w których jesteśmy zależni od innych wszystko jest jasne, a zasady współpracy określone?
Warto do współpracy zaprosić osoby o różnych kompetencjach: projektantów usług i interfejsów, grafików, programistów, testerów oraz reprezentantów grupy docelowej. Nie oznacza to tworzenia licznego zespołu, którym może być ciężko zarządzać, nie wszystkie kompetencje są też potrzebne przez cały czas. Wystarczające będą konsultacje ze specjalistami co jakiś czas, nawet jednorazowe wsparcie będzie cenne. Nie czekajmy też z tym do końca projektu. Wtedy zamiast usłyszeć słowa uznania, możemy usłyszeć komentarz „czemu nie przyszliście wcześniej”, a koszt wprowadzenia zmian rośnie w miarę zbliżania się końca projektu.
Pytania kontrolne:
Czy wiemy do kogo się zgłosić z prośbą o wsparcie w każdym z kluczowych obszarów projektu?
Lider projektu jest postacią absolutnie kluczową. Bardzo ważna jest osoba, która będzie koordynowała działania zespołu, wspomagała komunikację, dbała o ustalenie oraz trzymanie się priorytetów. Jej obecność nie gwarantuje sukcesu, ale zmniejsza ryzyko porażki i „rozjechania się” projektu. Aplikacje społeczne powstają często w ramach aktywności podejmowanych w wolnym czasie, członkowie zespołu uczestniczą w pracach z różnym zapałem i dostępnością. Osoba dbająca o spójność wizji i ostateczny kształt jest w takim wypadku niezbędna.
Pytania kontrolne:
Czy mam w zespole lidera, który będzie koordynował prace? Czy nasza wizja jest spójna, a priorytety określone?
Niektóre z adresowanych problemów ograniczone są czasowo lub odbywają się cyklicznie, jak na przykład wybory. Warto zastanowić się, czy nasze rozwiązanie jest uniwersalne, zniesie próbę czasu i czy będzie odpowiednie, gdy ponownie pojawi się potrzeba jego wykorzystania w przyszłości. Z odpowiednim zapasem zaplanujmy i rozpocznijmy prace, aby aplikacja była gotowa wtedy gdy będzie potrzebna a nie chwilę po, gdy jej istnienie straci już sens.
Pytania kontrolne:
Czy mamy określone konkretne terminy, które musimy wziąć pod uwagę?
W projektach biznesowych klient i zapisy umowy są gwarantem zakończenia projektu, ale nawet one borykają się z problemami przekroczonych budżetów i terminów. W projektach społecznych, gdy zespoły tworzą się i pracują skupione wokół idei i bazują na osobistym zaangażowaniu, rezygnacja jednej z osób może skutecznie zablokować i opóźnić prace. Nie zawsze wynika to z utraty chęci czy zapału do pracy, często są to czynniki zewnętrzne (założenie/powiększenie rodziny, zmiana pracy czy miejsca zamieszkania). Próbujmy dzielić projekt na mniejsze części, realizować go w etapach. Skupiajmy się w pierwszej kolejności na tym co kluczowe, na ozdobniki i dodatkowe funkcje przyjdzie jeszcze czas. Lepiej mieć jedną funkcję zrealizowaną w całości niż kilka częściowo. Zapał do pracy z biegiem czasu stopniowo maleje, a brak sukcesów w połączeniu z długa listą zadań i mglistym widokiem zakończenia projektu skutecznie to pogarszają. Dlatego określmy priorytety i skupmy się na kluczowych kwestiach.
Pytania kontrolne:
Czy zakres projektu nie jest zbyt duży? Czy wiemy na czym chcemy się skupić i od czego zacząć?
Nie chowajmy się w garażu czy rogu kawiarni. Wychodźmy, rozmawiajmy, słuchajmy. Nie wszystkie uwagi trzeba wprowadzić w życie, nie każdą propozycję zrealizować, ale warto ją usłyszeć i poznać. Przekaz w drugą stronę również jest istotny. Narzędzi i platform do komunikacji obecnie nie brakuje, korzystajmy z nich, pokazujmy postępy prac, dzielmy się problemami, chwalmy sukcesami. Dbajmy o regularne spotkania i informowanie zainteresowanych (nie tylko członków zespołu ale również odbiorców) o postępach – motywuje to do systematycznej pracy i pozwala na bieżąco wychwytywać błędy i zgłaszać uwagi. Dzielmy się zdobytą wiedzą, udostępnijmy kod projektu, pozwólmy innym zaangażować się i współtworzyć z nami projekty.
Pytania kontrolne:
Czy odpowiednio dbamy o komunikację ze światem zewnętrznym? Czy mamy stały kontakt z przyszłymi użytkownikami aplikacji?
Zakończenie pracy nad aplikacją to nie koniec projektu, a tylko jednego z jego etapów. Nie zapominajmy o działaniach marketingowo-promocyjnych, zbieraniu informacji zwrotnej od użytkowników, kontakcie z partnerami. Warto nie zostawiać tych tematów na sam koniec i zaplanować je wcześniej, aby od etapu tworzenia płynnie przejść do wdrożenia. Systematycznie prowadzona komunikacja w trakcie powstawania projektu będzie dużym ułatwieniem, osoby śledzące nasze działania zapewne chętnie pomogą w przetestowaniu aplikacji, przekażą nam uwagi, a innym potencjalnie zainteresowanym informacje o nas.
Pytania kontrolne:
Czy mamy zaplanowane działania, które podejmiemy po stworzeniu aplikacji? Czy wiemy kto (osoby, organizacje) może nam w tym pomóc?
Jeżeli nie popełniasz powyższych błędów, przyjmij nasze gratulacje i podeślij link do działającego projektu! Jeżeli popełniasz, to znaczy że pomimo napotykanych barier masz energię do działania – gratulujemy i trzymamy kciuki. Niezależnie od sytuacji, zapraszamy do kontaktu z nami. Koduj dla Polski wspiera tego typu projekty i pomaga rozwijać technologiczne rozwiązania dla społecznych problemów.
Autor: Michał Szkodziński
