Po co realizuje się projekty? – wartość biznesowa

Udostępnij

Tego tematu jeszcze u mnie na blogu nie było, ale zauważam, że jest bardzo potrzebny. Chodzi o pytanie PO CO REALIZUJE SIĘ PROJEKTY? Pewnie dla wielu osób było to pytanie retoryczne, bo przecież “wiadomo”. Spróbuj jednak zastanowić się nad odpowiedzią, zanim przeczytasz ten wpis.

wszystko ma swój cel… i zakres

Heh, wiem, że powtarzam to jak mantrę, ale powiem jeszcze raz: każdy projekt ma swój cel i zakres. Kluczowe jest, żeby określić te dwa parametry dla twojego przedsięwzięcia. Jeśli twój projekt nie ma celu, zastanów się czy na pewno warto go realizować. W większości przypadków kierownicy projektów dostają odgórne polecenie prowadzenia konkretnego projektu i często muszą uwierzyć na słowo, że zlecenie “z góry” ma jakiś głębszy sens. W każdym razie, projekt realizuje się po to, żeby wniósł wartość. Nie spotkałem się z przypadkiem, gdzie projekty realizuje się dla zabicia czasu, zazwyczaj po realizacji oczekuje się korzyści. Bardzo często (choć nie zawsze) tą wartością jest wartość biznesowa, która przekłada się na zyski.

Należy o tym pamiętać prowadząc projekt. Niby banalne, ALE…znam przypadki “z życia wzięte”, gdzie projekty się opóźniały właśnie przez brak rozumienia tej kwestii. Była to sytuacja, w której przykładano uwagę do jakości kodu. Odbywały się code review, każda wątpliwa linijka kodu była poprawiana. Jest to zacne i chwalebne 🙂 Jestem przekonany, że taką higieną kodu projekt byłby bardziej stabilny niż taki pisany “na kolanie”. Problem polegał na tym, że w pewnym momencie projekt zaczął się opóźniać względem harmonogramu. Natomiast wszelkie praktyki dotyczące jakości kodu zostały zachowane. Głównie chodziło o poprawianie kodu dobrego na “bardzo dobry” – przez co opóźnienie rosło. Efekt był taki, że projekt musiał zostać przerwany z powodu znacznego przekroczenia terminu (było to świetnie napisane 70% projektu 😉 ). Akurat w tym projekcie, data zakończenia nie mogła zostać przesunięta – kluczowe było, żeby wyrobić się na pewne wydarzenie (którego data była zaplanowana na sztywno). Po przekroczeniu tej daty projekt był bezużyteczny.

Nie twierdzę, że projekt opóźnił się przez nadmierną jakość kodu. Nie twierdzę również, że zostałby zrealizowany na czas gdyby w momencie opóźnienia zrezygnowano z code review. O powodu opóźnienia trzeba byłoby spytać kierownika projektu, wiem natomiast, że osoba prowadząca ten projekt nie miała jako głównego celu dostarczenia wartości biznesowej. Chciała zrealizować dobrej jakości projekt (był to cel kierownika, a nie projektu). Przez to nie skupiała się na tym co istotne.

Dla mnie myślą przewodnią podczas prowadzenia projektu, jest jego cel – w większości przypadków wartość biznesowa. Skupiam się więc na tym by ją dowieźć – nawet kosztem jakości rozwiązań. Nie boję się zaciągnąć dług technologiczny, bo wiem, że jeśli dowiozę wartość biznesową to znajdą się środki by spłacić dług technologiczny. Jeśli skupiłbym się na innych rzeczach (np jakość kodu) mogłoby dojść do sytuacji jak z przykładu, miałbym świetnie napisane 70% projektu, które trzeba byłoby wsadzić do kosza. Jakość kodu jest tylko jedną z rzeczy, na której można się nadmiernie skupić – podałem to tylko jako przykład. Wiem też, że bardzo trudne jest znalezienie złotego środka pomiędzy jakością rozwiązania a terminem ukończenia. Nie chodzi mi absolutnie o to, aby tworzyć projekty “kodem spaghetti” – trzeba dobrać odpowiednią jakość, która będzie wystarczająca dla użytkowników. Może się zdarzyć, że użytkownikom dodatkowe 2-3s na zapytaniu nie zrobią większej różnicy, a nam mogą znacznie przyśpieszyć czas realizacji. Wszystko musi być wymierne, trzeba znaleźć wcześniej wspomniany złoty środek.

Podsumowanie

Prowadząc projekt, twoją myśl przewodnia powinna być zbieżna z faktycznym celem projektu. Bardzo często będzie to wartość biznesowa projektu, w takim przypadku warto odpuścić własne cele projektowe (jak np chęć dbania o nadmierną jakość kodu). Słowem klucz jest “nadmierna” jakość kodu. Projekt, którego jakość kodu jest nieakceptowalna będzie bezużyteczny bo nie spełni swojej funkcji biznesowej. Musisz znaleźć złoty środek, by wartość projektu była wymierna.


Jeśli wpis ci się spodobał, udostępnij go lub śledź mnie na facebooku, twitterze, LinkedIn lub subskrybuj mój kanał na YouTube – twoja interakcja motywuje do dalszego pisania! Jeśli interesują cię podobne treści, dopisz się do newslettera (na górze strony) :).


Udostępnij

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *