Dopracowywanie wymagań (z Kelly Suter z BI Worldwide)

Przeczytaj transkrypcję:

Testujemy transkrypcję naszych podcastów za pomocą programu komputerowego. Prosimy o wyrozumiałość w przypadku literówek, ponieważ bot nie zawsze działa w 100% poprawnie.

Ben Aston:

Witamy w podcaście DPM, w którym wykraczamy poza teorię, aby提供ć ekspertom ds. zarządzania projektami praktyczne porady dotyczące prowadzenia lepszych projektów cyfrowych. Dziękuję za dostrojenie się. Nazywam się Ben Aston i jestem założycielem Digital Project Manager. Powiedzmy sobie szczerze: czy Twój klient kiedykolwiek pod koniec projektu powiedział: „Hej, naprawdę świetnie sobie z tym poradziliście, dokładnie tego chcieliśmy, dokładnie to, co powiedzieliście, że zrobicie na początku projektu, i to niesamowite, jak udało wam się uchwycić wszystko i niczego po drodze nie pominąć”?

Cóż, podejrzewam, że tak się nie stało. Prawdopodobnie dlatego, że wymagania nie zostały odpowiednio dopracowane. Jak więc zarządzać wymaganiami, aby później nie doprowadzić projektu do całkowitego chaosu, a jednocześnie przekazać klientowi i programiście informacje niezbędne do wykonania pracy? Temu właśnie poświęcony jest dzisiejszy podcast — wymaganiom projektowym.

Chodzi o sposób definiowania projektu i funkcjonalności dla naszych klientów, aby wszyscy wiedzieli, co zostanie dostarczone. Zasadniczo wymagania są, moim zdaniem, narzędziem komunikacji, ale bardzo trudno przygotować je właściwie. Jeśli określimy wymagania zbyt ogólnie, zyskamy większą elastyczność, ale możemy nie otrzymać dokładnie tego, czego chcieliśmy. Jeśli określimy je zbyt szczegółowo, może się okazać, że zabraknie wielu elementów. Jak więc znaleźć właściwą równowagę?

Dziś rozmawiam z Kelly Suter. Kelly jest techniczną kierowniczką projektów w BI Worldwide oraz jedną z naszych ekspertek Deakin w Digital Project Manager. Cześć, Kelly.

Kelly Suter:

Cześć, dziękuję za zaproszenie, Ben.

Ben Aston:

Nie, to świetnie, że jesteś z nami. To chyba nasz drugi podcast, prawda?

Kelly Suter:

Tak, zgadza się.

Ben Aston:

Nagraliśmy podcast bardzo dawno temu. Dla tych, którzy zapomnieli, kim jesteś — czy możesz krótko opowiedzieć, jak trafiłaś do zarządzania projektami? Obrałaś dość ciekawą drogę, chyba podobną do drogi większości kierowników projektów. Kiedy dorastaliśmy, raczej nie planowaliśmy zostać kierownikami projektów. Opowiedz nam trochę o swojej historii. Jak to się stało, że dziś jesteś kierowniczką projektów cyfrowych?

Kelly Suter:

Swoją karierę zawodową rozpoczęłam jako reporterka sportowa. Studiowałam komunikację ze specjalizacją w public relations i mediach. Kiedy zdałam sobie sprawę, że gazety nie są już rozwijającą się branżą, postanowiłam zainteresować się reklamą i przez około trzy lata pracowałam jako specjalistka ds. promocji. Pracowałam przy jednej marce — Sesame Street Live — i przez te trzy lata bardzo dobrze ją poznałam. Wtedy poznałam osobę pracującą w sklepie internetowym na zamówienie, czyli w agencji cyfrowej oferującej pełną obsługę i skupiającej się na handlu elektronicznym.

