EN Articles | PL Articles
About me | How can I help? | My LinkedIn Profile

Project Manager, więc kto? Sprzedaż, czyli RFI, RFP

Jest to drugi artykuł z cyklu Project Manager, więc kto., jeżeli nie czytałeś/aś od początku to zachęcam do przejścia na stronę Project Manager, więc kto? Wstęp.

Rola project managera może być skrajnie różna w zależności od firmy. Często stanowiska nazywane zwrotem “project manager” - nie są dla project managerów. Seria artykułów będzie zawierać pewne uproszczenia i ograniczony kontekst.

Ten artykuł nie jest o sprzedaży.

Sprzedaż, czyli najważniejsza umiejętność przyszłości

Ponad 5 lat temu, gdy pracowałem jako programista zaczynałem rozumieć, że realizowane projekty nie zostały przyniesione do nas przez Świętego Mikołąja, a poprzedził je jakiś proces sprzedażowy. Postrzegałem sprzedaż jako coś co polega na “wciśnięciu” klientowi naszych usług po możliwie najwyższej cenie. Wydawało mi się, że całość wymaga od nas nauki technik negocjacyjnych i manipulacyjnych.

W 2015 roku pojechałem na warszawską konferencję “Sprzedaż. Najważniejsza umiejętność przyszłości” w której udział brał Robert Cialdini, czyli autor książki Wywieranie wpływu na ludzi. Teoria i praktyka. Było to idealnym uzupełnieniem moich dotychczasowych założeń i w dalszym ciągu myślałem, że w sprzedaży chodzi o kit.

Negocjacje, a sprzedaż?

Dobrym punktem odniesienia do zrozumienia relacji występujących w sprzedaży jest przytoczenie definicji słówka “negocjacje”. Można byłoby podobnie tutaj założyć, że proces negocjacyjny to wojna polegająca na unicestwieniu przeciwnika i zgarnięciu wszystkiego dla siebie. Jeżeli jednak zapytamy dowolnego negocjatora lub chociażby zajrzymy do dowolnej na Wikipedii to zauważymy, że jest odrobinę inaczej.

Dwustronny proces komunikowania się, którego celem jest osiągnięcie porozumienia, gdy przynajmniej jedna strona nie zgadza się z daną opinią lub z danym rozwiązaniem sytuacji. Negocjacje to sposób porozumienia się w celu rozwiązania konfliktu oraz dojścia do porozumienia obydwu stron, proces wzajemnego poszukiwania takiego rozwiązania, które satysfakcjonowałoby zaangażowane w konflikt strony.

Powyższa definicja mówi, że negocjacje są dążeniem do osiągnięcia porozumienia w punkcie, który jest najbardziej korzystny dla obydwu stron. Brzmi przyjemniej i mniej negatywnie? Podobny jest cel sprzedaży. Jeżeli jesteśmy firmą usługą to oferujemy pewną wartość naszym klientom. W procesie sprzedaży chcemy dogadać się z naszym potencjalnym klientem i zaoferować mu naszą pomoc (partnerstwo) w realizacji jego celu.

W rezultacie, klient powinien być usatysfakcjonowany, że dzięki naszej pracy wniesionej do jego biznesu jest w stanie wiele zyskać, a tym samym my jesteśmy wynagrodzeni za nasz czas pracy po satysfakcjonującej stawce. Podobnie jak w udanym procesie negocjacyjnym, celem sprzedaży powinno być osiągnięcie sytuacji w której obydwie strony zyskują, czyli win-win.

Podział odpowiedzialności w procesie

Podział odpowiedzialności w całym procesie będzie zupełnie inny w różnych firmach. Mamy software house dysponujące całym departamentem sprzedażowym, a mamy również takie w których nie ma żadnego sprzedawcy. To co jest jednak wspólne dla wszystkich software house to perspektywa w której im wyższe stanowisko zajmujecie, tym większe prawdopodobieństwo, że sprzedaż Was dotknie. Jeżeli zwrócimy uwagę na pozycje zajmowane przez naszych “szefów”, czyli CEO, CTO, COO, Manager, Head of … to zazwyczaj każda z tych ról stoi przynajmniej jedną nogą po kostki w procesie sprzedażowym.

Sad, but true… jesteś senior developerem, chcesz być CTO? Będziesz musiał przynajmniej zrozumieć sprzedaż.

Pozyskiwanie klientów

