Shifting gears between design thinking, lean startup, and agile
การสับเปลี่ยนระหว่าง Design Thinking, Lean Startup และ Agile
แม้คำว่า “นวัตกรรม” จะฟังดูน่าตื่นเต้นเร้าใจ แต่งานหลักของเหล่าที่ปรึกษาให้กับผู้สร้างนวัตกรรม คือการลดความเสี่ยงในกระบวนการสร้างนวัตกรรม เพื่อให้สามารถดำเนินธุรกิจได้ อย่างมีประสิทธิภาพ ความเสี่ยงจำเป็นต้องถูกลดให้ต่ำมากที่สุดเท่าที่เป็นไปได้
ในงานของเรากับบริษัทระดับ Fortune 500 (อันดับบริษัท 500 แห่งในสหรัฐฯที่ถูกจัดอันดับโดยนิตยสารฟอร์จูน) เราจัดกระบวนการสร้างนวัตกรรมเป็น pipeline โดยหนึ่งในสิ่งที่ท้าทายมากที่สุดใน innovation pipeline คือการระบุว่าเครื่องมืออะไรที่ควรใช้ ใช้เมื่อไหร่ และเมื่อไหร่ที่ควรจะเปลี่ยนไปยัง phrase ต่อไป
The innovation pipeline
โดยทั่วไป Innovation Pipeline จะถูกแบ่งออกเป็น problem fit (ทางแก้ปัญหาของเราคือสิ่งที่ลูกค้าต้องการหรือไม่) solution fit (มีวิธีใดในการจะนำคุณค่ากลับคืนมาบ้าง) และ growth fit (นวัตกรรมที่ช่วยแก้ปัญหานั้นสามารถทำได้จริงและขยายตัวได้หรือไม่)
ก่อนอื่น คุณค้นหาปัญหาที่แท้จริง จากนั้นจึงค่อยเสนอแนวทางต่างในการแก้ปัญหานั้น หลังจากทำการตรวจสอบและยืนยันผ่านการทดลองต่างๆแล้ว คุณค่อยขยายตัว เครื่องมือและวิธีการต่างๆด้านล่างนั้นมักจะถูกใช้ร่วมกันใน innovation pipeline
Design thinking คือทัศนคติ (mindset) ที่ช่วยให้ทีมของคุณสามารถค้นหาข้อมูลเชิงลึกของลูกค้า ทั้งปัญหาและความต้องการของพวกเขา ด้วยวิธีคิดแบบมีระบบและการทำวิจัยเชิงคุณภาพ (Qualitative Research) ซึ่งทำให้สามารถกำหนดจุดเริ่มต้นของโครงการได้ นี่เป็น phrase ที่คุณจะถามตัวเองว่าคุณกำลังสร้างสิ่งที่ถูกต้องอยู่รึเปล่า
Lean Startup เป็นแนวคิดที่ช่วยให้ทีมของคุณสามารถลดความเสี่ยงได้มากยิ่งขึ้น ในขณะเดียวกันก็สามารถเรียนรู้ ตรวจสอบและยืนยันสมมติฐานหรือความเชื่อที่สำคัญด้วยวิธีการทางวิทยาศาสตร์
Business model innovation คือทัศนคติที่ช่วยให้ทีมของคุณพัฒนา prototype ที่มีคุณค่า แลกเปลี่ยนความคิดเห็บกับผู้ที่เกี่ยวข้อง (stakeholders) ไปพร้อมกับการระบุสมมติฐานหรือความเชื่อที่ชัดเจนเพื่อนำไปยืนยันในการทำซ้ำครั้งถัดไป
สุดท้าย คุณจะถามตัวเองว่าคุณกำลังสร้างอย่างถูกต้องรึเปล่า Agile development เป็นวิธีการพัฒนาด้วยการทำซ้ำทบกันไปเรื่อยๆ ซึ่งในแต่ละรอบของการทำซ้ำจะให้ลูกค้าได้ทดลองใช้ และนำผลตอบรับไปปรับปรุงหรือพิจารณาในรอบถัดไป ทำให้สามารถจัดการกับความเปลี่ยนแปลงที่มักเกิดขึ้นตลอดเวลาได้
การลดความเสี่ยงคือกุญแจสำคัญ
ในแต่ละ phrase ของการสร้างนวัตกรรมจะมีความเสี่ยงมากมายและหลากหลาย ทั้งความเสี่ยงของสิ่งที่เรารู้ ความเสี่ยงของสิ่งที่เราไม่รู้ และความเสี่ยงที่เราไม่ได้คิดถึง เครื่องมือและวิธีการต่างๆเช่น design thinking, lean startup, design sprints, prototypes, minimum viable product (MVP), business modeling และ agile development นั้นล้วนเป็นตัวช่วยลดความเสี่ยงลง
ซึ่งวิธีการที่กล่าวทั้งหมดนี้ล้วนเป็นเครื่องมือที่เรียบง่ายและเข้าถึงได้ในการจัดการความไม่แน่นอน มันช่วยลดช่องว่างระหว่างสิ่งที่เราคิดว่าเรารู้และสิ่งที่เรารู้จริง มันช่วยให้ข้อพิสูจน์และหลักฐานในการตัดสินใจ ทั้งยังทำให้เราได้เรียนรู้เพิ่มเติมในแต่ละ stage ของการสร้างนวัตกรรม เมื่อสิ่งที่เรารู้จริงมีเพิ่มขึ้น มันก็จะช่วยให้ทีมพบข้อผิดพลาดหรือจุดที่ควรปรับปรุงได้เร็วมากยิ่งขึ้น
อย่างไรก็ตาม สิ่งที่ท้าทายสำหรับองค์กรหรือทีมพัฒนาคือวิธีการใช้เครื่องมือเหล่านี้ให้เหมาะสม และเมื่อไหร่ที่ควรจะเปลี่ยนจากวิธีการหนึ่งไปยังอีกวิธี
เมื่อไหร่ที่ควรจะสับเปลี่ยนระหว่าง design thinking, lean startup, business modeling และ agile
เปรียบการทำงานไปทีละ phrase ของ innovation pipeline เป็นการขับรถ การรู้ว่าเกียร์อยู่ตรงไหน คันเร่งอยู่ตรงไหนนั้นไม่เพียงพอ เรายังต้องรู้ด้วยว่าเมื่อไหร่ที่ควรสับเปลี่ยนเกียร์ ซึ่งการจะรู้เรื่องนั้นได้ต้องใช้ประสบการณ์ แต่คุณไม่จำเป็นต้องเรียนรู้ด้วยตัวเอง คุณสามารถเรียนรู้ด้วยประสบการณ์ของคนอื่นได้ ข้างล่างนี้เป็นแนวทางปฎิบัติที่ถูกรวบรวมมาจากทีมสร้างนวัตกรรมทั่วทุกมุมโลก
เมื่ออยู่ใน design thinking phrase
-
ใครควรได้รับการฝึกฝนเป็นคนแรก?
ผู้นำ (Senior leadership) ควรเป็นคนแรกที่ฝึกฝนและเข้าใจ design thinking, lean startup, business modeling และการพัฒนาแบบ agile เพื่อที่พวกเขาจะได้เห็นคุณค่าและความสำคัญของเครื่องมือเหล่านี้ และนำไปสู่การเติบโตของธุรกิจ
-
เครื่องมือ หรือ วิธีการไหนที่คนในทีมควรเรียนรู้?
ผู้นำโปรเจคควรรู้ว่าการนำ design thinking, lean startup, business modeling และการพัฒนาแบบ agile มาใช้จริงนั้นทำได้อย่างไร ไม่ว่าความรู้นั้นจะมาจากประสบการณ์ก่อนหน้าหรือเรียนรู้จากโค้ชคนอื่นๆ วิธีนี้จะช่วยป้องกันไม่ให้ทีมสับเปลี่ยนจากวิธีหนึงไปยังอีกวิธีหนึ่งโดยไม่มีจุดหมาย
-
เมื่อไหร่ที่ควรนำความรู้ทางเทคนิคเข้ามาเกี่ยวข้องใน design thinking?
ความรู้ทางเทคนิคควรเอามาใช้ระหว่าง phrase ของ design thinking, lean startup, และ business modeling ทีมฝ่ายเทคนิคควรจะฟังและคาดเดาเทคโนโลยีที่จำเป็นเมื่อถึงช่วง market fit ในอนาคตอย่างเงียบๆ โดยไม่ต้องเอ่ยถึงข้อจำกัดทางเทคนิค
-
ใครควรเป็นเจ้าของโปรเจค?
ทีมพัฒนาโปรเจคควรมี product owner เพียงคนเดียวตลอดทั้ง innovation pipeline ตั้งแต่ขั้นตอนการพัฒนาไปจนถึงขั้นตอนติดตั้ง/นำไปใช้ การทำแบบนี้จะช่วยป้องกันไม่ให้หมดกำลังใจ ทำให้การจัดการกับผู้มีส่วนได้ส่วนเสียได้ง่ายขึ้น รวมถึงมีคนที่รู้รายละเอียดทุกซอกทุกมุมของโปรเจค product owner ควรเป็นคนที่เข้าใจวิสัยทัศน์ กลุ่มลูกค้า ธุรกิจและผู้พัฒนาอย่างชัดเจน ในขณะดียวกันก็คอยช่วยประสานงาน และมีความรู้ในลักษณะตัว T ก็ยิ่งดี
-
เมื่อถึงช่วง agile development แล้ว product owner ควรเป็นคนเดิมหรือไม่
ผู้ที่เป็น product owner ในช่วง design thinking และ lean startup ควรเป็น product owner ต่อในช่วง agile development ด้วย เพื่อที่การพัฒนา product เป็นไปอย่างต่อเนื่องและมั่นคง
-
ควรจัดทีมอย่างไร
คนในทีมควรมีความหลากหลายที่สุดเท่าที่เป็นไปได้ อย่างเช่น ฝ่ายทรัพยากรบุคคล, เซลล์, ฝ่ายการตลาด, ฝ่ายเทคนิค, ฝ่ายการเงิน, ฝ่ายกฏหมาย เพื่อให้แน่ใจว่าจะมีคนที่จะช่วยมองจากหลายมุมมอง และทำให้เกิดความคิดสร้างสรรค์มากยิ่งขึ้น
เมื่ออยู่ใน lean startup phrase
-
ให้ความต้องการของผู้ใช้เป็นสิ่งสำคัญที่สุด
ทีมควรคิดตามลำดับนี้ (1).ความต้องการของผู้ใช้ (2).ความเป็นไปได้ในเชิง business model (3).แล้วค่อยเป็นความเป็นไปได้ในเชิงเทคนิค โดยทั่วไป ทีมมักคิดว่าจะพัฒนาทางแก้ที่คิดขึ้นมาอย่างไร หลังจากที่คุณแน่ใจแล้วว่าลูกค้าต้องการทางแก้ปัญหาที่เราจะนำเสนอแล้วจริงๆ คุณถึงค่อยคิดเรื่องวิธีในการสร้างสิ่งที่ช่วยแก้ปัญหานั้น เพราะมันจะไม่มีประโยชน์เลยถ้าคุณมานั่งทำการวิเคราะห์วิธีสร้างหรือทำ business case ทั้งๆที่ยังไม่มีอะไรมายืนยันว่าลูกค้าต้องการสิ่งที่คุณกำลังจะเสนอจริงๆ
-
เมื่อไหร่ที่ควรจะพัฒนาจาก MVP/prototype เป็นสินค้าจริงๆ
Prototype ควรถูกใช้ให้นานที่สุดเท่าที่เป็นไปได้ จนกว่า business model จะถูก prototype และทดสอบแล้วยิ่งดี นี่จะทำให้การพัฒนาจาก prototype เป็นสินค้าจริงเร็วและง่ายขึ้นโดยไม่ต้องเสียเวลาหรือทรัพยากรในการแก้ไขมาก
-
อย่าตกหลุมรักกับสิ่งที่คุณสร้าง
ทีมพัฒนาโปรเจคไม่ควรรัก solution ที่ตัวเองสร้างขึ้นมา เพราะมันจะนำไปสู่การลำเอียงและอคติได้ คนในทีมควรใช้วิจารณญาณในการตัดสินใจอย่างมีเหตุผล
-
ใครควรเป็นคนรับผิดชอบเมื่อล้มเหลวหรือเกิดข้อผิดพลาด?
Product owner และทีมควรเป็นผู้รับผิดชอบ “เมื่อ” ล้มเหลว ไม่ใช่ “ถ้า”ล้มเหลว ( อ่านตาม ล้มแล้วลุก ล้มให้บ่อย ล้มให้เร็วจะได้เรียนรู้และปรับปรุง ไม่เสียเวลา) คุณควรฉลองเมื่อล้มเหลว เพราะความล้มเหลวเหล่านั้นจะทำให้คุณได้เรียนรู้และพัฒนานวัตกรรมไปในทางที่ถูกต้อง
-
ควรทำการ validation จากผู้ใช้เพื่อวัดการว่ามัน scale หรือไม่
ควรใช้ Prototype หรือ MVP ในช่วงของการขยายธุรกิจเพื่อทำการทดสอบและตรวจสอบสมมติฐานเชิงปริมาณก่อนจะเข้าสู่ช่วงการทำและทดสอบ prototype ของ business model นี่จะทำให้การตรวจสอบและยืนยันสมมติฐานของคุณสามารถนำไปใช้เมื่อขยายตัวได้ เพราะคุณรู้ว่าข้อมูลใดที่คุณต้องการ
เมื่ออยู่ใน phrase ของ business model innovation
-
จัด workshop ให้ขนานกันไป
Design sprint และ business model innovation ควรทำไปคู่ขนานเพื่อป้องกันไม่ให้โครงการถูกถ่วงเวลา อย่างเช่น การรวบรวมข้อมูลและทรัพยากรในช่วงเริ่มต้นของ agile development ที่มักกินเวลา
-
เมื่อไหร่ที่ควรตรวจสอบความเป็นไปได้ในทางเทคนิค
ก่อนที่จะเปลี่ยนจาก design thinking, lean startup และ business modelling ควรพิจารณาความเป็นไปได้ทางเทคนิค แม้ว่านี่อาจเป็นเรื่องที่ยอมรับได้ยากสำหรับทีมพัฒนา แต่ว่ามันเป็นความจริงที่ การวิเคราะห์ความเป็นไปได้ทางเทคนิคจะไม่มีประโยชน์อะไรเลย ถ้าปัญหาของลูกค้า และ business case ยังไม่ได้ถูกตรวจสอบและยืนยันเสียก่อน
-
การถอยหลังกลับก็สำคัญพอๆกับไปข้างหน้า
ถ้าตรวจสอบแล้วว่าโปรเจคไม่สามารถเป็นไปได้ในทางเทคนิคก่อนที่จะรวบรวมทรัพยากรใน Agile Development ให้โครงการกลับเข้าสู่ช่วง “การวิเคราะห์สิ่งที่จะสร้าง” และ “การค้นหาปัญหา/ทางแก้” อีกครั้ง ในระยะเวลาจำกัดก่อนจะทำการเปลี่ยนแผนธุรกิจไป
-
ทำอย่างไรให้คนในทีมสามารถทำงานได้อย่างต่อเนื่อง
หากคาดการณ์ว่าจะมีการล่าช้าในอนาคต (อย่างเช่น การเปลี่ยนไปมาระหว่าง CAPEX/OPEX กระทันหัน) คนในทีมควร (1). ปรับปรุง minimum viable product (MVP) หรือ prototype อย่างง่าย โดยใช้เวลา 3 วันในการ design sprint เพื่อทำการตรวจสอบและยืนยันข้อมูลที่สำคัญจากลูกค้า (2). ทำ business model innovation เพิ่มเพื่อทดสอบสมมติฐานที่โดดเด่น
การปรับเปลี่ยนเข้าสู่ Agile phrase
-
ปรับเปลี่ยนเข้าสู่ agile development อย่างเหมาะสม
นักออกแบบและนักพัฒนาที่ช่วยกันสร้าง minimal viable product (MVP) หรือ prototype อย่างง่าย ควรจะกำหนดขั้นตอนการทำงานให้ชัดเจนโดยใช้เครื่องมือ เช่น Sketch, Invision, Zeplin, Marvel, Supernova และอื่นๆในการลดการเขียนโค้ดซ้ำซ้อนในภายหลัง เพราะว่าในปัจจุบัน โปรแกรมบางโปรแกรมก็สามารถบันทึกออกมาเป็นโค้ดที่สามารถใช้จริง ดังนั้นทำให้แน่ใจว่าคุณระบุขั้นตอนและเครื่องมือการทำ MVP ให้ชัดเจนตั้งแต่เริ่มต้น
บทความแปลจากเว็บไซต์: https://www.boardofinnovation.com/blog/shifting-gear-between-design-thinking-lean-startup-agile/
Complete Web & App Design Course – UX, UI and Design Thinking With Big Data Bootcamp
เรียนรู้ หัวใจหลักสำคัญของการทำ Product ด้วย UX และ UI
การออกแบบโดยใช้ Concept ของ Design Thinking
นำข้อมูลที่ได้มาพัฒนา Product อย่างสม่ำเสมอ โดยใช้ Concept ของ Big Data
รายละเอียดเพิ่มเติมและสมัครที่นี่
หลักสูตรยาว 12 ครั้ง รวมเวลากว่า 72 ชั่วโมง จบมาทำงานได้จริง
ราคาคุ้มค่าที่สุด ตอนนี้มี promotion มา 2 คนลดเพิ่ม 10% 3 คนลดเพิ่ม 15%
สามารถขอ code ส่วนลดได้ที่ page LEAN upskill