Aby efektywnie pracować w projekcie potrzebna jest elastyczność – w działaniu, w wyborze rozwiązań, w podejściu do klienta. Najlepiej, kiedy jest wypadkową najlepszych praktyk rynkowych i własnego doświadczenia. Bo nie jest tak, że znajomość najlepszych praktyk zarządzania projektem wystarczy. Nie jest też tak, że można ich nie znać i uznawać, że własna, autorska metodyka najlepiej się sprawdzi, bo jest „moja”. Nie jest też tak, że klient pojawia się tylko przy podpisaniu umowy i protokołu końcowego. To jak jest?
Lubimy się z Agile
Planować czy nie planować?
Na bieżąco
Fixed price do lamusa?
Klient w zespole projektowym… dostawcy
Jej wysokość specyfikacja
Stawiamy na komunikację
Zmiany są fajne?
Lubimy się z Agile
W mbt media pracujemy „agilowo”. Takie podejście pozwala nam sprawnie realizować kolejne zadania projektowe angażując klienta w jego realizację przez cały czas. Szybciej rozpoczynamy prace nad projektem, krócej trwa przygotowanie wersji MVP, sprawniej przebiega jej późniejsza rozbudowa w oparciu o feedback decydentów oraz użytkowników aplikacji. W większości przypadków staramy się przekonać klienta do takiej formy współpracy, aby jak najszybciej wypuścić działający produkt w podstawowej funkcjonalności. Liczy się współdziałanie, szybkie reagowanie na zmiany i częste sprawdzanie efektów pracy, a nie kolejny tom dokumentacji…
Planować czy nie planować?
Już na etapie przygotowania specyfikacji dzielimy projekt na etapy po to, by w krótkim czasie móc klientowi przekazać konkretną wartość. Dzięki temu projekt realizowany jest sprawniej. Łatwiej nam na bieżąco kontrolować jego zgodność z oczekiwaniami – ale także wprowadzać zmiany w stosunku do tego, co było zaplanowane. Przede wszystkim staramy się dokładnie przygotować specyfikację danego zadania razem z klientem. Na tej podstawie estymujemy czas i koszty potrzebne na jej wdrożenie oraz staramy się przedstawić elementy specyfikacji, które mogą okazać się problematyczny lub mogą wpłynąć na inne, już gotowe elementy projektu. Jeśli po drodze pojawią się problemy lub w trakcie prac zmieniają się potrzeby – przede wszystkim rozmawiamy. Próbujemy zmienić podejście do zadania w sposób, który spełni nowe oczekiwania.
Na bieżąco
Takie podejście sprawdza się nam szczególnie przy złożonych, skomplikowanych funkcjonalnościach, kiedy zamiast zaplanowania całego projektu „z góry” i sztywnego trzymania się tego planu rozwijamy projekt zgodnie z tym, co się w nim dzieje. Do każdego z etapów podchodzimy jak do osobnego „małego” projektu. Zaakceptowany przez klienta produkt każdego etapu uruchamia realizację kolejnego, zaplanowanego zadania albo… całkiem innego, które po analizie okaże się lepszym rozwiązaniem. Takie podejście wymaga stałego kontaktu z klientem – na bieżąco informujemy o postępie prac, ustalamy priorytety, wyjaśniamy wątpliwości, szukamy rozwiązań. Klient widzi postępy niejako „w czasie rzeczywistym” i w miarę urzeczywistniania się jego wizji może modyfikować swoje wymagania. Celem nie jest bowiem „odhaczenie” wszystkich wymagań, a dostarczenie użytecznego rozwiązania.
Fixed price do lamusa?
Model wyceny fixed price dla dużych projektów sprawdza się już bardzo rzadko. W związku z tym, że na początku współpracy klient rzadko potrafi dostarczyć pełną specyfikację produktu wycena uwzględnia różne scenariusze, które mogą wydarzyć się po drodze. Z tego powodu często jest wysoka i odstraszająca. Fixed price utrudnia też lub w niektórych przypadkach nawet zamyka drogę na zmiany wymagań w trakcie trwania projektu.
Klient w zespole projektowym… dostawcy
Włączamy klienta w realizację projektu od samego początku, a w zasadzie jeszcze przed jego formalnym rozpoczęciem. Rozmawiamy, dopytujemy, poznajemy, by określić ramy i cele tworzonego oprogramowania. Często jest tak, że klient jest bardzo aktywy na etapie uświadamiania sobie potrzeby biznesowej i poszukiwania dostawcy oprogramowania, które tę potrzebę zaspokoi. W momencie, gdy dostawca zostaje wybrany, umowa podpisana – klient staje się bierny i wyczekujący efektów. Tylko to tak nie działa i nie ma prawa zadziałać. W naszych projektach klient staje się niejako członkiem naszego zespołu projektowego i współdziałamy.
Jej wysokość specyfikacja
Etap definiowania wymagań i tworzenia specyfikacji to moment, w którym udział klienta jest szczególnie ważny. To, jak konkretnie i precyzyjnie zostaną określone wymagania wpływa to, czy stworzone oprogramowanie będzie zgodne z tym oczekiwanym. Nawet pracując w duchu „agile”, gdzie bliższe jest nam reagowanie na zmiany od sztywnego trzymania się planu – brak zdefiniowanych wymagań może spowodować, że wypracowane rozwiązanie nie będzie takim, jakiego chciał. Nie tak rzadko spotykamy się z sytuacją, kiedy klient dopiero na etapie tworzenia specyfikacji uświadamia sobie, jakie rozwiązania tak naprawdę będą dla niego użyteczne. Najlepsze efekty współpracy osiągamy, kiedy od początku powstawania projektu możemy pracować z klientem nad specyfikacją i proponować pewne rozwiązania zanim jeszcze powstaną.
Stawiamy na komunikację
Sprawna komunikacja to jedna z naszych podstawowych wartości współpracy z klientami. Niejednokrotnie przekonaliśmy się, że to, co mogłoby wydawać się jasne i klarowne, wcale takim nie jest. Kluczem jest bowiem takie samo rozumienie technicznych i funkcjonalnych uzgodnień dotyczących nowego oprogramowania przez nas i klienta. Siła przekonań, wyobrażeń, ale i oczekiwań klientów jest ogromna i bywa, że przesłania to, co faktycznie zostało uzgodnione. Dlatego szczególnie ważna jest bieżąca komunikacja zespołu projektowego i klienta. Lepsze zrozumienie przekłada się na atmosferę pracy w projekcie i na jakość końcowego produktu. Staramy się dbać o to, żeby klient na bieżąco był informowany o tym, co dzieje się w projekcie. Częstotliwość kontaktów dostosowujemy do jego potrzeb i specyfiki projektu. Nie narzucamy formy komunikacji – raczej staramy się dostosować do klienta. Czasem są to cotygodniowe spotkania, a czasem spotkanie raz na miesiąc. Nie pracujemy wg jednego, narzuconego schematu. W trakcie spotkań przekazujemy informacje o postępie prac i omawiamy dalsze potrzeby pod kątem opracowania kolejnych zadań do wdrożenia.
Zmiany są fajne?
Zmiany wymagań są stałym elementem pracy w formie agilowej i Time&Materials. Często oczywiście wpływają one na czas realizacji projektu. Zazwyczaj w przypadku opóźnień spowodowanych zmianą wymagań klienta, spotykamy się ze zrozumieniem. Nie do przecenienia jest bieżąca komunikacja i otwarta rozmowa z klientem. Regularna ocena postępów prac i dostarczanie funkcjonalności w małych fragmentach pomaga zidentyfikować problemy i ryzyka na wczesnym etapie i ułatwia zarządzanie nimi. Zachowanie równowagi pomiędzy formalnym zarządzaniem projektem a włączeniem klienta w jego współtworzenie może być kluczem do prowadzenia satysfakcjonujących projektów dla dostawcy oprogramowania, a dla zlecającego źródłem innowacyjnych rozwiązań budujących jego przewagę konkurencyjną.
