Sześć mitów na temat rozwoju produktu

Większość menedżerów ds. rozwoju produktu zawsze zmaga się z problemem wprowadzania projektów na czas i w ramach budżetu. Nigdy nie mają wystarczająco dużo zasobów, aby wykonać pracę, a ich szefowie wymagają przewidywalnych harmonogramów i dostarczanych produktów. Tak więc menedżerowie naciskają na swoje zespoły, aby były bardziej oszczędne, aby pisały bardziej szczegółowe plany i aby zminimalizować odchylenia w harmonogramie i marnotrawstwo. Jednak takie podejście, które może się sprawdzać w przypadku nierentownych fabryk, może w rzeczywistości zaszkodzić działaniom związanym z rozwojem produktu.

Mimo że wiele firm traktuje rozwój produktu w taki sposób, jakby był podobny do produkcji, oba te procesy znacznie się od siebie różnią. W świecie produkcji przedmiotów fizycznych, zadania są powtarzalne, czynności są w miarę przewidywalne, a tworzone przedmioty mogą znajdować się tylko w jednym miejscu w danym czasie. W świecie rozwoju produktu wiele zadań jest unikalnych, wymagania projektowe stale się zmieniają, a produktem końcowym – częściowo dzięki powszechnemu zastosowaniu zaawansowanego projektowania i symulacji komputerowych oraz wbudowaniu oprogramowania w produkty fizyczne – jest informacja, która może znajdować się w wielu miejscach jednocześnie.

Niedocenianie tych krytycznych różnic doprowadziło do powstania kilku błędów, które osłabiają planowanie, realizację i ocenę projektów rozwoju produktu. Spędziliśmy razem ponad 50 lat badając i doradzając firmom w zakresie rozwoju produktów i spotkaliśmy się z tymi błędnymi przekonaniami – jak również z innymi, które pojawiają się z różnych powodów – w wielu branżach, w tym w branży półprzewodników, samochodów, elektroniki użytkowej, urządzeń medycznych, oprogramowania i usług finansowych. W tym artykule zdemaskujemy je i zaproponujemy sposoby na przezwyciężenie problemów, które stwarzają.

Fałsz 1: Wysokie wykorzystanie zasobów poprawi wydajność.

Zarówno w naszych badaniach, jak i w pracy konsultingowej zaobserwowaliśmy, że zdecydowana większość firm stara się w pełni wykorzystać swoje zasoby do rozwoju produktów. (Jeden z nas, Donald, dzięki ankietom przeprowadzonym na kursach dla kadry kierowniczej w Kalifornijskim Instytucie Technologii odkrył, że przeciętny menedżer ds. rozwoju produktu utrzymuje wykorzystanie mocy produkcyjnych na poziomie powyżej 98%). Logika wydaje się oczywista: projekty trwają dłużej, gdy ludzie nie pracują przez 100% czasu – a zatem organizacja zajmująca się rozwojem będzie szybsza i bardziej efektywna niż taka, która nie jest tak dobra w wykorzystywaniu swoich ludzi.

Ale w praktyce ta logika nie trzyma się kupy. Przekonaliśmy się, że szybkość, wydajność i jakość projektów nieuchronnie spada, gdy menedżerowie całkowicie zapełniają talerze swoich pracowników zajmujących się rozwojem produktów – niezależnie od tego, jak wykwalifikowani są ci menedżerowie. Wysokie wykorzystanie ma poważne negatywne skutki uboczne, których menedżerowie nie doceniają z trzech powodów:

Nie biorą w pełni pod uwagę wewnętrznej zmienności prac rozwojowych.

Wiele aspektów rozwoju produktu jest nieprzewidywalnych: kiedy pojawią się projekty, jakich indywidualnych zadań będą wymagać i ile czasu zajmie ich wykonanie pracownikom, którzy nigdy wcześniej nie mieli do czynienia z takimi zadaniami. Firmy jednak najlepiej znają powtarzalne procesy, takie jak produkcja i przetwarzanie transakcji, w których praca nie zmienia się zbytnio, a niespodzianki zdarzają się rzadko. Takie procesy zachowują się w sposób uporządkowany, gdy wzrasta wykorzystanie zasobów. Dodaj 5% więcej pracy, a jej wykonanie zajmie 5% więcej czasu.

