Pojęcie roli
Rola to pojęcie nierozerwalnie związane z obowiązkami: ktoś o danej roli ma szereg określonych obowiązków z danego obszaru specjalistycznego. Ale ktoś kto ma określony obowiązek niekoniecznie musi mieć od razu daną rolę. Rola wskazuje niejawnie na specjalizację, pojęcie specjalizacji ma tu kluczowe znaczenie, nawet jeśli pracujesz w Scrum.Teoria Scrum a praktyka Scrum
Przy okazji poruszenia tematu Scrum - dla zespołów praktykujących Scrum polecam publikację ze strony: http://www.infoq.com/minibooks/scrum-xp-from-the-trenches. Publikacja ma podtytuł "How do we do scrum" i jest wciągającą "war story" osadzającą oszlifowaną, wychuchaną i nienaganną teorię w twarde i nieubłagane realia projektowe. Ogólnie przestrzegam przed ślepym realizowaniem założeń teoretycznych bez wcześniejszego osadzenia ich w kontekście rzeczywistej sytuacji projektowej - korzystajmy z metodyk i dobrych praktyk, ale niech tłem do naszych decyzji projektowych będą doświadczenie, rozsądek i fakty. Możesz walczyć z realiami stojącymi w sprzeczności z teorią, ale z marnym skutkiem, mądrzej jest te realia zrozumieć i metodykę do nich dostosować niż obrażać się na rzeczywistość i powtarzać puste "powinno być". Ta publikacja pokaże Ci jak prowadzić rzeczywisty a nie wyimaginowany projekt w Scrum.Rola a obowiązek
Nikt nie jest dobry we wszystkim. Dotyczy to rzecz jasna również programistów. Oznacza to, że nie ma co liczyć na to, że programista świetny w zarządzaniu bazami danych usiądzie i narysuje piękną grafikę, programista lubiący programować na poziomie warstwy biznesowej okaże się świetnym analitykiem a inżynier systemowy zostanie niezrównanym testerem. W projekcie potrzebny jest programista, webdeveloper, analityk, projektant, tester i każda z tych ról powinna znać zakres swoich obowiązków.Dlatego też rola ma przewagę nad pojedynczym obowiązkiem. Analityk będzie wiedział jakie są jego obowiązki w zakresie analizy. Jeśli nie mamy analityka mamy problem, bo kto jest odpowiedzialny za ustalenia z klientem, kto za zarządzanie wymaganiami tego klienta na poziomie procesu biznesowego, kto za napisanie analizy, kto za uzgadnianie zmian wyglądu z webdeveloperem i sposobu działania aplikacji z projektantem. Bez analityka musimy wskazać osoby, które wezmą na siebie te obowiązki, potem rozrysować tabelę obowiązków, żeby zapamiętać te zobowiązania a następnie nosić ze sobą tą tabelę, żeby wiedzieć do kogo się udać, jeśli opóźnia się dokument analizy a do kogo chcąc się dowiedzieć jaka wygląda sytuacja z realizacją wymagań. Hmm.. Jakże łatwiej byłoby po prostu mieć analityka.
Zespoły o bezkształtej masie
Pracowałam kiedyś z zespołem składającym się niemal w całości z nowicjuszy. Nie byli to jeszcze nawet dobrzy programiści, więc pytanie w czym każdy z nich się specjalizował w ogóle nie miało tu racji bytu. Projekt, który miał być przez nich zrealizowany miał znaczenie strategiczne dla komórki organizacyjnej (o doborze "specjalistów" do zespołu pisałam w topiku Kulisy formowania zespołu w IT). Będąc kierownikiem projektu wzięłam na siebie dodatkowo, chcąc nie chcąc, obowiązki analityka i testera. Nie popełniaj tego błędu! Nie będziesz miał czasu kierować zespołem, reagować na zagrożenia, planować, będziesz ciągle zatopiony w pracach codziennych na poziomie programowania i co najważniejsze - stracisz perspektywę, zaczniesz myśleć jak programiści - w kategoriach technologii i problemów z nią związanych oraz rozwiązań na te problemy proponowanych, nie jak kierownik - w kategoriach planów, fakturowania, spełnienia wymagań Umowy, nadzoru i koordynacji. Jeśli masz czas możesz naturalnie aplikację testować, ale jako odcięty od całego zespołu projektowego Użytkownik, a nie tester na pełny wymiar czasu pracy.Jak pracować z zespołem niewyspecjalizowanych programistów
A więc co, jeśli nie mamy osób wyspecjalizowanych, którym możemy nadać poszczególne role w zespole projektowym?Musimy sobie radzić i sukcesywnie przekazywać programistom obowiązki dotyczące obszarów specjalistycznych, wydobyć z organu zajmującego się wyłącznie programowaniem te komórki, które będą się specjalizować i przejmą funkcje w innych dziedzinach procesu produkcji oprogramowania. Rób spotkania, obserwuj, kto jest daną dziedziną zainteresowany, pytaj zespół, jak rozwiązać problem braków w obszarach specjalistycznych, przedstawiaj skutki tych braków. Pozwól zespołowi samemu podzielić się obowiązkami, ale nie zostawiaj ich z tym samych, w przeciwnym razie podział jakiego dokonają będzie rozmyty, chwilowy i poszatkowany. I nie wskazuj kogoś arbitralnie do danej roli chyba, że już faktycznie nie będzie innego rozwiązania.
Nie jest to szybki i łatwy proces, ale zwraca się z nawiązką - zespół zaczyna być samoorganizujący się i nie wymaga ciągłego nadzoru Kierownika Projektu.
Rola dla spokoju
Role w zespole istnieją dla spokoju Kierownika Projektu i całego zespołu. Zespół z rolami ma strukturę, pracuje stabilnie i dojrzale, radzi sobie z problemami i nie wpada w panikę, gdy dzieje się coś złego. Role porządkują całe środowisko projektowe. Nie zgadzam się z tezą, że można prowadzić projekt zespołem bez wskazanych ról, czy choćby obowiązków, np. zespołem bez testera. Chyba, że chodzi o małe, półroczne projekty lub o projekty prowadzone przez zespoły lubiące pracować w chaosie, po nocach, na podwyższonym poziomie adrenaliny.
Brak komentarzy:
Prześlij komentarz