Ostatnio moje wpisy kręcą się wokół PM. Startup w końcu to projekt jak każdy inny. W zarządzaniu projektami jest dziewięć obszarów zarządzania (według PMI). Wspominam o nich tutaj. Czasami się zastawiam, który z nich jest kluczowy aby projekt się udał. Oczywiście wszystkie są istotne i komplementarne oraz wiele zależy od otoczenia projektu. Jeśli jednak ktoś by mnie poprosił o wybór jednego. Bez wahania wybrałbym zarządzanie komunikacją.
Chyba nikt nie zaprzeczy, że głównym kapitałem firmy czy też przedsięwzięcia są ludzie. To dobry zespół stanowi trzon. Nie jedna osoba ale kilka osób, które potrafią rozmawiać, dzielić się wiedzą, iść na kompromisy i zapominać o konfliktach. Ta swoista synergia i przewaga grupy nad jednostką zawiera się w powiedzeniu „co dwie głowy to nie jedna”. Jednak Ci ludzie muszą się komunikować. Jeśli tego nie ma to nawet najlepszy pomysł padnie wcześniej czy później.
Co jeśli ludzie nie potrafią się dogadać? Częsta sytuacja to różne interpretacje treści zadań, inne spojrzenie na przykład na model biznesowy, rozbieżne oczekiwania od pracodawcy, inaczej identyfikowane potrzeby użytkownika aż w końcu nieustalone zasady codziennej komunikacji.
Głównym produktem pośrednim projektu oraz kanałem komunikacji jest dokumentacja projektowa i kod. Wszelkie e-maile, specyfikacje, projekty graficzne, listy zadań, serwery plików oraz źródła samej aplikacji są miejscami, w których na co dzień umieszczamy efekty naszych prac. Warto poświęcić kilka godzin na identyfikację takich „miejsc” i pogadanie z ludźmi o tym jakie mają z nimi problemy lub co by tam poprawili.
Załóżmy, że mamy firmę – 15 osób, wszyscy na kompach, prowadzi biznes internetowy. Kilka porad z moich doświadczeń, które zmniejszają szum w komunikacji:
- wspólne opisywanie zadań (np. scrum) aby ich interpretacja była jednoznaczna,
- minimalizowanie zmian w zakresie w trakcie iteracji,
- jedna osoba odpowiedzialna za zadanie lub jego koordynację,
- nadawanie sensownych tematów e-mailom,
- pisanie w danym wątku e-mailowym wyłącznie na jeden temat (nie tworzenie nowych bez potrzeby!),
- przy dłuższych wątkach usuwanie osób nie powiązanych z tematem,
- na czacie statusowanie, że wyszedłem z firmy,
- jak w feng shui usuwamy wszystkie śmieci z chmur i serwera plików i trzymamy wszystko w odpowiednio nazwanych katalogach,
- stosowanie narzędzi wersjonujących dokumenty i trzymających historię, mi Google Docs zaspokaja te potrzeby,
- niektórzy sprawdzają pocztę co dwie godziny, popieram, i nie przerywać ludziom co chwila, ze złości niewiele zrozumieją,
- testerzy w bug-tracker nie piszą w opisie błędy tylko „jak jest” ale „jak jest i jak ma być”,
- w przepływie pracy takie dzielenie zadań aby na przykład testerzy nie dostawali wyników pracy programistów na koniec dnia, a ma być na dziś (to szerszy temat),
- na spotkaniach jasna artykulacja celu spotkania, mierzenie czasu dla każdego punktu agendy, podsumowanie ustaleń, jeśli „jeszcze musimy coś ustalić później” to robimy to tu i teraz, trzymanie się zasady „mówisz problem, proponujesz rozwiązanie” (tam gdzie problem jest wewnętrzny),
- specyfikacja standardów kodowania (dla łatwej rotacji i podnoszenia kwalifikacji),
- minimalizowanie po czasie wciąż używanej dokumentacji do niezbędnego minimum, dokumenty typu „one big picture” mile widziane,
- niektórzy stosują (ja nie) słownik wewnętrznego slangu organizacji aby łatwiej wdrażać nowych ludzi.
To niektóre stosowane przeze mnie praktyki dla poprawy komunikacji zespołu. Dla niektórych takie zasady kojarzą się z wojskiem, trudno. Wiadomo, jest potrzebna elastyczność i nie wszystko do wszystkiego pasuje. Jednak będę obstawał, że bez reguł komunikacji będzie słabo. Robi się krótko mówiąc burdel. Częściej dochodzi do konfliktów i ludzie mają mocniejsze poczucie niesprawiedliwości (zawsze je mają w jakimś stopniu). Jak ktoś dwa tygodnie po zleceniu zadania mówi mi, że miał problem, ale nic mi nie powiedział to znaczy, że firma ma duży problem.
Poza komunikacją w ramach zespołu ważne jest komunikowanie wszystkich o tym co się dzieje z firmą. Niektórzy nie popierają takiego podejścia. Ja stawiam na zaufanie. Większe ryzyko, ale lepsze efekty. Jeśli pracownik ma myśleć systemowo i pomagać innym musi wiedzieć jaka jest jego rola i wpływ na całość. Z bardziej zmotywowaną osobą zawsze łatwiej się dogadać. O mrukach gdzie w potoku slangu można wynieść jedynie fangę w nos już pisałem.
A co z naszym startupem?
W startupach często pierwszym dokumentem będącym częścią komunikacji jest eksplikacja pomysłu (o ile ktoś zamierza spisać bo działa sam). Jest sercem jest oczywiście idea, ale „opakowanie” (forma) konsumowalne dla czytelnika jest również bardzo istotne. Zaplanowanie odpowiedniej struktury dokumentu i dostosowanie go do odbiorcy (wyrzucenie reszty) to podstawa. Jak dostanę 50 stron czegoś i czytam streszczenie, po którym wiem jeszcze mniej to zastanawiam się jak z taką osobą będzie mi się rozmawiać i ogólnie pracować. Przydatne są wszelkie próby typu przeczytanie przez znajomych i najpierw zweryfikowanie czy wiedzą o czym ja piszę, a nie tylko czy pomysł jest wspaniały.
I na koniec podstawowa zasada komunikacji. Za jej sprawność odpowiadają nadawca i odbiorca. Upewnij się, że osoba do której mówisz lub piszesz zrozumiała przekaz. To zwykły szacunek. Jeśli członkowie zespołu startupu mają to gdzieś to podejrzewam, że podobnie będzie wyglądać komunikacja z użytkownikiem… ale to już inna działka.
Grafika z dreamstime.com
Maciej Oleksy