Procesy o dużej zmienności zachowują się zupełnie inaczej. Wraz ze wzrostem wykorzystania zasobów, opóźnienia drastycznie się wydłużają. (Patrz rysunek „High Utilization Leads to Delays.”) Dodaj 5% więcej pracy, a jej ukończenie może zająć 100% więcej czasu. Jednak niewiele osób rozumie ten efekt. Z naszego doświadczenia z setkami zespołów zajmujących się rozwojem produktów wynika, że większość z nich była znacznie przeciążona. Aby ukończyć wszystkie projekty na czas i w ramach budżetu, niektóre organizacje, z którymi współpracowaliśmy, potrzebowałyby co najmniej 50% więcej zasobów niż posiadały.

Prawdą jest, że pewna zmienność jest wynikiem braku dyscypliny i że niektóre zadania związane z rozwojem produktu (takie jak projektowanie komponentów do prototypu samolotu lub przeprowadzanie badań klinicznych) obejmują bardziej powtarzalną pracę. Ale nawet jeśli część pracy jest przewidywalna, to w połączeniu z inną nieprzewidywalną pracą pojawiają się problemy z kolejkami.

Nie rozumieją jak kolejki wpływają na wyniki ekonomiczne.

Wysokie wykorzystanie zasobów nieuchronnie tworzy kolejki projektów. Kiedy częściowo ukończone prace stoją bezczynnie, czekając na udostępnienie przepustowości, czas trwania całego projektu rośnie. Kolejki opóźniają również informację zwrotną, powodując, że programiści dłużej podążają bezproduktywnymi ścieżkami. Utrudniają one firmom dostosowanie się do zmieniających się potrzeb rynku i wykrycie słabych punktów w ich produktach, zanim będzie za późno. Jak na ironię, te problemy są dokładnie tymi, o których menedżerowie myślą, że wysokie wykorzystanie pozwoli ich zespołom uniknąć.

Nawet jeśli menedżerowie wiedzą, że tworzą kolejki, rzadko zdają sobie sprawę z kosztów ekonomicznych. Chociaż koszt ten można określić ilościowo, zauważyliśmy, że zdecydowana większość firm go nie oblicza. Menedżerowie muszą porównać koszty kolejek z kosztami niewykorzystanych mocy produkcyjnych, aby znaleźć właściwą równowagę.

W procesie rozwoju produktu, zapasy w toku produkcji są w większości niewidoczne.

Kolejki produkcyjne składają się z rzeczy fizycznych, a kiedy zapasy w fabryce podwajają się, jest to oczywiste. Inaczej jest w przypadku rozwoju produktu, gdzie zapasy w dużej mierze składają się z informacji, takich jak dokumentacja projektowa, procedury i wyniki testów oraz instrukcje budowy prototypów. Gdy zapasy podwajają się w procesie inżynieryjnym, nie ma żadnych fizycznych oznak. Ponadto, ponieważ standardy rachunkowości wymagają, aby większość zapasów R&D była wykazywana w wartości zerowej, sprawozdania finansowe nie wskazują na poważne nadwyżki zapasów w procesie rozwoju produktu.

Bardzo trudno jest walczyć z problemem, którego nie widać lub nie można zmierzyć. Rozważmy sytuację w jednej z dużych firm farmaceutycznych. Kilka lat temu jej nowo mianowany szef działu odkrywania leków stanął przed dylematem menedżerskim. Podobnie jak inni menedżerowie wyższego szczebla, którzy kierują dużymi organizacjami badawczo-rozwojowymi, starał się znaleźć sposób, aby jego naukowcy byli bardziej innowacyjni. Chciał, aby więcej eksperymentowali z nowymi związkami chemicznymi, które mogłyby generować obiecujące nowe leki, a jednocześnie, aby jak najwcześniej eliminowali mało obiecujących kandydatów. Eksperymenty z żywymi organizmami należały jednak do obowiązków działu badań na zwierzętach, który nie podlegał jego kontroli i był prowadzony jako centrum kosztów. Był oceniany na podstawie tego, jak efektywnie wykorzystywał zasoby badawcze, co naturalnie prowadziło do wysokiego stopnia ich wykorzystania. W konsekwencji, naukowcy zajmujący się odkrywaniem leków musieli czekać od trzech do czterech miesięcy na wyniki testów, których wykonanie zajmowało niewiele ponad tydzień. Dobrze zarządzana” organizacja testująca utrudniała postępy jednostki odkrywającej.

