W architekturze systemów i zarządzaniu projektami IT granica między wytrwałością a pułapką kosztów utopionych jest niezwykle cienka. Umiejętność strategicznej rezygnacji (ang. strategic quitting) nie jest przejawem słabości, lecz kluczowym narzędziem optymalizacji zasobów, które pozwala przekierować kapitał i czas tam, gdzie oczekiwana wartość (Expected Value – EV) jest najwyższa.
Metodologia Monkeys and Pedestals: Pułapka pozornego postępu
W laboratorium innowacji X (dawniej Google X), Astro Teller stosuje metaforę „małpy i postumentu” (ang. monkeys and pedestals), która jest fundamentalna dla zrozumienia efektywności w IT. Jeśli Twoim celem jest nauczenie małpy recytowania Szekspira na postumencie, większość zespołów instynktownie zaczyna od budowy postumentu, ponieważ jest to zadanie łatwe i daje iluzję postępu.
Z perspektywy architektonicznej, „budowanie postumentu” to inwestowanie w infrastrukturę, branding czy łatwe do zaimplementowania funkcjonalności, podczas gdy „trenowanie małpy” reprezentuje rozwiązanie najtrudniejszego problemu technicznego projektu. Jeśli nie potrafisz rozwiązać kluczowego wyzwania (małpy), cały zainwestowany czas w infrastrukturę (postument) jest zasobem zmarnowanym. Strategiczne podejście wymaga, aby najpierw zmierzyć się z krytycznymi ryzykami, co przyspiesza decyzję o ewentualnej rezygnacji i oszczędza budżet.
Mechanizmy błędu: Sunk Cost Fallacy i identity traps
Projekty technologiczne często wpadają w spiralę eskalacji zaangażowania (ang. escalation of commitment). Klasycznym przykładem błędu poznawczego jest traktowanie przeszłych inwestycji jako uzasadnienia dla dalszego finansowania nierentownych ścieżek. W IT objawia się to utrzymywaniem przestarzałych systemów (legacy) lub kontynuowaniem rozwoju produktów, które nie znajdują dopasowania rynkowego, tylko dlatego, że „wydaliśmy już na to miliony”.
Innym zagrożeniem jest pułapka tożsamości. Przykład firmy Sears pokazuje, jak kurczowe trzymanie się tożsamości „sprzedawcy detalicznego” doprowadziło do bankructwa, mimo posiadania dochodowych aktywów w innych sektorach. W IT podobny mechanizm widać, gdy organizacja odmawia adaptacji do nowych paradygmatów (np. cloud-native), ponieważ definiuje się poprzez specyficzny, posiadany stack technologiczny. Kontrastem jest firma Philips, która potrafiła sprzedać swój rdzenty biznes oświetleniowy, by stać się liderem technologii medycznych, kierując się przyszłą wartością, a nie historycznym sentymentem.
Kill Criteria: Architektura procesu decyzyjnego
Aby uniknąć reaktywnego podejmowania decyzji pod presją, niezbędne jest wdrożenie tzw. kill criteria – predefiniowanych warunków, po spełnieniu których projekt zostaje zamknięty. Kryteria te powinny składać się z mierzalnych stanów (states) i ram czasowych (dates), np. „zamykamy projekt, jeśli w ciągu 6 miesięcy nie osiągniemy 10-krotnego zwrotu z inwestycji”.
Stewart Butterfield, twórca Slacka, odniósł sukces dzięki strategicznej rezygnacji z projektu Glitch. Mimo posiadania 6 milionów dolarów kapitału i rosnącej bazy użytkowników, obliczył, że dalszy rozwój gry nie jest optymalny matematycznie. Przekierowanie zasobów na Slacka (początkowo narzędzie wewnętrzne) zamieniło porażkę w akwizycję o wartości 27,7 miliarda dolarów.
Wnioski praktyczne dla liderów IT
- Zdefiniuj Kill Criteria na starcie: Każdy projekt musi mieć jasno określone wskaźniki, które wymuszają jego zamknięcie. Zapobiega to wpływowi emocji na decyzje biznesowe.
- Najpierw trenuj małpę: Identyfikuj najtrudniejsze bariery technologiczne i rozwiązuj je w pierwszej kolejności, zamiast tracić budżet na infrastrukturę dla niepotwierdzonych koncepcji.
- Monitoruj EV zamiast kosztów: Decyzja o kontynuacji powinna opierać się na prawdopodobieństwie przyszłych zysków, a nie na wysokości już poniesionych nakładów (Sunk Cost Fallacy).
- Buduj systemy, nie cele: Zamiast skupiać się na sztywnym punkcie końcowym, wdrażaj systemy małych nawyków (metoda 1% Jamesa Cleara), które pozwalają na elastyczną korektę kursu w „dolinie rozczarowania”.
Dodaj komentarz