อย่าบอกแค่ว่าขั้นตอนนี้ทำอะไร แต่บอกด้วยว่าจบขั้นตอนนี้จะต้องได้อะไร

วันนี้ผมมีโอกาสไปสอนคลาส Design Thinking ให้กับผู้เข้าร่วมโครงการหนึ่ง ซึ่งแน่นอนว่าการสอน Design Thinking ก็ค่อนข้างจะเป็นท่ามาตรฐานอยู่ว่าจะมีกี่ขั้นตอน บางที่ก็ 3 ขั้นตอน บ้างก็ 4 ขั้นตอน หรืออาจจะไป 6 ขั้นตอนอะไรก็แล้วแต่

จากนั้นก็จะเป็นการอธิบายว่าแต่ละขั้นตอนนั้ทำอะไรบ้าง เช่น Empathy คือการเข้าใจปัญหานะ Define คือการระบุปัญหานะ

แน่นอนว่าถ้าเล่ากันมาสเตป คนฟังก็จะพยักหน้างืม ๆ ว่าอ่อ ขั้นตอนนี้ทำแบบนี้นะ ขั้นตอนนี้ต้องทำอันนั้นนะ

แต่ระหว่างการบรรยายผมจะมีการหยุดนิดนึงเพื่อถามกลับผู้เรียนว่าแล้วจะรู้ได้อย่างไรว่าเราทำขั้นตอนนี้เสร็จแล้ว ?

สมมติเช่นถ้าเราอยู่ในขั้นตอน Empathy นั้น เราก็ไปพยายามเข้าใจปัญหาของลูกค้านะ ไปลองจำลองตัวเองเป็นลูกค้า ลองเล่าปัญหา บลา บลา บลา อะไรก็ว่ากันไป

แล้วจะรู้ได้ยังไงว่ามันเสร็จแล้ว ?

ตรงนี้เลยเป็นที่มาว่าเวลาจะทำอะไรที่เป็นขั้นตอนนั้น ไม่ใช่แค่การถามว่ามีกี่ขั้นตอน ขั้นตอนอะไรบ้าง แต่ละขั้นตอนทำอะไร แต่ต้องถามกันต่อไปด้วยว่าขั้นตอนนี้ต้องการอะไร ? ขั้นตอนนี้จะจบลงนั้นจะต้องได้อะไรออกมา (หรือน่าจะได้อะไรออก)

ตัวอย่างที่ผมใช้ในคลาสคือพอจบขั้นตอน Empathy นั้น คุณจะ "ยังไม่ได้" โซลูชั่นแก้ปัญหา แต่จะ "ต้องได้" กลุ่มปัญหาต่าง ๆ หรือความเดือดร้อนที่เกิดขึ้นกับกลุ่มเป้าหมาย กับสถานการณ์ กับบริบทดังกล่าว หรือในทางกลับกันคือถ้ายังไม่เจอกลุ่มปัญหานั้นก็อย่าเพิ่งหยุด ให้ทำจนกว่าจะได้หรือได้เป็นที่พอใจแล้ว (ซึ่งก็จะเป็นการไกด์ต่อไปว่าควรจะมีปริมาณประมาณเท่าใด)

เทคนิคนี้เรามักจะใช้เวลาสอนงานให้กับพนักงานใหม่ หรือคนที่เข้ามารับตำแหน่งใหม่เพื่อเป็นเหมือน Checkpoint ว่าขั้นตอนที่กำลังทำอยู่นั้นสำเร็จแล้ว (และบอกกลาย ๆ ว่าวถา้ยังไม่เกิดก็ถือว่ายังเสร็จนั่นเอง) ซึ่งนอกจากจะให้ผู้ทำงานรู้ตัวเองแล้ว ยังรู้ด้วยว่าเป้าหมายที่สำคัญของขั้นตอนนั้นคืออะไรบ้าง จะได้มีโฟกัสถูกจุด

ที่หยิบเรื่องนี้มาเล่าก็หวังว่าจะลองเอาไปประยุกต์ใช้เวลาอธิบายงานต่าง ๆ ให้กับทีมงาน หรือสอนผู้อื่นต่อนะครับ ไม่อย่างนั้นเราอาจจะเผลอคิดว่าเขารู้และเข้าใจแล้ว แต่เขาอาจจะไม่รู้ว่าเมื่อไรควรจะหยุด ควรจะพอ นั่นเองล่ะครับ