• Różne

    Szkolenia online z perspektywy

    Dwa tygodnie temu poprowadziłem pierwsze szkolenie stacjonarne od początku marca 2020, a więc od pół roku (było to szkolenie PSPO Advanced). Przez ten czas zdążyłem jednak poprowadzić wiele szkoleń online. Bycie na sali było więc poniekąd zapomnianym doświadczeniem, powrót do którego przyniósł nieuchronne porównywanie tego ze szkoleniem online. Poniżej dzielę się tymi moimi osobistymi spostrzeżeniami i wrażeniami.

    Już przygotowując salę i materiały do szkolenia (wieczorem przed pierwszym dniem) – rzecz, którą przez ostatnią dekadę robiłem dziesiątki razy – miałem poczucie bezsensu i cofnięcia się. Bite dwie godziny przygotowywania różnych papierów: wieszania na ścianach plakatów, zasłaniania części z nich (by móc je potem w odpowiednim momencie ćwiczenia odkryć), następnie sortowania i układania materiałów opisujących studium przypadku (które potem uczestnicy otrzymywali stopniowo w trakcie), by upewnić się, że są wszystkie i we właściwej kolejności. Następnie sprawdzenie kart do gier (podczas szkolenia uczestnicy układają różne pojęcia lub otrzymują „karty inspiracji” – i tak dalej) i również odpowiednie ich przygotowanie. A na koniec rozłożenie na stołach materiałów indywidualnych – wydruk slajdów + miejsce na notatki w naszych eleganckich segregatorach – oraz oczywiście karteczek post-it, pisaków itp. itd. Całe sterty papieru. Papieru, który jest tam tylko dlatego, że nie ma jak inaczej przekazać tego wszystkiego uczestnikom; co gorsza papieru, którego większość skończyła w koszu dwa dni później.

    Poczucie bezsensu miałem, bo w głowie miałem świeże doświadczenie jak rzecz wygląda na szkoleniu online. Również trzeba przygotować materiały – a więc współdzielone dokumenty, czasem tablice wirtualne i jakieś wspomagające narzędzia. Wszystko to jednak jest od razu gotowe, nie trzeba rozkładać, sortować, kleić na ścianach i tak dalej. Nie może się też nic pogubić ani ułożyć w złej kolejności. Można więc ten czas przed szkoleniem poświęcić na to by, na przykład, zastanowić się co poprawić, co tym razem zrobić inaczej, lepiej. Mój czas jako trenera jest dużo lepiej wykorzystany – a dodatkowo nie powstają żadne odpady.

    Przez pierwszy dzień szkolenia zastanawiałem się, czy ten cały wysiłek ma w ogóle jakiś sens, ale nie odkryłem ani jednej korzyści z tego, że materiały miały fizyczną, papierową postać.

    Wręcz przeciwnie: pojawił się ponownie problem „brakujących slajdów”. Szykując materiały szkoleniowe do wydruku, zawsze pomija się pewne slajdy – na przykład takie, które zdradzają rozwiązania zagadek albo sugerują dalszy rozwój ćwiczeń – lub po prostu po to, żeby móc w ogóle uczestników czymś zaskoczyć. Oczywiście potem mają oni poczucie, że coś stracili, jeśli tych slajdów nie mają w leżącymi przed nimi wydruku – rodzi się zupełnie niepotrzebna frustracja. W szkoleniu online, gdzie nie ma żadnych papierowych artefaktów, problem w ogóle z natury rzeczy nie występuje, szkolenie toczy się naturalnie i wszyscy widzą to, co widzą, i co widzieć powinni wtedy, kiedy powinni. Jeśli potem proszą o PDF ze slajdami to nie z frustracji, ale po to pewnie, by móc coś, co ich zaciekawiło pokazać innym – albo z nawyku.

    Przy okazji zawsze zastanawiałem się jaka jest w ogóle wartość drukowania materiałów szkoleniowych. To taka tradycja, że na przyzwoitym szkoleniu stacjonarnym trzeba dostać coś drukowanego. Każdy z nas, kto pracuje dłużej niż dekadę, ma pewnie gdzieś – w domu albo w biurze – małą stertę takich materiałów, zbindowanych albo w segregatorkach, okraszonych naszymi notatkami i rysuneczkami. Ciekaw jestem jak często zdarza się Wam do nich wrócić – a jeśli już w ogóle się zdarzyło, to do jakiej części z nich? Bo mi się to prawie nie zdarza. A najważniejszym tego powodem jest fakt, że nie mogę ich przeszukać szybko i sprawnie. Dlatego już od kilku lat, kiedy jestem na szkoleniu jako uczestnik notuję na komputerze (parę lat temu nawet kupiłem specjalnie tableto-notebook by móc to robić efektywnie) – i te notatki niejednokrotnie zdarzyło mi się czytać, korzystać z nich. Czemu? Bo są w OneNote – a więc zawsze pod ręką – i łatwo mogę je znaleźć (wpisuję o co mi chodzi w pole „Search” – i voila, mam moje notatki).

    Ale na tym nie koniec. Na szkoleniu stacjonarnym część notatek powstaje jako wspólna praca zespołów, której efekty umieszczane są oczywiście na flipach albo na karteczkach lepionych po całej sali. Do tego dochodzą rysuneczki tworzone przez trenera przy okazji tłumaczenia tego czy owego zagadnienia. Żadnej z tych rzeczy uczestnicy nie mogą zabrać z sobą (i potem kończą one w śmietniku), więc wszyscy robią zdjęcia telefonami. Nie wiem czy później z tych zdjęć się korzysta czy też trafiają one na wirtualną stertę podobnie jak fizyczne segregatorki ze szkoleń? Bo problemem może być odgadnięcie czego dotyczy kolekcja kolorowych karteczek zabazgranych różnymi charakterami pisma, którym zdjęcie cyknąłeś rok temu.

    A jak to wygląda na szkoleniu online (przynajmniej u nas)? Każda grupa współpracuje na współdzielonym dokumencie, do którego wszyscy mają dostęp. Niemal wszystko, co normalnie ląduje na ścianie w formie flipów i post-itów, trafia tam. Tyle, że jest tam w kontekście konkretnego ćwiczenia czy zagadnienia, który jest w tymże dokumencie opisany, więc wiadomo o co chodzi. I jest w formie tekstu. Jest więc to zrozumiałe, łatwo wyszukiwalne i dostępne. Jeśli poza dokumentem używamy jakichś wirtualnych tablic, to na nich też po kartkach pisze się tekstem. Jeśli jako trener rysuję (czasem to robię, choć żaden ze mnie artysta), robię to oczywiście na wirtualnej tablicy. Później do wszystkiego tego uczestnicy zachowują dostęp „na zawsze” (w każdym razie u nas), czyli mogą sobie to skopiować albo wracać do tego, kiedy tylko zechcą.

    Inna obserwacja: na szkoleniach typową formą pracy jest dyskusja lub ćwiczenie w podgrupach (zespołach), a potem omówienie wyników cała grupą. Koncept jest ogólnie dobry, ale na szkoleniu stacjonarnym jest mały problem. Gdy grupy wkręcą się w dyskusję (co jest ogólnie dobre) samo doprowadzenie do tego, żeby wszyscy się uciszyli i można było kontynuować wymaga kilku minut sygnalizowania na różne sposoby, że czas minął. Tylko potem te „kilka minut” się sumuje i zjada czas, w efekcie czego jest ryzyko, że z agendy wypada jakaś część przewidzianego materiału. Można oczywiście uciszać i sygnalizować bardziej „agresywnie”. Wtedy jest szybciej, ale uczestnikom jest nieprzyjemnie o czym od razu mówią (mają poczucie, że prowadzący traktuje ich „z buta”).

    Kiedyś przyjmowałem to jako swego rodzaju zło konieczne, coś, co trzeba po prostu zaakceptować. Teraz patrzę już na to inaczej, bo wiem już jak się to robi online. Używamy do tego tzw. breakout-rooms, które na platformie Zoom mają niezwykle cenną cechę: same się zamykają po upłynięciu wcześniej ustawionego czasu (tzw. timebox). Problemu z przeciągającą się pracą w grupach po prostu nie ma. Zasadniczo ułatwia to trzymanie się czasu na szkoleniu, a co za tym idzie, sprawne przerobienie materiału. Mocno za tym zatęskniłem na sali.

    Co więcej, na szkoleniu online nie ma w ogóle „pobocznych dyskusji” – czyli sytuacji, kiedy dwie-trzy osoby gdzieś o czymś zawzięcie debatując przeszkadzają grupie – i trenerowi – w pójściu dalej z zajęciami. Na sali to norma. I zwykle dyskutujący są tak zaangażowani, że trzeba po prostu poczekać w ciszy aż skończą, albo zapytać o czym rozmawiają, żeby przerwali. To nie jest ich zła wola ani znudzenie zajęciami – przeciwnie, to najczęściej wyraz zaangażowania. Ale to kolejny „poślizg”, czas dla pozostałych zmarnowany.

    Szkoleń online od początku nie prowadziliśmy w Code Sprinters w blokach 8 godzinnych. Od razu wiedzieliśmy, że byłoby to zbyt męczące dla uczestników, obniżając ich zdolność do przyswojenia naszych szkoleń, których program jest mocno „napakowany”. Dlatego nasze szkolenia online od początku trwały 3-4 dni po 3.5-4.5h dziennie. Uczestnicy chwalą sobie, że dzięki temu nie mają typowego dla szkoleń popołudniowego „doła energetycznego”. Mogą także lepiej wykorzystać swój dzień – o tych zaletach już pisałem.

    Szkoląc stacjonarnie przez dwa pełne dni mogłem zaobserwować, że znużenie i zmęczenie, pojawiające się najpóźniej około 14-ej nie jest wyłącznie domeną szkoleń online. Przeciwnie, na sali jest ono nawet silniejsze, bo zwykle jest to czas po obiedzie – a więc dodatkowo organizm wielu osób krzyczy wręcz o typową poobiednią drzemkę. A tu nie ma mowy o tym (choć niektórzy przysypiają), bo jeszcze kolejne 3-4 godziny szkolenia przed nami. Więc wypija się kawę litrami (porada: lepiej pić wodę niż kawę) i je szkoleniowe ciastka, żeby podnieść sobie poziom cukru – co pomaga, ale tylko na chwilę. W sumie więc wszyscy się męczą – druga połowa dnia jest zawsze trudniejsza, mniej efektywna, o czym mówią też uczestnicy.

    Sęk w tym, że na szkoleniu stacjonarnym nie da się tego problemu rozwiązać. Nikt nie przyjedzie na cztery „połówki dni” – raz, że musiałoby go nie być 4 dni w pracy, dwa: to zwiększone koszty dla przyjeżdżających z innych miejscowości o kolejne noclegi, a dla trenera o dni wynajmu sali. Pozostaje się przemęczyć.

    I jeszcze jeden delikatny problem. Czasem widać, że ktoś z uczestników ma jakiś kłopot. Nie zgadza się z czymś albo nie rozumie albo jest mocno zamyślony. Jako dla prowadzącego jest to dla mnie sygnał, że z tym kimś trzeba porozmawiać, ustalić co się dzieje. Na szkoleniu stacjonarnym problem jest jak to zrobić dyskretnie, tak, żeby mieć szansę porozmawiać jeden na jeden. Jedyną metodą jest próba „wyłowienia” delikwenta na przerwie, w chwili, kiedy jest sam nad kawą – co nie zawsze się udaje.

    Co ciekawe, ten problem, ale w drugą stronę zgłaszali mi też uczestnicy: czasem z różnych powodów krępują się zadać prowadzącemu pytanie kiedy inni uczestnicy są w pobliżu. I również wtedy „łowią” prowadzącego na przerwach albo po szkoleniu.

    W formacie online oczywiście problem nie występuje. Rzecz można zrobić natychmiast korzystając z czatu „jeden na jeden”, w razie potrzeby umówić się na dodatkowe e-spotkanie (korzystając z tego, że dzień szkoleniowy jest krótszy).

    Czy przez te dwa dni nie było ani jednego momentu, który byłby lepszy niż na szkoleniu online? Owszem, były. Dwa.

    Pierwszy, to spontanicznie zorganizowane przez uczestników piwo pierwszego dnia po szkoleniu. Było to fajne i ciekawe towarzysko, zwłaszcza, że w grupie były dwie osoby, które już znałem z wcześniejszej współpracy a dawno nie miałem okazji ich spotkać. Problem w tym czy można to faktycznie podciągnąć pod szkolenie per se?

    Drugi, to kiedy na koniec drugiego dnia uczestnicy w ramach scenki praktykowali rozmowę z różnymi typami osobowości (w ramach tematu pracy z interesariuszami) – na tą chwilę wydaje mi się, że zorganizowanie tego na szkoleniu online byłoby mniej skuteczne. Ale niedługo spróbuję i może się okazać, że jednak i tu online pozytywnie mnie zaskoczy. Niemniej, wartość tego jednego ćwiczenia nie uzasadnia w mojej ocenie wysiłku, jakim jest podróż do innego miasta na szkolenie.

    Podsumowując, po tych dwóch dniach znów spędzonych na sali poczułem się jako trener jak ktoś, komu kazano się z samochodu przesiąść do furmanki – cofnięcie w czasie do starych, gorszych rozwiązań. Z perspektywy pół roku prowadzenia szkoleń online szkolenie stacjonarne to dla mnie po prostu szkolenie mniej efektywne.

    Główne punkty:

    • Trudność w przygotowaniu materiałów i ich niższa jakość (papier).
    • Trudniejsze „zabranie” notatek i materiałów ze sobą przez uczestników.
    • Mniejsza dyscyplina na szkoleniu, w efekcie większe ryzyko poślizgu i „wypadania” materiału do przerobienia z braku czasu.
    • Większe zmęczenie w formacie całodniowym a co za tym idzie mniej efektywne uczenie się.
    • Dodatkowe niepotrzebne wyjazdy do innego miasta, noclegi itp. itd.
    • Ogromne marnotrawstwo papieru.

    Dlatego postanowiłem, że szkolenie PSM-II, które poprowadziłem w zeszłym tygodniu było ostatnim szkoleniem stacjonarnym, które osobiście prowadzę; na pewno ostatnim w 2020, a może i w ogóle ostatnim.

  • Różne,  Zarządzanie,  Życie i inne refleksje

    O depresji przedsiębiorcy

    To jak widzimy świat, co jest dla nas ważne – jaki jest nasz świat – jest w dużym stopniu kształtowane przez media. Dzięki rozwojowi techniki są one w stanie jeszcze intensywniej i silniej niż kiedykolwiek przedstawiać historie i doświadczenia cudze albo całkowicie zmyślone z taką siłą, że stają się one nasze własne – wrastają w nasz „filtr” postrzegania świata.

    W mediach poświęconych tematyce biznesowej dużo uwagi poświęca się startupom. Startupy to są firmy, które mają nowy, rewelacyjny i rewolucyjny pomysł na usługę lub produkt, taki, który zasadniczo wywróci rynek lub wręcz stworzy zupełnie nowy. Wzorcem dla ludzi, którze je tworzą – oraz wielu, którzy się temu tylko przyglądają – są oczywiście te startupy, którym się udało i które obecnie są wielkimi firmami – a ich założyciele nieprzyzwoicie bogatymi ludźmi. Wielu z nich funkcjonuje wręcz jako swego rodzaju „święci” tej specyficznej odmiany wiary w sukces, ikony i idole do naśladowania – Steve Jobs (Apple), Bill Gates (Microsoft), Larry Ellison (Oracle), trzej założyciele Google, Mark Zuckerberg (Facebook) a ostatnio Elon Musk (Tesla, Space-X). Jest jeszcze wielu innych znanych tylko w swojej produktowej niszy albo na lokalnym, krajowym rynku. Właściwie każdy założyciel startupa, który się w miarę rozwinął może zakosztować odrobiny sławy i uznania, bo to ich sukcesy są wzorem a oni sami wzorcem do naśladowania. Ogląda się wywiady z nimi, studiuje ich działania, sposób życia i dietę w nadziei, że może uda się powtórzyć ich sukces.

    Wszystko to jest piękne i pouczające, ma jednak jedną paskudną wadę. I nie chodzi mi o powszechnie znany fakt, że przytłaczająca większość startupów kończy się kompletną klapą (albo pomysł albo wykonanie albo jedno i drugie nie było tak rewolucyjne i rewelacyjne jak się wydawało), bo z tym się liczy nawet większość założycieli startupów. Ani nawet o to, że wielu z nich swój sukces zawdzięcza nie tylko świetnemu pomysłowi i szczęściu, ale także koneksjom dzięki którym mogli dotrzeć do ludzi, z którymi przeciętny Kowalski nie ma szans porozmawiać. Nie, mam na myśli ten przykry fakt, że patrząc przez ten właśnie filtr normalny, dobrze prowadzony biznes, który rośnie o te 10-15% rok do roku wydaje się być kompletną porażką a prowadzący go życiowymi nieudacznikami przy wspomnianych wyżej ikonach sukcesu i ich wynikach. Niestety wielu przedsiębiorców wpędza to w depresję, która jako żywo przypomina mi depresję wielu kobiet, które będąc całkiem ładnymi dołują się porównując się z podrasowanymi w Photoshopie zdjęciami modelek.

    Dużo ważniejsze niż samopoczucie tych przedsiębiorców jest jednak to, że gospodarka opiera się właśnie na takich normalnych, przeciętnych firmach a nie na super-startupach. To właśnie one dostarczają większości usług i towarów, z których korzystamy i wypracowują większość narodowego bogactwa. Dlatego wydaje mi się, że powinniśmy je bardziej doceniać. I sami przedsiębiorcy powinni siebie i swoje firmy także bardziej docenić. Dobrze prowadzony biznes, który notuje systematyczne wzrosty, ma zadowolonych klientów, dobre produkty, jest dobrze zarządzany i solidnie rozwijany to duży sukces, który nie wszystkim udaje się osiągnąć.

  • Agile,  Różne,  Zarządzanie

    Jak dobrze budować systemy rządowe?

    Właśnie w ostatni weekend kolejny raz wyszły na jaw istotne niedociągnięcia w ważnym państwowym systemie informatycznym – okazało się, że system ePUAP (platforma przez którą obywatele mogą załatwić elektronicznie sprawy urzędowe) nie posiadał możliwości automatycznego przejęcia obsługi przez serwery zapasowe w razie awarii serwerów podstawowych. Wymagało to ręcznej pracy administratorów i w konsekwencji zajęło cały dzień jak ujawniła Minister Cyfryzacji.

    Więcej o sprawie można przeczytać na blogu Niebezpiecznik.pl. Czytając tą relację warto zwrócić uwagę na dwie rzeczy.

    Po pierwsze audyt tegoż systemu zamówiony przez nową Minister Cyfryzacji (którego fragmenty publikuje Niebezpiecznik.pl) koncentruje się na dokumentacji. Rzecz typowa dla audytorów, którzy najczęściej pochylają się właśnie nad szeroko rozumianymi „kwitami” co nie zawsze pokazuje meritum sprawy. Tak jest i w tym przypadku, bowiem jeśli jakiekolwiek działania naprawcze wymagają wykonania skomplikowanych kroków opisanych w rozlicznych dokumentach to można spokojnie przyjąć, że nawet jeśli owe dokumenty istnieją i opisują te kroki prawidłowo – to i tak będą praktycznie bezużyteczne. Zamiast mnożyć dokumenty należy maksymalnie uprościć wszelkie działania (w czym pomaga jak najdalej idąca ich automatyzacja) a następnie ćwiczyć je w warunkach możliwie zbliżonych do produkcyjnych – lub wręcz na środowisku produkcyjnym (por. Google DiRT). Chodzi o to, by kiedy dzieje się coś złego admini od razu wiedzieli co robić – i umieli to robić niemal z zamkniętymi oczami – a nie przystępowali do wertowania dokumentacji.

    Po drugie na pochwałę zasługuje otwartość z jaką Minister Cyfryzacji Anna Streżyńska poinformowała o sytuacji jak i stanie systemu ePUAP (musi on być opłakany, skoro ponoć gdyby nie konieczność zwrotu środków UE uzyskanych na jego budowę najlepiej byłoby go w/g słów pani minister „zaorać”). Jest to w ogóle jedna z tych postaci w nowym gabinecie, która cieszy się szacunkiem środowiska niezależnie od politycznych przekonań, co może cieszyć.

    Są to jednak dwie uwagi poboczne wobec meritum problemu, nad którym chcę się pochylić a mianowicie czemu właściwie systemy rządowe są najczęściej drogie i marne. Jak wspomniałem nie jest to przecież pierwsza wpadka tego rodzaju – że tylko wspomnę o systemie (dużo przecież prostszym) który miał policzyć głosy w wyborach samorządowych a po prostu nie działał. I nie jest to wyłącznie domena Polski.

    Moim zdaniem głównym źródłem problemu jest sama metoda tworzenia takich systemów. Zły jest bowiem nie tylko sposób ich zamawiania na rynku – zaszyty niestety „na sztywno” w ustawie o zamówieniach publicznych – błędne jest samo założenie, że państwo ważne systemy powinno w ogóle zamawiać od firm jako produkty lub w modelu projektowym.

    Przeanalizujmy najpierw obie te rzeczy po kolei a następnie spójrzmy na to jak powinno to wyglądać.

    Obecny obyczaj jest taki, że jak państwo potrzebuje jakiegoś systemu to zamawia go „pod klucz” na rynku rozpisując w tym celu przetarg. Najważniejszym problemem tych przetargów jest nawet nie to, że głównym kryterium jest najniższa cena (co nieuchronnie prowadzi do zaniżania oszacowań w dół a następnie patologii podczas realizacji, których symbolem w folklorze Agile jest tzw. „wiewiórkoburger”), ale sam fakt, że przetargi te są uosobieniem modelu kaskadowego (i jedną z jego ostatnich ostoi). W modelu tym zakłada się, że całość systemu ma zostać wyspecyfikowana z góry a następnie dostarczona w całości w jednym momencie – lub co najwyżej w kilku dużych etapach. Prowadzi to nieuchronnie nie tylko do budowania funkcji zbędnych ale i pominięcia funkcji potrzebnych, na które albo nie wpadli twórcy specyfikacji albo też potrzeba których ujawniła się dopiero z czasem. Innymi słowy, model taki gwarantuje, że funkcje systemu będą nieadekwatne i niewystarczające.

    A to tylko początek, czubek góry lodowej problemów z tym modelem. Czytelników mojego bloga nie będę zanudzać szerszym wykładem dlaczego model kaskadowy jest nieadekwatny dla budowy skomplikowanych systemów informatycznych – dość się o tym mówi i pisze od lat. Dość podsumować, że mamy tu zły proces, co gorsza mocno umocowany w prawie.

    Jakie powinno być zatem właściwie podejście do budowy takiego systemu? Oczywiście zwinne – a więc powinno się ustalić bieżącą listę najważniejszych wymagań wobec systemu, która nie musi być kompletna ale wystarczyć na 2-3 miesiące pracy. Następnie zespoły (początkowo zapewne jeden) powinny przystąpić do budowy systemu w krótkich, 2-3 tygodniowych iteracjach, wydając po każdej z nich kompletny, technicznie gotowy system na serwery produkcyjne. Po osiągnięciu jakiejś bazowej funkcjonalności efekt każdej takiej iteracji powinien być dostępny dla użytkowników (w przypadku ePUAP i innych systemów tego typu oznacza to także ogół obywateli) a używanie dostępnych funkcji powinno być mierzone i analizowane. Użytkownikom należy nadto udostępnić metodę łatwego zgłaszania pomysłów i potrzeb. Prowadzący rozwój systemu wybierałby na tej podstawie rzeczy najważniejsze do realizacji w kolejnej iteracji – i w ten sposób system non-stop poszerzałby swoje możliwości – ale zawsze o rzeczy w danej chwili najbardziej potrzebne. Zasadniczo zredukowałoby to zarówno marnotrawstwo jak i szanse pominięcia jakiejś istotnej dla dużej grupy użytkowników funkcji.

    Znowuż, dla osób zaznajomionych z nowoczesnymi metodami zarządzania rozwojem oprogramowania są to rzeczy do znudzenia wręcz oczywiste (jeśli dla kogoś stanowią nowość najwyższy już naprawdę czas zaktualizować swoją wiedzę w tym zakresie – na dobry początek proponuję moją książkę – podręcznik metod z rodziny Agile). Niestety, jak już napisałem w administracji państwowej brak nie tylko wiedzy i świadomości (jakże często decyzje o zakupie systemów podejmują ludzie, którzy nie rozumieją zasadniczych różnic pomiędzy prowadzeniem inwestycji w system informatyczny w stosunku do np. w budowy szpitala) – prawo wręcz zasadniczo utrudnia urzędnikom pracę w ten sposób.

    Wszelako jak już zasygnalizowałem powyżej problem tkwi jeszcze głębiej – w samym założeniu, że system tego rodzaju w ogóle musi być zamawiany jako produkt od firmy a nie po prostu organicznie rozwijany przez odpowiedzialną za niego instytucję. Tymczasem to właśnie – rozwijanie go przez ludzi bezpośrednio zatrudnionych przez np. Ministerstwo Cyfryzacji – byłoby absolutnie najlepsze pod każdym względem. Po pierwsze dlatego, że wówczas nic nie stałoby na przeszkodzie by zastosować metody zwinne usuwając wszystkie problemy jakie generuje model kaskadowy. Po drugie dlatego, że wówczas system budowałoby grono informatyków związanych z nim od samego początku – a jak pokazuje doświadczenie dużo łatwiej o zaangażowanie w produkt takiego zespołu niż pracowników firmy będącej dostawcą (albo – najpewniej – poddostawcą dostawcy). Co więcej, nie groziłaby wówczas ani utrata wiedzy o systemie ani możliwości jego stałego rozwoju – a takie ryzyko zawsze wiąże się z ew. upadkiem lub rozwiązaniem się firmy-dostawcy. Po trzecie, tak byłoby taniej gdyż nie trzeba  by było płacić niezbędnej marży dostawcy – co mogłoby się albo przełożyć na oszczędności albo umożliwić pozyskanie do zespołów lepszych specjalistów przez zaoferowanie wyższych zarobków.

    Sztandarowym projektem, który dobitnie pokazuje przewagę opisanego podejścia nad przetargami na realizację w/g specyfikacji jest projekt FBI Sentinel. Był to projekt budowy centralnego systemu informacji o sprawach, osobach itp. dla agentów FBI. W dużym skrócie po upadku wcześniejszego projektu (system nie działał) wartego miliony i 4 latach trwania kolejnego, w czasie którego Lokheed Martin zdążył spalić kolejne miliony nie dostarczając nic działającego system skończono po prostu ekipami programistów pracującymi w krótkich sprintach (chyba nawet w Scrumie)… w budynku FBI w Waszyngrtonie. Więcej o tym można poczytać tu, tu i tu.

    Może się jednak okazać, że brakuje funduszy na zatrudnienie zespołu (przyczynek do szerszej refleksji nad sensownością wydawania pieniędzy przez rząd, który jest w stanie wykładać pieniądze na zupełnie bezsensowne rzeczy ale nie miałby ich na pensje dla grupy fachowców zdolnych zbudować i utrzymać kluczowy dla państwa system? Co najmniej bez sensu). Istnieje wtedy jeszcze jeden sposób na zbudowanie takiego systemu, który byłby skuteczny i zapewniał wysoką jakość rozwiązania: projekt open source. Ministerstwo musiałoby zatrudnić tylko kilku kluczowych developerów, którzy położyliby podwaliny pod system (napisali jego wstępny zrąb) oraz dbaliby o jakość kodu (poprzez głównie akceptowanie lub nie kodu innych ludzi). Następnie należy odwołać się do społeczności informatycznej w Polsce o wsparcie projektu nie finansowo ale wprost kodem. Jestem pewien, że niezależnie od polityki i tego kto aktualnie jest u władzy jest dość zaangażowanych informatyków, by projekt żwawo posuwał się do przodu. Mielibyśmy wówczas społecznie rozwijany system rządowy w modelu open source – coś, co miałoby szansę być ewenementem na skalę światową.

    Pojawić się mogą zarzuty, że taki system nie byłby bezpieczny. Trudno się z nimi zgodzić – to właśnie podejście „security through obscurity” czyli bezpieczne, bo nikt nie wie jak to działa było historycznie źródłem największej liczby dziur w bezpieczeństwie. Dobry system oparty o kryptografię powinien oprzeć się atakom pomimo znajomości jego mechanizmów działania pod warunkiem zadbania o klucze kryptograficzne, które przecież nie stanowią części źródeł systemu. Co więcej, fakt weryfikacji mechanizmów przez wielu uczestników projektu powinien zapewnić wykrycie większej liczby potencjalnie zagrażających bezpieczeństwu błędów.

    Małe szanse, że mój artykuł dotrze do Pani Minister ale gdyby tak się stało: proszę poważnie rozważyć po pierwsze zastosowanie organicznego rozwoju oprogramowania rządowego przez zatrudnionych wprost przez rząd informatyków a w razie gdyby to nie było możliwe odwołanie się do modelu open source i wsparcia społeczności. Wyjdzie na tym i Ministerstwo i my wszyscy dużo lepiej niż na rozpisaniu kolejnego przetargu na kolejny projekt.