Oczywistym rozwiązaniem takich problemów jest zapewnienie bufora wydajności w procesach, które są wysoce zmienne. Niektóre firmy już dawno to zrozumiały. Przez dziesięciolecia firma 3M planowała programistów produktu na 85% ich możliwości. A Google słynie z „20% czasu” (pozwalając inżynierom pracować jeden dzień w tygodniu nad czymkolwiek chcą – praktyka ta oznacza, że dodatkowe moce przerobowe są dostępne, jeśli projekt spóźnia się z harmonogramem). Jednak z naszego doświadczenia wynika, że tego typu rozwiązanie jest dość trudne do wdrożenia. Jak wyjaśnimy, niewiele organizacji potrafi oprzeć się pokusie wykorzystania każdego skrawka dostępnego potencjału. Menedżerowie odruchowo rozpoczynają więcej pracy, gdy tylko widzą, że czas jest niewykorzystany.

Istnieją jednak inne realne rozwiązania:

Zmień systemy zarządzania i kontroli.

W przypadku firmy farmaceutycznej może to oznaczać podjęcie kroków mających na celu zrównanie celów jednostki zajmującej się badaniami na zwierzętach z celami jednostki zajmującej się odkryciami. Firma mogłaby, na przykład, nagradzać dział badań na zwierzętach za szybkie odpowiedzi (mierząc czas od zgłoszenia do zakończenia badania), a nie za wykorzystanie zasobów.

Wybiórcze zwiększanie wydajności.

Dodanie dodatkowych zasobów do obszarów, w których wskaźniki wykorzystania wynoszą 70% lub więcej, może znacząco skrócić czas oczekiwania. Jeśli firma farmaceutyczna zrobiłaby to w testach na zwierzętach, uzyskałaby informacje zwrotne na temat nowych związków chemicznych znacznie szybciej. W warunkach, w których testy przeprowadzane są z wykorzystaniem modelowania i symulacji komputerowej, zwiększenie wydajności jest często stosunkowo niedrogie, ponieważ wymaga jedynie zakupu dodatkowego sprzętu komputerowego i licencji na oprogramowanie.

Ograniczyć liczbę aktywnych projektów.

Jeżeli firma farmaceutyczna nie może zwiększyć wydajności testów na zwierzętach, wciąż może obniżyć wskaźnik wykorzystania poprzez redukcję liczby aktywnych projektów badających nowe związki chemiczne. Dyscyplina polegająca na nałożeniu twardego limitu na to, co trafia do linii rozwoju produktu, często skutkuje lepszym skupieniem uwagi i bardziej przejrzystymi priorytetami.

Ułatwienie wglądu w stan zapasów produkcji w toku.

Jedną z metod jest zastosowanie wizualnych tablic kontrolnych. Mogą one przybierać różne formy, ale kluczem jest posiadanie jakiegoś fizycznego symbolu, takiego jak karteczka Post-it, reprezentującego prace rozwojowe (patrz rysunek „Typowa tablica kontrolna procesu produkcyjnego”). Tablica kontrolna powinna przedstawiać wszystkie aktywne prace i pokazywać, w jakim stanie znajduje się każda część projektu. Powinna ona być w centrum procesu zarządzania zespołem. Zespoły mogą organizować 15-minutowe codzienne spotkania wokół takich tablic, aby koordynować wysiłki i utrzymać pracę w ruchu.

Fałsz 2: Przetwarzanie pracy w dużych partiach poprawia ekonomikę procesu rozwoju.

Drugą przyczyną kolejek w rozwoju produktu jest wielkość partii. Załóżmy, że nowy produkt składa się z 200 komponentów. Mógłbyś zdecydować się na zaprojektowanie i zbudowanie wszystkich 200 części, zanim przetestujesz którąkolwiek z nich. Gdybyś zamiast tego zaprojektował i zbudował tylko 20 komponentów przed rozpoczęciem testów, wielkość partii byłaby o 90% mniejsza. Miałoby to ogromny wpływ na czas oczekiwania w kolejce, ponieważ średnia kolejka w procesie jest wprost proporcjonalna do wielkości partii.

Zmniejszenie wielkości partii jest kluczową zasadą szczupłej produkcji. Małe partie pozwalają producentom ograniczyć pracę w procesie i przyspieszyć informacje zwrotne, co z kolei poprawia czas cyklu, jakość i wydajność. Małe partie mają jeszcze większe zastosowanie w rozwoju produktu, ale niewielu programistów zdaje sobie sprawę z mocy tej metody.

