W tym odcinku omawiam najtrudniejsze stwierdzenia klientów, z którymi przychodzi zmierzyć się twórcom oprogramowania.

Transkrypcja odcinka

Cześć, nazywam się Krzysztof Rychlicki-Kicior i witam cię serdecznie w podcaście „Software z każdej strony”, w którym dowiesz się, jak łączą się ze sobą świat biznesu i IT.

To jest odcinek jedenasty – „10 najtrudniejszych fraz w rozmowach o tworzeniu oprogramowania”. W poprzednim odcinku, w takich dość luźnych rozważaniach na temat przyszłości oprogramowania odpłynąłem nieco, między innymi w obszary związane z oczekiwaniami klientów dotyczącymi elastyczności tworzenia oprogramowania.

Po namyśle postanowiłem nieco ten temat rozszerzyć, no i nie da się ukryć, że bardzo łatwo zamienić takie rozważania w narzekania, można by rzec nawet hejt, czy też rant, korzystając z nieco nowszych określeń. Natomiast postaram się, aby moje rozważania miały jednak charakter jak najbardziej merytoryczny. Przy takich założeniach, naturalnie byłoby odwołać się do pewnych obserwacji, bezpośrednio z mojej strony, z moich doświadczeń. Natomiast postaram się dla równowagi przytoczyć również typowe uwagi kierowane wobec software house’u z drugiej strony. Siłą rzeczy nie będą to w większości uwagi pochodzące ode mnie, choć ja też mam pewne doświadczenia w tej materii, natomiast będą to uwagi zgłaszane przez naszych znajomych, klientów, czy nawet leadów, czyli takich perspektywicznych klientów, z którymi nierzadko mamy całkiem ciekawe relacje budowane latami. Zaznaczę też od razu, że te uwagi, które przedstawię, nie muszą być stricte ograniczone jedynie do branży IT, czy też nawet konkretnie software house’ów. U nas mają one na pewno specyficzny kontekst, natomiast tego rodzaju argumenty można spotkać chociażby w branży, czy to samochodowej, czy też remontowo-budowlanej. Bo przecież takie dość popularne hasła: „kto to panu tak zepsuł”, powiedzmy, wypowiadane przez jednego remontowca po robocie wykonanej przez drugiego. To jest chleb powszedni nie tylko w branży remontowej, ale także wśród programistów. I tutaj przyznam, że początkowo ta lista miała być nieco krótsza, ona się nieco rozrosła, podzieliłem ją na dwie części. I postanowiłem w związku z tym podzielić na dwie części również ten odcinek, zachowam numerację.

