Idee

Na początku musi być potrzeba posiadania czegoś nowego — nowego produktu, również usługi. Produktem takim może być nowy telefon, nowy samochód, nowy program komputerowy, nowe szkolenie, czy też nowy system zarządzania przedsięwzięciem (nastawionym na zysk bądź non profit), który nie może się obyć bez szybkiej komunikacji na odległość, transportu, systemów informatycznych i wiedzy jak z tego wszystkiego korzystać.

Potrzeba może zostać wyrażona wprost przez potrzebującego, może zostać wydedukowana (i wykazana potrzebującemu) przez usługodawcę, który jest w  stanie dostarczyć odpowiedni produkt, lub może być wyimaginowana przez wizjonera i następnie wykreowana w taki sposób, że każdy, kto natknie się na  dany wytwór, natychmiast go zapragnie.

Jeśli dla produktu znajdzie się odbiorca masowy będzie on mógł powstawać w wyniku produkcji ciągłej (lodówka, mikroprocesor, system zarządzania relacyjnymi bazami danych), choć samo opracowanie takiego produktu, umożliwiające jego produkcję ciągłą, wymaga już podejścia projektowego. Jeżeli odbiorca produktu jest jednostkowy to całość jego implementacji realizowana jest w ramach projektu.

Zarządzanie produkcją ciągłą, prowadzącą do powstania wyrobów, których jakość wyznaczana jest przez zgodność z wymaganiami, potrzebuje zgoła innego podejścia niż zarządzanie projektami, prowadzącymi do powstawania produktów, których miernikiem jakości ma być ich odpowiedniość do celu ich zastosowania (patrz: [Ballard2003]). Zgodność z wymaganiami jest oczywiście o wiele łatwiej zmierzyć niż przystawanie do wciąż zmieniających się potrzeb. Potrzeby odbiorców masowych nie zmieniają się u wszystkich w  tej samej chwili, a zatem w wyniku tego, że kilka, a nawet kilkaset osób sprzedało swoje Fiaty, aby kupić Fordy nie oznacza, że producent Fiatów musi natychmiast zamknąć całą linię produkcyjną danego modelu. Kiedyś to zapewne zrobi, ale los ten będzie czekał również Forda, zresztą tak samo jak innych producentów dóbr masowych. W przypadku produktów mających zastosowanie jednostkowe muszą być one dostosowywane do nowej rzeczywistości, a jeśli się to nie opłaca — zastępowane nowymi produktami.

Systemy zarządzania, mające na celu zapewnienie maksymalnej, możliwej efektywności funkcjonowania przedsięwzięć, są produktami jednostkowymi. W  przypadku firm komercyjnych, od sprawności systemu zarządzania będzie zależeć ich konkurencyjność na rynku. Firmy poszukują nowych rozwiązań, którymi będą w stanie zaskoczyć swoich rywali. W przypadku instytucji administracji państwowej, sprawne zarządzanie może oznaczać podniesienie standardu życia obywateli z jednoczesnym brakiem zarzutów o marnotrawienie pieniędzy z kieszeni podatnika. Administracja państwowa nie ma dla siebie konkurencji, więc nie musi się obawiać, że ktoś odbierze jej klientów. Za  tym jednak idzie fakt, że cele administracji państwowej są jeszcze bardziej unikatowe aniżeli cele przedsiębiorstw. To z kolei implikuje konieczność posiadania niekiedy bardzo specyficznych narzędzi, które i tak z punktu widziana dostawców, są niczym innym jak tylko produktami.

Potrzebującym nowych produktów winno zależeć przede wszystkim na tych produktach, a nie na wiedzy, w jaki sposób produkty te powstają i na  kontroli tego procesu. Bywają jednak przypadki, a do takich zaliczają się te  najbardziej unikatowe potrzeby, że zaspokojenie wymagań nie może się odbyć bez udziału potrzebującego i to na każdym etapie produkcji. W takich sytuacjach przedsięwzięcie, w wyniku którego ma powstać wytwór jest najczęściej projektem samego potrzebującego, w którym chce on mieć decydujący głos, jedynie outsource’ując pewne fragmenty.