Jednym z powodów jest charakter ich przepływu pracy. Ponownie, ponieważ informacje, które produkują są w większości niewidoczne dla nich, rozmiary partii są również. Po drugie, programiści wydają się mieć nieodłączną skłonność do używania dużych partii – być może dlatego, że błędnie wierzą, iż duże partie dają korzyści skali.

W dobrze zarządzanym procesie, wielkość partii zbilansuje koszty transakcji i koszty utrzymania (patrz eksponat „Jak określić optymalną wielkość partii”). To jest podobne do kupowania jajek w sklepie spożywczym. Jeśli kupisz 12-miesięczny zapas podczas jednej wyprawy, Twój koszt transakcji jest niski, ale większość jajek się zepsuje, zwiększając Twój koszt utrzymania. Jeśli kupisz jednodniową dostawę za jednym razem, koszt zepsucia będzie niski, ale koszty transakcji będą wysokie. Intuicyjnie, starasz się znaleźć równowagę między tymi dwoma rzeczami.

Firmy, które rozumieją, jak to działa, wykorzystały postępy informatyczne do zmniejszenia wielkości partii, często z zadziwiającymi wynikami. Niektóre firmy produkujące oprogramowanie, które kiedyś testowały duże partie kodu co 90 dni, teraz testują znacznie mniejsze partie kilka razy dziennie. Producent komputerowych urządzeń peryferyjnych, który zastosował podobne podejście w swojej grupie zajmującej się oprogramowaniem, skrócił czas cyklu testowania oprogramowania o 95% (z 48 miesięcy do 2,5 miesiąca), poprawił wydajność o 220% i zmniejszył liczbę defektów o 33%. Oszczędności kosztowe były dwukrotnie wyższe niż firma oczekiwała. Chociaż te wyniki były wyjątkowe, przekonaliśmy się, że zmniejszenie wielkości partii znacznie poprawia większość projektów rozwojowych. Podobnie, skomputeryzowane narzędzia do modelowania i symulacji radykalnie obniżyły optymalną wielkość partii eksperymentów i testów w firmach, które opracowują produkty fizyczne.

Fałszywe myślenie 3: Nasz plan rozwoju jest świetny; musimy się go tylko trzymać.

W całej naszej pracy konsultingowej i badaniach nigdy nie natknęliśmy się na ani jeden projekt rozwoju produktu, którego wymagania pozostawały niezmienne przez cały proces projektowania. Mimo to wiele organizacji pokłada nadmierną wiarę w swoje plany. Wszelkie odchylenia przypisują złemu zarządzaniu i realizacji, a żeby je zminimalizować, starannie śledzą każdy krok w odniesieniu do celów pośrednich i kamieni milowych. Takie myślenie jest dobre dla wysoce powtarzalnych działań w ustalonych procesach produkcyjnych. Ale może prowadzić do słabych wyników w innowacjach produktowych, gdzie codziennie generowane są nowe spostrzeżenia, a warunki stale się zmieniają.

Klasyczne badania nad rozwiązywaniem problemów technicznych przeprowadzone przez Thomasa Allena z MIT podkreślają płynną naturę prac rozwojowych. Odkrył on, że inżynierowie, którzy opracowywali podsystem lotniczy, rozważali i oceniali wiele alternatywnych rozwiązań projektowych, zanim wybrali jedno, które uznali za najlepsze. Po drodze ich preferencje często się zmieniały, ponieważ testowali i udoskonalali konkurujące ze sobą rozwiązania techniczne. Jest to typowe w projektach innowacyjnych: Testowanie i eksperymentowanie ujawnia, co działa, a co nie, a początkowe założenia dotyczące kosztów i wartości mogą zostać obalone.

Zdefiniowanie potrzeb klientów może być trudne na początku projektu rozwoju produktu. Gdy się nad tym zastanowić, nie jest to zaskakujące: Klientom nie jest łatwo precyzyjnie określić swoje potrzeby w odniesieniu do rozwiązań, które jeszcze nie istnieją. W rzeczywistości, znajomość atrybutów istniejących produktów może przeszkadzać w wyrażaniu potrzeb związanych z nowym produktem. Preferencje klientów mogą się również gwałtownie zmieniać w trakcie realizacji projektu rozwojowego, w miarę jak konkurencja wprowadza nowe oferty i pojawiają się nowe trendy.

