Rozrost funkcji: co to jest i jak mu zapobiegać

Wszyscy mieliśmy kiedyś taki produkt, którego po prostu nie mogliśmy wprowadzić na rynek, ponieważ zawsze wydawało się, że trzeba dodać „jeszcze tylko jedną funkcję”. Czasami nowe funkcje dodawał do zakresu dyrektor generalny. W innych przypadkach chodziło o uwzględnienie każdej, absolutnie każdej prośby użytkowników.

Niezależnie od przyczyny wszyscy doświadczyliśmy cichego zabójcy świetnych produktów — rozrostu funkcji.

Nie wyobrażacie sobie, ile obiecujących produktów przepadło w otchłani, ponieważ zespoły programistyczne i produktowe nie zdołały wprowadzić ich na rynek na czas, zajęte budowaniem niepotrzebnych funkcji.

Dlatego, aby pomóc Wam uniknąć tej częstej pułapki, wyjaśnię, czym jest rozrost funkcji i jak z nim walczyć, stosując proste taktyki, takie jak kontrola zmian i zarządzanie w górę.

Czym jest rozrost funkcji (czyli rozrost zakresu)?

Kiedy ktoś wspomina przy mnie o produkcie dotkniętym rozrostem funkcji, zawsze wyobrażam go sobie jako niechlujne, nadmuchane stworzenie z dodatkowymi, zbędnymi częściami ciała, które z trudem porusza się pod ciężarem wszystkich dodatkowych elementów. Kiedy poprosiłem nowy (i całkiem imponujący) generator obrazów ChatGPT, aby ożywił ten obraz, oto co stworzył.

P.S., sztuczna inteligencja jest naprawdę całkiem dobra w burzy mózgów dotyczącej przydatnych funkcji produktu, jeśli jesteście ciekawi.

Innymi słowy, rozrost funkcji to niekontrolowane dodawanie funkcji do produktu bez konkretnej wizji lub kierunku rozwoju. Często prowadzi to do sytuacji, w której rejestr wydań rośnie szybciej, niż udaje się dostarczać funkcje.

Istnieje również termin „rozrost zakresu”, który często stosuje się zamiennie do opisania tej sytuacji. Między tymi terminami istnieje jednak subtelna różnica.

• Rozrost zakresu zwykle odnosi się do niekończącego się dodawania funkcji do planu wydania, co prowadzi do opóźnień.
• Rozrost funkcji skupia się bardziej na rezultacie — produkcie przypominającym Frankensteina, po którym trudno się poruszać lub z którego trudno korzystać.

Istnieje również trzeci, powiązany termin — pułapka fabryki funkcji. Omówimy ją jednak w naszej sekcji pytań i odpowiedzi na końcu.

Oznaki rozrostu funkcji

Główne objawy rozrostu funkcji w produkcie są zazwyczaj oczywiste i łatwe do zauważenia. Do najbardziej widocznych należą:

• Zakres wydania się zwiększa bez jasnego wyjaśnienia, dlaczego potrzebujemy w nim nowych funkcji.
• Okazuje się, że opóźnienia wydań wynikają z dodanych funkcji w zakresie.
• Interesariusze dominują nad zarządzaniem zakresem wydania, nie przyjmując odpowiedzi „NIE”.

Niebezpieczeństwo związane z rozrostem funkcji polega na tym, że czasami jest on skrytym stworzeniem, które trudno zauważyć, dopóki nie jest za późno.

Zakładając, że nie widzicie tych oznak, czy oznacza to, że jesteście bezpieczni i rozrost funkcji Was nie dotyczy? Niekoniecznie. Niebezpieczeństwo związane z rozrostem funkcji polega na tym, że czasami jest on skrytym stworzeniem, które trudno zauważyć, dopóki nie jest za późno. Oznacza to, że niektóre jego objawy nie są tak łatwe do zidentyfikowania. Oto dwa z nich:

