Umowy i zaufanie

Ostatnio miałem przyjemność prowadzić szkolenie na temat zwinnego wytwarzania oprogramowania dla pracowników jednej z dużych firm informatycznych. W trakcie gdy mówiłem, widziałem w twarzach uczestników narastającą konfuzję i zwątpienie. Aż wreszcie jeden z nich wypowiedział to, co nurtowało zapewne ich wszystkich: „Ale czy w ogóle można tak pracować? A gdzie umowa z klientem? A gdzie wpisujemy zakres prac? A ustawa o zamówieniach publicznych? A jaki klient na to pójdzie?”.

No właśnie. Jeżeli wczytamy się w manifest i zasady zwinnego wytwarzania oprogramowania, znajdziemy tam takie stwierdzenia: „współpraca z klientem zamiast negocjacji umów”, „bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju”, „zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu”. Nietrudno zauważyć, że rzeczą absolutnie niezbędną do realizacji tych zasad jest wzajemne zaufanie pomiędzy klientem i dostawcą rozwiązań IT.

Na czym polega to zaufanie? Na tym, że wyznaczamy generalny kierunek prac lub też pożądany zarys produktu – ale z góry zakładamy, że może wystąpić wiele czynników, które będą wymagały zmiany założeń. Klient może zmienić zdanie. Dostawca może dokonać zmian wynikających z uwarunkowań technologicznych. Klient i dostawca ufają sobie, że nie wykorzystają tej przestrzeni wolności w niewłaściwy sposób.

Wątpliwości uczestników szkolenia wynikały przede wszystkim z tego, że na co dzień pracują oni w zupełnie innym świecie. Pracują się w świecie, w którym zakres oraz cenę wykonywanych prac wyznacza Umowa. W świecie, w którym odstępstwo lub niezrealizowanie któregoś z paragrafów Umowy grozi sporem, karami finansowymi czy też nasyłaniem na siebie prawników. W świecie, w którym klient obawia się o to, że dostawca obierze go z pieniędzy i jednocześnie nie dostarczy tego, czego klient potrzebuje. W świecie, w którym dostawca obawia się, że klient zapłaci za Dacię, a będzie chciał otrzymać Porsche. W świecie, w którym panuje permanentny kryzys zaufania.

Łatwo zauważyć z czego wynika to zaufanie do umów: jest to proste przeniesienie zasad ze świata wytwarzania produktów oraz prostych usług. Jeżeli mam do wykonania prostą usługę – na przykład pomalowanie pokoju – to prosto jest określić zakres prac, efekt końcowy, termin oraz cenę. Dzwonię do malarza, mierzymy metry kwadratowe, określamy stawkę za metr i umawiamy się na termin wykonania pracy.

Inaczej jest, kiedy przy realizacji zlecenia pojawia się pierwiastek zmienności. Kilka lat temu robiłem remont starego domu. Wraz z ekipą remontową obejrzeliśmy stan wyjściowy i zawarliśmy umowę precyzującą zakres prac oraz cenę – ale wszyscy mieli świadomość, że obie te rzeczy bazują na dość kruchym założeniu, że wszystko potoczy się zgodnie z planami. Oczywiście – nie potoczyło się. Rura doprowadzająca wodę była w innym miejscu i trzeba było ją przekładać, fundament pod budynkiem był zbyt mały i trzeba było go pogłębiać, trzeba było zastosować dodatkowe zabezpieczenie przeciw wilgoci, i tak dalej, i tak dalej. Sami też zaproponowałem kilka zmian w projekcie. To wszystko oczywiście miało wpływ na cenę, którą finalnie zapłaciłem – ale obie strony były w pełni świadome, z czego te zmiany wynikają. I nie dałoby się tego zrobić, gdyby nie wzajemne zaufanie – moje zaufanie, że ekipa budowlana nie chce mnie naciągnąć na dodatkowe koszty oraz zaufanie ekipy, że zapłacę im za dodatkowe, nieplanowane wcześniej zadania.

Bazowanie na Umowie – czyli na tym, że uda nam się dokładnie wyspecyfikować efekt końcowy prac oraz cenę – jest zamykaniem oczu na tę zmienność i próbą udawania, że ona w ogóle nie istnieje! „Na pewno w ciągu sześciu miesięcy realizacji naszego projektu nie zmienią się nasze potrzeby, nie odkryjemy żadnych pułapek w zakładanej technologii oraz nie zmieni się rynek i potrzeby klientów wokół nas”. To bardzo piękne założenie, ale niestety bardzo rzadko sprawdza się w praktyce…

Nie jesteśmy w stanie zmienić ustawy o zamówieniach publicznych ani praktyk w dużych korporacjach. Ale pracując w swoich projektach możemy pomyśleć chwilę o tym, na ile w codzienności naszych projektów przejawia się zaufanie lub jego brak. Ile razy w ciągu ostatniego czasu słyszeliśmy stwierdzenia typu: „to IT znowu nie dostarczyło na czas”, „klient znowu zmienił swoje wymagania”, „ta funkcjonalność cały czas nie działa tak, jak powinna” czy „znowu dowiadujemy się o tym za późno”.

Budowanie zaufania jest szczególnym zadaniem właściciela produktu. To on jest osobą spinającą klienta i udziałowców wraz z zespołami deweloperskimi. Jeżeli właściciel produktu staje po jednej ze stron, to znaczy jeżeli mocno identyfikuje się z klientem lub z dostawcą – to szanse na budowanie wzajemnego zaufanie mocno maleją.

Co można zrobić, żeby budować to zaufanie? Przede wszystkim wzajemnie się słuchać! Właściciel produktu musi zapewnić, że klient wie, co dostawca robi – a dostawca rozumie, czego klient potrzebuje. Jest to zresztą wprost zapisane w Scrum Guide:

Pojęcie zarządzania Backlogiem Produktu mieści w sobie:

• zapewnienie, że Backlog Produktu jest dostępny, przejrzysty oraz jasny dla wszystkich, a także, że dobrze opisuje to, czym Zespół Scrumowy będzie się zajmował w dalszej kolejności,
• zapewnienie, że Zespół Deweloperski rozumie elementy Backlogu Produktu w wymaganym stopniu.

Ale samo wzajemne wysłuchanie to jeszcze nie wszystko. Można się świetnie rozumieć, a jednocześnie nie ufać, że cele zostaną zrealizowane. I tutaj zespół deweloperski nie ma lepszej drogi na zdobycie tego zaufania niż częste i regularne dostarczanie kolejnych wersji systemu. Jeżeli zespół jest w stanie co miesiąc lub krócej pokazywać kolejne fragmenty systemu – klient powoli nabiera zaufania, że poruszając się w stałym tempie osiągniemy na koniec wyznaczony rezultat. Najczęściej początki są trudne, nierzadko klient nie chce przychodzić na prezentację (czy też Scrum’owy przegląd sprintu) argumentując „nie interesuje mnie prezentacja części funkcjonalności, chcę zobaczyć cały system”. I tutaj kluczowym zadaniem właściciela produktu jest zachęcenie przedstawicieli klienta do aktywnego udziału w cyklicznych przeglądach.

Oprócz edukacji ważne jest też przyglądanie się codziennym relacjom między zespołem biznesowym czy deweloperskim. Jak członkowie zespołów odnoszą się do siebie? Czy komunikują się przez maile czy bezpośrednio? Czy traktują dokumentację jako podkładkę (to ładniejsze słowo niż dupokrytka…) w razie potencjalnego konfliktu? Czy pomagają sobie, czy bardziej zrzucają na siebie problemy?

I na koniec dobry przykład. Ciekawie opisaną koncepcję współpracy można znaleźć na stronach Tomka Włodarka – jest tam kontrakt widziany od strony klienta oraz kontrakt widziany od strony dostawcy.

A jaki jest poziom wzajemnego zaufania przy wytwarzaniu Twojego systemu?