Powiedziała: „Nie mamy tutaj działu zarządzania projektami. Chcesz zostać kierowniczką projektu?”. Odpowiedziałam: „Co to takiego?”. Mój tata prowadził agencję projektowania graficznego, więc dorastając, znałam procesy agencyjne na tyle, by wiedzieć, że wszystko jest tam bardzo intensywne i ciągle coś się dzieje. Pomyślałam jednak: „Tak, jestem zainteresowana, zobaczmy, co tam macie”. Poszłam do tej firmy. Pierwszą książką, którą przeczytałam, była książka Meghan McInerny „People, Pixels, and Process”. Nie wiem, czy podałam właściwą kolejność, ale przeczytałam ją i zastosowałam jej wskazówki—

Ben Aston:

Wiem, o którą chodzi.

Kelly Suter:

Tak.

Ben Aston:

„People, Pixels, and Process”… Chyba właśnie tak brzmi tytuł.

Kelly Suter:

Właśnie. Zastosowałam te zasady najlepiej, jak potrafiłam, w agencji, którą zastałam. Wtedy pracowało tam 12 osób. Tworzyliśmy niestandardowe strony internetowe i rozwiązania e-commerce. Po około czterech latach zarządzałam już zespołem siedmiu kierowników projektów. Udało nam się stosować proces, który stale ewoluował. Później pomyślałam: „Dobrze, czuję się bardzo swobodnie w pracy z Magento, Drupalem, Cantego, WordPressem i podobnymi narzędziami. Chcę poszerzyć wiedzę techniczną”. W BI Worldwide, gdzie obecnie pracuję, pojawiła się możliwość objęcia stanowiska technicznej kierowniczki projektu. Przeszłam więc tutaj, ponieważ chciałam wrócić do świata zarządzania projektami, być bliżej projektów i doskonalić umiejętności techniczne. I właśnie tym zajmuję się dzisiaj. To bardzo ekscytujące — czas minął w mgnieniu oka, ale naprawdę uwielbiam tę pracę.

Ben Aston:

Zawsze jestem ciekawy: czy to jest teraz Twoja wymarzona praca? Wygląda na to, że przeszłaś ciekawą drogę — od reporterki sportowej, przez pracę przy Sesame Street, aż po technologię i zarządzanie projektami. Kim chcesz zostać, kiedy dorośniesz?

Kelly Suter:

To bardzo dobre pytanie. Najbardziej podoba mi się to, co robię obecnie i co niedawno robiłam w Irish Titan, innej firmie zajmującej się tworzeniem oprogramowania. Lubię przychodzić do miejsc, w których procesy nie są jeszcze jasno określone albo dopiero zaczynają się rozwijać. Nie oznacza to, że zespoły nie są bardzo utalentowane i nie dostarczają świetnych rezultatów. Po prostu lubię podejmować wyzwania, wprowadzać procesy tam, gdzie ich nie ma, sprawdzać, co działa, i dawać zespołom poczucie ulgi: „Mamy już coś, na czym możemy się oprzeć”. Myślę więc, że moim wymarzonym zajęciem byłoby bycie takim strażakiem — mówiąc obrazowo — dla rozwijających się firm i start-upów. Wchodzę, mówię: „Dobrze, wdrożyliśmy ten proces. Zobaczmy, jak zastosować go tutaj i tutaj”. Uwielbiam wymagające wyzwania.

Ben Aston:

Świetnie. Powiedz mi więc, z jakimi wyzwaniami mierzysz się teraz? Wspomniałaś o gaszeniu pożarów, porządkowaniu procesów i pracy w agencji, ale jakie wyzwania pojawiają się na co dzień albo nad jakim konkretnym wyzwaniem pracujesz obecnie?

Kelly Suter:

