W eVolpe doradzam na temat oprogramowania dla korporacyjnego biznesu. Prawdziwą wartość systemów CRM/CX 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. Szczególnie, jeśli zakładacie zastosowanie mechanizmów sztucznej inteligencji. Z tym także z przyjemnością pomogę.
W razie pytań zapraszam do kontaktu. Jestem też na LinkedInie!
- Umowa wdrożeniowa. Zapisy, które zabezpieczą interesy klienta - 11 grudnia 2024
- Dlaczego polscy przedsiębiorcy upodobali sobie systemy IT On-Premise? - 24 września 2024
- Open Source CRM – dlaczego sprawdza się w dużych firmach? - 11 września 2024
Jeśli nie znasz Scruma, albo potrzebujesz go objaśnić swoim kolegom i koleżankom z firmy – poniżej znajdziesz gotową instrukcję prowadzenia zwinnych projketów wdrożeniowych.
Przy okazji wyjaśniam, w czym tkwią pułapki tradycyjnego podejścia.
Pozbawione kontekstu hasła takie jak: Fixed Price czy Waterfall, niejednego zwiodły na manowce.
Sprawdź, jak się przed tym uchronić.
Waterfall – w czym tkwi problem?
Jeżeli zastanawiasz się akurat nad wyborem metodyki wdrożeniowej, bo za pomocą nowego oprogramowania chcesz umacniać swoją firmę – 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.
Waterfall to tradycyjna metodyka wdrożeniowa.
Przy jej pomocy, czyli „kaskadowo” realizowało się projekty IT u ich zarania. Umawiano się wtedy 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 czynniki, które wpływają na szybkie tempo dezaktualizacji przyjętych założeń. Także w obszarze prowadzenia przedsiębiorstwa oraz projketów Software Development.
Wady projektów bazujących 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, czyli elastyczne podejście 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ę od razu na praktyce tego podejścia.
#1 Zabezpieczenie interesów klienta
Po pierwsze umowa wdrożeniowa!
Ustalamy w niej warunki dalszej współpracy. Na jej mocy możesz się też 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 tym też jesteś 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
Zanim rozpoczną się prace deweloperskie, należy się jeszcze 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 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 też 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.
To bardzo odpowiedzialna rola. Powołanie do tego zadania kogoś zaufanego i decyzyjnego sprzyja sukcesowi całego przedsięwzięcia.
Product Owner Quiz
Sprawdź, kto z Twojej firmy nadaje się na koordynatora projektu wdrożeniowego.
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 oferuje Ci w ogóle taką możliwość. Masz szansę się zaangażować. Jeśli z tego korzystasz, otrzymasz narzędzie, z którego wszyscy będą 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 biznesowych 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 wykorzystane 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 była to tylko prognoza.
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 też 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 doświadczeniach we wdrażaniu oprogramowania z klientami takimi jak: MAN Truck & Bus Polska, OSHEE, Empik, NASK czy Bricoman.
Umów konsultację z ekspertem wdrożeniowym eVolpe
Wybierz dogodny dla siebie termin.
W eVolpe doradzam na temat oprogramowania dla korporacyjnego biznesu. Prawdziwą wartość systemów CRM/CX 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. Szczególnie, jeśli zakładacie zastosowanie mechanizmów sztucznej inteligencji. Z tym także z przyjemnością pomogę.
W razie pytań zapraszam do kontaktu. Jestem też na LinkedInie!
- Umowa wdrożeniowa. Zapisy, które zabezpieczą interesy klienta - 11 grudnia 2024
- Dlaczego polscy przedsiębiorcy upodobali sobie systemy IT On-Premise? - 24 września 2024
- Open Source CRM – dlaczego sprawdza się w dużych firmach? - 11 września 2024