Natomiast w tej pierwszej części odcinka wypowiem się bardziej z własnej perspektywy, z perspektywy software house’u, a w drugim, w kolejnym odcinku zajmiemy się tą perspektywą nakierowaną na klienta takiej firmy. No dobrze, to zacznijmy od czegoś prostego, tak na rozgrzewkę, dobrze znany tekst, nie tylko w branży IT, czyli „czemu tak drogo?”. Ten tekst spotkamy niewątpliwie w wielu różnych branżach, podejrzewam, że wręcz trudno znaleźć taką, gdzie taki argument w ogóle nie pada. Natomiast w przypadku tworzenia oprogramowania, zwłaszcza kiedy odnosimy się do już istniejących rozwiązań informatycznych, to pytanie pada, jest zadawane naprawdę szczerze. Udzielałem odpowiedzi na nie już tyle razy, że naprawdę dostrzegam tę różnicę, kiedy powiedzmy klient jest świadom kosztów i chce tylko trochę ponegocjować, a kiedy naprawdę jest mocno zaskoczony. I mam pewną wprawę w tłumaczeniu tego rodzaju kosztów. Oczywiście w przypadku tworzenia oprogramowania, takiego dedykowanego na zamówienie, mówimy tutaj głównie o prostej arytmetyce, a dokładnie o iloczynie godzin przeznaczonych na wykonanie danego oprogramowania i stawki godzinowej. I tutaj, o ile ze zrozumieniem stawki, biorąc pod uwagę, ile zarabiają sami programiści obecnie na rynku, z reguły nie ma problemu, no co najwyżej sobie wspólnie ponarzekamy, że no jest, jak jest, o tyle samo wyszacowanie godzinowe już tym problemem często niewątpliwie jest. To jest, mówiąc szczerze i mówiąc z perspektywy również programisty, którym zwłaszcza w ostatnich czasach też zdarza mi się coraz częściej być, co no daje też trochę ciekawego spojrzenia na bieżący stan technologii. I to jest taki paradoks, bo choć z jednej strony jakość oprogramowania na przestrzeni lat rośnie, to jednocześnie ten czas, który programiści poświęcają na stworzenie jakichś konkretnych funkcji wcale co do zasady nie maleje. Owszem, powstają technologie, które przyspieszają budowę najprostszych aplikacji, ale te bardziej zaawansowane niewątpliwie wciąż wymagają sporej ilości pracy. Dlatego właśnie tak ważny jest właściwy dobór narzędzi, aby nie strzelać z armaty do wróbla i nawet jeżeli mamy do dyspozycji jakieś rozbudowane technologie, czy to chmurowe, czy chociażby algorytmy sztucznej inteligencji, to nie zawsze trzeba je wrzucać na pierwszy ogień, do pierwszego prototypu, czy proof of concept jakiegoś rozwiązania informatycznego. Natomiast no podsumowując, nie da się ukryć, że cena oprogramowania niska nie jest i tutaj potrzebna jest, w slangu IT byśmy powiedzieli, taka ewangelizacja, nauczanie klientów, perspektywicznych klientów, leadów, z czego ten koszt wynika.

Argument numer dwa: „myślałem/myślałam, że wszystko da się zrobić”, to już niewątpliwie argument specyficzny dla naszej branży. Właśnie od niego zaczęły się moje rozważania, w poprzednim odcinku wspominałem, że nie idziemy do salonu samochodowego i nie prosimy o zamontowanie kierownicy na dachu, bo każdy racjonalnie myślący człowiek, ale myślę, że ci nieracjonalni też, wiedzą, że jest to niemożliwe. Natomiast wciąż krótki czas istnienia branży IT, jej niezwykle dynamiczny, błyskawiczny wręcz rozwój sprawiają, że osoby nietechniczne, osoby bez tej wiedzy technicznej, technologicznej czasami mają jeszcze większą wiarę w możliwości, w efekty, które można uzyskać za pomocą narzędzi informatycznych od osób faktycznie z tym technicznym doświadczeniem. To prawda, że pod wieloma względami ogranicza nas tylko wyobraźnia, no i oczywiście też budżet. Natomiast niekiedy na drodze tych nietypowych życzeń klientów staje również logika. Czasami też ograniczenia wynikają ze względów formalnych, tutaj zwłaszcza w systemach mobilnych iOS, czy Android. Producenci tych systemów, czyli Google, Apple, no odwrotnie właściwie wprowadzają pewne formalne obostrzenia i chociaż urządzenie byłoby w stanie jakąś funkcję zrealizować po naszej myśli, to po prostu nie jest to dopuszczalne. Takim całkiem ciekawym przykładem jest bardzo restrykcyjne podejście firmy Apple wobec tych zadań, które na urządzeniach, takich jak iPhone, czy iPad można realizować w tle, czyli wtedy, kiedy nie korzystamy z aplikacji. Na przykład jeżeli mamy chociażby, no nie wiem, klienta poczty elektronicznej to ten klient, owszem, poinformuje nas, że dostaliśmy nową wiadomość, bo takie powiadomienia w tle są dopuszczalne, ale nie możemy na przykład zostawić aplikacji i wykonywać jakichś bardziej złożonych obliczeniowo zadań. To jest tłumaczone między innymi chociażby większym zużyciem baterii, które doprowadziłoby do tego, że taki iPhone rozładowywałby się szybciej, klienci byliby niezadowoleni. Tylko że ich uwaga, ich protesty kierowałyby się w stronę Apple’a, a nie w stronę programistów aplikacji, którzy de facto doprowadzaliby do takiego działania. Pewnego rodzaju wariantem tego argumentu jest drobna, acz istotna różnica pomiędzy „myślałem, że funkcję X da się zrobić” w odniesieniu do tego, że „myślałem, że funkcja X jest od razu gotowa do użycia”. W rozmowach handlowych na temat oprogramowania bardzo często mówimy, co da się osiągnąć, a co jest zupełnie niemożliwe. Natomiast to nie oznacza, że taka możliwa do wykonania funkcja jest od razu dostępna. Świetnym przykładem takiej sytuacji są wszelkiej maści raporty. Wiele systemów potrzebuje raportowania, to jest sprawa oczywista i w zasadzie dysponując dowolnym językiem programowania można przygotować praktycznie dowolne raporty. Natomiast to nie oznacza, że te raporty są dostępne od razu, trzeba je oczywiście przygotować. No i tutaj taki brak zrozumienia klientów, który czasami może się pojawić, jest niewątpliwie pewnym problemem.

Argument  numer trzy: „ma być tak, jak ja chcę”. Niewątpliwie argument ten wynika z poprzedniego, czyli z poczucia, że wszystko da się zrobić, połączonego ze staropolskim „płacę, żądam”. Te dwa aspekty połączone razem powodują, że dyskusje z klientem, w których software house proponuje inne rozwiązania, czasami prostsze, ale niekoniecznie prostsze, dlatego że było mniej pracy, tylko dlatego że prostsze rozwiązanie może być również prostsze dla użytkowników. Takie podejście powoduje, że klient może posądzić wykonawcę o lenistwo, a nawet, no niestety o oszustwo, zwłaszcza w przypadku projektów o stałej wycenie fixed price, gdzie dogadujemy się na jakąś kwotę za jakiś zakres prac, no ale pewne szczegóły zostawiamy na później. Problem w tym, że żądanie, czy też prośba klienta po prostu może nie zawsze mieć sens. Podobne sytuacje zdarzają się w innych branżach, chociażby w branży kreatywnej, reklamowej, gdzie oczywiście klienci też lubią ingerować w kształt chociażby projektów graficznych. Powstają różne potworki, w stylu chociażby nieśmiertelnego skeczu Reklama autorstwa Manna, czy Materny, a z takich nowszych przejawów, mamy fanpage na Facebooku Junior Brand Manager, na którym też takie przykłady są publikowane. Natomiast niestety w przypadku oprogramowania nie jest tak łatwo zrozumieć, że żółty tekst na skrajnie jasnozielonym tle nie jest dobrym rozwiązaniem. Przechodząc do konkretów, na przykład takim typowym błędem popełnianym zwłaszcza przez start-up’y jest chęć umieszczenia zbyt wielu funkcji w pierwszej wersji aplikacji. Nie chodzi już o to, jakie są to funkcje, ale często stworzenie takiej aplikacji zamienia się w realizowanie jednej wielkiej listy życzeń, co by było fajnie mieć w takiej apce. No tylko problem w tym, że wydłuża to development, zwiększa koszty i potrafi nawet doprowadzić do porażki projektu, bo ktoś inny może z podobnym rozwiązaniem wyjść wcześniej na rynek. Sami mieliśmy takiego klienta, który dokładał, dokładał nowych funkcji, nawet potem przeszliśmy przez moment usuwania funkcji z systemu. Była to taka aplikacja społecznościowa do dzielenia się kontentem wideo, ale w końcu niestety Facebook wyszedł z podobną funkcją sam, no i oczywiście w tym aspekcie z Facebook’iem się nie wygra. Obecnie na szczęście ten trend powoli w przypadku start-up’ów się odwraca, ta świadomość jest większa. Nawet powstało takie pojęcie, jak „descoping”, gdzie taką listę życzeń po prostu redukujemy, zmniejszamy jej zakres, zgodnie z nazwą, co zwiększa sukces przedsięwzięcia. Natomiast już niezależnie, czy mówimy o start-up’ach, czy o dojrzałych firmach, dla których również oprogramowanie może być istotnym elementem przewagi konkurencyjnej, bardzo często, czy to bezpośrednio, czy w formie takiej osoby, co z tylnego siedzenia, mamy do czynienia z różnego rodzaju biznesmenami, decydentami, którzy odnieśli sukces i są bardzo mocno przekonani o słuszności swoich poglądów. Trzeba przy tym pamiętać, że biznesową skuteczność, której oczywiście trudno odmówić klientom, nie zawsze dobrze przenosi się na grunt technologii. Prawdziwie mądry klient to taki, który wytycza kierunek, ale jednocześnie obdarza pewnym zaufaniem wykonawcę, wierząc, że ten wykonawca, będąc doświadczonym w zakresie, w tym przypadku technologii poprowadzi go we właściwym kierunku.