Obecnie, spośród wszystkich wyzwań, z którymi stale się mierzymy, najważniejsze jest dla mnie przekonanie zespołu — w sposób, który nie będzie nudny — do dokumentowania pracy. Nie chcę brzmieć tak, jakbym reklamowała temat tego podcastu, ale kiedy klient i zespół są pełni entuzjazmu, trudno uzyskać pełną zgodę na komunikat: „Nie musimy zwalniać ani tracić impetu, ale musimy dokumentować”. Następnie trzeba ujednolicić tę dokumentację i odpowiednio zabezpieczyć wszystkie kwestie. Nie trzeba robić tego w sposób tak żmudny, jak czasami się wydaje, ale należy udokumentować wystarczająco dużo, aby po przejściu do innego zespołu, awansie albo zmianie roli nie utracić całej logiki i procesu. Widziałam zespoły, które nieustannie wynajdują koło na nowo — przy tworzeniu produktu albo dokumentacji. Nadmiernie komplikują coś, co można ustandaryzować i usprawnić.

Myślę więc, że obecnie największym wyzwaniem jest uzyskanie zgody zespołu. Dokumentuję teraz rozwiązania, których najnowsza dokumentacja pochodzi z 2014 roku. Wszystko działało dla klienta i dla nas, ale nie chcemy, żeby nadal tak było. Później, podczas audytu, dobrze jest mieć wszystko uporządkowane.

Ben Aston:

Skoro zajmujesz się definiowaniem, tworzeniem i udoskonalaniem procesów, czy używasz jakichś narzędzi? Co obecnie najbardziej ułatwia Ci życie?

Kelly Suter:

Jeśli chodzi o dokumentację, nie komplikuję sprawy. Jeżeli klient nie ma problemów z bezpieczeństwem ani prywatnością informacji, korzystam z Google Workspace, Dokumentów Google i współdzielonej przestrzeni. Można ustawić uprawnienia: określić, kto może tylko przeglądać, kto komentować, a kto edytować dokumenty.

Dzięki temu nie trzeba martwić się kontrolą wersji, a później można wyeksportować dokument do PDF i przygotować go do podpisu. Do samego pisania dokumentacji używamy właśnie tych narzędzi. InVision świetnie sprawdza się przy kontroli projektów kreatywnych i dodawaniu komentarzy. Projektanci umieszczają tam projekty albo makiety, a klient lub interesariusz może je komentować. Po zatwierdzeniu projektów można dodać adnotacje i wyeksportować materiały do dokumentacji. Elementy wizualne są bardzo pomocne.

Jeśli nie masz InVision, ponieważ jest to płatny zestaw narzędzi i może być kosztowny, możesz użyć Sketch. Korzystałam ze Sketch, kiedy nie miałam budżetu na InVision. To bezpłatne narzędzie Evernote, które pozwala w prosty i estetyczny sposób dodawać adnotacje. Wystarczy przesłać gotowe projekty, dodać numery lub litery i pracować z nimi w ten sposób.

Naprawdę nie komplikuję tego procesu. Potrzebuję tylko sposobu na zaimportowanie projektów, dodanie adnotacji, umieszczenie ich w dokumentacji i napisanie tekstu. To właśnie sprawdzało się u mnie najlepiej.

Ben Aston:

To ciekawe. Chciałbym wrócić do Twojego rozwoju jako kierowniczki projektu cyfrowego. Obecnie jesteś techniczną kierowniczką projektu, ale pełnisz różne role: kierowniczki projektu, analityczki biznesowej, mistrzyni SCRUM. Czym techniczna kierowniczka projektu różni się od kierowniczki projektu cyfrowego? Czy to właściwie to samo? Jak sprawdza się u Ciebie noszenie tych różnych kapeluszy?

Kelly Suter:

To bardzo dobre pytanie. W mojej obecnej roli mam szczęście, bo jest ona dość wyjątkowa. W BIW zajmuję się zarówno technicznym, jak i tradycyjnym zarządzaniem projektami. Prowadzę projekty związane z wydarzeniami na żywo oraz projekty dotyczące treści edukacyjnych — to około jednej czwartej mojej pracy. Pozostałe trzy czwarte to techniczne zarządzanie projektami, które może wyglądać różnie w zależności od firmy.

Można spotkać określenia takie jak cyfrowe, techniczne czy zwinne zarządzanie projektami. Największą różnicą między wcześniejszą rolą kierowniczki projektu cyfrowego a moją obecną rolą technicznej kierowniczki projektu jest poziom zrozumienia cyfrowej pracy. Gdy byłam kierowniczką projektu cyfrowego, zajmowałam się wszystkimi elementami projektu, ale na nieco wyższym poziomie. Wiedziałam, czym jest strategia treści, mapowanie strony, tworzenie makiet i projektowanie. Jeśli chodziło o programowanie, mówiłam mniej więcej: „Wiem, że trzeba przeanalizować te dane i określić, jak ma wyglądać eksport danych dotyczących zapasów. Dajcie znać, kiedy skończycie”.

W obecnej roli technicznej kierowniczki projektu jestem znacznie bliżej programowania. Nadal zarządzam rezultatami prac zespołów kreatywnych, strategii cyfrowej i kontroli jakości, ale przy programowaniu mogę być bliżej zespołu podczas testów. Przy przeglądzie kodu i wdrożeniach pracuję ramię w ramię z głównym programistą: „To są wymagania, które napisałam. Jak mają się do kodu, który widzisz, zanim odhaczymy zadanie?”. Drugą różnicą jest to, że piszę wymagania techniczne. Im bliżej wymagań jesteś, tym większa odpowiedzialność i tym bardziej musisz angażować się w późniejsze rozmowy.

Jako kierowniczka projektu cyfrowego zarządzałam wymaganiami i przekazywałam je właściwym osobom. Jako techniczna kierowniczka projektu sama je tworzę. Jestem więc głębiej zaangażowana w prace programistyczne.

Ben Aston:

Porozmawiajmy więc o tym, jak wygląda cały proces tworzenia wymagań funkcjonalnych i biznesowych. To często niejasny obszar. Programiści mogą powiedzieć: „To zadanie kierownika projektu” albo „To zadanie analityka biznesowego, nie moje”. Z drugiej strony analityk biznesowy lub kierownik projektu może stwierdzić: „Nie potrafię tego zdefiniować, bo nie wiem, jakie są możliwości”. Ty najwyraźniej znajdujesz się pośrodku. Jak podchodzisz do tego procesu?

Kelly Suter:

Na początku każdego projektu, przy dołączaniu do zespołu albo rozpoczynaniu pracy w nowej firmie, trzeba dobrze zrozumieć role i zakresy odpowiedzialności. Nawet jeśli są zdefiniowane, mogą ewoluować lub zmieniać się w zależności od klienta. Przykładowo, przy niestandardowej integracji mogę powiedzieć: „To integracja z bazą produktów. Chcę, aby dane były aktualizowane na żywo i pokazywały dokładną liczbę koszulek w magazynie, w każdym rozmiarze. Dane mają być aktualizowane codziennie o określonej godzinie”.

Mogę powiedzieć programiście, jaki ma być rezultat, ale on może zejść o poziom głębiej — na poziom, którego nie rozumiem i którego nie mogę samodzielnie określić. Nie chcę udawać, że rozumiem coś, czego nie rozumiem. Siadam więc z programistą i mówię: „Do tego miejsca biorę odpowiedzialność za wymagania. Czy możesz pomóc mi je uzupełnić i zadać pięć razy pytanie «dlaczego»?”. Wspominam o tym również w moim artykule. Trzeba pytać: „Dlaczego te dane mają być uzupełniane w ten sposób?”. Odpowiedź może brzmieć: „Bo tak często klienci kupują ten produkt”. Następnie znów pytamy: „Dlaczego?”.

