W tym odcinku omawiam najtrudniejsze stwierdzenia software house'ów, z którymi przychodzi zmierzyć się ich klientom.

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 dwunasty „10 najtrudniejszych fraz w rozmowach o tworzeniu software, część druga”. W poprzednim odcinku poruszyłem tę samą tematykę, ale w kontekście fraz, które stanowią, można powiedzieć, ból i esencję życia w software house’ie podczas rozmów z klientami i prospektami.

Dziś dla równowagi, jak to mawiał mój trener personalny, gdy jeszcze do niego chodziłem przed urodzeniem się syna: „aby równo puchło”, zajmiemy się argumentami z drugiej strony stołu, czyli stwierdzeniami software house’u, które mogą budzić smutek, zażenowanie, irytację, a nawet i kilka innych negatywnych emocji u klientów. Oczywiście znacznie bliżej jest mi do punktu widzenia software house’u, bo sam jestem współwłaścicielem jednego z nich, Makimo. Z pewnością warto będzie kiedyś nagrać odcinek z udziałem doświadczonego w tym zakresie gościa. Jednocześnie sam od wielu lat spotykam się z różnymi opiniami znajomych, licznych partnerów biznesowych. Miałem również okazję sam znaleźć się po tej stronie klienckiej, choć nie było to wiele okazji. Natomiast rozmawialiśmy między innymi jako Makimo z różnymi podwykonawcami, innymi software house’ami, ale nawet mam doświadczenie stricte z perspektywy interesariusza zainteresowanego zakupem oprogramowania w innej organizacji, niż Makimo poza tymi obowiązkami w ramach software house’u. Postaram się więc przybliżyć te typowe dla klientów bolączki i wyjaśnić też poniekąd ich przyczyny. Mam nadzieję, że pomoże to w rozmowach pomiędzy wytwórcami oprogramowania, czyli właśnie software house’ami, a ich klientami.

Przez analogię do poprzedniego odcinka, do którego serdecznie zapraszam, odcinek numer 11, czyli część pierwsza tego tematu, zacznę od frazy spotykanej dość powszechnie u wszelkiej maści wykonawców, czyli „nie da się”. W naszej branży jest to niewątpliwie trudny argument, bo tak, jak wspominałem w poprzednim odcinku, mało rzeczy w IT jest faktycznie logicznie, teoretycznie niemożliwych. Duży problem tkwi też w odmiennym postrzeganiu czasochłonności. Często zdarza się, że klienci inaczej rozumieją czasochłonność, inaczej wyobrażają sobie czas potrzebny na realizację jakieś funkcji, dodanie jakiegoś modułu systemu, niż ma to faktycznie miejsce w przypadku pracy programistów. Pół biedy, jeżeli to klientowi wydaje się, że dodanie jakiegoś mechanizmu do systemu będzie skomplikowane, no a tak naprawdę nie wymaga to aż tyle pracy, jesteśmy w stanie szybko dowieść rezultat. Wtedy to jest ten miły scenariusz, zespół staje na wysokości zadania i klient jest z reguły bardzo zadowolony. Niestety w drugą stronę dzieje się to chyba znacznie częściej, czyli klient myśli, że jego prośba o dodanie jakiejś funkcji do systemu, na przykład niestandardowego raportu, który wykracza poza standardowe możliwości narzędzia, klientowi wydaje się, że napisanie takiego raportu będzie dosyć łatwe, a tu okazuje się, że no niekoniecznie. Nawet ostatnio mieliśmy taką sytuację, na początku staraliśmy się stworzyć raport, korzystając z takich standardowych narzędzi oferowanych przez platformę, którą wybraliśmy w ramach systemu informatycznego. I te kolejne wersje raportu byliśmy w stanie generować w zasadzie na przestrzeni kilkunastu, kilkudziesięciu minut, bo była to kwestia, mówiąc potocznie, wyklikania niezbędnych opcji. Natomiast w pewnym momencie doszliśmy do przysłowiowej ściany i okazało się, że musimy napisać taki raport dedykowany. No i tutaj niestety liczba już nie minut, a godzin oscylowała wokół kilkunastu i klient był nieco zaskoczony, że aż tyle czasu nam to zajmuje. Niestety choć różnica wydawała się niewielka, to musieliśmy przejść z wyklikiwania do programowania, a to niestety takie konsekwencje często generuje. No i co? Czy faktycznie się nie da? No oczywiście, da się, ale wysiłek był naprawdę spory.

Argument numer dwa: „ja w tym kodzie pracować nie będę”. Ten argument jest już zdecydowanie mocniej związany ze światem IT, a nawet dokładnie światem tworzenia oprogramowania. I wynika on z dość prostej zależności. Otóż wiele organizacji wciąż stoi dopiero przed wyzwaniem digitalizacji, ucyfrowienia swoich organizacji, ale jednocześnie coraz więcej firm i różnych instytucji dysponuje już istniejącym oprogramowaniem, często dedykowanym. Gdy na horyzoncie pojawia się kwestia dalszego rozwoju organizacji, bo na przykład przekracza ona kolejne bariery liczby pracowników, pojawia się konieczność rozwoju oprogramowania, ale jednocześnie trudno jest przekonać taką organizację, aby kolejne, nowe wersje oprogramowania stworzyć od zera. No bo jak to? Mamy coś, co działa, coś co się sprawdzało, trzeba to tylko lekko zmienić i mielibyśmy wyrzucić wszystko co zostało zrobione do tej pory do kosza. To brzmi po prostu irracjonalnie. Rozwój istniejącego oprogramowania wiąże się oczywiście z koniecznością mniejszej lub większej pracy z tymże istniejącym oprogramowaniem, czyli istniejącym kodem źródłowym, kodem oprogramowania. Tego niestety programiści za bardzo nie lubią. Tutaj z pewnością można wysnuć pewne podobieństwo do remontowców, wykończeniowców, ewentualnie też do mechaników samochodowych, czyli przedstawicieli takich zawodów, którzy lubią narzekać na efekty pracy poprzedników. Dokładnie to samo, choć pozornie w zupełnie innym świecie ma miejsce w przypadku informatyków i programistów. Znowu, o ile jeszcze prosimy tych naszych programistów o ocenę, audyt istniejącego rozwiązania, no to oczywiście taką ocenę dostaniemy, natomiast nie jest to jeszcze taka kiepska sytuacja, o tyle znacznie gorzej, jeżeli nasi programiści będą zmuszeni do pracy w istniejącym środowisku. Prawda jest jednak taka, że na rynku będzie coraz więcej już istniejącego oprogramowania, którego nie będzie można łatwo porzucić. Trzeba więc szukać kompromisów, z jednej strony potrzebne jest zrozumienie dla programistów, bo uwierzcie mi, sam tym programistą jestem i praca w istniejącym kodzie, to naprawdę spore utrudnienie. Tutaj nie tylko chodzi o to, że poprzedni programiści, programistki mogli zostawić coś nieciekawego w kodzie, jakieś niezbyt eleganckie konstrukcje, ale same technologie też bardzo się zmieniają. I kiedy programiści uczą się nowych technologii, a potem przyjdzie im pracować w projekcie sprzed kilku lat, to po prostu jest to niezwykle trudne, aby powrócić do tych starych wersji technologii. Z drugiej strony, jak to w kompromisie, należy też zrozumieć to, co tkwi, tą wartość, która tkwi w istniejącym oprogramowaniu. Nawet jeżeli ono nie zostało napisane zbyt elegancko, nawet jeżeli jest przestarzałej technologii, to ono przynosi klientowi pewną wartość. Gdyby było bezwartościowe, to faktycznie moglibyśmy mówić o przepisaniu takiego oprogramowania, stworzeniu go ponownie od zera. Najważniejsze jest aby takie projekty realizować ostrożnie i spokojnie, z odpowiednio długim czasem na taki, można powiedzieć, rozruch przy przejęciu takiego odziedziczonego starego projektu, po angielsku się często mówi „legacy” przynajmniej do czasu aklimatyzacji i odnalezienia się nowego zespołu w starym projekcie.

