Budowanie zaufania jako software house

Porządny Agile

Jak budować zaufanie z klientem? To pytanie, które nurtuje wiele firm, zwłaszcza w branży IT, gdzie relacje z klientem odgrywają kluczową rolę. Dla software house’ów, które chcą utrzymać solidne relacje z klientami, zaufanie jest fundamentalne.

Porządny Agile · Budowanie zaufania jako Software House

Obejrzyj nagranie na YouTube

Transkrypcja podcastu „Budowanie zaufania jako software house”

Jacek: Prowadziliśmy ostatnio wspólnie z Kubą warsztaty dedykowane dla firmy typu software house. Pośród poruszanych tematów jednym z nich było zaufanie, które budujemy z klientem zewnętrznym. Uznaliśmy z Kubą, że jest to na tyle ciekawy temat, że chcemy się nim z tobą podzielić.

Kuba: Temat jest bardzo dookreślony do pewnej konkretnej grupy firm, ale czuję też, że będzie to dosyć ciekawa inspiracja również dla osób czy firm, które nie mają tej relacji klient-dostawca. No bo jak odpowiednio zmrużyć oczy to relacje między wewnętrznym IT w bardzo dużej korporacji a jakimś biznesem, partnerami czy innymi rynkami z innych krajów mogą być bardzo, bardzo bliskie na tyle, że duża część z naszych rekomendacji również będzie inspiracją, nawet jeśli w twoim konkretnym przypadku nie jesteś częścią software house.

Kuba: Odcinek będzie miał spis treści, bardzo krótki. Zaczniemy od zdefiniowania zaufania, żebyśmy wiedzieli, o czym w ogóle to mówimy. Po czym podamy cztery przykładowe aspekty budowania zaufania w software house.

Jacek: Startując, spróbujmy zdefiniować czym jest zaufanie. Jest to pewne przekonanie, że można na kimś polegać, że ta konkretna osoba będzie postępować zgodnie z naszymi oczekiwaniami, wyobrażaniami, wartościami i będzie wywiązywać się z jakichś zobowiązań.

Kuba: Moja definicja zaufania jest ciutkę inna w niuansach. Dla mnie zaufanie to jest wiara w przewidywalność zachowań osoby, z którą mam relacje zaufania. Takie zaufanie bazuje albo na wiarygodności, lub na dotychczasowych dobrych doświadczeniach współpracy z tą konkretną osobą.

Jacek: No i w realiach pracy w firmach typu software house zaufanie to jest coś, co chcemy pielęgnować, coś, co chcemy rozwijać z tego względu, że jest to bardzo istotna i ważna płaszczyzna, która buduje bardzo przyjazne warunki do współpracy.

Kuba: To przejdźmy do zasadniczej części nagrania, w której powiemy, jak można takie zaufanie budować. I podzieliliśmy to na cztery aspekty, cztery takie grupy pojęciowe, w których mamy konkretne rekomendowane praktyki, czy konkretne podpowiedzi jak to zaufanie budować.

Kuba: Pierwszym tym aspektem jest wiarygodność. Jak można budować wiarygodność w tym konkretnym kontekście?

Jacek: Pierwsza rekomendacja w obszarze wiarygodności brzmi: Spełniaj złożone obietnice. Jest to dosyć pojemny punkt, pod który można podpiąć wiele różnych zachowań. No ale na koniec dnia chodzi o to, że jeżeli obiecamy, że coś zrobimy, że coś zrealizujemy, że czegoś dopilnujemy, no to tak naprawdę powinniśmy zadbać o to, żeby ta złożona obietnica została, mówiąc potocznie, dowieziona. Czyli przykładowo, jeżeli obiecaliśmy klientowi, że przygotujemy draft projektu i umówiliśmy się, że ten draft projektu wyląduje u klienta na skrzynce mailowej do jakiejś konkretnej daty, czy do jakiejś konkretnej godziny, no to spełnieniem złożonej obietnicy jest oczywiście wywiązanie się z takiej obietnicy.

