Kiedy zaczynasz prowadzić firmę nie masz problemu ze zdefiniowaniem ról w zespole. Każdy zajmuje się tym, czym potrzeba (często wszystkim!), zespół jest mały i nie ma problemu z efektywnością. Jest bardzo efektywnie.
Masz specjalizacje – jedna osoba jest lepsza w sprzedaży, a druga zajmuje się produkcją (swoją drogą, to jeden z lepszych podziałów obowiązków między co-founderami) itd.

Każda firma dojrzewa i rozwija się szybciej lub wolniej. Prędzej czy później pojawia się problem podziału kompetencji w zespole, zwłaszcza, jeśli ten szybko rośnie – lub jeśli Twoja firma składa się z wielu zespołów. W Divante w 2012 pracowało 50 osób, w 2013 urośliśmy do 90. Obecnie mamy na pokładzie 150 świetnych osób. To nie lada wyzwanie, aby takim zespołem realizować z sukcesem i efektywnie skomplikowane projekty (które właściwie, realizujemy :)).

W tym wpisie chciałem podzielić się kilkoma poradami jak można sobie pomóc. Nie jestem teoretykiem zarządzania, przez wiele lat byłem programistą a większość rzeczy o zarządzaniu nauczyło mnie życie i porażki :) Zdaję sobie sprawę, że te porady nie wszędzie pasują. Pasują jednak mniej więcej do firmy IT i agencji e-Commerce, takiej jak Divante. Może będą więc Tobie przydatne?

Jeden zespół – wiele zespołów

Bardzo ważne jest zbudowanie jednego zespołu – w sensie poczucia jedności, celów, wartości a przede wszystkim chęci pomagania sobie wzajemnie. W Divante mamy kilka działów, a w każdym dziale wiele zespołów realizujących projekty.

Zespoły składają się – w zależności od projektu, od 5 do 12 osób i są formowane na czas trwania projektu – od 6 do 24 mc (mniej więcej).

Ustaliliśmy na samym początku naszej firmy – w 2008 roku – zestaw zasad którymi chcemy się posługiwać. Zasad współpracy. Które powinny mieć zastosowanie wszędzie – niezależnie od tego czy realizujesz projekt samodzielnie, czy pomagasz koledze z innego działu, czy może zwracasz się do swojego przełożonego.

Taki zbiór ustaliliśmy, nie sami z siebie, a raczej po kilku „pomyłkach HR” – głównie na stanowisku menedżera zespołu/projektu. Takie pomyłki kosztują najwięcej:  nas kosztowały zepsutą atmosferę i sporo nerwów pozostałych pracowników.

Dlaczego? Nie każdy chce pracować tak jak Ty. Ktoś wyznaje zasadę „do celu po trupach”, a ktoś inny może pracować dla Ciebie bo „pragnie władzy”, ktoś jeszcze inny uznaje klientów za wrogów numer jeden :)  Żadne doświadczenie i specjalizacja nie zastąpi dopasowania osoby którą zatrudniasz do Twojego zespołu. Dopasowania do Ciebie, na samym początku. Zwłaszcza, jeśli dana osoba ma duży wpływ na innych.

Jeśli chcesz się zainspirować jak wyglądała pierwsza wersja naszych zasad – można je pobrać tutaj. W miarę jak Divante rosło, zmieniała się struktura organizacyjna, te zasady były zmieniane i dopasowywane.

Kiedyś wydawało mi się, że ustalanie celów i wartości dla firmy dotyczy tylko dużych korporacji. W zeszłym roku zmieniłem zdanie. Nie z każdym jestem w stanie porozmawiać tak długo jakbym chciał i przekazać mu wszystko co jest ważne. Skodyfikowaliśmy wtedy nasze wartości. Teraz  każdy otrzymuje w ramach prezentacji w Poradniku startowym – dokumencie (drukowanym :)) który czyta pierwszego dnia pracy  (oprócz tego w tym dokumencie są też bardzo przydatne informacje – gdzie zjeść obiad, kto jest twoim szefem itd ..  )

Jasne postawienie sprawy co do zasad  to, moim zdaniem, podstawa do budowania zespołu.

Najważniejsze jest oczywiście by pamiętać, że spisane wartości nie wdrożą się w życie same. Musisz znaleźć odpowiednie osoby zarządzające które potraktują je jak swoje – tak jak Ty. Razem z nimi ciągle je powtarzać i zgodnie z nimi się zachowywać.

To buduje kręgosłup firmy. Chociaż zespołów jest wiele, każdy ma zakodowany kodeks postępowania i wie jak się współpracuje. Nawet jeśli zespół się zmienia to postępowanie się nie zmienia.

Idealny zespół projektowy

Nasza firma realizuje różne projekty  – mamy bardzo prężny zespół UX, eMarketingowy, Analityczny i QA, dział Software Development & Maintenance. Do tego jest też hosting.

