Wprowadzenie do podcastu i założenia tematu.

Cześć, dzień dobry. Witam Was w podcaście IT i Biznes. Nazywam się Grzegorz Tabor i na co dzień prowadzę trzy firmy, w tym firmę programistyczną, agencję doradczo-rekrutacyjną i SaaS do monitoringu cen konkurencji dla e-commerce.Podcast IT i Biznes kieruje do właścicieli firm oraz menadżerów, którzy na co dzień współpracują w swoich firmach często i dużo z szeroko pojętym IT i chcieliby realizować owe projekty IT bardziej świadomie i skuteczniej. Odcinek 49. Czy Scrum zawsze działa? O zwinności bez kierunku, czyli dlaczego Twój projekt IT może utknąć mimo dobrego procesu.

Scrum to jeden z najczęściej wybieranych frameworków czy metodyk w świecie IT, ale czy zawsze przynosi on realną wartość? W tym odcinku opowiadam o tym, dlaczego projekty IT potrafią utknąć mimo zastosowania metodyki zwinnej. Zastanowimy się, co może pójść nie tak, kiedy brakuje Ci strategicznego spojrzenia i dobrego połączenia biznesu, technologii i architektury IT. To odcinek dla tych, którzy chcą więcej niż tylko książkowego Scruma.

Nie przedłużając, serdecznie zapraszam do części głównej dzisiejszego odcinka. Cześć, dzień dobry. Witam Was serdecznie w ten poświąteczny wtorek.

Mam nadzieję, że naładowaliście już swoje baterie i jesteście gotowi na kolejną dawkę wiedzy o połączeniu biznesu i IT. Dzisiaj przyjrzymy się jednej z metodyk, czyli Scrumowi, ale spokojnie, nie będziemy tutaj teoretyzować sposobu funkcjonowania czy działania tej metodyki. Spojrzymy trochę na Scruma z nieco szerszej perspektywy.

Raczej przyjrzymy się temu, co się dzieje w realnych projektach, szczególnie tych bardziej skomplikowanych, gdzie integrujemy systemy, budujemy duże rozwiązania dedykowane albo przekładamy procesy firmowe na technologię.

Scrum czyli skąd się wziął i jakie problemy miał rozwiązać?

No dobra, ale zaczynając tak naprawdę od początku, skąd ten cały Scrum i dlaczego ma aż tylu, nazwijmy to wyznawców? No właśnie, Scrum dziś to hasło tak naprawdę zna niemal każdy, kto choć trochę otarł się o świat IT. Scrum pojawił się w latach dziewięćdziesiątych jako odpowiedź na bardzo konkretne problemy, wówczas widoczne, czyli sztywne, nieelastyczne podejście do zarządzania projektami.

Był on w pewnym sensie odpowiedzią na tak zwany model kaskadowy, który z góry zakładał wszystkie etapy, wszelkie cele z wyprzedzeniem, no z teoretycznie jasnym harmonogramem i zakresem pracy. Tyle, że w świecie oprogramowania czy IT dość często zmieniają się różne rzeczy, nawet z tygodnia na tydzień. No i z uwagi na to, że tak się też działo w latach dziewięćdziesiątych, no to model kaskadowy bardzo rzadko działał, no bo zawsze szukano kompromisu między tym, co trzeba zrobić, co było planowane kontra za ile to zrobić, w jakim czasie.

Model kaskadowy vs. zwinność – co poszło nie tak?

No bo jeżeli mamy sztywny harmonogram, sztywny termin i jednocześnie mamy sztywny budżet, no to musimy zarządzać ewentualnie zakresem, czyli go albo zmniejszać od strony funkcjonalnej, albo od strony jakości wykonania, jeżeli chcemy utrzymać jedną z tych wartości. No nie da się utrzymać wszystkich naraz tak naprawdę, szczególnie przy dużych projektach, to zaznaczam, bo oczywiście przy małych projektach jesteśmy w stanie praktycznie każde ryzyko przewidzieć, albo przynajmniej zdecydowaną większość większych ryzyk. Przy dużych projektach natomiast nie wszystko da się przewidzieć, więc z reguły w modelu kaskadowym szukano kompromisów i to się zwyczajnie nie sprawdzało.