Kuba: I tutaj te złożone obietnice, dowiezione, jak to powiedziałaś, budują takie wrażenie niezawodności, budują też takie przeczucie, że mogę na tobie polegać. Mogę polegać na Twoim zespole, mogę na Tobie polegać jako części firmy. Mogę polegać jako na przykład klient zewnętrzny na Twojej firmie jako dostawcy. Takim najmocniejszym przykładem i takim bardzo też często do poprawy zagadnieniem jest przewidywalność działań. Czyli zespoły, które pracują nad jakimiś działaniami projektowymi, czy rozwojowymi dla klienta mogą składać obietnicę, czy obiecywać, czy projektować, czy przewidywać, że coś zrobią, dostarczą jakiś ficzer na jakąś datę, dostarczą zawartość Sprintu albo Cel Sprintu, jeśli pracują z Scrumem, po czym te obietnice nie są dostarczane i to nie są dostarczane w taki, bym powiedział, spektakularny sposób. To nie buduje zaufania. Czyli odwracając, częścią zaufania jest składanie obietnic, które później mają pokrycie i robienie wszystko, żeby to dowiezienie potocznie mogą właśnie uzyskać.

Jacek: Przewidywalność jest czymś, czego na bazie naszych doświadczeń firmy poszukują, dlatego robimy takie programy, w których pomagamy poprawić przewidywalność procesu wytwarzania. Przykładowo jednego z moich klientów dzięki takiemu wsparciu, które trwało 3 miesiące, zespół poprawił przewidywalność z 43% do 78%. Więc jeżeli temat przewidywalności jest dla Ciebie ważny, to zachęcamy do kontaktu przez formularz na stronie porzadnyagile.pl/kontakt

Kuba: Drugim zagadnieniem, które wspomnimy w temacie budowania zaufania poprzez wiarygodność, jest komunikowanie w przewidywalny sposób. Chodzi tu o to, by komunikacja dowolnego typu, czy to taka bardzo operacyjna, niskopoziomowa, jak i ta najwyższego rzędu, taka firma do firmy, czy liderzy projektu do liderów dostawców, była przeprowadzona w pewnym standardzie jakościowym, jeśli chodzi o po prostu zawartość tej komunikacji, punktualność, responsywność i taka szeroko rozumiana spójność o pewnej obietnicy na temat rzetelności partnera.

Jacek: No byłoby źle, gdyby klient piszący do nas maila musiał na odpowiedź czekać jakoś długo albo w taki nieprzewidywalny sposób długo. Czyli jeżeli cały czas odpisywaliśmy szybko i nagle bez podania jakiejś sensownej przyczyny przestajemy odpisywać albo raz jest szybko, raz jest ten czas oczekiwania wydłużony, może to powodować takie poczucie, że nie do końca klient może na nas polegać, bo raz robimy tak, raz robimy tak i tak naprawdę nie ma sensownego wytłumaczenia. Pewnym rozwiązaniem tego problemu może być na przykład jakaś informacja wyprzedzająca do klienta, że rozpoczyna się jakieś działania w naszej organizacji czy w zespole, która może obniżyć responsywność. Przykładowo wyjeżdżamy na wyjazd integracyjny, czy jest jakaś impreza, która dzieje się w organizacji no i po prostu nie będziemy odpisywać tak, jak to zwykle robiliśmy. No jakby tutaj jasność tego, zakomunikowanie tego z wyprzedzeniem, co jak słyszysz jest dosyć prostą generalnie techniką, może zmienić postrzeganie tego jak my się zachowujemy w oczach naszego klienta.

Kuba: I użyliśmy przykładu maila, ale to tak naprawdę jest komunikacja dowolnego typu, zarówno komunikacja taka bezpośrednia lub pośrednia, ale na spotkaniach jakieś wideo, jak i komunikacja na chatach, czy komunikacja w narzędziach do pracy elektronicznej. Wszędzie te zasady tutaj spójności i przewidywalności tego, czego się można po naszym zespole, po każdym ze specjalistów w jego skład wchodzącym, czego się można spodziewać, żeby to było do jakby przewidzenia i żeby to było w miarę w spójny sposób dostarczone.

Jacek: Mówiliśmy o wiarygodności, teraz przejdziemy płynnie do aspektu komunikacyjnego i w tym obszarze przede wszystkim myślimy o takiej rekomendacji, żeby informować o ryzykach i o problemach na bieżąco. Na bazie moich doświadczeń w pracy w software house’ie myślę, że ona nie ma niczego gorszego niż postawienie klienta w takiej sytuacji, gdzie o konkretnych problemach dotyczących jego projektu dowiaduje się gdzieś tam na końcu i niestety bywałem świadkiem takich sytuacji. Najczęstszy komentarz, który słyszy się wtedy od klienta, to jest coś w stylu „Przecież mogliście powiedzieć mi to wcześniej, dlaczego tego nie zrobiliście?”. Zespół zwykle reaguje czymś w stylu „Myśleliśmy, że się uda”, albo „Nie chcieliśmy denerwować klienta” i jakieś takie tam różne. Różne mogą być powody. Natomiast to zawsze ma krótkie nogi, w sensie to nigdy nie jest dobry pomysł, żeby takie rzeczy zataić, więc budowanie komunikacji, która zarówno niesie pozytywne informacje, jak i wszelkiego rodzaju ryzyka, zagrożenia, rzeczy, które nie wyszły, jest bardzo istotnym fundamentem budowania długofalowego zaufania z klientami.

Kuba: Ja w relacji klient-dostawca o wiele częściej jestem po stronie zamawiających i to też jest często bardzo gołym okiem widoczne, że te tak naprawdę obietnice, że wszystko jest dobrze, że nie ma problemów, że idzie dobrze, że sobie poradzimy, że się gdzieś tam wyrobimy, to już z mowy ciała, to już z mikrozawahań pomiędzy zdaniami już wynika, że coś się zaczyna śmierdzieć. No ale tak naprawdę jest jakaś taka, zwłaszcza przy rozpoczynającej się współpracy, jakaś taka niepewność, co do tego jak zachowa się druga strona, a myślę, że jednak my tutaj obaj mocno rekomendujemy, zbuduj tę rzetelność na wczesnym ostrzeganiu, na jasnym powiedzeniu jak sprawy się mają. Coś, co może być też nawet wręcz taką ważną postawą, taką partnerską wspólnego rozwiązywania pewnych problemów, zwłaszcza jeśli jakieś nadciągające ryzyka są tak naprawdę do rozwiązania obustronnie. Czyli jakąś tam porcję pracy ma do wykonania zespół wykonawczy, ale być może jakąś część działań jest po stronie klienta i im wcześniej się zacznie o tym szczerze rozmawiać, tym większa szansa, że dla wspólnego sukcesu rozwiąże się to szybciej. No albo niestety w tym alternatywnym scenariuszu, tak się dosyć szybko zepchniemy w taką przepychankę, że wasza wina, nasza wina, nie powiedzieliście nam i to już źle wróży na dalszą współpracę.

Kuba: Druga kwestia związana z komunikacją, którą rekomendujemy, to „Dziel się informacją zwrotną”. Tutaj też to wzajemne zaufanie budowane jest poprzez takie dotarcie się, a to dotarcie się oczywiście będzie budowane na bazie informacji zwrotnej. I nie mamy na myśli tutaj tylko i wyłącznie mówienie sobie, co mogłoby się poprawić, ale również takie docenianie się wzajemne na to, co działa, co doceniamy, co nam pomaga, co sprawia, że ta relacja buduje się coraz lepiej. Jest na to szereg konkretnych praktyk, które tutaj zaraz Jacek kilka wymieni.