To wszystko jednak nie zmienia faktu, że najważniejszy jest produkt, a  reszta to tylko narzędzia wspomagające jego tworzenie (np. metodyka). Te  narzędzia również są produktami. Uwaga: Na każdym kroku wytwarzania powinniśmy znać odpowiedź na pytanie — czy rzeczywiście to co teraz robimy, czy też to co teraz wykorzystujemy przybliża nas do celu, jaki sobie postawiliśmy.

W związku z tym, że w wyniku projektu ma powstać coś nowego, bądź coś, co już istniało ma być wykonane w nowy sposób (to tylko fragment definicji pojęcia projekt, w [Wideman2002] można znaleźć 23 różne podejścia do zdefiniowania angielskiego terminu project = przedsięwzięcie) — każde przedsięwzięcie typu projektowego musi być traktowane jako coś odmiennego. Fakt, że na  wykonanie swoich prac nie dysponujemy nieskończenie długim czasem i  nieskończenie obszernymi zasobami, jeszcze bardziej to podkreśla.

Projekty mogą się różnić od siebie innym naciskiem na poszczególne zmienne. Czasem chodzi, przede wszystkim o zrealizowanie wymagań, innym razem istotniejszą od tego kwestią jest szybkie dostarczenie produktu, choćby cząstkowego, jeszcze w innym przypadku musimy się liczyć z  koniecznością wykonywania swoich prac po jak najniższych kosztach.

W przypadku, gdy w wyniku projektu ma powstać również oprogramowanie komputerowe, zagadnienie staje się jeszcze bardziej złożone. A dzieje się tak dlatego, że oprogramowanie jest produktem całkowicie niematerialnym, a  zatem dużo trudniej, niż cokolwiek innego, wyobrażalnym. Jeżeli częścią produktu powstającego w ramach projektu (system zarządzania) mają być właściwe środki IT (system informatyczny umożliwiający funkcjonowanie systemu zarządzania) to właśnie ta część, związana z IT jest głównym wyznacznikiem kosztu, czasu trwania i w ogóle powodzenia przedsięwzięcia^[1]. A bez informatyki trudno dziś sobie wyobrazić sprawne funkcjonowanie systemów pomocy społecznej i rynku pracy.

Szczęśliwie, istnieje obecnie już wiele różnych systemów informatycznych, których podpatrywanie pozwala nam na antycypowanie nowych potrzeb, oraz które w całości lub części możemy wykorzystać przy konstrukcji naszego, specyficznego rozwiązania. Szczęśliwie też mamy kilkuletnie doświadczenie związane z funkcjonowaniem systemów PULS i POMOST. Zawsze pozostaje jednak ta część, którą rzeczywiście musimy wykonać od  podstaw^[2] — i tu leży zasadniczy problem. Jakie powinniśmy podjąć działania, aby wyprodukować coś, co na pewno okaże się przydatne, zanim użytkownicy tę przydatność będą mogli zweryfikować sami, korzystając z  dostarczonych im produktów? Jeżeli dostarczony produkt okaże się nieprzydatny — pozostaniemy ze świadomością zmarnowanych funduszy i  czasu.

Konieczność różnego podchodzenia do projektów, w wyniku których produkowane są również narzędzia informatyczne, ma swoje odbicie w  literaturze dotyczącej zagadnienia.

Brooks (patrz: [Brooks2000], str. 16+) porównuje procesy wytwórcze dla programu, produktu programowego, systemu oprogramowania oraz systemu oprogramowania stanowiącego produkt^[3]. Autor twierdzi, że „…produkt programowy kosztuje przynajmniej trzy razy tyle co pozbawiony błędów program o tych samych funkcjach.” (patrz: [Brooks2000], str. 18). „…system oprogramowania jako produkt. Różni się od prostego programu pod każdym względem. Kosztuje dziewięć razy więcej.”. Zarządzanie przedsięwzięciem, które kosztuje dziewięć razy więcej (w domyśle wymaga dziewięciokrotnie większego wysiłku) musi wymagać innego podejścia! A czego my potrzebujemy?