Projekty trwały dłużej niż były zakładane, były realizowane w niewłaściwy sposób, czyli nie do końca dowożone funkcjonalnie w 100%, lub co gorsza też brano po prostu tutaj poprawkę na jakość i tej jakości też od strony nawet kodu architektury zwyczajnie nie dowożono, co przekładało się na kiepskie wdrożenia, mówiąc wprost. 

Zalety Scruma – iteracyjność, feedback i elastyczność

No i Scrum wprowadził tutaj do projektów coś nowego, czyli coś co dawało taką dużą elastyczność, zwinność, szybkie iteracje i częsty feedback, czyli podejście, które pozwalało też w pewnym sensie uczyć się w trakcie trwania projektu, a nie dopiero na jego końcu. Z tą nauką oczywiście część osób będzie myślała o tym, że przecież ja nie płacę za to, żeby ludzie uczyli się w trakcie trwania mojego projektu, natomiast tutaj z tą nauką przede wszystkim chodzi o takie częste feedbackowanie się między biznesem a IT, czyli dużo lepiej jest po tygodniu czy dwóch tygodniach pracy, czyli po takim czasie jaki z reguły trwa sprint, czyli jakiś określony zakres prac, zfeedbackować się, że na przykład jakaś jego część tego zakresu nie została wdrożona dobrze, albo że nie o to nam chodziło od strony biznesu, niż zrobić to samo, ale na większym zakresie prac dopiero po pół roku.

Bo może się okazać, że w tym drugim przypadku zrobimy to zwyczajnie za późno, no i nie wiem, jakaś większa część projektu będzie zwyczajnie do przerobienia, co będzie generowało dodatkowe koszty i dodatkowe niepotrzebne złe emocje. No i dzisiaj Scrum jest tak naprawdę jedną z najpopularniejszych i też z reguły najchętniej stosowanych metod prowadzenia projektów IT. Czasem nawet mam wrażenie, że jest to w pewnym sensie taka wyznawana metodyka, no bo powstały o nim niezliczone książki, blogi, kursy, certyfikaty, szkolenia.

Gdzie Scrum zawodzi - pułapki zwinności bez strategii.

Czasem można nawet odnieść wrażenie, że Scrum stał się w pewnym sensie bardziej ruchem kulturowym niż tylko metodyką wdrażania projektów IT. I tutaj też, żeby była jasność, ja generalnie uważam, że Scrum w swoich założeniach jest OK i często korzystam przynajmniej z większości ceremoniałów i jakby też zasad, struktury, jakie Scrum wnosi i często też polecam zwinne podejście do tworzenia projektów. Natomiast co do zasady, nie jestem bardzo za tym, żeby to traktować jako metodykę, rozwiązanie na wszystko i absolutnie nie jestem zwolennikiem tego, żeby Scrum był wytłumaczeniem na to, że projekt nie jest dowiaziony na przykład w terminie albo zgodnie z założeniami, bo często w wielu firmach tak to wygląda, że Scrum jest stosowany trochę dla zasady, trochę dla sztuki.

Zespoły trzymają się tego frameworku, tej metodyki bardzo książkowo, krok po kroku, zgodnie z teorią. Ale wtedy powstaje prowadzenie projektu dla Scruma, a nie Scrum wspierający dowożenie projektu, no bo często właśnie tego typu firmy, osoby zapominają o tym, co w Scrumie jest najważniejsze, czyli o dostarczaniu wartości i ciągłym doskonaleniu procesu. Czyli co do zasady zakłada się w Scrumie, że po danym tygodniu, dwóch, czyli po danym sprincie powinniśmy mieć jakiś określony obszar zamknięty i on już powinien dostarczać wartość biznesową.

Jeżeli tego konkretnego założenia nie będziemy mieli w naszym życiu w podejściu zwinnym, no to wówczas będziemy płynąć z zakresem aż miło, no i koniec końców temat nie będzie dowieziony na czas.

Strategia jako warunek skutecznego wdrażania Scruma.

I w dalszej części tego odcinka chcę opowiedzieć o tym, jak nie wpaść w pułapkę takiej Scrumowej teorii, takiej sztuki dla sztuki, jak działać zwinnie, żeby naprawdę mieć wartość z tego zwinnego wdrożenia, no i kiedy ten model niekoniecznie jest najlepszym rozwiązaniem. No i też skupię się na tym, kiedy ten Scrum może nie działać, tak żebyś mógł, drogi słuchaczu bądź droga słuchaczko, wyciągnąć z tego jakieś wnioski i inspiracje dla siebie.