Firmy szukają klientów we wszelakie sposoby. Jedni robią to przez cold mailing i cold calling. Inni przez wysyłanie specjalistów na różne konferencje technologiczne. Inni przez reklamowanie się na konferencjach specjalistycznych innych branż (np. produkcyjnych, handlowych, nieruchomościowych, budowlanych, medycznych). Inni przez tworzenie materiałów marketingowych i udostępnianie ich za pozostawienie adresu mailowego na tzw. landing page. Inni zgłaszają się jako potencjalni wykonawcy opublikowanego przetargu. Jeszcze inni budują długoterminowe relacje chodząc na squasha z przyszłymi klientami. Sposobów jest wiele i każdy z nich charakteryzuje inny procent konwersji oraz koszt. O ile cold mailing jesteśmy w stanie zrealizować za setki złotych to możliwość wystawienia się na niektórych zagranicznych konferencjach może przekraczać koszt 150 000 zł.

O pozyskiwaniu klientów zostało napisanych wiele książek, a ja z pewnością nie jestem specjalistą od tego. Ograniczmy się do sytuacji w której “dział sprzedaży” ma już kogoś na celowniku i oczekuje od nas (project managera pracującego w software house) pewnego wsparcia. Sprzedawca otrzymuje dokumenty do uzupełnienia lub zapytania, które częściowo jest w stanie okiełznać samodzielnie, a inne z naszą pomocą.

Request for information (RFI)

RFI to zapytanie o informację. Jest to najbardziej ogólny z omawianych w tym artykule “dokumentów”, który jest uzupełniany przez potencjalnego wykonawce jeszcze przed zaznajomieniem się ze szczegółami projektu. Na tym etapie zazwyczaj posiadamy jedynie bardzo ogólną wiedzą na jego temat. Jeżeli z dokumentem RFI spotkałby się programista to prawdopodobnie powiedziałby że nic w nim nie ma i byłby zły, że marnujemy jego czas.

RFI zawiera ogólne pytania dotyczące naszej firmy. Ich celem jest zebranie zgłoszeń od większej ilości potencjalnych wykonawców oraz ogólne zapoznanie się z tymi firmami. Dokumenty te są zazwyczaj ustryktuzowane i zawierają listę pytań w tabelce. Takie ustandaryzowanie dokumentu pozwala na późniejsze porównanie zgłoszonych wykonawców oraz ocenę każdej odpowiedzi w pewnej skali (np. 0-10 punktów).

Załóżmy że klientem, który szuka wykonawcy jest firma z Londynu chcąca stworzyć system WMS (Warehouse Management System).

Przykładowe pytania jakie mogą się pojawić w RFI to:

Rolą project managera może być wsparcie sprzedawcy w sformułowaniu odpowiedzi na bardziej techniczne / procesowe / produktowe pytania. Najlepiej ocenieni wykonawcy trafiają do kolejnego etapu, czyli RFP.

Request for proposal (RFP)

RFP to zapytanie ofertowe. W ramach tego elementu procesu, klient udostępnia nam materiały potrzebne do zaproponowania rozwiązania, wraz z jego wyceną. Zazwyczaj jest to lista funkcjonalności potrzebnych wytworzenia, lista wymagań, czasami dostarczane są designy aplikacji, a w przypadku ich braku - podobne (może konkurencyjne) strony internetowe na których możemy się wzorować przy tworzeniu oferty / wyceny.

W zależności od doświadczenia naszego sprzedawcy możemy być poproszeni o wsparcie w przygotowaniu odpowiedzi na zapytanie ofertowe. Jest to dobrą praktyką, ponieważ antywzorcem jest sytuacja w której sprzedawca przygotowuje wycenę projektu bez porozumienia z programistami / architektami / osobami technicznymi. Brak obecności specjalisty przy proponowaniu rozwiązania i jego estymowaniu prowadzi do niesamowitych problemów po podpisaniu umowy, gdzie programiści dowiadują się, że muszą zrealizować projekt w 20% potrzebnego na jego realizację czasu. W celu uniknięcia takiej sytuacji sprzedawca prosi o pomoc project managera. PM na bazie swojej wiedzy pomaga sprzedawcy w przygotowaniu odpowiedzi, a jeżeli jego wiedza nie jest wystarczająca - koordynuje alokację czasu specjalistów (którzy prawdopodobnie pracują nad projektami i zarabiają dla firmy pieniądze), aby w jak najbardziej efektywny sposób pomogli nam w przygotowaniu naszej oferty.