Z tych wszystkich powodów trzymanie się pierwotnego planu – niezależnie od tego, jak doskonała była jego koncepcja i jak umiejętnie został wykonany – może być receptą na katastrofę. Nie sugeruje to, że nie wierzymy w planowanie. Rozwój produktu to zestaw złożonych działań, które wymagają starannej koordynacji i dbałości o najmniejsze szczegóły. Plan należy jednak traktować jako wstępną hipotezę, która podlega ciągłej weryfikacji w miarę rozwoju wydarzeń, zmian założeń ekonomicznych i ponownej oceny możliwości. (Patrz „The Value Captor’s Process,” autorstwa Rity Gunther McGrath i Thomasa Keila, HBR maj 2007.)

Błąd nr 4: Im szybciej projekt zostanie rozpoczęty, tym szybciej zostanie ukończony.

Jak już mówiliśmy wcześniej, bezczynność jest anatemą dla menedżerów. Mają oni tendencję do wykorzystywania każdego przestoju poprzez rozpoczęcie nowego projektu. Nawet jeśli zadanie nie może zostać ukończone, ponieważ ludzie muszą wrócić do innego projektu, menedżerowie uważają, że wszystko, co zostało zrobione w nowym projekcie, to praca, której nie trzeba będzie wykonywać później. Takie myślenie prowadzi firmy do rozpoczynania większej liczby projektów, niż są w stanie energicznie realizować, rozcieńczając zasoby.

To rozcieńczanie jest niebezpieczne. Jeśli firma rozpoczyna projekt, zanim będzie miała środki na jego realizację, będzie się powoli potykać w procesie rozwoju. Jest to problematyczne, ponieważ prace nad rozwojem produktu są bardzo nietrwałe: Założenia dotyczące technologii i rynku mogą szybko stać się nieaktualne. Im wolniej projekt postępuje, tym większe prawdopodobieństwo, że trzeba będzie zmienić jego kierunek. W rzeczy samej, jedna z gałęzi wojska odkryła, że przekroczenia kosztów i harmonogramów są wykładniczo proporcjonalne (do czwartej potęgi) do czasu trwania projektu. Innymi słowy, gdy pierwotny harmonogram projektu podwoił się, koszty i przekroczenia harmonogramu wzrosły 16-krotnie.

Ważność zmniejszenia ilości pracy w toku jest oczywista, gdy spojrzymy na jeden z klasycznych wzorów teorii kolejek: Prawo Little’a. Stwierdza ono po prostu, że średnio czas cyklu jest proporcjonalny do wielkości kolejki podzielonej przez szybkość przetwarzania. Jeśli więc w Starbucksie w kolejce przed Tobą stoi 20 osób, a barista obsługuje pięć osób na minutę, zostaniesz obsłużony w ciągu czterech minut. Możesz skrócić czas cyklu poprzez zwiększenie szybkości przetwarzania lub zmniejszenie liczby zadań w toku. W większości ustawień to ostatnie jest jedynym praktycznym wyborem.

Dla niektórych twórców produktów rozwiązaniem jest rygorystyczna kontrola tempa, w jakim rozpoczynają pracę. Dopasowują je do tempa, w jakim praca jest faktycznie kończona; starannie zarządzają liczbą projektów w toku; upewniają się, że raz rozpoczęty projekt ma odpowiednią obsadę aż do jego ukończenia; i opierają się pokusie kradzieży zasobów z trwającego projektu, aby wcisnąć nowe.

Błąd nr 5: Im więcej funkcji umieścimy w produkcie, tym bardziej spodoba się on klientom.

Zespoły zajmujące się rozwojem produktów zdają się wierzyć, że dodawanie funkcji tworzy wartość dla klientów, a ich odejmowanie ją niszczy. Takie podejście wyjaśnia, dlaczego produkty są tak skomplikowane: Piloty zdalnego sterowania wydają się niemożliwe w użyciu, konfiguracja komputerów zajmuje godziny, samochody mają tak wiele przełączników i pokręteł, że przypominają kokpity samolotów, a nawet skromny toster jest teraz wyposażony w instrukcję obsługi i wyświetlacze LCD.

Przedsiębiorstwa, które kwestionują przekonanie, że więcej znaczy lepiej, tworzą produkty eleganckie w swojej prostocie. Bang & Olufsen, duński producent sprzętu audio, telewizorów i telefonów, rozumie, że klienci niekoniecznie chcą bawić się korektorem, balansem i innymi elementami sterującymi, aby znaleźć optymalną kombinację ustawień do słuchania muzyki. Głośniki klasy high-end automatycznie dokonują regulacji niezbędnych do odtworzenia utworu z możliwie największą wiernością oryginałowi. Jedyne, co pozostaje użytkownikom do wyboru, to głośność.