Highsmith (patrz: [Highsmith2000], str. 18) podkreśla konieczność zwrócenia uwagi na dwa, niezmiernie jego zdaniem istotne, elementy przedsięwzięć IT, te z którymi musimy się liczyć podczas wytwarzania produktów. Rzecz pierwsza to kwestia szybkości działania — czy rzeczywiście musimy się spieszyć, a jeśli tak, to jak bardzo. Rzecz druga — to pytanie o szybkość pojawiania się zmian. Czy jesteśmy w stanie zdążyć z  czymkolwiek, zanim założenia leżące u podstaw naszego działania nie ulegną dezaktualizacji? Wg Highsmith’a, kiedy nie musimy się aż nadto spieszyć, ani aż nadto obawiać zmian, to możemy pozwolić sobie na wodospadowy cykl tworzenia naszego produktu. Jeżeli jednak mimo braku konieczności pośpiechu w działaniu musimy liczyć się z bombardowaniem zmianami, lepiej byłoby zdecydować się na podejście ewolucyjne (patrz: [Gilb1988]) bądź spiralne (patrz: [Boehm1988], str. 61-72 oraz [Boehm2000]). Wybór modelu realizacji projektu należy do  kluczowych zagadnień, co do których należy się określić przystępując do  prac. Są to modele wytwarzania produktów, ale jeszcze raz pozwolę sobie podkreślić — to właśnie produktu potrzebujemy.

W trakcie realizacji projektu ALSO, którego jesteśmy spadkobiercami, dokonano nowelizacji łącznie 76 aktów prawnych mających wpływ na  funkcjonowanie systemów POMOST (patrz: [Smoleński1999], str. 56) i PULS (patrz: [Jakóbik1999], str. 57-58). Czego musimy się obawiać tym razem?

Prawdopodobnie najdalej w różnicowaniu podejść do przedsięwzięć posuwa się Cockburn (patrz: [Cockburn2002]). Wg niego, przy doborze sposobu realizacji projektu powinniśmy się kierować zagrożeniami, jakie się objawią w przypadki niedostarczenia odpowiedniego produktu (począwszy od utraty komfortu po utratę życia) oraz liczbą osób zaangażowanych w przedsięwzięcie. I tak dla projektu typu C6 (utrata komfortu / ok. 6 osób zaangażowanych) powinniśmy podejść nieco inaczej niż do projektu typu C20 (utrata komfort / ok. 20 osób zaangażowanych) i  absolutnie inaczej niż do projektu typu L100 (utrata życia / ok. 100 osób zaangażowanych). Zmienną dodatkową, jaką autor radzi wziąć pod uwagę jest ustalenie priorytetu (szybkość działania / tolerancja dla zmian / zgodność z  prawem). Jaki jest nasz projekt?

Metodyka jest „zbiorem zasad dotyczących sposobu wykonania jakiejś pracy lub trybu postępowania prowadzącego do określonego celu” (patrz: [PWN1979], str. 144), a zatem ma  określać to, jak powinniśmy pracować, aby otrzymać pożądany produkt w  ogóle^[4]. Dobra (najbardziej odpowiednia) metodyka powinna umożliwiać wykonanie tego przy minimalnych kosztach i oczywiście jak najszybciej. W  związku z tym, że każdy projekt jest inny, każdemu potrzebne jest inne podejście, a zatem inna metodyka.

Nie oznacza to jednak, że za każdym razem musimy odkrywać świat na  nowo. Projekty należące do tej samej klasy, przy zachowaniu minimum zdrowego rozsądku, mogą być realizowane na podobnych zasadach. Im liczniejsza jest klasa, do jakiej dany projekt można zaliczyć, tym większe jest prawdopodobieństwo odnalezienia gotowej i sprawdzonej metodyki, którą po  nieznacznym przystosowaniu można zacząć przynosić nam wymierne korzyści.

