Przypuszczam, iż kontekst naszej pracy oraz konkretne zadania, są nieco inne. Być może pracujesz w analizie, testowaniu, programowaniu, może w managemencie. Niemniej jednak podrzucam dziś garść pytań, które zadaję na wstępie nowemu klientowi przed rozpoczęciem współpracy. Myślę, iż w formie podanej dalej lub nieco przez Ciebie zmodyfikowanej będą one użyteczne również w Twojej pracy.
Słowo wstępu o shift left
Zanim zaczniemy skupmy się na bardzo ważnym warunku niezbędnym, aby użyć moich pytań. Brzmi on shift left. Ogólnie rzecz biorąc shitf left jest pojęciem z zakresu procesów produkcji i oznacza, iż staramy się tak organizować dany proces, aby czynności na których może wystąpić ewentualny błąd, przesuwać na możliwe wczesne etapy procesu – czyli w lewo (zgodnie z tradycją proces wizualizujemy na osi liczbowej od lewa do prawa.)
Weźmy dla przykładu proces wytwarzania oprogramowania. Oczywistą aktywnością wykrywającą błędy jest testowanie. Zasada shift left w tym przypadku wskazuje, iż trzeba zminimalizować konieczność testowania na samym końcu procesu na przykład tuż przed wdrożeniem. Powód jest prosty: naprawianie błędów na wczesnych etapach produkcji jest tańsze, szybsze i prostsze niż na końcowych etapach.
W telegraficznym skrócie: kontemplując wnikliwie shift left dochodzimy do wniosku, iż zanim będziemy testować gotową wdrożoną (na przedprodukcję) funkcjonalność, wcześniej można przetestować API serwisów, a wcześnie integrację między modułami, a wcześniej integrację komponentów wewnątrz modułów, a wcześniej można testować jednostkowo, a wcześniej używać Test-Driven Development, ale jeszcze wcześniej można opracować plan koniecznych testów funkcjonalności jeszcze przed przystąpieniem do prac, a jeszcze wcześniej można zadbać o praktykę regularnych refinementów, z kolei jeszcze wcześniej można zadbać o to, aby dowiadywać się o możliwych planach biznesowych zanim zostaną one zatwierdzone, ale jeszcze wcześniej można dowiadywać się o planach sprzedażowych zanim kontrakty zostana podpisane i plany sprzedażowe staną się planami biznesowymi.
W powyższym akapicie wielokrotnie (rekurencyjnie ???? ) zastosowałem zasadę shift left. Wyszedłem od błędu we wdrożonej funkcjonalności, a następnie pytałem sam siebie które z czynności mogę zrobić wcześniej w procesie pracy. Ostatecznie doszedłem do wniosku, iż aby zmniejszyć liczbę błędów we wdrożonym oprogramowaniu, warto zacząć o tego, aby gwałtownie dowiadywać się o planach sprzedażowych w biznesie. No i właśnie do tego chciałbym nawiązać ????
Gdzie jest ten etap?
Żeby zastosować pytania, które za chwilę podam, potrzeba je zadać na możliwie wczesnych etapach pracy nad oprogramowaniem. Najlepiej zanim na podstawie tego, co Twoja organizacja sprzedała klientom, zostanie przygotowany pakiet celów dla IT i przekazany do wykonu.
Klient zewnętrzny
Gdy pracujesz dla klienta zewnętrznego ów wczesny etap nazywa się presales. Staraj się tam być. jeżeli nie Ty osobiście, to może ktoś z zespołu. W trakcie spotkania przedsprzedażowego (presales) można wychwycić pomysły klienta oraz uprzedzić ewentualne konsekwencje. Możesz wtedy porozmawiać o potrzebach biznesowych albo o tym, co jest in scope / out of scope. Etap przedsprzedażowy to bardzo dobre miejsce do zadania pytań, które za chwilę Ci podam.
Co, jeżeli nie możesz być na spotkaniu przedsprzedażowym? Wtedy proponuję nawiązać ściślejszy kontakt ze osobami ze sprzedaży lub osobami, które w Twojej firmie mogą nazywać się: key account manager, product manager, business development manager. Nawiązanie regularnego kontaktu z tymi osobami, pozwoli Ci zadać moje pytania. Z pewnością otrzymasz wartościowe odpowiedzi.
Moim klientom proponuję, aby przeprowadzić wewnętrzny warsztat, na którym sprzedaż przedstawi IT to, co oferuje klientom. Takie warsztaty bywają naprawdę zaskakujące.
Konkretną metodą, która organizuje takie zbliżenie biznesu z IT są procesy up stream. W przeciwieństwie do procesów down stream – czyli produkcji – procesy up stream służą do analizowania potencjałów biznesowych i podejmowania decyzji, jakie funkcjonalności warto stworzyć. Jeden z procesów up stream – sprzedażowy – opisałem w artykule Kanban w sprzedaży.
Jeśli nie zdążysz nic zrobić na etapie przedsprzedażowym, to zwykle po nim następuje etap, który jest nazywany po polskawu warsztatami skołpingowymi albo po prostu analizą. Różnią się niuansami, ale mniej więcej chodzi w nich o to samo – o scope – czyli o zdefiniowanie zakresu pracy. Na tym etapie również możesz zadać pytania, które za chwilę Ci podam.
Klient wewnętrzny
Jeśli pracujesz dla klienta wewnętrznego, na przykład dla departamentów biznesowych, tam również istnieje odpowiednik etapu presales. Miewa on różne nazwy: cele sprzedażowe, MBO, OKR, strategia. Przeważnie istnieją spotkania, na których omawiane (nie ogłaszane) są wymienione tematy oraz dokumenty robocze, do których można by zajrzeć. Te miejsca, jeżeli uda Ci się je zidentyfikować są źródłem wiedzy, której potrzebujesz. Wiedzy o planach i pomysłach zanim zostaną one zatwierdzone. Wtedy będziesz mieć możliwość zadania pytań, które za chwilę Ci podam.
W przypadku klienta wewnętrznego ma również zastosowanie organizacja procesów up stream.
Kung-fu Panda
Jeśi nie znasz jeszcze filmu Kung-Fu Panda gorąco Tobie go polecam. Dla leniwych i zapracowanych streszczam w dwóch zdaniach. Miś panda pragnie odczytać zawartość magicznego zwoju, gdyż zawarta jest tam wielka tajemnica dająca ogromną moc. Po otwarciu zwoju okazuje się, iż jest on pusty…
Ja i Ty jesteśmy właśnie w miejscu, do którego dotarł miś panda otwierając zwój. Otóż nie ma żadnych magicznych pytań. Nie ma żadnego mindhacka, który nagle otwiera głowy klientów i sprawia, iż podejmują odpowiednie decyzje.
Pytania takie, czy inne mają drugorzędne znaczenie. Najważniejsze jest kiedy je zadasz. Zadawaj pytania na wczesnym etapie prac, zanim zostaną podjęte wiążące decyzje. Pytania zadane zbyt późno – choćby te najbardziej wyrafinowane – kilka zmienią. Na nic się nie zdadzą, bo kontrakty będą już podpisane, zobowiązania podjęte i jedyne co będzie można zrobić, to zacisnąć zęby i dowieźć projekt. Śpiesz się zatem, bo nie ma czasu do stracenia! Śpiesz się i co sił biegnij w lewo — shift left.
A oto one
Żebyś nie został/a z tym poczuciem oświecenia graniczącego z rozczarowaniem, w które – mam wielką nadzieję – udało mi się Ciebie wprowadzić, podaję pytania, które na wstępie zadaję moim klientom.
Ważne: są to pytania, które zadaję ja – konsultant, moim klientom czyli firmom, tworzącym oprogramowanie.
O software/produkt
- Czy tworzycie swój własny produkt?
- Czy skupiacie się na raczej na rozwoju tego produktu, czy raczej na realizacji projektów/wdrożeń?
- Czy wasz produkt jest oparty o platformę w rodzaju Salesforce, SerciceNow lub analogiczną?
- Czy może jest napisany od początku przez was? W czym?
- Czy wdrażacie jakiś gotowe rozwiązanie innego producenta?
- Co to jest?
- W czym piszecie jest custom development?
O klientów
- Czy macie dużo drobnych klientów czy kilku dużych?
- Jak wiele customowego developmentu oczekują klienci?
- Jak radzicie sobie z sytuacjami, gdy oczekiwania klientów rozwalają Wam architekturę?
- Czy klient jest public czy business – co przeważa?
- Czy pracujecie fixed scope czy t&m?
- Czy robicie raczej jednorazowe wdrożenia, czy drążycie potrzeby klientów i nastawiacie się na długą współpracę?
- Ile przeciętnie trwa jedna „akcja” u klienta? tygodnie, miesiące, lata?
- Gdy robicie analizę przedwdrożeniową, to macie potem możliwość zmienić procesy u klienta, czy musicie się do nich dostosować?
- Czy gdy szacujecie ficzer do wykonania, to brany jest również pod uwagę koszt utrzymania albo co gorsza koszt wygenerowania długu technicznego?
O proces developerski?
- Czy zespoły pracują w oparciu o jakąś nazwaną metodykę: scrum, kanban czy coś własnego?
- Gdy już prace zostaną zakontraktowane, jak często klient ogląda efekty pracy? Na końcu przy odbiorze? W międzyczasie weryfikując milestones? Inaczej?
- Zbieranie wymagań i analiza przedwdrożeniowa są:
a. płatne i klient może sobie wziąć dokument analizy i iść do innego dostawcy?
b. bezpłatne, jak nie dojdzie do współpracy, to jest to nasz koszt?
c. powiedzmy, iż bezpłatne – wliczamy do całości prac?
O metody i narzędzia
- Jakich metod używacie przy okazji prac dla klienta?
- przykłady: User Story Mapping, Impact Mapping, Event Storming, UML, BPMN, C4, Gherkin, inne?
- Z jakich narzędzi używacie w do pracy nad tematami dla klientów?
- przykłady Jira, Trello, MSOffice365, Conluence, Redmine, Miro, Mural, Jamboard, inne?
O komunikację z klientem
- Kto reprezentuje klienta dla zespołu developerskiego? Wasz PO/PM? Ktoś bezpośrednio od klienta?
- Czy klient ma dostęp np. do waszego Jiry/Conluence?
- Jeśli nie, to jak się z nim komunikujecie? Mailem? Dokumentami word? Chat?
I co myślisz o moich pytaniach? Pytania, jak pytania, ale moment ich zadania jest adekwatny – możliwie wczesny.
