waste lean marnowanie nadprodukcja

O marnowaniu #2 – Nadprodukcja – niepotrzebne funkcjonalności

Agile

Nie kusiło Cię czasem, aby zasugerować coś w stylu “dodajmy jeszcze tę funkcjonalność, może się przydać, a to tylko trochę roboty”? Mnie kusiło wiele razy i wiele razy coś podobnego słyszałem od innych. Prawie zawsze było to zwykłe marnotrawstwo.


Ten post to drugi post z serii, w której poruszam problem manortrawstwa (waste). Jeśli chcesz się dowiedzieć, czym ono jest przejdź do tej strony.


 

Niepotrzebne i niewłaściwe funkcjonalności

Często słyszę “dodajmy jeszcze to”, dorzućmy “trochę efektu wow”. Rzadko “ten ficzer jest zbędny, usuńmy go”.

Każda energia, funkcjonalność, usługa, kod, które tworzymy, a z których klient nie korzysta, to marnotrawstwo. Czemu? Pakujemy czas (pieniądze) w coś co nie będzie używane, zamiast w coś co będzie 😲 Proste, prawda?

Intencje towarzyszą nam najlepsze – chcemy, aby klienci byli zadowoleni, chcemy budować. Mówimy “dorobienie tego przycisku to niewielki wysiłek, a na pewno się przyda użytkownikom”. Jasne! Skąd to wiesz? Argumenty często okazują się bardzo słabe – brakuje danych, które popierają takie pomysły. Intuicja jest ważna, ale obiektywne dane są po prostu lepsze.

Skoro tak, to przydadzą nam się narzędzia analityczne, pozwalające badać zachowanie użytkowników na stronie. Ważne też będą opinie klientów – wiesz co oni w ogóle myślą o Twoim produkcie i jego poszczególnych elementach? Jeśli potrafimy z takich informacji korzystać, to dużo łatwiej podjąć mądrą decyzję. Wiemy jak naprawdę zrobić dobrze naszym użytkownikom 😎

Popracujmy trochę na przykładzie. Załóżmy, że wiesz już, że klientom jest potrzebna dana funkcjonalność – niech to będzie edytowanie postów, za pomocą edytora WYSIWYG. Jednak czy wiesz, w jaki sposób chcieliby edytować te posty? Czy potrzebne jest im pogrubienie i kursywa, zmienianie koloru fontów? Warto zacząć skromnie – edytor przygotować w wersji podstawowej, sprawdzić jak klienci z niego korzystają i następnie dodawać do niego kolejne funkcjonalności (np. kolorwanie tekstu, osadzanie wideo). Można podpiąć gotowe rozwiązanie (np. tinyMCE) i zobaczyć czy jest wystarczające, a jeśli będzie trzeba, to w kolejnym kroku pracować nad czymś autorskim lub rozwinięciem gotowca.

Lepiej opierać się na małych krokach, sprawdzaniu ich efektów i dopiero na tej podstawie, robieniu kolejnych. Stąd też sukcesy firm, które potrafią korzystać z idei typu MVP, prototypów, danych analitycznych. Zamiast robić ogromny projekt, zasilany przez intuicję, lepiej zrobić ich wiele, mniejszych, opartych na wiedzy.

Programiści też czasem przesadzają: z refaktoryzacją bazylion razy tego samego, robieniem na zapas funkcji itd. Dodanie paru linijek kodu, aby coś było reużywalnym komponentem, bo “może się przyda” ma w sobie potencjał do bycia marnotrawstwem. Każda linijka napisana tylko po to, aby było elegancko i na zapas, staje się potem integralną częścią kodu aplikacji i wymaga utrzymywania. Dodatkowo komplikuje to całość systemu, będąc potencjalnym źródłem błędów. Nie piszę tu o tym, aby robić brzydko. Jakość jest niezwykle istotna! Chodzi o to, aby szyć na miarę, a nie ”bo za rok mogę być grubszy”. Dostarczajmy to czego potrzeba, a nie +miliard dodatkowych, niepotrzebnych rzeczy.

 

Podsumowanie

Mam nadzieję, że rozumiesz, że warto zastanowić się następnym razem, gdy przyjdzie Ci do głowy pomysł dodania czegoś do Twojej aplikacji czy usługi, tak na wszelki wypadek, bo “może się przyda”. Być może się przyda, ale zdecydowanie warto najpierw to spróbować zweryfikować – czy na pewno tego potrzebują moi użytkownicy?


Podobne wpisy

Powiadomienia o nowych wpisach

Kolejne posty o marnotrawstwie (i nie tylko)

 

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *