Jak rozmawiać z zespołem deweloperskim o zakresie i wymaganiach

Biznes i technologia rzadko dogadują się w 100%. Dlaczego? Bo zazwyczaj patrzą na projekt z zupełnie różnych perspektyw. Biznes myśli celami, rynkiem i terminami. Zespół deweloperski – wykonalnością, architekturą i długiem technicznym. Jeśli dodamy do tego odmienny język oraz barierę wiedzy specjalistycznej, stanie się jasne, że te dwa światy nie zgrają się same z siebie.

Dlatego porozumienia nie można po prostu założyć jako czegoś oczywistego. Trzeba je wypracować, a kluczowym do tego narzędziem jest świadoma komunikacja. Jej celem nie jest wyłącznie to, by wszyscy ciągnęli linę w tę samą stronę. Chodzi o to, aby każdy – od biznesu, przez Product Ownera, aż po deweloperów – dokładnie wiedział, po co ją ciągnie. Bez tego zespół dostarczy dokładnie to, o co poprosiłeś, ale niekoniecznie to, czego naprawdę potrzebowałeś.

Najwięcej zgrzytów powstaje właśnie na styku zakresu i wymagań – tam, gdzie te same słowa mogą oznaczać zupełnie inne rzeczy dla biznesu i dla inżynierów. Poniżej, na lekko przerysowanych przykładach, pokazuję te nieporozumienia i podpowiadam, jak skutecznie rozbroić każde z nich, aby pomóc obu stronom znaleźć wspólny język.

Jak rozmawiać o zmianie wymagań dla już gotowej funkcjonalności?

Nie ma droższego momentu na dorzucenie nowego pomysłu niż chwila, w której oglądasz działającą wersję funkcjonalności.

Wyobraź sobie klasyczny scenariusz: zespół oddaje gotowe, zgodne z ustaleniami rozwiązanie. Wtedy na stole pojawia się nowy pomysł. Niezależnie od tego, czy to wymuszona rynkiem korekta, czy spóźniona refleksja, biznes najczęściej rzuca wtedy: „zróbmy tu jeszcze taki drobny dodatek”. Kłopot w tym, że słowo „drobny” odnosi się zazwyczaj do efektu na ekranie, a nie do tego, co trzeba zmienić pod spodem. Żeby wdrożyć tę jedną rzecz, zespół musi często przebudować założenia, na których opiera się cała funkcjonalność. Dla Ciebie to drobna modyfikacja, dla deweloperów – przepisanie połowy kodu od zera. Zanim w ogóle oszacują koszt, muszą najpierw przeanalizować skutki tej operacji. Świadomość tej potencjalnej skali jest kluczowa. Bez niej łatwo nalegać na wdrożenie w ciemno, a potem dziwić się, że „mała poprawka” zablokowała zespół na dwa tygodnie i kosztowała dziesięć razy więcej, niż zakładałeś.

Bądźmy uczciwi: część takich zmian jest w pełni uzasadniona. Rynek, konkurencja czy przepisy potrafią się zmienić już po ustaleniu wymagań. Wtedy korekta zakresu to nie kaprys, lecz zdrowa reakcja na nową sytuację. Gorzej, gdy zmiana sprowadza się do „a, bo przypomniało mi się jeszcze o…”. To zwykle sygnał, że zawiodło zbieranie wymagań: albo zespół nie dopytał o szczegóły, albo nie przekazałeś mu wszystkich informacji. W obu przypadkach źródłem problemu jest komunikacja, a nie sama zmiana.

Jak zapobiegać kosztownym zmianom wymagań?

Największy wpływ na ostateczny koszt masz na samym początku – jeszcze zanim zespół napisze pierwszą linijkę kodu. Potraktuj więc zbieranie wymagań jak inwestycję, a nie jak uciążliwą formalność. Wyjaśnij zespołowi nie tylko, co ma powstać, ale przede wszystkim – po co i dla kogo. Przedstaw kontekst biznesowy i opisz, jak funkcjonalność powinna się zachować w mniej oczywistych scenariuszach. Zadawaj pytania i zachęcaj deweloperów do robienia tego samego. Im więcej wątpliwości rozwiejecie na starcie, tym rzadziej będziecie musieli wyrzucać gotowy kod. Pamiętaj przy tym, że precyzowanie wymagań to nie jednorazowa rozmowa na starcie, lecz ciągła wymiana informacji. Nawet najlepszy proces nie wyeliminuje jednak wszystkich późniejszych zmian i nie o to chodzi. Kluczowe jest, by ich nie bagatelizować. Gdy pojawia się nowy pomysł, zapytaj Product Ownera lub lidera technicznego, ile gotowej pracy trzeba będzie wyrzucić do kosza, by go wdrożyć. Jeśli odpowiedź brzmi „większość”, nie wmawiaj sobie ani zespołowi, że to tylko kosmetyczna poprawka. Potraktuj to uczciwie jako nowe zadanie, które wymaga osobnej wyceny i ponownej decyzji budżetowej.

Jak rozmawiać o skalowalności produktu cyfrowego „na zapas”?

