Jak sprzedawać agile?

Co możesz zrobić, żeby przekonać swojego klienta do pracy w sposób zwinny? Jak skutecznie przedstawić mu zalety pracy zwinnej? Dajemy Ci pięć porad, które pomogą dobrze sprzedać Agile, a także otwarcie mówimy, kiedy gra nie jest warta świeczki.

Zobacz wersję wideo:

Dodatkowe materiały

• artykuł Jacka na stronie jacekwieczorek.pl

TRANSKRYPCJA

Jacek: W dzisiejszym odcinku chcemy porozmawiać o tym, jak sprzedawać agile, jak sprzedawać zwinność. Tłem do tego odcinka są historie, których wielokrotnie doświadczyłem pracując w software house, gdzie zarówno ja, jak i generalnie rzecz ujmując software house stawał przed taką sytuacją, w której trzeba opowiedzieć klientowi czym jest praca zwinna. W dzisiejszych czasach generalnie jak wejdzie się na dowolny software house no to ta zwinność jest mocno dostrzegalna już na poziomie strony internetowej. Natomiast dla klienta może to znaczyć wszystko i nic. Stąd nie wystarczy powiedzieć, że jesteśmy zwinnym software house czy, że pracujemy w sposób zwinnym z klientem zewnętrznym. Warto nauczyć się i przemyśleć jaką w ogóle mamy strategię inspirowania klienta zwinnością i w jaki sposób chcemy klienta do tego rodzaju pracy zachęcać i przekonywać. Kiedy mówię o relacji klient zewnętrzny, a dostawca mam na myśli taki główny jeden scenariusz. Jest to scenariusz, w którym jesteśmy software housem i dostarczamy klientom zewnętrznym konkretne oprogramowanie najczęściej skrojone na miarę, a czasem jest to taki wariant, w którym mamy jakieś produkt pudełkowy i stanowi on pewną bazę. Natomiast już konkretnie pod klienta, pod jego potrzeby ten produkt rozbudowujemy czy konfigurujemy.

