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?
Świetny post, poruszasz w nim fundamentalną kwestię. Kwestię, która „dla każdego jest ważna”, ale jednak w codziennej praktyce często zaufanie (starania o nie) ginie gdzieś między kolejnymi oskarżeniami i deadlineami.
Rzeczywiście szczególną role odgrywa tu właściciel produktu. Jednocześnie każdy członek teamu, mgmt musi znaleźć w sobie dużo empatii, mieć dobrą, otwartą postawę i starać się uczyć tego samego innych dookoła (swoim podejściem pokazywać, że się da i jest dobrze). No i cierpliwość jest bardzo ważna. Dobre teamy rzadko kiedy są dobre od samego początku ;-)
Stasiu, ważne to co piszesz. I wierzę w to podejście. W moim obecnym projekcie miałam szczęście (i satysfakcję) uczestniczyć w ewolucji zespołu z trzypoziomowej akceptacji dokumentów analizy (wnoszącej fikcyjne potwierdzenie, że wiemy o czym mówimy i stanowiącej w istocie sztuczną 'podkładkę’, bo 'przecież ktoś to akceptował’) ku wspólnemu z zespołem omawianiu potrzeb i dochodzeniu do możliwie najlepszych rozwiązań. To łączy, buduje, angażuje, daje wartość. Naprawdę nie potrzeba cudzych podpisów pod nieudanymi rozwiązaniami. Potrzeba dobrych, wartościowych rozwiązań.
Autor artykułu ma zasadniczo racje co do tego, że zaufanie jest podstawą sukcesu rozumianego jako zadowolenie końcowego użytkownika.
Nie mniej jednak nie do końca odpowiedział na wyzwania poruszane na wstępie – kwestia umowy. Realizowałem wiele projektów dla centralnej i wojewódzkiej administracji publicznej. Niezależnie od budowy zaufania pomiędzy dostawcom a klientem jest jeszcze umowa. Klient nie może jej dowolnie zmieniać i interpretować z uwagi na prawo o Zamówieniach Publicznych. Jeśli cokolwiek tam zapisano to MUSI być zrealizowane, nawet jeśli w to miejsce moglibyśmy zrobić 10 lepszych rzeczy, które podsunie nam klient w czasie scrumowej pracy nad projektem. Umowa często prowadzi do przepalania czasu na nikomu niepotrzebne pierdoły kosztem wartościowych rzeczy. Obie strony tkwią tu w pułapce ustawy o zamówieniach publicznych. Reprezentant klienta podlega kontroli NIK, przełożonych oraz konkurentów, którzy przegrali przetarg. Nie podpisze protokołu odbiory jeśli nie będzie w zadanym czasie zrealizowane wszystko z zapytania ofertowego i umowy. Narażałby się na karę i dyscyplinarce. Może co prawda w różnym stopniu podchodzić do weryfikacji pewnych elementów systemu, ale nadal jest dość mocno ograniczony co do zakresu. Budżet i czas też jest przyklepany i niezmienalny (np. kasa pochodzi z UE i musi być wydana do określonej daty). Za zmiany terminów lecą kary umowne.
Dlatego też uważam, że metodyka Scrum (w zakresie zarządzania backlogiem i terminem) jest mocno ograniczona w tego rodzaju projektach i nie może pokazać pełni siły. Zalecałbym ostrożność w forsowaniu podejścia Scrum dla tego rodzaju projektów z uwagi na bardzo ograniczoną elastyczność klientów (niezależnie od zaufania, które może się zrodzić w codziennej współpracy).
Dodam jeszcze, że umowy pisane są często z harmonogramami pod klasyczny Waterfall.
Wydaje mi się, że skuteczniejsze będzie dążenie do zmiany ustawy o zamówieniach publicznych (na pro Agile) niż przekonywanie kursantów jak mają działać Agile w świecie Waterfall (polegną).
Dziękuję za komentarz!
Celem artykułu (ani szkolenia) nie było przekonanie kursantów, że mają od razu „robić agile w świecie waterfall”. I rozumiem ograczenia płynące z prawa o zamówieniach publicznych.
Bardziej chciałem zwrócić uwagę na sytuację, którą obserwuję – firma tak bardzo żyje w świecie pernamentnego braku zaufania, że staje ten brak zaufania staje się normą dla pracowników. A wówczas wszelkie próby wdrożenia Lean’ów, Kanban’ów czy Scrum’ów są bardzo trudne.
I jeszcze jedna ciekawostka.
W grudniu zeszłego roku pojawiła się „Opinia prawna w sprawie możliwości i sposobu wykorzystania metodyki Agile w projektach informatycznych realizowanych z zastosowaniem ustawy – Prawo zamówień publicznych”. Można ją pobrać tutaj.
Ten dokument pokazuje różne mechanizmy, które pozwalają na realizację projektów IT w sektorze publiczym zgodnie ze zwinnymi metodykami wytwarzania.
I pozwolę sobie wkleić mały cytat:
Pośród najczęstszych sygnalizowanych wyzwań związanych z realizacją takiego projektu wymienia się w szczególności: konieczność zmiany nawyków personelu administracyjnego odpowiedzialnego za realizację projektów informatycznych na rynku publicznym, utrwalonych w efekcie wieloletnich przyzwyczajeń tego personelu do zasad kaskadowego modelu realizacji projektów informatycznych.