Często dostaję pytania związane z analizą biznesową albo rolą analityka. Poniżej cytuję kilka z nich:

Mam klienta, który nie za bardzo chce z nami współpracować, niecierpliwi się. Znasz może jakieś techniki, które by mi pomogły?

Przejęliśmy projekt po innej firmie, tam prawie nie ma dokumentacji, a eksperci biznesowi są bardzo trudno dostępni. Jak sobie poradzić w tej sytuacji?

Sprzedawcy znowu zakontraktowali rzeczy, których nie mamy. Nie mamy czasu na zbieranie wymagań, bo deadline jest na koniec kwartału. Myślisz, że Event Storming albo Story Mapping mogą tu pomóc?

Każda z cytowanych sytuacji obrazuję dokładnie ten sam przypadek. Wpadłeś w projekt, w którym już wszystko jest ustalone: zakres, cena, termin, a może nawet i błędy, które wystąpią. No i co ty analityku masz z tym zrobić? Jaką analizę wykonać? Na jakie decyzje projektowe masz wpływ? Odpowiadam: na żadne. Bo to jest coś, co nazywam projektem źle sprzedanym. Nie ma tu miejsca na analizę. To trzeba po prostu dowieźć i tyle.

Masz bardzo niewielkie pole manewru w takiej sytuacji, bo dostałeś się do projektu zbyt późno. Dlatego zamiast szukać technik na obsłużenie tej beznadziejnej sytuacji, skupię się na tym, co robić, aby jej unikać.

Pchaj się do presales

Gdy pracowałem jako programista, tworzyliśmy oprogramowanie webowe do czegoś tam. Nasz sprzedawca pojechał do klienta i rozpoczął swoją nawijkę. W pewnym momencie klient spytał:

  • Dobra, a jak się ten program instaluje?
    Na co sprzedawca niewiele myśląc - Dokładnie tak jak programy gazety. Wkłada Pan płytkę i uruchamia. [mb: pamiętajmy, że był to rok 2006]

Przez następny tydzień ośmioosobowy zespół developerów kombinował, w jaki sposób z softu webowego zrobić program instalowany "z płytki". Zrobiliśmy, a jakże - custom wersja dla tego klienta. Było to chyba najgłupsza robota, w jakiej brałem udział.

Rada moja taka: pchaj się do presales. Analityk na etapie presales to nieoceniona pomoc dla Sprzedaży. Twoim zdaniem będzie tu nie dopuścić do tego, aby klientowi nie obiecano gruszek na wierzbie.

Umowa o współpracy

Moim zdaniem rzeczy takie jak dostępność przedstawicieli klienta dla wykonawcy, sposób współpracy, zlecania i odbioru powinny zostać literalnie wymienione w umowie. Klienci są najczęściej zajęci, gdyby nie byli, to nie zlecali by roboty 😃. Często chcą ci przekazać temat, a potem go odebrać. Regularnej współpracy "w trakcie" bywa, że woleli by uniknąć.

Gdy naciskasz na taką umowę, Sprzedaż szepnie zarządowi, że z taką umową to nie sprzedacie. To bardzo ważki argument. Jednak, gdy patrzę wstecz na swoje projekty, jestem zdania, że często lepiej odpuścić na początku, niż sprzedać na marnych warunkach, a potem wtopić albo zamęczyć Delivery.

Ta cholerna prowizja

Osobiście jestem wrogo nastawiony do prowizji od sprzedaży ponieważ:

  • skupia sprzedaż na prowizji, a Delivery na technikaliach - mają różne cele i często wzajemnie się zwalczają
  • z horyzontu magicznie znikają koszty utrzymania - sprzedanie feature za 20k to żaden wyczyn, jeśli generuje 5k kosztów utrzymania rocznie; pamiętajmy, że raz napisany kod już zawsze trzeba supportować
  • sprzedawane są rzeczy najłatwiejsze do sprzedania, zamiast tych, które są strategicznie istotne
  • sprzedaż zamykana jest zbyt szybko - za prowizję można sprzedawać np. europalety, praca intelektualna wymaga refleksji, namysłu i zgłębienia tematu; nie ma na nią czasu, gdy marże są obcięte do granic możliwości
  • bywa, że testy są wycenione w ofercie jako osobna pozycja, a klient wtedy mówi To ja za testy dziękuję.; i kto to potem będzie fixował? [:

Jeśli już prowizji a musi być, to w parze z nią powinna iść również struktura sprzedaży, która będzie mówić o tym, co chcemy sprzedawać, a nie tylko co możemy sprzedawać.

W BNS IT w pewnym momencie zlikwidowaliśmy prowizję od sprzedaży na rzecz podniesienia podstawy wynagrodzenia. Z punktu widzenia organizacji to był bardzo dobry krok. Wynik finansowy o dziwo był lepszy i ubyło stresu przy wyznaczaniu celów.

Metryki

Parę lat temu, gdy zachodnie firmy przeniosły swe łaskawe oczy z Orientalnego Wschodu na naszą sielską krainę, brali my wszystko jak leci. Nie było tak słabego kodu, którego nie można było przejąć. Po pewnym czasie sytuacja uległa zmianie. Polskie firmy zaczęły uzależniać cenę za utrzymanie/rozwój przejętego kodu od od metryk - słaby kod wysoka cena, sensowny kod - atrakcyjna cena.

Dlaczego w przypadku analityków nie zrobić tego samego? Brak dostępnych ekspertów dziedzinowych, chaos w dokumentach - stawka x 3. To w głównej mierze kwestia odpowiedniej podaży zleceń.

Worksphop ze Sprzedażą

Na koniec namawiam do zrobienia ćwiczenia, w którym weźmie udział Delivery oraz Sprzedaż. Niech sprzedawcy zrobią prezentację sprzedażową przed IT, niech zaprezentują to, co sprzedają. A potem feedback i action pointy. To będzie ciekawy workshop.

.