Mikołaj Lehman

Dlaczego wkurza mnie gdy traktujesz mój zespół IT jak kuriera

Czyli o tym jak rozpocząć współpracę z dostawcą oprogramowania…

Za każdym razem gdy ktoś rozpoczyna rozmowę od “mam taki pomysł na aplikacje jak Uber, tylko trochę inną, ile to będzie kosztować?”, mam ochotę kliknąć “rozłącz z rozmowy”. Pomimo tylu lat w branży, to w pełni logiczne pytanie nadal wywołuje u mnie silne emocje. Pewnie podobnie mają architekci budynków, gdy ktoś pyta o koszt zbudowania losowego domu. Jak w takim razie dowiedzieć się ile będzie kosztować moja aplikacja?

Budowanie aplikacji jak budowa domu?

Analogie do budowy domu czy np. do kupna samochodu, który może kosztować 50 tys. albo 5mln na pierwszy rzut oka wydają się sensowne. Jednak samochód jest gotowym produktem, który kupujesz z salonu i nad którego stworzeniem producenci spędzili lata oraz wydali miliardy dolarów. Dom również mimo sporej złożoności składa się z dosyć ograniczonej liczby elementów oraz jego oddanie do użytku zazwyczaj oznacza, że w najbliższym czasie nie będziemy dokonywać radykalnych zmian. Budowanie oprogramowania jest ciężkie do porównania z innymi branżami. Jeżeli budujesz marketplace to tak jakbyś budował miasto na obszarze którego może dziać się wiele niezależnych rzeczy w ramach praw i reguł które ustalisz. Jeżeli budujesz aplikację biznesową to tak jakbyś projektował i budował biurowiec lub całe centrum handlowe. 

To tylko przycisk…

Złożoność można wyobrazić sobie na przykładzie kranu – jako użytkownik kranu odkręcasz prawy kurek i  leci ciepła woda. Czy zastanawia Cię w tym momencie, że aby osiągnąć tak trywialny efekt jak woda w kranie setki osób musiały zbudować całą sieć wodociągów? Oczyszczalnie ścieków? Rury? Przyłącza? Bardzo podobnie jest w IT, czasem to co widzisz jako użytkownik na ekranie jako jeden przycisk, jeden popup, wymagało pracy zespołu przez kilka tygodni, miesięcy. Właśnie z tego względu pułapką w którą łatwo jest wpaść jest szacowanie czasochłonności zbudowania danego oprogramowania tylko na podstawie tego co widzimy na zewnątrz. 

  • Montaż kranu i zlewu? 2h? Jasne! T
  • Dodanie przycisku i wyskakującego okienka? Damy radę w 1h! 

Kluczowe i decydujące jest to co dzieje się pod spodem. Do montażu kranu potrzebujesz gotowe przyłącze. W przypadku wyskakującego okienka może się okazać się że wyciągnięcie z bazy danych informacji i przetworzenie ich przez systemu wymaga funkcji, które obecnie nie istnieją w systemie. Estymacja wzrasta do 2 tygodni.

Nie teraz, później

“If you are not embarrassed by the first version of your product you’ve launched too late.”

Oprócz pułapki złożoności w IT mamy jeszcze jedną zabawkę, która jest niespotykana w innych branżach. Zazwyczaj gdy zamontujesz wannę to nikomu nie przyjdzie do głowy, aby za 3 dni zamienić wannę na prysznic. W projektach IT to codzienność. 

Przykład prosto z życia – w aktualnym tygodniu tworzymy formularz rejestracji, który został zaprojektowany na podstawie najnowszych standardów UX, następnie marketing wpuszcza kilkaset osób, aby przetestować proces rejestracji i aktywacji konta. Analizując nagrania oraz heatmaps okazuje się że wyniki są o 50% niższe niż zakładaliśmy, ponieważ w tej grupie odbiorców podział rejestracji na dwa kroki jest procesem mylącym, przez co nieskutecznym. Ściągamy UI/UX Designera oraz Developerów, analizujemy wyniki i już w kolejnych dniach pracujemy nad nową wersją, która powinna poprawić wyniki. Finalnie wyniki się poprawiają i są lepsze od oczekiwanych. 

Takich możliwości nie mają architekci projektujący centra handlowe. Jeżeli okaże się że zaprojektowane wejście do budynku zniechęca klienta do wejścia to mają wielki i bardzo kosztowny problem. Nie są w stanie w kilka dni zbudować wersji 0.5 wejścia do centrum handlowego i zaprosić następnego dnia tysiąc osób do skorzystania z tego wejścia. W IT możemy to zrobić. Jest to niesamowita możliwość, dzięki której możemy podzielić tworzenie danego produktu na etapy – a dokładniej mówiąc wersje. 

W pierwszej wersji możemy stworzyć wejście do budynku za pomocą drewnianych schodów, a w piątej wersji dopiero pojawią się ruchome schody. Dzięki temu będziemy w stanie zaprosić naszych klientów do używania aplikacji po kilku tygodniach, a nie latach. Klienci poznają nasz produkt, my uczymy się tego jak się zachowują używając produktu i czego najbardziej potrzebują. Dzięki takiemu podejściu po przeprowadzeniu większej liczby iteracji powstaje produkt o wiele lepiej dopasowany do potrzeb klienta niż gdybyśmy chcieli na samym początku odgadnąć wszystkie możliwe zachowania użytkowników. W praktyce wyglądałoby to tak, że nasza konkurencja przez 12 miesięcy analizował aby możliwe scenariusze, a my rozpoczynając pracę od prostszej wersji po 12 miesiącach posiadamy klientów w systemie, oraz masę wiedzy na temat ich potrzeb i zachowań. Jest to jedna z największych zalet zwinnego podejścia prowadzenia projektów oraz modelu Time&Material.

Co dostarczam?

Jednak dlaczego wkurza mnie analogia pracy zespołu programistycznego do pracy kuriera? Jest to wielki skrót myślowy. Zespół IT oraz kurier mają za zadanie dostarczyć coś do odbiorcy. Jednak kurier otrzymuje paczkę i musi ją mimo przeciwności losu dostarczyć do klienta na czas. Zespół IT musi zrozumieć to czego potrzebuje klient, a właściwie użytkownik końcowy, następnie to zaprojektować, zbudować i dostarczyć. To tak jakby kurier otrzymał list przewozowy z napisem “Dostarcz smaczny jabłecznik na ul. Wiejską w Warszawie”, pomijam już to że pewnie żaden kurier nie chciałby realizować takiego zlecenia, to w tym przypadku przyjmijmy że szarlotka nie byłaby wcale dołączona do przesyłki. Czy powinienem sam upiec ciasto? Czy kupić w najbliższej piekarni? Czy posypać ciasto cynamonem? Czy może właściwie jest to ironiczny żart i powinienem dostarczyć zakalec?

Utopia?

Ani przykład kuriera, ani architekta, ani sprzedawcy samochodów nie jest w stanie w 100% odzwierciedlić procesu powstawania produktu cyfrowego, aplikacji. Dlatego bardzo często dla osób niedoświadczonych w projektach software zderzenie z takimi tematami jak wersjonowanie, iteracyjność, priorytetyzacja ficzerów, definiowania zakresu MVP jest czymś bardzo trudnym. Każdy chciałby zbudować idealny produkt, który sam przyciągnie klientów, sam się sprzeda i zwróci koszt z inwestycji w pierwszym miesiącu po uruchomieniu. Jednak żyjemy w świecie ograniczonym między innymi przez czas oraz pieniądze, dodatkowo presja działań konkurencji wymaga od nas sprawnego podejmowania decyzji, często ryzykownych. Dopiero lata doświadczenia oraz praca z odpowiednimi ludźmi może doprowadzić nas do wydajnej pracy, a co za tym idzie do osiągnięcia sukcesu.

Rozmawiaj

Te wszystkie aspekty powodują to, że pytając dostawcę oprogramowania o “koszt aplikacji jak uber tylko trochę innej” możesz zderzyć się ze skrajnymi wycenami. Dosyć trafna jest analogia do pytania “ile kosztuje samochód?”, “to zależy :)”. Profesjonalny zespół poznasz po tym, że będzie chciał wejść z Tobą w bliższy kontakt, będzie chciał porozmawiać, zrozumieć. Dopiero wspólna rozmowa pozwoli zdefiniować to czy jesteśmy w stanie znaleźć to co będziemy wspólnie przez najbliższy czas nazywać “Wersja 1.0” lub MVP (Minimum Viable Product). Jeżeli znajdziemy tutaj zrozumienie to o wiele łatwiej będzie nam przeprowadzić cały proces kreatywny powstawania produktu, łatwiej będzie nam zarządzać budżetem, priorytetami. To nie będą jednorazowe aktualizacje statusu projektowego raz na miesiąc. Tutaj każdego dnia nasze zespoły muszą wspólnie pracować nad tym, aby odnieść sukces. 

Zaangażuj się

Jeżeli oczekujesz że dzisiaj wyślesz zapytanie do dostawców, w ciągu tygodnia otrzymasz kilka ofert, umówisz się na spotkanie, opowiesz o swojej wizji, podpiszesz umowę i za 3 miesiące odbierzesz gotowy produkt – to muszę Cię rozczarować. Tworzenie produktu wymaga bliskiej komunikacji, współpracy wielu osób. W budowę nawet najmniejszej aplikacji zaangażowani są analitycy biznesowi, graficy, programiści, administratorzy, managerowie. Jednak wszystkie te osoby budują coś całkiem nowego, opartego na Twojej wizji. Jeżeli chcesz zbudować produkt który podbije serca klientów to Ty lub Twój zespół musicie  aktywnie uczestniczyć w całym procesie. W innym przypadku podzielisz los 90% startupów, które upadają. Najlepszą drogą będzie dokładniejsze poznanie 3-5 wybranych software houseów, które odpowiadają wielkością, branżą oraz kulturą pracy. Dzięki temu upewnisz się że pracujesz ze specjalistami w swojej dziedzinie oraz że współpraca będzie miłym i owocnym czasem.

Niewygodne pytania

Nie bój się gdy w trakcie rozmów będziemy zadawać ciężkie pytania, gdy będziemy pytać o wartość czy sens danego pomysłu. Te pytania pozwalają wydzielić najważniejsze elementy produktu. Mając wiedzę o tym dla kogo budujemy produkt, co jest w nim najbardziej istotne i jakie cele chcesz za pomocą tego oprogramowania osiągnąć, będziemy w stanie dać z siebie o wiele więcej niż w sytuacji gdy poprosisz nas o podanie wyceny na podstawie przesłanego briefu w pdfie.

Zbudujmy razem zespół

Na podstawie ponad 12 letniego doświadczenia wiem, że najlepsze produkty powstają wtedy gdy zespół klienta pracuje bardzo blisko z zespołem dostawcy oprogramowania. W praktyce często powstaje jeden lub dwa zespoły skupione na budowaniu, rozwoju produktu.

Podsumowując, najbardziej produktywna i dająca najlepsze rezultaty będzie ścisła współpraca i transparentna komunikacja pomiędzy klientem, a dostawcą oprogramowania. Mówiąc wprost – otwarta komunikacja oraz bezpośrednie, szybkie testowanie dają najlepsze rezultaty. Warto docenić zespoły, które zadają pytania, które chcą zrozumieć produkt. Takim zespołom zależy na tym, aby Twój produkt odniósł sukces.  Prawda jest taka, że tylko dzięki takiemu, jakościowemu podejściu wykonawca może liczyć na dalszą pracę nad produktem oraz Twoją rekomendację. Warto zadbać o wspólne win-win, ponieważ Twój sukces jest również naszym sukcesem!

Do you like this article? Share it with your friends:
Author:

Mikołaj Lehman

Write to me: m.lehman@gmihub.com

Recommended articles

Zbuduj swój produkt z GMI

Wyślij nam zapytanie i uzyskaj odpowiedź tego samego dnia!

Zatrudnij nas