W pewnym momencie trzeba powiedzieć: „Programisto, potrzebuję Twojej pomocy przy napisaniu pozostałej części wymagań dotyczących tej funkcji, ponieważ nie potrafię tego zrobić i nie chcę ryzykować, że coś przeoczymy”. To kwestia równowagi i wczesnego określenia, co jesteś w stanie zrobić. Zakres odpowiedzialności może się zmieniać. Najważniejsze, aby ludzie nie traktowali tego osobiście. Chodzi o wykorzystanie mocnych stron wszystkich osób, a to wymaga komunikacji.

Ben Aston:

Dla osób, które słuchają tego i zastanawiają się, czym właściwie jest projektowanie wymagań biznesowych albo wymagania funkcjonalne: czy nie jest tak, że agencja lub studio po prostu przygotowuje projekty, przekazuje je programistom i czeka na rezultat? Mówisz o dokumentacji. Czy to nie jest przeciwieństwo podejścia zwinnego i elastycznego?

Jakie są to dokumenty i dlaczego są ważne?

Kelly Suter:

Dokument wymagań biznesowych można porównać do podstawowego kursu. Zawiera najważniejsze informacje, na przykład: „Potrzebujemy tłumaczenia na język hiszpański i mandaryński”, „Musimy dostarczyć dziesięć różnych kursów”, „Projekt ma działać do kwietnia” albo „Musimy obsługiwać bazę 6000 użytkowników lub taki poziom ruchu”. To może być zawartość dokumentu wymagań biznesowych. Jest to podsumowanie dotychczasowych ustaleń i punkt kontrolny, który pozwala obu stronom potwierdzić: „Tak, rozumiemy projekt tak samo”.

Oczywiście dokument powinien też wskazywać, że szczegóły zostaną doprecyzowane. Jeśli coś wyjdzie poza zakres albo spowoduje przekroczenie budżetu, poinformujemy o tym, ustalimy priorytety i zdecydujemy, co pozostaje w projekcie, a co zostanie przesunięte do drugiej fazy.

Dokument wymagań funkcjonalnych jest kolejnym punktem kontrolnym. Pomiędzy dokumentem wymagań biznesowych a funkcjonalnych dzieje się bardzo dużo. Każdy punkt rozwijamy w szczegóły. Jeśli mamy tłumaczenia na hiszpański i mandaryński, pytamy: Czy skorzystamy z zewnętrznego dostawcy? Czy napiszemy kod automatyzujący ten proces? Czy administrator będzie ręcznie wprowadzał trzy języki w systemie zarządzania treścią? Wszystkie te kwestie trzeba rozwinąć.

Dokument wymagań biznesowych potwierdza, że wszyscy rozumieją ogólny kierunek. Dokument wymagań funkcjonalnych jest natomiast planem budowy — i powinien nim być.

Ben Aston:

Dokument wymagań biznesowych określa więc na początku projektu, jak wygląda sukces z perspektywy biznesowej i jakie kwestie musimy uwzględnić. Wymagania funkcjonalne określają natomiast, jak ma działać konkretna funkcjonalność. Jeśli strona ma być dostępna i czytelna dla osób w Chinach, musi być przygotowana w języku mandaryńskim i odpowiednio zlokalizowana.

Jak widzisz to w kontekście podejścia zwinnego? Niektórzy programiści mówią: „Pokażcie mi wymagania, nie mogę bez nich pracować”. Kiedy jednak je otrzymują, twierdzą: „Nie powinniśmy tak pracować. Powinniśmy dostarczać małe fragmenty funkcjonalności i rozwijać je iteracyjnie, zamiast tworzyć ogromne ilości dokumentacji”. Jak znaleźć równowagę?

Kelly Suter:

Trzeba zacząć od wstępnego uzgodnienia procesu. Można stworzyć dokument określający: „Będziemy pracować zwinnie. Oznacza to to i to. Od klienta potrzebujemy takich informacji, a wewnętrznie potrzebujemy takich działań”. Następnie należy przeprowadzić solidne spotkanie rozpoczynające projekt.

