Budowanie zespołu - Porady dla Project Managerów i Project Ownerów

W tej serii artykułów chciałbym podzielić się praktycznymi aspektami procesu developmentu w kontekście modelu Team as a Service (TaaS), zaczerpniętymi z doświadczenia naszego zespołu w dostarczaniu projektów komercyjnych. W szczególności dowiecie się o:

  • Wyborze członków zespołu z odpowiednimi umiejętnościami i doświadczeniem
  • Bootstrapowaniu procesu developmentu przy użyciu zasad Agile
  • Komunikacji ze stakeholderami (POs / PMs / CTO itd.)
  • Zrozumieniu celów biznesowych i technologicznych (CPO/CTO)
  • Zajmowaniu się relacjami wewnątrz zespołu

Chciałbym opowiedzieć Wam o tym przez pryzmat kilku wymagających projektów, dostarczonych przez nasz dzielny zespół pracujący w modelu ‘Team as a Service’.

Pamiętaj, że to tylko przykład, rozwiązanie ‘Team as a Service’ powinno oferować pełną elastyczność w “zaopatrzeniu” w pracowników. Oznacza to, że możesz przypisać więcej pracowników do swoich projektów, gdy tego potrzebujesz, bądź zmniejszyć ich ilość, gdy nakład pracy jest mniejszy.

Bez dalszej zwłoki przejdźmy do tematu Team as a Servive (TaaS) w praktyce. Jako, że jest to dość obszerna kwestia, podzielę ją na kilka blog postów. Dzisiaj skupimy się na tym, jak wybrać odpowiednich pracowników do danego projektu.

WYBÓR ODPOWIEDNICH CZŁONKÓW ZESPOŁU DO PROJEKTU

Poniżej znajdują się najistotniejsze kryteria, które należy wziąć pod uwagę przy wyborze członków zespołu do konkretnego projektu:

  • umiejętności techniczne (programowanie / projektowanie / architektura),
  • doświadczenie w pracy zespołowej,
  • chęć rozwiązywania problemów,
  • zaangażowanie,
  • umiejętność komunikowania zarówno problemów, jak i rozwiązań.

Powyższe kryteria nie są w żadnym konkretnym porządku, jako że zauważyliśmy, że wszystkie w równym stopniu przyczyniają się do udanego dostarczenia projektu.

Najważniejszą rzeczą, jest umiejętność zweryfikowania poziomu konkretnych umiejętności wśród członków zespołu. Pamiętaj jednak, że Twoim celem jest zbudowanie zespołu, więc nie jest konieczne, aby każdy członek zespołu posiadał taki sam poziom wymienionych powyżej umiejętności. Ważniejsze jest, żeby uzupełniali się nawzajem, ponieważ to pozwoli im właściwie wykorzystywać swoje umiejętności i stworzyć synergię, dzięki której osiągniecie lepsze rezultaty.

Podczas rozmowy o pracę bardzo trudno jest zweryfikować te elementy, dlatego kluczowym jest przeznaczenie trochę czasu na projekty wewnętrzne, które dają idealną okazję, żeby przekonać się czy dany członek zespołu będzie w stanie współpracować i pracować na pożądanym poziomie. Ważne jest żeby stworzyć kontrolowane środowisko, w którym można skupić się na obserwacji i weryfikowaniu umiejętności, ponieważ w prawdziwym projekcie zwykle nie ma na to czasu.

Mogę podzielić się naszymi doświadczeniami z prowadzenia projektów wewnętrznych. Podczas tych projektów staramy bardziej skupiać się na obserwowaniu i trenowaniu ludzi, niż na perspektywie biznesowej. Wewnętrzne nadawanie ról Product Ownera i Scrum Mastera seniorom pozwala nam kontrolować każdy aspekt procesu i wyciągać wnioski odnośnie tego, co nasi adepci powinni poprawić. Co ważne - staramy się, aby te projekty nie były tylko ćwiczeniem i żeby miały swój cel i przydatność w przyszłości.

Powyższe przemyślenia to nie tylko teoria, jako że wszystkie nasze wnioski są oparte o znaczną ilość klientów i dostarczonych projektów. Postanowiliśmy wnieść swój wkład nie tylko na płaszczyźnie rozwiązań Open Source i dlatego dzielę się dzisiaj naszymi doświadczeniami.

PROJEKT

Naszym klientem był jeden z najbardziej innowacyjnych dostawców rozwiązań w branży budowlanej i inżynieryjnej. Potrzebowali zaufanego partnera, który wspomógłby ich w procesie ulepszania ich flagowego produktu.

CTO tej organizacji szukał efektywnego sposobu na zwiększenie prędkości developmentu w projekcie, bez narażania jego jakości. Po ustaleniu wstępnych wymagań, mogliśmy zacząć kompletować dedykowany zespół. Naszym celem podczas wybierania członków zespołu było zmaksymalizowanie synergii i wszechstronności, w tym samym czasie ograniczając ryzyko związane z tzw. Single Point of Failure (SPOF). Współpracę rozpoczęliśmy w składzie trzech osób, z czasem skalując zespół do sześciu osób:

  • Dwóch senior full stack developerów
  • Dwóch full stack developerów
  • Jeden specjalista quality assurance
  • Jeden scrum master

Dzięki zróżnicowanemu składowi zespołu, mogliśmy funkcjonować sprawnie nawet podczas potencjalnych trudności.

Mam nadzieję, że powyższe obserwacje będą pomocne i będziesz mieć możliwość wdrożyć część z nich do swojej organizacji. Umiejętność dobrania właściwych członków zespołu do projektu jest tylko częścią większej całości procesów budowania i rozwijania zespołu. W końcu ten właśnie zespół jest Twoją przewagą biznesową.

Możesz poświęcić czas, aby zbudować zespół, ale pamiętaj, że istnieją alternatywne rozwiązania, które mogą pomóc osiągnąć ten sam cel, bez konieczności inwestowania czy ponoszenia jakiegokolwiek ryzyka. Jeśli nie wiesz jakie rozwiązanie byłoby najlepsze dla Twojej organizacji - odezwij się na Twitterze czy Linkedin.

Jeśli chcesz przeczytać nasz poprzedni blog post, w którym opisuję różne modele współpracy, możesz znaleźć go tutaj

Kolejna część dotycząca bootstrapowania procesu developmentu już wkrótce!

click to subscribe
hire us

Let’s talk about Mobile Apps

We’d love to design, develop and release them for you.

Highest DevOps Standards

Our team wield the right skills to make things work.

Angular magic in the making

Most flexible development technology for stunnig results.

Web Apps cooked the right way

The ultimate combination of code, design and user experience.

Django REST Framework

TEONITE develops, supports and donates open source projects.