PZP vs. AGILE

Ciekawy artykuł na temat uznanych metodyk w kontekście Prawa Zamówień Publicznych. Zachęcam do uważnej lektury. Pod dyskusję poddałbym także relację PZP do architektury korporacyjnej.

autorem artykułu jest Łukasz Węgrzyn, a także Michał Bagłaj, Piotr Kaniewski i Jakub Krysa, prawnicy w Praktyce Transformacji Cyfrowych w kancelarii Maruta Wachta sp.j. artykuł ukazał się na łamach ITWIZ.PL 18 stycznia 2017.

Dla sektora prywatnego pytaniem nie jest już czy, ale kiedy agile stanie się dominującym modelem realizacji przedsięwzięć IT. A co z sektorem publicznym? W stosunku do tego drugiego, panuje przekonanie, że realizacja projektów IT w metodykach zwinnych nie jest możliwa. Jako jedną z przeszkód wskazuje się Prawo zamówień publicznych. Czy rzeczywiście tak jest? Na to pytanie spróbujemy odpowiedzieć w ramach tego cyklu.

Powstanie Agile powszechnie łączy się z ogłoszeniem tzw. Manifestu Agile, jakie miało miejsce podczas konferencji w Snowbird (Utah, USA) w lutym 2001 r. Jednak historia agile sięga znacznie dalej. Pomijając nieco przesadne poglądy, że początki zwinności można odnaleźć w metodzie naukowej przedstawionej w roku… 1620 przez F. Bacona, to idea prowadzenia projektów, na których współcześnie opiera się agile, jest wyraźnie dostrzegalna już w produkcji przemysłowej działającej w latach 30-tych XX wieku, a wykrystalizowała się na przełomie jego lat 80-tych i 90-tych.

W 1986 r., na łamach Harvard Business Review (01/1986), H. Takeuchi i I. Nonaki opublikowali artykuł pt. The New New Product Development Game, stanowiący zbiór spostrzeżeń co do wspólnych cech metod zarządzania innowacyjnymi przedsięwzięciami i ich skutków dla tych przedsięwzięć. Ta publikacja to kamień milowy na drodze do stworzenia dojrzałych modeli zwinnego zarządzania projektami. Niecałą dekadę później, w 1995 r., Ken Shwaber zaprezentował podczas konferencji Object Oriented Programming, System, Languages & Applications (OOPSLA) podstawowe założenia metodyki Scrum – aktualnie najpopularniejszej zwinnej metodyki realizacji produktów IT.

Jak widać, agile nie jest owocem spotkania w Snowbird. Jego zasady, wyrażone w Manifeście Agile, są co prawda wyrazem radykalnej zmiany sposobu myślenia o zarządzaniu projektami IT – ale powstającej ewolucyjnie, przez lata, w praktyce wytwórczej wielu innowacyjnych organizacji. W Snowbird, pod wspólnym sztandarem, doszło do zjednoczenia tych praktyk, czy raczej idei – oraz do ustalenia ich wspólnego programu. Od tej pory zaczęto mówić o agile, ale hasło to pokrywa już wcześniej istniejące metodyki wytwarzania i wspólną im filozofię myślenia (mindset).

“9 grudnia 2010 r. Biały Dom wydał dokument „25 Point Implementation Plan to Reform Federal Information Technology Management”. Zawiera on m.in. wytyczne przejścia na zwinny model wytwarzania oprogramowania – w celu redukcji kosztów, zmniejszenia ryzyka niepowodzenia projektów IT oraz dostarczenia podatnikom systemów IT zapewniających odpowiednie standardy bezpieczeństwa i jakości. Wytyczne te identyfikują problemy, jakie mogą napotkać organy państwowe realizując przedsięwzięcia IT, wskazują jak je rozwiązać, za pomocą jakich narzędzi i w jakim to powinno nastąpić czasie.”

Jakie to ma znaczenie z perspektywy problemów z implementacją agile? Otóż agile powstał właśnie w obliczu problemów – po pierwsze, z efektywnością tradycyjnej metodyki kaskadowej, po drugie – wdrażania zwinności do organizacji, wbrew ich silnym nawykom. Analizując te dwa czynniki możemy znaleźć receptę na adaptację Agile w polskiej rzeczywistości.

