Menedżer, podobnie jak analityk biznesowy czy Product Owner, pełni rolę “lokomotywy”, ponieważ odpowiada za kierowanie procesem we właściwym kierunku. Aby skutecznie “doprowadzić” projekt IT do właściwego punktu, menedżerowi pomaga charyzma, umiejętności zarządzania i wiedza techniczna. Absolutnym minimum jest nauczenie się, jak działać w oparciu o znajomość standardowego cyklu życia oprogramowania.
Na początku kariery taka podstawowa wiedza techniczna jest wystarczająca, ale w miarę dalszego rozwoju menedżer jest odpowiedzialny nie tylko za koordynowanie działań zespołu, ale także za osiąganie celów. Aby stworzyć produkt wysokiej jakości w określonym czasie, menedżer będzie potrzebować głębszego zrozumienia aspektów technicznych, co wymaga zaznajomienia się z architekturą.
Oto trzy główne korzyści, jakie czekają na PM, BA i PO, jeśli zaczną bardziej zagłębiać się w procesy architektoniczne.
1. Dogadanie się z architektem
Dobra architektura leży w najlepszym interesie klienta i zespołu: łatwo ją rozbudowywać, zmieniać, testować, debugować, a w miarę wzrostu poziomu złożoności i rozmiarów, aplikacja nadal działa szybko i płynnie.
W przypadku większych projektów, architekturą zajmuje się specjalista na stanowisku architekta rozwiązań, i wydawać by się mogło, że ta opcja jest dla menedżera łatwiejsza. Jest jednak “minus” tej sytuacji: często zdarza się, że architekt rozwiązań myśli, że zadaniem menedżera jest zarządzanie gotowymi rozwiązaniami, które architekt wymyślił lub wybrał. Pytania PM pozostają bez odpowiedzi, ponieważ architekt postrzega je jako ingerencję w czyjąś rolę.
A menedżer, nie znając wszystkich niuansów, nie może właściwie zaplanować ryzyka, ocenić zakresu, obliczyć kosztów — całe zarządzanie projektem jest dla niego trudniejsze.
Oczywiście specjaliści techniczni często nie lubią, gdy “nietechniczni” ingerują w ich pracę. Można się dogadać, jeśli spełnione są dwa kryteria:
- Zrozumienie architektury. Oznacza to, że menedżer zna na tyle terminologię, aby zrozumieć, o czym mówią programiści, a w szczególności architekt, a także zna wskaźniki for architecture quality i wie, na co one wpływają.
- Komunikacja na poziomie wartości firmy. Architekt nie powinien mieć wrażenia, że go sprawdzają, kontrolują, ani że menedżer stosuje mikrozarządzanie i próbuje wykonywać zadania za architekta.
Kiedy menedżer rozumie, o czym mówi architekt i jakimi kategoriami mierzy produkt, może przedstawić argumenty, na przykład dotyczące estymacji i ilości testów lub nalegać na wprowadzenie zmian u programistów.
2. Przekonanie klienta
Często zdarza się, że klient wpada na pomysł w połowie projektu: “Chcę inaczej, wymyśliłem nowy przycisk, przeprojektujcie go!”.
Menedżerowi nie wystarczy po prostu zrozumieć, że ten przycisk nie jest potrzebny. Trzeba także przekonać klienta, dlaczego pomysł jest niemożliwy, nieopłacalny lub nieodpowiedni w danym momencie.
Takie rzeczy można przekonująco wyjaśnić tylko wtedy, gdy wiesz, jak działa architektura produktu.
Inny przykład. W każdym projekcie wcześniej czy później pojawia się dług techniczny – jakieś elementy są niedojrzałe lub trzeba tworzyć tymczasowe rozwiązanie dla przyspieszenia tempa. Programiści potrzebują czasu, żeby się z nim uporać. Klient nie zawsze rozumie, skąd bierze się dług techniczny i może myśleć, że programiści po prostu naprawiają swoje własne “błędy” które z jakiegoś powodu nie zostały naprawione wcześniej.
Zadaniem menedżera w takiej sytuacji jest udowodnienie klientowi, że dług techniczny pojawi się tak czy siak, a potem wszystko będzie w normie, ale to zajmie to czas, pieniądze itp.
Zrozumienie procesów architektonicznych pomoże uzasadnić wielkość budżetu przeznaczonego na ryzyko lub koszty związane z odpowiednim poziomem bezpieczeństwa. Jeśli nie wyjaśnisz klientowi, dlaczego należy zainwestować więcej pieniędzy w bezpieczeństwo, możesz skończyć tak, jak w tym przypadku:
Zespół tworzył aplikację, która zbierała dane użytkowników. PM na początku nie zdołał przekonać klienta do przeznaczenia dodatkowego budżetu na bezpieczeństwo, więc pewnego ranka programista zobaczył na ekranie napis: „Oddam bazę danych za 100 bitcoinów”. Aplikację zhakowano, a dane użytkowników zostały skradzione.
Czasami klient po prostu nie zdaje sobie sprawy ze znaczenia niektórych wymagań niefunkcjonalnych. Dlatego konieczne jest, aby menedżer zadawał właściwe pytania, uzyskiwał właściwe informacje i przekazywał je programistom.
Zebrane odpowiedzi ułatwią pracę architektowi lub liderowi zespołu: nie trzeba będzie później wnosić milion poprawek, można poprawnie oszacować koszty, a zespół nie straci pieniędzy, czasu i nerwów.
3. Znalezienie najlepszego rozwiązania dla projektu
Właściwe pytania pomogą dowiedzieć się, czego naprawdę chce klient i zaproponować najlepsze rozwiązanie. Jeśli menedżer lub analityk biznesowy omówił ważne aspekty techniczne z klientem na początku projektu, programistom łatwiej będzie zbudować optymalną architekturę.
Na przykład, menedżer wie, dlaczego dla MVP odpowiedni jest jeden konkretny rodzaj architektury, a przy skalowaniu projektu – zupełnie inny, a zatem zaoferuje klientowi właściwe rozwiązanie. W rezultacie wszyscy są na wygranej pozycji: klient otrzyma produkt wysokiej jakości, a zespół nie będzie musiał ciągle czegoś przerabiać i stawać na głowie.
W trakcie projektu klient może zgłaszać menedżerowi projektu propozycje dotyczące ulepszeń i rozszerzenia funkcjonalności. Dobrze, jeśli PM dokładnie wie, jak korzystać z metryk i jak przeprowadzić analizę przed wdrożeniem nowej funkcji – w przeciwnym razie zespół będzie marnować czas.
Jak pojawia się niepotrzebne zadanie, dobrze widać na tym przerysowanym przykładzie. Chociaż ta funkcja jest wymyślona, samą koncepcję niestety często się spotyka.
Załóżmy, że zespół tworzy aplikację, która śledzi czas i dystans biegu. Klient ma taką zachciankę, żeby dodać nową ciekawą funkcję – chce, aby program pokazywał, ile czasu dana osoba spędza od momentu uruchomienia aplikacji do wyjścia na ulicę, czyli ile trwa zakładanie butów do biegania, założenie stroju sportowego itp.
Programiści zaczęli to robić, a kiedy skończyli, klient mówi: “To nie pomaga śledzić czasu ubierania. A co, jeśli podczas przygotowań ktoś będzie parzył kawę? To przecież wydłuża czas. Oznacza to, że zbieramy nieadekwatne dane, które nie prowadzą do zaplanowanego rezultatu. Więc po co to robimy?”.
W rezultacie wszyscy pracowali, tracąc czas, a wdrożenie nowej oryginalnej funkcji nie przyniosło rezultatów biznesowych: nie zwiększyło retencji ani liczby użytkowników.
Rozumiejąc architekturę, menedżer będzie w stanie pomóc zespołowi wybrać rozwiązanie dla konkretnego problemu biznesowego, przeanalizować korzyści z wdrożenia konkretnej funkcji i ustalić priorytety funkcjonalności dla użytkowników.
Inny przykład. Rozpoczynasz pracę nad aplikacją i na początku musisz zdecydować, gdzie przechowywać dane: na serwerze fizycznym czy w chmurze. Są to dwa zupełnie różne podejścia, a ich koszty również są różne.
Klientom oferowano przechowywanie danych w chmurze jako najlepszy sposób, ale nikt nie analizował trendów biznesowych – spadku cen sprzętu, który stał się tańszy z powodu spadku wartości kryptowaluty. I chociaż można było kupować serwery z zyskiem, skupiono się na chmurze.
Wszystko szło dobrze, a potem, gdy klient chciał gromadzić więcej danych użytkowników i skalować projekt, okazało się, że w chmurze będzie to znacznie droższe niż na własnym sprzęcie.
Gdyby na początku omówiono, że w przypadku tej konkretnej aplikacji bardziej opłacalne byłoby przechowywanie danych na dysku – klient zaoszczędziłby pieniądze.
Na przykład, PM mógłby zapytać: “Ilu użytkowników planujecie przyciągnąć i w jakim okresie czasu?”.
BA mógłby przeprowadzić analizę rynku, zobaczyć dynamikę cen i zaproponować klientowi odpowiedni sposób przechowywania danych.
Prawidłowe pytania i analiza pomagają znaleźć najlepsze rozwiązanie dla projektu od razu, a nie po miesiącach pracy nad nim.
Praca z architekturą jest kluczowa na początku projektu, gdy kładzie się fundament: wybiera się język programowania, strukturę przechowywania danych, framework do tworzenia oprogramowania. W bieżącym projekcie fundamenty zostały już położone, ale w trakcie procesu trzeba będzie nadal uwzględniać propozycje klienta. Jeśli będą to jakieś rozwiązania funkcjonalne, wpłyną one na zmiany w architekturze, i trzeba będzie umieć wyjaśnić, na przykład, dlaczego nie wszystko można zrobić od razu.
Koniec końców, zrozumienie architektury będzie konieczne, jeśli chce się efektywnie komunikować z architektem rozwiązań, szacować wstępne koszty, zadawać właściwe pytania klientowi i mieć jakiś wpływ na wybór rozwiązania.