Leksykon słów niewybaczalnych

harry-potter-388256_1280

Fani Harry’ego Pottera z pewnością pamiętają klątwy niewybaczalne, których użycie powodować miało ciężkie kary. Sposób w jaki opisywane są aplikacje dedykowane na potrzeby wycen, wiele ciężkich kar potrafi zagwarantować. Zwłaszcza przekroczenie terminów i budżetów. W porywach nawet do wieloletnich procesów sądowych. Skojarzenie z Harrym Potterem ma też drugie, nie tak oczywiste źródło.

Kilka już lat temu odebrałem telefon od potencjalnego klienta, który swój pomysł na aplikację, z przeświadczeniem, że do wyceny to wystarczy, opisał w następujący sposób:

-„Wie Pan, ja jestem trochę takim szalonym naukowcem i mam różne pomysły, oglądał Pan Harry’ego Pottera? Tak? No, to tam są takie Huncwoty, i właśnie takie Huncwoty chcę zrobić”.

Odnosiło się to oczywiście do słynnej mapy pokazującej gdzie kto się na bieżąco znajduje w Hogwarcie, a oczekiwaną była wycena aplikacji prezentującej na mapach, np. Google, gdzie są inni użytkownicy. Ten jeden akapit miał spokojnie wystarczyć, żeby podać przybliżoną kwotę, poziom przybliżenia został też określony: „wie Pan, tak plus minus 15%”.

Interfejs ma być przyjazny i intuicyjny, użytkownik ma się szybko i bezpiecznie logować do aplikacji, wyszukiwanie ma być proste, a integrujemy się oczywiście z Googlem i operatorami płatności. I sęk w tym, że to może znaczyć bardzo wiele, bo co dokładnie właściwie znaczy np.: łatwe wprowadzanie informacji o kliencie, albo przejrzysty sposób prezentacji informacji o produkcie? Dla każdego znaczy to coś innego, są to zwroty ogólne, oparte raczej na estetyce niż na twardych parametrach.

Czy wyobrażamy sobie definiowanie prac przy budowie domu poprzez dwa-trzy akapity opisujące elewację (nowoczesna, z drzwiami w intuicyjnym miejscu), wysokość (odpowiednia, tak na jedno piętro) i dach (spadzisty), acha no i pokoje powinny być, tak z 4-5 rozłożone ergonomicznie po domu, to ile taki dom będzie kosztować? Raczej nie. Bo sami instynktownie czujemy śmieszność takiego formułowania. W realnym świecie nie spytalibyśmy tak o cenę budowy domu i ofertę na nią, musiałby być projekt, opis konstrukcji, określone materiały, instalacje, dokładne wymiary etc. Wszyscy to wiemy – czemu nie wiemy tego jeśli chodzi o oprogramowanie? Jest jakaś naiwna wiara w standardy i dobre praktyki, tak jakby to oprogramowanie ludzkość budowała od tysiącleci, a nie domy i wszystko już było jasne (i przejrzyste i intuicyjne).

Niechęć do poświęcania czasu na analizę, tworzenie dokładnego projektu (co w rozumieniu wielu opóźnia realizację projektu) mści się straszliwie i zawsze. Po pierwsze otrzymywane wyceny są bardzo rozstrzelone, skoro zapytanie nie definiuje takich danych jak chociażby technologia, mechanizmy jakościowe przy tworzeniu oprogramowania (np. code review, jakość dokumentacji), czy szczegółów widoków i dokładnej logiki to oferenci potraktują je po swojemu, jedni stosując jakieś wypracowane dobre praktyki inni na zasadzie spełnia/nie spełnia. Fundujemy sobie w tej sytuacji decyzję o wyborze partnera biznesowego (często na lata) w bardzo utrudnionych warunkach, bo nie wiemy często między czym dokładnie wybieramy. Te wszystkie nieokreślone szczegóły, jeśli nie zostaną dookreślone przed realizacją, to niestety będą dookreślane w trakcie, najczęściej wtedy gdy już zostaną częściowo, lub w całości wykonane i wtedy pojawia się dopiero magiczne „Panie, ale to nie tak powinno być, to nie jest…” [tu wstaw dowolne słowo klasy „intuicyjne”]. Pojawia się zatem oczekiwanie zmiany, zmiana wiąże się z czasem pracy, czas pracy jest główną składową kosztu wykonawcy i zaczyna się dyskusja, nie zawsze prowadząca niestety do kontynuacji doskonałych relacji. Zanim zatem „intuicyjnie” wybierzemy przekroczone terminy, budżety i ciężkie dyskusje z dostawcami, warto zastanowić się nad wybraniem innej drogi – pozornie dłuższej i bardziej uciążliwej – ścieżki precyzyjnego definiowania wymagań.

 

 

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn