Archives for 2015

Kilka dni temu, Adrian Dampc napisał przydatny, choć krótki tekst o chorobie nadmiernej liczby funkcjonalności w produktach, którą na własny użytek nazywam ficzerozą. Produkty dotknięte tę dolegliwością stanowią niezwykle wdzięczny temat do rozmów przy okazji różnych spotkań branżowych (mój ulubiony przykład to stworzenie w jednym z CMSów modułu do obróbki plików graficznych o poziomie możliwości Adobe Photoshop, serio!), ale są też poważnym problemem, ponieważ koszt ich wytworzenia i utrzymania zwyczajowo jest bardzo wysoki w całościowym cyklu życia produktu.

Trudno więc się nie podpisać pod niemal całym wpisem, natomiast moje dotychczasowe doświadczenia, co do źródeł takiego zjawiska są nieco szersze, niż te opisane przez Adriana. Zacząłem pisać więc na UXWatch komentarz, ale po 200 słowach doszedłem do wniosku, że to tekst, który znakomicie się nadaje tutaj:

Adrian diagnozuje trzy główne powody powstawania nowych, niepotrzebnych funkcjonalności.

• konkurencja
• dosłowna interpretacja oczekiwań użytkowników
• nowa wersja produktu.

O ile diagnoza związana z konkurencją jest faktycznie trafiona  o tyle co do reszty punktów mam wątpliwości. W świecie rozbudowanych systemów informatycznych (kilkaset tysięcy linii kodu+) nowe wersje produktów posiadają dodatkowe funkcjonalności nie (tylko) dlatego, żeby lepiej się sprzedać, ale często z powodu ograniczeń technologicznych, czasowych czy kosztowych. Niektóre systemy posiadają na tyle duży dług technologiczny ,że bardziej opłaca się napisać rozwiązanie (nawet z nowymi możliwości) od podstaw niż przerabiać stare.

Według mnie, można zdiagnozować co najmniej kilka innych, istotnych powodów powstawania ficzerozy:

1. projektowanie i zarządzanie produktami przez komitety sterujące
   Design jest wartością uniwersalną, wszechobecną w naszym życiu, serwisy internetowe przegląda każdy, Facebook jest obecny na prawie każdym urządzeniu mobilnym. Rodzi to iluzję, że każdy kto korzysta z Internetu i ma smartfona ma też doświadczenie, wiedzę i umiejętność zarządzania projektami cyfrowymi.  W dużych organizacjach, realną władzę posiadają managerowie średniego i wyższego szczebla i zwykle to oni, w oparciu o politykę firmową, uzgodnienia i kompromisy na spotkaniach, podejmują decyzje o produktach. Zjawisko takie nosi nazwę design by committee i jest szczególnie obecne w organizacjach wykorzystujących tradycyjne podejścia do procesów i projektów (PRINCE2, ITIL, etc).
2. Brak właściciela biznesowego produktu
   Wbrew pozorom, nie każdy produkt cyfrowy ma właściciela. Część firmy nie widzą takiej potrzeby, co powoduje, że za zarządzanie aplikacjami, produktami czy  usługami odpowiadają działy IT lub marketingu. W takim modelu nowe funkcjonalności zgłaszane mailem czy przez ticket, lądują często bezpośrednio u programistów, bez żadnych racjonalizacji. Zresztą sam właściciel produktu, o ile nie ma odpowiednich instrumentów, aby rozwijać swój produkt (czyt. budżet, budżet i jeszcze raz budżet) i odpowiedniego miejsca w organizacji – bywa kwiatkiem do kożucha.
3. Model biznesowy organizacji tworzącej produkt
   Nie wszystkie organizacje posiadają w swojej strukturze działy zajmujące się tworzeniem oprogramowania. Niektóre wynajmują do tego firmy zewnętrzne, w którym żywotnym interesie jest rozwijanie produktu swojego klienta, tak długo jak to tylko możliwe. Innym, też popularnym przypadkiem są firmy specjalizujące się w tworzeniu specjalizowanych produktów (np. platform VOD, serwisów ogłoszeniowych, usługi wyszukiwarki), posiadające własny zespół programistów i projektantów. W takich firmach kolejne wdrożenia i kolejne funkcjonalności bardzo, bardzo często są rozwijane na potrzeby pojedynczych klientów. Rezultat – dość oczywisty ;)
4. Brak strategii rozwoju produktu sięgający dalej niż kwartał
   Może to kwestia firm, na jakie trafiałem i konsultowałem w swojej zawodowej karierze, ale brak strategii i wizji rozwoju posiadanych przez firmę produktów jest standardem. A nawet jeśli jakimś cudem strategia istnieje, to nie jest realizowana.
5. Brak dokumentacji
   Popularne ostatnimi laty metodyki zwinne doprowadziły (słusznie) do zmniejszenia biurokracji w projektach informatycznych. Dobre praktyki ograniczenia dokumentacji często jednak interpretowane są jako brak jakiejkolwiek dokumentacji (bo żółtych karteczek za dokumentację uznać nie potrafię). Efekty tego są wesołe – zdarzało mi się widzieć takie same lub prawie takie funkcjonalności tworzone po raz kolejny, tylko dlatego, że ani programiści, ani projektant nie posiadali dokumentacji produktu/projektu, w której istniałaby chociaż lista funkcjonalności
6. Trudność i koszty usuwania istniejących funkcjonalności
   Wraz z upływem czasu, złożoność rozwijanych cyfrowych produktów pod kątem technologicznym zwiększa się. Powoduje to, że zależności, które powstają pomiędzy poszczególnymi modułami, funkcjonalnościami i bibliotekami stają się coraz zawiłe i rozsupłanie ich jest trudne i “zjada” drogocenne zasoby: czas i pieniądze. Według różnych źródeł aplikacja/produkt cyfrowy/system żyje średnio około 5 lat. Implikuje to, że pozostawienie ficzera jest “prawie” darmowe (powstaje dług technologiczny, w efekcie którego system jest coraz trudniejszy w utrzymaniu i rozwoju) a zasoby, które należałoby użyć do jego usunięcia – można wykorzystać do rozwoju kolejnego. Rozwijany produkt, usługa, system i tak najprawdopodobniej zanim zbankrutuje technologicznie – przestanie być używana. Proste i logiczne. Niestety.

Nie są to oczywiscie jedyne i wyłączone powody powstawania feature creep. Wydaje mi się jednak, że powyższa lista podsumowuje najbardziej typowe powody tej bolączki.
Aha. Celowo nie odnoszę się do środowiska startupowego, bo mam relatywnie mało doświadczeń tamże, a z kolei ciągłe pivotowanie i wypróbowywanie kolejnych modeli biznesowych jest niejako wpisane w model start-up.