Zdjęcie główne artykułu pochodzi z pl.depositphotos.com
Po pierwsze – komunikacja
Serio. To podstawa wszystkiego – od zakupów w warzywniaku do zarządzania globalną firmą. Jak organizować komunikację w startupach, aby oszczędzić czas, pieniądze… i mieć dużo spokoju? Jeśli zarządzasz startupem albo jakimkolwiek projektem, dobrze wiesz, jak kluczowa jest komunikacja w zespole. Im więcej zaangażowanych we współpracę osób, tym większym wyzwaniem jest skuteczne porozumiewanie się i działanie bez opóźnień. Jeśli Twoim partnerem w projekcie jest firma zewnętrzna (może w innym kraju), ryzyko komplikacji rośnie – każda organizacja ma inną kulturę komunikacji. Oznacza to często konkretne problemy.
BAR kontra Finowie
Jednym z naszych klientów jest fiński startup, dla którego tworzyliśmy aplikację FLOUD (LINK). Apka umożliwia kupowanie biletów na wydarzenia, imprezy i koncerty. Pozwala w czasie rzeczywistym śledzić aktywność znajomych – jakie bilety kupili oraz na jakie wydarzenie właśnie się wybierają. Ponadto aplikacja ma też rozbudowane funkcjonalności społecznościowe – pozwala czatować z organizatorami i innymi uczestnikami wydarzeń.
Before Action Review – jak przygotować siebie i klienta do współpracy
We współpracy z fińskim startupem fantastycznie sprawdziła się stosowana przez nas od dawna, a w Polsce jeszcze niezbyt znana technika BAR, czyli Before Action Review, której założenia opisałem w poprzednim tekście. W fazie planowania projektu i zasobów (BAR) określiliśmy dokładnie cele, terminy, oczekiwane rezultaty i zasoby jakie mamy, a także odpowiedzialności za poszczególne fazy i elementy składowe. Wszystko w jednej prostej tabelce…
(Kliknij w obrazek, aby go powiększyć)
Wbrew intuicji, kluczowa rubryka w tej tabeli to nie WHAT i WHEN, ale… WHY. To ona pozwala zrozumieć wszystkim uczestnikom projektu, dlaczego poszczególne elementy są ważne.
To sprawia, że każdy z nich inaczej odczuwa odpowiedzialność, widząc swoją rolę w całym projekcie. BAR doskonale ujmuje wewnętrzny sens całego projektu. Developer odpowiedzialny za kodowanie, project manager, grafik i klient widzą, że mają wspólny cel. Nagle określony precyzyjne harmonogram staje się uzasadniony, a dedlajny nabierają głębszego sensu. To Ty musisz odpowiedzieć sobie na pytanie: dlaczego właściwie mam to robić.
Co więcej, BAR oferuje przydatny mechanizm określania scenariuszy działania w przypadku, kiedy nie wszystko idzie zgodnie z planem. Pozwala zachować zimną krew w kryzysie i daje poczucie bezpieczeństwa. Umożliwia skrócenie czasu reagowania w przypadku zmian. Naszym prawdziwym odkryciem w kontekście optymalizacji czasu pracy jest jednak nowe podejście do podziału i delegowania zadań.
BAR, czyli inna koordynacja projektów
W większości projektów IT osobą kluczowa, zaangażowaną w każdy etap pracy, jest project manager lub product owner, który koordynuje komunikację i czuwa nad całym przepływem informacji i zadań – flow. Tymczasem dzięki BAR rola PM-a zostaje efektywnie rozbita na kilka osób.
Jak to działa?
BAR precyzyjnie określa odpowiedzialność poszczególnych osób za konkretne obszary realizacji, co w znaczny sposób upraszcza komunikację i w razie problemów kieruje klienta do konkretnej osoby. W konsekwencji projekt nie ma jednego managera, do którego zrzucane są wszystkie taski, zamiast tego zespół specjalistów z jasno rozdzielonymi obowiązkami, z którymi klient kontaktuje się bezpośrednio, co znacznie skraca czas rozwiązania danego problemu i czas reakcji, niż w przypadku projektów zarządzanych przez Project Managerów. Dzięki takiemu podejściu upraszczamy komunikację i unikamy nieustającego ping-ponga poprawek i akceptacji. Każdy z nas ma inne know-how i doświadczenia, które wnosi w projekt – BAR pozwala je dokładnie określić i wycisnąć z każdego maksymalne zaangażowanie.
My już na samym początku określiliśmy dość precyzyjnie, jakie problemy (technologiczne, organizacyjne, administracyjne, biznesowe) mogą się pojawić w konkretnych kanałach. Wyznaczyliśmy też czas, w którym konkretne osoby z naszego zespołu były do dyspozycji klienta. To pozwoliło stworzyć bardzo techniczną instrukcję dotyczącą naszej komunikacji. Towarzyszył jej dokładny, tygodniowy harmonogram:
(Kliknij w obrazek, aby go powiększyć)
Dzięki takiemu rozwiązaniu przebieg komunikacji w projekcie FLOUD działał bez zarzutu.
Tak Janne Haila pisze o tym modelu współpracy: Komunikację i workflow w tym modelu oceniamy bardzo wysoko. Czas, który spędziliśmy na ustalaniu zasad współpracy, zwrócił się wielokrotnie! Ta struktura współpracy sprawiła, że na co dzień pracowało nam się z Leaware jak z teamem w tym samym budynku. Używaliśmy tych zasad współpracy wcześniej, ale nigdy w tak uporządkowanej formie. Te techniki są bardzo pomocne, szczególnie przy współpracy z remote teams, w której ustalenie wzajemnych oczekiwań i sprawdzanie rezultatów jest bardzo istotne. Dzięki nim obie strony czują się pewnie i bezpiecznie, i całą energię mogą poświęcić na ukończenie projektu.
Projekt zakończył się sukcesem, ale my mieliśmy do odrobienia jeszcze pracę domową – AAR – After Action Review. Czy Graal okazał się tym, czego szukaliśmy? Opowiem w trzeciej części moich BARowych zwierzeń.
–
Zbyszek Waz
Managing Partner w Leaware
Trener biznesowy, fan metodyk związanych z tworzeniem i rozwojem produktów oraz efektywnym działaniem. Aktywnie pracuje ze startupami i pomaga je rozwijać – zarówno jako dostawca technologii jak i znienawidzony konsultant zadający trudne pytania. Od blisko 20 lat tworzy produkty i wprowadza je na rynek, dbając o to, by zderzenie z rzeczywistością nie było zbyt bolesne. Niestrudzony poszukiwacz odpowiedzi na pytanie „dlaczego w większości przypadków rzeczywistość wygrywa z ideą”.
