Nieporozumienia i błędy związane z rozwojem produktów są dość uniwersalne – problemy znane z branży cyfrowej występują również w inżynierii kosmicznej i branży farmaceutycznej. Świetnie omawiają to autorzy artykułu „Six Myths Of Product Development” opublikowanego w Harvard Business Review. Jakie są ich wnioski?
- Prace rozwojowe warto dzielić na małe części, realizowane w krótkich cyklach. Dzięki temu łatwiej weryfikować tezy projektowe i reagować w razie niepowodzenia. Po latach porażek z wielkimi projektami wydaje się dziwne jak rzadko się tak robi.
- Zmiana planu to rzecz nieunikniona i dobra. A nawet: w rozwoju nie da się nic dokładnie zaplanować i wszystkiego przewidzieć. Wybór rozwiązania ustala się dzięki testom i na początku procesu nie można określić, które powinno być wdrożone i ile to zajmie. Autorzy piszą, że w całej swojej historii nie spotkali produktu, co do którego wymagania nie zmieniły się w procesie projektowania.
Dlatego planowanie to zgadywanie (jeden z podrozdziałów „Rework” ma taki tytuł). Plany warto mieć, ale ze świadomością, że oparte są na fałszywych przesłankach i trzymanie się ich może być przepisem na porażkę. - To, że projekt zaczynamy wcześniej, nie oznacza, że wcześniej go skończymy. To ma bezpośredni związek z dostępnością zasobów. Rzecz dotyczy raczej większych organizacji – takich, w których ludzie nie pracują stale nad jednym produktem, tylko realizują różne projekty. Jedna z zasad kanbana mówi, że należy kontrolować ilość prac w toku. Ważna reguła w prowadzeniu projektów natomiast „nie zaczynaj, dopóki nie masz wszystkich zasobów”. Zamiast dbać o to, by projekty ruszały „tak szybko jak się da”, lepiej troszczyć się o to, by całkowity czas trwania – od pierwszego spotkania zespołu do zakończenia poprawek – się skracał.
- Liczba funkcji nie przekłada się na jakość produktu. Dla zainteresowanych projektowaniem to nic nowego. Dobre produkty robią kluczowe rzeczy bardzo dobrze. Jeden z głównych powodów: mniejsza liczba funkcji pozwala skupić się zespołom na najważniejszych.
- Sukces rzadko oznacza powodzenie przy pierwszej próbie. Lepiej się pomylić i szybko wyciągnąć wnioski. Przeważnie paraliżuje nas lęk przed porażką. Sięgamy po bezpieczne rozwiązania, które niczego nie zmieniają i nie tworzą wartości.
Polecam lekturę. Artykuł można znaleźć nie tylko na stronach HBR.
Generalizując wnioski: budując organizację, która zajmuje się rozwojem lepiej skupić się na tworzeniu zespołów, które sprawnie eksperymentują i zdolne są do zwrotów, szybkiego wyciągania wniosków i porzucania błędnych tropów. Ważniejsza jest gospodarka odpadami niż tworzenie ambitnych, fikcyjnych planów. Ważniejsza jest realizacja niż pomysły z powerpointa.
Najciekawszy wątek artykułu to jednak teza, że w takiej organizacji dążenie do pełnego wykorzystania zasobów jest błędem. O tym jednak w następnym wpisie.