• Ciągłe zmiany zakresu. Zmiana zakresu jest czymś normalnym w realiach metodyk Lean i Agile. Czasami w porządku jest również dodanie 1–2 funkcji do zakresu wydania, gdy rozumiemy, że bez nich wartość dla użytkownika zostanie utracona. Jednak gdy zakres wydania cały czas się zwiększa, a dodatkowe funkcje nie mają dla użytkownika dużej wartości, mamy do czynienia z rozrostem funkcji.
• Interesariusze wywierają presję, aby zbudować ostateczną wersję produktu. Rozumiem, że wersja beta lub wersja MVP nie jest czymś, co przyniesie interesariuszom przychody. Dlatego naturalne jest, że uznają MVP za stratę czasu i chcą skupić się zamiast tego na wersji ostatecznej. Jednak budowanie wersji ostatecznych bez wcześniejszej walidacji kluczowych funkcji przez użytkowników MVP to gwarantowany sposób na stworzenie rzeczy, których ludzie nie potrzebują.

Jeśli przyjrzymy się uważnie tym objawom (zwłaszcza tym subtelnym), wielu z nas zda sobie sprawę, że chaotyczny zakres projektu, z którym mamy do czynienia, nie jest „zwinnością”. To po prostu stary, dobry rozrost funkcji.

Dobrze, ale jak do tego doszło? Wydawało się, że robiliście wszystko, co w Waszej mocy, aby kontrolować zakres. Przyjrzyjmy się typowym (i zaskakującym) powodom, dla których w produktach dochodzi do rozrostu zakresu.

Dlaczego dochodzi do rozrostu funkcji?

Oto jesteście — mimo wysiłków włożonych w zarządzanie rejestrem. Jak do tego doszło? Przez większość czasu podstawowe przyczyny rozrostu funkcji są trudne do zauważenia, a ich naprawienie za pomocą prostego zarządzania zakresem jest jeszcze trudniejsze.

The truth about project scope creep

Patrząc z perspektywy czasu na wyboistą drogę, którą nazywam swoją karierą, zdaję sobie sprawę, że również miałem swój udział w przypadkach rozrostu funkcjonalności. Stojące za tym powody nie były wtedy oczywiste. Większość tych wniosków wynikała z trudnych lekcji zdobywanych metodą prób i błędów w pierwszych latach mojej kariery. Jednak teraz, patrząc na te wydarzenia oczami głównego menedżera produktu, widzę, gdzie wszystko zaczęło się rozpadać.

Ogólnie rzecz biorąc, rozrost funkcjonalności ma miejsce z jednego z następujących powodów:

• Presja interesariuszy: CZYLI „Dodajmy jeszcze tylko jedną rzecz i to wszystko”. Słyszałeś to, ja też. Czasami interesariusze sądzą, że niewielkie rozszerzenie zakresu nie wpłynie na datę wydania, ponieważ jest naprawdę małe. Problem polega na tym, że nawet najmniejsza zmiana musi przejść przez cały proces przeglądu kodu, zapewniania jakości oraz potok CI/CD, co może trwać całymi dniami.
• Menedżerowie produktu zbyt rzadko mówią „NIE”: Wiem, że to trudne — szczególnie gdy trzeba przeciwstawić się interesariuszom. Jednak większość z nich z chęcią wycofa swój pomysł, jeśli jasno wyjaśnisz im związane z nim kompromisy. Jeśli przełożysz ich „małą prośbę” na dodatkowy czas, kolejne cykle zapewniania jakości, dostępność zespołu inżynieryjnego oraz potencjalne ryzyko dla harmonogramu wydania, zrozumieją, że nie chodzi tylko o szybką poprawkę — to inwestycja z realnymi konsekwencjami.
• Spełnianie każdej prośby klienta: To kuszące — szczególnie gdy próbujesz zdobywać umowy, utrzymywać klientów o wysokiej wartości lub udowodnić swoją responsywność. Jednak tworzenie wszystkiego, o co proszą klienci, nie sprawia, że produkt staje się lepszy. Po prostu staje się przeładowany, niespójny i trudniejszy w utrzymaniu.
  
  Trudna prawda? Nie każda informacja zwrotna ma taką samą wartość. Świetne zespoły produktowe wiedzą, kiedy działać, kiedy odłożyć coś na później, a kiedy odpuścić — ponieważ każde „tak” ma swoją cenę: chodzi o posiadanie przejrzystej pętli informacji zwrotnej od klientów, która pomaga strategicznie ustalać priorytety dla otrzymywanych opinii i zachować zgodność z wizją produktu.
