Jak realizujemy projekty (nasze zasady) – MANIFEST ISOLUTION
Każda firma tworząca oprogramowanie doskonali swój proces wytwarzania oprogramowania, każda ma na to inny pomysł. Nie jest to zadanie łatwe, ponieważ zależy od wielu składowych np. dziedziny biznesowej, kultury organizacji, modelu współpracy, technologii i wielu wielu innych.
W tym artykule, przedstawimy nasze podejście do realizacji projektów (zasady pracy), które stara się wykorzystać najlepsze praktyki zaczerpnięte z Agile, Scrum, Kanban, Lean, CRISP DNA, Management 3.0 dostosowane do naszego kontekstu oraz nasze autorskie pomysły. Cały czas szukamy usprawnień i poprawy jakości naszej pracy.
W ISOLUTION mamy podział na zespoły merytoryczne np. Programiści, Analitycy, PMO/Scrum Master, Testerzy. Zespół projektowy budujemy w oparciu o ludzi z różnych zespołów merytorycznych. Każdy projekt tworzy specyficzną, zależną od kontekstu projektu “kulturę projektu”.
Każdy uczestnik projektu pełni w ramach projektu 1 lub wiele ról, z którymi wiążą się konkretne odpowiedzialności. Zarówno role projektowe, jak i odpowiedzialności są wypracowywane per projekt.
Dodatkowo każdy projekt na początek stara się skorzystać z:
wcześniej wytworzonych w ramach innych projektów rozwiązań (Rejestr Rozwiązań) np. moduł do wysyłania e-mail, szkielet aplikacji RWA/PWA, integracja z PayPal/Slackiem/JIRA, CI/CD itd.
Dobrych Praktyk, które pozwalają nam czerpać z wcześniejszych doświadczeń np. DoD, DoR, zadanie < 1 MD itd.
zasad prowadzenia projektów, które określają ramy dla każdego zespołu, pozwalające inicjalnie rozpocząć projekt i dalej dostosować go do własnego kontekstu.
Każdy projekt korzysta z dowolnego zestawu Dobrych Praktyk, Zasad Realizacji projektów oraz gotowych rozwiązań. Oczywiście dostosowuje je do własnych potrzeb, rozszerza. Rejestr Rozwiązań oraz Dobre Praktyki to nasze wewnętrzne, budowane przez lata doświadczenie. W dalszej części artykułu skupię się na opisaniu Zasad Prowadzenia Projektów, które stanowi swoisty Manifest.
Tworząc zasady zgodnie z którymi chcemy pracować tworząc innowacyjne cyfrowe produkty dla naszych Partnerów staraliśmy się skupić na tym, żeby gwarantowały one dobrą jakość pracy oraz dostarczenie wartości biznesowej. Poniżej nasz Manifest z krótkim omówieniem.
I Projekt jest ważny dla Klienta
Chcemy mieć pewność, że projekt/produkt jest ważny dla Klienta, że ma wszystkie niezbędne zasoby na realizację projektu. Szczególnie istotne jest dla nas wyznaczenie przez Klienta konkretnej osoby, która będzie pełniła rolę Product Ownera.
II Pracujemy w metodykach zwinnych.
Bierzemy to co najlepsze z podejść SCRUM, Agile, Kanban, CRISP, Lean. Współpracę opieramy na partnerskich relacjach w oparciu o umowę Agile.
Rozliczamy się na podstawie TS po każdym Sprincie.
Klient może zrezygnować ze współpracy w każdym momencie z miesięcznym okresem wypowiedzenia.
III Nie jesteśmy najtańsi cenowo, ale najtańsi kosztowo.
Oznacza to, że nie chcemy konkurować najniższą stawką, a najniższym końcowym kosztem stworzenia produktu i dostarczenia wartości, która będzie wspierała biznes naszych Klientów.
IV Transparentność
Budujemy z Klientem relacje partnerskie oparte na zaufaniu. Klient ma ciągły dostęp do wszystkich artefaktów projektu. Na bieżąco jest informowany o stanie realizacji projektu. Istotne dla nas parametry projektu to: % realizacji zakresu, % realizacji budżetu, poziom zadowolenie z pracy zespołu (Happiness Index).
V Zespół jest ważny
Rozwój naszego zespołu oraz jego zadowolenie z pracy jest dla nas bardzo ważne. Wierzymy, że dobrze zbudowany, zmotywowany i zaangażowany zespół jest w stanie nawet średni pomysł przekształcić w świetne rozwiązanie.
Dbamy o to by proces formowania zespołu uwzględniał potencjał i kompetencje każdej osoby, jej styl osobowości, motywatory. Chcemy zapewnić zespołowi bezpieczeństwo psychologiczne oraz środowisko zapewniające możliwość popełnia błędów. Z naszego punktu widzenia projekty są robione przez ludzi, którzy są członkami zespołów projektowych. Zadbanie o dobre środowisko pracy dla nich jest krytyczne.
Zespół ma prawo do popełniania błędów.
Tworzenie produktów cyfrowych jest niepowtarzalne. Zespół musi mieć komfort pracy w warunkach, które daje przestrzeń na popełnianie błędów szybciej. Chcemy, żeby cały zespół skupiał się na jakości i dostarczaniu wartości, a nie ciągłym strachu przed popełnieniem błędu.
Wierzymy w efekt synergii.
Zespół to siła. Dobrze zbudowany zespół stanowi wartość. Cenimy bardziej zespół od indywidualności.
Mówimy o problemach, gdy je zauważamy.
Budujemy zespoły proaktywne, odpowiedzialne i zaangażowane. Stosujemy zasadę, że o problemach mówimy od razu, nie czekamy do ostatniej chwili.
Oszacowanie zespołu jest “święte”.
Ufamy, że zespół szacuje najlepiej jak potrafi w danym momencie, dysponując określoną wiedzą na temat zadania.
Pojemność osoby = 32h
Każda osoba ma na tydzień 32h pojemności, pozostałe godziny do wykorzystania na rytuały i komunikację.
VI Codzienna praca odbywa się wg. jasnych zasad
Lubimy jasne zasady. Stosując je możemy budować relacje oparte na zaufaniu i skupić się na jakości oraz dostarczaniu wartościowych produktów.
Backlog zadań na sprint jest stały.
Po zaplanowaniu Sprintu nie pozwalamy zmieniać zakresu. Jeżeli jest taka potrzeba, zmieniamy podejście na oparte o Kanban.
Każde zadanie jest zapisane i oszacowane.
Tylko takie zadanie dopuszczane są do realizacji.
Oszacowane zadania zajmują mniej niż 1 MD.
W szacowaniu zadań bierze udział cały zespół. Z naszej praktyki wynika, że wydzielanie mniejszych zadań możliwych do zrealizowania w 1 dzień roboczy, ułatwia planowanie prac i ich przebieg.
Dzień pracy developera (8h) to realnie 5 h pracy
Badania wskazują, że przy zadaniach kreatywnych efektywny czas pracy to max 5-6 h. Wierzymy w to. Wierzymy, że dostarczając naszym klientom wartościowe produkty musimy być kreatywni, wypoczęci i zaangażowani. Musimy mieć czas na chwilę przerwy, zabawy i relaksu.
Znamy kryteria odbioru zadania DoD
Zasady wg. których uznajemy zadanie za odebrane ustalamy przed, a nie po realizacji.
Wypełniamy TS codziennie
Chcemy być w pełni transparentni wobec naszych Klientów. Codzienne wypełnianie TS przez wszystkich pozwala dbać o budżet przedsięwzięcia.
Codziennie dostarczamy działające oprogramowanie
Stosując CI/CD/Devops automatyzujemy procesy związane z wytwarzaniem oprogramowania.
DEMO robi Klient
Odbioru prac dokonuje nasz Klient. To on prowadzi DEMO.
Planowanie
Klient bierze udział w planowaniu. Jego zaangażowanie jest dla nas krytyczne.
Priorytety
To Klient decyduje o tym co jest ważne z punktu widzenia biznesu. To on reguluje kolejność i tempo prac.
Sprint
Standardowo pracujemy w Sprintach. Realizujemy w nim tyle zadań, ile wynika z pojemności zespołu.
Błąd w szacowaniu
Tworzenie produktów cyfrowych jest niepowtarzalne. To zadanie kreatywne, realizowane w zespole. Dlatego istotne jest dla nas zapewnienie zespołowi środowiska do pracy kreatywnej, w której nie będą bali się popełniać błędy szybciej, uczyć się na błędach, usprawniać proces, dbać o jakość, poprawiać i ulepszać kod. W tym celu pracujemy stosując zasadę, że w przypadku pojawienia się przekroczenia terminu realizacji Klient zgadza się na wydłużenie czasu realizacji lub zdejmuje zadanie z realizacji (opłacając dotychczasowy czas) i wrzucając zadania z powrotem do backlogu.
Oczekiwanie na prace
Dbamy o dostarczenie wartości dla naszych Klientów i jakość naszej pracy. Dbamy też o rozwój naszego biznesu.
W przypadku oczekiwania na dostarczenie artefaktów przez Klienta (środowisko, wykonanie testów) ustalamy z Klientem jak wykorzystać ten czas. Klient płaci za ten czas.
Przedstawione powyżej zasady to model do którego dążymy. Nie zawsze udaje się zastosować wszystkie zasady w każdym projekcie. Chcemy je jednak jasno komunikować i rozmawiać z nimi z naszymi partnerami.
Organizacja prac projektowych jest elementem naszej kultury. Będziesz mógł o niej przeczytać więcej w kolejnym wpisie na blogu oraz na naszej stronie. #staytuned