Firma stara się poszukiwać w gotowych metodykach, również w nieco dziś zarzuconych w świecie serwisów WWW metodykach Prince2 czy PMBoK, wskazówek do organizacji swoich działań. Zdaniem Lecha Rychlińskiego, zdefiniowane w standardowych metodykach procesy nie muszą być implementowane w komplecie. Ich różne fragmenty mogą występować w każdym projekcie. "Dobrze jest być przygotowanym na taką ewentualność i wplatać te elementy we własną drogę realizacji projektów" - mówi Rychliński.

Jego zespół korzysta też z rekomendacji płynących z biblioteki ITIL. "Nie są to może praktyki bezpośrednio związane z wytwarzaniem projektów, a bardziej z ich utrzymaniem i obsługą, jednak elementy te silnie się ze sobą łączą" - wyjaśnia dyrektor IT w Gratce. "Mając na uwadze procesy utrzymaniowe, lepiej możemy dostosowywać do ich wymagań swoje procesy produkcyjne" - dodaje.

Chętnie stosowane są również metodyki lekkie, głównie popularny ostatnio SCRUM, który pozwolił nieco odświeżyć spojrzenie na produkcję i wyjść naprzeciw oczekiwaniom klienta biznesowego, dla którego rynek internetowy jest bardzo dynamiczny i wymaga większej elastyczności w działaniu. "Mieliśmy też przygody z XP, jednak ze względów organizacyjnych nie do końca mogliśmy pozwolić sobie na pełne jego wykorzystanie" - wyjaśnia Lech Rychliński.

Małe i zwinne

Wspomniane metodyki lekkie zarządzania projektami, to właśnie metodyka w wersji light skierowana dla organizacji prowadzących projekty informatyczne. Projekty te wymagają bowiem kreatywności, a klasyczne metodyki to synonim nie kreatywności, ale kontroli i standaryzacji. To nie odpowiada specyfice pracy przy projektach informatycznych. "Specyfika pracy przy softwarze jest zupełnie inna niż przy pracy w fabryce. Posługując się analogią można powiedzieć, że używając tradycyjnych metodyk można zaplanować budowę domu, ale już nie nadają się one do zaprojektowania domu, gdzie konieczna jest interakcja z klientem, wprowadzanie wielu zmian, stałe dostosowywanie planu do zmieniających się warunków zewnętrznych i oczekiwań klienta" - wyjaśnia Janusz Gorycki z firmy Spartez, która nie tylko prowadzi szkolenia z metodyk adaptacyjnych (ang. agile), ale również sama je wykorzystuje.

Metodyki standardowe są nastawione na niezmienne warunki - zmiany są tam notowane jako problemy, a w pracy programisty zmiany to codzienność. Metodologie zwinne w centrum uwagi stawiają okiełznanie takiej pracy kreatywnej, za jaką można uznać pisanie oprogramowania. Stawiają w centrum uwagi to, że proces będzie się zmieniał w trakcie realizacji projektu, że efekt końcowy projektu może być inny niż początkowo zaplanowany.

Dlaczego metodyki adaptacyjne nadają się dla małych firm? "Specyfika projektów software’owych, zresztą nie tylko software’owych, jest taka, że przynajmniej na początku, projekt jest obarczony dużymi obszarami ryzyka. Jest swego rodzaju <<terra incognita>> dla firmy. Podejście adaptacyjne, agile, pozwala na zaadresowanie tego ryzyka od samego początku i <<rozpoznanie terenu>> przy jednoczesnym dostarczaniu części produktu" - tłumaczy Janusz Gorycki. Jest to bardzo atrakcyjne, zarówno dla zespołu realizującego, jak i klienta. Projekt jest wtedy podzielony na części i klient dostaje, np. co dwa tygodnie, fragmenty zamówionego produktu. Widzi na bieżąco efekty pracy, może na bieżąco reagować i wprowadzać zmiany, modyfikacje, a zespół projektowy może te zmiany szybko wprowadzić w życie, nie dowiaduje się o konieczności modyfikacji lub zmiany produktu po zakończeniu jego realizacji. "Standardowe metodyki kładą bardzo duży nacisk na planowanie całego projektu. Metodyka agile mówi natomiast: zaplanuj tyle, ile trzeba i ile się da, zrób kawałek, po krótkim czasie, kiedy wiesz więcej, zaplanuj lepiej następny kawałek" - zauważa Janusz Gorycki. "Tym sposobem w trakcie projektu uczymy się, precyzujemy swoje potrzeby, a jednocześnie realizujemy już projekt" - dodaje.

Efekt końcowy otrzymujemy w podobnym czasie, jak w przypadku metodyk standardowych. Różnica jest taka, że jeśli stosujemy metodyki zwinne, klient szybciej widzi efekty, a zespół projektowy łatwiej reaguje na zmiany. Zgodnie z zasadą Pareto, klient zwykle (80% przypadków) najbardziej potrzebuje ok. 20% "efektu końcowego". Metodyki standardowe nie pozwalają na otrzymanie tych 20% przed zakończeniem całości projektu. Metodyka agile, niejako z zasady, stara się te krytyczne 20% dostarczyć jak najszybciej.