Wdrożenie systemu B2B to nie jest tylko kwestia technologii. W praktyce jest to złożony projekt, w którym technologia okazuje się łatwiejszym elementem do opanowania niż ludzkie przekonania, procesy decyzyjne i wzajemne oczekiwania stron. W tym artykule opisujemy cztery obszary, które najczęściej decydują o powodzeniu lub porażce projektu, oraz nasze podejście do minimalizowania ryzyka.
Spis treści
- Dane o skuteczności projektów oprogramowania
- Doświadczenie: gdy obie strony mówią innym językiem
- Edukacja: metodyki, które nie rozwiązują wszystkiego
- Specyfikacja: jak nie pisać dokumentacji, która się dezaktualizuje
- Komunikacja: najczęstsze punkty zapalne w projekcie
- SOHO.Concept: odpowiedź na systemowe problemy branży
- FAQ
Kluczowe wnioski
| Punkt | Szczegóły |
|---|---|
| Skuteczność wdrożeń | Według Chaos Report 2015 (Standish Group) mniej niż 40% projektów software’owych kończy się sukcesem – przy rosnącej złożoności wskaźnik spada do 19% dla metodyk zwinnych i 3% dla modelu kaskadowego |
| Doświadczenie | Luka doświadczeń między firmami tradycyjnymi a dostawcami IT to jeden z głównych powodów niepowodzeń – partnerskie podejście łączące wiedzę obu stron zwiększa szansę na sukces |
| Specyfikacja | Wspólny słownik i specyfikowanie minimalnego zakresu (MLP/MVP) są skuteczniejsze niż wielomiesięczna dokumentacja, która i tak nie przewidzi wszystkich problemów |
| Komunikacja | Najczęstsze patologie to ponowne rozpatrywanie podjętych decyzji, rozmywanie odpowiedzialności i zmiany zakresu w trakcie realizacji etapu |
| SOHO.Concept | Hybrydowy model łączący przewidywalność waterfall z elastycznością agile – system uruchamiany jest w kilka tygodni i od startu spełnia 90–95% potrzeb klienta |
Dane o skuteczności projektów oprogramowania
Wytwarzanie oprogramowania to nieodłączny element rozwoju każdej nowoczesnej organizacji. Wdrożenie i dostosowanie systemów realizujących kolejne cele biznesowe to duża szansa, ale też poważne wyzwanie dla wszystkich uczestników projektu.
Według analiz Standish Group opublikowanych w raporcie Chaos Report 2015, niezależnie od przyjętej metodyki mniej niż 40% projektów wdrożenia systemów kończy się pełnym powodzeniem. Skuteczność spada poniżej 20% wraz ze wzrostem złożoności projektu. W takiej sytuacji pełnym sukcesem kończy się zaledwie 19% projektów realizowanych w metodykach zwinnych i 3% w modelu kaskadowym.
Dane te są niepokojące, ale nie zaskakują nikogo, kto przez lata pracował nad wdrożeniami dla firm z sektora MSP. Nasza współpraca z kilkudziesięcioma firmami z tego sektora oraz spółkami notowanymi na GPW pozwala w dużym stopniu zdefiniować przyczyny problemów na linii dostawca–odbiorca i rozpoznać możliwości ich rozwiązania.
Fundamenty większości zdiagnozowanych problemów sprowadzają się do zakresu doświadczeń osób przystępujących do projektu i słabej edukacji rynku w temacie łączenia technologii z biznesem. Rynek chętnie podąża za trendami, od kilkudziesięciu lat jednak popełnia te same błędy związane z adaptacją oprogramowania do celów biznesowych.
Doświadczenie – gdy obie strony mówią innym językiem
Stosunkowo młoda branża IT rozwija się w zawrotnym tempie, a firmy tradycyjne wchodzące w świat online usiłują przenosić tu swoje wieloletnie przyzwyczajenia. Nierealistyczne oczekiwania wyniesione z procesów budowanych przez kilka dekad to częsty czynnik niepowodzenia projektów.
Doświadczenia biznesowe takich firm nie wpływają pozytywnie na wyspecyfikowane, często nieuzasadnione wymagania. W skrajnych przypadkach sprowadzają się do chęci odwzorowania funkcjonalności i ergonomii systemu ERP na platformie e-commerce, co jest fundamentalnym nieporozumieniem co do roli obu systemów.
Firmy pure online i jednowymiarowa perspektywa biznesowa
Na drugim krańcu tej skali funkcjonują firmy pure online. Młode organizacje rodzące się w Internecie rozumieją rynek i możliwości technologiczne, ale ich perspektywa biznesowa bywa jednowymiarowa. Wynika to z faktu, że niewiele polskich e-biznesów ma za sobą dwie dekady ciągłego działania. Większość z nich, nawet jeśli istnieje od ponad dziesięciu lat, zmieniała się kilkukrotnie. Brakuje w nich menedżerów z szerokim doświadczeniem w prowadzeniu złożonych projektów software’owych. W praktyce ten rodzaj interesariuszy buduje maksymalnie rozbudowane, wielofunkcyjne systemy, które z założenia są podatne na dług technologiczny.
Partnerstwo jako sposób na korzystanie z sumy doświadczeń
Problem luki doświadczeń jest nagminny, a relacja oparta na schemacie „pan i poddany” nie pomaga w korzystaniu z wiedzy żadnej ze stron. Geneza problemu leży po stronie dostawcy w braku udokumentowanych kompetencji i wiarygodności, a po stronie odbiorcy w małej skłonności do zmiany i niechęci do rozumienia możliwości technologicznych tworzonych systemów.
Rozwiązanie istnieje, wymaga jednak partnerskiego podejścia do współpracy. Tylko korzystanie z sumy doświadczeń obu stron przekłada się na synergię i realnie zwiększa szansę powodzenia projektu.
Edukacja – metodyki, które nie rozwiązują wszystkiego
Edukacja w zakresie zarządzania projektem oprogramowania wciąż jest niszowym elementem. Firmy z sektora MSP zwykle nie utrzymują wewnętrznie takich kompetencji, bo nie jest to ekonomicznie uzasadnione. Równie rzadko decydują się na zatrudnienie zewnętrznego konsultanta, który działając po stronie klienta jako właściciel produktu, poprawiłby komunikację między dostawcą a odbiorcą.
Przedstawiciele branży starają się udowodnić wyższość zwinnego zarządzania projektami nad tradycyjnymi modelami kaskadowymi. Konserwatywni klienci z dojrzałych rynków wiedzą jednak, że w budownictwie, medycynie czy motoryzacji nie ma miejsca na MVP i zwinność, a czas, budżet i specyfikacja muszą być zamknięte w sztywnych ramach.
W rezultacie klienci chcą czerpać z obu modeli jednocześnie: elastyczności agile i przewidywalności waterfall. Statystycznie najwyższą skuteczność zapewniają właśnie metody hybrydowe, ale żadna metodologia nie jest w stanie ze stuprocentową gwarancją dostarczyć każdy projekt zgodnie z założonym czasem, budżetem i specyfikacją przy pełnej elastyczności.
3 sposoby na ograniczenie luki kompetencyjnej
Problemu niskiego poziomu wiedzy w zakresie zarządzania projektem nie da się zignorować. Można go jednak ograniczyć na kilka sposobów:
- przekonanie klienta, że wiedza, z którą przychodzi do projektu, nie jest wystarczająca i istnieje realne zagrożenie dla jego realizacji – klient musi mieć tę świadomość potwierdzoną zapisami umowy,
- zaproponowanie wspólnych warsztatów przedwdrożeniowych, które pomagają zdiagnozować i wyeliminować część przyszłych problemów,
- zaproponowanie klientowi zatrudnienia zewnętrznego, doświadczonego konsultanta w sytuacji, gdy poziom zaufania do dostawcy jest ograniczony lub pojawiają się wątpliwości co do dostarczanych kompetencji.
Specyfikacja – jak nie pisać dokumentacji, która się dezaktualizuje
Zebranie i opracowanie wymagań dotyczących tworzonego oprogramowania to rozsądny punkt wyjścia. W zderzeniu z rzeczywistością nawet najbardziej szczegółowa specyfikacja może jednak okazać się niewystarczająca. Kilkusetstronicowe dokumenty pisane przez wiele miesięcy, przy wsparciu zewnętrznych konsultantów i wewnętrznych specjalistów, nie są w stanie przewidzieć wszystkich zawiłości pojawiających się podczas realizacji.
Jeden słownik dla wszystkich stron projektu
Nagminnym zjawiskiem, szczególnie w dużych organizacjach, jest precyzowanie wymagań przez nieodpowiednie działy, co prowadzi do wzajemnie wykluczających się celów. Używanie różnego słownika przez różne osoby jest normą w mało doświadczonych zespołach projektowych.
Kluczowe założenie to stworzenie wspólnego słownika i posługiwanie się wyłącznie nim przez cały czas trwania projektu. Wspólny słownik to pewność, że jednoznacznie interpretujemy pojęcia, które w projekcie mają znaczenie rozstrzygające.
Specyfikuj minimum, uruchom szybko, rozwijaj na podstawie danych
Warto przekonać klienta do specyfikowania w zakresie MLP (minimum loveable product). Ograniczona funkcjonalność o wysokiej jakości, wykluczająca złożone funkcjonalności, które stają się przyczyną niepowodzenia projektu przed jego uruchomieniem. Statystyki są tu wymowne: 23% złożonych projektów agile kończy się niepowodzeniem (42% w waterfall), podczas gdy dla małych i prostych projektów liczby te wynoszą odpowiednio 4% i 11%. Mniejszy zakres pierwszej wersji to wyraźnie większa szansa na terminowe uruchomienie.
Zasady minimalizujące ryzyko na etapie specyfikacji
- specyfikuj wyłącznie minimalny zakres projektu i waliduj każde wymaganie z celami biznesowymi,
- odzwierciedlaj funkcjonalności w user story w konstrukcji „Jako… chcę… więc/aby…”, czytelnej dla IT, marketingu i zarządu,
- unikaj sytuacji, w której wszystkie wymagania mają równy priorytet – rozmywa to chronologię prowadzenia projektu,
- wszystkie decyzje dokumentuj na bieżąco; ustaleń ustnych i drobnych zmian między pracami wyspecyfikowanymi nie zostawiaj bez śladu w dokumentacji.
Literatura specjalistyczna szczegółowo opisała dziesiątki problemów pojawiających się podczas wytwarzania oprogramowania. Dla tych, którzy chcą zgłębić temat, warto sięgnąć po: Karl Wiegers, Joy Beatty, „Specyfikacja oprogramowania. Inżynieria wymagań”, Helion 2015.
Komunikacja – najczęstsze punkty zapalne w projekcie
Metodyki zwinne chętnie korzystają z tablic kanban i codziennych spotkań zespołu. Model kaskadowy ogranicza kontakty z klientem do protokołów zdawczo-odbiorczych po kolejnych etapach. Oba podejścia mają swoje zagrożenia.
Wśród najczęstszych problemów komunikacyjnych można wyróżnić:
- ponowne rozpatrywanie podjętych już decyzji przez klientów, którzy nie są pewni czego chcą, lub przez osoby bez wystarczającej decyzyjności,
- rozmywanie odpowiedzialności za rozwiązanie wątpliwości dotyczących wymagań,
- zmienianie priorytetów realizowanych zadań w trakcie trwającego etapu lub sprintu,
- wprowadzanie zmian po ukończeniu danego etapu wytwarzania oprogramowania,
- dodawanie nowych, czasem wykluczających się wymagań przez różne działy firmy.
Korekty w połowie realizacji projektu potrafią postawić go na głowie. Zadania wymuszane na dostawcy w środku prac nad umową ramową wymagają ponownej analizy technicznej, planowania zasobów i oceny rentowności – i otwierają drogę do niekończącej się customizacji produktu.
Zasady, które ograniczają ryzyko na linii klient-dostawca
Aby ograniczyć ryzyko problemów przy wdrożeniach, warto trzymać się tych reguł:
- komunikacja odbywa się w określonych przedziałach czasowych lub po określonych zdarzeniach, a każde spotkanie ma konkretny konspekt i ograniczony czas,
- wszystkie zadania w projekcie prowadzone są na tablicy kanban dostępnej dla obu stron,
- na początku projektu ustalana jest jedna osoba decyzyjna po stronie klienta i jedna po stronie dostawcy,
- zmiany zakresu i nowe wymagania, które ujawni bieżący sprint, planowane są w ramach kolejnych etapów, a nie realizowane natychmiast.
Warto pamiętać, że w teorii łatwiej jest zmieniać założenia rozwijającego się oprogramowania niż np. zmieniać położenie centrum handlowego w trakcie budowy – jednak nie warto podchodzić do tych zagadnień jak do zupełnie skrajnych przypadków. Zmiana w połowie projektu zawsze generuje koszty.
SOHO.Concept: odpowiedź na systemowe problemy branży
Analiza praktyk software house’ów pokazuje, że sposób wytwarzania oprogramowania w większości firm ma negatywny wpływ na skuteczność projektów. Wynika to z faktu, że branża oferuje klientom nieustanny proces, podczas gdy klient chce przede wszystkim gotowego narzędzia, które spełni jego podstawowe cele.
Realizując dziesiątki projektów z małymi i dużymi firmami, poznaliśmy ich problemy i potrzeby. Nauczyliśmy się też, że długie, wieloletnie realizacje mogą być korzystne finansowo dla dostawcy, ale nie służą wspólnemu sukcesowi. Im szybciej jesteśmy w stanie dostarczyć mierzalną wartość dla klienta, tym skuteczniej wdrażamy rozwiązanie i tym szybciej obie strony widzą efekty.
Szybkie time to value zamiast wielomiesięcznych wdrożeń
Udało nam się wypracować autorski system realizacji projektów – SOHO.Concept. Hybrydowa struktura rozwiązania łączy przewidywalność waterfall (pełna specyfikacja funkcjonalności na starcie i konkretny termin uruchomienia) z elastycznością agile (możliwość nieograniczonego rozwoju zgodnie ze specyficznymi potrzebami klienta).
W modelu SOHO.Concept dostarczamy systemy B2B i oprogramowanie marketplace w czasie kilku tygodni. Podstawowe oprogramowanie spełnia od startu 90-95% oczekiwań klientów, po czym jest rozwijane pod kątem specyficznych potrzeb i branży w oparciu o metodyki zwinne. Ten model pracy zapewnił nam 100% skuteczności w dostarczaniu oprogramowania.
Chcesz omówić, jak SOHO.Concept mógłby wyglądać w Twoim przypadku? Umów z nami bezpłatną rozmowę.
FAQ
Dlaczego tak wiele projektów oprogramowania kończy się niepowodzeniem?
Według Chaos Report 2015 (Standish Group) mniej niż 40% projektów kończy się pełnym sukcesem. Główne przyczyny to luka doświadczeń między klientem a dostawcą, brak wspólnego słownika, zbyt rozbudowana specyfikacja na starcie i problemy komunikacyjne w trakcie realizacji. Trudność polega na tym, że wszystkie te czynniki są po ludzku zrozumiałe, ale statystycznie destrukcyjne.
Czy lepiej wdrażać w metodyce agile czy waterfall?
Obie mają zalety i wady. Agile daje elastyczność, ale wymaga dojrzałości organizacyjnej i może prowadzić do nieskończonej customizacji. Waterfall daje przewidywalność, ale jest nieodporny na zmiany. Statystycznie najwyższą skuteczność dają metody hybrydowe, które łączą narzędzia obu podejść do specyfiki konkretnego projektu.
Co to jest MLP i dlaczego warto zacząć od niego zamiast pełnej specyfikacji?
MLP (minimum loveable product) to minimalna wersja systemu o wysokiej jakości, która pozwala uruchomić projekt bez złożonych funkcjonalności, które są główną przyczyną przekroczeń budżetu i terminów. Małe i proste projekty kończą się niepowodzeniem tylko w 4% przypadków (agile) wobec 23% dla projektów złożonych. Szybkie uruchomienie MLP pozwala zwalidować system z realnymi użytkownikami i rozwijać go na podstawie danych, nie założeń.
Jak dobrze zdefiniować osobę decyzyjną po stronie klienta w projekcie?
Warto to ustalić na piśmie przed startem projektu. Najczęstszy problem to sytuacja, w której product owner realizuje projekt według swojej wizji, a po zakończonym etapie waliduje wynik z prezesem – który ma inne oczekiwania. To generuje zmiany w ukończonym oprogramowaniu i gwałtownie podnosi koszty. Jedna osoba z realną decyzyjnością po stronie klienta to warunek sprawnej realizacji.
Na czym polega SOHO.Concept?
To autorska metodologia SOHOsoft łącząca waterfall i agile. Na starcie dostarczamy oprogramowanie spełniające 90-95% potrzeb klienta, uruchamiamy je w kilka tygodni, a następnie rozwijamy pod indywidualne wymagania w modelu abonamentowym. Celem jest jak najszybsze dostarczenie mierzalnej wartości biznesowej, zamiast wielomiesięcznego procesu kończącego się uruchomieniem.
