Co Teraz Zrobić? Planowanie Zmian w Projektowaniu Systemów

Bardzo często zdarza mi się rozmawiać z ludźmi na temat projektów systemów, planów i architektur. Wiele razy ta dyskusja zaczyna się za późno i projekty są już wdrożone lub częściowo wdrożone. Może to być bardzo frustrujące, jeśli realizowany projekt okazuje się nieodpowiedni dla danej sytuacji.

Rozumiem uczucie frustracji wynikające z takiej sytuacji, ale jest to coś, z czym w IT musimy mierzyć się bardzo regularnie — a konstruktywne zarządzanie tą reakcją jest kluczową umiejętnością w branży. Musimy stać się mistrzami tej sytuacji zarówno technicznie, jak i emocjonalnie. Nie powinniśmy być przez nią sparaliżowani — to naturalna sytuacja, z którą każdy specjalista IT będzie się regularnie spotykał. Nie powinna zniechęcać ani paraliżować, choć bardzo dobrze rozumiem, że można tak to odczuwać.

Jednym z kluczowych powodów, dla których tak często tego doświadczamy, jest to, że IT to ogromna dziedzina z wielką liczbą zmiennych do uwzględnienia w każdej sytuacji. To również bardzo kreatywna dziedzina, w której do każdego problemu może istnieć wiele realnych podejść. Rzadko kiedy istnieje nawet jedna jedyna „najlepsza" opcja. Zwykle mamy wiele konkurencyjnych możliwości. Czasem są one ze sobą bardzo zbliżone, a czasem drastycznie różne, co sprawia, że trudno je sensownie porównać.

Kolejnym kluczowym powodem jest to, że czynniki się zmieniają. Mogą pojawić się nowe techniki lub informacje, nowe produkty mogą trafić na rynek, istniejące produkty są aktualizowane, ceny się zmieniają lub zmieniają się potrzeby biznesowe — tuż przed lub nawet w trakcie procesu podejmowania decyzji i projektowania. Tego tempa zmian nie jesteśmy, jako specjaliści IT, w stanie kontrolować. Musimy to zaakceptować i radzić sobie z tym najlepiej jak potrafimy.

Inną rzeczą, którą często obserwuję, jest przeoczanie faktu, że rozwiązanie, które było idealne w momencie jego wyboru, może nie być idealne, gdyby ta sama decyzja była podejmowana dziś. Nie oznacza to w żadnym stopniu niedoskonałości pierwotnego projektu, a jednak widziałem wiele osób reagujących jakby tak właśnie było. Najczęstszy scenariusz, w którym obserwuję takie zachowanie, to awersja do stosowania RAID 5 we współczesnym projektowaniu storage'u — RAID 6 i RAID 10 są popularnymi alternatywami z dobrych powodów. Ale ta awersja do RAID 5, powszechna mniej więcej od 2009 roku, nie istniała zawsze — od połowy lat 90. do niemal końca lat 2000. RAID 5 nie tylko był realną opcją, ale bardzo często był najlepszym rozwiązaniem dla danych potrzeb biznesowych i technicznych (wzrost niechęci do niego był głównie stopniowy, a nie nagły). Jednak wiele osób postrzega RAID 5 jako słabą opcję dzisiaj i stosuje tę nową awersję do systemów zaprojektowanych i wdrożonych dawno temu — czasem blisko dwie dekady temu. To nie ma sensu i jest czysto emocjonalną reakcją. To, że RAID 5 był najlepszym wyborem w danym scenariuszu w 2002 roku, w żaden sposób nie oznacza, że nadal będzie najlepszym wyborem w 2015 roku. Ale też to, że RAID 5 jest złym wyborem w 2015 roku, w żaden sposób nie umniejsza faktu, że kilka lat temu był bardzo często świetnym wyborem.

Wiele razy byłem pytany, co zrobić, kiedy podjęto mniej niż idealne decyzje projektowe. „Co teraz zrobić?"

Nauka tego, co robić, gdy doskonałość nie jest już opcją (jakby kiedykolwiek naprawdę była — całe IT to kwestia kompromisów), jest bardzo ważną umiejętnością. Pierwszymi rzeczami, z którymi musimy się zmierzyć, są problemy emocjonalne, ponieważ będą one podważać wszystko inne. Musimy jak najlepiej cofnąć się, zaakceptować sytuację i działać racjonalnie. Ostatnią rzeczą, którą chcemy zrobić, to wziąć nieidealna sytuację i pogorszyć ją, próbując wstecznie uzasadniać złe decyzje lub wpadając w panikę.

Zaakceptowanie, że żaden projekt nie jest doskonały, że nie ma sposobu na zawsze zrobienie wszystkiego w pełni właściwie i że radzenie sobie z tym jest po prostu częścią pracy w IT — to jest pierwszy krok. Zrób krok w tył, zaczerpnij głęboko powietrza. Nie jest tak źle. To nie jest wyjątkowa sytuacja. Każdy specjalista IT zajmujący się projektowaniem przechodzi przez to przez cały czas. Powinieneś starać się podejmować jak najlepsze decyzje, ale musisz też zaakceptować, że rzadko można to osiągnąć — nikt nie ma dostępu do wystarczających zasobów, by naprawdę to zrobić. Pracujemy z tym, co mamy. No więc, jesteśmy tu gdzie jesteśmy. Co dalej?