W przypadku dużych przedsięwzięć, a zapewne wszyscy, jeśli tego nie jesteśmy pewni, to podskórnie czujemy, że projekt „SYRIUSZ” właśnie do takich należy zaliczyć — sprawa jest bardziej skomplikowana. W  takich przypadkach, w sposób naturalny chcemy kierować swoje kroki do  „wielkich metodyk”, jak np. metodyka rządu brytyjskiego PRINCE 2 (patrz: [Prince2]) bądź metodyka RUP (patrz: [RUP]) stanowiąca, od niedawna, własność firmy IBM. „Wielkość” tych metodyk nie oznacza jednak tylko tego, że są one dedykowane realizacji „dużych” przedsięwzięć. Autorzy obydwu twierdzą, że metodyki te nadają się niemal do wszystkiego, od  projektów jednoosobowych, po takie, w które zaangażowane są setki, a nawet tysiące uczestników. Aby było to możliwe metodyki te muszą zostać najpierw dostosowane do rzeczywistych potrzeb, a zatem nie można w takim przypadku mówić wprost o metodykach, a raczej o zbiorach czy rodzinach lub też generatorach^[5] metodyk.

Od pojęcia rodziny wychodzi Cockburn, proponując swoją Crystal Methodologies Family (patrz: [Cockburn2002], str. 198-212), a w ramach niej kolejne metodyki dla różnych klas projektów: Crystal Clear, Crystal Yellow, Crystal Orange, Crytsal Red. Choć nie wszystkie one zostały już zaproponowane, w zamierzeniu mają stanowić zamknięte całości, oparte na  wspólnych podstawach.

Od nieco innej strony podeszli autorzy RUP. Najpierw zebrali ogromny materiał metodyczny, wcześniej rozproszony w różnych publikacjach, a  następnie na tej bazie rozpoczęli budować konkretne metodyki, nazywane przez nich Development Case’ami. RUP wciąż jednak nie jest odbierany jako zbiór gotowych metodyk, ale worek z pomysłami, z którego mamy wybierać. Krytyka takiego podejścia: „skoro jest wszystkim to może się okazać, że jest niczym” (patrz: [Fowler2003]); „jak dużo należy pozostawić z RUP, aby powstający, w wyniku odchudzania całości, proces wciąż jeszcze był RUP’em” (patrz: [Abrahamsson2002], str. 61) nie wydaje się być nieuzasadniona.

Autorzy metodyki PRINCE 2, w przeciwieństwie do wersji pierwotnej PRINCE, postanowili opisać zasady zarządzania każdego typu projektem, bez względu na to czy w ramach projektu ma powstać oprogramowanie czy też nie. I  tu mogą nasunąć się dodatkowe wątpliwości, takie same, jakie kierowane są do  zaleceń zawartych w PMBOK (patrz: [PMBOOK]) opracowanym przez Project Management Institute – ukierunkowanie jedynie na planowanie WBS^[6] (oprócz dziesięciu procesów związanych z planowaniem jest tylko jeden proces związany z realizacją oraz dwa procesy kontrolne, patrz: [Koskela2002], str. 293-302).

Wybór nie jest łatwy.

Kiedy uda się nam wstępnie określić klasę naszego projektu (co jeszcze raz podkreślę, musi stanowić podstawę do dalszych prac nad metodyką — por. całe wyżej zamieszczone sekcje o produkcie i przedsięwzięciu), powinniśmy otworzyć szeroko oczy na to co już jest dostępne na polskim rynku. Być może będzie istniał, odpowiedni dla nas Development Case Rational Unified Process’u, być może okaże się, że PRINCE 2 da się w miarę szybko przystosować do naszych potrzeb. Ale wzięcie którejkolwiek z tych metodyk, ot tak, dlatego, że sprzedawca stojący za daną metodyką twierdzi, że „będzie dobra, bo już ją inni wykorzystują i są szczęśliwi”^[7] — może nie okazać się najlepszym posunięciem.

Możliwe też, że pewnych rzeczy nie będzie w wybranej przez nas metodyce i wówczas konieczne okaże się skorzystanie z dodatkowych zasobów wiedzy. W przypadku metodyki PRINCE 2, dobrym jej uzupełnieniem może okazać się bardziej konkretna, ukierunkowana na wytwarzanie systemów informatycznych, również brytyjska i nie mniej w Wielkiej Brytanii rozpowszechniona metodyka DSDM (patrz: [Stapleton1997] i  [DSDM2003]).

