Kontrolowanie wymykającego się zakresu projektu (z Suze Haworth)

Przeczytaj transkrypcję:

Testujemy transkrybowanie naszych audycji 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 audycji DPM, w której wychodzimy poza teorię, aby udzielać fachowych porad dotyczących skuteczniejszego prowadzenia projektów cyfrowych. Dziękuję za dostrojenie się. Nazywam się Ben Aston, jestem założycielem The Digital Project Manager. Jeśli istnieje jedna rzecz, która wykoleja niemal każdy projekt, jest nią wymykający się zakres projektu. Wszyscy wiemy, że jest to problem. Wszyscy wiemy, że chcemy go unikać. Ale jak rozpoznać go we wszystkich jego odmianach? Co go powoduje? Czyja to wina? A przede wszystkim — jak sobie z nim radzić? Wszystko wyjaśnimy w dzisiejszej audycji, w której rozmawiamy o kontrolowaniu wymykającego się zakresu projektu.

Dzisiejszą audycję sponsoruje Clarizen, lider w dziedzinie oprogramowania do zarządzania projektami i projektami przedsiębiorstw.

Dowiedz się więcej na clarizen.com

Gości dziś ze mną Suze Haworth. Suze jest jedną z naszych stałych ekspertek DPM w The Digital Project Manager i pracuje jako niezależna starsza menedżerka projektów cyfrowych w Londynie, w Wielkiej Brytanii. Ma ponad 10 lat doświadczenia w pracy w agencjach i zetknęła się z wieloma przypadkami wymykającego się zakresu projektu, więc jest świetną osobą do dzisiejszej rozmowy. Suze, witaj.

Suze Haworth:

Cześć, Ben.

Ben Aston:

Suze, rozmawialiśmy przed rozpoczęciem nagrania. Czy możesz opowiedzieć nam trochę o projektach, nad którymi obecnie pracujesz, i o wyzwaniach, z którymi się mierzysz?

Suze Haworth:

Obecnie pracuję jako freelancerka w agencji w Londynie, więc łączę rolę starszej menedżerki projektu i dyrektorki projektu przy dwóch klientach. Przy jednym z nich pracuję dla IKEA, dużej firmy handlowej i zajmującej się handlem elektronicznym. Tworzymy dla niej system projektowy, a właściwie jego prototyp. Pracuję też dla innego sprzedawcy internetowego w Wielkiej Brytanii, więc obecnie mam dużo projektów związanych z handlem detalicznym. Jeśli chodzi o wyzwania, zawsze trudno o nich mówić, zwłaszcza gdy projekty wciąż trwają. Myślę, że...

Ben Aston:

Czy chodzi o tego kłopotliwego klienta?

Suze Haworth:

Nie, właściwie nie. Muszę powiedzieć, że obecnie pracuję z naprawdę dobrymi klientami. Myślę, że trudność polega na pracy z ludźmi. To jednocześnie dobra i zła strona projektów oraz samego zarządzania projektami. Uwielbiam pracować z różnymi ludźmi, ich charakterami i dziwactwami. Czasami jednak dochodzimy do momentu, w którym frustruje nas próba uzyskania czegoś od osób, które nie chcą się tym zająć. Ostatnio trochę tego doświadczyłam.

Ben Aston:

Zabawa i gry. Opowiedz nam więc o projekcie budowy systemu projektowego. To interesujący rodzaj projektu, którego widzimy coraz więcej. Wcześniej być może każdy projekt traktowano jak wyjątkowy, a kreatywni chcieli przede wszystkim tworzyć. Czym właściwie jest system projektowy? Nad jakim projektem pracujesz i jak go wdrażacie?

Suze Haworth:

To naprawdę ekscytujący projekt, ponieważ systemy projektowe coraz częściej pojawiają się w świecie cyfrowym. Są czymś w rodzaju biblioteki stylów dla cyfrowego projektowania firm i marek. Ustanawiają zestaw bazowych komponentów, modułów i szablonów, które każdy projektant lub programista pracujący z daną marką może wykorzystać do tworzenia własnych projektów i kodu. Taka baza zwiększa wydajność, umożliwia ponowne wykorzystanie kodu i projektów oraz zapewnia spójność w całej firmie.

W przypadku marki takiej jak IKEA, która jest ogromna i współpracuje z wieloma agencjami, osobami i organizacjami, system projektowy może ustanowić standard, według którego pracują projektanci i programiści. Przycisk lub wezwanie do działania na stronie może dzięki temu wyglądać spójnie na wielu platformach, urządzeniach i w aplikacjach.

Ben Aston:

Jak wygląda proces zarządzania takim projektem? Może to być projekt, w przypadku którego nie wiadomo, jak długo potrwa. Od czego zaczęliście, nad czym iterujecie i gdzie projekt się kończy?

Suze Haworth:

W przypadku IKEA zaczęliśmy od strategicznego spojrzenia na całość. Oceniliśmy podstawowe zasady cyfrowe, koncepcję stojącą za projektem oraz zasady projektowania marki IKEA. Następnie przeszliśmy do bardziej konkretnych projektów i stworzyliśmy bazę na podstawie istniejących elementów: kolorów, typografii i siatek. Później przeprowadziliśmy testy z użytkownikami na kilku platformach IKEA, a następnie zaczęliśmy projektować i tworzyć konkretne komponenty oraz umieszczać je w wewnętrznej witrynie systemu projektowego.

Każdy system projektowy powinien być rozwijany bez końca. Nie ma określonego momentu, w którym projekt jest całkowicie zakończony. Z czasem grupuje się komponenty, tworzy moduły i szablony, a następnie pomaga ludziom korzystać z systemu i wdraża ich do pracy z nim.

Ben Aston:

Porozmawiajmy teraz o wymykającym się zakresie projektu. Czym on właściwie jest i dlaczego powinniśmy się nim przejmować?

Suze Haworth:

To sytuacja, w której zakres projektu — czyli uzgodnione elementy, produkty końcowe lub funkcje — rozszerza się w stosunku do pierwotnych ustaleń bez uwzględnienia dodatkowego czasu, budżetu lub nakładu pracy. Może przyjmować różne formy, ale zasadniczo chodzi o to, że nowe elementy zaczynają się pojawiać, wydłużają projekt i powodują opóźnienia.

Najczęstsze przyczyny to brak jasnego określenia zakresu na początku oraz brak upewnienia się, że osoba zatwierdzająca zakres dokładnie rozumie, co otrzyma. Nieprecyzyjny opis produktu końcowego może być różnie interpretowany przez klienta i zespół. Dlatego warto omówić zakres wspólnie, zamiast po prostu wysłać dokument i oczekiwać podpisu.

Wymykający się zakres może również pochodzić z wewnątrz zespołu. Projektant może dodać elementy, które nie zostały uwzględnione w pracach programistycznych, albo ktoś może próbować „upiększyć” projekt i stworzyć coś bardziej efektownego, nie sprawdzając, kto zapłaci za dodatkową pracę. Także testy jakości mogą się rozszerzać, jeśli nie określono kryteriów akceptacji, obsługiwanych przeglądarek i urządzeń oraz priorytetów błędów.

Najważniejsze jest szybkie ujawnianie problemów, otwarta komunikacja i przedstawianie klientowi możliwych rozwiązań. Jeśli pojawia się nowe wymaganie, trzeba przeanalizować jego wpływ na czas i budżet oraz ustalić, co można zdepriorytetyzować.

Dotyczy to także projektów zwinnych. Zmiana nie musi być wrogiem — może prowadzić do powstania lepszego produktu lub usługi. W projekcie zwinnym nowe wymaganie powinno jednak równoważyć się z usunięciem lub przesunięciem innego elementu. Trzeba więc ponownie ustalić priorytety i upewnić się, że zespół mieści się w ramach danego sprintu.

Najlepsza rada dla osoby przejmującej projekt to dokładne oszacowanie zakresu razem z zespołem. Jeśli projekt już trwa, należy zatrzymać się, ustalić, co pozostało do zrobienia, określić skalę przekroczenia i otwarcie omówić sytuację z klientem.

Ben Aston:

Suze, dziękuję za udział w audycji. Jeśli chcesz dowiedzieć się więcej o zarządzaniu projektami cyfrowymi, odwiedź DPMschool.com. Możesz także dołączyć do rozmowy na temat wymykającego się zakresu projektu, komentując wpis i odwiedzając sekcję zasobów TheDigitalProjectManager.com, gdzie znajdziesz informacje o tym, jak dołączyć do naszego zespołu na Slacku. Do usłyszenia następnym razem.