Kaskadowy kataklizm, czyli problemy z waterfall

Bezpośrednią przyczyną determinującą powstanie metodyk zwinnych były liczne niepowodzenia projektów IT realizowanych w metodyce kaskadowej (tzw. waterfall). Notorycznie dochodziło w nich – i dochodzi nadal – do niepowodzeń, albo częściowych – kiedy udaje się ukończyć projekt, ale z przekroczeniem budżetu lub harmonogramu, bądź całkowitych – kiedy mimo zainwestowanych środków i czasu, zamawiający nie otrzymywał żadnego przydatnego rezultatu. Zgodnie z badaniami zebranymi w ramach Chaos Report 2015, w przedsięwzięciach IT w latach 2011-2015, w założonym budżecie i czasie i w zaplanowanym z góry kształcie, udało się ukończyć jedynie 11% projektów prowadzonych kaskadowo. 60% z nich udało się dokończyć, ale po napotkaniu istotnych trudności (dotyczących głównie zakresu, budżetu lub harmonogramu). Aż 29% przedsięwzięć skończyło się zupełnym fiaskiem, czyli zmarnowaniem wszystkich zaangażowanych środków i wysiłków. Niesławnym, sztandarowym przykładem takiej porażki jest historia informatyzacji brytyjskiej służby zdrowia – który pochłonął 12 mld funtów (!), trwał 10 lat – a w jego efekcie nie dostarczono żadnego rezultatu przydatnego dla zamawiającego.

Fatalne statystyki projektów IT realizowanych kaskadowo nie pozwalają przyjmować, że winni są wyłącznie ludzie je realizujący. Prowadzą raczej do wniosku, że sam model musi być obarczony wadami. W istocie tak jest – i wyczerpująco wady te opisał W. W. Royce – już w 1970 r. (czyli na samym początku istnienia metodyki kaskadowej), w artykule pt. Managing the Development of Large Software Systems. Autor (jako pierwszy) przedstawił precyzyjny opis procesu budowania oprogramowania i jego kolejne kroki przedstawił graficznie – w sposób przypominający wizualnie wodospad – stąd pochodzi nazwa waterfall. Jego kluczowymi cechami są:

• podział projektu na etapy o różnej długości – w których realizuje się jednorodne rodzajowo czynności, np. kolejno analiza, projektowanie, programowanie, testowanie,

• dążenie do realizacji produktu odpowiadającego 1:1 założeniom podjętym na samym początku projektu – najczęściej wynikającym z analizy.

“11% – jedynie tyle projektów prowadzonych kaskadowo udało się – zgodnie z badaniami zebranymi w ramach Chaos Report 2015 – ukończyć w latach 2011-2015 w założonym budżecie i czasie i w zaplanowanym z góry kształcie. Aż 60% z nich udało się dokończyć, ale po napotkaniu istotnych trudności (dotyczących głównie zakresu, budżetu lub harmonogramu).”

Sam waterfallowy podział projektu na etapy W. W. Royce określił mianem „ryzykownego i ściągającego niepowodzenie”. Wskazał, że przez długi czas wykonawca pracuje w zupełnej separacji od zamawiającego (klienta) i dopiero na sam koniec projektu, kiedy cała planowana praca została wykonana – sprawdza się, czy produkt działa i czy odpowiada przyjętym na wstępie założeniom. Jeśli jest im on odległy – w chwili, w której powinno się zamykać projekt, konieczne jest wykonanie czasochłonnej i kosztownej pracy polegającej na dokonaniu koniecznych poprawek.

Jeszcze istotniejszą wadą modelu kaskadowego jest dążenie do realizacji z góry przyjętych założeń. W. W. Royce słusznie zauważył, że problem powstaje już w chwili ich interpretacji – wykonawca odczytuje zaplanowane wymagania inaczej niż zamawiający i podczas ich weryfikacji jest bardzo prawdopodobne, że dojdzie do konfliktu o to, czy dane wymaganie zostało zrealizowane. Celnie zostało to ujęte w „Managing the Development of Large Software Systems”: danie wykonawcy wolnej ręki w zdefiniowaniu wymagań, które potem sam będzie realizował, oznacza zaproszenie problemów do projektu.

