List do klienta, prawda o projektach IT – „Xanpan”, Allan Kelly

Xanpan

List pochodzi z książki "Xanpan" Allana Kelly i przedstawia potencjalnemu klientowi całą prawdę o projektach IT. Autorem tłumaczenia jest zwinnołódzki Tomasz Szer.

 

Drogi kliencie: prawda o projektach IT

Drogi kliencie,

Myślę, że nadszedł czas byśmy my z branży IT przyznali się jak pobieramy od ciebie wynagrodzenie, czemu nasze faktury są czasami trochę wyższe niż mógłbyś oczekiwać i czemu tak wiele projektów IT kończy się rozczarowującymi rezultatami.

Prawda jest taka, że gdy startujemy projekt IT nie wiemy ile czasu i wysiłku będzie potrzebne aby go skończyć. W konsekwencji nie wiemy ile to będzie kosztować. To nie jest wiadomość, którą chciałbyś usłyszeć, szczególnie gdy jesteś absolutnie pewien, że wiesz czego chcesz.

Tutaj zawarta jest inna prawda, którą spróbuję przedstawić tak łagodnie jak tylko potrafię. Jesteś, w końcu, klientem i naprawdę nie powinienem cię urazić. Znasz powiedzenie „Klient ma zawsze rację”? Rzecz w tym, że nie wiesz czego chcesz. Możesz wiedzieć w ogólnym zakresie, ale diabeł tkwi w szczegółach – i im więcej szczegółów chcesz nam dostarczyć na początku, tym bardziej prawdopodobne jest, że twoje oczekiwania się zmienią. Za każdym razem gdy dajesz nam więcej szczegółów, oferujesz nam więcej zakładników przypadku.

Ekspert oprogramowania Caspers Jones wierzy, że rzeczy które chcesz (‘wymagania’, jak chcemy je nazywać) zmieniają się średnio 2% miesięcznie – zbliżając się do 27% w przeciągu roku zliczając razem je wszystkie. Osobiście jestem zdumiony, że ta liczba jest tak niska. A wszystko komplikuje fakt, że świat jest niepewny. Rzeczy się zmieniają a firmy wypadają z biznesu. Pamiętasz Enron? Pamiętasz Lehman Brothers? Klient lubi zmiany. Pamiętasz Cabbage Patch Kids? Moda się zmienia, rządy się zmieniają i konkurenci robią wszystko co w ich mocy aby utrudnić życie. Więc jeśli nawet naprawdę wiesz absolutnie czego chcesz, gdy rozmawiamy po raz pierwszy, jest niemożliwe, aby tak było bardzo długo.

Obawiam się powiedzieć, że są ludzie w branży IT, którzy wykorzystują taką sytuację. Będą się uśmiechać i zgadzać się z tobą gdy będziesz im mówił co chcesz do momentu gdy podpiszesz. Od tego momentu, to będzie inna bajka; oni wiedzą że zmiany są nieuniknione i planują zarobić niezłą prowizję ze zmian (Change Requests) i późnych ‘wrzutek’, oczywiście na twój koszt.

Jeśli mam być szczery, to prawda że czasami ‘pozłacamy’ różne rzeczy. Być może nie potrzeba ci hurtowni danych dla twojego sklepu online zaraz pierwszego dnia od startu. Tak, część naszych inżynierów lubi robić więcej niż potrzeba, i tak, mamy żywotny interes w tym, aby dodawać różne rzeczy, po to aby móc pobrać od ciebie większą opłatę.

Jest także prawdą, że całkiem uzasadnione jest myślenie o cechach i funkcjonalności jakie chciałbyś mieć zaraz po tym, jak my już zaczęliśmy. Zupełnie naturalnie zakładasz, że coś jest ‘wejściem’ (‘in’) gdy my zakładamy, że to jest ‘wyjściem’ (‘out’). I w duchu otwartości, czy możesz uczciwie powiedzieć, że nigdy nie próbowałeś wrzucić nam czegoś dodatkowego? (Nie mówmy nawet teraz o błędach: bo to jeszcze bardziej wszystko komplikuje.) Szczerze, biorąc to wszystko pod uwagę, jest poruszające, że masz tak dużo wiary w dostarczaną przez nas technologię. Ale jeśli IT coś dostarcza, to dostarcza naprawdę dużo.

Zobacz co zrobiono dla Billa Gatesa i Larrego Page’a lub Amazona i FedEx’a. Czy nie jest zastanawiające, że jeśli branża IT tworzy coś dla siebie, to kończy się to często nowymi multimilionerami? Gdy robimy coś dla innych, oni kończą tracąc pieniądze. Jak zatem kiedykolwiek moglibyśmy cię do czegoś takiego namówić? Cóż, pakujemy ten nieestetyczny bałagan i próbujemy ci to jakoś sprzedać. Aby to zrobić musimy ukryć wszystkie te nieprzyjemności.

Startujemy z rytuałem zwanym ‘estymacje’ – ile czasu, jak nam się wydaje, może zająć praca. Te ‘estymacje’ są trochę lepsze niż zgadywanie. Ludzie nie potrafią szacować czasu. Wiemy to od końca lat 70-tych, gdy Kahneman i Tversky opisali w 1979 ‘złudzenie planowania’ (‘planning fallacy’), co doprowadziło do uzyskania przez nich Nagrody Nobla. Po prostu, ludzie stale zbyt nisko oceniają ile czasu zajmie im praca i nadmiernie ufają swoim oszacowaniom.

Co gorsza, mamy zły nawyk, którego naprawdę powinniśmy się pozbyć. Między oszacowaniem pracy i wykonywaniem pracy zwykle zmieniamy zespół. Estymacja może być zrobiona przez dział IT będący odpowiednikiem Manchesteru United czy New York Yankees a zespół, który wykonuje pracę jest bardziej jak zbieranina koderów, analityków i menadżerów, którzy nigdy się wcześniej nie spotkali.

Historyczne dane – dane o estymacjach, stanach aktualnych, kosztach itd. – mogą pomóc objaśniać planowanie, ale większość firm nie posiada własnych danych. Dla tych, którzy posiadają dane, większość z nich jest bezużyteczna. Faktycznie, Capers Jones sugeruje, że nieodpowiednie dane historyczne są główną przyczyną porażek projektów. Na przykład, inżynierom oprogramowania rzadko płaci się nadgodziny, więc systemom śledzenia czasu (tracking systems) często brakuje tych extra godzin. Faktycznie, niektóre firmy zabraniają pracownikom logowania więcej niż ich oficjalne godziny pracy jakie są w systemie.

Więc robimy zgadywanki (przepraszam, ‘estymujemy’) i podwajamy je – a nawet możemy je potrajać. Jeżeli nowe wartości wyglądają na zbyt duże, możemy je zmniejszyć. Jak tylko nasi inżynierowie zakończą dopasowywać te wartości są one przekazywane do ludzi od sprzedaży, którzy podrasowują je jeszcze trochę. Po wszystkim chcemy abyś powiedział „tak” dla największej ceny jaką chcielibyśmy dostać. To być może brzmi podle, ale pamiętaj: będziemy zawsze umieszczać te najwyższe wartości w pierwszej kolejności.

Proszę nie strzelaj do mnie: jestem tylko posłańcem. Nie wiemy, która wartość jest ‘poprawna’ ale, aby była ona możliwa do zaakceptowania dla ciebie udajemy, że jest pewna i bierzemy na siebie pełne ryzyko. Robimy to tylko wtedy, gdy wartość ta jest wystarczająco bezpieczna (i nawet wtedy się mylimy). Jeżeli ryzyko się opłaca otrzymujemy pokaźne zyski. Jeśli nie, to nie otrzymujemy żadnych profitów a nawet możemy zaliczyć stratę. Jeżeli jest naprawdę źle, ty nic nie dostajesz i kończy się sądem lub totalną klapą.

Alternatywa jest taka, że ty ponosisz całe ryzyko – i bałagan – i dalej robisz wszystko sam. Niestety inną smutną prawdą jest ta, że wewnętrzny dział IT jest zwykle nawet gorszy niż ten dostarczany przez specjalistów. Dla firmy tworzącej oprogramowanie pisanie programów jest główną kompetencją – taka firma żyje lub umiera dzięki swojej zdolności do dostarczania oprogramowania i jeśli jest zła to wypada z interesu. Ewolucja odsiewa słabo dostosowanych. Korporacyjne działy IT, z drugiej strony, rzadko niszczą biznes – chociaż mogą zniszczyć zyski. Faktycznie, badania Capersa Jones’a także sugerują, że dostawcy specjalistów są zazwyczaj lepsi niż korporacyjne działy IT. Goście od sprzedaży mogą być nieobecni a i tak cały proces estymacji jest otwarty na zagrywki z wielu innych stron i wielu innych powodów.

Podsumowując: jeśli zdecydujesz się wziąć na siebie ryzyko, to możesz istotnie zwiększyć jego poziom. Wiem, że może to brzmieć jak sytuacja typu przegrany-przegrany (no-win, loose-loose). Możesz po prostu usiąść i czekać aż Microsoft lub Google rozwiąże twoje problemy rozwiązaniem z paczki ale czy twoi konkurenci będą stali w miejscu tak jak ty? Czy nadal będziesz prowadził biznes gdy Google wprowadzi darmową wersję?

Strzeż się szarlatanów sprzedających aplikacje z paczki. Gdy ludzie zaczynają rozmawiać o ‘personalizacji’ lub ‘konfiguracji’, wtedy lecisz głową w dół po śliskim zboczu. Konfiguracja ogromnej instalacji SAP nie jest tylko kwestią wyboru z menu Narzędzia, Opcje i zaznaczenia pól. Konfigurowanie wielkich pakietów jest główną działalnością w tworzeniu oprogramowania i nie ważne co ci powiedziano. Ludzie, którzy zajmują się konfigurowaniem mogą być ‘konsultantami’ ale tak naprawdę są specjalistami od tworzenia oprogramowania, programistami inaczej ich nazywając.

Tak naprawdę nie ma na to ładnego i prostego rozwiązania. Nie możemy rozwiązać tego problemu za ciebie. Potrzebujemy cię ale ty musisz pracować z nami. Jako klient, musisz być przygotowany na pracę z nami, dostawcami, ciągle i na okrągło w celu zmniejszenia ryzyka. Zapobieganie ryzyku w odpowiednim momencie i w efektywny kosztowo sposób wymaga decyzji na poziomie biznesowym i kompromisów Jeśli nie jesteś tu by nam pomagać możemy albo podejmować decyzje za ciebie (wliczając ryzyko, na które się nie godzisz) albo marnować twój czas i pieniądze żeby się tym zająć. Musisz być przygotowany by zaakceptować i dzielić z nami ryzyko. Jeśli nie jesteś gotowy na podjęcie żadnego ryzyka, to my bardzo dużo policzymy sobie za każde ryzyko, które weźmiemy na siebie. Dzielenie ryzyka daje w efekcie zmniejszenie ryzyka, ponieważ gdy ryzyko jest dzielone to ty, klient, jesteś zmotywowany do jego redukcji. Jednym z ogromnych ryzyk w projektach IT jest brak zaangażowania klienta. Możesz w tym pomóc po prostu będąc zaangażowanym.

Ostatecznie wszystkie ryzyka są twoimi ryzykami: ty jesteś klientem, ty płacisz za projekt w ten czy inny sposób. Jeśli zawiedzie dostarczenie wartości, to twój biznes na tym ucierpi. Gdy dzielisz ryzyko, gdy jesteś mocno zaangażowany, ryzyko może być zmniejszone natychmiast zamiast pozwolić mu powstać i narastać.

Wreszcie, możesz mieć ogromne ambicje, lecz my potrzebujemy pracować małymi kawałkami. Wiem, że nie brzmi to bardzo sexy ale pisanie oprogramowania najlepiej działa jak się je wykonuje pomału. Ekonomia skali nie istnieje. W rzeczywistości mamy dysekonomię skali, więc potrzebujemy pracować w maleńkich kawałkach ciągle, ciągle i ciagle. Jeśli jesteś gotów by zaakceptować te sugestie, to naciśnijmy ‘reset’ w naszych relacjach i rozmawiajmy trochę więcej.

Z poważaniem,
Branża IT

Źródło: "Xanpan" Allan Kelly
Tłumaczenie: Tomasz Szer

xanpan

Dyskusje:

Pierwszy komentarz?