• Presja konkurencji: To, że konkurent uruchomił efektowną funkcję opartą na sztucznej inteligencji, nie oznacza, że musisz na siłę wprowadzać coś podobnego do bieżącego wydania. Zbyt szybkie reagowanie często prowadzi do niedopracowanych funkcji, które w rzeczywistości nie przynoszą znaczących efektów — a co gorsza, mogą wykoleić plan rozwoju, obniżyć jakość produktu i opóźnić premiery. Silne przywództwo produktowe często oznacza wiedzę o tym, kiedy się zatrzymać, dokonać oceny i chronić spójność tego, co tworzysz.
• Brak jasno określonego zakresu: Wczesne uzgodnienie tego, co wchodzi w zakres, a co nie, ma kluczowe znaczenie dla ochrony harmonogramu, a wszystko zaczyna się od wypracowania wspólnego rozumienia zakresu dzięki solidnym praktykom zarządzania produktem w Scrumie.
• Przeinżynierowanie: Przeinżynierowanie często zaczyna się od dobrych intencji — zabezpieczenia na przyszłość, optymalizacji, zaimponowania współpracownikom — ale kończy się kruchymi systemami, których nikt w pełni nie rozumie. Prawdziwa umiejętność nie polega na tworzeniu czegoś złożonego. Chodzi o to, by wiedzieć, kiedy tego nie robić. Stosowanie podstawowych najlepszych praktyk zarządzania produktem może pomóc zespołom skupić się na dostarczaniu wartości bez zbędnej złożoności.
• Uwzględnianie przypadków użycia wszystkich użytkowników: Nie wszyscy użytkownicy końcowi są sobie równi. Niektórzy są „równiejsi od innych” (czyli przynoszą ci więcej pieniędzy). Oto cytat Briana de Haaffa, współzałożyciela i dyrektora generalnego Aha!, dotyczący równoważenia opinii użytkowników z celami biznesowymi.

Patrząc na powyższą listę, prawdopodobnie dostrzeżesz kilku winowajców czających się w twoim własnym produkcie. I choć każdy z nich z osobna może wydawać się nieszkodliwy, razem po cichu podkopują koncentrację, tempo pracy i integralność produktu.

Ile kosztuje cię rozrost funkcjonalności?

Krótka odpowiedź? Bardzo dużo! Rozrost funkcjonalności wiąże się z ukrytymi kosztami, które po cichu obniżają jakość i wydajność produktu oraz morale zespołu. Chociaż jego wpływ na doświadczenie użytkownika jest tak szkodliwy, że zasługuje na osobną sekcję, najpierw przyjrzyjmy się innym sposobom, na jakie podważa on twój produkt.

Niedotrzymywanie terminów wydań

Czas wprowadzenia produktu na rynek często ma większe znaczenie niż dopracowanie. Przekonałem się o tym na własnej skórze podczas tworzenia mojej pierwszej funkcji opartej na sztucznej inteligencji. Miałem obsesję na punkcie osiągnięcia współczynnika błędów wynoszącego 0%, ale mój dyrektor generalny wciąż mi przypominał: „Nie musi być idealna — musi po prostu zostać wydana”.

Miał rację. Wystartowaliśmy szybko i choć funkcja była niedopracowana, byliśmy pierwsi. Ponieważ jako pierwsi wśród konkurencji ją uruchomiliśmy, ludzie zaczęli kojarzyć tę funkcję AI (chodziło o podsumowywanie rozmów; uruchomiliśmy ją na długo przed Microsoft Teams i innymi rozwiązaniami) z naszą marką. Dlatego nawet gdy Teams ją wprowadził, wiele osób nadal korzystało z naszego narzędzia, ponieważ zdążyli się do niego przyzwyczaić.

To wczesne wdrożenie zapewniło nam rozpoznawalność marki i przewagę w doskonaleniu doświadczenia, podczas gdy konkurenci wciąż próbowali nas dogonić. Gdybyśmy czekali, mogliśmy całkowicie przegapić ten moment.