Jacek: Tak, bo przede wszystkim myślę, że to jest tak, w zależności od tego, jak blisko jesteśmy z klientem, jak formalna bądź nieformalna jest ta relacja, no to te formy mogą przybierać no najróżniejszą postać. Myślę, że taka najbardziej oficjalna to jest forma pisana, ona może się pojawić no najczęściej w formie właśnie jakiegoś maila, czy to na chatach rzadziej takie rzeczy spotykałem, no i ona ma swoją jakąś tam wartość niewątpliwie. Natomiast pewnym minusem jest to, że dostajemy bardzo suchy komunikat, no i jakby sporo zależy od tego, jak go zinterpretujemy. Jeśli nałożymy na to filtr kulturowy, no to np. informacja zwrotna pochodząca od osób z Londynu może brzmieć bardzo dobrze, a tak naprawdę wcale nie, tak bardzo dobrze nie jest. Więc pod okrągłymi słowami mogą kryć się czasem rzeczy, których no nie wyłapiemy na pierwszy rzut oka. No i z tej perspektywy feedbackowanie słowne, bardziej na zasadzie rozmowy, czy to rozmowy wideo, czy rozmowy audio, idealnie jak jest to jest rozmowa face to face, no bo oczywiście wtedy trochę więcej sygnałów możemy odczytać, no jest lepsza, można dopytać, można sparafrazować, można poprosić o jakiś konkretny przykład. Tak więc takie myślę, że dwie najprostsze formy, które mi przychodzą do głowy tutaj mają miejsce, mogą też się pojawić formuły takie wynikające być może ze sposobu, w jaki pracujemy. Czyli na przykład sensownym miejscem na porozmawianie o tym, co nam działa, co nam nie działa, no jest oczywiście wydarzenie typu Retrospektywa, czy jakieś warsztaty usprawniające, jakkolwiek sobie to nazwiemy, gdzie na temat informacji zwrotnej, na temat tego jak się nam pracuje, możemy spojrzeć w bardzo różny sposób i z wielu różnych perspektyw.

Jacek: Trzeci aspekt, który ma wpływ na budowanie zaufania z klientem to proces deweloperski, czyli proces wytwarzania. Pierwsza rekomendacja z tego obszaru brzmi, jak najwcześniej oddawaj działający produkt. Klient przychodzi do nas zwykle z pewnym problemem, ma jakąś konkretną potrzebę, chce coś zrealizować. Im wcześniej pokażemy, że potrafimy wytworzyć coś namacalnego, tym większa jest szansa, że klient zbuduje sobie wyobrażenie, że ok, ta firma faktycznie mówiła, że to zrobi i dostaje pierwsze namacalne rezultaty. Mogę to zobaczyć, mogę to być może kliknąć, mogę to przetestować, oczywiście rozumiejąc, że nie jest to nic finalnego, doskonałego, skończonego, ale pokazuje, że jednak pewne klocki jesteśmy w stanie połączyć. Chociażby taką prozaiczną rzecz jak to, że ten zespół, który pracuje na rzecz klienta, potrafi się dogadać, no i te wszystkie elementy front-endowe, back-endowe, jakościowe, być może tam jest jakiś UX, który też jakiś design proponuje, potrafią połączyć w sensowną i w logiczną całość.