Obecnie tworzymy oprogramowanie, które przypisuje punkty do nauki. Użytkownik przechodzi kurs, robi postępy, zdobywa punkty, a następnie może wykorzystać je na rynku. Nie wiemy jeszcze wszystkiego, czego nie wiemy. Klient wie jednak, czego chce, chce to otrzymać w styczniu i ufa nam, ponieważ współpracowaliśmy już przy wielu projektach.

Nie mamy czasu na stworzenie całej dokumentacji, choć bardzo bym tego chciała. Muszę więc zaakceptować cel końcowy i nie definiować szczegółowo wszystkich kroków pośrednich. Co tydzień organizujemy spotkanie i ustalamy: jedna osoba pracuje nad odznakami, druga nad certyfikatami, kolejna nad tabelą wyników, a jeszcze inna nad zakupami. Z klientem spotykamy się co dwa tygodnie, aby zaprezentować wydanie.

Klient wie, że to, co ogląda, jest surowe i nie będzie jeszcze dopracowane wizualnie. Najważniejsze jest wdrożenie funkcjonalności. Cotygodniowe spotkania są bezcenne. Jako kierownik projektu możesz je dokumentować: wskazać, co pokazujemy, co zostało wykonane w poprzednim tygodniu i jakie pytania wymagają odpowiedzi.

Podczas spotkania klient może powiedzieć: „Myślałem, że będzie to wyglądało inaczej”. Dzięki zaufaniu może zgłosić obawy, a zespół może przygotować plan na kolejny tydzień. Trzeba też stale kontrolować kierunek projektu i pytać, jak wygląda postęp względem celu. Być może certyfikaty trzeba będzie odłożyć, aby skoncentrować się na ważniejszym elemencie. To wymaga ciągłej komunikacji, dokumentowania postępów i zaufania.

Ben Aston:

Często projekt zostaje wstrzymany już na początku, jeśli czekamy z rozpoczęciem prac do czasu pełnego zdefiniowania wymagań. To może trwać bardzo długo. Podoba mi się więc idea, że wymagania dają programistom jasność co do tego, co mają zbudować, klientowi — co otrzyma, a zespołowi kontroli jakości — względem czego ma testować. Wymagania mogą ewoluować wraz z projektem.

Dokumentowanie wszystkiego jest jednak czasochłonne. Jak to robisz? Czy tworzysz wymagania w JIRA podczas pisania zadań?

Kelly Suter:

Kiedy mam ukończony dokument wymagań funkcjonalnych, upewniam się, że wszyscy go przejrzeli, a następnie przekazuję go klientowi do zatwierdzenia. Później omawiam go z zespołem programistycznym. Niektórzy programiści chcą otrzymać dokładnie opisane zadania. Inni wolą sami zdecydować, w jakiej kolejności je wykonać. Najpierw pytam więc, które podejście preferują.

Zwykle, ponieważ przejrzeli już dokument, zgadzają się, abym utworzyła zadania. Tworzę jedno zadanie dla każdego punktu wymagań. Historie użytkownika organizuję według typów stron — może to być historia rejestracji, strona główna albo strona produktu — a następnie tworzę podzadania dla każdego elementu danego typu strony.

Programiści powinni sami oszacować czas pracy. Jeśli to możliwe, nie należy prosić najlepszych programistów o oszacowanie wszystkiego, a potem przekazywać zadań młodszemu programiście. Osoba, która będzie wykonywać pracę, powinna ją oszacować. Jeżeli zna wymagania i oczekiwania, różnica między szacunkiem a rzeczywistym nakładem powinna być niewielka.

Korzystam z JIRA, pakietu Atlassian, do zarządzania zadaniami. Kiedy wszystko znajduje się w rejestrze zadań, proszę programistów o oszacowanie i uporządkowanie pracy. Następnie dzielę zadania na sprinty, zwykle zakładając 30–35 godzin tygodniowo, jeśli dana osoba pracuje tylko nad jednym projektem. Jeśli działamy zwinnie i chcemy uwzględnić kontrolę jakości, przy każdym zadaniu należy dodać instrukcję testowania, która pozwoli ocenić, czy zadanie zakończyło się powodzeniem.

