Powody Feature creep – kilka przemyśleń

tumblr_lldcbmA4nV1qewpp2o1_1280

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.

Jaka jest dobra cena za twój produkt – przypadek infakt.pl

Kilka tygodni temu czytałem polskie wydanie kultowej ksiązki Jessicki Livingstone Founders at work o niezbyt wdzięcznie przetłumaczonym tytule Rozmowy o startupach. Szczególnie utkwił mi w głowie fragment wywiadu Joela Spolsky-ego (twórcy popularnego bloga Joel on Software i m.in. FogBugz) poświęcony zwiększaniu wiarygodności i podwyższaniu ceny za produkt:

Po prostu siedzieliśmy i patrzyliśmy, jak krzywa wzrostu pnie się do góry – tak jest do dzisiaj, już od pięciu lat. Aplikacja staje się coraz bardziej popularna i sprzedajemy jej więcej i więcej każdego miesiąca.
Kilkakrotnie musieliśmy podnieść jej cenę – podwyżka ceny sprawiła, że sprzedaliśmy więcej jednostek. Pewnie dlatego, że z bardziej realistyczną ceną sprawiała wrażenie poważniejszej.
Livingston: Ludzie traktują produkt poważniej, jeżeli muszą za niego więcej zapłacić?
Spolsky: Zdecydowanie tak. Mieliśmy licencję na pięciu użytkowników za 199 dolarów, a to praktycznie jak licencja na oprogramowanie typu shareware. Jeśli jednak dzisiaj ogłosisz, że licencja na 10 użytkowników kosztuje 999 dolarów, zaczyna się ją postrzegać jako bardziej znaczący produkt. Na obecnym rynku taka cena to i tak niezła okazja. Rzecz jednak w tym, aby wyznaczyć cenę, która ukazuje, jaką pozycję powinien zajmować produkt. Wiele osób ocenia miejsce produktu na rynku na podstawie jego ceny.
Dlatego dwa razy podnieśliśmy cenę i za każdym razem wzrosła liczba sprzedawanych przez nas jednostek. Wypuściliśmy też nowe wersje, dodawaliśmy nowe funkcje. Produkt stał się wręcz gigantyczny.

Pomyślałem o tym cytacie raz jeszcze, kiedy dostałem fakturę pro-forma na kwotę 118 PLN od firmy InFakt, która produkuje świetną web aplikację do wystawiania faktur. Kwota nieco mnie zastanowiła, wiec przejrzałem poprzednie faktury. Wynik poszukiwania był jak poniżej.

infakt

W ciągu 4 lat twórca aplikacji dwukrotnie podniósł cenę za swoją najprostszą (i najtańszą) usługę, jaką jest wystawianie faktur. To prawda, aplikacja się rozrosła bardzo mocno, poza wystawianiem faktur oferuje także usługi księgowe (płatne extra), wysyłanie faktur tradycyjną pocztą (płatne extra) i innej przydatne funkcjonalności.
Prawda jest też to, że moduł wystawiania faktur prawie się nie zmienił od roku, a ja kompletnie nie zmieniałem parametrów usługi. Co gorsza, zmiana pakietu na droższy w żaden przejrzysty sposób (poza wyższą kwotą na fakturze) nie została mi jako zakomunikowana.

Czy takie zmiany są uczciwe w stosunku do klientów? Czy taka praktyka nie jest nieco samobójcza, biorąc pod uwagę, że konkurencją dla takiej usługi jest zwykły edytor tekstu, który jest w stanie spokojnie generować przyjazne dla oka faktury?

Jestem bardzo ciekaw, jak ostatnie zmiany cenowe wpłyną na satysfakcję klientów. Rozumiem ekonomiczny sens wprowadzanych zmian, ale z perspektywy doświadczeń użytkownika uważam zarówno komunikowanie zmiany jak i całościowe traktowanie klienta za porażkę. Co więcej,  mam wrażenie Fakt bardziej dba o swój wizerunek w artykułach na branżowych serwisach niż o płacących klientów. Z drugiej strony może decyzja o podwyżkach była świadoma a klienci bardzo zadowoleni z usług nie zauważą różnicy? Interesujące.

PS. Zrobiłem szybką sondę wśród znajomych używających InFakt. Nikt nie zauważył ani nie miał świadomości podwyżki.

Tekst miesiąca – Ciężkie życie korporacyjnego projektanta

Maciek Lipiec napisał prawdziwy, chociaż gorzki tekst na temat życia korporacyjnego projektanta. Wczoraj i dziś przez Facebookowe ściany przesypała się lawina komentarzy na temat doświadczeń i historii różnych projektów. Gorąco polecam do przeczytania, bo warto.

Wyrwane z kontekstu – I Have Seen the Future and I Am Opposed

The much more fundamental problem is caused by the business models of the service providers, whether they be for radio or television, cable or satellite, telephone or mobile phone. Each of these providers wish to maximize their profit while simultaneously minimizing that of their competition. They try to enforce proprietary standards, locking people into their own distribution: Think proprietary digital rights management systems for music, movies and books, think locked cellular phones, think region codes on movie DVDs, think overly restrictive copyrights on content and over-inclusive patents on inventions and ideas. Each system has some basis in logic and business, each has some legitimate reason for existence. But these systems are implemented and enforced in ways that restrict them far beyond what is necessary — even to the point of reducing creativity and hurting individuals.

More and more of our open, universal networks are becoming locked down, available only from within the walls erected by corporate interests. This is how a number of our early communication services started: they were walled gardens with all news, entertainment and information locked away inside, accessible only to members. This is the model being followed in todays television world of cable and satellite delivery — it threatens to be the model of all service and content providers.

Źródło: I Have Seen the Future and I Am Opposed, Don Norman

Krótko – zbiór esejów i artykułów o projektowaniu interakcji

Dan Saffer, autor bardzo znanej ksiażki Designing for Interaction: Creating Innovative Applications and Devices, opublikował bardzo przydatną listę artykułów i esejów, poświęconych projektowaniu interakcji. Część z nich, faktycznie jest kultowa  jak “The magical number seven, plus or minus two: Some limits on our capacity for processing information”,  część z nich – godna jest uwagi.  Polecam.

Wyrwane z kontekstu – Gestural interfaces: a step backwards in usability

Yes, new technologies require new methods, but the refusal to follow well-tested, well-established principles leads to usability disaster.

[Read more…]