Kuba: Ta nasza rekomendacja wynika z definicji, z tej części związanej z takim poczuciem przewidywalności, poczuciem tego, że można polegać na danej, drugiej stronie. No i tutaj to budowanie zaufania wprost wynika z tego, że po prostu zaczynamy udowadniać jako dostawca, że umiemy to dostarczyć, że to, co tworzymy faktycznie, ma konkretną postać. To też jest po prostu jak najwcześniej danie okazję do tego, żeby też się dopasować czy dogrzać te nasze zasady komunikacji, o których wspomnieliśmy też już chwilę temu. Natomiast rekomendacja ma też swoją taką jakby odwrotną stronę. Zdecydowanie nie polecamy zbyt długiego trzymania się w jakichś fazach jakiegoś Sprintu Zero, fazy incepcji, czy czegokolwiek, co tak kojarzy się z długimi dywagacjami, z których niewiele wynika. I to nie jest tak, że jesteśmy przeciwni przemyśleniu dobrze, co jest do zbudowania, albo dobremu zrozumieniu, co druga strona oczekuje, ale może być tak, że przekiszenie się na niekończących się warsztatach, budowanie jakichś kolejnych planów, Exceli, dokumentów, cokolwiek, co nie ma namacalnej postaci działającego produktu, po prostu będzie odwróceniem takiego ostatecznego testu, czy faktycznie się rozumiemy. Więc jeśli produkt jest bardzo złożony, to owszem duża pula takich prac związanych z budowaniem zrozumienia jest potrzebna, ale i tak dążmy do tego, żeby w najlepszym razie to było coś, co jest zrównoleglone. Bardzo podstawowa funkcja, chociaż pierwszy krok, pierwszy ekran, jakaś taki podstawowy, pierwszy przypadek użycia i równolegle budowane, bardziej rozbudowane elementy tego, co jest tam faktycznie do zrobienia.

Kuba: Druga nasza rekomendacja to „Pokazuj efekty pracy częściej niż na Demo”. Wiele zespołów działających z klientem pracuje w jakiejś formule iteracji, niektórzy nazywają to Sprintem, niekoniecznie jest to zgodne ze Scrumem, ale nie o tym będzie ten odcinek. Natomiast coś, do czego zachęcamy to to, żeby zbudować sobie taką relację z klientem i tak ustawić sposoby działania samego zespołu, żeby efekty pracy były pokazywane jak najczęściej, być może codziennie, jeśli to jest nierealistyczne, to chociaż kilkukrotnie w ciągu na przykład dwutygodniowej iteracji. Żeby nie było tak, że klient jest zaskakiwany elementami dostarczonymi dopiero na jakiejś formalnej prezentacji. Te formalne prezentacje też często nie są najlepszym środowiskiem do szczerej rozmowy, dobrego wniknięcia, o co chodzi. One często są takie dosyć poważne. Więc tutaj zwłaszcza z takimi osobami, które są jakiegoś rodzaju reprezentantem klienta współpracującym z naszym zespołem, zaciągnijmy je do takich krótkich pętli może codziennych, jak wspomniałem, tak żeby ewentualny też feedback albo dobre zrozumienie budować sobie jak najkrótszymi odcinkami czasowymi.

Jacek: I czasem przybiera to formułę taką, że mamy jakiś codzienny catch up z klientem, gdzie zwykle rozmawiamy o pewnych tematach, no i jeżeli to ma sens i mamy coś namacalnego i czujemy, że to jest ten moment właśnie, kiedy klient mógłby ręką pokazać w prawo czy w lewo, albo wypowiedzieć się, czy to jest tak jak sobie to wyobrażał, no to po prostu możemy czy udostępnić ekran, jeżeli pracujemy zdalnie, czy po prostu wyświetlić to na jakimś ekranie, jeśli akurat jesteśmy stacjonarnie, czy u klienta, czy u nas w software house’ie. No i po prostu porozmawiać o tym, skomentować to. I tak jak przed chwilą Kuba słusznie mówił o tym, żeby pokazywać działający produkt, no to tutaj z mojej perspektywy ma sens pokazanie nawet, nazwijmy to, jakichś półproduktów. Czyli podyskutowania o makiecie, może mieć sens, w sensie im wcześniej dostaniemy feedback, tym lepiej. Pokazanie nieskończonego front-endu też może być inspiracją do rozmowy, oczywiście tłumacząc klientowi, że to co widzi, no to jest tylko nazwijmy to jeszcze jakaś wydmuszka, coś co nie jest kompletne, żeby z drugiej strony nie budować poczucia, no przecież przed chwilą mi pokazywaliście, widziałem mój produkt – na zasadzie wydawało mi się, że to jest mój produkt, a teraz mówicie, że jeszcze miesiąc czy dwa będziemy budować jakiś back-end, jakieś rzeczy z tyłu. Więc jakby to ma sens, może być wartościowe, może wzbudzać zaufanie. Na zasadzie pytają się mnie jako klienta, w którą stronę skręcić. Fajnie mam poczucie, że mam wpływ, no ale jednocześnie warto tutaj jakieś takie minimalne wprowadzenie do tego jak tworzy się w ogóle software, no klientowi taką pigułkę po prostu zapewnić.