Dobrze, w takim razie rozkładając na czynniki pierwsze metodologię Scruma. Z jednej strony mamy tę elastyczność i zwinność, które są oczywiście ogromną zaletą, ale jednocześnie mogą być też wadą, no bo jeśli nie trzymamy projektu w ryzach, to ta elastyczność może sprawić, że projekt zaczyna żyć w pewnym sensie własnym życiem. Zaczyna się od małych zmian, poprawek, które są niby do ogarnięcia, a potem mamy całą masę nowych rzeczy w backlogu, które niby dodają wartość, ale już nie wiadomo jaką.

I zamiast sfinalizować projekt, który często rozumuje się jako coś, co niekoniecznie ma dobre założenia, no bo przecież będziemy pracować w Scrumie, więc będziemy wypracowywać rzeczy na bieżąco. Jeżeli nie mamy takiej sytuacji, w której finalizujemy też dobrze poszczególne etapy, to w pewnym sensie, w cudzysłowie, wkręcamy się w kolejne zmiany, które się nigdy nie kończą. No i wtedy, jeżeli biznes widzi, że może dodawać kolejne rzeczy, to je dodaje.

Zespół, jeżeli nie panuje dobrze nad backlogiem, czyli nie robi dobrego procesu tzw. refinementu tego backlogu, to też niekoniecznie dobrze odpowiada na pytanie, czy to powinno być uwzględnione np. w pierwszym takim większym etapie, z którego składa się kilka sprintów w tym zakresie prac.

Efekt „Scrum dla Scruma” – jak stracić kierunek

No i z kolei właśnie później to nie wychodzi i mimo, że zespół działa super zwinnie, powiedzmy technicznie można powiedzieć książkowo, to nikt nie zadaje sobie pytania, co to zmienia w biznesie, albo czy użytkownik końcowy rzeczywiście tego potrzebuje. Czyli nie zastanawiamy się nad tym, czy to jest potrzebne w tym podstawowym zakresie, albo czy użytkownik końcowy faktycznie czegoś potrzebuje, tylko często jest tak w tego typu zespołach niestety, co wynika też z moich obserwacji gdzieś tam w różnych projektach, czy to odbieranych, czy prowadzonych też jako CTO na godzinę, że zespoły często zapominają o tym, że na koniec dnia chodzi o to, żeby projekt od strony technicznej spełniał założenia i cele biznesowe. Nigdy na odwrót.

I teraz te drobne poprawki czy zmiany, które się pojawiają i które rozbudowują projekt wynikają z jednego ważnego czynnika. Z reguły zwyczajnie w świecie nikt nie pilnuje tego długoterminowego kierunku. No bo często osoba odpowiedzialna za projekt, czyli w większości przypadków to jest product owner, jest zbyt pochłonięty szczegółami.

Czyli często funkcjonalności, które są dostarczane na sprintach, choć poprawne i które spełniają swoją rolę, są skierowane do ewentualnych zmian. Czyli zbyt często skupiamy się na idealizowaniu jakiejś funkcjonalności zamiast skupić się na samej funkcji, która ma ta dana funkcjonalność realizować. Czyli tutaj zbyt drobiazgowe podejście do projektu sprawia, że zapominamy często co ma być celem projektu na dłuższą metę.

Studium przypadku – jak drobiazgowość niszczy projekt

To też jest tak, że na przykład zespoły od strony technicznej bardzo często lubią, to jest niestety taki zły nawyk, że zespoły od strony technicznej, szczególnie w pierwszych sprintach, lubią bardzo długo idealizować podstawę projektu. Kiedyś miałem okazję brać udział jako taki zewnętrzny programista, jako jeden z iluś programistów właśnie w tego typu projekcie, gdzie przez dwa lub trzy sprinty, jeżeli dobrze pamiętam, co najmniej dwa, ale z tego co pamiętam jeszcze kawałek trzeciego, była realizowana dopiero podstawa aplikacji, którą normalnie dałoby się zrobić w dwa, trzy dni robocze takim zespołem, jakim działaliśmy. Natomiast przez to, że ciągle Tech Lead miał poczucie, że jeszcze zmieńmy coś, jeszcze coś poprawmy, jeszcze coś dodajmy, a jeszcze brakuje nam takiego systemu do logowania, a takiego systemu do kontroli jakości kodu, a jeszcze czegoś, to powodowało, że na koniec dnia biznes miał poczucie, że nie idzie w ogóle do przodu, no bo przecież biznes wie, że ma być realizowana podstawa aplikacji i ją trzeba zrobić, żeby w ogóle wystartować.

No a z drugiej strony właśnie te takie drobne rzeczy, idealizowanie wszystkiego już na samym początku, chociaż wcześniej nie było to tak przewidziane, powodowało, że no zwyczajnie w świecie projekt z perspektywy biznesowej kompletnie nie szedł do przodu. No niestety tamten projekt po dwóch miesiącach tego typu działań został zakończony przez biznes i w cudzysłowie schowany do szuflady, no ale wynikało to przede wszystkim z tego, no że biznes nie widział kompletnie wartości w tym, co jest zrealizowane w tym projekcie versus budżet, jaki ten projekt pochłaniał i versus termin, jaki gdzieś tam był zakładany, przynajmniej orientacyjny, bo pamiętajmy też o tym, że mimo, że realizujemy projekt od strony, znaczy korzystając z metodyki zwinnej, to nie może to być wymówką na to, że projekt nie będzie dowiedziony na określony termin czy czas. Oczywiście trzeba mądrze zarządzać backlogiem tego produktu i tego projektu, no i dobrze wiedzieć, w jaki sposób będziemy czerpać z tego projektu później, żeby dobrze dobierać też funkcjonalności, które są do zrobienia, ale to nie oznacza, że projekt ma kompletnie płynąć, bo zwinnie nim zarządzamy.

Absolutnie nie. No i często dzieje się tak dlatego, że brakuje osoby, która będzie spinała to w pewnym sensie z poziomu biznesu, technologii i architektury. Czyli Scrum będzie działał świetnie, kiedy mamy jasno wyznaczone role, ale często będzie działał źle, kiedy brakowało będzie tej kluczowej osoby, która zespaja wszystko, czyli ten biznes, technologię i architekturę.

I w większych projektach, gdzie trzeba łączyć różne obszary, np. wymagania biznesowe z technologicznymi ograniczeniami, brak tego typu osoby może doprowadzić do tego, że zespoły zaczynają działać kompletnie na własną rękę, bez koordynacji, bez też komunikacji z biznesem, czyli przyjmując pewne założenia, że skoro mamy 3 miesiące na realizację pierwszego etapu prac, co nam się przekłada na 6 sprintów, no to po prostu działamy mniej więcej z backlogiem, który został rozpisany. No a to, że się pojawiają nowe rzeczy, dodatkowe rzeźbienie czegoś bez kontroli biznesu bardzo często wymyka się spod kontroli.

Dlaczego potrzebujesz osoby łączącej biznes, technologię i architekturę?

I może się zdarzyć, że zespół IT koncentruje się właśnie na implementacji np. najnowszej technologii, czy właśnie idealizacji tej podstawy danej aplikacji, podczas gdy nie bierze pod uwagę np. tego, czy to w ogóle pasuje do długoterminowej strategii firmy.

Albo np. zespół biznesowy zmienia co chwilę kierunek, ale nie zdając sobie sprawy, że technologia, którą już wdrożono, nie będzie np. w stanie sprostać tym wymaganiom, ale zwyczajnie w świecie brakuje nadzoru takiej osoby, często tę rolę pełni np.

dyrektor technologiczny, która to osoba będzie dbała o spójność całości i dopilnuje, by biznes, technologia i architektura nie szły w różnych kierunkach. No i właśnie odpowiadając na pytanie z początku odcinka, jak działać w Scrumie, żeby naprawdę mieć wartość, pamiętajcie tutaj o tym, że Scrum to jest tylko metodyka prowadzenia projektu i to, co musi się zadziać przed to strategia, która jasno określa nam jaką wartość, czy jaki cel biznesowy ma dany projekt, przeradzający się w produkt nam realizować. Scrum będzie działał najlepiej, kiedy zespół będzie rozumiał po co coś robi, czyli jakie jest dlaczego dla tego projektu.