Gdyśmy dla uzyskania przyspieszenia, zmniejszenia kosztów i  zwiększenia jakości wyników zechcieli oprzeć część naszych rozwiązań na  istniejących już i sprawdzonych fragmentach kodu open source, powinniśmy dobrze przyjrzeć się umowom licencyjnym towarzyszącym tym fragmentom. W  pewnych przypadkach nasz kod oprogramowania, w sposób automatyczny mógłby stać się kodem open source, a wówczas musiałby być wytwarzany i pielęgnowany na zasadach obowiązujących w społecznościach open source, którym daleko jest do zasad wskazywanych przez jakąkolwiek z metodyk sformalizowanych (patrz: [Young2001]).

Być może też, okaże się, że pewnych potrzebnych nam wskazówek w ogóle nie znajdziemy w żadnej z istniejących metodyk. Dopiero wówczas powinniśmy rozpocząć poszukiwania naszych własnych, autorskich pomysłów, w oparciu o  nasze własne, dotychczasowe doświadczenia. Gdybyśmy zdecydowali, że nasze docelowe rozwiązanie chcemy skonstruować w oparciu o homologację, a zatem poprzez kreację prawdziwie konkurencyjnego rynku dostawców niezbędnych nam produktów, to możemy się zetknąć z koniecznością opracowania własnych elementów metodyki.

Przy wyborze właściwej metodyki wypada też pamiętać o koszcie jej posiadania. Zakupienie odpowiednich podręczników (w formie papierowej czy też elektronicznej) to jeszcze nie wszystko. Dokumentacja nie oznacza jeszcze zrozumienia^[8]. Koszt szkoleń i być może konsultantów udzielających swojego wsparcia może stanowić zauważalną część budżetu projektu. Rzeczą nierozłącznie z tym związaną jest też kwestia czasu, jaki należy przeznaczyć na przygotowanie i pielęgnowanie metodyki. Metodyka jest wiedzą o sposobie prowadzenia projektu i jako taka nie może po prostu zostać wypakowana z  pudełka, zainstalowana na komputerze i uruchomiona. Musi zostać przyswojona.

Należy też zwrócić uwagę na ciekawą zależność dwukierunkową pomiędzy liczbą osób i stopniem sformalizowania postępowania w projektach. Im więcej mamy osób w projekcie tym stopień sformalizowania prac powinien być większy. Z drugiej jednak strony liczbę osób zaangażowanych w przedsięwzięcie będziemy mogli zredukować dzięki zastosowaniu mniej sformalizowanej metodyki (patrz: [Cockburn2002] str. 163). Ale tutaj znów musimy przywołać do pamięci fakt, że zwiększenie zespołu projektowego w chwili kryzysu zazwyczaj prowadzi do katastrofy (patrz: [Brooks2000] str. 163).

I rzecz ostatnia w tym krótkim wprowadzeniu do zagadnienia metodyki dla projektu „SYRIUSZ”. Wybranej, dostosowanej i wzbogaconej metodyki nie powinniśmy traktować jak Biblii. Produkowanie kolejnego dokumentu, tylko dlatego, że tak mówi nasza metodyka, bo kiedy dokonywaliśmy jej wyboru wydawało się to słuszne — nie będzie dobrym rozwiązaniem, gdy wszyscy nabiorą przekonania, że dany materiał ani na krok nie przybliża nas do celu. A problem w tym, że nie wszystko da się z góry przewidzieć, a zatem zaplanować. Nasz projekt może w trakcie realizacji zmienić swoją klasę.

Metodyka ma być dla nas przewodnikiem, uwalniającym nas od  konieczności ciągłego poszukiwania odpowiedzi na pytanie: „a co by tu  jeszcze zrobić?” oraz ciągłego poczucia żalu, że zrobiło się coś, co  wprawdzie było ciekawe, ale nijak nie przystawało do potrzeb. Jako przewodnik, nie musi istnieć w szczegółach, od razu, na starcie projektu, ale wszelkie wskazówki metodyczne powinny być dostępne wtedy, kiedy się ich potrzebuje.

Co do ram metodyki powinniśmy się określić na samym początku. Jej szczegóły nie mogą stanowić jednak jedynie opisu sposobu realizacji projektu, udostępnionego po jego zakończeniu.