Skalowalność to nie funkcjonalność, którą się „dodaje” – to seria decyzji o kosztach i kompromisach. Zespół czy Product Owner rozłożą je na warianty, ale to, jak daleko warto sięgnąć, zależy od Twoich planów na wzrost i budżetu. Bez tych danych ktoś wybierze za Ciebie – niekoniecznie tak, jak byś chciał.

Problem polega na tym, że bez twardych parametrów „skalowalność” oznacza dla każdej ze stron coś zupełnie innego. Ty myślisz zazwyczaj o tym, by za rok dało się tanio i sprawnie wdrażać kolejne funkcjonalności. Zespół słyszy „przygotujcie się na duży ruch” i bez konkretnego punktu odniesienia projektuje bezpieczniejsze, bardziej skomplikowane rozwiązanie. Nikt nie buduje świadomie systemu dla miliona użytkowników, których nie ma. Jednak bez jasno określonych granic łatwo ulec pokusie projektowania „na zapas”: wybrać droższą, rzekomo bardziej skalowalną technologię zamiast prostszego standardu albo podzielić system na wiele osobnych usług, zanim będzie to naprawdę potrzebne. Każda taka decyzja spowalnia tempo prac już na starcie i komplikuje późniejszy rozwój systemu. A wszystko to dla ruchu, który może nigdy nie nadejść.

Spójrzmy na to uczciwie: to nie wynika ze złośliwości ani braku rozsądku po stronie inżynierów. Gdy brakuje twardych danych, projektowanie z naddatkiem staje się racjonalnym odruchem – znacznie łatwiej uzasadnić wyższy koszt infrastruktury niż awarię systemu pod obciążeniem. Ty z kolei nie zawsze masz te liczby pod ręką. Bywa przecież, że na wczesnym etapie sam jeszcze nie wiesz, jakiego obciążenia możesz się spodziewać ani jaki budżet możesz przeznaczyć na utrzymanie. Dopóki jednak nie ustalicie tych parametrów, obu stronom pozostaje zgadywanie.

Jak precyzyjnie określić wymagania skalowalności?

Nikt nie oczekuje, że bezbłędnie przewidzisz przyszłość. Losu produktu rynkowego nie da się precyzyjnie zaplanować, a prognozy ruchu rzadko sprawdzają się w stu procentach. Chodzi raczej o podzielenie się z zespołem wiedzą, którą już dysponujesz, zamiast rzucania ogólnego hasła o „skalowalności”. To, ile jesteś w stanie określić, zależy przede wszystkim od specyfiki projektu. Jeśli pracujesz nad wewnętrznym narzędziem dla firmy, którego obciążenie zależy od liczby pracowników, oddziałów czy przetwarzanych transakcji – skalę możesz oszacować dość dokładnie. Podaj wtedy te parametry wprost. Jeśli jednak tworzysz produkt rynkowy, operuj widełkami: realnym planem na pierwszy rok, progiem, który uznasz za sukces, oraz maksymalnym pułapem, którego przekroczenie w najbliższym czasie jest mało prawdopodobne.

Nazwij też otwarcie poziom niepewności. Dzięki szczerej informacji, że podane liczby to jedynie szacunki, a nie twarde pewniki, zespół zyskuje znacznie więcej niż przy pozornej precyzji. Może wtedy zaprojektować rozsądny zapas techniczny zamiast ślepego zabezpieczania się na każdą ewentualność. Na koniec zapytaj o cenę takiego zabezpieczenia – nie tylko w rachunkach za chmurę, ale przede wszystkim w czasie realizacji: „O ile dłużej zajmie nam wdrożenie wariantu przygotowanego na dziesięciokrotny wzrost?”. Dopiero z takimi danymi możesz świadomie zdecydować, ile elastyczności na przyszłość chcesz kupić już na starcie.

Jak rozmawiać o zmianie priorytetów w trakcie sprintu?

Zmiana priorytetów w trakcie sprintu sama w sobie to nic złego – o ile wynika z twardych przesłanek biznesowych. Kłopot zaczyna się wtedy, gdy dorzucasz nowe zadania bez żadnego uzasadnienia. Taka pozbawiona kontekstu wrzutka błyskawicznie dezorganizuje zaplanowaną pracę i demotywuje zespół.

Sprint to z góry określone ramy czasowe, w których zespół skupia się na realizacji uzgodnionego celu. Wbrew obiegowej opinii te ramy nie są nienaruszalne. Zgodnie z zasadami Scruma zakres prac można w trakcie sprintu doprecyzowywać i renegocjować z Product Ownerem. Co więcej, gdy sam cel straci rację bytu, Product Owner ma prawo przerwać sprint, by po ponownym planowaniu rozpocząć nowy. Metodyki zwinne nie zakazują więc wprowadzania zmian. Problemem są jedynie te dorzucane po cichu, bez analizy i świadomej decyzji. Każda ingerencja ma bowiem swoją cenę, a o tym, czy warto ją zapłacić, decyduje odpowiedź na jedno pytanie: „po co?”. To właśnie ta odpowiedź oddziela uzasadniony zwrot biznesowy od zwykłej zachcianki. Zmiana kierunku oparta na realnej potrzebie rynkowej – jak domknięcie kluczowego kontraktu, dostosowanie do nowych przepisów czy usunięcie poważnej awarii – to świadoma decyzja biznesowa. Z kolei dorzucanie zadań pod wpływem nagłego impulsu to czysta strata: kończy się rozgrzebanym sprintem, spadkiem morale i zerową wartością.