Argument numer trzy: „ale tego się używa inaczej”. To argument, który na szczęście odchodzi nieco do lamusa za sprawą coraz większej świadomości i wagi doświadczenia użytkownika i ogólnie użyteczności, czyli user experience, usability. Natomiast wciąż, zwłaszcza gdy pierwsze skrzypce gra termin, czyli potrzebujemy oprogramowanie na za miesiąc, to niestety te aspekty UX-owe, użyteczności schodzą na dalszy plan. I o działaniu, o wyglądzie aplikacji coraz bardziej zaczynają decydować programiści lub ewentualnie inne osoby, które za pomocą kodu, bądź innych wyspecjalizowanych narzędzi tworzą graficzne interfejsy użytkownika i projektują interakcje. W normalnych projektach, takich tworzonych zgodnie z obowiązującymi, może nie normami, ale takimi dobrymi praktykami, aplikacje są implementowane, są realizowane zgodnie z precyzyjnymi wytycznymi projektantów, designerów właśnie użyteczności, projektantami interfejsów użytkownika. Ale jeżeli w budżecie, czy to pod względem finansów, czy właśnie zwłaszcza terminów, zabraknie dla nich miejsca, oj biada, biada. Wtedy często okazuje się, że użytkownicy nie potrafią korzystać z takiej aplikacji zaprojektowanej wizualnie przez programistów, a jedyną odpowiedzią na taką sytuację może być wyżej przytoczony argument, że przecież programiście wydawało się, że tak i tak, jak się wyklika, tu się coś wpisze, to będzie dobrze. Owszem, zawsze można powiedzieć tak, jak nam kiedyś powiedział klient, że użytkownicy najwyżej kilka razy się pomylą i w końcu się nauczą. Ale czy w świecie oprogramowania, w obecnych czasach możemy sobie na to dzisiaj pozwolić? Argument numer cztery: „a, bo to trzeba jeszcze”. No właśnie, trzeba to, trzeba tamto. Poprzednie argumenty jakoś tak skoncentrowały się wokół programistów, programistek, osób takich wykonawczych w projektach. Sam nim jestem, więc też czuję się uprawniony do pewnego takiego delikatnego osądu naszej grupy zawodowej. Ale prawda jest taka, że nawet jeżeli te argumenty dotyczyły pracy właśnie programistycznej, to z reguły taka praca jest efektem niezbyt mądrego zaplanowania projektu od strony menadżerskiej, zarządczej.

Ten argument, czyli ten czwarty argument, którym teraz się zajmujemy, dotyczy już jednak stricte sprzedaży. Dość nagminnym zjawiskiem u sprzedażowców, i to raczej nie jest tylko problem branży IT, jest bycie bardzo ugodowym, obiecywanie złotych gór, byle zdobyć klienta. Zdarzało nam się mówić, zwłaszcza gdy mieliśmy takie projekty, w których pracowaliśmy z firmami, które właśnie sprzedawały pewne usługi, myśmy je wykonywali, no i trochę denerwowaliśmy się czasami na sprzedażowców, że oni tylko umieją powiedzieć „tak, tak, oczywiście, będzie zrobione”, bądź obiecać nierealistyczny termin. Problemem charakterystycznym dla naszej branży jest kwestia kosztów dodatkowych, bo o ile problem stawki godzinowej w zasadzie trudno źle zakomunikować, stawka jaka jest, każdy ją widzi, o tyle wyszacowania godzin potrzebnych do realizacji, choć też wydawałoby się, że są dosyć precyzyjne, lubią być często przekraczane. Nie chcę w tym momencie przypisywać winy jednej ze stron, bo z reguły takiej stuprocentowej winy po jednej stronie nie ma. Czasami może być na przykład niejasny zakres, specyfikacja projektu, i to naprawdę często, tutaj w tym przypadku wina leży po obu stronach. Firma może powiedzieć, że klient nieprecyzyjnie się wyrażał, klient może powiedzieć, że firma mogła lepiej dopytać, to w końcu oni są specjalistami. Natomiast koniec końców są to problemy komunikacyjne, no ale ktoś za te godziny musi zapłacić, albo będzie to klient, albo firma weźmie to na siebie. Czasami development może po prostu się wydłużyć, bo wyszacowania jednak są w pewien sposób przybliżone. I znowu pytanie, kto to weźmie na siebie. Czasami tutaj, chociaż w sumie stoję w tym odcinku bardziej po stronie klientów, no to czasami zdarzają się sytuacje, w których klient zobaczy to, co chciał dostać, nawet jeżeli widział wcześniej makiety, projekty graficzne i stwierdza, że to jednak, no do końca nie jest to. Znowu, można powiedzieć, że można było to jeszcze lepiej zaprojektować, jeszcze bardziej zprototypować, ale tutaj no niestety bardzo ważny jest czynnik ludzki. Taką uniwersalną radą, poradą w tym zakresie jest to, aby starać się pracować w takich przypadkach zwinnie, agile’owo, jak to się mówi teraz, bo im szybciej będziemy dowozić, dostarczać rezultaty, im szybciej klient zobaczy aplikację, tym mniejsze ryzyko, że potem powie, że coś jest nie tak. No bo jeżeli już klient widzi jedną, drugą, trzecią wersję i dopiero potem stwierdza, że coś mu nie pasuje, no to już jest taka sytuacja, w której wina raczej jest po jego stronie. Ale tak, jak wspominałem, rzadko można mówić o takiej jednostronnej winie.