Efektem tego etapu jest propozycja rozwiązania wraz z wyceną.

Wycena

Ale jak możemy wycenić projekt, który zajmie 1,5 roku skoro nie potrafimy nawet poprawnie wyestymować pojedynczego zadania w najbliższym sprincie? To trudne pytanie. Czasami programiści wyceniający tak długie projekty posiłkują się stwierdzeniem “wstępnych estymacji”. W efekcie, klient otrzymuje “wstępną wycenę”, która jest kilkukrotnie niższa od spalonego do realizacji projektu budżetu, zmierzonego na dzień zakończenia projektu.

Wykazując się odrobiną empatii można się domyślić, że takie sytuacje są niedopuszczalne i zdarza się, że kończą się procesami sądowymi. Składając ofertę klientowi, wyceniając projekt, musimy wykazać się naszymi najlepszymi umiejętnościami i doświadczeniem, aby zrobić to jak najbardziej precyzyjnie. Nawet gdy pracujemy w time&materials i przysługuje nam prawo do pobrania opłaty za wymienione powyżej przekrocznie początkowej wyceny to naszym obowiązkiem jest minimalizowanie ryzyka przekroczenia budżetu o chociażby 1 zł.

Budowanie zaufania

Powyższe przekłada się na zaufanie. Jako programiści chcemy korzystać z najnowszych technologii, robić refactoring, uczyć się każdego dnia, estymować w czymkolwiek innym niż osobogodziny i aplikować Kubernetes’a oraz event sourcing do prostego projektu. Klienci nam na to wszystko pozwolą, gdy będzie to miało uzasadnienie, a naszym profesjonalizmem i budowaniem relacji już od początku procesu sprzedażowego zaczniemy budować zaufanie. To rola project managera oraz każdego członka zespołu. Nie ma tu miejsca na wciskanie kitu.

Ale jak?

Nie padła jeszcze odpowiedź na to jak wyestymować projekt na 1,5 roku do przodu. No i nie padnie. Kluczowe jest doświadczenie i różne punkty widzenia. W ramach minimalizacji ryzyka możemy zaproponować klientowi przeprowadzenie tzw. discovery workshop przed przygotowaniem wyceny lub np. bardzo drobno zgranulować wyceniane wymagania, czy też spisaniem potencjalnego rozwiązania problemu przy każdym z wycenianych wymagań. Nie zawsze mamy jednak ku temu okazję, szczególnie przy odpowiedziach na przetargi publiczne.

Jest to trudne, ale gdyby wytwarzanie oprogramowanie było proste to robiłby to każdy. :)

Czyli kim są dla nas sprzedawcy?

Czasami wśród managerów i developerów panuje przekonanie, że dział sprzedaży jest w pewien sposób naszym wrogiem. Wydaje nam się, że są to osoby dostarczające problemy, rzeczy niezwiązane z naszym projektem, które powodują odrywanie się od niego i utrudniają nam skupienie się nad dobrym wykonywaniem naszej pracy. Nikt nie chce robić wycen, nikt nie chce mierzyć się z codziennym poczuciem “odrzucenia”, gdy np. tylko 10% przygotowanych przez nas wycen finalnie wejdzie do firmy (czyt. klient zdecyduje się na współpracę z nami).

Pamiętajmy jednak, że gdyby nie ten etap to żaden z nas nie pracowałby aktualnie nad żadnym projektem, być może nasza firma by nie istniała. Zapewniam, że po poznaniu tego procesu można poczuć olbrzymi respekt do ludzi dbających o ten pierwszy z etapów całego procesu wytwarzania oprogramowania. Osoby zajmujące się sprzedażą są częścią naszego zespołu i jako project managerzy musimy pracować nad wzajemnym wspieraniem się wszystkich jego członków.

Do posłuchania

Podcasty to świetna rozrywka podczas chodzenia po mieście, jazdy autobusem czy pociągiem. Zachęcam do przesłuchania:

Źródła i pojęcia

Dalej chcesz zostać PMem? Jeżeli tak, to zachęcam do przeczytania trzeciego artykułu Project Manager, więc kto? Analityka, czyli definiowanie zakresu projektu.

Back to Home


© 2023 Rafal Makara </> Powered by Jekyll and The Plain theme.