Prowadzenie projektów związanych z wytwarzaniem oprogramowania to nieodłączny element rozwoju nowoczesnej organizacji. Wdrożenie i dostosowanie systemów realizujących kolejne cele biznesowe to ogromna szansa, ale też duże wyzwanie dla uczestników projektu.
Dane o skuteczności wytwarzania oprogramowania na świecie
Według analiz opublikowanych przez Standish Group w raporcie “Chaos Report 2015” niezależnie od metody realizacji projektu, mniej niż 40-proc. przedsięwzięć związanych z wdrożeniem systemów kończy się powodzeniem. Skuteczność dostarczania oprogramowania spada poniżej 20-proc. wraz ze wzrostem złożoności projektu. W takiej sytuacji pełnym sukcesem kończy się zaledwie 19-proc. projektów realizowanych w metodykach zwinnych i jedynie 3-proc. prowadzonych w modelu kaskadowym. Sytuacja związana z wytwarzaniem oprogramowania niezbędnego do rozwoju biznesów w obszarze e-commerce wygląda fatalnie, pomimo niewątpliwie dobrej woli wszystkich interesariuszy projektu.
Wytwarzanie oprogramowania w literaturze
Nasza współpraca z kilkudziesięcioma firmami z sektora MSP oraz spółkami z GPW, a także rzetelna analiza wykonanych w tym czasie wdrożeń systemów B2B, pozwala w dużym stopniu zdefiniować przyczyny problemów na linii dostawca – odbiorca oraz rozpoznać potencjalne możliwości ich rozwiązania. Literatura specjalistyczna opisała szczegółowo dziesiątki problemów powstających pomiędzy klientem i usługodawcą podczas projektów wytwarzania oprogramowania. Aby poznać je wszystkie warto sięgnąć po lekturę: “Specyfikacja oprogramowania. Inżynieria wymagań” Karl Wiegers i Joy Beatty, Helion 2015. Jednocześnie teoretyczne poznanie i zrozumienie pojawiających się problemów nie zastępuje praktyki, dlatego wyodrębniliśmy kluczowe problemy praktyczne związane z wytwarzaniem oprogramowania B2B i marketplace.
Praktyka wytwarzania oprogramowania
Fundamenty większości zdiagnozowanych problemów wciąż sprowadzają się do zakresu doświadczeń osób przystępujących do projektu i słabej edukacji rynku w temacie łączenia nowych technologii i biznesu. Z jednej strony rynek pragnie podążać za trendami, o czym świadczy choćby mnogość konferencji poruszających tematykę sztucznej inteligencji i pokrewnych, z drugiej zaś, od kilkudziesięciu lat popełnia te same błędy związane z adaptacją oprogramowania do realizacji celów biznesowych.
Doświadczenie
W filozofii „doświadczenie” to całokształt procesu postrzegania rzeczywistości, a według słownika PWN – “suma wiadomości i umiejętności zdobytych na podstawie obserwacji i własnych przeżyć”. Abstrahując od celu biznesowego przedsięwzięcia to właśnie doświadczenie stron przystępujących do projektu może być fundamentalnym problemem w procesie wytwarzania oprogramowania.
Stosunkowo młoda branża IT rozwija się w zawrotnym tempie, a firmy tradycyjne wchodzące w świat online usiłują przenieść tutaj swoje wieloletnie przyzwyczajenia. Nierealistyczne oczekiwania wyniesione z siermiężnych procesów budowanych przez kilka dekad są częstym czynnikiem niepowodzenia projektów. Doświadczenia biznesowe takich firm nie wpływają pozytywnie na wyspecyfikowane, często nieuzasadnione wymagania, które w skrajnych przypadkach sprowadzają się do chęci odwzorowania funkcjonalności i ergonomii systemu ERP na platformie e-commerce.
Jednocześnie na drugim krańcu tej szali funkcjonują firmy typu pure online. Młode organizacje rodzące się w internecie. Te firmy rozumieją rynek i możliwości technologiczne, ale ich perspektywa biznesowa bywa jednowymiarowa. Wynika to z faktu, że niewiele jest w polskich realiach e-biznesów, które rozwijają się od 20 lat. Większość z nich, nawet jeśli funkcjonuje od ponad dekady, zmieniała się kilkukrotnie, przez co brakuje w nich managerów posiadających szerokie doświadczenie w prowadzeniu projektów związanych z wytwarzaniem oprogramowania. W praktyce ten rodzaj interesariuszy próbuje budować maksymalnie “skastomizowane” multifunkcjonalne systemy i narzędzia, które z założenia skazane są na małą elastyczność i nieunikniony dług technologiczny w przyszłości.
Problem z różnymi doświadczeniami stron przystępujących do projektu jest nagminny, a przebieg współpracy z perspektywy “pan i poddany” nie pomaga w korzystaniu z sumy doświadczeń interesariuszy. Genezą tego problemu jest brak zaufania do dostawcy, mała wiarygodność dostawcy lub brak udokumentowanych kompetencji. Natomiast po stronie odbiorcy jest to zwykle mniejsza niż oczekiwana skłonność do zmiany, brak chęci edukacji i zrozumienia możliwości technologicznych tworzonych systemów.
Rozwiązanie jest osiągalne, wymaga jednak partnerskiego podejścia do współpracy, ponieważ tylko korzystanie z sumy doświadczeń przekłada się na synergię i zwiększa szansę powodzenia projektu.
Edukacja
Edukacja związana z wytwarzaniem oprogramowania wciąż jest niszowym elementem projektu. Zdarza się, że poziom wiedzy po stronie klienta to jedynie owoc rozmów z przystępującymi do ofertowania firmami. Przedsiębiorstwa z sektora MSP zwykle nie utrzymują wewnętrznie kompetencji związanych z prowadzeniem projektów software’owych, bo nie jest to uzasadnione ekonomicznie. Niestety równie rzadko decydują się na zatrudnienie zewnętrznego konsultanta, który działając po stronie klienta jako właściciel produktu jest w stanie poprawić komunikację pomiędzy dostawcą i odbiorcą oprogramowania. Nierozerwalnie związane z edukacją jest zrozumienie samego sposobu zarządzania projektem. Firmy prześcigają się w optymalizowaniu metodologii i metodyk, których zadaniem jest wzrost efektywności realizowanych projektów.
Reprezentanci młodej branży starają się udowodnić wyższość zwinnego zarządzania projektami nad tradycyjnymi modelami kaskadowymi. Konserwatywni klienci przychodzący z dojrzałych rynków do świata online, wiedzą że w budownictwie, medycynie, motoryzacji i innych branżach nie ma miejsca na MVP i “zwinność”, a czas, budżet i specyfikacja powinny być zamknięte w sztywnych ramach.
W rezultacie klienci chcieliby czerpać korzyści ze wszystkich poznanych modeli, dlatego wymagają agile’owej elastyczności i sztywnych ram finansowo-czasowych waterfall’a. Statystycznie najwyższą skuteczność zapewniają właśnie metody hybrydowe, czerpiące z narzędzi modeli kaskadowych i metodyk zwinnych typu AgilePM. Nie istnieje jednak jeden skuteczny system zarządzania, metodologia czy zespół, które w zderzeniu z rzeczywistością rynkową są w stanie, ze stuprocentową skutecznością, dostarczyć każdy projekt zgodnie z założonym czasem, budżetem i specyfikacją wymagań przy zachowaniu pełnej elastyczności.
Wielowymiarowa specyfika rynku weryfikuje każdy sposób zarządzania projektem, który jak się okazuje w ostatecznym rozrachunku, jest tylko wierzchołkiem piętrzących się trudności w procesie wytwarzania oprogramowania.
Problem niskiego poziomu wiedzy w zakresie zarządzania projektem oprogramowania można ograniczyć na kilka sposobów:
- przekonać klienta, że wiedza z którą przychodzi do projektu nie jest wystarczająca i istnieje duże zagrożenie dla jego realizacji, dlatego klient musi mieć tego świadomość potwierdzoną zapisami umowy,
- zaproponować klientowi wspólne warsztaty przedwdrożeniowe, które pomogą zdiagnozować i wyeliminować część przyszłych problemów,
- zaproponować klientowi zatrudnienie zewnętrznego, doświadczonego konsultanta w sytuacji gdy poziom zaufania do dostawcy jest ograniczony lub pojawiają się wątpliwości co do dostarczanych kompetencji.
Przy założeniu, że w procesie wytwarzania oprogramowania:
- klient podchodzi do współpracy partnersko i wybiera wspomnianą wcześniej sumę doświadczeń, kosztem pełnej władczości w projekcie,
- jest w stanie uzupełniać potencjalne braki na jeden z rekomendowanych powyżej sposobów,
- zrozumiał i wybrał metodę prowadzenia projektu,
istnieje duża szansa na zakończenie projektu sukcesem. Wiedząc jednocześnie, że prawdziwe wyzwania pojawią się dopiero na kolejnych etapach jego realizacji.
Specyfikacja
Zebranie i opracowanie wymagań dotyczących tworzonego oprogramowania jest rozsądnym punktem wyjścia do pracy z nowym projektem. Niestety w zderzeniach z rzeczywistością potrafi ucierpieć nawet najbardziej szczegółowa specyfikacja wymagań. Kilkusetstronicowe specyfikacje oprogramowania pisane przez wiele miesięcy przy wsparciu zewnętrznych konsultantów i wewnętrznych specjalistów, a także walidowane z dostawcą przed rozpoczęciem projektu, nie są w stanie przewidzieć wszystkich zawiłości, które pojawią się podczas realizacji przedsięwzięcia.
Metodyki zwinne zakładają, aby czekać ze szczegółowymi wymaganiami do momentu startu prac, bo w przeciwnym wypadku tracimy czas na tworzenie dezaktualizujących się założeń. Model kaskadowy nakazuje specyfikować szczegółowo minimalizując tym samym ryzyko błędów i niedopowiedzeń. Praktyka pokazuje, że wyszczególnienie zbędnych wymagań czy używanie różnego słownika, jest normą w większości mało doświadczonych zespołów projektowych. Nagminnym zjawiskiem, szczególnie w dużych organizacjach, bywa precyzowanie wymagań przez nieodpowiednie działy w firmie, najczęściej prowadzące do wzajemnie wykluczających się celów.
Aby poradzić sobie z wyzwaniem związanym ze specyfikacją wymagań warto rozważyć następujące założenia:
- stworzenie wspólnego słownika i posługiwanie się tylko nim w czasie trwania projektu. Wspólny słownik to pewność, że jednoznacznie interpretujemy kluczowe pojęcia w projekcie.
- specyfikowanie wyłącznie minimalnego zakresu projektu. Warto przekonać klienta do specyfikowania w zakresie MLP (ang. minimum loveable product). Ograniczona funkcjonalność, która pozwala uruchomić projekt przy zachowaniu wysokiej jakości i wyklucza złożone funkcjonalności, które są przyczyną niepowodzenia projektu przed jego uruchomieniem. 23-proc. złożonych projektów w procesie agile kończy się niepowodzeniem (42-proc. w przypadku waterfall) w stosunku do 4-proc. (11-proc w waterfall) dla małych i prostych projektów. Mniejszy zakres pierwszej odsłony (ang. release) to większa szansa na terminowe uruchomienie projektu.
- odzwierciedlanie funkcjonalności w “user story”, czyli czytelnych dla wszystkich działów w firmie (IT, marketing, zarząd) historiach użytkownika związanych z wykorzystaniem systemu. Popularny wzorzec tworzenia “user story” bazuje na następującej konstrukcji: “Jako … chcę … więc/aby …”.
- unikanie sytuacji, w której spisane wymagania mają równą wagę i jednakowo wysoki priorytet, bo rozmywa to chronologie prowadzenia projektu.
- unikanie podejmowania ustnych, nie udokumentowanych ustaleń i drobnych zmian pojawiających się pomiędzy pracami wyspecyfikowanymi.
- przy tworzeniu specyfikacji walidować wymagania z celami biznesowymi projektu. W praktyce może okazać się, że zakres funkcjonalności odbiega znacząco od zamierzonych do osiągnięcia celów biznesowych lub też, pomimo złożoności projektu, w niewielkim stopniu realizuje wybrane cele.
Kluczowe jest założenie posługiwania się jednym słownikiem i dążenie do szybkiego uruchomienia wersji MLP (ang. minimum loveable product) lub MVP (ang. minimum viable product), bo to pozwala sprawnie zwalidować dostarczone oprogramowanie z potrzebami jego interesariuszy, a następnie rozwijać system zgodnie z bieżącym zapotrzebowaniem i trendami.
Komunikacja
Komunikacja w projekcie to codzienność, a sposób jej prowadzenia zależny jest od przyjętego sposobu zarządzania projektem. Metodyki zwinne chętnie wykorzystują tablice typu kanban w celu stałej wizualizacji stanu projektu. W modelu kaskadowym rzadziej prowadzona jest bieżąca komunikacja, a w skrajnych przypadkach kontakty z klientem sprowadzają się do spisania protokołów zdawczo-odbiorczych po realizacji kolejnego etapu projektu.
Model komunikacji przyjęty w tradycyjnych modelach zarządzania pomimo tego, że wygodny dla dostawcy, może ujawnić niedopowiedzenia dopiero na ostatnich etapach realizacji projektu. Zagrożenia komunikacyjne w metodykach zwinnych to permanentne prowadzenie debaty nad projektem, częste omawianie abstrakcyjnych, zawieszonych w próżni problemów, a czasami raportowanie zamiast planowania. Wielogodzinne wideokonferencje z klientem, długotrwałe analizy pojawiających się po drodze problemów teoretycznych, a tym samym ograniczenie czasu na pracę nad projektem, to sytuacje z którymi spotykają się zespoły zwinne. Oczywiście frameworki typu Scrum dostarczają konkretnych wskazówek, co do czasu planowania backloga produktu, częstotliwości retrospekcji czy sposobu prowadzenia codziennych spotkań zespołu developerskiego. Dzięki czemu stosowanie tych wzorców wpływa pozytywnie na proces wytwarzania oprogramowania. Jednak żaden zespół czy metodyka, pomimo ściśle wyznaczonych kanonów komunikacyjnych, nie są w stanie w pełni uniknąć zagrożeń.
Wśród najczęstszych możemy wyróżnić:
- ponowne rozpatrywanie podjętych już decyzji – klienci nie są pewni czego chcą lub osoby podejmujące decyzje po stronie klienta nie mają dostatecznej władzy,
- rozmywanie odpowiedzialności za rozwiązanie części pojawiających się problemów i wątpliwości dotyczących wymagań,
- zmienianie priorytetów realizowanych zadań,
- wprowadzanie zmian po ukończeniu danego etapu wytwarzania oprogramowania,
- dodawanie nowych czasem wykluczających się wymagań, przez różne działy w firmie.
Korekty pojawiające się na etapie realizacji projektu potrafią postawić projekt na głowie. Zdarza się, że odbiorca początkowo nalega na zamknięcie umowy w kilku sztywnych etapach projektu. Następnie w toku prac korzystając z dyspozycyjności zespołu projektowego zmienia wymagania lub specyfikuje nowe zadania z wyższym priorytetem. Dla dostawcy jest to sytuacja niekorzystna, bo przed podjęciem zmian i nowych zadań chce zrealizować i rozliczyć założenia umowy. Zadania wymuszane na dostawcy w połowie prac nad umową ramową wymagają ponownej analizy technicznej, ponownego planowania zasobów i ogólnej rentowności projektu. Decydowanie się na zmianę założeń w trakcie trwania projektu stwarza też pole do wejścia w ryzykowny proces niekończącej się “kastomizacji” produktu.
Aby minimalizować ryzyko konfliktów w trakcie wytwarzania oprogramowania warto przekonać klienta do trzymania się poniższych założeń:
- komunikujemy się w określonych przedziałach czasowych lub po określonych wydarzeniach, a nasze spotkania mają konkretnie określony konspekt i czas,
- wszystkie zadania realizowane w trakcie projektu prowadzimy na tablicy typu kanban, która jest dostępna dla każdej ze stron, a w razie potrzeby wspomagamy się dodatkowymi wykresami, np. zaczerpniętymi ze scrum typu “burn-down”,
- podejmujemy decyzję, czy w ramach projektu wszyscy członkowie zespołu deweloperskiego mogą i powinni komunikować się z uczestnikami projektu po stronie klienta, czy komunikacja prowadzona jest wyłącznie na poziomie product owner – project manager,
- ustalamy, że głos osoby X w projekcie jest decyzyjny po stronie klienta, a osoby Y po stronie dostawcy. Ogranicza to sytuacje, w których właściciel produktu realizuje projekt według swojej wizji, a następnie, już po zakończonym etapie, waliduje rezultat z prezesem przyjmując jego wytyczne – taka procedura najczęściej generuje zmiany w wytworzonym już oprogramowaniu.
- wspólnie minimalizujemy sytuacje, w których podczas jednego etapu lub sprintu następuje zmiana priorytetów lub zakresu wymagań dla danego etapu.
- wszystkie rozszerzenia, dodatki i zmiany, które ujawnił obecny sprint, staramy się planować w ramach kolejnych etapów.
Podsumowanie
Wytwarzanie oprogramowania niesie znacznie więcej zagrożeń dla każdej strony projektu, niż te opisane powyżej. Rzeczywistość rynkowa nie jest pozbawiona przykładów, w których pomimo prowadzenia projektu na najwyższym szczeblu decyzyjności (zarząd – dostawca), do akcji wkracza większościowy udziałowiec. Jego zaangażowanie i zainteresowanie tematem najczęściej prowadzi do redefinicji celów biznesowych, a tym samym do odwrócenia założeń o 180-stopni. Wynika to z faktu, że wytwarzanie oprogramowania, czyli wirtualnych zapisów w systemach informatycznych to abstrakcyjny twór dla osób nietechnicznych. Co prawda w teorii i w praktyce łatwiej jest zmieniać założenia rozwijanego oprogramowania niż np. zmieniać położenie centrum handlowego w trakcie budowy, jednak nie warto z góry podchodzić do tych zagadnień, jak do zupełnie skrajnych projektów. Warto również pamiętać, że wskazane obszary związane z doświadczeniem, edukacją, specyfikacją i komunikacją to elementy, na które trzeba zwrócić szczególną uwagę jeszcze przed rozpoczęciem projektu. A sama świadomość regularnego występowania wymienionych w tym artykule wyzwań to pierwszy krok w kierunku minimalizowania ryzyka związanego z nowym przedsięwzięciem.
Rozwiązanie sprawdzone w praktyce, czyli SOHO.Concept
Pomimo tego, że statystyki są zatrważające, a doświadczenia rynkowe potwierdzają, że wytwarzanie oprogramowania to trudny i ryzykowny proces, stanowi on nieodłączny element rozwoju biznesu na całym świecie. Analiza jaką przeprowadziliśmy – przyglądając się dokładnie praktykom software house’ów – pokazuje, że sposób wytwarzania oprogramowania w większości firm ma negatywny wpływ na skuteczność realizowanych projektów. Wynika to z faktu, że wszyscy oferują klientom nieustanny proces, budując, wdrażając lub rozwijając oprogramowanie. Konotacje słów, wykorzystywanych przez branżę do realizacji swoich usług, sprowadzają się do działań ciągłych i niekończących się, co nie jest spójne z DNA biznesu.
Biznes chce przede wszystkim otrzymać narzędzie, które spełni jego podstawowe cele. Dlatego nie interesuje go żmudny proces, a gotowy towar (ang. commodity product) jakim jest oprogramowanie.
Realizując dziesiątki projektów z małymi i dużymi firmami poznaliśmy ich problemy i potrzeby, dzięki czemu udało nam się wypracować autorski system realizacji projektów – SOHO.Concept. Patent działa na pograniczu metodyk zwinnych i czerpie z najlepszych praktyk modelu kaskadowego. Dzięki temu hybrydowa struktura rozwiązania wychodzi na przeciw oczekiwań naszych klientów, łącząc w sobie przewidywalność waterfall (pełna specyfikacja funkcjonalności na starcie i konkretny termin uruchomienia) i elastyczność agile (możliwość nieograniczonego rozwoju zgodnie ze specyficznymi potrzebami klienta). Ideą nadrzędną jest dostarczenie partnerom biznesowym takiego rozwiązania, które mogą uruchomić szybciej, taniej i bez kompromisów jakościowych, a następnie rozwijać w ramach w pełni ustandaryzowanych procesów. Ten sposób dostarczania oprogramowania zapewnia wysoką skuteczność realizowanych projektów, a tym samym odpowiada oczekiwaniom i wymaganiom wszystkich interesariuszy projektu. Obecnie w modelu SOHO.Concept dostarczamy systemy B2B i oprogramowanie Marketplace. W obu przypadkach podstawowe oprogramowanie uruchamiane jest w czasie kilku tygodni. Takie oprogramowanie posiada założoną specyfikację funkcjonalności, które spełniają nawet 90-95% oczekiwań większości klientów. Następnie – po uruchomieniu oprogramowania – dostarczony system jest rozwijany pod kątem specyficznych potrzeb klienta i rynku, na którym działa, w oparciu o metodyki zwinne. Ten model pracy zapewnił nam 100% skuteczność wytwarzania oprogramowania.