Ponadto, ponieważ wystartowaliśmy jako pierwsi, mieliśmy przewagę czasową w iteracyjnym rozwijaniu i dopracowywaniu funkcji, podczas gdy inni dopiero uruchamiali swoje pierwsze, niedopracowane wersje.

Rozrost funkcji spowalnia zespoły i je wyczerpuje

Każda dodana funkcja nie tylko wymaga czasu na zbudowanie — zwiększa też obciążenie wszystkiego, co następuje później. Z czasem architektura produktu staje się trudniejsza do zrozumienia. Nawet niewielkie zmiany mogą wywołać lawinę nieoczekiwanych zależności między modelami danych, interfejsami, testami i przepływami pracy. W rezultacie wdrażanie nowych funkcji trwa dłużej, naprawianie błędów staje się bardziej ryzykowne, a zaufanie do bazy kodu słabnie.

Narastająca złożoność wpływa nie tylko na dostarczanie produktu — uderza również w morale. Gdy zespoły tkwią w rozplątywaniu przypadków brzegowych lub poruszają się na palcach wokół decyzji podjętych w przeszłości, impet zanika. A kiedy kolejne wydania opóźniają się, ponieważ zakres wciąż rośnie, łatwo odnieść wrażenie, że nic nigdy nie zostaje ukończone. Właśnie wtedy zaczyna się wypalenie — nie z powodu ciężkiej pracy, lecz pracy, która sprawia wrażenie, jakby donikąd nie prowadziła.

Jak rozrost funkcji wpływa na UX

Wpływ rozrostu funkcji na UX jest tak znaczący, że muszę omówić go w osobnej sekcji. Dobre doświadczenie użytkownika jest jednym z kluczowych aspektów sukcesu produktu i czymś, na co należy zwracać szczególną uwagę. W końcu każdy dolar wydany na budowanie dobrego doświadczenia użytkownika może przynieść 100 dolarów przychodu.

Oczywiście chcesz zrobić wszystko, co możliwe, aby uniknąć czynników szkodzących UX, w tym budzącego grozę rozrostu funkcji.

Ale jak dokładnie rozrost funkcji szkodzi UX? Oto jak:

Przeciążenie interfejsu

Paradoks polega na tym, że większa liczba funkcji nie oznacza lepszego produktu. Wręcz przeciwnie — dodanie zbyt wielu elementów do produktu pogarsza jego użyteczność.

Logika jest tu prosta — użyteczność jest bezpośrednio związana z tym, jak przejrzysty i lekki jest interfejs. W przypadku rozrostu funkcji kończysz jednak z dziesiątkami funkcji i przypisanych do nich przycisków upchniętych w interfejsie, przez co nawigacja staje się trudna.

W świetnych produktach każdy ekran na ścieżce użytkownika ma jeden główny cel. Wszystkie elementy tego ekranu, które nie służą głównemu celowi, będą rozpraszać użytkownika i utrudniać mu osiągnięcie celu. Dlatego im mniej drugorzędnych elementów interfejsu masz, tym lepsza staje się użyteczność.

Spójrzmy na ten kalkulator wcześniejszej spłaty kredytu hipotecznego jako przykład.

Każdy element tego interfejsu służy jednemu celowi — pomaga obliczyć wcześniejszą spłatę kredytu hipotecznego. Dzięki temu jest łatwy w użyciu nawet dla osób, które widzą go po raz pierwszy. Nie ma tu żadnych dodatkowych funkcji, które mogłyby wprowadzać w błąd lub przytłaczać użytkownika.

Teraz spójrzmy na edytor automatyzacji Jira.

Zabolały cię oczy od samego patrzenia? Bo mnie tak! Dobrze, przyznaję — to potężna funkcja z mnóstwem możliwości. Atlassian zdołał jednak umieścić je wszystkie w jednym interfejsie, przez co nawigacja po nim może być nieco onieśmielająca.

Automatyzacja Jira jest więc żywym dowodem na to, jak tworzenie zbyt wielu funkcji (czyli rozrost funkcji) szkodzi użyteczności.