Backlog będzie wynikał ze strategii, a nie tylko z pomysłów wrzucanych na bieżąco. No i jeśli jest ktoś, kto potrafi połączyć świat technologii i biznesu i kiedy ten ktoś wie, kiedy powiedzieć stop to nie ma sensu, albo teraz kluczowe jest zupełnie coś innego. No i teraz właśnie a propos tej strategii.

Brak strategii? B2B nie zadziała bez dobrego pytania „DLACZEGO”

Bardzo często spotykam się w firmach też z czymś takim, że Scrum jest lekarstwem w pewnym sensie na wszystko, czyli tak, z jednej strony firma nie ma jakiejś takiej spisanej strategii biznesowej, z drugiej strony firma odczuwa jakieś bóle i jakieś wyzwania, czyli firma chce jakieś procesy sobie na przykład poprawić. Z trzeciej strony te procesy funkcjonują tylko w głowach ludzi, którzy za te procesy odpowiadają. Czyli na przykład dział handlowy wie jak mniej więcej dzieje się sprzedaż krok po kroku, ale jeżeli na przykład zapytamy o formę dokumentacji w jaki sposób ten dział handlowy faktycznie działa, no to okazuje się, że nigdzie to nie jest spisane, nigdzie ten proces nie jest narysowany, nigdzie nie są zmapowane najważniejsze rzeczy na co zwrócić uwagę w tym procesie, na każdym kroku jakieś porady jak przejść dalej na przykład w tym procesie.

Tego typu rzeczy zwyczajnie w świecie nie ma, bo tutaj bardzo często w firmach stosuje się uproszczenie, że jeżeli jest na przykład dyrektor handlowy odpowiadający za dział handlowy, no to ten dyrektor ma zarządzać czasem i kompetencjami w swoim zespole właśnie dla tych osób, no i kropka, no i zarząd przyjmuje założenie, że oczywiście tak powinno być i tutaj nie zastanawia się jakoś głębiej nad tym. I teraz bardzo często okazuje się, że firmy przychodzą na przykład do software house'u i chcą zlecić na przykład platformę B2B. No i teraz chcą zlecić tą platformę B2B, bo z ich perspektywy, czyli z perspektywy tej firmy, to jest rozwiązanie technologiczne, które powinno odpowiedzieć na konkretne bóle w ich biznesie, czyli ma odpowiedzieć na problem, że do danego handlowca jest przypisana określona grupa klientów i jest przyzwyczajona ta grupa klientów do kupowania u danego handlowca, co powoduje, że dany handlowiec na przykład zdobywa tych klientów w formie prospectingu, takiej proaktywnej sprzedaży po raz pierwszy, a potem ci ludzie zwyczajnie świecie z uwagi na relacje składają u tej osoby zamówienia.

No i mają z nim jakąś relację, dzięki jego doradztwu i konsultacjom składają tych zamówień na przykład więcej, bądź mniej lub mają wyższą wartość koszyka, czyli generalnie co do zasady proces sprzedaży działa, ale jest mocno oparty o konkretnego handlowca, czyli na tym handlowcu mamy tak zwany buzz factor, czyli taką dużą odpowiedzialność i teraz w momencie, kiedy ten handlowiec idzie na urlop albo odchodzi z firmy, okazuje się, że nagle sprzedaż spada, no bo siłą rzeczy, jeżeli ten handlowiec jest niedostępny, a ludzie są przyzwyczajeni do kupowania wraz z nim czy u niego, no to zwyczajnie świecie nie kupują na przykład, albo wysyłają zamówienia dużo mniejsze, bo kupują tylko to, gdzie już muszą coś kupić, a w pozostałych przypadkach czekają na tego konkretnego handlowca. No i teraz na tego typu postawiony problem, firma może znaleźć rozwiązanie właśnie w postaci, zróbmy platformę B2B, niech ona będzie dopasowana i po prostu wdrożona do firmy, wtedy handlowcy niech sobie rotują, platforma B2B będzie spełniać ich założenia. Tylko teraz jest pytanie, czy platforma B2B na pewno będzie się wspinała ze strategią całą firmę, bo może się okazać, że firma może podjąć inne działania, czyli na przykład firma może zadbać o swój magazyn, żeby wysyłał zamówienie jeszcze szybciej.