Kuba: A jeżeli czujesz, że taki odcinek nie dotyczy Ciebie, to bardzo liczę na to, że, mimo że tematyka jest dosyć dookreślona i może być niszowa, to liczę na to, że te historie o tym jak sprzedawać agile w takich relacjach klient-dostawca mogą być również inspirujące dla innych przypadków, gdy wewnątrz organizacji trzeba do tego agile`a przekonać czy to biznes, czy zespół z którym współpracujemy czy ogólnie sprzedać agile’a do firmy czy do zarządzających. Więc pomimo tego, że jesteśmy bardzo dookreśleni i będziemy się trzymać tych realiów współpracy z klientem, no mimo wszystko liczę na to, że będzie też do wyjęcia również dla osób, które w tej relacji przynajmniej teraz nie pracują.

Jacek: Przygotowaliśmy pięć konkretnych porad, które z naszej perspektywy warto spróbować, warto wcielić w życie i przejdziemy po kolei po tych poradach. Pierwsza porada co do której się zgodziliśmy z Kubą to jest porada, w której mówimy, że warto skupić się na sprzedawaniu korzyści, a nie konkretnie na przykład Scruma, czyli konkretnego narzędzia. Z czego wynika taka porada? Powodów jest co najmniej kilka. Po pierwsze, kiedy będziemy sprzedawać klientowi Scruma jako takiego, no to możemy trafić na sytuację, w których klient pracował już wcześniej przy użyciu tego frameworka. No i może mieć jakieś swoje już doświadczenia, jakiś swój punkt widzenia. Super, jeżeli są to pozytywne doświadczenia. Natomiast no ten bardziej ciemny scenariusz to jest ten, w którym klient pracował w kiepskim Scrumie, który umówmy się nie był, nie dostarczał wartości. No więc jak klient usłyszy Scrum, no to może zareagować alergicznie na zasadzie – my już pracowaliśmy Scrumem, przekonaliśmy, to nie działało, to była strata czasu i tak dalej i tak dalej. Tak więc to jest pierwszy powód. Drugi powód dla którego moim zdaniem warto skupić się na korzyściach pracy w Scrumie, a nie na samym operowaniu tym słownictwem jest to, że po prostu te sformułowania, których będziemy używać mogą być dla klienta po prostu niezrozumiałe. Czyli nie możemy się skupić na takich ładnych okrągłych zwrotach jak transparencja, inspekcja, adaptacja, Backlog Sprintu, Product Owner, Scrum Master. I dla nas to może być oczywistość co te rzeczy znaczą i absolutnie jasne pojęcia. Natomiast Backlog produktu może nie znaczyć nic. Natomiast no to nie jest aż tak, że każdy klient podczas rozmowy będzie na tyle odważny czy otwarty, żeby dopytywać o te rzeczy. Tak więc możemy mieć takie piękne poczucie, że idealnie i perfekcyjnie tłumaczymy Scruma, natomiast dla klienta to będzie absolutny bełkot w takim sensie, jakieś buzz wordy, jakieś specjalistyczne słownictwo, z którego nic nie wynika. Trzeci powód, który przychodzi mi do głowy, jest taki, że z perspektywy samej komunikacji, moim zdaniem lepiej jest powiedzieć klientowi jaką konkretną korzyść uzyska pracując w Scrumie, niż opowiadać o tym, że jakiś tam element Scruma będzie wykorzystywany. Czyli przykładowo, zamiast mówić klientowi, że praca w Scrumie będzie transparentna, co tak do końca nie wiadomo co będzie znaczyć dla klienta. Moim zdaniem lepiej jest powiedzieć, że pracujemy w przejrzysty sposób i cały nasz proces pracy jest gotowy do wglądu. Można zobaczyć jak pracujemy. Te efekty pracy są namacalne. Dużo rzeczy jest dookreślonych. To nie jest jakiś black box, takie pudełko, które klient widzi z lotu ptaka i nie ma pojęcia co się z nim dzieje. Czy na przykład, zamiast mówić, że będzie Product Owner po stronie klienta, moim zdaniem lepiej jest powiedzieć, że decyzje na temat zakresu prac będzie podejmował Klient i będzie miał wpływ na priorytety pracy.

Kuba: Jak mówimy o tym sprzedawaniu korzyści to mi przychodzi do głowy jeden taki wymiar bardzo mocno patrzenia na rezultaty. Czyli uzyskamy lepszej jakości produkt. Produkt, który o wiele lepiej odpowiada potrzebie klienta czy też klient w trakcie będzie miał lepsze możliwości wpływania na priorytety. I to są takie najwyższego rzędu korzyści takie biznesowe albo powiedzmy operacyjne w projekcie. À propos tego bełkotu jak to powiedziałeś na przykład scrumowego, ale to można też rozszerzyć, bo podobnym bełkotem może być hasło na przykład MVP, albo przyrost, iteracja. Również nie tylko scrumowe rzeczy mogą być dla nas słowem kluczem, które są pozytywne, a dla kogoś to może być słowo klucz, które jest bardzo negatywne albo nic nie znaczy. Więc oprócz samego sprzedawania korzyści ja bym też trochę opowiedział klientowi językiem zrozumiałym dla niego. Więc to może będzie językiem projektów, to może będzie takim językiem ogólnym biznesowym. Jak dokładnie chcemy współpracować i czego też obie strony od siebie powinny oczekiwać. I my dużo damy, ale też na przykład też oczekujemy. Czyli jeśli chcemy, żeby to klient wszedł w rolę Product Ownera, jeśli mówimy o Scrumie, to są konkretne obowiązki. Jeśli oczekujemy, że będzie się pojawiał na Sprint Review no to tu podobnie. No raczej ta responsywność jakaś musi być. Więc o ile się w pełni się zgadzam ze sprzedawaniem korzyści to dołożyłbym do tego jeszcze tę komponentę opowiedzmy też takim językiem nazwę to ogólno biznesowym bez żadnego  żargonu specyficznego dla metod zwinnych. Co to dokładnie będzie oznaczało? Że będziemy współpracować w sposób zwinny. Bo to już jest to miejsce, w którym też możemy się po prostu nie dogadać. Czyli zwinni, czyli oni myślą, że my będziemy absolutnie chaotycznie elastycznie, a my zwinnie, czyli bardzo partnersko. Tu się może okazać, że już na przymiotnikach się rozjedziemy.

Jacek: Tak. Tak więc ja tutaj z tego, co powiedziałeś bym zwrócił szczególną uwagę na to, co ja w praktyce stosowałem. Że moje doświadczenia z pracy w roli Project Managera okazały się bardzo przydatne w kontakcie z klientami, którzy w większości pracowali przy projektach. Tak więc takie pojęcia takie ogólnie znane jak zakres, budżet, jakość, niestety też zasoby, to są pojęcia, które są absolutnie jasne i zwykle na tej płaszczyźnie o wiele prościej jest się dogadać niż używając no takich zwrotów jak powiedziałeś, nie tylko scrumowych, ale chociażby to MVP, no to to może znaczyć naprawdę. MVP to może być – rok pracowaliśmy nad pierwszą wersją produktu, a może znaczyć – no zrobiliśmy eksperyment w dwa dni i już mieliśmy jakieś rezultaty i się czegoś nauczyliśmy. Tak więc te słowa mają znaczenie.

Drugi pomysł, z którym chcemy się podzielić, jeśli chodzi o to jak można inspirować klientów do podejścia zwinnego i też sprzedawać zwinność jako taką, to jest pokazanie metryk, którymi dysponujemy jako software house czy jako firma – jako dowód. Czyli pokazać klientowi coś namacalnego, coś w postaci liczbowej, jakieś konkretne dane, które będą uzupełnieniem takiego opisu słowno-muzycznego, gdzie po prostu będziemy opowiadać na przykład o korzyściach. Tak więc te dwa punkty fajnie się łączą o tyle, że możemy mówić o korzyściach i jednocześnie przeplatać to bardzo konkretnymi danymi. No i tu myślę, że tu też dużo zależy też od klienta. Możemy trafić na klienta, który lubi po prostu konkrety. Możemy trafić na klienta, do którego konkrety nie przemawiają tak jak jakaś dobrze roztoczona wizja. No a może warto po prostu korzystać z tego i z tego, żeby ten obraz był pełniejszy. Jakie metryki tutaj przychodzą mi do głowy. No ja myślę tak, że zanim wskazałbym konkretne, to bym zaznaczył jeszcze taki punkt, który z mojej perspektywy jest ważny, że te metryki, które mamy w organizacji one powinny wynikać z potrzeb, które mamy jako organizacja. Czyli na przykład, jeżeli promujemy się jako software house, który szybko dostarcza wartość dla klienta, no to zastanowiłbym się jakie metryki będą dowodem na to, że faktycznie my dostarczamy szybko. Czyli przykładowo w tym kontekście zastanowiłbym się na przykład nad lead tim’em, albo bym się zastanowił nad taką jakąś metryką w stylu – ile Sprintów potrzebowaliśmy, żeby dostarczyć coś działającego, co klient już mógł zwalidować na rynku. Ale przykładowo, jeżeli nie wiem, akcentujemy w naszym software house’ie, że mamy wysoką jakość, no to zastanowiłbym się nad jakąś metryką jakościową. Czyli nie wiem, aż taka na przykład szczelność procesu testerskiego u nas. Czyli jakieś taki stosunek liczby błędów wskazanych przez klienta bądź zgłoszonych przez użytkowników naszego klienta w stosunku do błędów, które wyłapujemy w procesie developmentu. Tak więc byłbym ostrożny ze strzelaniem jakimiś metrykami w stylu prędkość, no bo to jest absolutnie nic niemówiące, łatwe do zhakowania, ale z perspektywy klienta też to moim zdaniem trudno jest to do czegokolwiek odnieść. Trudno w ogóle porównywać prędkości dwóch zespołów więc dlatego byłbym ostrożny i taki świadomy w doborze tego, co chcemy pokazać jako dowód.

Kuba: Dobrze, że powiedziałeś o tej perspektywie Klienta, bo tutaj jedna strona, to jest taka, że my mamy jakąś swoją historię i dowody z dotychczasowej współpracy, ale ja bym też patrząc z tej perspektywy klienta, bo o wiele częściej raczej byłem w takiej pozycji w swojej pracy zwinnej. No to też klientowi może zależeć na pewnych konkretnych metrykach, żeby po pierwsze, żebyście wy jako dostawca się nimi pochwalili jak to u Was wygląda. Na przykład jakość kodu. Z takich rzeczy, których nie wymieniłeś a też moim zdaniem mogą być bardzo istotne. No i mi zależy na tym, żeby Wasza ta strona inżynierska była bardzo dobra. I chcę, żebyście po pierwsze się tym pochwalili, ale po drugie, żeby również w moim projekcie to również było bardzo dobrze dopilnowane oraz między innymi pomierzone i na przykład w jakiś sposób dzielone, raportowane. W każdym razie oprócz tego, że widzę, że pracuje z nami w sposób zwinny, to też na przykład dostaje jakieś informacje na temat tego w jakim stanie jest kod tego, co tworzymy. Może jakie są statystyki procesu wytwarzania rzeczy, na których może z jakiegoś powodu mi zależeć. Więc tutaj ja bym dorzucił – sprzedawajmy metryki, ale też rozmawiajmy od razu z klientem, a jemu na czym konkretnie zależy, jak to ma pomierzone. Bo szczerze mówiąc to może być ta różnica, którą też zrobimy na wrażeniu. Czyli firma, która obiecuje złote góry, czyli ten pierwszy punkt o korzyściach, to jeszcze jest słowo przeciwko słowu. Ale jeśli my jeszcze też oprócz tego umiemy opowiedzieć, że mamy już dowody pomierzone z poprzednich historii, umiemy to wysetup’ować też w naszej relacji no jest zupełnie inna rozmowa. Od razu zaczynam nabierać zaufania do takiego sprzedawcy czy do takiego dostawcy jako partnera biznesowego.

Jacek: Jasne. Trzecia porada, którą przygotowaliśmy brzmi – wytłumacz złożoną naturę software developmentu. Sugerując tę poradę mam na myśli aspekt złożoności software developmentu jako takiego pewnego fundamentu do dyskusji z klientem na temat tego jakich narzędzi powinniśmy użyć, żeby w tym złożonym środowisku funkcjonować. No i tutaj jakby to jest fajne podłoże, gdzie możemy sobie trochę porozmawiać o teorii złożoności. O tym jak bardzo jesteśmy w stanie przewidzieć pewne rzeczy w trakcie procesu pracy. Trochę opowiedzieć o tym jak ważny jest aspekt uczenia się strony dostarczającej software i też jak ważne jest uczenie się klienta w trakcie pracy nad produktem. Jakby bez takiego wprowadzenia i wytłumaczenia, dlaczego używamy na przykład narzędzi takich iteracyjnych jak na przykład Scrum, no może być bardzo trudno przekonać, że to jest właściwy kierunek prac. No i klient może mieć poczucie, że to co zamawia jest super proste i łatwe i po co wytaczać działa i po co mi tutaj opowiadacie o jakimś Scrumie, Agile’u i tak dalej. Skoro przecież to jest takie proste i takie oczywiste. Tak więc tutaj jakby pokazanie jak trudne jest estymowanie na bardzo wczesnym etapie, pokazanie jak bardzo możemy się nie zrozumieć, jeżeli się będziemy skupiać tylko na formie pisanej. Pokazanie jak bardzo możemy się przejechać, jeśli chodzi o takie założenia co jest potrzebne do wytworzenia, kontra to jak zareaguje na to rynek. No to są takie aspekty, które bez przegadania, bez zrozumienia na tym poziomie – no może być ciężko przekonywać do pewnego rodzaju narzutu, bo tak to klient może odebrać w stylu, zróbmy warsztaty, przeprowadźmy refinement, może przeprowadźmy jakieś testy z użytkownikami, po co, skoro przecież wszystko jest jasne. Tak więc uważam to za też jedną taką z fundamentalnych strategii przekonywania, czy też tłumaczenia, dlaczego w ogóle chcemy pracować w sposób zwinny.

Kuba: I to może być czasem takie wrażenie sprawiać, że tłumaczenie komuś złożoności wytwarzania oprogramowania, to jest jak tłumaczenie komuś, że tak działa świat. Moim zdaniem nadal możemy trafić na klienta, na zamawiającego, który nie ma wystarczająco dużego doświadczenia i nie rozumie tych wszystkich kwestii, których wymieniłeś i wielu innych, których nie zdążyłeś wymienić. Które powodują, że po prostu wytwarzanie oprogramowania nie jest tak łatwe do zaplanowania. Ja bardzo zawsze liczę w takich momentach, zwłaszcza jeśli mam do czynienia z sytuacją, w której mogę doradzić zamawiającemu, ale przy okazji mam też trochę kontakt z tym, kto jest potencjalnym wykonawcą. Żeby też trochę pokazać obu stroną jak wiele tych czynników może się zmieniać. Trochę już ich wymieniłeś, ale jakby jeśli ta strona wykonawcza jest otwarta na temat tego, jak wiele czynników może nam psuć plany – tak to powiem może trochę negatywnie. Jest spora szansa, że również strona biznesowa wtedy trochę powie – tutaj gdzieniegdzie, tu trochę bardziej spekulujemy, że to będzie przydatne i potrzebne, a byłoby fajnie, gdybyśmy mogli zmieniać zakres pracy w trakcie pracy. No i jest wtedy taka faja zasada może wzajemności. Wiem i oczywiście trafią się klienci, którzy albo nie uświadomią sobie tego, albo świadomie będą udawać, że takiego tematu nie ma. Oni tu mają plan, zakres, wszystko opisane – tabelki, dokumenty, proszę bardzo, książka. No ale i tak jestem tutaj trochę może optymistą. Jak my wytłumaczymy, dlaczego software development jest złożony, to jest szansa też na rozmowę, jak złożony jest ich biznes. Jak bardzo innowacyjne jest to co chcemy zrealizować. A nawet jeśli nie realizujemy super innowacyjnych rzeczy, nie wiem – CRM, albo jakąś stronę intranetową stawiamy. Czyli relatywnie akurat rozwiązanie jest już powiedzmy ograne, no to zawsze jeszcze zostaje ta perspektywa klienta. Klient będzie chciał tego użyć, czy się przyzwyczai, jakie ma konteksty. To wszystko powoduje, że ta złożoność tutaj nam tylko się potęguje.

Jacek: I tak sobie myślę słuchając tego, co mówisz, że generalnie to takie pogłębienie tego z czym się mierzymy i dlaczego chcemy pracować przyrostowo, iteracyjnie i tak dalej, to są fajne fundamenty też takie, jeżeli po prostu decydujemy się na to, że chcemy się edukować w całym tym obszarze czy software developmentu czy konkretnie zwinnego wytwarzania oprogramowania, czy nawet po prostu zwinnego podejścia do tworzenia produktów. Dojście do argumentów, dlaczego tak pracujemy oraz też umiejętność wytłumaczenia klientowi na temat tego, co poczytaliśmy, posłuchaliśmy, obejrzeliśmy, uważam, że to jest ogólnie wszechstronna umiejętność, którą dobrze posiąść, bo czasem będziemy coś tłumaczyć klientowi, czasem Product Ownerowi, z którym będziemy pracować, a czasem osobie z zespołu developerskiego. Tak więc nie tylko w tym przypadku uważam, że takie głębokie zrozumienie na poziomie dlaczego, po prostu jest czymś w co warto zainwestować swój czas.

Czwartą propozycją, którą mamy, jeśli chodzi o przekonywanie do podejścia zwinnego, to pokaż klientowi case study. I tutaj mam na myśli takie trzy poziomy, na których możemy operować. Case study tak może tylko słowem wprowadzenia, jest to zwykle jakaś forma dokumentu, prezentacji, pokazującej rys historyczny, jakby klienta z kim pracujemy. Opowiadamy trochę czy piszemy o problemie klienta. Następnie w jaki sposób podeszliśmy do rozwiązania tych problemów. Pokazujemy też efekty jakie uzyskaliśmy, no i zwykle jakoś to zamykamy w jakąś formę podsumowania. Jakby nie chcę tutaj wchodzić w to jak napisać dobre case study, bo to jest temat, który można łatwo sobie znaleźć w Internecie. Natomiast tak z praktyki to wracając do tych trzech poziomów, to myślę sobie tak, że po pierwsze możemy pokazać klientowi case study współpracy naszej jako software house’u z innym klientem. Idealnie jeżeli to jest klient z tej samej branży co klient, z którym właśnie rozmawiamy. Czyli mamy dowód na to, że po pierwsze – można pracować zwinnie i to daje efekty. Po drugie – możemy to zrobić w twojej branży. Każdy, kto pracował, nie wiem, w bankowości, finansach czy ubezpieczeniach no to pewnie zderzył się z takim stwierdzeniem, że może i ten Agile działa, ale nie w bankowości. Ale nie w finansach, bo XYZ. No dzisiaj już akurat żyjemy w takich czasach, że tych przykładów i case studies jest całkiem sporo. Myślę że, tu jestem w stanie zaryzykować, że na każdą branżę. Tak więc na pewno idealnie, jeżeli jesteśmy w stanie pokazać innym klientom, że pracowali klienci z nami z Twojej branży i były efekty. Jeżeli nie jesteśmy w stanie przedstawić tak perfekcyjnego przykładu no to kolejną naszą deską ratunku jest po prostu case study. Czyli znów efekty pracy zwinnej z innym klientem z innej branży, możenie koniecznie z branży, z którym pracujemy, ale nadal jest to dowód na to, że być może podobne tematy, być może podobne produkty, podobny software tworzyliśmy dla kogoś innego. Jeżeli mamy tylko jakąś taką płynność w tym, żeby opowiedzieć, dlaczego to jest podobne, albo pokazać co jest inne i jak to możemy zaadresować, no to myślę, że te case study jest nadal jest bardzo fajnym takim silnym argumentem w naszej dłoni. Jeżeli nie mamy case studies my jako software house, no to trzeci poziom, na który wejść to po prostu wejść to sięgnąć po dostępne case studies publiczne. Czyli sięgamy po case study liderów branż, firm, które wszyscy znają. Jakby niezależnie tutaj już konkretnie od branży klienta, w sensie super, jeśli mamy z branży. Jeśli nie to po prostu pewne duże nazwy, znane firmy i pokazujemy tym samym zobacz – świat się zmienia, to nie jest nasza fanaberia, najwięksi gracze na rynku, których na pewno znasz. No i tutaj cała odpowiedzialność za to, żeby te przykłady były wymowne pozostaje po naszej stronie. Stają się naprawdę fajnym argumentem. W sensie świat wokół nas się zmienił, takie są nowe realia i my właśnie tak pracujemy. Tak więc case study jest fajnym narzędziem niezależnie czy mamy swoje czy będziemy się popierać przykładami z rynku. Uważam, że jest to coś, co jest bardzo przekonujące. No bo zwykle pokazuje co w praktyce się zadziało i jakie to ma namacalne efekty.

Kuba: Przy wykorzystaniu case study można mieć dwie wątpliwości, przynajmniej ja miałem te wątpliwości, gdy sam nad nimi myślę. Z jednej strony zwłaszcza takich, w których zwłaszcza osobiście nie bierzemy udziału, może być wątpliwość na ile to case study odzwierciedla rzeczywistość. No i jest dylemat czy na pewno tego użyć. Druga perspektywa to czy czasami trochę nie za bardzo nie lecimy tą perspektywą rozwiązań. Czyli opowiadamy pewną historię, która ma początek, środek i koniec i wszystko było proste. Zazwyczaj ciężko jest znaleźć case study, które idealnie odzwierciedla wszystkie góry i doliny historii i całą złożoność tej sytuacji, w której byliśmy. Więc zawsze case study to będzie jakieś tam spłaszczenie. Ale pomimo tych możliwych dylematów i tak bym w te case study wchodził. To na przykład na szkoleniach, na przykład, gdy się rozmawia z zarządzającymi jakąś organizacją. Widzę jaką różnicę robi, jeśli tę stronę korzyści, o których mówiliśmy w pierwszym punkcie jeszcze dołożę jakąś fajną historię taką konkretną z konkretnej marki, konkretnej firmy, z konkretnej relacji konkretnego projektu. To już w mojej rzetelności jest to, żeby była prawda i w mojej rzetelności jest też to, żeby to być może nie była tylko pozytywna część historii. Sam gdy rozmawiam o case study, gdy je prezentuje, ale sam też, gdy słucham o jakimś case study no to lubię też usłyszeć tę drugą stronę. Realne historie zazwyczaj mają jakieś słabsze momenty, momenty zawahania, momenty, które można było zrobić lepiej i zawsze fajnie o tym porozmawiać. Zwłaszcza jeśli przedstawiamy swoje case study, no to tu jest piękne pole do popisu do zrobienia jakiejś formy pokazania też swoich takich wartości związanych na przykład z transparentnością, z ciągłym doskonaleniem. Czyli historie o tym jak się doskonalimy mogą być również paradoksalnie, ale całkiem przekonujące, że jesteśmy ludźmi, którzy wiedzą o co chodzi, i że się uczą, a nie tylko w zasadzie od sukcesu do sukcesu – co jest raczej nierealne.

Jacek: I piąty punkt, którym chcemy się podzielić brzmi – zaproponuj darmowy Sprint. Myśląc o darmowym Sprincie mam na myśli taki model, w którym dajemy klientowi spróbować naszej usługi, zanim on zdecyduje się on ją kupić. Czyli w tym przypadku mam na myśli jeden, dwa darmowe Sprinty w praktyce. W praktyce różnie to wygląda, gdzie klient może zobaczyć, nawet bym powiedział doświadczyć tego jak wygląda w praktyce praca na przykład tu konkretnie w Scrumie. No myślę, że to jest co najmniej z dwóch powodów ciekawy pomysł. Po pierwsze klient będzie miał okazję zobaczyć czy te wszystkie pomysły z poprzednich punktów jesteśmy w stanie w praktyce zaimplementować. Czyli wszystkie te obietnice, o których mówiliśmy to teraz trzeba je będzie spełnić. Czyli na przykład dostarczyć coś namacalnego, działającego po jednym czy po dwóch Sprintach, co świadczy w pewnym sensie o tym jak dobrze potrafimy wykorzystać zwinność. Tak więc z jednej strony to jest taka walidacja tego, czy to nie były tylko piękne opowieści działu handlowego. Z drugiej strony to też jest dobre dla klienta, że on wejdzie zakładając, że wchodzi w rolę Product Ownera jako klient, że on doświadczy tego z czym to się je na takiej zasadzie, że będzie to też wymagało pewnego zaangażowania i pracy ze strony klienta. Czyli zobaczy jak to jest być Product Ownerem, zobaczy co to jest Backlog produktu, zobaczy też ile jest pracy przy tym, żeby dobrze być przygotowanym na planowanie. Zespół będzie zadawał pytania, a po co, a dlaczego. No i na te pytania jakoś będzie trzeba odpowiedzieć i to też jest taki test czy w ogóle klient będzie miał dostępność czasową. Bardzo fajnie jest powiedzieć róbcie, wy jesteście zespołem, wy decydujcie. No ale bez pewnego takiego fundamentalnego backgroundu biznesowego no to zespół no może nie mieć dostatecznej wiedzy z danej domeny, żeby tak fajnie i płynnie podejmować samodzielne decyzje. Tak więc uważam, że to jest takie obustronnie wartościowe i też co najmniej też takie dwa pryzmaty patrzenia na ten darmowy Sprint. Z jednej strony to może być darmowy Sprint faktycznie, czyli, że po prostu klient nigdy nie zapłaci już za te jeden, dwa Sprinty, czyli na koniec dnia za jakiś tam czas zespołu. Z drugiej strony można się umówić, że spróbuj i zapłacisz jak będziesz zadowolony. Czyli taka najbliższa analogia jaka mi przychodzi do głowy to jest taka analogia gwarancji. Po prostu stuprocentowy zwrot kosztów, których nie poniosłeś, jeśli nie będziesz zadowolony. Tak naprawdę chciałoby się powiedzieć – nic nie ryzykujesz. Nie jest to do końca prawda, no bo jednak ryzykujemy czas. Natomiast no sama taka propozycja z mojej perspektywy stawia nas jako software house w takiej pozycji, jesteśmy pewnie tego, co dostarczamy tak więc wiemy, że i tak zapłacisz, bo będziesz zadowolony. Po prostu wiemy, że my to tak robimy.

Kuba: I to ryzyko czasu, o którym wspominasz często jest niedostrzegane, a bardzo istotne. Bo się może okazać, że ten proces decydowania czy będziemy z wami współpracować, kiedy zaczynamy, jak zaczynamy, w jakiej formule pracujemy, czy się zgodzić na to wy proponujecie, czy może jednak będziemy się gdzieś tam przepychać o to jak będziemy działać. Może się okazać, że w sumie niby nic nas to nie kosztuje – w sensie faktury na razie nam nie wystawiacie, ale tak naprawdę ucieka nam okazja rynkowa. I w zależności od tego jak duże jest to coś, co robimy, jak wiele firma ma z tego uzyskać, może się okazać, że koszty zarówno jednego zespołu developerskiego po stronie dostawcy, jak i koszty jakichś tam kilku godzin czy kilkunastu godzin szykowania się do współpracy ze strony zamawiającego to jest nic w porównaniu z tym, że straciliśmy tydzień przychodów w tym roku, bo o tydzień później produkt na rynek wystartował. Na przykład, to już w ogóle dramat, że nie zdążyliśmy przed konkurencją, albo się nie załapaliśmy na jakiś taki dobry moment typu szczyt sezonu czy początek sezonu. Więc tutaj te takie wystąpienie z propozycją darmowego sprintu może być też taką bardzo rozładowującą sytuacją dla takiego ryzyka biznesowego. Po prostu jak najszybciej dążmy do tego, żeby dostarczać wartość, co daje taką zwinność na poziomie całego kontraktu, po prostu kierujmy się i dążmy do tego, żeby jak najszybciej zadowalać klienta. A nie gdzieś tam, będziemy pracować zwinnie jak już będziemy pracować, ale póki co to się przepychamy o kontrakty, jakieś takie dziwne decyzje, dziwne ryzyka. Te decyzje mogą być również bardzo trudne po stronie osoby, która zamawia no bo ona ma również ponieść pewne ryzyko, jeśli te decyzje będą błędne. Więc tu wychodzimy naprzeciw również takiemu strachowi, tak to nazwę. Tego, kto musi się zdecydować na współpracę z tą konkretną firmą. I tutaj jak mówisz, pewność siebie tego zamawiającego, który chce nawet zaryzykować stratę czasu swoich ludzi, może być czasem tym języczkiem uwagi.

Jacek: Takim ostatnim punktem, którym chcielibyśmy – szóstym, ale nie szóstym, to jest taka uwaga, że no tutaj cały czas byliśmy w takiej linii pod tytułem jak przekonywać, jak to robić. Taki punkt ostatni, którym chcielibyśmy się podzielić jest taki punkt, który nazwaliśmy – nie zawsze trzeba sprzedawać. I co tutaj mamy na myśli? Nie każdy klient jest dobry dla naszego software house’u. Nie każdy klient będzie dopasowany z nami na poziomie kultury. Nie każdy klient będzie dopasowany z nami na poziomie wartości. Nie każdego klienta będziemy w stanie przekonać. Nie każdy klient będzie chciał słuchać. Być może pojawią się klienci, którzy chcą – przerysuje, po prostu zapłacić za zasoby we wschodniej europie, rzucić stustronicową knigę z wymaganiami, pojawić się na początku i przyjść za trzy miesiące i oczekiwać świetnych rezultatów i w ogóle dostępności ludzi dwadzieścia cztery H na dobę. Po prostu to co z mojej perspektywy jest istotne to to, że może nie zawsze musimy sprzedawać, w takim sensie, że nie zawsze jest tak, że ta wygrana, faktura czy dłuższa współpraca daje większą wartość od tego, co się dzieje w naszej organizacji, to jak się czują zespoły developerskie, którym przyjdzie z takim klientem pracować, bo możemy dojść do takiego nieprzyjemnego dysonansu, gdzie całą gębą jesteśmy zwinni na każdej konferencji, strona internetowa kipi od buzz word’ów i w ogóle całe biuro wyklejone kolorowymi karteczkami – tu oczywiście półżartem mówię i nagle wchodzimy w kontrakt z klientem, który jest też, przerysuję, kompletnie waterfallowy, kompletnie niezorientowany na partnerstwo i kompletnie nie rozumie czemu zwinność, on po prostu chce, żebyśmy kodowali i siedzieli przy klawiaturze, jeżeli mówimy o software developmencie. Teraz pytanie, czy demotywacja ludzi w zespole, czy ich przechodzenie do innych zespołów, a w skrajnym przypadku opuszczanie organizacji, czy to jest cena, którą chcemy ponieść za ten konkretny kontrakt. I oczywiście nie każda firma jest gotowa podjąć taką decyzję, żeby odrzucić klienta. Nie każda firma też jest finansowo gotowa na coś takiego. Niektóre firmy być może potrzebują każdego kontraktu na pewnym etapie rozwoju, żeby przetrwać. Natomiast ten punkt świadomie stawiamy jako taką pewną kontrę i też takie ostudzenie, że tu nie chodzi o to, żeby przekonać klienta za wszelką cenę. Dlatego tak ostrożnie na początku formułowałem te określenia i obok sprzedaży, która może zabrzmieć tak bardzo twardo stawiałem takie słowa jak zainspirować. Bo tak patrzę na proces sprzedaży z mojej perspektywy on powinien być czysty, oparty na wartościach. Jeżeli coś sprzedajemy no, to po prostu powinniśmy być w stanie to dowieść. No i moim zdaniem to nie jest deal za każdą cenę.

Jeżeli powyższe punkty były dla Ciebie interesujące i chcesz więcej to zapraszam Cię wpis na moim blogu jacekwieczorek.pl/blog. Link do tego wpisu znajdziesz w opisie odcinka, a w samym artykule opisuję więcej strategii, więcej opcji, które możesz zastosować podczas sprzedaży zwinności klientowi. Dodatkowo też zamieszczam tam więcej przykładów i materiałów, które rozszerzają cały ten temat sprzedaży na etapie, kiedy jeszcze nie mamy podpisanego kontraktu.

Kuba: A ja pokuszę się o podsumowanie całego odcinka. Spróbuję też te punkty ująć tak bardziej generalnie, żeby też uwypuklić tę stronę inspiracyjną. Więc mówiliśmy o tym, żeby sprzedawać korzyści, sprzedawać ludzkim językiem to co mamy do uzyskania dzięki współpracy w sposób zwinny, a nie korzystać z żargonu, czy wręcz bełkotu scrumowego czy zwinnego. Warto pokazywać metryki. Warto pokazywać, że mierzymy się. Warto pokazać też, że mamy już rezultaty z dotychczasowej współpracy. Jako dowód, który może być punktem startu do dalszej współpracy z tą konkretną grupą, która zleca nam jakieś wykonanie pracy. Warto też wytłumaczyć złożoną naturę tego, co będziemy realizować. Czy to jest wytwarzanie oprogramowania, czy to szerzej, w ogóle zrealizowanie rozwoju produktu w sposób zwinny. Ten sam fakt złożoności tej natury może być albo na razie w ogóle niewidoczny dla osoby, z którą chcemy zacząć współpracę. Albo on może być bardzo niedoceniany. Warto tutaj zadbać o to, żebyśmy się wszyscy zrozumieli. Warto też pokazać drugiej stronie case study. Jeśli mamy już dotychczas współprace w sposób zwinny w naszej firmie, no to pokażmy to, opowiedzmy o tym, przekonajmy. Opowiedzmy również o tych gorszych stronach tej współpracy i czego się z tego nauczyliśmy. A jeśli w naszej firmie do tej pory nikt tak nie pracował, to postarajmy się o zdobycie case studies z zewnątrz organizacji. Może z naszej branży, a może po prostu ze znanych marek z innych branż. Najtrudniej jest translować darmowy Sprint, ale ja bym powiedział – zaproponuj darmowy Sprint, zaproś do współpracy, zaproś do współpracy na zasadzie eksperymentu zamiast wielce czaić się na jakąś wielką współpracę, szykowanie się, jakieś takie wielkie manewry. Może po prostu zaprośmy tę osobę na godzinne spotkanie, na którym nam opowie co mamy zrobić i za dwa tygodnie pokażmy jej rezultaty i może zupełnie nieświadomie ta osoba właśnie nam zrealizowała darmowo rolę Product Ownera i możemy jej już na przykładach praktycznych z jej życia opowiedzieć o co chodzi i dlaczego tak właśnie chcemy pracować. No i nie zapomnijmy, że są też te momenty, gdy nie sprzedawajmy, bo może jest jeszcze za wcześnie, po prostu nie są dobre warunki, żeby akurat przekonać, bo akurat tej osoby przekonać nam się nie uda.

Jacek: Na koniec chcieliśmy zaprosić Cię na trzeci live na Facebooku, który będziemy organizować 8 czerwca. Jest to spotkanie w nieco luźniejszej formule niż podcast, podczas którego odpowiadamy na Wasze pytania. Często też są to takie pytania mniej formalne, trochę luźniejsza atmosfera. Myślimy o tych spotkaniach jako takim poszerzeniu podcastu w takiej formule takiej bardziej społecznościowej, trochę mniej oficjalnej, trochę takiej odsłaniającej kulisy pracy, ale nadal też merytorycznej. Tak więc jeśli chcesz dołączyć to można to zrobić przez stronę Facebooka, czyli wchodząc na nasz profil Porządny Agile. Link do tego profilu i do tego wydarzenia załączymy w notatkach do tego odcinka.

Kuba: A ja przypominam, że zbieram grupę roboczą na warsztaty czy też może szkolenie z Przypadków Scrumowych. To szkolenie odbędzie się zdalnie 17 i 18 czerwca. Przepracujemy sobie trudne sytuacje, trudne case’y z różnych zespołów scrumowych, z którymi współpracowałem w przeszłości i na tej bazie wypracujemy konkretną listę narzędzi i praktyk, które można stosować. Jeśli macie podobne historie w tym momencie lub będziecie mieli je w przyszłości. I to by było na tyle w dzisiejszym odcinku. Dzięki Jacek.

Jacek: Dzięki Kuba i do usłyszenia wkrótce.