Przekonanie firm do przyjęcia i wdrożenia zasady, że mniej może oznaczać więcej, jest trudne, ponieważ wymaga dodatkowego wysiłku w dwóch obszarach rozwoju produktu:

Zdefiniowanie problemu.

Artykułowanie problemu, który programiści będą próbowali rozwiązać, jest najbardziej niedocenianą częścią procesu innowacji. Zbyt wiele firm poświęca jej zdecydowanie za mało czasu. Ale ta faza jest ważna, ponieważ to właśnie w niej zespoły rozwijają jasne zrozumienie swoich celów i generują hipotezy, które mogą być testowane i udoskonalane poprzez eksperymenty. Jakość opisu problemu czyni różnicę w zdolności zespołu do skupienia się na kilku cechach, które naprawdę mają znaczenie.

Gdy Walt Disney planował Disneyland, nie spieszył się, aby dodać więcej cech (przejażdżki, rodzaje jedzenia, ilość parkingów) niż miały inne parki rozrywki. Zaczął raczej od zadania dużo większego pytania: W jaki sposób Disneyland mógłby zapewnić odwiedzającym magiczne doświadczenie klienta? Oczywiście, odpowiedź nie przyszła z dnia na dzień; wymagała żmudnych, szczegółowych badań, ciągłych eksperymentów i głębokiego wglądu w to, co „magiczne” oznacza dla Disneya i jego klientów. IDEO i inne firmy mają dedykowane fazy, w których całkowicie zanurzają się w kontekście, w którym planowany produkt lub usługa będzie używana. Ich programiści czytają wszystko, co interesujące na temat rynków, obserwują i przeprowadzają wywiady z przyszłymi użytkownikami, badają oferty, które będą konkurować z nowym produktem, a następnie syntetyzują wszystko, czego się dowiedzieli, w postaci obrazów, modeli i diagramów. Rezultatem jest głęboki wgląd w klientów, który jest testowany, ulepszany lub porzucany w trakcie iteracyjnego procesu rozwoju.

Determinowanie, co ukryć lub pominąć.

Zespoły często mają pokusę popisywania się poprzez tworzenie genialnych rozwiązań technicznych, które zadziwiają ich rówieśników i kierownictwo. Ale często klienci woleliby produkt, który po prostu działa bez wysiłku. Z punktu widzenia klienta, najlepsze rozwiązania rozwiązują problem w najprostszy sposób i ukrywają pracę, z której programiści są tak dumni.

Jedną z firm, która to zrozumiała, jest Apple. Jest ona znana z wielu rzeczy – innowacyjnych produktów, stylowych projektów i błyskotliwego marketingu – ale być może jej największą siłą jest umiejętność dotarcia do sedna problemu. (Zobacz „Prawdziwe lekcje przywództwa Steve’a Jobsa”, autorstwa Waltera Isaacsona, w naszym kwietniowym wydaniu). Jak powiedział kiedyś Steve Jobs: „Kiedy zaczynasz przyglądać się problemowi i wydaje ci się on naprawdę prosty, nie rozumiesz jego złożoności. A twoje rozwiązania są zbyt uproszczone. Potem zagłębiasz się w problem i widzisz, że jest on naprawdę skomplikowany. I wymyślasz te wszystkie zagmatwane rozwiązania…. Na tym większość ludzi poprzestaje.” Ale nie Apple. Apple nie przestaje kombinować. „Naprawdę wspaniała osoba będzie kontynuowała swoją pracę”, powiedział Jobs, „i znajdzie… kluczową zasadę leżącą u podstaw problemu i wymyśli piękne, eleganckie rozwiązanie, które zadziała.”

Decydowanie o tym, które funkcje pominąć, jest równie ważne, a może nawet ważniejsze niż ustalenie, które z nich należy uwzględnić. Niestety, wiele firm, starając się być innowacyjnymi, wrzuca każdy możliwy dzwonek i gwizdek, nie biorąc w pełni pod uwagę ważnych czynników, takich jak wartość dla klientów i łatwość użytkowania. Kiedy takie firmy pomijają jakąś zaplanowaną funkcjonalność, to zazwyczaj dlatego, że muszą ciąć koszty lub nie dotrzymują terminów, albo dlatego, że zespół zawiódł w jakiś inny sposób.

Menedżerowie powinni natomiast skupić się na ustaleniu, czy usunięcie jakiejkolwiek proponowanej funkcji może ulepszyć dany produkt i pozwolić zespołowi skupić się na rzeczach, które naprawdę podnoszą ogólne doświadczenie klienta. Można to ustalić, traktując każde domniemane wymaganie jako hipotezę i testując ją w małych, szybkich eksperymentach z potencjalnymi klientami.

Zespoły programistów często zakładają, że ich produkty są skończone, kiedy nie można już dodać żadnych funkcji. Być może ich logika powinna być odwrotna: Produkty zbliżają się do doskonałości, gdy nie można już wyeliminować żadnych funkcji. Jak powiedział kiedyś Leonardo da Vinci, „Prostota jest ostatecznym wyrafinowaniem.”

Fałsz 6: Odniesiemy większy sukces, jeśli zrobimy to dobrze za pierwszym razem.

Wielu projektom rozwoju produktu nie udaje się osiągnąć celów związanych z budżetem, harmonogramem i wydajnością techniczną. Niewątpliwie słabe planowanie, sztywne procesy i słabe przywództwo odgrywają tu pewną rolę. Jednak inną, często pomijaną przyczyną są wymagania menedżerów, aby ich zespoły „zrobiły to dobrze za pierwszym razem”. Wymóg osiągnięcia sukcesu za pierwszym razem skłania zespoły do stosowania najmniej ryzykownych rozwiązań, nawet jeśli klienci nie uważają ich za zbytnie ulepszenie w stosunku do tego, co już jest dostępne. Co gorsza, zespoły mają niewielką motywację do poszukiwania innowacyjnych rozwiązań problemów klientów.

Aby uniknąć popełniania błędów, zespoły stosują liniowy proces, w którym każdy etap (określenie, zaprojektowanie, zbudowanie, przetestowanie, skalowanie, uruchomienie) jest dokładnie monitorowany na „bramkach” przeglądu. Praca nad kolejnym etapem nie może się rozpocząć, dopóki projekt nie przejdzie przez daną bramkę. W miarę jak projekt przesuwa się w dół linii, podejmowane są znaczące zobowiązania, a koszt reakcji na nowe spostrzeżenia wzrasta o rzędy wielkości. Udane testy na późnych etapach są celebrowane, a niespodzianki, niezależnie od tego, jak cenne, są uważane za niepowodzenia. Niestety, taki liniowy przebieg procesu może powodować przekroczenia projektów, ponieważ informacje zwrotne z testów są opóźnione, zespoły trzymają się złych pomysłów dłużej niż powinny, a problemy nie są odkrywane, dopóki ich rozwiązanie nie jest kosztowne.

Tolerancja na „popełnienie błędu za pierwszym razem” może być lepszą strategią, o ile ludzie dokonują iteracji szybko i często oraz szybko uczą się na swoich niepowodzeniach. Postępy w dziedzinie symulacji i technologii szybkiego prototypowania sprawiły, że działanie w ten sposób stało się znacznie łatwiejsze i tańsze.

Pomyślmy o tym, co znaleźliśmy w badaniu 391 zespołów, które projektowały niestandardowe układy scalone. Zespoły, które stosowały podejście iteracyjne i przeprowadzały wczesne i częste testy, popełniały po drodze więcej błędów. Ponieważ jednak korzystały z tanich technologii prototypowania, osiągały lepsze wyniki (pod względem czasu i wymaganego wysiłku) niż zespoły, które starały się uzyskać poprawny projekt za pierwszym razem. Zespoły, które miały do czynienia z wysokimi kosztami prototypowania, zainwestowały więcej wysiłku w specyfikację, rozwój i weryfikację. A ponieważ wykonywały one swoje iteracje w późniejszej fazie procesu – i robiły ich znacznie mniej – opóźniały odkrycie krytycznych problemów.

Eksperymentowanie z wieloma różnymi pomysłami jest kluczowe dla projektów innowacyjnych. Kiedy ludzie eksperymentują szybko i często, wiele nowatorskich koncepcji oczywiście się nie powiedzie. Ale takie wczesne porażki mogą być pożądane, ponieważ pozwalają zespołom szybko wyeliminować słabe opcje i skupić się na bardziej obiecujących alternatywach. Test zderzeniowy, który pokazuje, że projekt samochodu jest niebezpieczny, kandydat na lek, który okazuje się być toksyczny, lub interfejs użytkownika oprogramowania, który dezorientuje klientów, mogą być pożądanymi rezultatami – pod warunkiem, że wystąpią na wczesnym etapie procesu, kiedy niewiele zasobów zostało zaangażowanych, projekty są wciąż bardzo elastyczne i można wypróbować inne rozwiązania.