Kwestia ta rodzi jednak jeszcze inne, znacznie groźniejsze niebezpieczeństwo, które w ostatnich latach wyraźnie się uwypukliło: brak możliwości odpowiednio szybkiej reakcji na zmiany zachodzące podczas realizacji projektu IT. Współczesny rozwój techniki, przyrastający nieomal w tempie geometrycznym, powoduje, że w czasie pomiędzy chwilą zamknięcia analizy i przystąpieniem do budowania oprogramowania, a oddaniem gotowego produktu – co w projektach średniego i dużego rozmiaru trwa od kilku miesięcy do nawet kilku lat – dochodzi do znaczących przeobrażeń, które zmieniają zakres potrzeb zamawiającego i możliwości wykonawcy. Rozwój oprogramowania w modelu waterfall w istotny sposób utrudnia, aby nie powiedzieć uniemożliwia, szanse na dostosowanie się do tych zmian. W efekcie, zamawiający, po poniesieniu znacznych kosztów, po długim czasie oczekiwania – otrzymuje produkt, który go nie satysfakcjonuje, bo jest w mniejszej lub większej mierze przestarzały lub niezaadaptowany do jego aktualnych potrzeb biznesowych. Rozmiar tego zjawiska najlepiej charakteryzują wyniki badań amerykańskich naukowców, którzy dostarczyli statystycznych informacji o tym, w jakim tempie dochodzi do dezaktualizacji wymagań analizy przedwdrożeniowej, tj. po jakim czasie przestają odpowiadać potrzebom zamawiającego albo realiom technicznym. Mowa jest o badaniach zespołu z Uniwersytetu Missouri pod kierownictwem prof. A. Goernera. Naukowcy ci, dla zobrazowania erozji wymagań analizy, stworzyli model oparty na zjawisku ze świata fizyki – tzw. połowicznym rozpadzie. Zgodnie z tym modelem, 50% wymagań analizy przedwdrożeniowej staje się zupełnie bezwartościowa już po upływie… 6 miesięcy (!). Po upływie kolejnych 6 miesięcy, bezużyteczne staje się 50% pozostałej części – czyli łącznie, po roku, zupełnie nieaktualne jest 75% analizy. A po dwóch latach – aż 92,5%!

“Współczesny rozwój techniki, przyrastający nieomal w tempie geometrycznym, powoduje, że w czasie pomiędzy chwilą zamknięcia analizy i przystąpieniem do budowania oprogramowania, a oddaniem gotowego produktu – co w projektach średniego i dużego rozmiaru trwa od kilku miesięcy do nawet kilku lat – dochodzi do znaczących przeobrażeń, które zmieniają zakres potrzeb zamawiającego i możliwości wykonawcy. Rozwój oprogramowania w modelu waterfall w istotny sposób utrudnia, aby nie powiedzieć uniemożliwia, szanse na dostosowanie się do tych zmian.”

Podsumowując, realizacja projektów w waterfallu jest obarczona ogromnym ryzykiem, z uwagi na niewydolność tego modelu –wynikającą z jego „wad wrodzonych” – które współczesny dynamiczny rozwój techniki dodatkowo pogłębił. W tym wszystkim chichotem historii można określić fakt, że W. W. Royce – który już na samym początku korzystania z metodyki nazwanej później kaskadową, wskazał jej najistotniejsze wady i zaproponował sposoby ich rozwiązania – w zbiorowej świadomości figuruje jako ojciec waterfallu i porażki, która zanim podąża. Plotka głosi, że wynika to z faktu, że pracownik Departamentu Obrony USA, który poszukiwał, na początku lat 70-tych XX wieku, informacji o wytwarzaniu oprogramowania, znalazł artykuł W. W. Royce’a, ale przeczytał tylko jego pierwszą stronę i zarekomendował jej stosowanie, przypisując jemu jej autorstwo.

Dlaczego agile działa lepiej

W przeciwieństwie do metody kaskadowej, Agile zakłada:

• częste dostarczanie małych elementów produktu końcowego;