Spadek wydajności

Oprócz utrudniania nawigacji po interfejsie rozrost funkcji może również prowadzić do znacznego spowolnienia produktu.

Każda nowa funkcja, którą zbudujesz, będzie zawierać dodatkowy kod JavaScript do przetworzenia przez przeglądarkę użytkownika oraz logikę zaplecza do przetworzenia przez serwery. Dodanie wielu funkcji o niskiej wartości spowoduje więc przeciążenia zarówno urządzeń użytkowników, jak i serwerów.

Spowolnienie produktu należy do najbardziej dotkliwych problemów z użytecznością, jakie mogą wystąpić. Słynne badanie Amazona wykazało, że spowolnienie o 100 ms kosztowało firmę 1% przychodów.

Jak zarządzać rozrostem funkcji (i mu zapobiegać)

Rozrost funkcji zaszkodzi postępom w rozwoju produktu i zdarza się cały czas. Dobra wiadomość jest jednak taka, że dość łatwo nim zarządzać i mu zapobiegać (gdy wiadomo jak).

Oto 6-etapowy przewodnik, jak trzymać go pod kontrolą.

1. Opieraj każdą decyzję na wizji produktu

Gdy produkt nie ma jasnej, wspólnej wizji, każdy pomysł może wydawać się uzasadniony — i właśnie tak zaczyna się rozrost funkcji. Wizja pozwala zespołom skupić się na priorytetach. Określa nie tylko to, co tworzysz, ale także to, czego nie tworzysz.

Weźmy na przykład Figma. Na początku zespół świadomie zdecydował, że pozostanie przy wersji przeglądarkowej — mimo że wielu użytkowników prosiło o natywną aplikację komputerową. Ta decyzja nie wynikała z ignorowania opinii, lecz z zaangażowania w długoterminową wizję dostępności i współpracy w czasie rzeczywistym. Gdyby ulegli każdej prośbie, mogli stracić właśnie tę cechę wyróżniającą, która uczyniła z nich Figmę.

Silna wizja nie ma służyć inspirowaniu — ma służyć filtrowaniu. Bez jasnej wizji ustalanie priorytetów zamienia się w negocjacje. Z nią możesz z przekonaniem powiedzieć: „nie teraz” — albo „wcale”. Staje się oczywiste, co nie pasuje.

2. Bezwzględnie ustalaj priorytety za pomocą planu rozwoju

Prawidłowo przeprowadzone ustalanie priorytetów to kolejny sposób na uniknięcie rozrostu funkcji. Kluczowe są tutaj słowa „prawidłowo przeprowadzone”. Oznaczenie co drugiego pomysłu na funkcję jako „musi być” nie jest ustalaniem priorytetów.

Aby uniknąć takiej sytuacji, przyjrzyj się swojej wizji i kluczowym potrzebom użytkowników. Jeśli pomysł na funkcję nie przyczynia się jednocześnie do realizacji obu tych elementów, z całą pewnością nie jest niezbędny.

Jeśli chodzi o metody ustalania priorytetów, moimi osobistymi faworytami są te dwie:

MoSCoW: Prosta klasyfikacja pomysłów na „musi być”, „powinno być”, „może być” i „nie będzie”. Rejestr zadań uporządkowany według MoSCoW wygląda tak:

RICE: To tabela, w której każdy wiersz odpowiada pomysłowi na funkcję, a każda kolumna przedstawia:

• Liczbę użytkowników, którym służy funkcja (zasięg)
• To, jak dobrze rozwiąże ona problemy użytkowników (wpływ)
• To, na ile masz pewność, że funkcja odniesie sukces (pewność)
• Zasoby potrzebne do jej zbudowania (wysiłek).

Oto jak to wygląda:

Oba te frameworki są wystarczająco proste, aby priorytetyzować backlog w arkuszu kalkulacyjnym lub pliku prezentacji. Zalecam jednak korzystanie zamiast tego z specjalistycznego narzędzia do zarządzania produktem (np. Aha! lub ProdPad), ponieważ automatyzują one większość pracy i integrują się z używanym przez Ciebie oprogramowaniem do zarządzania zadaniami.

