Dziś szybkie studium przypadku. Mamy przyjemność (i w przypadku tego projektu nie jest to pusty slogan) pracować z Klientem, który potrzebuje intranetu obsługującego biuro księgowe. Potrzebuje też na ten system budżetu, dlatego stara się o dofinansowanie. Aby je otrzymać, musiał przedstawić oficjalne, opieczętowane pieczęciami, poświadczone Powagą Urzędu zaświadczenie że system działa i robi to, co do niego należy. Zaświadczenie wystawiało Grono Akademickie jednej z politechnik. I co wprawiło szacowne Grono w największe zdumienie? To, że informatycy z księgowymi dogadali się i stworzyli coś, co spełnia swoją rolę.
Ta ciekawa informacja skłoniła mnie do refleksji nad tym, co takiego specjalnego jest w naszym “dogadywaniu się”. A czego, jak można wnioskować z reakcji szacownego Grona, często przy tworzeniu oprogramowania brakuje. Wnioski w skrócie można przedstawić za pomocą jednej z głównych zasad SCRUM-u : “it’s all about common sense”.
Zaangażowanie. Potrzebne jest z obu stron- do tego, aby każda z nich mogła dostarczyć drugiej informacje, o jakie prosi. Czy będą to dokładne wzory na obliczanie podatków, czy informacja co można, a czego nie można zrobić, czy cokolwiek innego. Sprawa niby oczywista, ale w przypadku projektu, który trwa miesiącami łatwa do pominięcia, zwłaszcza ze strony Klienta, który ma przecież swoje zajęcia i nie zawsze musi przejmować się programem który “się pisze”.
Zrozumienie dla niezrozumienia. Niektórych informacji trzeba udzielać wielokrotnie, tłumaczyć, wyłuszczać i wyjaśniać. Informacji, które leżą u podstaw zawodu jednej ze stron projektu, ale drugiej – niekoniecznie. Choćby wydawały się nie wiem jak proste – na przykładzie projektu dla biura księgowego widać to idealnie. Dla przykładu: członkowie naszego zespołu potrzebowali niekiedy dokładnego rozpisania i wielokrotnego wyjaśniania obliczeń podatkowych, które Klient początkowo opisywał jednym krótkim zdaniem. Z drugiej strony, niejeden raz musieliśmy wyjaśniać że aplikacja obsługiwana przez przeglądarkę to nie to samo co aplikacja desktopowa.
Przyjęcie niezrozumiałych potrzeb. Tak jak Klient nie musi rozumieć, dlaczego właściwie niektórych druków nie można drukować bezpośrednio z przeglądarkowego “drukuj”, tylko muszą przejść przez PDFa, skoro “ten inny druk można tak wydrukować”, tak samo projektant UI nie musi rozumieć dlaczego dwa pola formularza muszą być koniecznie obok siebie, a nie jedno pod drugim. Od strony zespołu tworzącego system oczywiście “wszystko jest kwestią czasu i pieniędzy”, ale działając w określonych realiach – trzeba niektóre rzeczy trzeba po prostu przyjąć. Bo “tak musi być”.
Unikanie hermetycznego języka. W zasadzie jest to pochodna “zrozumienia dla niezrozumienia”, ale zdaniem naszego Klienta, jest to tak ważne, że musi być wymienione oddzielnie 
Księgowy naprawdę nie musi wiedzieć, ani do sprawnego przeprowadzenia projektu nie jest potrzebne by się nauczył, czym różni się HTTP od WWW. A członkowie zespołu tworzącego soft do końca prac nie muszą wiedzieć czym są “konta grupy 7″.
Dodatkowo, przy tworzeniu tak rozbudowanego systemu, wydaje się że najbardziej naturalnym sposobem prowadzenia projektu jest zastosowanie zasad SCRUM – obu stronom najłatwiej zaakceptować prace prowadzone właśnie w tym modelu.
I to wszytko. Bo do tego, żeby udał się jakikolwiek projekt, potrzeba przede wszystkim zdrowego rozsądku.