Następnie należy ocenić sytuację. Gdzie jesteśmy teraz? W wielu przypadkach wdrożenie jest zakończone i nie ma nic więcej do zrobienia. Sytuacja nie jest idealna, ale czy jest zła? Bardzo często największym błędem, który widzę u osób stojących przed już wdrożonym projektem, jest to, że jest zbyt kosztowny — zazwyczaj „lepsze" rozwiązania nie są lepsze dlatego, że są szybsze lub bardziej niezawodne, ale dlatego, że są tańsze, łatwiejsze lub szybsze do wdrożenia. To niefortuna sytuacja, ale bynajmniej nie paraliżująca. Jakikolwiek czas lub pieniądze zostały wydane, musiały być akceptowalną kwotą w tamtym czasie i musiały być zatwierdzone. Najlepsze, co możemy teraz zrobić, to wyciągnąć wnioski z procesu decyzyjnego i starać się unikać przyszłego przepłacania. Nie oznacza to, że istniejące rozwiązanie nie będzie działać, a nawet nie będzie działać znakomicie. Po prostu mogło nie być to doskonały wybór biorąc pod uwagę potrzeby biznesowe, przede wszystkim finansowe.

Zdarzają się sytuacje, w których wdrożony projekt nie spełnia w wystarczającym stopniu określonych wymagań biznesowych. Na szczęście jest to rzadsze — w moim doświadczeniu — ponieważ jest to znacznie trudniejsza sytuacja. W takim przypadku musimy wprowadzić pewne modyfikacje, aby spełnić nasze potrzeby biznesowe. Może to okazać się kosztowne lub złożone. Ale rzeczy mogą nie być tak złe, jak się wydają. Reakcje na to często są mylące i sytuację można często uratować.

Pierwszym krokiem, gdy znaleźliśmy się w sytuacji, w której wdrożyliśmy rozwiązanie niespełniające potrzeb biznesowych, jest ponowna ocena tych potrzeb. Nie sugeruje to, że powinniśmy naciągać potrzeby, by dopasować je do tego, co nasz system jest w stanie spełnić — bynajmniej. Ale to dobry moment, by cofnąć się i sprawdzić, czy pierwotnie określone potrzeby są naprawdę słuszne, czy po prostu nie zostały wystarczająco dobrze zweryfikowane, albo — co jeszcze bardziej prawdopodobne — by sprawdzić, czy potrzeby biznesowe zmieniły się w czasie realizacji wdrożenia. Może się okazać, że wdrożone rozwiązanie faktycznie spełnia rzeczywiste potrzeby biznesowe, nawet jeśli zostały one pierwotnie błędnie określone lub ponieważ potrzeby zmieniły się z biegiem czasu. Albo może być tak, że potrzeby biznesowe zmieniły się tak dramatycznie, że nawet perfekcyjne planowanie pierwotnie nie sprostałoby obecnym potrzebom, a fakt, że wdrożone rozwiązanie nie działa zgodnie z oczekiwaniami, ma drugorzędne znaczenie. Byłem bardzo zaskoczony tym, jak często ta weryfikacja potrzeb biznesowych zamieniała rozwiązanie uznane za niewystarczające w rozwiązanie „zbyt rozbudowane", które faktycznie kosztowało więcej niż konieczne — po prostu dlatego, że nikt nie zakwestionował przesadzonych wymagań biznesowych ani nikt nie zapytał o wartość finansową określonych inwestycji technologicznych.

Drugim krokiem jest stworzenie nowego punktu odniesienia technologicznego. To bardzo ważny krok pomagający zapobiec wpadnięciu IT w pułapkę błędu utopionych kosztów (sunk cost fallacy). Bardzo powszechne jest to, że każdy — to nie jest nic wyjątkowego dla IT — patrzy na czas i pieniądze wydane na projekt i zakłada, że kontynuowanie pierwotnej ścieżki, bez względu na to, jak głupie to jest, jest właściwym kierunkiem, bo tak wiele zasobów już na tę ścieżkę wydano. Ale oczywiście to nie ma sensu — w jaki sposób dotarliśmy do obecnego stanu jest bez znaczenia. Istotne jest ocenienie bieżących potrzeb działu i firmy oraz wzięcie pod uwagę aktualnie dostępnych rozwiązań, technologii i zasobów. Biorąc pod uwagę obecny stan, można określić najlepszą ścieżkę naprzód. Jakiekolwiek rozważania dotyczące wysiłku włożonego w dotarcie do obecnego stanu są jedynie mylące.