Ben Aston:

Chciałbym poruszyć temat szacowania. W przypadku projektów technicznych jest to coraz większe wyzwanie. Na początku klient chce wiedzieć, ile projekt będzie kosztował, ale nie znamy jeszcze wszystkich funkcjonalności. Jak podchodzisz do oszacowania na poziomie 200 tysięcy, zanim wymagania funkcjonalne zostaną dokładnie opisane?

Kelly Suter:

To złożone pytanie. W większości przypadków kierownik projektu nie ma wpływu na początkową wycenę. Czasami ktoś pyta: „Rozmawiam z klientem, ma świetny pomysł. Jak myślisz, czy zdążymy do marca?”. Wtedy mam oczywiście mnóstwo pytań.

Jeśli mogę przygotować wstępny szacunek, najpierw sprawdzam, co robiliśmy wcześniej. Każda firma ma zwykle określoną specjalizację. Analizuję podobieństwa, takie jak wielkość bazy użytkowników albo wielkość firmy, i porównuję je z wcześniejszymi projektami. Na przykład wcześniejsza realizacja sklepu internetowego na Magento zajmowała sześć do ośmiu tygodni przy pracy dwóch programistów. To daje pewien punkt odniesienia, choć nie jest jeszcze dokładną wyceną godzinową ani pieniężną.

Sprzedawcom i osobom zajmującym się rozwojem biznesu powiedziałabym przede wszystkim: „Jeszcze nie wiemy”. Jeśli nie ma integracji ani niestandardowych rozwiązań i korzystamy z gotowych funkcji, można podać bardziej konkretny zakres. W przeciwnym razie pomocna jest osoba odpowiedzialna za rozwój techniczny. Czasami tę rolę pełni techniczny kierownik projektu. Warto mieć przygotowany zestaw punktów odniesienia: jeśli projekt dotyczy handlu elektronicznego, systemu zarządzania nauczaniem albo innego obszaru, trzeba móc porównać go z podobnymi realizacjami.

Ben Aston:

Mówisz o szacowaniu analogicznym. Na wczesnym etapie, gdy nie znamy jeszcze wymagań funkcjonalnych, najlepiej wskazać kilka podobnych projektów: dolną i górną granicę kosztów oraz prawdopodobny przedział. Nie należy zobowiązywać się do konkretnej kwoty, dopóki wymagania nie zostaną dokładniej zdefiniowane.

Kelly Suter:

Zawsze wykonuję dwa krótkie ćwiczenia. Pierwsze polega na narysowaniu trójkąta: zakres, harmonogram i budżet. Proszę klienta o uporządkowanie tych trzech elementów według ważności. Klient często mówi: „Wszystkie są ważne”, ale pytam wtedy, który jest najważniejszy, ponieważ ta decyzja będzie miała wpływ na cały projekt. Priorytety mogą się później zmienić.

Drugie ćwiczenie to podział na wariant dobry, lepszy i najlepszy. Jeśli klient ma określony budżet, pytam, czy chce się go trzymać kosztem zakresu, czy też woli zapłacić więcej za dodatkową integrację lub niestandardowe rozwiązanie. Możemy również znaleźć rozwiązanie pośrednie. Klient musi podjąć tę trudną decyzję, zamiast słyszeć od nas wyłącznie: „Tego nie da się zrobić”.

Te ćwiczenia pomagają utrzymać równowagę między zakresem, harmonogramem i budżetem. Klient czuje, że uczestniczy we wspólnym podejmowaniu decyzji biznesowych.

Ben Aston:

