Współpraca z klientem jest kluczem do pomyślnej realizacji projektu – być może zdanie to słyszeliśmy już tak wiele razy, że przestaliśmy przywiązywać do niego szczególną uwagę. To w jakiś sposób naturalne, że będąc na kolejnym spotkaniu, w trakcie którego powtarzane jest, że rozmowa i współpraca z klientem jest najważniejsza, powszednieje nam istota i głębia tego przesłania. To wielki błąd!
Po pierwsze, rozmowa
Podczas mojej ponad 6-letniej pracy w roli Scrum Mastera widziałem wiele projektów i współpracowałem z wieloma zespołami. Projekty te różniły się między sobą wielkością, doświadczeniem czy narodowością członków zespołów. Mimo wielu różnic wszystkie projekty łączyła jedna cecha. Te, w których klient był zaangażowany, a pomiędzy zespołem a klientem istniała niezakłócona nić komunikacji, osiągały lepsze wyniki i dostarczały lepszy jakościowo produkt.
Co na to Manifest Agile?
Przypomnę w tym miejscu Manifest Agile, który jest niejako protoplastą Scruma i fundamentem zwinnych metod wytwarzania oprogramowania:
„Odkrywamy nowe metody programowania dzięki praktyce w programowaniu
i wspieraniu w nim innych. W wyniku naszej pracy
,zaczęliśmy bardziej cenić:
- Ludzi i interakcje od procesów i narzędzi
- Działające oprogramowanie od szczegółowej dokumentacji
- Współpracę z klientem od negocjacji umów
- Reagowanie na zmiany od realizacji założonego planu
.Oznacza to, że elementy wypisane po prawej są wartościowe, ale większą wartość mają dla nas te, które wypisano po lewej.”
Zwróćmy uwagę, że aż 3 z 4 pogrubionych (znajdujących się po lewej stronie) punktów dotyczą interakcji międzyludzkich, współpracy z klientem i reagowania na zmiany – które sprowadzają się tak naprawdę do jednego słowa – rozmowa. Bez rozmowy z klientem będzie nam niesamowicie trudno stworzyć działające oprogramowanie – czyli tak naprawdę to, co jest faktycznym celem prowadzenia projektu IT.
Zespół Deweloperski w Scrumie a klient. Jak zadbać o dobre relacje w trakcie pracy nad produktem?
Nie będzie niczym odkrywczym, gdy napiszę, że podczas pracy nad produktem ważne są relacje. Dotyczą one oczywiście nie tylko samego Zespołu Deweloperskiego czy patrząc szerzej – Zespołu Scrumowego. Każdy pojedynczy członek zespołu prędzej czy później będzie dokonywał interakcji z szeroko pojmowanym klientem. Jeśli zastanawialiśmy się nie tylko nad tym, jak zbudować relacje, ale przede wszystkim, na czym je oprzeć, wówczas z pomocą przychodzi sam Scrum Guide. Autorzy Przewodnika po Scrumie piszą:
„Aby stosowanie Scruma mogło przynosić pożądane efekty, członkowie zespołu muszą doskonalić się w postępowaniu według pięciu wartości, jakimi są:
Zaangażowanie, Skupienie, Otwartość, Szacunek, Odwaga”
Powyższe pięć wartości jest na tyle uniwersalne, że stosowane mogą być zarówno w życiu zawodowym, jak i prywatnym. Stosując je, przyczyniamy się do wzrostu zaufania i uczciwości, które to z kolei są niczym innym jak synonimem zwrotu „dobre relacje”.
Deweloper a relacje z klientem
Programista często kojarzy się z zawodem, w którym nie liczą się umiejętności miękkie, a tylko kod, który wyjdzie „spod palców” pracownika. Postrzeganie dewelopera jako „stereotypowego informatyka” jest nie tylko błędne, ale i krzywdzące.
Obecnie deweloper musi posiadać rozwinięte umiejętności miękkie oraz komunikacyjne, aby nie tylko porozumiewać się wewnątrz zespołu, ale także z przedstawicielami klienta, czyli stakeholderami. Istnieje wiele zagadnień lub tematów, w których Product Owner może prosić Zespół Deweloperski, aby wytłumaczył techniczne tematy w sposób przystępny dla biznesu.
Nawiązanie dobrych relacji z klientem wydaje się kluczowe dla wspólnego zrozumienia i zaufania. Klient bardzo często chce i musi uwierzyć na słowo, że np. zaproponowane przez zespół rozwiązanie techniczne zajmie więcej czasu, ale w perspektywie długoterminowej będzie korzystne biznesowo.
Współpraca z biznesem: najczęstsze wyzwania w trakcie rozwoju oprogramowania
Zwinne podejście do rozwoju oprogramowania lub patrząc węziej – adaptacja Scruma staje się w dzisiejszych czasach coraz bardziej popularna zarówno w małych firmach, jak i ogromnych korporacjach. I słusznie, gdyż właśnie Agile, w przeciwieństwie do tradycyjnego Waterfalla jest odpowiedzą na szybko zmieniający się świat i otoczenie biznesowe.
Pamiętajmy, że samo wprowadzenie Scruma do organizacji nie spowoduje natychmiastowych zmian na lepsze. Sama zwinność jest sposobem myślenia i działania. Nie bałbym się użyć także stwierdzenia – filozofią, którą kierują się wszyscy uczestnicy procesu wytwarzania oprogramowania.
Procesy, paradoksalnie, zmienić można stosunkowo szybko – wystarczy wola osób decyzyjnych, lecz sposobu myślenia (ang. mindset) nie zmienimy w ciągu chwili. To proces, który może trwać bardzo długo.
Nie inaczej jest podczas współpracy z klientem. Nie możemy oczekiwać, że biznes, przyzwyczajony przez wiele lat do stosowania praktyk micromanagementu, w ciągu jednego dnia zmieni swoje nastawienie i zaufa, że zespół jest w stanie samozarządzać się.
Przeczytaj także: Samozarządzanie to zarządzanie przyszłości
Pomyślmy, że to, co dla nas jest oczywiste, dla osób mających inne wzorce, kulturę organizacyjną lub doświadczenia zawodowe, może być kompletnie obce i niezrozumiałe. Dajmy sobie czas i przestrzeń na zmiany. Zmiana, jak i nawiązanie relacji nie przychodzi z dnia na dzień – jest drogą, która nierzadko jest kręta i wyboista.
Bez klienta projekt się nie uda
Teza zawarta w tym punkcie może być dość radykalna, lecz moje doświadczenie wskazuje, że jest także prawdziwa. Praca w Scrumie bez zaangażowanego klienta nie ma sensu.
Widziałem wiele zespołów tylko pozornie pracujących w Scrumie. Były Sprinty. Był Sprint Review, na którym zespół prezentował wykonaną pracę. Był Sprint Planning, podczas którego zespół starał się zaplanować pracę na nadchodzący Sprint. Było Daily, na którym zespół sprawdzał postępy w realizacji Celu Sprintu. Ostatecznie jednak wszystkie wysiłki spełzły na niczym, gdyż klient uznał, że sama praca w Scrumie przyniesie upragniony efekt w postaci dobrze działającej aplikacji. Niestety, bez zaangażowania klienta, który będzie odpowiadać na dziesiątki pytań Product Ownera, bez interesariuszy, którzy na Sprint Review oceniają to, co zostało zrealizowane – nawet najlepszy zespół poniesie porażkę.
Scrum Master a relacje z klientem
W moim odczuciu jedną z odpowiedzialności Scrum Mastera jest nawiązanie dobrej relacji z klientem. Jest to napisane w Scrum Guide, lecz nie bezpośrednio. Przytoczmy zatem cytat:
Scrum Master wspiera organizację na różne sposoby, m.in.:
- przewodzi organizacji, szkoli i instruuje ją w procesie wdrażania Scruma;
- planuje i doradza w wykorzystaniu Scruma w organizacji;
- pomaga pracownikom i interesariuszom w zrozumieniu oraz stosowaniu empirycznego podejścia do złożonych problemów
Jeśli Scrum Master pracuje dla organizacji klienta, wówczas wszystkie powyższe aktywności nie tylko pomagają we wdrażaniu i zrozumieniu Scruma, ale także wpływają na rozwój relacji z klientem opartej na wzajemnym zrozumieniu i poszanowaniu.
Przeczytaj także: Artefakty Scruma
Podsumowanie
Myślę, że podsumowaniem moich rozważań dotyczących budowania relacji z klientem może być 5 poniższych punktów, które także bezpośrednio mogą wpływać na zaangażowanie klienta w prace projektowe:
1. Rozmowa – bez rozmowy opartej na szczerości i zaufaniu nie zbudujemy dobrych podstaw do jakiejkolwiek współpracy. Mogę napisać, że realizacja projektów IT na każdym etapie opiera się właśnie na rozmowie.
2. Uczestniczenie w spotkaniach – warto, aby Scrum Master zaprosił interesariuszy na Review i wytłumaczył istotę spotkania, a także fakt, dlaczego ich informacja zwrotna podczas spotkania jest tak bardzo istotna. Jednym z czynników, które najbardziej motywują ludzi do pracy, jej sens jej wykonania. Zespół Deweloperski, widząc zadowolonych i zaangażowanych w rozwój produktu stakeholderów, na pewno będzie miał jeszcze więcej motywacji i chęci do wspólnej pracy.
3. Odpowiedzi na pytania Zespołu Deweloperskiego – uczestniczenie w spotkaniach to jedno, lecz odpowiadanie na pojawiające się pytania – to drugie. Zaangażowany klient wie i rozumie, że pojawiające się pytania się wyrazem otwartości i dbałości Zespołu Deweloperskiego o produkt, nad rozwojem którego razem pracują.
4. Ocena prac Zespołu Deweloperskiego – mając dobrze nawiązane relacje, możemy liczyć na szczerość i otwartość. Systematyczny feedback jest niezbędny, aby korygować naszą pracę i motywować się do zmian i ulepszeń. Pamiętajmy o tym, aby doceniać się wzajemnie! Dobre słowo, gratulacje czy publiczne uznanie bardzo wpływają na wysokie morale.
5. Integracja, czas na poznanie się – praca zdalna na stałe zagościła w naszej branży. Jednak nic nie wpływa tak dobrze na budowanie relacji i zaangażowania jak osobiste spotkanie i czas na wspólne poznanie się. Nie oszukujmy się – lubimy bardziej te osoby, z którymi mieliśmy okazję porozmawiać twarzą w twarz. Wykorzystujmy każdą szansę na możliwą integrację – to jest zawsze dobrze zainwestowany czas 🙂
Scrum Master w Inetum. Wierzy w empiryzm i iterację, uczy Zespoły Scrumowe samodzielności i odpowiedzialności. Poza pracą Łukasz jest taternikiem i wspinaczem, a także autorem portalu Tuudi.net.