Firma może na przykład dać użytkownikom jeszcze inną formę składania zamówień, bo teraz, czy handlowca łatwo zastąpić platformą B2B? Niekoniecznie, bo może się okazać, że ten klient na przykład zamawia produkty posługując się jakimiś różnymi sloganami, albo zwyczajnie w świecie używa po prostu zwrotów, które są znane w danej branży i na przykład oznaczają jakiś ogólny przedmiot, typu ktoś chce kupić, nie wiem, przyjmijmy skrót, czyli chce ktoś kupić na przykład krzesło, przyjmijmy, że to jest firma meblowa i potrzebuje uzupełnić swój stok od hurtowni, ale niekoniecznie się zastanawia, jakie po prostu krzesło biurowe i potrzebuje 10 krzeseł biurowych na już. No i teraz w platformie B2B dochodzi ten aspekt doboru konkretnego krzesła, konkretnej firmy o konkretnych parametrach, gdzie handlowiec byłby w stanie takie krzesła zarekomendować znając firmę, której sprzedaje. Czyli mam na myśli to, że handlowiec w pewnym sensie przyjmie uproszczenie człowieka w jego procesie zakupu, że potrzebuje 10 krzeseł biurowych na już versus platforma B2B, która będzie jednak taką formą właśnie platformy, gdzie trzeba wyszukać różne krzesła, zastanowić się, porównać parametry, czyli ten proces zakupu będzie wyglądał zupełnie inaczej w obu tych przypadkach.

I teraz, jeżeli do czego dążę? Jeżeli tą platformę B2B będziemy chcieli zlecić na zewnątrz bez uprzedniego zastanowienia się, jak strategicznie ona wpływa na nasz biznes, czyli jakie obszary taka platforma czy tego typu rozwiązanie technologiczne powinno spełniać, to już na dzień dobry popełnimy bardzo duży błąd, który później generuje duży dług i trudno go spłacić. To znaczy, już na dzień dobry przyjmiemy sobie błędne założenia. I teraz, jeżeli nie będziemy tutaj mieli założenia, które jest właśnie strategiczne, czyli że platforma B2B musi, jeżeli ma zastępować w cudzysłowie handlowca albo po stronie klienta, ma spowodować, że klient chętniej dokona zakupu na tej platformie, a nie u tego konkretnego handlowca, nawet jeżeli on będzie dostępny, to musimy bardzo mocno zastanowić się nad tym, co ta platforma może dać temu użytkownikowi jako taką wartość dodaną, żeby ten użytkownik wybrał taką platformę do stałych, cyklicznych zamówień, a niekoniecznie tego handlowca.

No i jednym z przykładów może być to, że ktoś np. robiąc zamówienia na tego typu krzesła, które podałem w przykładzie, sprawdza sobie np. na koniec dnia ile tych krzeseł ma i teraz w momencie, kiedy widzi, że ma ich za mało, no to zwyczajnie mówi np.

do telefonu, czyli robi takiego trochę voice searcha czy voice order. Potrzebuje 10 krzeseł biurowych, 10 krzeseł stołowych i 3 krzesła kuchenne. No i aplikacja sama mu wtedy pokazuje, jakie ma krzesła na stanie, ale już tak konkretnie wybierając pod tą konkretną też firmę, znając wcześniejsze preferencje zakupowe tego klienta, bo on zamawia już po raz kolejny np.

te krzesła. No i teraz on po prostu jest w stanie od ręki sobie wybrać te krzesła, kliknić złóż zamówienie i zrobić to o godzinie 23, kiedy jego handlowiec byłby niedostępny i tych produktów zwyczajnie nie byłby w stanie mu sprzedać. I teraz, gdybyśmy z takim nie przeszli przez cały ten proces, przez cały ten tok myślowy i nie zastanowili się jak strategicznie ten dany produkt, dany projekt będzie wpływał na naszą firmę i na naszych klientów w tym wypadku, czyli tych użytkowników końcowych, wówczas mimo, że realizowalibyśmy projekt zwinnie, to bardzo szybko doszlibyśmy do ściany w postaci takiej, że wdrożyliśmy nową platformę, ale ludzie dalej kupują u handlowców.

Dlaczego? I to jest właśnie kluczowe w tym, że bardzo często firmy przyjmują uproszczenie, idą do software house'u, mówią, że chcą platformę B2B. Software house'y nie pytają dlaczego ta platforma B2B, tylko pytają jakie ma mieć funkcjonalności, na czym ci najbardziej zależy i zaczynamy wchodzić już w szczegóły specyfikowanie zakresu. 

