Zakładamy, że ludzie wiedzą to co my… i rozumieją to, co mówimy, tak jak my chcemy, żeby rozumieli.
Laptop
Ostatnio zadzwonił do mnie pewien znajomy z problemem. Z jakiegoś sklepu internetowego próbował kupić pakiet Microsoft Office i utknął, nie wiedział co zrobić. W sklepie tym były bowiem do kupienia pakiety Office z podziałem na dwie grupy: Mac i PC, a on ma laptopa, więc (jego zdaniem) nie może kupić oprogramowania ani z jednej, ani z drugiej grupy.
Cóż, wyjaśniłem znajomemu, że powinien zainteresować się oprogramowaniem z kategorii PC, ponieważ ta jest odpowiednia dla jego urządzenia. Właściciel sklepu dokonał pewnego uproszczenia i założył, że dla wszystkich jest jasne, że każdy komputer z zainstalowanym systemem Windows – czy to stacjonarny, czy laptop – ma podobne wymagania dotyczące oprogramowania.
Osoby obracające się w pewnej dziedzinie często wpadają w pułapkę, bowiem zakładają, że “wszyscy to wiedzą”, że “przecież to oczywiste”… Ale, jak widać, nie zawsze i nie dla wszystkich jest oczywiste. To, że my o czymś wiemy, że coś jest dla nas oczywiste, nie oznacza, że takie jest również dla kogoś innego.
Dla czytelności wystarczyło, by właściciel sklepu opisał produkty przypisując je do systemu Mac lub Windows i sprawa byłaby jednoznaczna. A tak: wzbudziła wątpliwości i frustrację.
Oczywista procedura
Jakiś czas temu pewien znajomy z racji kłopotów, jakie go dotknęły, zdecydował się na ogłoszenie upadłości konsumenckiej. Najpierw czytał na temat wszelkich konsekwencji przeprowadzenia takiej procedury, żeby wiedzieć z czym się ona wiąże. Wybrał prawnika, któremu zaufał, że procedurę przeprowadzi najlepiej jak to możliwe. Zasypywał go pytaniami wskazując na kluczowe dla niego aspekty i wątpliwości. A jednym z kluczowych dla niego aspektów była kwestia ochrony jego rodziny.
Rozpoczął działania, prawnik w jego imieniu złożył odpowiedni wniosek, sąd ten wniosek rozpatrzył pozytywnie i sprawa trafiła do Syndyka. I tu, jednym z pierwszych działań Syndyka, było poinformowanie żony znajomego poprzez wysłanie do niej listem poleconym informacji o rozpoczętej procedurze. Znajomy zadrżał, bo nie miał pojęcia co to oznacza dla jego rodziny, a wcześniej o takiej praktyce nie słyszał. Zadał pytanie swojemu prawnikowi… a ten, w rozbrajający sposób odpowiedział, że przecież to oczywiste, “przecież już od 1932 roku jest znana i stosowana praktyka informowania współmałżonków o upadłości”. Dla znajomego nie było to absolutnie oczywiste i odpowiedź prawnika, zamiast go uspokoić, jeszcze przysporzyła mu niepotrzebnych nerwów.
Na szczęście – nie wyniknęły z tego żadne negatywne konsekwencje i procedura nie dotknęła w sposób negatywny rodziny. Natomiast, jak widać z powyższego przykładu, założenie, że coś “jest oczywiste” może czasem niemal doprowadzić do zawału serca.
Sortowanie list
Tego typu rozbieżności w rozumieniu czegoś, co jest oczywiste, a co nam się wydaje, że takie jest, zdarzają się często w realiach biznesowych. I, jeśli się pojawiają, zwykle kończą się problemami.
Pamiętam kiedyś pewien projekt, który realizowaliśmy dla naszego klienta – duży dedykowany system typu CRM, bardzo rozbudowany, z wieloma funkcjonalnościami. System został opisany możliwie dokładnie, stworzona została dokumentacja i stała się załącznikiem do umowy. Jeden z punktów tej dokumentacji brzmiał “System będzie umożliwiał sortowanie alfabetyczne listy klientów i osób”.
Byliśmy na finiszu realizacji tego projektu i spotkaliśmy się z klientem by zaprezentować efekty naszej pracy. Prezentujemy między innymi wspomnianą funkcjonalność sortowania – klikamy w nagłówek tabeli, w nazwę kolumny “nazwisko” – wszystkie osoby na liście sortują się alfabetycznie, według nazwiska. Klikamy w nagłówek tabeli “imię” – wszystkie osoby poniżej sortują się alfabetycznie według imienia.
Pełen sukces – wykonaliśmy naszą pracę na 100%.
W tym momencie chwilę ciszy przeszywa mrożące krew w żyłach pytanie klienta: “A w jaki sposób te osoby posortować alfabetycznie tak, aby sortowanie było po nazwisku ORAZ po imieniu, żeby obok siebie byli wszyscy Kowalscy, potem wszyscy Nowakowie, a alfabetycznie były posortowane imiona w ramach tych nazwisk? Tak jak w Excelu.”. Czyli, innymi słowy, czy da się posortować dane wielopoziomowo. W naszym modelu tak się nie dało. Mało tego: w żadnym znanym nam systemie informatycznym (poza Excelem) – też się tak nie dało. Ale klient tworząc zapis w umowie “System będzie umożliwiał sortowanie alfabetyczne listy klientów i osób” miał na myśli “wielopoziomowe, jak w Excelu”, a my “jak w innych systemach CRM – jednopoziomowo”.
Powstał spór i niewiele brakowało, a zakończyłby się w sądzie. Nie chcieliśmy jednak toczyć kilkuletniej batalii przed sądem, szczególnie, że od tego zależała wypłata całości wynagrodzenia za budowę systemu. Dlatego podjęliśmy decyzję o spełnieniu żądania klienta i zmianie funkcjonalności.
Koszt, jaki nasza firma z tego tytułu poniosła, to kilkanaście tysięcy złotych. Tyle kosztowała nas różnica w interpretacji tego samego zapisu w umowie.
Głuchy telefon
Często spotykam też przypadki rozbieżności interpretacji zapisów, gdzie na spotkanie sprzedażowe z klientem jedzie handlowiec, który ustala z klientem warunki współpracy. Po spotkaniu, w pocie czoła opisuje je w firmowym systemie CRM i, z zachowaniem należytej staranności, notuje wszystko dokładnie to, co zostało ustalone z klientem. Następnie informacja ta trafia do osoby pełniącej funkcję PM’a (menedżera projektu), a ten skrupulatnie przetwarza tę informację, tworząc zadania i rozdzielając je pomiędzy poszczególnych pracowników.
Zapewne każdy w dzieciństwie bawił się w “głuchy telefon” – taką zabawę, w której uczestnicy ustawiają się jeden obok drugiego i pierwsza osoba szepce na ucho drugiej jakieś zdanie. Następnie druga przekazuje to samo zdanie trzeciej, również szeptem. Kiedy zdanie dociera do osoby ostatniej – chyba nigdy się nie zdarzyło by brzmiało tak samo, jak wypowiedziane przez pierwszą osobę.
A w zabawie tej zwykle posługujemy się jednym zdaniem.
Kontrakt z klientem to zawsze znacznie bardziej rozbudowany zestaw informacji i ustaleń. Ile więc okazji do tego, by wdrożyć, całkiem nieświadomie, zabawę w głuchy telefon do naszej komunikacji biznesowej. A co jeśli opisana przeze mnie kaskada jest znacznie bardziej złożona i zlecenie od klienta nie przechodzi kolejno przez 3 osoby w firmie, ale przez 5 lub 6?
W efekcie: to co zleca klient nie zawsze jest tym, co otrzymuje na koniec procesu tworzenia.
Humorystycznie tę sytuację przedstawia poniższy mem:
Prosty projekt
Jakiś czas temu spotkałem się z klientem, który znał moje realizacje, wiedział, że zajmuję się tworzeniem oprogramowania i że mam na tym polu spore doświadczenie. Postanowił zlecić mi realizację projektu dla swojej firmy.
– Tu nie ma żadnych trudnych spraw, same proste działania – oznajmił klient podczas naszego pierwszego spotkania i narysował na kartce proces, jaki chce, żeby został zdygitalizowany. Na kartce pojawiło się siedem kwadracików, połączonych strzałkami.
Rzeczywiście, proces dotyczył kilku kroków, które można opisać następującą sekwencją: materiał wchodzi do firmy, trafia do działu pierwszego, następnie do działu drugiego, a po przejściu pięciu działów, już w formie gotowego wyrobu – jest gotowy do wysyłki do odbiorcy. Wstępna ocena stopnia złożoności projektu pozwoliła mi przyjąć założenie odnośnie czasu i kosztu wykonania prac.
Oczywiście, jak zwykle, diabeł tkwi w szczegółach, więc zacząłem doprecyzowywać z klientem poszczególne funkcjonalności, jakie program miał realizować – co ma dziać się na etapie „wejścia materiału do firmy”, co w dziale pierwszym i w kolejnych, a co na etapie wysyłki.
I tak, podczas kolejnych spotkań zaczęło się okazywać, że „przecież to oczywiste”, że jak materiał wchodzi do firmy, to konieczna jest obsługa magazynu. A właściwie kilku, bo firma musi mieć możliwość zarządzania w sposób swobodny kilkoma magazynami. A poza tym, przy takiej ilości materiałów, które są obsługiwane przez firmę, konieczne jest wprowadzenie identyfikacji materiałów przez kody kreskowe. I to w taki sposób, by na etapie gotowego wyrobu, było wiadomo z jakich materiałów i z jakich dostaw ten wyrób powstał. Ha… i najlepiej, by można było dotrzeć do informacji, który pracownik w poszczególnych etapach był odpowiedzialny za wykonanie tego wyrobu. Poza tym „jest oczywistym”, że jak produkt jest wysyłany do odbiorcy, to trzeba wygenerować fakturę. I „oczywiście” odpowiednie dokumenty załadunkowe i przewozowe, żeby można było łatwo dotrzeć do informacji co jest na samochodach i żeby to spełniało wszelkie normy… A ponieważ część odbiorców jest zagranicznych, więc dokumenty muszą być w kilku językach. No tak – „oczywiście” nazwy wyrobów w systemie także.
I tak płynęliśmy.
W trakcie naszych ustaleń okazało się, że z pięciu działów wstępnie narysowanych przez klienta, zrobiło się dwanaście. Ponadto doszliśmy do tego, że w procesie zdarza się, że produkt, przechodząc pomiędzy poszczególnymi działami, czasem jest wysyłany do podwykonawcy. Wykonawca uszlachetnia wyrób, więc wraca on już jako nieco inny produkt, co powinno znaleźć odzwierciedlenie w systemie. Zdarza się też, że w procesie tworzenia wyrobu strzałki nie zawsze biegną z działu 1 do 2, z 2 do 3, itd. – czasem jest to z 1 do 5, z 5 do 2… a czasem nawet któryś z działów może być odwiedzany wielokrotnie.
W efekcie coś co było oczywiste dla klienta, i to na tyle, że zawarł to w kilku blokach narysowanych na kartce papieru, takim nie było. Dopiero po dokładnym opisaniu wszystkich elementów procesu okazało się, z czym de facto się mierzymy. Moje pierwotne założenia dotyczące czasu potrzebnego do wykonania tego projektu legły w gruzach.
Jestem właścicielem softwarehouse’u LEA24.
Od 2000 roku zajmuję się optymalizacją procesów w firmach, projektowaniem i tworzeniem dedykowanych rozwiązań informatycznych, doradztwem w zakresie oprogramowania i sprzętu, a także promocją w internecie.