Spis treści
Często spotykam się z sytuacją, w której klient z uśmiechem zgłasza prośbę: „A może byśmy zmienili to i owo w systemie? To przecież niewielka poprawka, prawda?”. Na pierwszy rzut oka wygląda to zupełnie nieszkodliwie. Zmiana pola w formularzu, przesunięcie przycisku, przerzucenie całej sekcji w inne miejsce interfejsu – wydaje się, że wystarczy jeden ruch, tak jak w kultowej scenie z filmu Barei, w której dyrektor beztrosko przesuwa jezioro, mówiąc: „Jezioro damy tutaj, a ten niech sobie stoi w zieleni”. Jednak w rzeczywistości za taką decyzją często kryje się mnóstwo dodatkowych kroków, niewidocznych na pierwszy rzut oka, a kluczowych dla stabilności i działania całego systemu.
Poszukiwany poszukiwana, reż. Stanisław Bareja (1972)
Przykład z przesuniętym silnikiem
Wyobraźmy sobie samochód, w którym ktoś wpadł na pomysł, żeby zamontować silnik z tyłu zamiast z przodu. To brzmi fascynująco, a przy okazji może wydawać się proste. Ktoś patrzy na auto i stwierdza: „Wystarczy wyjąć silnik, przełożyć go do bagażnika i podpiąć, jak wcześniej”. Jednak rzeczywistość szybko weryfikuje takie plany. Nagle okazuje się, że trzeba przekonstruować układ chłodzenia, zmienić rozmieszczenie zbiornika paliwa, dostosować podwozie, wzmocnić ramę, wymyślić nowe łączenia przewodów, a przy okazji przebudować cały tył, żeby nie zaczął się przegrzewać w pierwszej lepszej sytuacji. Z drobnej modyfikacji robi się poważny projekt, który angażuje więcej rąk do pracy i potrafi pochłonąć znacznie większe środki, niż pierwotnie zakładaliśmy.
Ukryte koszty i zależności w systemie
Z pozoru niewinne przesunięcie jednego przycisku w oprogramowaniu może wpłynąć na inne mechanizmy, o których istnieniu wcale nie myślimy w danym momencie. Kod to nie jest pojedynczy silos, który wystarczy lekko przemieścić. Tworzy on sieć wzajemnych zależności. Czasami dana funkcja jest w kilkunastu miejscach w systemie i każda z tych części może reagować inaczej na naszą zmianę. Bywa, że efekty tej modyfikacji ujawnią się dopiero w momencie, kiedy oprogramowanie wchodzi w interakcję z innymi modułami lub aplikacjami zewnętrznymi. Każdy doświadczony programista wie, że pozornie nieszkodliwe poprawki potrafią wygenerować wiele dodatkowych godzin pracy, bo wymagają testów, korekty dokumentacji i aktualizacji środowisk testowych oraz produkcyjnych.
Historia z praktyki
Niedawno pracowaliśmy nad systemem SaaS, który oferował rozliczanie usług w modelu subskrypcyjnym. W skład tego rozwiązania wchodził panel zarządzania, wewnętrzne API, aplikacja mobilna, aplikacja WWW oraz strona informacyjna. Klient poprosił o zmianę sposobu naliczania opłat, argumentując, że chce „drobnej” korekty, aby lepiej dostosować cennik do potrzeb swoich użytkowników. Początkowo wyglądało to na kilka godzin pracy, ale życie szybko zweryfikowało te założenia. Wprowadzenie nowego algorytmu pobierania opłat pociągnęło za sobą potrzebę przebudowania tabel w bazie danych, modyfikacji logiki w aplikacji mobilnej, dostosowania warstw API i wdrożenia zmian na stronie WWW. Okazało się też, że trzeba przeprojektować część panelu zarządzania, by umożliwić administratorom wprowadzanie nowych stawek oraz zapewnić pełną zgodność z istniejącymi danymi o subskrypcjach. Drobną zmianę należało więc rozbić na kilka etapów, żeby zagwarantować stabilność całego systemu i nie przerywać dostępu do usług setkom aktywnych użytkowników. W ten sposób pierwotne kilka godzin pracy zamieniło się w blisko dwutygodniowy projekt dla kilku osób.
Zrozumieć pełen obraz
Nikt nie neguje korzyści płynących z modyfikacji systemów – wręcz przeciwnie, rozwój oprogramowania i wychodzenie naprzeciw potrzebom użytkowników to dla wielu biznesów klucz do sukcesu. Ale aby uniknąć zbędnych frustracji i nieporozumień, warto pamiętać, że za prostym pomysłem często stoi rozbudowana architektura. Przemyślana zmiana powinna uwzględniać wszystkie elementy, które mogą być tą modyfikacją dotknięte. W razie wątpliwości najlepiej skonsultować ją na wczesnym etapie z osobami odpowiedzialnymi za projekt, dzięki czemu można ocenić rzeczywisty nakład pracy i ryzyko.
Przyszłość projektów i odpowiedzialne decyzje
Zarządzając software housem, zawsze staram się uczulać moich klientów, że czasem lepiej poświęcić chwilę na rozmowę, wyjaśnienie oczekiwań i wspólne przeanalizowanie potencjalnych konsekwencji, włącznie z wymaganiami budżetowymi. Warto postawić na przejrzyste procesy i dbać o klarowną komunikację, żeby wszyscy wiedzieli, co oznacza taka, a nie inna modyfikacja w systemie. Dzięki temu wszelkie zmiany, nawet te, które z pozoru wyglądają na proste przeniesienie jeziora z jednego końca mapy na drugi, zostaną przeprowadzone z należytym przygotowaniem i odpowiednią dawką rozsądku.
