Wymaganie niefunkcjonalne należą do moich ulubionych typów wymagań. Mówię to oczywiście z delikatnym przymrużeniem oka. Wiadomo, że wszyscy skupiamy się na dostarczeniu tej „klikalnej” i użytecznej części rozwiązania. Kiedyś jednak musi nadejść chwila realizacji zadań „mniej biznesowych”, a czasem wręcz mocno technicznych. Kiedy jest ten czas? Jak źle zarządzać wymaganiami niefunkcjonalnymi?
Technical Debt
Dług technologiczny, czyli świadome odłożenie realizacji części wymagań bardzo często powiązany jest właśnie z wymaganiami niefunkcjonalnymi. Nikt nie chce przecież odkładać w czasie wymagań funkcjonalnych. Jak pewnie się domyślacie, takie odkładanie, jak to w życiu, ma swoje konsekwencje. Nie bez powodu twierdzi się, że każdy typ wymagań (i innych Elementów Backlogu Produktu) powinien być traktowany w taki sam sposób. Włączamy w to też i błędy, i wymagania niefunkcjonalne.
Jeśli wiemy już, że najczęściej odkładanym typem wymagań są (pieszczotliwie nazywane) NFR-y, to zastanówmy się, jaki może to mieć wpływ na Produkt, nad którym pracujemy. A jak już pytamy o Produkt to większość z Was wie, że nie robimy tego bez powodu. Bo o wytwarzanie Produktu przecież nam chodzi.
Pozytywy i negatywy
Wpływ odkładania na później wymagań niefunkcjonalnych może mieć zarówno pozytywne, jak i negatywne oblicze. To pozytywne związane jest z faktem, że skupiamy się na dostarczeniu tego, czego najbardziej potrzebuje i z czego będzie korzystał nasz Klient. Nie wiadomo jeszcze czy owe korzystanie będzie bezpieczne, ergonomiczne, przyjazne, wydajne, itd. To właśnie skutek świadomego odłożenia tej decyzji na później. Wydaje nam się, że na teraz będzie dobrze, a jak będzie naprawdę – zobaczymy.
Do tego momentu wszystko wygląda dobrze. Kraina mlekiem i NFR-ami płynąca. Źle zaczyna być w momencie, w którym na skutek braków w budżecie, czasie, wiedzy czy kompetencjach ta świadoma decyzja idzie w zapomnienie, a wymagania niefunkcjonalne wędrują do lamusa. To przepis na gwarantowane problemy, których skutki zauważymy dopiero po jakimś czasie.
Zaczyna się od tego, że wykonanie akcji na zadaniu trwa tak długo, że spokojnie możecie zrobić sobie kawę i obejrzeć skrót najciekawszego spotkania ostatniej kolejki piłki nożnej. Myślicie sobie „to chwilowe, pewnie Internet przyciął”. Kończy się na tym, że nasza firma trafia do prasy na skutek wycieku informacji o wykradzionych danych wrażliwych Klientów. Umówmy się, nie o taki PR nam chodzi! Gdzieś popełniliśmy błąd!
Zróbmy je na sam koniec
Mamy budżet, czas, kompetencje, kiedy więc zająć się wymaganiami określanymi jako NFR? Część organizacji twierdzi, że na końcu. „Teraz skupmy się teraz nad dowiezieniem funkcjonalności, a na pozostałe rzeczy jeszcze przyjdzie czas”. Czy zastanawialiście się kiedyś nad skutkiem takich decyzji?
Odkładanie wymagań niefunkcjonalnych na koniec prac nad Produktem jest przede wszystkim nieefektywne. Bierze się.to stąd, że musimy wówczas analizować i dokonywać zmian w całym „prawie gotowym” rozwiązaniu, co nie jest już tak proste, jak dbanie o spełnianie wymagań niefunkcjonalnych na bieżąco.
Podobnie rzecz ma się z atencją na ich wykonanie. Często zasadniczą fazę rozwoju Produktu mamy już za sobą, zostaje nam więc konieczność dostarczenia tego, co już nie jest tak spektakularne ani nawet „fajne” do wytworzenia. Czasem wydaje mi się, że w takich momentach kwestia wymagań niefunkcjonalnych jest dla Deweloperów tak samo nudna i nieatrakcyjna, jak utrzymanie systemu i wykonywanie prac operacyjnych. Czy faktycznie tak jest?
Jak źle zarządzać wymaganiami niefunkcjonalnymi?
Skąd w takim razie bierze się takie podejście? Wiem o kilku przyczynach. Większość z nich to niestety niedostatki w umiejętnościach zarządzania wymaganiami przez Product Ownera. Niestety.
Za co płaci Klient? Klient płaci za to co widzi. Jeśli robimy rzeczy w backendzie albo optymalizujemy kod, to trudno pokazać widzialne efekty naszej pracy. Problem jest oczywiście bardziej złożony, a u jego źródeł leży umiejętności „sprzedawania” wymagań Klientom. Nie ma znaczenia, czy są to wymagania niefunkcjonalne (które czuć) czy funkcjonalne (które widać).
Kolejną przyczyną jest błędne pojęcie „najlepszego czasu” na wykonanie wymagań niefunkcjonalnych. Można zająć się nimi na końcu, ale wiemy, że to problematyczne. Podobnie, całkowitym niezrozumieniem tematu są osobne techniczne Sprinty, podczas których ludzie zmuszani są do dostarczenia tylko i wyłącznie tego typu wymagań. Rozwiązanie jest gdzieś po środku – trzeba nimi zajmować się na bieżąco, w odpowiednim momencie.
I tu w końcu wychodzi fakt nieumiejętnego zarządzania wymaganiami, a raczej nieujmowania ich w Backlogu. „Nie mam ich, bo nie wiedziałem, że trzeba” czy „Skąd miałem wiedzieć, że musimy je zrobić?”. To grzech niewiedzy, a ona wzięła się prawdopodobnie z braku Refinementów, wcześniej przygotowanego „kompletnego” Backlogu Produktu czy najzwyczajniej w świecie z braku współpracy z Deweloperami, którzy na pewno zwracali uwagę na te aspekty.
Można inaczej. Pracujmy inaczej, niż powyżej i nie traktujmy wymagań niefunkcjonalnych po macoszemu. One też zasługują na naszą uwagę!
