W świecie, w którym funkcję można zaprojektować, zaprogramować i wdrożyć szybciej niż kiedykolwiek, największym problemem przestaje być tempo tworzenia. Problemem staje się decyzja, co właściwie warto stworzyć.
Jest taki moment w życiu niemal każdego rozwijanego systemu, kiedy lista funkcji zaczyna żyć własnym życiem.
"Klient o to pytał."
"Konkurencja ma."
"To chyba nie powinno być trudne."
"Skoro już mamy ten moduł, dodajmy jeszcze..."
"AI zrobi to szybko."
I nagle kolejna funkcja trafia do backlogu. Potem kolejna. I następna. Po kilku latach firma ma aplikację, która potrafi niemal wszystko. Tylko że użytkownik coraz trudniej może znaleźć to, czego faktycznie potrzebuje.
To nie jest wyłącznie problem UX. To problem biznesowy.
Kiedy więcej funkcji przestaje oznaczać lepszy produkt
Przez lata rozwój oprogramowania miał dość prostą logikę: jeżeli użytkownicy potrzebują nowych możliwości, dodajemy nowe funkcje. Brzmi rozsądnie.
Problem zaczyna się wtedy, gdy rozwój produktu zostaje sprowadzony do liczby dostarczonych funkcji. Wtedy zespół zaczyna optymalizować nie pod kątem wartości dla użytkownika, ale pod kątem liczby rzeczy, które udało się "dowiezć".
Powstaje tak zwana Feature Factory - organizacja, która produkuje kolejne funkcjonalności, ale niekoniecznie mierzy, czy rzeczywiście rozwiązują one problemy klientów.
To zjawisko nie jest nowe. Nowe jest tempo, w jakim może się dzisiaj rozwijać.
AI znacząco skraca drogę od pomysłu do działającego prototypu. Atlassian opisuje zmianę wprost: wraz z agentami programistycznymi droga od "wiemy, co chcemy zbudować" do działającego prototypu może skrócić się z tygodni do godzin.
To ogromna szansa. Ale również pułapka.
Bo jeżeli budowanie staje się tańsze i szybsze, łatwiej zacząć budować rzeczy, których wcześniej nikt nie odważyłby się zamówić.
"Skoro możemy, to zróbmy"
To jedno z najdroższych zdań w projektach IT. Nie dlatego, że każda dodatkowa funkcja kosztuje fortunę. Problem polega na tym, że funkcja nigdy nie kończy swojego życia w momencie wdrożenia.
Każdy nowy moduł trzeba później utrzymywać. Trzeba go testować. Trzeba uwzględniać go przy kolejnych zmianach. Trzeba dokumentować jego działanie. Trzeba obsługiwać błędy. Trzeba szkolić użytkowników. Trzeba uwzględniać go w UX. Trzeba pilnować jego bezpieczeństwa. Trzeba sprawdzać, czy kolejne zmiany w systemie czegoś nie zepsują.
Dlatego koszt funkcji to nie tylko koszt jej stworzenia. To również koszt jej przyszłego istnienia.
I właśnie tego kosztu bardzo często nie widać w momencie, kiedy ktoś mówi:
"To może jeszcze dodajmy..."
Najdroższa funkcja może być tą, której nikt nie używa
Wyobraźmy sobie firmę, która rozwija panel B2B.
Klienci mogą składać zamówienia, sprawdzać historię zakupów, pobierać dokumenty i kontaktować się z opiekunem.
Pojawia się pomysł na rozbudowany system raportowania. Zespół go projektuje. Developerzy budują. Powstają wykresy, filtry, eksporty, zestawienia i kilkanaście dodatkowych parametrów. Funkcja trafia na produkcję.
I wtedy okazuje się, że większość klientów chce po prostu wiedzieć: ile kupiłem, co jest w drodze i jaka jest cena.
Cała reszta była założeniem. Nie potrzebą. To bardzo ważna różnica.
Klient może poprosić o funkcję. Nie oznacza to jeszcze, że rozwiązaniem jego problemu jest ta funkcja.
"Konkurencja to ma"
To drugi klasyk.
Firma analizuje konkurencję. Widzi nowy moduł.
I zaczyna się: "Musimy też to mieć."
Tylko że konkurencja może mieć zupełnie inny model biznesowy, inną grupę klientów, inne procesy sprzedaży i inną strategię produktu.
Funkcja, która ma sens w jednym systemie, może być kompletnie niepotrzebna w drugim.
To szczególnie ważne w projektach tworzonych na zamówienie. Nie istnieje uniwersalny zestaw funkcji, który sprawi, że każda aplikacja będzie dobra.
System dla producenta przemysłowego nie powinien być projektowany tak samo jak platforma dla firmy szkoleniowej.
CRM dla handlowców nie powinien działać tak samo jak panel B2B dla stałych klientów.
Sklep internetowy sprzedający produkty premium może potrzebować zupełnie innego doświadczenia zakupowego niż sklep, którego głównym argumentem jest cena.
Software powinien wynikać z modelu biznesowego, a nie z katalogu funkcji konkurencji.
AI zmienia tutaj naprawdę dużo
I właśnie dlatego ten temat jest dziś szczególnie interesujący.
Jeszcze kilka lat temu pomysł na nową funkcję musiał przejść przez wiele etapów, zanim użytkownik mógł ją zobaczyć.
Analiza.
Projekt.
UX.
Development.
Testy.
Wdrożenie.
Dzisiaj część tych etapów może zostać znacząco przyspieszona przez AI. Możemy szybciej stworzyć prototyp. Szybciej przygotować interfejs. Szybciej napisać kod. Szybciej wygenerować testy. Szybciej przeanalizować dane.
I właśnie dlatego sama szybkość developmentu przestaje być wystarczającą przewagą.
Jeżeli każdy może szybciej coś zbudować, przewagę zaczyna mieć ten, kto lepiej wybiera, co budować.
Atlassian w swoim opracowaniu dotyczącym przyszłości product managementu zwraca uwagę na ten paradoks: AI zwiększa tempo pracy, ale samo zwiększenie tempa nie oznacza jeszcze lepszych produktów. Jednocześnie 89% badanych przez Atlassian przedstawicieli kadry zarządzającej deklarowało wzrost szybkości pracy dzięki AI, podczas gdy tylko 6% czuło się pewnie w określaniu konkretnego ROI AI w skali całej organizacji.
To bardzo dobrze pokazuje różnicę między robieniem szybciej a osiąganiem lepszego wyniku.
Najpierw problem. Dopiero później funkcja
Dobry proces produktowy powinien zaczynać się od pytania: Jaki problem próbujemy rozwiązać?
Nie: "Jaką funkcję mamy dodać?"
To niby niewielka różnica. W praktyce zmienia wszystko.
Jeżeli klient mówi: "Potrzebujemy aplikacji mobilnej",
warto zapytać: Dlaczego?
Może rzeczywiście potrzebuje aplikacji. Ale może problemem jest brak wygodnego dostępu do panelu na telefonie. Może wystarczy dobrze zaprojektowany interfejs responsywny. Może PWA. Może mobilny moduł jednego procesu. A może aplikacja jest potrzebna - ale zupełnie nie z powodów, które początkowo podał klient.
Tak samo działa to z funkcjami.
"Potrzebujemy automatycznych raportów." - Dlaczego?
"Bo handlowcy tracą czas." - Na czym?
"Na przepisywaniu danych z systemu."
I nagle okazuje się, że problemem nie jest brak raportu. Problemem jest brak integracji.
Dobra analiza potrafi oszczędzić miesiące developmentu.
Czasami najlepszą funkcją jest brak funkcji
To brzmi paradoksalnie, ale właśnie taka powinna być rola doświadczonego partnera technologicznego.
Nie tylko realizować. Także kwestionować założenia, kiedy jest ku temu powód.
Jeżeli klient przychodzi z listą dwudziestu funkcji, software house nie powinien automatycznie traktować jej jak specyfikacji technicznej wyrytej w kamieniu.
Powinien zapytać: Które z tych funkcji rozwiązują realny problem? Które są krytyczne? Które zwiększają sprzedaż? Które skracają pracę? Które poprawiają obsługę klienta? Które są wymagane prawnie lub operacyjnie? Które są tylko "fajnym dodatkiem"?
I przede wszystkim: po czym poznamy, że dana funkcja odniosła sukces?
Bez tego ostatniego pytania łatwo stworzyć produkt, który stale rośnie, ale nigdy nie wiadomo, czy rzeczywiście staje się lepszy.
Produkt powinien umieć powiedzieć "nie"
W dobrym product developmentzie równie ważna jak lista rzeczy do zbudowania jest lista rzeczy, których nie budujemy. To wymaga odwagi.
Bo łatwo powiedzieć: "Tak, zrobimy."
Trudniej powiedzieć: "Na podstawie tego, co wiemy, nie widzimy jeszcze powodu, żeby za to płacić."
Jeszcze trudniej powiedzieć to klientowi, który właśnie przyszedł z gotowym pomysłem.
Ale właśnie wtedy zaczyna się partnerska współpraca.
Software house nie powinien być tylko zespołem, który zamienia polecenia na kod. Powinien pomagać klientowi podejmować decyzje technologiczne.
Czasami oznacza to zaprojektowanie funkcji.
Czasami uproszczenie jej.
Czasami zastąpienie jej innym rozwiązaniem.
A czasami całkowite zrezygnowanie z pomysłu.
Jak rozpoznać funkcję, której prawdopodobnie nie potrzebujesz?
Nie ma jednego magicznego testu, ale kilka pytań potrafi bardzo szybko ostudzić entuzjazm.
Kto konkretnie będzie z tego korzystał?
Jeżeli odpowiedź brzmi "wszyscy", warto doprecyzować.
Jaki problem rozwiązujemy?
Jeżeli odpowiedź brzmi "będzie wygodniej", problem prawdopodobnie wymaga dalszej analizy.
Jak często użytkownik będzie z tego korzystał?
Raz w roku? Raz w miesiącu? Codziennie?
Czy istnieje prostszy sposób rozwiązania tego samego problemu?
To pytanie jest szczególnie ważne.
Jak zmierzymy efekt?
Więcej sprzedaży? Mniej pracy? Krótszy proces? Mniej błędów? Większa retencja?
Co się stanie, jeśli tej funkcji nie zbudujemy?
Jeżeli odpowiedź brzmi "właściwie nic", być może właśnie znaleźliśmy funkcję, której nie trzeba budować.
Nie każda prośba użytkownika powinna trafiać do backlogu
To również ważna zmiana mentalna.
Feedback użytkowników jest bezcenny. Ale feedback nie jest automatyczną specyfikacją produktu.
Użytkownik mówi o swoim problemie przez pryzmat własnego doświadczenia.
Może powiedzieć: "Potrzebuję przycisku X."
Rolą zespołu produktowego nie jest bezrefleksyjne stworzenie przycisku X.
Rolą zespołu jest zrozumienie: dlaczego użytkownik go potrzebuje.
Dopiero wtedy można zdecydować, czy najlepszym rozwiązaniem rzeczywiście jest przycisk X.
Może być nim automatyzacja.
Może integracja.
Może zmiana procesu.
Może lepszy interfejs.
Może edukacja użytkownika.
A czasami rzeczywiście nowa funkcja.
To właśnie jest różnica między feature delivery a product development.
Dane też mogą powiedzieć: "usuńmy to"
Rozwój produktu nie powinien kończyć się na dodawaniu.
Trzeba również patrzeć na to, co już istnieje.
Które funkcje są używane?
Które są ignorowane?
Gdzie użytkownicy odpadają?
Które procesy zajmują najwięcej czasu?
Które elementy generują najwięcej zgłoszeń do supportu?
Które funkcje zwiększają konwersję?
A które tylko komplikują interfejs?
Czasami najlepszym projektem rozwojowym nie jest dodanie kolejnego modułu. Jest nim usunięcie trzech niepotrzebnych. To może poprawić UX bardziej niż kolejny miesiąc developmentu.
AI może pomóc również tutaj
Co ciekawe, AI nie musi służyć tylko do tworzenia funkcji.
Może pomagać również w analizie tego, czy funkcje mają sens.
Może analizować feedback użytkowników.
Grupować zgłoszenia.
Wykrywać powtarzające się problemy.
Analizować dane z supportu.
Podsumowywać rozmowy z klientami.
Pomagać zespołowi porównywać hipotezy.
Przygotowywać warianty rozwiązania.
Wspierać analizę zachowania użytkowników.
Czyli paradoksalnie najlepsze wykorzystanie AI w product development może czasami polegać nie na tym, że dzięki niej szybciej zbudujemy kolejną funkcję.
Tylko na tym, że szybciej odkryjemy, że nie powinniśmy jej budować.
Web24: najpierw pytamy "po co?"
Każdy projekt software'owy zaczyna się od potrzeby.
Czasami klient dokładnie wie, czego potrzebuje.
Czasami ma już gotową specyfikację.
Czasami przychodzi tylko z problemem: "Ten proces zajmuje nam trzy godziny dziennie."
I to jest bardzo dobry punkt wyjścia.
Bo wtedy możemy zastanowić się nie nad tym, jak zakodować wskazane rozwiązanie, ale jak najlepiej rozwiązać problem.
To właśnie odróżnia tworzenie dedykowanego oprogramowania od składania produktu z gotowych funkcji.
W Web24 nie chodzi o to, żeby każda aplikacja miała jak najwięcej możliwości.
Chodzi o to, żeby miała te możliwości, które rzeczywiście są potrzebne danemu biznesowi.
Dlatego dwa podobne systemy mogą wyglądać i działać zupełnie inaczej.
Bo różnią się procesy.
Różnią się użytkownicy.
Różnią się cele.
Różni się sposób sprzedaży.
Różni się sposób obsługi klienta.
I różni się problem, który oprogramowanie ma rozwiązać.
Najdroższy backlog to ten, którego nikt nie kwestionuje
W świecie AI możemy wejść w bardzo ciekawy etap rozwoju software'u.
Technologia będzie coraz lepiej odpowiadała na pytanie: "Jak to zbudować?"
A człowiek będzie musiał coraz lepiej odpowiadać na pytanie: "Czy w ogóle powinniśmy to budować?"
To może być jedna z najważniejszych zmian w tworzeniu oprogramowania.
Bo jeżeli koszt i czas wykonania kolejnej funkcji spadają, pokusa ich dodawania rośnie.
A razem z nią rośnie znaczenie Product Discovery, UX, analizy danych, rozmów z użytkownikami i strategicznego podejścia do rozwoju produktu. Gartner zwraca uwagę, że szybki rozwój produktów napędzany przez AI może prowadzić między innymi do problemów ze strategicznym dopasowaniem i wzrostu technical debt, jeżeli tempo technologiczne nie idzie w parze z zarządzaniem produktem.
Dlatego przyszłość nie należy wyłącznie do firm, które potrafią budować szybciej. Będzie należała również do tych, które potrafią lepiej wybierać, co budować.
Bo czasami najlepsza decyzja technologiczna nie brzmi: "Zróbmy jeszcze jedną funkcję."
Tylko: "Sprawdźmy najpierw, czy naprawdę jej potrzebujemy."