Jacek: Ostatnia porada w aspekcie procesu deweloperskiego brzmi „Dostarczaj kompletne, przekrojowe funkcje”. I stoi to trochę w sprzeczności z tą poprzednią poradą, bo tutaj jednak chcielibyśmy podkreślić z Kubą, że zależy nam na tym, żeby klient dostawał coś namacalnego, funkcjonalnego, konkretnego. Czyli pokazywanie czy dostarczanie rzeczy totalnie back-endowych, które nie mają żadnego przełożenia na to jak faktycznie będzie ostatecznie działał produkt, może wzbudzać zaufanie, na zasadzie deweloperzy mogą mieć poczucie, że to jest już coś, co pokazują, ale klient, on tam może widzieć jakieś krzaczki, ptaszki, jak nigdy nie napisał linijki kodu. No to po prostu to może nie mieć wartości. Więc trochę empatyzując z klientem, on jednak się spodziewa zobaczyć coś, co będzie w zgodzie z jego wyobrażeniem, nie wiem, aplikacji, produktu, w zależności czy to jest fizyczne, czy to jest software. Może to jest połączenie hardware’u i software’u? Więc jednak dążyłbym do tego, żeby jak najszybciej uzyskać taki efekt docelowy, nawet jeżeli pewne rzeczy są jeszcze uproszczone, zamockowane, nieskończone, żeby bazować na czymś, co maksymalnie przybliża nas do finalnego produktu. Bo to wtedy uruchamia ciekawe rozmowy na temat pewnego całego kształtu i takiego doświadczenia, które płynie nam, kiedy korzystamy z tego produktu.

Kuba: Powiedziałeś Jacek o empatyzowaniu z zamawiającym i sam tutaj wielokrotnie jestem po stronie zamawiającego, który współpracuje z jakimś dostawcą. No i niestety zdarzają się dwa takie antywzorce. Jeden antywzorzec jest taki bardziej zarządzania projektami, gdzie pokazywane są wykonane działania i tam jakieś długie opowieści, ruszenie rękami i parę slajdów na temat tego, jak już bardzo zbliżyliśmy się do rezultatu. Jak już naprawdę mamy wszystko dobrze zaplanowane, poprojektowane, odpowiednie spotkania odbyte. Ale tak naprawdę w ogóle jeszcze nie powstało żadne rozwiązanie, albo ono nie jest ukazywane. No i choć może być wrażenie, że dużo ruszenia rękami właśnie się odbyło, jakieś fajne show, no to tak naprawdę to zaufanie zbudowane zostanie, jak będzie rezultat. A druga rzecz, która też czasami jest pokazana, to na przykład dobry schemat bazy, albo parę diagramów, gdzieś tam modelu danych. No i to też znowu wygląda nieźle, buduje wrażenie jakiejś złożoności. Być może wypełni całe spotkanie pokazujące – no pracowaliśmy, namęczyliśmy się, już jesteśmy kroczek bliżej rezultatu. No, ale to nie o to nam tu chodzi. Jednak mocno, mocno tutaj rekomendujemy takie podzielenie produktu, takie podzielenie zakresu tych efektów, żeby pokazać, chociaż jeden prosty przypadek, ale jednak cały. Pokazać się pewien ekran, czy pewien proces end to end, nawet jeśli nie ma jeszcze wszystkich przypadków brzegowych. I też być może niektórych klientów wręcz nauczenie tego, że to nam pozwala jakby rozbudowywać. To też pokazuje jakieś pierwsze przybliżenie, czy się w ogóle rozumiemy. No bo prawdopodobieństwo, że dobrze zinterpretują model danych, albo schemat bazy danych jest o wiele mniejsze niż to, że dobrze zinterpretują, że no ale my tu inaczej chcielibyśmy klikać ten proces, no i na wczesnym etapie ewentualnie odkryjemy jakąś pułapkę, no albo odkryjemy jakieś wymagania, które nie były wyrażone, a jednak są dla klienta superważne i wiemy o tym najwcześniej jak to możliwe.