No i argument numer pięć, tu też się tak fajnie złożyło, że jednym słowem jestem w stanie podsumować „lingo”, czyli żargon. Informatycy i programiści mają ogromną tendencję do wplatania słownictwa branżowego, no właśnie żargonu, nie tylko w rozmowie między sobą, co jest dość zrozumiałe, ale także z klientami, i to nawet tymi nietechnicznymi. Jest to dość naturalne, bo jeśli używamy jakichś słów na co dzień, to stają się one nieodłącznym elementem naszego języka. U nas też jest tak, że często nawet osoby, które w naszej firmie pełnią funkcje nietechniczne, nie są programistami, programistkami przez jakiś tam dłuższy czas, ale przyzwyczajają się do pewnych pojęć, mimo że nie korzystają z nich faktycznie jakby w swojej pracy. Natomiast z klientami jest już trudniej, pamiętam tutaj, jak jeden z naszych członków zespołu na spotkaniu z nietechnicznym klientem zdecydowanie powiedział, że „zdeplojujemy apkę na sandboksie”. Klient bardzo poważnie podszedł do tematu, pokiwał z uznaniem głową, nie dało się poznać, że to stwierdzenie nie brzmi zbyt zrozumiale, ale no może w sumie, nigdy nie zapytałem tak naprawdę klienta, może zrozumiał, o co chodzi. Ale to było sformułowanie bardzo żargonowe, dlatego ja dla pewności dopowiedziałem, że chodzi po prostu o umieszczenie aplikacji, którą robiliśmy, na środowisku testowym, a nie już od razu na sklepach. Z przedstawionych argumentów ten ostatni właśnie chyba najłatwiej jest naprawić, bo polega to po prostu na takiej dosyć prostej edukacji, na regularnym przypominaniu osobom technicznym, aby nie stosowały tego żargonu, aby stosowały jakieś bardziej przyjazne dla osób nietechnicznych synonimy. Chociaż nawet mi, po tych wielu latach dydaktyki, rozmów z klientami, nawet mi czasem zdarza się zapędzić i zapomnieć. Dosłownie z miesiąc temu w dyskusji mailowej tak bardzo chciałem objaśnić pewien problem, że klient po otrzymaniu mojego maila, wysłał tylko maila z krótkim pytaniem, które no mogę tak powiedzieć, że stwierdził: „ale o co Ci właściwie chodzi, Krzysiek?”. Także z tą kwestią słownictwa niby jest łatwo, ale jednak nie do końca. I na tym argumencie dochodzimy do końca dzisiejszego odcinka. Zdaję się, że wyszedł krótszy, niż poprzedni, no jednak natury się nie oszuka. Natomiast bardzo gorąco zachęcam do przekazywania własnych doświadczeń, sugestii związanych właśnie z tymi trudnymi frazami, z tymi problemami, jakie pojawiają się we współpracy, bo przecież frazy to tylko pretekst do tego, aby po prostu omówić problemy, jakie pojawiają się często właśnie w komunikacji, głównie tak naprawdę. Czy to z perspektywy właśnie tej programistycznej, bycia programistką, programistą, kierownikiem projektu, ale też z perspektywy klienta. Dajcie znać, z pewnością warto będzie wrócić do tego tematu za jakiś czas, bardzo możliwe, że właśnie z jakimś gościem i omówić własne doświadczenia, ale też Wasze sugestie.

Na tym kończymy dzisiejszy odcinek. Ja oczywiście nagrywam je z pewnym wyprzedzeniem, ale za parę godzin udaję się na urlop, także w wyjątkowo dobrym nastroju dzisiaj jestem, może stąd te śmiechy, hihy w trakcie. Oczywiście nie wpłynie to na cykl publikacji, co dwa tygodnie możecie mnie wysłuchać. No teraz to już wszystko, dziękuję bardzo za wysłuchanie tego odcinka. Kłaniam się i do usłyszenia.