Osoby pracujące w IT nie czują się dobrze w kontaktach z klientami. W tym momencie wielu podniesie larum, że to stereotyp, że oni są inni, że nowocześni pracownicy tej branży to osoby wszechstronne, dynamicznie rozwijające się, również w interakcjach międzyludzkich oraz że w ogóle żyję w średniowieczu i śmierdzę. Zanim zostanę ukamieniowany za swój humor i staroświeckie poglądy ("pewnie jeszcze myśli, że programiści siedzą ciągle sami w domu i nie mają przyjaciół!"), to pozwólcie, że doprecyzuję - rozmawianie z klientami jest trudne i nie mam tutaj na myśli tego, że są niemili. Przeciwnie - zazwyczaj są bardzo mili, ale z jakiegoś względu z nami współpracują i potrzebują naszych usług. A co za tym idzie - jesteśmy niezbędni nie tylko ze względu na nasze umiejętności techniczne, ale też orientację w technologii, doświadczenie i umiejętność analizy oprogramowania. To ostatnie właśnie jest tematem tego krótkiego tekstu.
Osoby, które mają już solidne doświadczenie w programowaniu i dodatkowo przejawiają smykałkę do umiejętności miękkich, stopniowo przechodzą do kierowania małymi zespołami, następnie większymi i na tym etapie często uczestniczą w korespondencji bądź spotkaniach z klientami jako konsultanci, posiadając duży wpływ na wyceny. Jest to ważne i powinniśmy się z tego cieszyć, gdyż o ile handlowcy czują się jak ryba w wodzie dyskutując o perspektywach biznesowych, o tyle przy konkretach technicznych mogą albo wydawać się zakłopotani, albo wykazywać się nadmiernym optymizmem i obiecywać złote góry. Dlatego konsultant IT z twardym, analitycznym spojrzeniem jest cennym wsparciem dla firmy w takich sytuacjach. W dodatku, jego obecność lub opinia pozytywnie wpływają na relację z klientem, demonstrując fakt, że traktujemy sprawę poważnie. Tak, wbrew pozorom klienci lubią rozmawiać z osobami od IT, gdyż wielu z nich lubi zobaczyć, jak sprawy mają się "od środka" danej branży.
Natomiast jak to wygląda z perspektywy samego konsultanta IT, który chce być pomocny, ale przy tym precyzyjny i realistyczny, wiedząc, że wkrótce przyjdzie jemu lub jego towarzyszom realizować ustalenia? Przede wszystkim, musi analizować nowe wymagania i proponowane zmiany ze wszystkich stron, co oznacza kilka rzeczy:
- możliwość realizacji w danym kontekście,
- sensowność (być może niepotrzebne jest wprowadzenie nowej funkcji do systemu, a jedynie odpowiednie wykorzystanie starej),
- rozpatrzenie przypadków szczególnych.
O ile pierwsze dwa punkty najczęściej stosunkowo łatwo wycenić kierownikom projektów (a przynajmniej wcelować się w odpowiedni rząd wielkości; pomijam tutaj fakt, że samo wyceniane jest trudne i niewdzięczne), o tyle ten ostatni punkt zwykle jest sporym zaskoczeniem dla klienta i decyduje o "bonusie" do oszacowania godzinowego. Użytkownikom nietechnicznym może się wydawać, że dane wymaganie jest proste, jednak osadzone w odpowiednim kontekście staje się fragmentami... wymagające. Wartość 99,9% z tytułu tego tekstu to nawiązanie do sytuacji, w których klient jest przeświadczony, że skoro przez większość czasu dana funkcja będzie używana w systemie w standardowy sposób, to można na tym poprzestać z analizą. Zwykle pada wówczas magiczne stwierdzenie "na razie zrobimy to prosto".
A tu konsultant IT się nie zgadza - on nie może patrzeć tylko na proste przypadki, które łatwo obsłużyć w systemie. Musi mieć na względzie to, że gdy wystąpi trudniejszy przypadek, to system nadal musi sobie z nim poradzić, aby dane były spójne. Gdy tego nie zrobi, a taka sytuacja wyniknie po dłuższym czasie od ustaleń, klient może (do czego ma prawo) zgłosić, iż oprogramowanie nie działa po jego myśli i dokonać zgłoszenia gwarancyjnego, które nieświadomi handlowcy często przyjmują bezkrytycznie. Dlatego osoba techniczna musi spokojnie rozważyć wszystkie scenariusze, które jest w stanie sobie wyobrazić i zadać pytania do tych, które nawet, jeśli wystąpią rzadko (chociażby raz na milion), to muszą zostać "strawione" przez system. Musi często także wytłumaczyć, dlaczego taki przypadek jest rozważany, a co gorsza - opisać go, podać przykład i liczyć na zrozumienie. Ma to dwie wyraźne ciemne strony, a więc konieczność poświęcenia mńostwa czasu na korespondencję, ale także niebezpieczeństwo, iż klient przestraszy się konsekwencji zmian i zrezygnuje ze zlecenia pracy. Tym niemniej, etyka zawodu programisty czy w ogóle osoby z IT wymaga, aby nie ukrywał takich rzeczy. Choćby dla bezpieczeństwa własnego, swoich koleżanek i kolegów oraz całej firmy.
Mógłbym tutaj napisać jeszcze więcej, ale obiecałem, że tekst będzie krótki (a dla mnie nie istnieje coś takiego jak "zbyt długi tekst"), więc zakończę go w tym miejscu. Jeśli będzie jakikolwiek odzew i chęć pociągnięcia tematu, to chętnie wrócę do niego. To, co chciałem przekazać tym wpisem, to dwa fakty:
- Najbardziej szczególne scenariusze wykorzystania danej funkcji, nawet, jeśli są rzadkie, muszą być uwzględnione podczas projektowania i implementacji systemu.
- To one często decydują o niespodzianych "dodatkach" w wycenie.
Klientom mogę doradzić cierpliwość do trudnych tłumaczeń konsultantów IT i próbę spojrzenia na "rewelacje" tak, że im więcej scenariuszy zostanie uwzględnionych wcześniej, tym łatwiejszy będzie późniejszy rozwój i mniej nieporozumień w przyszłości. Zespół IT naprawdę nie chce dla Was źle - im też zależy na rozwoju systemu. Jeśli widzicie, że starają się wyjaśniać i nie ograniczają się jedynie do skrótowych odpowiedzi, to możecie się tylko cieszyć, bo widocznie dobrze im się z Wami koresponduje.
Pozdrawiam - Jakub Rojek