Klasycznym przykładem zalet podejścia „ponoś porażkę wcześnie, ponoś porażkę często” jest zaskakujące zwycięstwo drużyny Nowej Zelandii w Pucharze Ameryki w 1995 roku. Aby przetestować pomysły na ulepszenie konstrukcji stępki, zespół użył dwóch niemal identycznych łodzi: jednej łodzi, która została zmodyfikowana w trakcie trwania projektu i łodzi „kontrolnej”, która nie została zmodyfikowana. Każdego dnia zespół symulował hipotezy na lokalnej stacji graficznej, stosował te, które wydawały się obiecujące w jednej łodzi, ścigał się z łodzią kontrolną i analizował wyniki. Z kolei jego konkurent, zespół Dennisa Connera, który miał dostęp do potężniejszych komputerów (superkomputery w Boeingu), co kilka tygodni przeprowadzał duże partie symulacji, a następnie testował możliwe rozwiązania na jednej łodzi. Wynik: Team New Zealand wykonał o wiele więcej cykli uczenia się, szybciej wyeliminował nie rokujące pomysły i ostatecznie pokonał łódź Young America zespołu Dennisa Connera.

Co, mamy nadzieję, staje się już jasne, to fakt, że eksperymenty kończące się porażkami niekoniecznie są nieudanymi eksperymentami. Generują one nowe informacje, których innowator nie był w stanie przewidzieć. Im szybszy cykl eksperymentowania, tym więcej informacji zwrotnych można zebrać i włączyć do kolejnych rund eksperymentów z nowatorskimi i potencjalnie ryzykownymi pomysłami. W takim środowisku pracownicy mają tendencję do wytrwałości, gdy czasy stają się trudne, angażują się w bardziej wymagającą pracę i osiągają lepsze wyniki niż ich rówieśnicy unikający ryzyka.

Ale stworzenie takiego środowiska nie jest łatwe – temat ten poruszyła Amy C. Edmondson z Harvard Business School w artykule „Strategie uczenia się z porażek” (HBR kwiecień 2011). Porażka może prowadzić do zakłopotania i ujawnić luki w wiedzy, co może podważyć poczucie własnej wartości i pozycję jednostki w organizacji. W końcu, jak często menedżerowie są awansowani, a zespoły nagradzane za wczesne ujawnienie niepowodzeń, które prowadzą do zakończenia projektu – nawet jeśli wczesne przesunięcie cennych zasobów przynosi firmie korzyści? Jest to szczególnie prawdziwe w organizacjach, które zbudowały środowisko „zerowej tolerancji dla niepowodzeń” lub „wolne od błędów” (Six Sigma).

Ten artykuł ukazał się również w:

Thomas Alva Edison rozumiał to wszystko. Zorganizował swoje słynne laboratoria wokół koncepcji szybkiego eksperymentowania, lokując warsztaty maszynowe do budowy modeli w pobliżu pomieszczeń, w których przeprowadzano eksperymenty, tak aby maszyniści mogli ściśle współpracować z badaczami. W laboratoriach znajdowały się biblioteki zawierające ogromną ilość woluminów, aby można było szybko znaleźć informacje, pobliskie magazyny z dużą ilością zapasów oraz zróżnicowana kadra rzemieślników, naukowców i inżynierów. Edison chciał mieć pewność, że gdy on lub jego ludzie wpadną na jakiś pomysł, będzie można go natychmiast przekształcić w działający model lub prototyp. „Prawdziwą miarą sukcesu jest liczba eksperymentów, które można zmieścić w 24 godzinach” – powiedział.

Postępy w technologii informacyjnej, takie jak wspomagane komputerowo projektowanie, modelowanie i symulacja, pozwoliły już firmom na poczynienie wielkich postępów w opracowywaniu lepszych produktów w krótszym czasie i po niższych kosztach. Wiele firm nie wykorzystało jednak w pełni potencjału tych narzędzi, ponieważ ich sposób myślenia o zarządzaniu nie ewoluował tak szybko jak technologia: Nadal podchodzą one do wysoce zmiennej, generującej informacje pracy, jaką jest rozwój produktu, w taki sposób, jakby była to produkcja. Wraz z postępem w dziedzinie informatyki możliwości usprawnienia procesu rozwoju produktu będą jeszcze większe. Ale wzrosną również zagrożenia dla firm, które nie dostrzegą, że rozwój produktów głęboko różni się od produkcji.