Kuba: I ostatni aspekt związany z budowaniem zaufania jako software house, to transparentność. Tutaj wymienimy dwa konkretne zagadnienia. Pierwsze to: „Zapewnij przejrzystość procesu wytwórczego”. Zwłaszcza klient, który nie jest fachowy, nie jest techniczny, może po prostu bardzo, bardzo potrzebować takiego pewnego rodzaju wglądu w to jak wyglądają prace w konkretnym zespole. Prace poprzez pokazanie na przykład tablicy scrumowej lub kanbanowej tego zespołu. Informacje takie w stylu Daily, co dzisiaj robimy, nad czym dzisiaj pracujemy, co jest ewentualnie w planach na kolejny jakiś tam krótki okres. Może też jakie mamy problemy, to by nawiązywało do tego przejrzystego informowania o ryzykach. No, a jeśli pracujemy na jakimś artefakcie typu Backlog Produktu, czy jakiś plan prac, czy plan zakres kolejnego wdrożenia, to również jasny, jawny i zrozumiały wgląd tego typu narzędzia. Tak, żeby klient po prostu widział pewnego rodzaju trybiki i widział, że te trybiki się kręcą i idą do przodu.

Jacek: Ktoś może mieć takie poczucie, że czy nie, aby nie schodzimy zbyt nisko poziomowo, co robimy dzisiaj, co robimy jutro. Ja myślę, że to warto pamiętać, że klient często jest tysiące kilometrów od nas i tak naprawdę oprócz jakichś tam obietnic, tego, co usłyszą na rozmowie sprzedażowej, tego, co mówi mu jakiś tam key account, to tak naprawdę niewiele widzi. Jeżeli dołożymy do tego sytuację, w której nie dostaje namacalnych rezultatów, no to wejdźmy w buty klienta. Płaci, przychodzą faktury, ale tak naprawdę nie kształtuje się poczucie, że te pieniądze zamieniają się w jakiś tam rezultat. Więc myślę, że w szczególności na początku warto pokazać pełną transparentność, zrozumieć z jakimi obawami może przychodzić klient. Natomiast praktyka mi pokazuje, że udowodnienie na wczesnym etapie, że często dostarczamy gotowe rzeczy, że wszystko jest transparentne, jasne, szybko wychodzą ryzyka, powoduje, że klient w pewnym momencie przestaje się tak super nisko poziomowo interesować, no bo te obawy pierwotne po prostu okazują się nieprawdziwe no i wtedy skupienie bardzo łatwo przenosi się już na te faktyczne rezultaty.