• ścisłą współpracę na partnerskich zasadach pomiędzy zamawiającym a wykonawcą – i udział zamawiającego w bieżących pracach wykonawcy;

• ustalanie na początku projektu wymagań na dosyć ogólnym poziomie – które następnie – w ramach każdej iteracji – będą doprecyzowywane;

• elastyczność i otwartość na zmiany – możliwość korygowania założonych wymagań, w zależności od pojawiających się okoliczności tak, aby finalnie zamawiający otrzymał satysfakcjonujący go produkt.

Wskazane założenia zwinnego zarządzania przedsięwzięciami pozwalają zniwelować podstawowe wady waterfall. Częste dostarczanie małych części produktu pozwala na ich bieżące weryfikowanie przez zamawiającego i ocenę, czy zaspokajają jego potrzeby. Dzięki ścisłej współpracy, strony razem określają precyzyjnie, co ma być w danej iteracji wykonane – a w razie niepowodzenia – dlaczego do niego doszło i jak uniknąć go w przyszłych fazach. Możliwość doprecyzowywania i korygowania zakresu (przedmiotu) projektu pozwala na uniknięcie sytuacji, w której wykonawca dostarczy przestarzały lub z innego powodu nieodpowiadający realiom produkt. Oczywiście, za zmianami przedmiotu muszą podążać zmiany harmonogramu i budżetu, jeśli są potrzebne. W Agile zamawiający może na bieżąco wpływać na pracę wykonawcy i ma świadomość oraz kontrolę nad tym, co otrzyma na końcu przedsięwzięcia. Dlatego niekiedy Agile określa się mianem kultury „klientocentrycznej”.

“Wadą modelu kaskadowego jest dążenie do realizacji z góry przyjętych założeń. W. W. Royce słusznie zauważył, że problem powstaje już w chwili ich interpretacji – wykonawca odczytuje zaplanowane wymagania inaczej niż zamawiający i podczas ich weryfikacji jest bardzo prawdopodobne, że dojdzie do konfliktu o to, czy dane wymaganie zostało zrealizowane. Jak zostało to celnie ujęte w „Managing the Development of Large Software Systems”: danie wykonawcy wolnej ręki w zdefiniowaniu wymagań, które potem sam będzie realizował, oznacza zaproszenie problemów do projektu.”

Oczywiście, Agile nie jest lekarstwem na wszystko. Wiążą się z nim pewne trudności. Przede wszystkim to zaimplementowanie zwinnego modelu wytwarzania w organizacji, znalezienie odpowiednio wykwalifikowanego i doświadczonego personelu oraz możliwość udzielenia drugiej stronie znacznego kredytu zaufania potrzebnego do zbudowania relacji partnerskiej. Wszystko to wymaga dużej elastyczności, na początku także na pewno cierpliwości, jak i sporych wydatków. Nie mniej, warto znieść te niedogodności. Agile generuje znaczące oszczędności – przede wszystkim co do kosztów i czasu. Chociaż jest pewnie odległy od ideału, ma istotną zaletę w porównaniu do waterfallu, na ogół działa.

Statystyki dowodzą, że zastosowanie zwinnych zasad zarządzania projektami IT znacznie podnosi prawdopodobieństwo sukcesu projektu IT. Według Chaos Report 2015, w latach 2011-2015, wszystkich projektów zakończonych sukcesem (tj. w zaplanowanym zakresie, zgodnie z budżetem i harmonogramem), a przy których zastosowano Agile, było o 250% więcej niż projektów zakończonych sukcesem, a w których zastosowano waterfall. Co więcej, Chaos Report 2015 ujawnił prawidłowość, że najwięcej, na zastosowaniu zwinności, zyskują duże projekty. W ich przypadku, przy zastosowaniu Agile, sukcesem zakończyło się aż 5 razy więcej projektów niż przy zastosowaniu waterfall! Wśród projektów średnich rozmiarów, sukcesem zakończyło się o ok. 280% więcej projektów zwinnych niż tych prowadzonych w metodyce kaskadowej – a wśród małych projektów – o 32% więcej.