3. Weryfikuj funkcje przed ich zbudowaniem

Z mojego doświadczenia wynika, że walidacja pomysłów jest jednym z najskuteczniejszych sposobów obrony przed bezużytecznymi pomysłami na funkcje. Jest szczególnie pomocna, gdy odczuwasz presję ze strony interesariuszy. Jeśli mają pomysł, który chcesz wdrożyć, najpierw go zweryfikuj.

Pomysł albo przejdzie walidację i zdasz sobie sprawę, że warto go zbudować, albo jej nie przejdzie i będziesz mieć empiryczne dowody, które możesz przedstawić interesariuszom, gdy powiesz im „NIE”.

W ramach walidacji możesz zastosować następujące podejścia:

1. Przeprowadzaj wywiady z użytkownikami, aby zrozumieć, czy jest to coś, czego potrzebują.
2. Twórz klikalne prototypy i pozwól użytkownikom z nich korzystać oraz przekazywać Ci informacje zwrotne.
3. Przeprowadzaj testy A/B, aby uzyskać dane analityczne pokazujące, czy ludzie korzystają z tego pomysłu, czy go ignorują.
4. Zbuduj wersję MVP (minimalnie funkcjonalnego produktu) tej funkcji, udostępnij ją i przetestuj.

Podejścia na tej liście są uporządkowane od najtańszego (wywiady) do najdroższego (MVP). Dlatego radzę Ci zacząć od pierwszego. Pozwoli Ci ono odrzucić zły pomysł na funkcję bez poświęcania zbyt dużej ilości czasu i wysiłku.

4. Ustal granice zakresu i trzymaj się ich

Istnieje również taktyka bezpośredniej odmowy zmiany zakresu wydania. Nie chodzi oczywiście o stuprocentową odmowę, lecz o utrzymanie pierwotnego zakresu bez zmian, chyba że pojawi się coś krytycznego, co trzeba zrealizować. 

Jedynym momentem, w którym można zmienić zakres, jest uświadomienie sobie, że pierwotny plan nie jest w stanie obsłużyć przypadku użycia, dla którego zbudowano tę funkcję.

Wyobraź sobie na przykład, że tworzysz narzędzie AI do przetwarzania dokumentów podatkowych, które obsługuje wyłącznie pliki graficzne. W pewnym momencie zdajesz sobie sprawę, że wiele dokumentów podatkowych to pliki PDF, a nie obrazy. Brak obsługi plików PDF sprawi więc, że funkcja będzie bezużyteczna. W takiej sytuacji można zmienić zakres.

Ten proces jest znany jako kontrola zmian i stanowi świetne narzędzie do zarządzania rozszerzaniem zakresu.

5. Edukuj interesariuszy i uzgadniaj z nimi cele

Z mojego doświadczenia wynika, że większość z około sześciu prezesów, z którymi pracowałem, nie ma nic przeciwko usłyszeniu „nie” — pod warunkiem że potrafisz wyjaśnić dlaczego.

Osoby na stanowiskach kierowniczych chcą działać szybko, ale polegają na Tobie, jeśli chodzi o wskazanie dalszych konsekwencji tego, co może wydawać się niewielką prośbą.

Mary Abbajay w Managing Up

Nie potrzebujesz dramatycznej obrony — wystarczy jasne przedstawienie kompromisów. Gdy zobaczą, że prośba może opóźnić realizację lub zagrozić innym priorytetom, większość nie tylko uszanuje sprzeciw — będzie też zadowolona, że ktoś myśli dalej niż tylko o natychmiastowym „tak”.

 6. Regularnie przeprowadzaj audyt i usuwaj zbędne elementy

Wszyscy wiemy, że powinniśmy utrzymywać porządek w backlogach, ale łatwo dopuścić do tego, by zamieniły się w cmentarzysko niedopracowanych pomysłów i dawno zapomnianych próśb o funkcje. Zamiast traktować porządkowanie backlogu jak kwartalną pokutę, pomyśl o nim jak o rutynowej konserwacji — podobnej do podlewania roślin lub usuwania zrzutów ekranu z pulpitu.