To bardzo dobre podejście. Klienci czasami próbują zmusić nas do zadeklarowania konkretnego budżetu. Przy stałej cenie, nowych integracjach albo nieznanej platformie jest to szczególnie trudne. Podoba mi się więc pomysł, aby uczynić z tego współpracę i pokazać, że zwiększenie funkcjonalności wymaga dodatkowej pracy.

Na koniec: co powiedziałabyś osobie, która po raz pierwszy chce zacząć pisać wymagania?

Kelly Suter:

Jeśli po raz pierwszy pracujesz jako kierownik projektu cyfrowego, wiesz więcej, niż Ci się wydaje. Masz kontakt ze smartfonami, tabletami i technologią. Znasz zachowania cyfrowe i wykształciłeś już wiele nawyków.

Zamiast od razu wyszukiwać w Google szablon dokumentacji technicznej, zacznij od konkretnego projektu. Załóżmy, że tworzysz stronę rejestracji na wydarzenie. Ma ona stronę główną i formularz internetowy. Zastanów się: co trzeba tutaj zdefiniować? Przeanalizuj każdy element strony i zapytaj: „Co to robi na urządzeniu mobilnym, a co na komputerze?”.

Wyjaśnij wszystko na głos, tak jakbyś tłumaczył to komuś z rodziny, kto nadal korzysta ze starego telefonu Nokia. Następnie zapytaj programistę: „Czy dobrze rozumiem?”. Programista doceni to, że zadajesz pytania i starasz się opisać rozwiązanie w sposób, który umożliwi mu skuteczne wykonanie pracy.

Podziel dokumentację wymagań na elementy projektu i wyjaśnij każdy z nich. Pierwsza wersja dokumentu może brzmieć zbyt rozmownie albo być niespójna. To w porządku — dokumentacja będzie ewoluować. Klient prawdopodobnie nie realizuje takich projektów codziennie, dlatego reprezentujesz swoją firmę i zespół jako ekspert. Przejdź przez wymagania razem z klientem. Wiesz więcej, niż myślisz, ponieważ wszyscy żyjemy w świecie technologii cyfrowych.

Ben Aston:

To bardzo pomocne. Wymagania polegają przede wszystkim na zadawaniu pytań i uzyskiwaniu odpowiedzi. Możemy zastanawiać się, czy pytanie jest głupie albo oczywiste, ale nic nie jest naprawdę oczywiste. Warto zacząć od pytania, jak wyjaśnilibyśmy dane rozwiązanie własnej mamie albo babci.

Trzeba też pamiętać, że wymagania są narzędziem komunikacji. Pozwalają wszystkim rozumieć, co właściwie jest tworzone. Jasność oznacza mniej zmarnowanej pracy, lepsze zarządzanie oczekiwaniami i mniejsze ryzyko rozczarowania klienta. Dokumentacja wymaga czasu, ale zwraca się, ponieważ ogranicza konieczność przeróbek i nieporozumień.

Kelly, bardzo dziękuję za udział. Wspaniale było Cię gościć.

Kelly Suter:

Dziękuję, bardzo to doceniam.

Ben Aston:

Kelly, jako jedna z naszych ekspertek DPM, występuje również w naszym kursie Mistrzowskie zarządzanie projektami cyfrowymi. Jeśli nie wiesz, o czym mówię, ale potrzebujesz szkolenia z zarządzania projektami, sprawdź ten kurs. To siedmiotygodniowy intensywny program obejmujący interaktywne lekcje wideo, zadania, dyskusje grupowe i webinary. Wejdź na stronę dpmschool.com i zapisz się. Kurs rozpoczyna się w lutym.

Jeśli chcesz włączyć się do rozmowy o wymaganiach i o tym, jak z nimi pracujemy, odwiedź sekcję zasobów na stronie thedigitalprojectmanager.com i dołącz do naszego zespołu Slack, gdzie toczą się ciekawe dyskusje. Możesz też skomentować ten wpis. Do usłyszenia następnym razem. Dziękuję za uwagę.