Taka perspektywa jest najlepszym argumentem, że warto zastosować Agile. Oznacza on zresztą nie tylko ogromną szansę na znaczące oszczędności finansowe i czasowe w stosunku do prowadzenia projektów IT w sposób tradycyjny. Sprawia on też, że optymalizacji ulega jakość produktu – zarówno z perspektywy standardu jego wykonania, jak i przydatności dla zamawiającego.

Zwinne projekty w sektorze publicznym

Korzyści płynące z Agile nie umknęły uwadze podmiotom rynku publicznego na Zachodzie. Borykały się one z tymi samymi problemami wynikającymi z metodyki kaskadowej, co rynek prywatny. Dlatego w wielu krajach podjęto się próby uzwinnienia sektora publicznego. Na tego typu eksperyment zdecydowano się m.in. w Holandii. Miał dotyczyć wdrożenia nowego oprogramowania Harbour Master Management and Information System (HaMIS) przeznaczonego do zarządzania portem w Rotterdamie – największym portem morskim w Europie.

“Częste dostarczanie w agile małych części produktu pozwala na ich bieżące weryfikowanie przez zamawiającego i ocenę, czy zaspokajają jego potrzeby. Dzięki ścisłej współpracy, strony razem określają precyzyjnie, co ma być w danej iteracji wykonane – a w razie niepowodzenia – dlaczego do niego doszło i jak uniknąć go w przyszłych fazach. Możliwość doprecyzowywania i korygowania zakresu (przedmiotu) projektu pozwala na uniknięcie sytuacji, w której wykonawca dostarczy przestarzały lub z innego powodu nieodpowiadający realiom produkt.”

HaMIS miał być głównym systemem IT obsługującym port zajmujący 105 km2 powierzchni, obracający rocznie kwotami przekraczającymi 500 mln euro, który odwiedza rocznie ok. 34 tys. statków. Jednak w ramach agile miał zostać wykonany jedynie niewielki element systemu. Szybko okazało się, że element wykonywany zwinnie jest rozwijany najszybciej i najefektywniej – a pozostała część projektu napotykała istotne trudności już na etapie przygotowania szczegółowego planu systemu. Oczekiwania zamawiającego ewoluowały zbyt dynamicznie. Po zaledwie kilku miesiącach zadecydowano o zaimplementowaniu agile do całości projektu. Wdrożenie HaMIS zakończyło się sukcesem.

Agile zastosowano także w dużym projekcie rządowym w Danii. Przy użyciu metodyk zwinnych został zaprojektowany i stworzony internetowy system rejestracji spółek handlowych, który całkowicie wyparł „papierowy” proces rejestracji. Choć nadal jest on wiodący przy rejestracji w rejestrze przedsiębiorców Krajowego Rejestru Sądowego. Przedsięwzięcie zakończyło się pełnym sukcesem. Nie tylko dlatego, że udało się ukończyć wdrożenie w ramach zaplanowanego budżetu i harmonogramu, ale przede wszystkim ze względu na osiągnięcie znacznego poziomu satysfakcji użytkowników końcowych – przedsiębiorców operujących w Danii. W trakcie realizacji przedsięwzięcia zasięgano ich opinii i konsultacji, czego efektem było stworzenie procedury rejestracji spółek, która jest uznawana za jedną z najprostszych, najszybszych i najbardziej user-friendly na świecie.

Ciekawe i nietypowe zastosowanie metodyki zwinne znalazły w Wielkiej Brytanii – użyto ich nie do przeprowadzenia projektu IT, ale do budowy Terminalu 5 na lotnisku Heathrow w Londynie. Łączny koszt tego projektu wyniósł ok. 4,3 mld funtów. Przystąpiono do budowy adaptując zwinne podejście z projektów IT z trzech względów. Pierwszym z nich był fakt, że Terminal 5 miał być bardzo nowoczesny – i równolegle z jego budową powstawały instalacje elektroniczne i systemy IT do obsługi lotniska. Postanowiono projektować je w taki sam sposób. Drugim czynnikiem, który zadecydował o zastosowaniu agile, była silna intencja możliwości zmieniania pierwotnego planu terminalu – tak aby odpowiadał on dynamicznie zmieniającym się okolicznościom. Jednak, przede wszystkim, argumentowano, że podobnie jak system IT przeznaczony dla klientów końcowych, lotnisko również ma służyć potrzebom osób trzecich – w tym wypadku pasażerów – i powinno zostać zaprojektowane z myślą o nich i przy współpracy z nimi.