Wchodzisz po drabinie… ale czy przystawiłeś ją do właściwego budynku?

Potem wchodzimy w realizację projektu w Scramie i to jest tak jakbyśmy porównali sobie do tego, że wchodzimy po drabinie, wchodzimy, wchodzimy i to jest ta realizacja projektu w Scramie i nagle okazuje się, że tak, pojawia się dodatkowe piętro, kolejne piętro, jeszcze inne piętro.

Piętra, których nie widzieliśmy z dołu, ale wchodząc po drabinie one się nagle uwidaczniają. Ta drabina nam się robi coraz większa, coraz większa, coraz wyższa w tym sensie, że nie wiemy gdzie będzie koniec. Jesteśmy przerażeni, bo jesteśmy już bardzo wysoko i już naprawdę nie widać nawet tej ziemi, z której stawaliśmy.

Jest masa czasu już na to przepalona i nagle okazuje się, że ten projekt to nie był ten projekt, którego potrzebowaliśmy. Bo my potrzebowaliśmy prostego asystenta AI na stronie w formie chatbota, który szybko doradzi produkty, a zleciliśmy zbudowanie nowej platformy B2B, bo stara np. nie sprzedaje albo zwyczajnie nie mieliśmy tej platformy.

I mamy drabinę, a tylko, że przystawioną do złego budynku. I do tego tutaj chciałbym zmierzać, jeżeli chodzi o podsumowanie tego odcinka, że to nigdy nie jest tak, że jedna metodyka jest lepsza, a inna gorsza, tylko super ważne jest to, żeby w złożonych projektach informatycznych mieć to poczucie, że ten projekt, który chcemy zrobić, on faktycznie ma założenia też i podwaliny od strony biznesowej, czyli co nam to da faktycznie, że ten projekt wdrożymy, jakie są najważniejsze aspekty tego, żeby ten projekt zrealizować i dopiero mając te założenia, możemy projekt realizować zwinnie w kontekście dostosowywania na bieżąco zakresu funkcjonalnego, weryfikacji co tydzień, czy co dwa postępów, czy idziemy w dobrym kierunku i teraz jak weryfikować, czy idziemy w dobrym kierunku, czy jesteśmy bliżej celu biznesowego, który ma nam ta dana technologia pokryć, po prostu. 

Podsumowanie – nie chodzi o metodykę, tylko o sens

I podsumowując dzisiejszy odcinek, na pewno ważne jest to, żeby nie skupiać się tak bardzo na tej metodyce, co bardziej na tym, co my tak naprawdę chcemy zrobić i jak to się przełoży na nasz biznes.

Jeżeli to już będzie przemyślane, wówczas powinniśmy dopiero wtedy zastanowić się nad metodyką i tutaj też zachęcam do tego, żeby przesłuchać odcinek 17 pod tytułem Scrum, Kanban albo Waterfall Która metodyka najbardziej opłaca się biznesowo? Dam link do tego odcinka też w opisie z uwagi na to, że on właśnie trochę bardziej już opowiada o tym, jak podejść stricte do pojedynczego projektu. Ja tylko tutaj chciałbym was zostawić z myślą przede wszystkim, żebyście się zastanowili nad kontekstem, w jakim działacie, nad potrzebami i nad tym, kogo macie w swoim zespole, nad tymi celami biznesowymi i nad tym, żeby mocno, mocno przemyśleć, jakie projekty albo jakie etapy projektu powinny być wdrożone, żeby wasz cel biznesowy jak najszybciej pokryć. I do tego was serdecznie zachęcam, bo często to nie tak, że brakuje zwinności, tylko brakuje jasnego kierunku i kogoś, kto ten kierunek pomoże wam utrzymać.

Na koniec, zaproszenie do rozmowy

Jeżeli czujecie, że przydałaby się rozmowa o tym, co u was gra, co nie gra, jak to poukładać, to jak zawsze ja serdecznie zapraszam na kawkę, może być na żywo, może być wirtualna, ale co, pogadamy, przeanalizujemy rzeczy i zobaczymy zwyczajnie, co można zrobić lepiej w waszych projektach albo w tym, jak pokryć lepiej wasze cele biznesowe. Dzięki serdecznie za dzisiejszy odcinek i do usłyszenia za tydzień we wtorek. Cześć!

‍