Sokan – érthető módon – nagyon zavarba jönnek, amikor innovációs módszer, keretrendszer vagy technikáról esik szó. Nagyon gyakoriak az ilyen kérdések, mint: „Mikor kell használni a Design Thinking -et?”, „Mi a célja a Design Sprint-nek?”, „A Lean Startup csak az induló vállalkozásoknak szól?”, „Hol használható az Agilis módszertan?”.
Kutatva az internetes forrásokban, hamar rájövünk, hogy az innovációs módszerek homályában mások is elvesznek. Gartner (mint sokan mások) megpróbálta elképzelni, hogy olyan módszerek, mint a Design Thinking, a Lean, a Design Sprint és az Agilitás szépen haladnak egymás után. Ezt általában színes, látványos, egymást átfedő körökkel szokták ábrázolni. Ez a megközelítés azonban pontatlan. A valóságban a módszertanok határai összemosódnak, mivel a sok hasonló technika között nagyon sok az átfedés.
Mivel a Design Thinking, a Lean, a Design Sprint és az Agilis technikák mind-mind hozzáadott értéket jelenthetnek az innovációs spektrumban, nem érdemes rangsorolni őket, sokkal inkább érdemes egy eszközcsomag részeinek tekinteni.
Az innovációs kezdeményezések tárháza nagyon széles spektrumot ölel fel, a probléma feltárásától, számos megoldási lehetőségen át, egészen az adott megoldás konkrét üzleti körülmények közötti fenntartható fejlesztéséig.
Sokan elfelejtik figyelembe venni az üzleti modell „érettségi” (előrehaladást jelző) tengelyét. A bevált és összehasonlítható termékek esetében az üzleti modellek többnyire kielégítően pontosak. A kezdő vállalkozásoknál vagy régebbi szervezeten belül teljesen újonnan induló innovációk esetében azonban az üzleti modellt kísérletekkel kell validálni.
Forrás: https://www.problem2value.com/blog/when-which-design-thinking-lean-design-sprint-agile.html
A tervezői gondolkodás kitűnő megoldás olyan helyzetben, amikor alaposan meg kell érteni a problématerületet, és azonosítani az első/kezdeti felhasználókat Double-diamond technika szerint, az elején (Research) azonosítunk egy megoldandó helyzetet (Problem), utána mindig tágítjuk a látáskörünket: minél szélesebb célcsoporttal beszélgessünk az erre vonatkozó igényeikről. Majd az összegyűjtött információt sűrítve, meghatározzuk a legfontosabb, legégetőbb problémákat és elvégzendő feladatokat (Problem Definition). Utána következik a Design fázis, amelynek az elején megpróbáljuk elképzelni az összes lehetséges megoldást, prototípusokat készíteni és tesztelni a legígéretesebb ötleteket. Az érkezett visszajelzés alapján, újra fókuszálva a látáskörünket csak a legjobb megoldásokra, érkezünk a második rombusz csúcsára, a Solution-höz. A Design Thinking elsősorban minőségi szempontokra összpontosít.
A kifejezés a felhasználónak értéket teremtő, minél kevesebb erőforrással, „sallangmentesen” végigvitt fejlesztést takarja.
Némi különbség a Design Thinking-hez képest az, hogy a vállalkozó gyakran már jól ismeri a problématerületet. A Lean azonban mindent feltételezésnek tekint, amíg meg nem erősítik, tehát még ez a jó helyzetismeret is csak hipotézis. A Lean általában azzal kezdődik, hogy a feltételezéseit egy szűkebb ügyfélközpontú körre határozza meg, rajtuk teszteli, majd a feltevéseket rangsorolja és érvényesíti a teljes termékre vonatkozó legmagasabb kockázat szerint. A feltételezések validálásának folyamata egy kísérlet felépítése, tesztelése, és tanulság levonása arról, hogy feltételezésünk vagy hipotézisünk továbbra is helytálló-e (építs, mérj és tanulj, hármas elv). A Lean a korai szakaszban minőségi rátekintést alkalmaz, de később arra ösztönöz, hogy működőképes mennyiségi adatokat határozzon meg annak mérésére, hogy a megoldás mennyire hatékonyan oldja meg a problémát, és hogy a növekedési stratégia jó úton halad-e. A „Get out of the building” (menj ki az épületből) kifejezést gyakran a Lean Startup-hoz társítják, de ugyanez a vevőközpontú megközelítés nyilvánvalóan számít a cikkben bemutatott összes módszertan esetében is.
A Google Venture stílusú Design Sprint módszer gyökerei valószínűleg a Lean UX könyvben leírt technikából származnak. A Design Sprint fő erőssége, hogy öt napos sprint során a csapat megoszthatja egymással az új ismereteket, ötleteket, prototípusokat és tesztelhet egy koncepciót. Tekintettel a rövid időtartamra, a Design Sprint csak a megoldás egy részére összpontosít, de kiváló módja annak, hogy nagyon gyorsan kiderüljön, hogy jó úton járunk, vagy sem.
Nem csak maga a probléma, a megoldás és a piaci feltételezések is bizonytalanok – a termékfejlesztés is az. Az agilis fejlesztés nagyszerű módja annak, hogy megbirkózzunk ezzel. Az agilis módszertan szerint, mivel sok a feltételezés és a bizonytalanság, nem szükséges előre meghatározni a termék minden részletét. Emiatt ez a keretrendszer kiváló módja annak, hogy építsünk-mérjünk-tanuljunk és validáljunk feltételezéseket, miközben először Minimum Viable Product (a leggyorsabban elkészíthető első üzemképes prototípus)-t hozunk létre. Meg kell határoznunk és érték alapon priorizálnunk kell a teendőlistát (Product Backlog) és rövid sprintekben kell dolgoznunk, amelyeknek a végén teszteljük a leszállított értéket.
Nincs egyértelmű szabály arra vonatkozóan, hogy melyik innovációs módszertan mikor, mennyi ideig, milyen körülmények között alkalmazható. A sok átfedés miatt nincs nyilvánvaló átadási pont sem. - Ez lehet az oka annak, hogy egyes szakemberek szerint érdemesebb módszertanról beszélni, mint egy-egy módszerről.
A legtöbb innovációs módszer igen nagy értéket képvisel, és a csapatnak kell eldöntenie, hogy hol és mikor kezdje el az adott módszert vagy technikát alkalmazni. Nagyon fontos, hogy kerüljük a kedvenc módszerünkhöz való ragaszkodást, így biztosítva a közös megegyezést. Ne felejtsünk el folyamatosan figyelni a felhasználók visszajelzéseire is, szükség szerint átalakítva a munkafolyamatot (retrospektív).
Az eredeti cikk írója, Geert Claes, innovációval foglalkozik, több projektben dolgoztunk már korábban együtt, Design Sprint-eket is vezettünk közösen és körülbelül négy éve posztolta a forrásként felhasznált cikket. Azóta több nyelvre lett lefordítva és mi is rendszeresen használjuk a vizualizációját magyarázatra. A tevékenységéről az alábbi linken lehet többet olvasni.
Forrás: https://www.problem2value.com/blog/when-which-design-thinking-lean-design-sprint-agile.html
Szerző: Danka Zsuzsa
