W eVolpe zajmuję się sprzedażą oprogramowania Open Source dla biznesu. Prawdziwą wartość systemów CRM dostrzegam w funkcjach pozwalających na analitykę danych. W rozmowach z moimi klientami często podkreślam, jak istotna jest skrupulatność wprowadzania informacji do systemu.
W razie pytań zapraszam do kontaktu. Jestem też na LinkedInie!
Do napisania tego artykułu zainspirowała mnie prawdziwa historia. Jakiś czas temu rozmawiałem z klientem na temat zasad dalszej współpracy. Dogadywaliśmy się w lot. Piotr (tak go nazwijmy) wykazywał bardzo dużo zrozumienia dla podejścia zwinnego i realizacji omawianego projektu w Scrumie. Problem w tym, że miał przekonać do tego jeszcze kilku decydentów – osoby, które nie miały z tym nigdy do czynienia…
Poprosił mnie wtedy o pomoc. Potrzebował uporządkowanej listy argumentów, których mógłby użyć. Razem z Asią z Marketingu przygotowaliśmy dla niego specjalny załącznik. Pomyślałem, że podobny materiał przyda się także Tobie.
Jeśli nie znasz Scruma, albo podobnie jak Piotr potrzebujesz go zarekomendować wewnątrz organizacji – znajdziesz tutaj gotową instrukcję. Przy okazji wyjaśniam, w czym tkwią pułapki tradycyjnego podejścia. Pozbawione kontekstu hasła takie jak: fixed price, dokumentacja systemu czy stabilny projekt wdrożeniowy, nie jednego zwiodły na manowce.
Waterfall – w czym tkwi problem?
Waterfall to tradycyjna metodyka wdrożeniowa. „Kaskadowo” realizowało się projekty IT u ich zarania. Umawiano się na efekt końcowy, cenę, spisywano dokumentację gotowego systemu i podążano w kierunku jej wypełnienia.
Brzmi rozsądnie? Cóż, być może, ale nie w czasach, kiedy tak wiele wokół nas niepewności. Wojna, pandemia, kryzys gospodarczy, pędzący postęp technologiczny to tylko niektóre (jakże bieżące) czynniki, które wpływają na szybkie tempo dezaktualizacji przyjętych założeń. Także w obszarze prowadzenia przedsiębiorstwa. Również w obszarze Software Development.
I chociaż to z pewnością nie najważniejszy temat na dziś, nasze biznesy powinny działać dalej. Jeżeli zastanawiasz się akurat nad wyborem metodyki wdrożeniowej, bo za pomocą nowego oprogramowania chcesz umacniać swoją firmę dla dobra pracowników i całej gospodarki – liczę, że te kilka akapitów na coś się przyda. Znajdziesz tu odpowiedź na typowe wątpliwości nurtujące decydentów.
Zacznijmy jednak od ostatecznej dekonstrukcji mitu dotyczącego tradycyjnego (waterfallowego) podejścia. Później będzie jeszcze trochę o frameworku Scrum.
Wady projektów opartych na sztywnej dokumentacji
Zgodnie z zasadami Waterfall – projekt zaczyna się od sporządzenia dokumentacji systemu do wytworzenia. Pierwsza trudność polega na opracowaniu bardzo szczegółowego opisu nieistniejącego jeszcze produktu. Zajmuje to bardzo dużo czasu i opóźnia rozpoczęcie prac deweloperskich. Zanim programiści siądą do kodu, czekają Cię długie negocjacje, analiza wielu scenariuszy (bez gwarancji ich ziszczenia) oraz godziny spędzone na poprawkach treści.
Co najgorsze nawet obustronnie zatwierdzona i w 100% zrealizowana dokumentacja nie gwarantuje sukcesu projektu wdrożeniowego. Uzyskasz co prawda działający system, w uzgodnionej formie i za określone pieniądze, ale z dużą dozą prawdopodobieństwa – w znacznej części „przeterminowany”.
Wdrożenie trwa zwykle od kilku do kilkunastu tygodni, a nawet dłużej. Myślę, że nie musimy tego sprawdzać empirycznie, żeby uznać, że w takim czasie albo zdezaktualizują się potrzeby wobec oprogramowania, albo Twój biznes ruszy naprzód, albo w środowisku zewnętrznym wydarzy się coś całkowicie nieprzewidywalnego.
Utrudnione zarządzanie zmianą
Oczywiście to nie tak, że w trakcie tradycyjnego wdrożenia dokumentacja staje się nietykalna. Możecie na bieżąco ją aneksować. Niestety wymaga to długotrwałych negocjacji, konsultacji z licznym kworum decydentów oraz wysoce sformalizowanej formy. A przecież czas to pieniądz. Działając waterfallowo sporo go marnujesz. Nie zrekompensuje Ci tego nawet osławiony fixed price. Co z tego, że cena za system pozostaje bez zmian, jeśli projekt się opóźnia, funkcje dezaktualizują, a Wy nawet nie zaczęliście z tym jeszcze pracować…
Scrum – ratunek w elastycznym podejściu do sprawy
Nie chciałbym dzisiaj powielać wywodów definicyjnych. O tym, czym jest Scrum i jak przebiega „zwinne” wdrożenie systemu IT, było już tutaj wiele razy. Jeśli masz wątpliwości, odwiedź proszę tę podstronę: https://evolpe.pl/scrum/ lub obejrzyj załączony poniżej filmik.
Tym razem skupmy się na bezdyskusyjnych zaletach tego typu podejścia. O taką odartą z kontekstu listę poprosił mnie Piotr i takie argumenty przygotowałem także dla Ciebie.
#1 Zabezpieczenie interesów klienta
Po pierwsze umowa wdrożeniowa. Ustalamy w niej warunki dalszej współpracy. Na jej mocy możesz się domagać respektowania Twoich praw. Między innymi prawa do wstrzymania lub zakończenia projektu na dowolnym etapie oraz powrotu do jego realizacji po czasie (decyzją Klienta). To powinno uspokoić decydentów, którzy obawiają się przekroczenia budżetu, gdy nie wskazano stałej ceny za system w określonej dokumentacją formie.
#2 Oszacowanie projektu
Zresztą to nie tak, że budżet w Scrumie jest totalną niewiadomą. Po dogłębnej analizie przedwdrożeniowej (o niej za chwilę) otrzymasz bardzo konkretne oszacowanie projektu z podziałem na mniejsze elementy i informacją o szacunkowej cenie każdego z nich. Wskazuje się w nim również górną granicę budżetu na system w aktualnie uzgodnionej formie. Wydatkami na system sterujesz na bieżąco, dobierając kolejne zagadnienia do realizacji. Masz pełnię swobody w nadawaniu im priorytetów (np. na podstawie kryterium kosztowego). A po ludzku: płacisz za to, co zgłaszasz do wytworzenia. I to dokładnie tyle, ile czasu i zasobów pochłonie realizacja zagadnienia. O czym, jesteś też zresztą na bieżąco informowany w systemie projektowym. Członkowie zespołu deweloperskiego zamieszczają tam komentarze na temat tego, czym się i jak długo zajmowali. Wszystko jest prowadzone przejrzyście i na stałe udostępnione do wglądu przez Klienta.
#3 Dogłębne badanie potrzeb
Obiecałem Ci jeszcze parę słów o analizie przedwdrożeniowej. Bez tego nie może być mowy o sukcesie zwinnego wdrożenia. Zanim rozpoczną się prace, należy się koniecznie spotkać na specjalnych warsztatach z analitykiem. Służy to zrozumieniu procesu biznesowego klienta oraz rozpoznaniu najważniejszych potrzeb do odzwierciedlenia w systemie. W ten sposób zabezpieczasz się przed nieporozumieniami i niepowodzeniem całego przedsięwzięcia. Wnioski ze spotkania posłużą do stworzenia tzw. Backlogu Produktu; potocznie mówiąc – worka z pomysłami na funkcjonalność Twojego systemu. Będziemy do niego sięgać w trakcie prac implementacyjnych. Cały czas możesz go też porządkować, zmieniać i rozbudowywać wedle aktualnych preferencji.
#4 Natychmiastowe rozpoczęcie prac nad systemem
Brak dokumentacji oznacza znaczącą oszczędność czasu. Zamiast czekać na kolejny tom tej jakby niekończącej się opowieści, prace nad systemem można rozpocząć od razu.
Analityk, który odwiedza Twoją siedzibę w celu przeprowadzenia warsztatów, po zbadaniu potrzeb i w porozumieniu z przedstawicielem Twojej organizacji, jest w stanie przygotować zestaw funkcji do wytworzenia w pierwszych kilku Sprintach. Na podstawie historyjek z życia użytkowników (User Stories) zebranych przez niego w Backlogu Produktu, programiści siadają do pracy bez zbędnych ceregieli.
Już po pierwszych 2 tygodniach (tyle zwykle trwa jedna iteracja w Scrumie) otrzymujesz pierwsze funkcje do testów. Efekty pracy zespołu mogą nawet od razu trafić na „produkcję”.
Instancja systemu, której będziecie używać jeszcze w trakcie trwania projektu, nazywa się MVP – Minimum Viable Product. Jest to rozwiązanie, które przy niskim nakładzie kosztów zapewnia pierwsze mierzalne zyski dla organizacji. Rozbudowuje się ją wraz z każdym kolejnym ukończonym i zatwierdzonym przez Ciebie przyrostem funkcjonalnym. Nie musisz czekać kilku miesięcy na zakończenie prac nad całym rozpisanym projektem. Z powstającego oprogramowania da się korzystać i czerpać wartość już od samego początku prac. Szczególnie, jeżeli sięgacie po gotowy produkt o otwartym kodzie, w którym programiści dokonają tylko pewnych zmian.
#5 Twój aktywny udział w projekcie
Kiedy decydujesz się na Scrum nic, co dzieje się w projekcie, nie ujdzie Twojej uwadze. Zwinna metodyka wdrożeniowa wymaga zaangażowania przedstawiciela z organizacji, która zamawia system.
Na wyznaczonego przez Ciebie koordynatora projektu mówi się z angielska Product Owner. Bierze on udział w licznych spotkaniach, w trakcie których ustala się kierunek realizowanych działań. Otrzymuje dostęp do systemu projektowego. Na jego skrzynkę mailową spływają powiadomienia o postępach. W imieniu firmy testuje i akceptuje wytworzone przez zespół deweloperski „kawałki” systemu.
I tak. To bardzo odpowiedzialna rola. Powołanie do tego zadania kogoś zaufanego i decyzyjnego sprzyja sukcesowi całego przedsięwzięcia. Product Owner powinien czuwać nad przebiegiem wdrożenia, na bieżąco zgłaszać zmieniające się potrzeby oraz kontrolować budżet. Najważniejsze jednak, że Scrum gwarantuje Ci taką możliwość. Masz szansę się zaangażować. Jeśli z tego korzystasz, otrzymujesz narzędzie, z którego wszyscy są zadowoleni.
#6 Elastyczne podejście do zmiany
W projektach scrumowych zmiana jest czymś naturalnym. Podobnie zresztą jak w życiu. Po co udawać, że jest inaczej? Może ona wynikać zarówno ze zmieniających się potrzeb Klienta jak i na bieżąco uzgadnianych usprawnień dotyczących sposobu działania.
Były już takie przypadki, że firma rozszerzała portfolio oferowanych usług albo dokonywała zmian wewnętrznych struktur w trakcie wdrożenia. Scrum pozwala na adaptację do takich decyzji. Chociaż na początku przewidywano ograniczony katalog produktów, po czasie na życzenie klienta, można go było rozbudować. Jest to wręcz jak najbardziej wskazane! Po co komu system, który nie pasuje do aktualnego obrazu firmy?
Na koniec tej myśli jeszcze jedna informacja dla sceptyków. W umowie wdrożeniowej znajduje się zabezpieczenie przed manipulowaniem dwoma rzeczami: harmonogramem oraz budżetem.
No chyba, że sam takowe zmiany zatwierdzasz lub zlecasz.
#7 Rozliczenia za czas i zasoby wykorzystane w projekcie
Przemycałem tę informację już kilkakrotnie, ale nie nazwałem tego jeszcze po imieniu. W Scrumie rozliczamy się na zasadach Time & Material, czyli wyłącznie za czas i zasoby poświęcane na realizację systemu. Oczywiście z uwzględnieniem oszacowania i górnej granicy budżetu, o których była mowa wyżej. Wszystko jest też transparentnie komunikowane w systemie projektowym (powiadomienia rozsyłane na skrzynki mailowe zainteresowanych osób) oraz podlega stałej kontroli Product Ownera (koordynatora projektu wyznaczonego przez Klienta).
Może się oczywiście wydarzyć, że za niektóre funkcje zapłacisz więcej niż wstępnie oszacowano. To w końcu tylko szacunek. Nie dowiadujesz się jednak o tym z faktury na koniec miesiąca, a na bieżąco, z systemu projektowego. To Product Owner wraz z proxy Product Ownerem, czyli analitykiem biznesowym wspólnie dobierają zagadnienia do realizacji i kontrolują ile to wszystko kosztuje.
Może się też zdarzyć, że zapłacisz mniej.
#8 Partnerska współpraca i poczucie bezpieczeństwa
Zaletą zwinnej metodyki wdrożeniowej jest niski stopień formalizacji całego procesu. Nie trzeba każdej poprawki zgłaszać na piśmie. Wystarczy komentarz pod odpowiednim wątkiem w Redmine (system projektowy wykorzystywany w eVolpe).
W trakcie wdrożenia masz do czynienia zarówno ze sprzedawcą (Opiekunem Klienta) jak i analitykiem (w roli proxy Product Ownera) oraz programistami i testerami dbającymi o jakość kodu. Możesz liczyć na ich wsparcie konsultacyjne dotyczące działania wytworzonych funkcji. Scrum to zatem doskonały sposób na wypracowanie partnerskiej relacji z pracownikami firmy wdrożeniowej.
Pamiętaj! Stała kontrola jakości, harmonogramu oraz budżetu to przede wszystkim wymiana doświadczeń i spostrzeżeń między ludźmi. Dzięki częstej komunikacji wzrasta poczucie bezpieczeństwa i poziom zaufania do osób zaangażowanych w projekcie. Dzięki tym wszystkim rozmowom buduje się mocna relacja biznesowa. Co, chyba przyznasz, nie jest bez znaczenia.
Zalety zwinnej metodyki wdrożeniowej — podsumowanie
Mam nadzieję, że się za bardzo nie rozpisałem i użyłem zrozumiałego języka. Nie dało się uniknąć niektórych branżowych pojęć, ale liczę, że precyzyjnie je objaśniłem. Szczerze mówiąc, jeśli planujesz wdrożenie nowego oprogramowania w Twojej organizacji, z niektórymi lepiej się oswoić. Branżowy żargon ostatecznie sporo ułatwia, kiedy się już nim płynnie posługujesz.
Podsumowując główny wątek, mam nadzieję, że ten artykuł ostatecznie rozwiał wątpliwości dotyczące wyboru Waterfall vs. Agile. Nie chciałbym się zanadto powtarzać, ale niech to wybrzmi z całą mocą: Scrum i metodyka zwinna jako taka, to aktualnie jedyna słuszna droga realizacji projektów wdrożeniowych. Zalety współpracy w Scrumie, dotyczą przede wszystkim kwestii umownych, badania potrzeb, zasad wytwarzania oprogramowania, rozliczeń oraz otwartości na zmianę. Jeżeli masz do tego dodatkowe pytania, na dole znajdziesz kalendarz rezerwacji terminów na indywidualną konsultację z ekspertem. Zachęcam do skorzystania z tej opcji. Chętnie opowiem o moim doświadczeniu na tym polu we współpracy z klientami takimi jak: MAN Truck & Bus Polska, Mokate, Empik, NASK czy Contrain.
Do usłyszenia!
W eVolpe zajmuję się sprzedażą oprogramowania Open Source dla biznesu. Prawdziwą wartość systemów CRM dostrzegam w funkcjach pozwalających na analitykę danych. W rozmowach z moimi klientami często podkreślam, jak istotna jest skrupulatność wprowadzania informacji do systemu.
W razie pytań zapraszam do kontaktu. Jestem też na LinkedInie!