Jacek: Drugą rekomendacją w zakresie transparentności to rekomendacja brzmiąca „Zadbaj o jasny skład zespołu”. Coś, co z perspektywy software house’u jest zwykle jasne, na zasadzie dla projektu X czy dla klienta Y pracują te konkretne osoby, wcale nie musi oznaczać, że klient ma takie poczucie. Może mieć takie wrażenie, że jest tam po prostu jakiś taki black box. Nie wiadomo jak to pudełko funkcjonuje, no i co jakiś czas to pudełko coś tam pokazuje, pojawiają się jakieś rezultaty. Jakby stąd informacja, ile mamy osób w zespole, jaki jest poziom tych osób, czy to są juniorzy, seniorzy, albo może jaka jest proporcja tych ról, czy mamy QA, czy nie mamy, czy mamy UX? A w jakim wymiarze? Kto czym się zajmuje? No są to absolutnie podstawowe informacje, które no uważam, że gdzieś już na początku w ogóle tego procesu współpracy powinny się pojawić do tego stopnia, że tak naprawdę klient powinien te osoby zobaczyć fizycznie. Jakby poznać się z imienia, przedstawić, powiedzieć dwa zdania. No po to, żeby zmaksymalizować to poczucie, że faktycznie po drugiej stronie jest mój zespół czy zespół, z którym pracuję. No bo w dobrej relacji będzie tak, że klient może się bezpośrednio zwracać do konkretnych osób, no i dobrze tak naprawdę, żeby nie było zaskoczenia, że próbuję złapać Tomka i odkrywa, że Tomek się zwolnił, albo że Tomek pracuje w innym projekcie, albo odkryć, że pracuje w dwóch projektach. No myślę, że nie są to rzeczy, które chcielibyśmy, żeby klient ich doświadczył znienacka.

Kuba: No i właśnie to zagadnienie związane z dostępnością, przykładowego Tomka, to też jest cząstka tej naszej rekomendacji o jasnym składzie zespołu. Sam też byłem świadkiem takiej sytuacji, gdzie właśnie przykładowy Tomek zaczął jakoś bardzo nieprzejrzyście w czasie spotkania tłumaczyć, że tam miała jakiś inny projekt, który właśnie zaczyna, szykuje, no i wszyscy w szoku, wszyscy wręcz właśnie też tak zdegustowani, no bo tutaj kluczowy programista projektu nagle zaczyna być niedostępny, nie wiadomo co chodzi, znika. W zasadzie to nie wiadomo, czy my upłacimy mu za ten jutrzejszy dzień, co on zapowiada, że go tam nie będzie. Więc tutaj, nawet jeśli faktycznie następują jakieś zmiany osobowe, to również częścią budowania tej przejrzystości jest również bardzo szczere sygnalizowanie co się dzieje, jak się dzieje oraz no, jeśli faktycznie następuje pewna zmiana, być może zupełnie poza naszą kontrolą, bo na przykład przykładowy Tomek postanowił kontynuować karierę w jakiejś innej organizacji, no to chociaż za sygnalizowanie, w jaki sposób zostanie przeprowadzone przekazanie wiedzy oraz obowiązków, tak żeby następca wspomnianego Tomka też mógł być rzetelnym członkiem zespołu projektowego, którego dostarczamy naszemu zamawiającemu.

Jacek: I tym sposobem zbliżamy się do końca tego odcinka. Podsumowując, jak możesz budować zaufanie jako software house? Spełniaj złożone obietnice. Komunikuj się w przewidywalny sposób. Informuj o ryzykach i problemach na bieżąco. Dziel się informacją zwrotną.

Kuba: Jak najczęściej oddawaj działający produkt. Pokazuj efekty pracy częściej niż na Demo. Dostarczaj kompletne przekrojowe funkcje. Zapewnij przejrzystość procesu wytwórczego i zadbaj o jasny skład zespołu.

Jacek: Jeśli chcesz podnieść zadowolenie klientów Twojego software house’u, to robimy z Kubą dedykowane warsztaty, w których przepracowujemy kwestie podobne do tych, które poruszliśmy w tym odcinku. Odezwij się do nas poprzez stronę porzadnyagile.pl/kontakt, jeśli chcesz tego typu warsztaty przeprowadzić w swojej firmie.

Kuba: A notatki do tego odcinka, artykuł na jego podstawie, transkrypcję naszej rozmowy oraz zapis wideo, znajdziesz na stronie porzadnyagile.pl/121.

Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.

The post Budowanie zaufania jako software house first appeared on Porządny Agile.