W Stanach Zjednoczonych, agile święci jeszcze większe triumfy na rynku publicznym. Dobrym przykładem udanego przedsięwzięcia jest chociażby projekt Sentinel prowadzony przez FBI – polegający na wdrożeniu systemu do obiegu dokumentów. Początkowo realizowano go w waterfall i mimo wydania 500 mln USD nie osiągnięto zamierzonych efektów. Całe przedsięwzięcie uratowało zastosowanie metodyk zwinnych – w krótkim czasie doprowadziło ono do dostarczenia działającego, w pełni funkcjonalnego systemu.

Jednak czynnikiem, który sprawia, że Stany Zjednoczone znacznie wyprzedzają pozostałe państwa w stopniu zaimplementowania agile oraz związanej z tym efektywności prowadzenia projektów IT, jest nie sama liczba udanych projektów, ale transformacja do modelu zwinnego całego sektora amerykańskiej administracji publicznej w zakresie w jakim ma do czynienia z IT. Wymagało to odgórnych wytycznych, pochodzących m.in. z samego Białego Domu oraz stworzenia licznych oficjalnych dokumentów pozwalających na różnych szczeblach administracji publicznej zaimplantować Agile – zarówno w obszarze procedur, jak i mentalności urzędniczej. Koronnym przykładem takiego dokumentu jest wydany przez Biały Dom, 9 grudnia 2010 r., 25 Point Implementation Plan to Reform Federal Information Technology Management, który zawiera m.in. wytyczne przejścia na zwinny model wytwarzania oprogramowania – w celu redukcji kosztów, zmniejszenia ryzyka niepowodzenia projektów IT oraz dostarczenia podatnikom systemów informatycznych zapewniających odpowiednie standardy bezpieczeństwa i jakości. Wytyczne te identyfikują problemy, jakie mogą napotkać organy państwowe realizując przedsięwzięcia IT, wskazują, jak je rozwiązać, za pomocą jakich narzędzi i w jakim to powinno nastąpić czasie.

Suplementami do dokumentu „25 Point Implementation Plan…” są przewodniki i dobre praktyki stanowiące szczegółowe dyrektywy postępowania odnośnie konkretnych obszarów. Są one źródłem cennej wiedzy dotyczącej problemów napotykanych przez amerykańską administrację przy transformacji do modelu zwinnego. Informacji na temat czynników pozwalających uniknąć lub zaradzić ww. problemom dostarczają także raporty organizacji rządowych kontrolujących i analizujących postępy organów państwa w tym obszarze. Należą do nich: Software Development. Effective Practices and Federal Challenges in Applying Agile Methods z lipca 2012 r. oraz Information Technology. Agencies Need to Establish and Implement Incremental Development Policies z maja 2014 r. – przygotowane przez US Government Accountability Office (GAO). Zidentyfikowano w nich główne wyzwania w adaptowaniu agile w administracji publicznej. Wśród nich są problemy z: bliską współpracą z wykonawcami; przygotowaniem personelu do pracy w ramach krótkich iteracji i zgodnie ze zwinną mechaniką wytwarzania; nabyciem na czas odpowiednich narzędzi informatycznych wspierających obsługę zwinnych przedsięwzięć; nieelastycznymi przepisami i wytycznymi w obszarze amerykańskiego prawa zamówień publicznych; przyzwyczajeniami i mentalnością urzędników; oczekiwaniami organów kontroli niedostosowanymi do realiów zwinnego wytwarzania.

