Case Study – Analiza Porażki Projektu
Poruszę dziś temat historyczny (ale autentyczny) pewnego projektu, w którym uczestniczyłem kilka dobrych lat temu. Był to jeden z pierwszych projektów komercyjnych, w którym uczestniczyłem jako programista, w którym byłem jednocześnie leaderem zespołu.
W moich obowiązkach była komunikacja z biznesem i tworzenie harmonogramów. Oprócz tego również czynnie programowałem w projekcie i odpowiadałem za dobór technologii. Tynkarz, murarz, akrobata 😉
Opowiem Ci dzisiaj o tym jak niebezpieczna może być zmiana priorytetów projektowych i ciągłe naciskanie na terminy dostarczania oprogramowania.
Biznes Vs Deweloperzy
Przed dłuższy czas myślałem, że przyczyną porażki leżały w zespole deweloperskim, dziś jednak wiem, że było inaczej.
Sytuacja wyglądała tak, że znaliśmy generalny zakres projektu – nie było mowy o analizie. Powstało coś w rodzaju dokumentacji, ale brakowało w nim syntezy, czyli rozwiązania.
Jednak nie brak analizy okazał się najgorszy. Dużo bardziej niekorzystne okazał się brak planu projektu (ustalenia priorytetów projektowych).
Chodzi mi o przemyślenie biznesowe projektu i zaplanowanie go względem wydarzeń biznesowych skupionych wokół projektu oraz samego dostarczania funkcji użytkownikom – chyba nikt nie zastanowił się co będzie im najbardziej potrzebne.
Zmiana Priorytetów Projektu
Początkowe tygodnie realizacji przebiegały bez problemów – stawialiśmy szablon aplikacji, projektowaliśmy model. Przyjemne rzeczy.
Gdy mieliśmy około 10% zrealizowanego zakresu. Zaznaczę tutaj tylko, że projekt nie należał do najmniejszych. Estymata wynosiła prawie rok programowania zespołu kilku osobowego.
Kiedy mieliśmy wcześniej wspomniane 10%, dowiedzieliśmy się, że za kilka dni będą targi związane z branżą projektu i warto, żeby do tego czasu powstał dodatkowy landing page umożliwiający założenie konta, integrację z mediami społecznościowymi i zapraszanie znajomych. Typowa funkcjonalność na tego typu event.
Priorytety zespołu się zmieniły – zamiast skupić się na najważniejszym celu projektu czyli dowieźć funkcje końcowym użytkownikom, skupiliśmy się na czymś innym.
Nie udało nam się dowieźć dodatkowej aplikacji do zapraszania użytkowników, plan spalił się na panewce. Działała częściowo, ale nie na tyle żeby spełnić swoją funkcję czyli pozyskać użytkowników do wersji alfa.
Podwójna porażka bo oprócz palenia budżetu na dodatkową akcję zaczęło się generować opóźnienie względem całości projektu. Nie duże, ale jednak.
Takich sytuacji było jeszcze kilka – po kilkunastu tygodniach pracy, przez to „udało” nam się wygenerować prawie miesięczne opóźnienie.
Skróćmy Terminy, Będzie Szycbiej ¯\_(ツ)_/¯
Biznes próbując sobie z tym poradzić i „nadgonić” pracę narzucił nam jeszcze ciaśniejsze deadline. Chodzi o to, że jeśli mieliśmy na realizację modułu na przykład 6 tygodni, to został on skrócony do 4 tygodni.
Został skrócony jedynie termin dowiezienia projektu, zakres pozostawał ten sam. Amen.
Teraz po kilku ładnych latach jestem w stanie dokładniej zrozumieć ten absurd, jednak wtedy zespół był przerażony. Komunikacja pomiędzy biznesem, a zespołem przebiegała na zasadzie „wyrzutów”, że programiści opóźniają projekt. Trzeba pracować w soboty, a terminy realizacji skrócić.
Dziś pisząc ten wpis zadaję sobie pytanie „jak?, dlaczego?”.
Zespół po dwóch miesiącach był wypalony i najchętniej zmieniłby pracę. Robiłem co mogłem by dbać o morale zespołu, czasami wychodziło, czasami nie.
Przez to, że mieliśmy ciaśniejsze terminy, musieliśmy zaciągać dług technologiczny by zrobić te rzeczy szybciej. Zemściło się to na nas po kilku tygodniach kiedy musieliśmy cofać się poprawiając bugi w napisanych modułach. To potęgowało opóźnienie bo zamiast realizować nowe moduły, musieliśmy poprawiać stare. Never ending story.
Zmiana Priorytetów Projektowych Może Go Opóźnić
Pewnie zastanawiasz się dlaczego o tym piszę. Sytuacja, którą opisuję nie jest odosobniona. Takie projekty toczą się każdego dnia, dlatego chcę zaznaczyć jak ważny jest plan projektu.
Nie wiem jak dla Ciebie, ale dla mnie nie ma gorszego uczucia niż pracować cały dzień i mieć wrażenie, że nic się nie zrobiło. Bo cały czas wpada coś pilniejszego.
Tak w mikro skali wygląda zmiana priorytetów projektowych. Zespół często mieli kołami w miejscu. Nie chcę żebyś mnie źle nie zrozumiał – często zmiana priorytetów jest potrzebna, żeby dowieźć większą wartość biznesową. Chodzi mi tutaj o sytuacje, gdzie zmiany wynikają z braki zaplanowania i decyzje są podejmowane na zasadzie „jak zawieje wiatr”.
Presja Nie Sprawi, Że Prace Pójdą Szybciej
Pisałem już o tym kilkukrotnie. Presja, wywołanie stresu według intencji ma sprawić, że ktoś będzie pracował szybciej.
I rzeczywiście tak jest… tylko, że na krótką metę. W stresie pracujemy szybciej, ale nie pracujemy lepiej. Stres zabija kreatywność, nie wyszukujemy najlepszych rozwiązań. Sprawi jedynie, że będziemy wykonywać rzeczy mechanicznie szybciej.
Co o ile w przypadku fabryki się sprawdzi, o tyle w wytwarzaniu oprogramowania nie do końca.
Programowanie to praca kreatywna – każdy problem jest unikalny, wymaga indywidualnego podejścia. Wywierając presję na zespole sprawimy, że będą starali się ukończyć zadania szybciej… w gorszej jakości, z bugami, które będzie trzeba naprawić. Co oczywiście kosztuje czas.
Często pozwalając pracować wolniej (bez presji) kończymy projekt szybciej. Dlatego pisałem kilka zdań wcześniej, że wywieranie presji to podejście krótkodystansowe. Prędzej czy później wróci to do nas z dwojoną siła przez gorszą jakość wytwarzanego softu.
Nikt nie lubi pracować w stresie, istnieje więc ryzyko, że będziemy mieć duże rotacje w zespole, które też mogą przyczynić się do opóźnień.
Podsumowanie
Wbrew pozorom wolniej (bez presji), może znaczyć szybciej (finalnie). Wywieranie presji i stresu na zespole jest krótkowzroczne. Nikt na dłuższą metę nie będzie zadowolony z takiej pracy.
Szybsza praca pod wpływem stresu spowoduje gorszą jakość kodu, co wróci do Ciebie z zdwojoną siłą podczas testów lub integracji.
Bardzo ważne jest żeby przed rozpoczęciem projektu wyznaczyć jego priorytety i kierunek, w którym ma iść. Nie ma nic złego w zmianie priorytetów jeśli wynikają z przemyślanej strategii. Najgorzej jest jeśli działasz bez planu poniekąd „dryfując” co przyniesie los.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍
