Coraz częściej łapię się na tym, że zupełnie nieświadomie zaczynam planować studia podyplomowe. Co ciekawsze nie związane z informatyką.

Generalnie od pewnego już czasu obserwuję, że praca na stanowisku programisty wymaga poza znajomością zagadnień stricte informatycznych też bardzo dużej wiedzy ogólnej. Programista ograniczający się tylko do swojej działki związanej z klepaniem kodu i ślepo wierzący w dokumentację biznesową jest skazany w wielu przypadkach na porażkę… albo przynajmniej ciężki opierdol. Bezkrytyczne przyjmowanie tego co ktoś gdzieś opisał, ujął w listę o kilku poziomach i nazwał specyfikacją może prowadzić do wielu problemów.

Miałem ostatnio przykład tego typu zdarzenia. W sumie dwa zupełnie niezależne zdarzenia sprowokowały mnie do tego wpisu.

Zdarzenie pierwsze

W dużym skrócie klepię teraz soft do komunikacji z e-sądem. Na mnie spadł kawałek związany z generowaniem dokumentów w formacie e-sądu z dokumentów istniejących w systemie klienta. W sumie proste przepisywanie beanów wzbogacone w kilku miejscach o jakąś niezbyt wyszukaną logikę w stylu pobierania dokumentów z innych serwisów. Jednym z generowanych dokumentów jest wniosek egzekucyjny wysyłany do komornika. Wniosek generuje się na podstawie orzeczenia (wyrok/nakaz zapłaty), które wydaje sąd. Wszystko zgrabnie… do momentu aż trzeba na wniosku podać kwotę roszczenia. Dokumentacja mówi o ponownym wyliczeniu (stoi jak wół), a moja intuicja podpowiada, że kwota na wniosku nie może być inna niż ta w orzeczeniu. Sprawa wraca do analityka i dalej jako zapytanie do prawników klienta. W sumie wychodzi na moje.
Tyle tylko, że nie tylko intuicja jest ważna. Kilka lat wieczornych rozmów z Myszą i Murzynem, którzy są prawnikami, pozwoliło mi na wykrycie pewnej nieścisłości. Po prostu coś mi nie pasowało. Co więcej mając trochę doświadczenia z naszych rozmów potrafiłem zadać pytanie biznesowi tak, że ten zrozumiał o co chodzi…

Zdarzenie drugie

Z poprzedniego projektu wracają do mnie różne różności w postaci pytań klienta o jakieś szczegóły i duperele. Odpowiadam w 5 minut i po problemie. Ostatnio dostałem jednak ciekawego maila, pozwolę sobie na zacytowanie fragmentu

Mam świadomość, że część pytań miała charakter biznesowy, jednak z doświadczenia wiem […], że to IT ogniskuje w sobie więdzę techniczną z biznesową

Podsumowanie

Programista, który będzie ograniczał się tylko i wyłącznie do kodowania jako swojego kawałka pracy szybko popadnie w tarapaty. Z jednej strony będzie na niego spadała odpowiedzialność za wszystkie błędy techniczne, a z drugiej nie mając „świadomości biznesowej” (pomimo posługiwania się odpowiednim językiem domeny) nie wykryje błędów w specyfikacjach… i dostanie po głowie za wypuszczenie babola.
Czemu ma odpowiadać za błędy biznesowe? Ponieważ grupa posługująca się językiem domeny zakłada, że każdy z jej członków ma pewne minimalne pojęcie o samej domenie. Tyle tylko, że to niezbędne minimum wyznacza strona której językiem się posługujemy, czyli biznes.