<h2 data-line="4" dir="auto" id="lejek-sprzedaowy">Lejek sprzedażowy</h2>
<p data-line="6" dir="auto">Najpierw obrazek, potem cała reszta:</p>
<figure><img src="https://editor.blogstatic.io/web/assets/uploads/d06c56bd70577c676b72e1245be3d9c4.png" id="/tmp/phpJubmRa" data-image="/tmp/phpJubmRa" width="380" height="551" style="width: 380px; max-width: 380px;"></figure><p data-line="10" dir="auto">To jest <a href="https://pl.wikipedia.org/wiki/Lead_sprzeda%C5%BCowy" data-href="https://pl.wikipedia.org/wiki/Lead_sprzeda%C5%BCowy">lejek sprzedażowy</a>. Myślę, iż koncepcja obiła Ci się o uszy, ale jeżeli nie, to zwięźle streszczam. Przypuśćmy, iż chcesz sprzedać 100 dresów z kreszu. Nie wszyscy, których zapytasz będą chętni bykupić. Mogą na przykład preferować dresy z 4 paskami. Musisz zatem przedstawić ofertę kupna np. 1000 osobom, a z nich 500 osób będzie poważnie zainteresowanych. Z tych 500 dres przymierzy może 200, a ostatecznie kupi 100 osób. Na każdym kolejnym etapie sprzedaży zostaje coraz mniej osób chętnych do wydania pieniędzy. Gdybyśmy liczbę osób reprezentowali graficznie dzięki odcinków o długości 1000mm, 500mm, 200mm, 100mm, to jeżeli położymy je równolegle obok siebie powstanie coś takiego:</p>
<figure><img src="https://editor.blogstatic.io/web/assets/uploads/fa3b9c5a6f852b31b8f1ff242ab9c9a1.png" id="/tmp/php0EnYHs" data-image="/tmp/php0EnYHs" width="520" height="261" style="width: 520px; max-width: 520px;"></figure><p data-line="14" dir="auto">Przypomina to trochę lejek. Reprezentuje prawidłowość procesu sprzedażowego od oferty do płatności i dlatego nazywa się lejkiem sprzedażowym.</p>
<p data-line="16" dir="auto">Biznes siedzi na górze lejka. W biznesie czas płynie szybko, bo więcej się dzieje. Walczą tam o przychód, o prowizje, o płynność. Zanim zlecą jedną rzecz do IT, sami muszą przerobić ich ze kilkadziesiąt. Przerobić to znaczy: ocenić, oszacować, sprawdzić czy ma sens biznesowy. IT natomiast bierze jedną zleconą rzecz i rozdłubuje ją do ziarnistości atomu, bo tak trzeba, aby coś porządnie zrobić.</p>
<p data-line="18" dir="auto">Jednym z pomysłów na uporządkowanie współpracy pomiędzy biznesem a IT, jest wstawienie pomiędzy nich analityka, który będzie tłumaczył z biznesowego na systemowe i odwrotnie.</p>
<p data-line="20" dir="auto">Pytanie killer brzmi: kto w tym układzie ma najbardziej przerąbane? No, pewnie, iż analityk! Z opisanego wyżej stylu pracy biznesu oraz IT wynika, iż biznes będzie miał do analityka pretensje, iż analizuje za wolno. IT będzie miało pretensje, iż analizuje zbyt niedokładnie. Współczuję :(</p>
<h2 data-line="22" dir="auto" id="a-moe-zesp-analitykw">A może zespół analityków?</h2>
<p data-line="24" dir="auto">Powszechnym rozwiązaniem problemu niewystarczających mocy przerobowych analityka, jest leczenie objawowe, czyli: zatrudnijmy więcej analityków. Niestety mamy do czynienia z układem z dodanim sprzężeniem zwrotnym, który działa tak:</p>
<figure><img src="https://editor.blogstatic.io/web/assets/uploads/50466d0c09e53d3d439a51e5e760dfdb.png" id="/tmp/phpOldx42" data-image="/tmp/phpOldx42" width="448" height="237" style="width: 448px; max-width: 448px;"></figure><p data-line="28" dir="auto">Zespół analityków jako wydzielona jednostka w organizacji ma sens, gdy:</p>
<ul data-line="30" dir="auto"><li data-line="30" dir="auto">pracujecie dla klientów zewnętrznych i analitycy są w projektach u różnych klientów,</li><li data-line="31" dir="auto">pracujecie dla klientów wewnętrznych, analityków jest wielu i trzeba o nich zadbać.</li></ul><p data-line="33" dir="auto">Oba powyższe rozwiązania pomogą zająć się rozwojem analityków oraz standardami ich pracy. W innych przypadkach polecam zatrudnianie analityków na budżecie managera zespołu, dla którego analityk pracuje. Ostatecznie o standardy pracy może dbać nieformalne <em>community of practice</em> w organizacji.</p>
<h2 data-line="35" dir="auto" id="uciec-z-lejka-sprzedaowego">Uciec z lejka sprzedażowego</h2>
<p data-line="37" dir="auto">W opisanym na początku przykładzie analityk jest interfejsem pomiędzy biznesem a IT. Słowo "interfejs" po polsku tłumaczy się jako "międzymordzie". No zastanów się, czy chcesz być międzymordziem? :)</p>
<p data-line="39" dir="auto">Pierwszym zadaniem analityka jest ucieczka z lejka sprzedażowego:</p>
<figure><img src="https://editor.blogstatic.io/web/assets/uploads/dc63f1d56a2cd4ea397c00851b1d23f0.png" id="/tmp/phpoFoZX8" data-image="/tmp/phpoFoZX8"></figure><p data-line="43" dir="auto">Jednym zdaniem: <strong>analityk zamiast pośredniczyć, powinien być wzmacniaczem współpracy między biznesem i IT</strong>.</p>
<p data-line="45" dir="auto">Poniżej precyzuję konkretnego różnice pomiędzy dwoma opisanymi miejscami analityka w procesie dostarczania. </p>
<table><thead><tr><th width="50%">jesteś międzymordziem, gdy<br></th><th width="50%">jesteś wzmacniaczem, gdy</th></tr></thead><tbody><tr><td width="50%">spisujesz oczekiwania od każdego z interesariuszy, a potem przygotowujesz dla zespołu backlog prac</td><td width="50%">pomagasz interesariuszom ustalić wspólny cel, a w sprawie szczegółowych wymagań organizujesz warsztat z biz-IT</td></tr><tr><td width="50%">organizjesz spotkania z grupą > 4 interesariuszy, gdzie oni mówią, a Ty piszesz albo nagrywasz</td><td width="50%">organizujesz to spatkanie tak, by pracowali interesariusze, a ty trzymasz się roli moderatora, który dba o wartościowy output warsztatu</td></tr><tr><td width="50%">masz wielu interesariuszy o sprzecznych priorytetach i starasz się zadowolić wszystkich, albo samodzielnie podejmujesz decyzję o kolejności realizacji prac</td><td width="50%">moderujesz interesariuszy tak, aby to oni dogadali się między sobą co do priorytetu prac</td></tr><tr><td width="50%">wbjasz taski do backloga</td><td width="50%">ustalasz z zespołem i PO, kto będzie wbijał taski do backloga</td></tr><tr><td width="50%">przygotowujesz zespołowi kompletną specyfikację wymagań</td><td width="50%">wykorzystujesz refinement, aby przewarsztatować z zespołem wymagania; razem produkujecie karteczki, a potem na ich podstawie opracowujesz specyfkację</td></tr><tr><td width="50%">przygotowujesz dokumentację techniczną (powykonawczą lub na koniec sprintu)</td><td width="50%">opracowujesz standard tworzenia dokumentacji technicznej najbardziej odpowiedni do kontekstu, w którym pracuje zespół; dbasz dokumentacja była kompletna</td></tr><tr><td width="50%">jesteś jedyną osobą reprezentującą interesariuszy, z którą widuje się zespół</td><td width="50%">w razie potrzeby organizujesz spotkania/warsztaty z interesariuszami albo specjalistami biznesowymi</td></tr><tr><td width="50%">wyjaśniasz zespołowi cele i założenia biznesowe</td><td width="50%">pomagasz odpowiednim interesariuszom sformułować cele i założenia biznesowe; przygotowujesz ich do wyjaśnienia ich zespołowi<br></td></tr></tbody></table><h2 data-line="58" dir="auto" id="proroctwo-">Proroctwo :)</h2>
<p data-line="60" dir="auto">Kilka lat temu występowałem na <em>Business Analyst Meetup</em> we Wrocławiu i powiedziałem między innymi coś takiego: <em>(...) niedawno Microsoft kupił GitHub i trenuje swoje algorytmy AI. Przewiduję, iż niedalekiej przyszłości rola developerów straci na znaczeniu. Zawsze jednak będzie potrzeba ludzi, którzy poruszają się na granicy różnych domen, rozumieją i biznes i technologię. Analitycy będą w cenie.</em></p>
<p data-line="62" dir="auto">I proszę bardzo - proroctwo zaczyna się sprawdzać. Tak, jak wspomniałem na początku, obserwuję, iż na nowo odkrywa się rolę analityka. </p>