Jednym z zaskakująco przydatnych ćwiczeń (wytrzymaj ze mną) jest to, co lubię nazywać przycinaniem drzewa produktu. Odwzorowujesz funkcje produktu jako części drzewa — pień, gałęzie i liście — a następnie wspólnie z zespołem decydujesz, co rozwija się dobrze, co wymaga przycięcia, a czego można się pozbyć. 

To wizualne, zespołowe i dziwnie satysfakcjonujące ćwiczenie — a przy okazji może w końcu pomóc Ci pogodzić się z backlogiem.

Przykłady rozszerzania zakresu funkcji z rzeczywistego świata

Wielu z nas uważa, że rozszerzanie zakresu funkcji zdarza się rzadko albo że spotykamy się z nim na początku kariery, a później uczymy się nad nim panować. Nic bardziej mylnego. Nawet giganci technologiczni i obiecujące startupy doświadczyli przypadków rozszerzania zakresu funkcji, które niemal doprowadziły ich produkty do upadku. Oto kilka znaczących przykładów.

Przykład 1: Windows Vista

Istnieje teoria, że Microsoft psuje co drugą wersję systemu Windows. XP był świetny. Naturalnie więc Vista miała być tą katastrofalną wersją.

I tak właśnie było. Był to rozdęty, nadmiernie rozbudowany system operacyjny, który wymagał zbyt dużej mocy obliczeniowej i słynął z niestabilności.

Jednym z powodów tego chaotycznego wydania było rozszerzanie zakresu funkcji. Microsoft chciał ulepszyć wszystko naraz w jednym nowym wydaniu. Dodano efektowny interfejs użytkownika, zmieniono architekturę zabezpieczeń, chciano zapewnić pełną kompatybilność wsteczną oraz atrakcyjne widżety.

Skutkiem tego wszystkiego była niechęć użytkowników do aktualizacji z XP do Visty. Świat komputerów uznał ją za porażkę, a Microsoft mógł odzyskać swoją reputację dopiero dzięki wydaniu znakomitego następcy Visty — systemu Windows 7.

Przykład 2: Google Wave

Szczerze mówiąc, nigdy nie rozumiałem, czego dotyczył ten produkt. Z opisu wynika, że Google Wave to narzędzie umożliwiające współpracę w czasie rzeczywistym nad zasobami takimi jak dokumenty. Ja jednak postrzegam je jako niezorganizowany zbiór niesamowitych, ale pozbawionych znaczenia funkcji.

To świetny przykład tworzenia czegoś bez wizji i strategii. Tak, funkcje współpracy w czasie rzeczywistym z Google Wave trafiły ostatecznie do Dokumentów Google i stały się ich podstawową funkcją, zaspokajając rzeczywiste potrzeby użytkowników. Jednak pierwotny produkt był po prostu zbiorem funkcji połączonych bez żadnego praktycznego celu.

Przykład 3: przeprojektowanie Snapchata

Kiedy Snapchat wprowadził ogromne przeprojektowanie interfejsu w 2018 roku, ludzie byli wściekli.

Powodem, dla którego nikt nie polubił nowego wyglądu, było — podobnie jak w przypadku innych przykładów z tej listy — to, że zawierał zdecydowanie zbyt wiele funkcji bez wyraźnego kierunku. Zespół Snapchata tak bardzo skupił się na dodawaniu wielu „fajnych” funkcji, że całkowicie zapomniał o zachowaniu spójnych ścieżek użytkownika.

Skutkiem było ogromne zamieszanie, gdy użytkownicy nie mogli znaleźć funkcji, z której chcieli skorzystać w nowym interfejsie.

Kiedy rozszerzanie funkcji jest dobrym rozwiązaniem

Jak wspominałem wcześniej, nie każde rozszerzenie zakresu jest złe. W rzadkich przypadkach dodanie nowych funkcji do zakresu wydania jest w porządku.

Ogólna zasada mówi, że nowy pomysł na funkcję powinien jednocześnie spełniać te trzy kryteria, aby można było uwzględnić go w zakresie:

• Użytkownicy go zweryfikowali. Po wypróbowaniu prototypów lub MVP użytkownicy wskazali, że brakuje określonej funkcji i że jest ona dla nich ważna.
• Jest zgodny ze strategią. Funkcja, o którą poprosili użytkownicy, przyczynia się do realizacji Twojej wizji i strategii.
• Stać Cię na jej stworzenie. Dodanie tej funkcji nie wpłynie znacząco na harmonogram wydania, a w Twojej firmie są dodatkowe osoby, które mogą ją zbudować.

Jeśli widzisz, że Twój pomysł na funkcję spełnia te trzy kryteria, prawdopodobnie jest naprawdę ważny, a zignorowanie go doprowadzi do złych doświadczeń użytkowników po wydaniu. W takiej sytuacji można dodać go do zakresu.

Jak wychwytywać dobre pomysły, nie tracąc koncentracji?

Dobre pomysły nie zawsze pojawiają się zgodnie z harmonogramem prac. Mogą pojawić się w połowie sprintu, podczas rozmowy przy kawie albo w „krótkiej wiadomości na Slacku”, która okazuje się czymś zupełnie innym. Wyzwaniem nie jest powstrzymywanie pomysłów — chodzi o to, by wiedzieć, jak je zachować, nie tracąc kierunku.

Oto jak pozostawić otwarte drzwi, nie dopuszczając do rozszerzenia zakresu:

• Wyznacz miejsce na pomysły, które nie są przeznaczone na teraz. Kolumna backlogu, dokument zespołu, tablica w Notion — cokolwiek pasuje do Twojego sposobu pracy. Najważniejsze, żeby było to widoczne, regularnie przeglądane i nie było traktowane jak cmentarzysko. Dzięki temu zespół może powiedzieć „tak, ale później” zamiast „jasne, spróbujmy to jakoś przemycić”.
• Korzystaj ze struktur, które pokazują priorytety, a nie tylko przechowują informacje. Drzewa produktu, tablice Teraz/Następnie/Później czy harmonogramy z podziałem na poziomy pomagają wizualizować kompromisy. Gdy ktoś doda nowy pomysł, możesz wskazać tablicę i powiedzieć: „To świetny pomysł — oto miejsce, w którym by się znalazł”. Dzięki temu wszyscy zachowują wspólny kontekst.
• Porządkuj pomysły celowo, a nie reaktywnie. Zarezerwuj regularny czas na ponowną ocenę pomysłów. Co kilka tygodni przeglądaj to, co się pojawiło. Co staje się pilne? Co nadal jest interesujące, ale nieprzydatne? Taka regularność daje dobrym pomysłom przestrzeń na dojrzewanie — i odfiltrowuje szum.
• Jasno komunikuj interesariuszom, co jest w planie, a co zostało odłożone. Jeśli ktoś ważny zgłosi prośbę o funkcję, nie ignoruj jej. Potwierdź jej otrzymanie, wyjaśnij, gdzie się wpisuje (lub dlaczego się nie wpisuje), i upewnij się, że została zarejestrowana. Gdy ludzie wiedzą, że ich opinie są szanowane — nawet jeśli ich realizacja zostanie odroczona — z większym prawdopodobieństwem uszanują Twoje priorytety.

Podsumowując: nie wszystko musi zostać wdrożone od razu. Zbieraj pomysły uważnie, a nie w panice. Twoja przyszła mapa drogowa będzie Ci wdzięczna.

Podsumowanie: używaj wizji jako filtra, a nie muru

Rozrost funkcji nie dotyczy pomysłów — chodzi o kompromisy. Niektóre nowe prośby będą tego warte, nawet w trakcie sprintu. Jednak bez jasnej wizji i procesu oceny wpływu po prostu mówisz „tak” na cały szum.

Gdy pojawia się nowa funkcja, nie pytaj tylko:

„Czy powinniśmy ją zbudować?”

Zapytaj:

„Czego nie zbudujemy, jeśli to zrobimy?”

To jest prawdziwy koszt. 

Co dalej

Nie zapomnij zapisać się do naszego newslettera, aby otrzymywać więcej materiałów i poradników dotyczących zarządzania produktem, a także najnowsze podcasty, wywiady oraz inne spostrzeżenia liderów i ekspertów z branży.