Jak widać, zróżnicowanie i specjalizacja jest duża. Projekty które obejmujemy są dość szerokie. Najczęściej w ramach jednego, dużego projektu wdrożeniowego współdziałają wszystkie działy.

Jeśli masz fajną atmosferę w firmie i wszyscy lubią ze sobą pracować – jesteś w połowie drogi, żeby robić świetne projekty.  Pozostaje bardzo trudne pytanie: jak ułożyć więc pracę zespołu, żeby każda osoba czuła się spełniona, ale także aby efektywnie wykorzystać jej czas? Jak sprawić, aby nie była przepracowana i czuła się dobrze?

Charakterystyka pracy w każdej specjalizacji jest inna. Projektant interakcji może stworzyć projektowo makiety i zacząć realizować inny projekt przekazując swoją pracę dalej. Podobnie grafik i webmaster. To jedno z rozwiązań – osoby mogą też pracować w trybie ciągłym współpracując z zespołem przez cały okres trwania projektu. Mogą też pracować w trybie mieszanym. Tester może testować projekt na samym końcu, albo w trakcie. Programiści mają różne specjalizacje, jeśli jest ich w projekcie wielu (na przykład 10) to potrzebują architekta który zachowa spójną wizję systemu i zadba o jakość kodu.

W drodze ewolucji doszliśmy do poniższego podziału ról w zespole:

  • analityk – zbiera wymagania podczas analizy wstępnej i przygotowuje grunt pod projektowanie systemu, po zaprojektowaniu interfejsu systemu prowadzi analizę szczegółową w oparciu o komplet danych (analizę wstępną i makiety) – prowadzi też analizę integracji które system ma realizować; analitycy u nas pomagają też liderom technicznym stworzyć backlog produktu oraz na bieżąco konsultują cały projekt
  • projektant – przygotowuje makiety systemu na bazie wstępnej analizy i pogłębia ją ciągle pracując z klientem,
  • pm – cały czas w projekcie, praktycznie już od momentu sprzedaży usług – aby mieć pewność, że żadne ważne informacje nie zostaną „zagubione” :)
  • grafik – na bazie makiet opracowuje grafikę systemu – pracuje projektowo + jeśli jest to wymagane na bieżąco dorabia brakujące elementy; bierze też udział w testach systemu sprawdzając jego zgodność z grafikami
  • frontend-developer – na bazie makiet i grafiki opracowuje kod HTML, CSS i skrypty JS napędzające frontend – jego zadanie w projektach RWD czasami jest poszerzone o współpracę na bieżąco z grafikiem i projektantem
  • lider techniczny/team leader – wyznaczona osoba z zespołu programistów która ma wydzielony czas na „liderowanie” – na czym ono polega napiszę jeszcze w kolejnym wpisie; jest to np. tworzenie backlogu, doprecyzowanie wymagań itd.
  • tester – przydzielony od momentu powstania kodu HTML i na stałe zaangażowany w projekt (często na ok 25-30% swojego czasu pracy per projekt); na bieżąco tworzy dokumentację testową i odbiera każde zadanie programistyczne, testując je. Dzięki temu testy akceptacyjne są krótsze a efektywność pracy większa (nie ma przestojów i powrotów)
  • programiści – pracują w ramach sprintów razem z liderem technicznym, PMem analitykiem i testerem.

Doszliśmy do takiego, optymalnego, składu projektowego po sprawdzeniu wielu różnych kombinacji. Ta najlepiej się sprawdza  – dając najwyższą jakość, bez przeciążania poszczególnych członków zespołu.

Nie jest dobrym pomysłem angażowanie (mocne) programistów w testy, a PMów w analitykę. Kończy się to 16 godzinnym dniem pracy i opłakaną jakością (kiedyś, dawno temu – popełnialiśmy takie błędy – jak wiele mniejszych firm :))

Taki podział nie jest łatwy i trudno wdrożyć go w życie – zwłaszcza na początku, gdy zdarzają się wąskie gardła w projektach gdy osób danej specjalizacji brakuje.

Gdy jednak uda Ci się już znaleźć osoby – trzeba mieć na uwadze, że oprócz takiego, jasnego podziału kluczowe jest opisanie (tak, opisanie w formie pisemnej) dobrych praktyk programistycznych, przebiegu procesu wdrożeniowego i ról każdej z osób. Firma i zespół będzie rosła. To jest pewne (nie jest pewna szybkość) – każdy nowy członek zespołu musi wiedzieć jakiej pomocy i od kogo może oczekiwać. Co jest oczekiwane od niego.

W kolejnych wpisach postaram się naświetlić jak takie role mogą być zdefiniowane. Jestem ciekaw jak to wygląda w Twojej firmie?

 

ps. Fotka do wpisu to realne zdjęcie z Divante :)