Część 4 z 5 – Współpraca, współpraca i jeszcze raz współpraca.
Dzisiaj na warsztat bierzemy:
Współpraca z klientem ponad negocjację umów
Dawno temu, gdy byłem jeszcze początkującym programistą, zdarzało mi się realizować projekty dla klientów, których w życiu nie widziałem, których potrzeb nie rozumiałem, ba, nawet nie do końca wiedziałem, jak ten produkt ma działać. Zdarzało się, że w trakcie prac nad jakąś funkcjonalnością dostrzegałem, że to, co robię, niekoniecznie musi odpowiadać potrzebom klientów, dla których to robię, ale niestety PM zawsze sprowadzał mnie na ziemię, mówiąc, że taka jest umowa, że zostało to zaakceptowane i jeśli teraz będziemy chcieli coś zmieniać, to trzeba będzie negocjować umowę, co nie zawsze było ekonomicznie uzasadnione.
Podobnie było wewnątrz firmy. My kodowaliśmy jakiś fragment, podczas gdy drugi zespół implementował inny fragment oprogramowania. Na początku umawialiśmy się na coś, po czym rozchodziliśmy się, aby po zakończeniu prac znowu się spotkać i zaplanować integrację naszych produktów. Żeby nie było, z takim scenariuszem spotykałem się również później w firmach, które mówiły o sobie, że są „zwinne”. Przeważnie integracja była koszmarem. Nic nie działało. Wiele rzeczy trzeba było pisać niemalże od nowa. Testy trwały w nieskończoność. Terminy? PMowie musieli renegocjować umowy, bo terminy okazywały się nierealne. Przez tę koszmarną integrację.
No dobrze, ale co ma to wszystko wspólnego z punktem manifestu, który mówi o współpracy z klientem? Ano ma, bo klienta powinniśmy szukać nie tylko na zewnątrz firmy, ale również w środku. Czy zespół, dla którego tworzymy jakiś fragment oprogramowania, nie jest naszym klientem? Czy my nie jesteśmy klientem zespołu piszącego dla nas usługi, które później wykorzystamy w naszym oprogramowaniu? Jesteśmy! Dlatego współpracujmy ze sobą.
Jak najlepiej współpracować zarówno z klientem zewnętrznym, jak i wewnętrznym w Agile? Proponuję wykorzystać do tego dobrodziejstwo gotowych, dostępnych ram postępowania, jak np. SCRUM. Mówiąc krótko – starajmy się najczęściej jak się da prezentować klientowi efekty naszej pracy. Najlepiej, jeśli możemy pokazać działające oprogramowanie. W trakcie takich prezentacji zbierajmy od klienta informację zwrotną, czy to co zrobiliśmy jest ok. Czy idziemy w dobrym kierunku? Czy właśnie się przypadkiem nie mijamy z jego oczekiwaniami? Jeśli okaże się, że coś robimy niezgodnie z wizją klienta, to od razu po takiej prezentacji możemy to skorygować, czy wręcz przeplanować całą naszą dalszą pracę. Angażując klienta w taką aktywność, cały czas „trzymamy rękę na pulsie”. Dzięki temu cały czas mamy pewność, że podążamy za jego wymaganiami.
Chciałbym jeszcze raz nawiązać do wspomnianego wcześniej podziału klientów na zewnętrznych i wewnętrznych. Zrobiłem to celowo, ponieważ miałem okazję współpracować z zespołami o różnym typie klienta. W przypadku teamów pracujących bezpośrednio dla klienta zewnętrznego kilkukrotnie zetknąłem się z obawą, że częste angażowanie go w spotkania może być obciążające czy wręcz irytujące. Zgadzam się. Klient może tak zareagować (i w rzeczywistości często reagował), zwłaszcza na początku, gdy nie dostrzegał w tym korzyści dla siebie. I wtedy z pomocą przychodził nam omawiany już pierwszy punkt manifestu. Po prostu uzgadnialiśmy z klientem, jak często i po zakończeniu których elementów produktu będziemy go zapraszali na prezentację tak, aby nie było to dla niego kłopotem. Nie zdarzyło się, aby któryś z klientów po doświadczeniu takiego podejścia, był niezadowolony. Wręcz przeciwnie, czuł, że rzeczywiście jest słuchany i że reagujemy na jego potrzeby, a produkt, który powstaje, to jest właśnie „TO”.
Z drugiej strony zespoły, które pracowały dla klienta wewnętrznego, miały tendencję do ignorowania go. Nie było świadomości, że nasi firmowi koledzy zza ściany to nasi klienci i że im również warto, tak często jak się da, pokazywać efekty naszej pracy. Kiedy zaczęliśmy zapraszać ich na swoje podsumowania sprintów i prezentować, co wykonaliśmy, stał się cud. Informacja zwrotna popłynęła jak rzeka, a problem integracji niemalże przestał być dostrzegalny. Dlaczego? Bo np. jeżeli zademonstrowaliśmy, że interfejs usługi, którą im dostarczymy w przyszłości, ma taką a nie inną postać, to oni mogli już do tego interfejsu dostosowywać swój kod. Mogli również prosić o zmianę interfejsu, bo taki, jaki przygotowaliśmy, nie spełnia ich oczekiwań.
Chciałbym, abyś wziął dla siebie z tego punktu manifestu, że: „jeśli jeszcze tego nie zrobiłeś, to zacznij współpracować z klientem”. Pamiętaj jednak, że spotkania, na których będziesz mu prezentował kolejne efekty swojej pracy, to nie jest wyłącznie „show”. Nie mogą kończyć się na zaprezentowaniu produktu. Musi tam się wydarzyć coś jeszcze: INTERAKCJA. Klient musi dać Ci informację zwrotną, czy to, co robisz, jest ok. A jeżeli nie jest, to jak ma być, żeby było ok. Wyposażony w taką wiedzę będziesz mógł cały czas podążać za potrzebą klienta. I tutaj na horyzoncie pojawia się kolejny punkt manifestu, o którym w następnym wpisie.