Nie jest to jednak wyłącznie Twoja wina. Gdy prośba pada nagle i z pozycji przełożonego, po drugiej stronie łatwo o bierność. Zamiast otwarcie nazwać koszt takiej zmiany lub zaproponować wymianę zadań, zespół i Product Owner często przyjmują ją w milczeniu. A skoro nikt nie komunikuje Ci wprost, że nowa funkcjonalność opóźni wcześniej obiecane wdrożenia, masz pełne prawo sądzić, że nic ona nie kosztuje.

Jak wprowadzać zmiany w sprincie bez chaosu?

Zanim zdecydujesz się na modyfikację trwającego sprintu, zadaj sobie dwa kluczowe pytania. Pierwsze: czy ta zmiana ma twarde uzasadnienie biznesowe? (np. szansa na pozyskanie klienta, błąd blokujący sprzedaż czy nowy wymóg prawny). Jeśli nie – nowe zadanie powinno trafić do backlogu i poczekać na kolejne planowanie. Drugie: jeśli zmiana jest konieczna, to co w zamian wypada ze sprintu? Usiądź z Product Ownerem lub liderem zespołu i otwarcie ustal wymianę „jeden za jeden”. Przekazując nową prośbę, dołącz do niej jasne wytyczne: opisz krótko, jaki cel chcesz osiągnąć i jakiego rezultatu oczekujesz. Bez otwartej rozmowy o kompromisach zapłacisz podwójnie – najpierw opóźnieniami w pierwotnym planie, a potem chaosem i frustracją w zespole.

Jak rozmawiać o wykonalności technicznej rozwiązania?

Zgrzyt w dyskusji o wykonalności rzadko wynika z odpowiedzi zespołu – znacznie częściej z samego pytania. „Czy dałoby się…?” to pytanie zamknięte, na które prawie zawsze usłyszysz „tak”. Tyle że takie „tak” kompletnie milczy o tym, co dla biznesu kluczowe: czasie, koszcie i ryzyku.

Skąd ta zgodność, która prowadzi donikąd? Kiedy pytasz „czy dałoby się…?”, zwykle zależy Ci na szybkim zielonym świetle, by pchnąć dalej negocjacje z klientem lub zarządem. Zespół traktuje pytanie dosłownie i odpowiada z inżynierską precyzją: skoro istnieje jakakolwiek techniczna ścieżka, to „się da”. I tak obie strony rozchodzą się w świetnych humorach, choć każda usłyszała coś zupełnie innego.

Sami inżynierowie też jednak nie ułatwiają tej rozmowy. Łatwo wtedy o równie zdawkową odpowiedź – „da się” albo „nie da się”. Naprawdę ogarnięty zespół nie poprzestanie jednak na takiej deklaracji i sam dopyta: „Tak, ale po co?”. To jedno pytanie zamienia suchą odpowiedź w rozmowę o celu i pozwala inżynierom wejść w rolę doradców, a nie tylko wykonawców.

Jak poznać realne koszty i ryzyko wdrożenia rozwiązania?

Raz na zawsze wykreśl ze słownika sformułowanie „Czy dałoby się…?”. Zamiast tego przedstaw zespołowi cel biznesowy i poproś o możliwe scenariusze: „Chcemy osiągnąć [cel]. Jakie mamy opcje, ile potrwa wdrożenie każdej z nich i z jakim kosztem oraz ryzykiem musimy się liczyć?”. Dojrzały zespół rozpisze dla Ciebie kilka ścieżek ułożonych według ceny i kompromisów: od ekspresowej prowizorki ze świadomym zaciągnięciem długu technicznego, przez solidny standard rynkowy, aż po najbardziej dopracowane rozwiązanie docelowe. Dopiero takie zestawienie daje pełny obraz sytuacji i pozwala podjąć świadomą decyzję biznesową.

Podsumowanie

Wszystkie te nieporozumienia sprowadzają się do jednego wniosku: zespół rzadko ma złe intencje i na ogół nie narzeka na brak słuchu. Po prostu filtruje Twoje słowa przez własną, inżynierską perspektywę. Ostatecznie otrzymasz dokładnie to, co zapiszesz w wymaganiach. To jednak od Ciebie zależy, jak je sformułujesz, jaki nadasz im kontekst i komu je powierzysz. I to właśnie na tym etapie – a nie podczas samego pisania kodu – masz największy wpływ na ostateczny koszt i tempo prac całego projektu.

To jednak dopiero początek. Zakres i wymagania to zaledwie pierwszy z trzech obszarów, na których biznes i technologia rozmijają się najczęściej. W kolejnych artykułach wezmę pod lupę dwa równie zapalne tematy: estymacje czasowe oraz jakość kodu i dług techniczny.