Argument numer cztery: „rozmawialiśmy o tym wcześniej lub było mówione”. Jest to argument dedykowany wszystkim fanom bezpośrednich spotkań, rozmów telefonicznych, takiego ciągłego wydzwaniania, można by rzec. Oczywiście nie zamierzam się sprzeczać, bezpośrednie rozmowy, takie face to face, czy chociaż wideokonferencje dają bardzo dużo. I sam też ich nie unikam. Natomiast tak naprawdę najważniejsze jest to, co dzieje się po takich spotkaniach, po takich rozmowach, czyli podsumowanie ich. Bo uwierzcie mi, ile razy dochodziło do sytuacji, w których zapomniało się o jakiejś notatce, zapomniało się o takim podsumowaniu i po, nie po dniu, nie po kilku dniach, ale po kilku miesiącach, czy wręcz no nawet latach, okazywało się, że zupełnie inaczej pamiętam tą rozmowę ja, a zupełnie inaczej klient. Nie chodzi więc o to, żeby mieć twardą podkładkę, niemalże dowód w sprawie w sądzie, tylko o to, aby mieć zgodę obu stron, że to, co zostało spisane, to co zostało podsumowane, choćby w ramach takiej prostej notatki jest faktycznie akceptowane. Dlatego poza samym faktem przesłania takiej notatki ważne jest też potwierdzenie, akceptacja ze strony, no klienta zwykle. Nawet przy najlepszych, takich najcieplejszych relacjach, które przecież też się kształtuje, nie należy dać się ponieść za bardzo tej pozytywnej atmosferze, która z reguły faktycznie jest obecna na początku w zasadzie wszystkich projektów. Nie należy uznawać, że: „a, jakoś to będzie, dogadamy się, zrobimy projekt na ryzyku”, jak to powiedział kiedyś mój znajomy. Jeśli ktoś nie lubi komunikacji mailowej, co zdarza się niewątpliwie i też w pełni rozumiem, istnieje masa przeróżnych narzędzi. Wymienię tutaj choćby Trello, czyli taką tablicę z kolumnami, gdzie możemy przesuwać kartki z komentarzami, przypisywać je do osób, oznaczać kolorami, no jest tam cała paleta możliwości. Trello wspominam dlatego, że mieliśmy już kilka bardzo pozytywnych doświadczeń ze strony klientów wybitnie nietechnicznych, którzy doskonale radzili sobie z jego obsługą. I naprawdę za pomocą tego narzędzia byliśmy w stanie prowadzić projekt do przodu. No i argument numer pięć, ostatni na dziś, chyba mój ulubiony, tak naprawdę ten odcinek na początku miał się nazywać „5 najtrudniejszych słów”, ale koniec końców były to w większości jednak frazy, czy też nawet zdania, ale ten ostatni argument będzie pojedynczym słowem. A to słowo, to „oczywisty”, chodzi nomen omen oczywiście o to, że obecność jakiejś funkcji w oprogramowaniu jest oczywista. Dlaczego? A bo ktoś widział w innym, podobnym rozwiązaniu, że taka funkcja była, no to przecież oczywiście powinna być ona tutaj. Problem z oczywistymi funkcjami, czy elementami oprogramowania jest taki, że z reguły wychodzą one zbyt późno. Bo jeżeli prowadzimy jakieś wstępne rozmowy, ustalamy zakres, i wtedy klient mówi: „a, myślałem, że w tym dokumencie znajdzie się też taka oczywista funkcja”, to oczywiście my mówimy: „jasne, taka funkcja się znajdzie. Ona może skutkować pewnym kosztem, no ale ustalamy po prostu zakres prac, nie ma problemu”. Niestety z reguły brak tej oczywistej funkcji pojawia się dużo później, kiedy klient już chce odebrać oprogramowanie, czy zaczyna je testować po wykonaniu całego procesu wytwórczego. No i właśnie wtedy niestety pojawia się ta dyskusja. Problem bierze się też z tego, że na taki, no można powiedzieć, zarzut z naszej strony, że a przecież można było to wpisać do dokumentacji, do zakresu projektu, klient stwierdza właśnie, że to było tak oczywiste, że nie uważałem, że należy to dodać. Jednocześnie patrząc na to możliwie obiektywnie, wiadomo, że pewne elementy oprogramowania faktycznie można uznać za oczywiste. Jeżeli mamy chociażby formularz logowania do jakiegoś systemu, mamy pole na login, mamy pole na hasło, no to oczywiście musimy jakoś zatwierdzić te dane, z reguły przyciskiem. Natomiast tutaj nie chodzi raczej o takie wyjątki, a zdecydowanie bardziej chodzi o to, aby przyjąć czytelny i akceptowany przez obie strony format komunikacji i dokumentowania tego, co ma być zrobione i trzymać się tej dokumentacji. A jeżeli nawet pojawia się jakaś zmiana, to po prostu trzeba przejść przez proces wprowadzenia tej zmiany w taki sposób, aby nie zaburzyło to reszty procesu tworzenia oprogramowania. Jeżeli więc obie strony ustalą wspólnie proces, w ramach którego takie oczywiste rzeczy będą po prostu dodawane do systemu, do aplikacji, to myślę że żadna ze stron nie będzie ani stratna, ani też nie będzie narzekała na jakość współpracy. Bo takie sytuacje, takie wyjątki zdarzają się i będą się zdarzać, natomiast jak zawsze najważniejsze jest to, jak z takimi sytuacjami sobie poradzimy.

Dotarliśmy do końca listy, a właściwie tej części z punktu widzenia software house’u, no troszeczkę taki mały rancik, można powiedzieć, chyba jednak wyszedł, ale mam nadzieję, że nie za duży, i że jednak było bardziej konstruktywnie, niż marudząco. Natomiast w drugiej części, czyli za dwa tygodnie siądę po drugiej stronie stołu, można by rzec, bo sam również mam pewne doświadczenia bycia klientem, po tej właśnie drugiej stronie. Ale przede wszystkim czerpię tutaj doświadczenie od innych osób, wielu przedsiębiorców, z którymi rozmawiałem, z którymi starałem się dociec, w czym leżą problemy w wytwarzaniu oprogramowania, co ich trapi. Także mam nadzieję, że za te dwa tygodnie również w interesujący sposób będę w stanie przedstawić ten drugi punkt widzenia. Na dziś to już wszystko, bardzo dziękuję za wysłuchanie tego odcinka, kłaniam się i do usłyszenia.