Dobrym przykładem błędu utopionych kosztów jest gra w szachy. Przy każdym ruchu ważne jest, by ponownie ocenić wszystkie dostępne ruchy, ryzyka i strategie, ponieważ to, jakie ruchy zostały wykonane, by dotrzeć do obecnego stanu, nie ma żadnego znaczenia dla tego, jakie ruchy mają sens w przyszłości. Gdyby najlepszy szachista na świecie lub niesamowity algorytm szachowy oparty na komputerze został wprowadzony w środku gry, nie potrzebowałby żadnej wiedzy o tym, jak obecny stan zaistniał — po prostu oceniłby obecny stan i stworzyłby strategię opartą na nim.

Tak samo powinniśmy postępować w IT. Nasz obecny stan jest naszym obecnym stanem. Nie ma znaczenia dla planowania strategicznego, co się wydarzyło, by wprowadzić nas w ten stan. Interesują nas te decyzje i koszty tylko podczas procesu post-mortem, by ustalić, gdzie proces decyzyjny mógł zawieść, by wyciągnąć z tego wnioski. Uczenie się o sobie i naszych procesach jest bardzo ważne. Ale to bardzo różne zadanie od planowania strategicznego dla bieżącej inicjatywy.

Niestety, musimy rozpocząć nasze procesy planistyczne od nowa, ale tym razem zakładamy, że mamy więcej do dyspozycji. Ale tego nie można uniknąć. W najgorszych przypadkach budżety nie są już dostępne i nie ma zasobów, by naprawić wadliwy projekt i osiągnąć niezbędne cele biznesowe. Czasem konieczne są kompromisy. Radzenie sobie z tym, co mamy, jest czasem najlepszym, co możemy zrobić. Ale w zdecydowanej większości przypadków jakaś kombinacja dodatkowego budżetu lub kreatywnego ponownego wykorzystania istniejących produktów może być wystarczająca, by zaradzić sytuacji.

Kiedy osiągniemy stan, w którym zaradziliśmy naszym brakom — czy to po prostu akceptując, że przepłaciliśmy, nie dostarczyliśmy tego, co trzeba, czy też dostosowując się do potrzeb — mamy okazję, by wrócić i zbadać nasze procesy decyzyjne. To właśnie robiąc to, mamy nadzieję rosnąć jako jednostki i — jeśli to w ogóle możliwe — na poziomie organizacyjnym uczyć się na błędach lub ustalić, czy w ogóle były błędy. Każda firma i każda osoba popełnia błędy. To, co nas wyróżnia, to zdolność do uczenia się na nich i unikania tych samych błędów w przyszłości. Wzrost pochodzi głównie z doświadczenia bólu w ten sposób i choć często trudno to znosić, właśnie tu mamy najlepszą okazję, by stworzyć prawdziwą, trwałą wartość. Nie odkładaj ani nie pomijaj tej okazji do przeglądu — czy to surowy, osobisty przegląd, który robisz sam, czy formalny, organizacyjny przegląd prowadzony przez osoby przeszkolone do tego celu, czy coś pomiędzy. Im szybciej procesy decyzyjne zostaną ocenione, tym świeższe będzie wspomnienie i tym szybciej korekta kursu zacznie obowiązywać.

Ostatnim krokiem, który możemy podjąć, jest jak najszybsze rozpoczęcie procesu decyzyjnego dotyczącego zaprojektowania zamiennika dla bieżącego wdrożenia, po zakończeniu przeglądu procesu decyzyjnego. Niekoniecznie oznacza to, że powinniśmy planować wydawanie pieniędzy lub zmianę projektów w najbliższej przyszłości. Bynajmniej. Ale będąc niezwykle proaktywnymi w podejmowaniu decyzji projektowych, możemy próbować unikać problemów z przeszłości, dając sobie więcej czasu na planowanie, więcej czasu na zbieranie i dokumentowanie wymagań, lepszy wgląd w zmiany wymagań w czasie przez regularne powracanie do tych wymagań, by sprawdzić, czy pozostają stabilne czy się zmieniają, więcej okazji do uzyskania zaangażowania i inwestycji zarządu i współpracowników w decyzję, oraz lepsze rozumienie domeny problemu, dzięki czemu jesteśmy lepiej przygotowani do modyfikacji zamierzonego projektu lub wiemy, kiedy go porzucić i zacząć od nowa przed jego kolejnym wdrożeniem. Mogłoby to też, potencjalnie, dać nam lepszą szansę na skodyfikowanie wiedzy organizacyjnej, którą można byłoby przekazać następcy, gdybyś sam nie był w pozycji decydenta lub wykonawcy, gdy nadejdzie kolejny cykl.

Dzięki dobrym, racjonalnym procesom i dobremu zrozumieniu kroków, które należy podjąć w przypadku mniej niż idealnego projektu lub wdrożenia systemu, możemy odzyskać sprawność po potknięciach i nie tylko — w większości przypadków — wyjść z nich w krótkim terminie, ale możemy też zabezpieczyć organizację przed tymi samymi błędami w przyszłości.