Krótka pamięć i inne problemy komunikacyjne w branży IT

W pracy programisty często zdarza się, że klient zgłasza błąd, bo coś działa nie tak, jak powinno. Po sprawdzeniu okazuje się jednak, że program działa dokładnie tak, jak wcześniej ustalono, że ma działać. Czasem wynika to z tego, że po kilku miesiącach ludzie zapominają o tym, co sami chcieli, a czasem osób zainteresowanych danym programem jest kilka, i mają inne wizje, czasem sprzeczne ze sobą. Jedna osoba prosi o dodanie funkcjonalności, po czym inna prosi o jej usunięcie, gdyż uważa to za buga.

Dla mnie wiedza, czy coś jest faktycznie błędem, przekłada się na pieniądze: w Green Code Studio błędy popełnione z mojej winy naprawiam bezpłatnie, ale zmiana spowodowana tym, że to klient zmienił zdanie już bezpłatna nie jest.

Trudniejsza sytuacja jest wtedy, gdy to programiści znajdują w programie coś, co wygląda jak błąd, ale nikt (ani po stronie zespołu programistów, ani po stronie klienta) nie wie na pewno, czy to bug czy feature. Nie da się zrobić programu, który działa poprawnie, jeśli nikt nie wie, co to znaczy poprawnie. Do tego nim więcej elementów, które strach ruszyć, tym programowanie staje się trudniejsze (a więc i droższe)

Znajomy pracował kiedyś nad programem do wykonywania obliczeń dla kopalni. Dostał on program napisany 3 dekady wcześniej w fortranie dla systemu MS-Dos i miał za zadanie przepisać go w nowocześniejszej technologii. Udało mu się w oryginalnym programie znaleźć błędy, przez które wyniki były błędne, czego nikt nie zauważył przez lata.

Jak się przed tym bronić?

Dużą pomocą w rozwiązywaniu tego typu sytuacji są wszelkie notatki i zapiski z komunikacją z klientem, np. maile. Jeśli rozmawiasz osobiście czy przez telefon dobrze zapisywać notatki. Niekoniecznie muszą być ładnie posortowane, ważne, żeby było jakieś słowo kluczowe, po którym wyszukiwarka je znajdzie.

Ja do zapisywania notatek i tego, co mam do zrobienia używam Asany. W bardziej skomplikowanych projektach daję dostęp do Asany klientowi: wtedy zamiast rozmawiać w mailach, które są odpowiedzią odpowiedzi do odpowiedzi odpowiedzi mamy od razu podział na poszczególne zadania. Poza Asaną testowałem też issue tracker w JetBrains Space, i choć uwielbiam JetBrainsów, to to narzędzie wyszło im dosyć ubogo. Pracowałem też na Jirze, ale wydaje mi się oprogramowaniem przeznaczonym raczej dla korpo.

Pomocą jest też posiadanie gita, gdyż można sprawdzić kiedy dana zmiana w kodzie została wprowadzona. Używanie gita wydaje się być czymś oczywistym, ale tylko pozornie.

Od ponad roku pracuję nad projektem, który wcześniej tworzyła inna firma. Klient był niezadowolony, więc zgodnie z umową poprosił o podesłanie kodu źródłowego i przekazał projekt mi. Ale w umowie nie było historii gita, więc tamta firma jej nie przesłała.

Coś, co chciałbym spróbować w przyszłości, to zapisywanie wszystkich ustaleń co program ma robić w jednym miejscu, dostępnym również dla klienta, i wprowadzanie każdej nowej funkcjonalności najpierw w tym dokumencie. Nie wiem jednak, czy sprawdzi się to w praktyce. Próbowałem to tylko na małej skali, w pojedynczych funkcjonalnościach, co do których nie byłem w stanie dość do porozumienia z klientem jak mają działać.