Z kolei, jako praktyki przydatne w transformacji ku zwinności wymieniono w nich m.in.: płynne, ewolucyjne i ostrożne przechodzenie do agile; obserwację i komunikację z innymi organizacjami działającymi zwinnie; gotowość na trudności i nastawienie na ich przezwyciężanie; zatrudnienie oraz przeszkolenie odpowiedniego personelu; przygotowanie środowisk OT oraz fizycznych lokalizacji do pracy w zwinnej mechanice; korzystanie z zasad i narzędzi już istniejących metodyk zwinnych i ich przewodników; zaangażowanie osób trzecich (obywateli) w prace nad przedsięwzięciami IT oraz branie pod uwagę otrzymanych od nich informacji zwrotnych; częste weryfikowanie i prezentowanie rezultatów dostarczanych w ramach projektu; przygotowanie elastycznych umów, dobrych praktyk i innych dokumentów pozwalających na Agile’owe zarządzanie projektami. Raporty te podkreślają także rolę, jaką odgrywało zaangażowanie i nacisk „góry” w administracji publicznej (która jest bardzo zhierarchizowana) na prowadzenie przedsięwzięć IT zwinnie.

W Europie na podobne kroki, choć w mniejszym zakresie, zdecydowano się w Norwegii. Powstały tam m.in. standardowe wzorce umów zwinnych przeznaczone do stosowania na rynku publicznym.

Zwinne projekty e-Government w Polsce?

Analiza opisanych zjawisk i przykładów prowadzi do konkluzji, że w Polsce spotykamy się z takimi samymi problemami, jak miało to miejsce na Zachodzie. Obserwujemy liczne niepowodzenia projektów IT realizowanych w tradycyjnym, kaskadowym podejściu i próby redukcji tego ryzyka, przez stosowanie agile. Metodyki zwinne są w Polsce nowością i ich stosowanie rodzi liczne wyzwania. Znajdujemy się jednak w o tyle lepszej sytuacji, że w przeciwieństwie do krajów zachodnich, możemy skorzystać z doświadczeń państw, w których już wcześniej zaimplementowano agile – na rynku prywatnym i publicznym. – i napotkano tam te same trudności i dylematy.

Rynek prywatny dostrzegł tę szansę i coraz śmielej korzysta z dobrodziejstw zwinności – choć napotyka pewne przeszkody. Znacznie gorzej sytuacja prezentuje się na rynku publicznym – na którym pokutuje niesłuszne przekonanie, że w reżimie prawa zamówień publicznych agile jest – mówiąc kolokwialnie – nierabialny. Tymczasem z punktu widzenia regulacyjnego – zarówno w sektorze prywatnym, jak i publicznym – korzystanie z agile jest możliwe. W publicu wymaga to więcej wysiłku niż na rynku prywatnym, ale cały czas jest możliwe. Z czego wynika ten wysiłek i jak uelastyczniać projekty IT realizowane w sektorze publicznym? O tym już za miesiąc w drugiej części cyklu.

Główne wyzwania w adaptowaniu agile w administracji publicznej:

• bliska współpraca z wykonawcami;

• przygotowanie personelu do pracy w ramach krótkich iteracji i zgodnie ze zwinną mechaniką wytwarzania;

• nabycie na czas odpowiednich narzędzi informatycznych wspierających obsługę zwinnych przedsięwzięć;

• nieelastyczne przepisy i wytyczne w obszarze amerykańskiego prawa zamówień publicznych;

• przyzwyczajenia i mentalność urzędników;

• oczekiwania organów kontroli niedostosowanymi do realiów zwinnego wytwarzania.

Źródło – administracja USA

Praktyki przydatne w transformacji ku zwinności:

• płynne, ewolucyjne i ostrożne przechodzenie do agile;

• obserwacja i komunikacja z innymi organizacjami działającymi zwinnie;

• gotowość na trudności i nastawienie na ich przezwyciężanie; zatrudnienie oraz przeszkolenie odpowiedniego personelu;

• przygotowanie środowisk OT oraz fizycznych lokalizacji do pracy w zwinnej mechanice;

• korzystanie z zasad i narzędzi już istniejących metodyk zwinnych i ich przewodników;

• zaangażowanie osób trzecich (obywateli) w prace nad przedsięwzięciami IT oraz branie pod uwagę otrzymanych od nich informacji zwrotnych;

• częste weryfikowanie i prezentowanie rezultatów dostarczanych w ramach projektu;

• przygotowanie elastycznych umów, dobrych praktyk i innych dokumentów pozwalających na agile’owe zarządzanie projektami.