1 EventStorming มีลกั ษณะอย่างไร? - 85%
คุณอาจเคยได้ยินเกียวกับ EventStorming ซึงเป็ นเวิรก์ ช็อปทีดูแปลกตาและมีการใช้กระดาษโน้ตสีสม้ จํานวนมาก คุณ
อาจเคยลองทํามันกับเพือนร่วมงานในบริษัทของคุณ และบางทีคณ
ุ อาจกําลังอ่านหนังสือเล่มนีเพือหาคําแนะนําเกียวกับวิธีทีดี
ทีสุดในการจัดเวิรก์ ช็อป EventStorming
ุ ผิดหวัง: ไม่มี "วิธีทีดีทีสุด"
แต่เพิงจะถึงย่อหน้าทีสอง และฉันก็ตอ้ งขอโทษทีทําให้คณ
ในความเป็ นจริง มีหลายวิธีทีแตกต่างกันในการจัด EventStorming ซึงมีวตั ถุประสงค์และกฎเกณฑ์ทีต่างกัน แต่กย็ งั มี
บางสิงทีเหมือนกัน
ในทีนี คุณจะได้ลองสัมผัสถึงสิงทีคุณอาจคาดหวังได้ ผ่านเรืองราว EventStorming สีเรืองทีแตกต่างกัน
การท้าทายกระบวนการในองค์กร
บริษัทขนาดกลางกําลังเผชิญกับปั ญหาการเติบโตทีพบได้ทวไป:
ั
โครงสร้างพืนฐานด้านไอทีทีเคยเป็ นจุดเด่นในช่วง
เริมต้น กลับค่อย ๆ กลายเป็ นภาระ ทําให้การดําเนินงานประจําวันเป็ นเรืองยุง่ ยาก และในทีสุดก็ทาํ ให้ตวั เลือกการเติบโตเชิงกล
ยุทธ์บางอย่างไม่สามารถทําได้
ฉันได้รบั เชิญให้เข้ามาประเมินภาพรวมในระดับกว้างของสถานการณ์ในปั จจุบนั เพือเน้นถึงการดําเนินการสําคัญถัดไป
ไม่มีสงที
ิ ชาญฉลาดใด ๆ ทีจะเกิดขึนจากสถานการณ์นีได้เลย แต่...กรุณานังลงเถอะ!
พวกเราเข้าควบคุมห้องก่อนทีผูเ้ ข้าร่วมจะมาถึงประมาณ 30 นาที เพือปรับพืนทีให้เป็ นประโยชน์ต่อเรา เราดันเก้าอี
ทังหมดไปทีมุมห้องและย้ายโต๊ะไปด้านข้าง (มันเป็ นหนึงในโต๊ะประชุมขนาดใหญ่ทีทําให้คณ
ุ สงสัยว่า "พวกเขาเอาเข้ามาได้
ยังไง?") แล้วเราก็ตดิ กระดาษม้วนจากเครืองพล็อตเตอร์ยาวประมาณ 8-9 เมตรลงบนผนังหลัก จากนันฉันก็หยิบปากกามาร์ค
เกอร์สีดาํ หลายโหลออกมาจากกระเป๋ า พร้อมกับกองกระดาษโน้ตสีสม้ จํานวนมาก
การจัดห้อง ก่อนเริมเวิร์กช็อป
ในทีสุด ผูเ้ ข้าร่วมซึงเป็ นตัวแทนจากแผนกต่าง ๆ ของบริษัท รวมถึงฝ่ ายไอที ก็เริมทยอยเข้ามา บางคนดูงงงวยกับการจัด
ห้องทีแปลกตา และพยายามหาทีนังอย่างสุดความสามารถ ส่วนบางคนยังไม่มา แต่พวกเราตัดสินใจเริมต้นก่อน
ฉันเปิ ดการประชุมด้วยการแนะนําสัน ๆ ว่า “เราขอให้พวกคุณเขียนเหตุการณ์สาํ คัญในโดเมนของคุณลงบนกระดาษ
โน้ตสีสม้ โดยใช้คาํ กริยาในรูปอดีตกาล แล้ววางเรียงตามเส้นเวลา”
เราตัดสินใจจํากัดขอบเขตเฉพาะในกระบวนการการหาลูกค้าใหม่ เพราะมันดูใหญ่พอสมควรเมือเทียบกับข้อจํากัดของ
เวลา (รวมทังหมด 2-3 ชัวโมง)
ทุกสิงทีคุณจําเป็ นต้องรู เ้ กียวกับ Domain Event เพือเริมต้น
ผูเ้ ข้าร่วมบางคนยังคงดูสบั สน แต่ส่วนใหญ่เริมเขียนกระดาษโน้ตของตัวเองและนําไปติดบนกระดาษม้วนทีผนัง ตัวช่วย
ละลายพฤติกรรมกําลังทํางานได้อย่างยอดเยียม โดยทําหน้าทีเป็ นตัวอย่างให้กบั เพือนร่วมงาน ซึงในไม่ชา้ ก็เริมเลียนแบบพวก
เขา ด้วยวิธีนี เราสามารถเข้าสู่สภาวะการทํางานแบบลืนไหลได้ในเวลาเพียงไม่กีนาที
ฉันเสนอความช่วยเหลือให้กบั คนทียังดูไม่คอ่ ยสบายใจ ตอบคําถาม หรือส่งปากกาให้ถา้ พวกเขาขาดมันไป ปรากฏว่า
ฉันเข้าใจผิดเกียวกับการไม่มีส่วนร่วมของพวกเขา: “ฉันเพิงเข้ามาทํางานได้สองสัปดาห์เอง ในทีสุดฉันก็เริมเข้าใจว่าบริษัทนีทํา
อะไร!” คนหนึงกระซิบ
กระบวนการทังหมดเริมมีความหมาย และในขณะทีเรากําลังรวมมุมมองทีแตกต่างกัน ผูค้ นก็หยุดไม่ได้ทีจะออกความ
คิดเห็นเกียวกับขันตอนทางธุรกิจบางอย่าง: “และนีคือจุดทีทุกอย่างพังทลาย!” หรือ “นีไม่เคยทํางานได้ตามทีคาดหวังเลย” หรือ
“มันใช้เวลานานมากกว่าจะทําขันตอนนีเสร็จ”
ข้อมูลเหล่านีมีความสําคัญมาก ดังนันฉันพยายามจดบันทึกสัญญาณเตือนทุกอย่างลงบนกระดาษโน้ตสีมว่ ง พร้อม
ตกแต่งด้วยเครืองหมายอัศเจรียข์ นาดใหญ่ จากนันนําไปวางใกล้กบั ขันตอนทีเกียวข้องในเวิรก์ โฟลว์ทีกําลังปรากฏออกมา
บันทึกคําเตือน การอภิปราย และข้อสงสัยระหว่างทาง
ตามทีเราคาดไว้ จํานวนประเด็นปั ญหาทีสําคัญมีอยู่ไม่นอ้ ย แต่การวางปัญหาเหล่านีไว้ใกล้กบั เหตุการณ์ทีเกียวข้อง
ช่วยบอกใบ้ว่าเราควรมุง่ ความสนใจไปทีใด
แม้แต่อารมณ์ของฉันก็เปลียนไปด้วย ตอนแรกฉันถามคําถามพืนฐานแบบมือใหม่มาก ๆ แต่ตอนนีฉันรูส้ กึ ว่าเรากําลัง
เข้าใกล้แก่นของปั ญหาอย่างรวดเร็ว
ทุกอย่างดูสมเหตุสมผลจากมุมมองทางธุรกิจ ยกเว้นขันตอนสองสามขันทีฉันยังไม่สามารถเข้าใจความหมายได้ โดเมน
นีมีขอ้ จํากัดด้านกฎระเบียบและขันตอนด้านระบบราชการทีเข้าใจยากอยู่มาก แต่ขนตอนเหล่
ั
านียังคงดูแปลกสําหรับสายตา
ใหม่ของฉัน
ขันตอนเหล่านีดูไม่เข้าท่า ปรากฏว่า ซอฟต์แวร์ภายในบริษัทกําลังบังคับให้เพิมขันตอนกระบวนการบางอย่าง เพือบังคับ
ความสอดคล้องในโครงสร้างข้อมูลภายใน ซึงทําให้ความซับซ้อนถูกผลักออกไปนอกซอฟต์แวร์โดยไม่เป็ นธรรมชาติ และทําให้
ผูใ้ ช้ตอ้ งทํากิจกรรมเพิมเติมนอกซอฟต์แวร์
เมือเราได้สาํ รวจและแสดงภาพกระบวนการในโลกแห่งความจริง ผลลัพธ์ทีออกมาดูไม่ราบรืนและมีแนวโน้มทีจะเกิด
ข้อผิดพลาด ผลลัพธ์ทน่ี าผิดหวังคือ กระบวนการนีกลับทําให้การหาลูกค้าใหม่ลา่ ช้า ซึงไม่ใช่การตัดสินใจทีชาญฉลาดในตลาด
ทีมีการแข่งขันสูง
โชคดีทีเราเชิญคนทีเหมาะสมมา: ผูม้ ีอาํ นาจตัดสินใจอยูใ่ นห้อง พวกเขาเสนอการปรับเปลียนกระบวนการทีมีอยู่ทนั ที
โดยการผ่อนคลายข้อกําหนดเกียวกับเอกสารบังคับ ความจริงแล้ว ข้อกําหนดทีใช้อยู่ในปัจจุบนั เข้มงวดเกินไป การกําจัด
ผลกระทบทีไม่ตงใจเหล่
ั
านีจึงเป็ นเรืองง่าย
เวลาของเรากําลังหมดลง เราจึงถามว่าตัวปัญหาทีเป็ นอุปสรรคทังหมดได้แสดงอยู่ในกระบวนการปั จจุบนั แล้วหรือยัง
(เราเพิมอีกสองสามจุด) จากนันเราขอให้ผเู้ ข้าร่วมจัดลําดับความสําคัญของปั ญหาเหล่านี พวกเขาแทบจะเห็นตรงกันทังหมด
ว่าควรมุง่ ไปทีปั ญหาใด ง่ายมาก
ดูเหมือนว่าเราจะได้ผชู ้ นะทีชัดเจน นีคือจุดทีเราต้องมุง่ เน้น
เรามีภารกิจแล้วตอนนี
ผลลัพธ์หลังเวิรก์ ช็อป
ในช่วงบ่าย ขันตอนถัดไปชัดเจน: เนืองจากเราได้เน้นให้เห็นถึงอุปสรรคหลักในกระบวนการ จึงไม่มีสิงใดสําคัญไปกว่า
การแก้ไขปั ญหานัน (หรืออย่างน้อยก็ลองพยายามแก้ไข)
การหาทางแก้ไขจะไม่งา่ ยเหมือนกับการชีปั ญหา และอุปสรรคนีเป็ นเพียงอาการทีมองเห็นได้ ไม่ใช่ตน้ เหตุทแท้
ี จริง แต่
การเลือกปั ญหาทีถูกต้องเพือแก้ไขเป็ นผลลัพธ์ทมีี คุณค่า และเราก็บรรลุสิงนีได้อย่างรวดเร็ว
มีความรูส้ กึ เร่งด่วนทีจะสร้างต้นแบบของทางแก้ ดังนัน หลังจากถ่ายรูปกระดาษม้วนเอาไว้ (เผือมีใครฉีกมันออก) ฉันก็
เริมทํางานในโมเดลทางเลือกสําหรับจุดสําคัญทีเลือกไว้ ร่วมกับสถาปนิกซอฟต์แวร์ โดยอิงจากโมเดลแยกกันสองแบบแทนทีจะ
เป็ นโมเดลเดียวทีมีความซับซ้อนเกินไป
เราจําเป็ นต้องมีตน้ แบบเพือแสดงให้เห็นถึงความเป็ นไปได้ของทางเลือกใหม่ อย่างไรก็ตาม เราก็ยอมรับว่ามันยังไม่
เพียงพอ: ตอนนีอุปสรรคส่วนใหญ่เป็ นเรืองการเมืองภายในองค์กร
แม้วา่ เราจะสร้างความเชือมโยงทีชัดเจนระหว่างอุปสรรคหลักในกระบวนการกับทางออกทีเป็ นไปได้ แต่การนํามันไปใช้
งานจริงไม่ใช่แค่ปัญหาด้านเทคนิค: ต้องได้รบั อนุญาต และบทบาทและความรับผิดชอบในองค์กรรอบ ๆ ขันตอนนันจําเป็ นต้อง
ถูกออกแบบใหม่เพือเอาชนะอุปสรรคปัจจุบนั
แม้วา่ ในตอนแรกเราจะสันนิษฐานว่าซอฟต์แวร์เป็ นส่วนทีสําคัญทีสุดของปัญหา แต่กลับกลายเป็ นว่าทางออกนันส่วน
ใหญ่เกียวข้องกับการเมือง และเมือเป็ นเรืองการเมือง การเปลียนแปลงมักใช้เวลานานกว่าทีคาดไว้ และไม่เคยเป็ นเส้นตรงหรือ
ชัดเจนแบบขาวดํา
การเริมต้นสร้างสตาร์ทอัพ
ผูก้ ่อตังสตาร์ทอัพสุดเจ๋งแห่งใหม่กาํ ลังจ้างบริษัทพัฒนาซอฟต์แวร์ทีเจ๋ง และเอเจนซี UX ทีเจ๋ง เพือช่วยพวกเขาสร้าง
ซอฟต์แวร์โครงหลักทีเจ๋งของพวกเขา
โมเดลธุรกิจนีใหม่สาํ หรับตลาด ในสมองของผูก้ ่อตัง ทุกอย่างชัดเจน พวกเขามีประสบการณ์อย่างมากในด้านการเงิน
ทีมพัฒนาเคยสัมผัสกับแนวคิด Domain-Driven Design มาแล้ว แต่สาํ หรับนักพัฒนา ซึงเป็ นคนทีต้องลงมือทําให้มนั เป็ นจริง
กลับไม่มีความรูเ้ กียวกับโดเมนนีมาก่อนเลย ยกเว้นประสบการณ์ในฐานะลูกค้าทีไม่ค่อยน่าจดจํานัก และทุกอย่างก็ดูใหญ่โตไป
หมด
ฉันได้รบั เชิญให้เข้าร่วมในฐานะผูช้ ่วยกระบวนการในเวิรก์ ช็อปการสํารวจ: เป้าหมายคือการช่วยให้ทีมพัฒนาเข้าใจและ
เรียนรูเ้ กียวกับโดเมนนีให้เร็วทีสุดเท่าทีจะเป็ นไปได้ นอกจากนี ผูก้ ่อตังทีมีความรูเ้ กียวกับโดเมนธุรกิจ ยังไม่ทราบถึงความเสียง
ทางเทคนิคทีซ่อนอยู่ในระดับการดําเนินการอีกด้วย
เนืองจากข้อกําหนดด้านการปฏิบตั ิตามกฎระเบียบทีจําเป็ นในโดเมนนี ทําให้ Minimum Viable Product (MVP)
ค่อนข้างใหญ่เมือเทียบกับสตาร์ทอัพในอุดมคติสไตล์ของ Eric Ries อย่างไรก็ตาม เราจะต้องควบคุมแนวโน้มตามธรรมชาติที
จะทําให้ MVP ขยายตัวมากเกินไป เพราะการเข้าสู่ตลาดให้เร็วทีสุดเป็ นสิงสําคัญอย่างยิง
วันแรก
เวลา 9 โมงเช้า มีคนแปดคนอยู่ในห้อง: มุมมองด้านธุรกิจ เทคโนโลยี และ UX ได้รบั การเป็ นตัวแทนครบถ้วน
ในขณะทีทุกคนกําลังแนะนําตัวกันและดืมกาแฟ ฉันเริมเตรียมอาวุธลับของฉัน: ฉันคลีกระดาษม้วนจากเครืองพล็อต
เตอร์ให้มากทีสุดเท่าทีจะทําได้แล้วติดมันกับผนัง จากนันหยิบกระดาษโน้ตสีสม้ หลายร้อยแผ่นออกมาจากกระเป๋ าและวางไว้
บนโต๊ะ พร้อมด้วยปากกามาร์คเกอร์สีดาํ จํานวนมากจนดูนา่ ขํา
บางคนรูจ้ กั EventStorming อยูแ่ ล้ว แต่สาํ หรับผูก้ ่อตังนัน พวกเขาไม่เคยรูจ้ กั แนวคิดนีมาก่อน อย่างไรก็ตาม พวกเขา
ชอบไอเดียนี การจัดเตรียมทีไม่ธรรมดาเช่นนีได้กระตุน้ ความอยากรูอ้ ยากเห็นอยู่แล้ว ดังนันฉันจึงไม่ตอ้ งใช้เวลามากในการ
อธิบายเวิรก์ ช็อป
ฉันขอให้ทกุ คนเขียน Domain Event ทีสําคัญในกระบวนการธุรกิจลงบนกระดาษโน้ตสีสม้ และวางเรียงตามลําดับเวลา
ในกระดาษม้วนบนผนัง
คําขอนีฟั งดูแปลกไปเล็กน้อย เพราะเราข้ามขันตอนการแนะนําตัวและการอธิบายไปเลย สิงทีเราต้องการจริง ๆ คือ
ตัวอย่าง: เมือ Domain Event แรกถูกวางลง ทุกคนก็เริมมันใจมากขึนว่า Domain Event ควรจะเป็ นอย่างไร
ต้องเริมต้นทีไหนสักแห่ง...
เราเข้าสู่สภาวะการทํางานแบบลืนไหลอย่างรวดเร็ว: เมือ Domain Event แรกถูกวางลงบนเส้นเวลา มันค่อนข้างชัดเจน
ว่ามีอะไรต้องเกิดขึนก่อนหน้าและอะไรเกิดขึนหลังจากนัน ดังนันทุกคนจึงเริมช่วยกันสร้างโมเดลนี
กระดาษโน้ตสีสม้ บางแผ่นถูกเขียนซํา น่าจะเป็ นเพราะบางคนมีไอเดียเดียวกันในเวลาเดียวกัน ส่วนบางแผ่นดูคล้ายกัน
แต่ใช้ถอ้ ยคําต่างกันเล็กน้อย เราเก็บมันไว้ทงหมดในตอนนี
ั
เพราะจะเลือกรูปแบบคําทีเหมาะสมทีสุดในภายหลัง เมือเรามี
ข้อมูลเพิมเติม
ฉันยังยําว่า “ไม่มคี าํ ตอบทีถูกต้องทีสุด” ความจริงแล้ว การพยายามหาถ้อยคําทีสมบูรณ์แบบจะทําให้เราช้าลง
มีบางกระดาษโน้ตทีไม่สอดคล้องกับคํานิยามของ Domain Event ทีฉันได้อธิบายไว้ เช่น มีบางสิงทีเป็ นเหมือน "เฟส"
แทนทีจะเป็ นกริยาในรูปอดีตกาล แต่ "เฟส" อาจซ่อนความซับซ้อนทีเราควรจะตรวจสอบไว้ ฉันจึงหมุนกระดาษโน้ตนัน 45 องศา
ทวนเข็มนาฬิกา เพือส่งสัญญาณว่ามีบางอย่างผิด โดยไม่ทาํ ลายจังหวะของการอภิปราย
นีไม่ใช่ Domain Event นีคือกระบวนการ…
ก่อนทีจะมีการอธิบายอย่างละเอียดจากผูเ้ ชียวชาญด้านโดเมน
ไม่มีการอธิบายขันตอนทีน่าเบือและคาดเดาได้งา่ ยในกระบวนการธุรกิจ แต่ทกุ ครังทีนักพัฒนาหลงทางจากเป้าหมาย
การสนทนาทีมีความหมายจะเกิดขึน เราไม่ได้พดู ถึงว่า “ผูใ้ ช้ตอ้ งเข้าสู่ระบบในระบบ” (น่าเบือ) แต่เราพูดถึงจุดทีมีสงใหม่
ิ ให้
เรียนรูม้ ากกว่า
มันเป็ นการค้นพบมากกว่าการแปล ด้วยวิธีนี ทําให้นกั พัฒนารูส้ กึ เหมือนกําลังเข้าไปสู่แก่นของปัญหาจริง ๆ
บทสนทนา บทสนทนา บทสนทนา
บางครังผูก้ ่อตังให้ขอ้ มูลเชิงลึกทียอดเยียมเกียวกับความซับซ้อนทีคาดไม่ถึงในโดเมน และพวกเรารับฟั งเหมือนนักเรียน
ในห้องเรียน จดบันทึก และพยายามจัดโครงสร้างความซับซ้อนทีเพิงเรียนรูใ้ นรูปแบบของ Domain Events เพิมคําศัพท์ที
แม่นยํายิงขึนลงในพจนานุกรม
เมือมีคาํ ศัพท์ใหม่ปรากฏขึน และการสนทนาแสดงให้เห็นว่าคําเหล่านันมีความหมายทีชัดเจนใน Context นัน ฉันเริม
บันทึกคําจํากัดความของคําสําคัญเหล่านีลงบนกระดาษโน้ตพิเศษ และวางไว้ใต้เส้นทางปกติของการทํางาน
เมือความแม่นยําปรากฏขึนจากคําพูดของผูเ้ ชียวชาญด้านโดเมน ควรรีบจดบันทึกไว้ทใดสั
ี กแห่ง...
มันจะไม่ใช่คาํ จํากัดความทีพร้อมลงใน Wikipedia: เป็ นเพียงความหมายทีชัดเจนของคําศัพท์นนในบริ
ั
บทของการ
สนทนาเฉพาะเจาะจงนี
บางครังความรูอ้ ยู่ในฝังเทคนิค: นักพัฒนาคนหนึงก้าวขึนมาอธิบายความซับซ้อนทีซ่อนอยูเ่ บืองหลังปั ญหาทีดูเหมือน
เรียบง่าย เราสามารถเห็นได้ว่าทังฝ่ ายธุรกิจและฝ่ ายเทคนิคเริมมีความเข้าใจลึกซึงขึนในทุก ๆ รอบ
การสนทนาแบบปลายเปิ ดเป็ นสิงทีฉันชอบทีสุด ในบางครัง ผูก้ อ่ ตังพูดอย่างตรงไปตรงมาว่า: “ผมไม่มีไอเดียเลย เรา
ต้องสํารวจสถานการณ์น”ี ฉันชอบมากทีได้ยินเช่นนัน ผูเ้ ชียวชาญด้านโดเมนทีซือสัตย์และยอมรับว่าพวกเขาไม่รูอ้ ะไรบางอย่าง
นันดีกว่าคนทีพยายามแสดงตัวเป็ นผูเ้ ชียวชาญ แต่ตอบคําถามแบบไม่รูอ้ ะไรเลยเป็ นล้านเท่า
ในขณะทีผูค้ นยังคงสํารวจส่วนต่าง ๆ ของโดเมน ฉันเริมจดบันทึกจุดสําคัญทังหมดลงบนกระดาษโน้ตสีม่วง จุดเหล่านี
อาจหมายถึงปั ญหา ความเสียง พืนทีทีต้องการการสํารวจเพิมเติม จุดตัดสินใจทีเรายังไม่มขี อ้ มูลเพียงพอ หรือส่วนของระบบที
มีขอ้ กําหนดสําคัญ
ในทีสุด เราเริมพูดถึงระบบภายนอก: สิงเหล่านีอาจเป็ นองค์กรหรือบริการภายนอก หรือแอปออนไลน์ ฉันเริมแทนทีด้วย
กระดาษโน้ตสีชมพูขนาดใหญ่เพือแสดงถึงระบบภายนอกทีซอฟต์แวร์ใหม่ของเราจะต้องจัดการ
แม้ว่าจะมีการพูดถึงอย่าง
ชัดเจนในขันตอนถัดไป แต่การมีตวั อย่างไว้ลว่ งหน้าจะทําให้ขนตอนต่
ั
อไปง่ายขึน
[FIXME: ภาพเล็ก ๆ ตรงนี]
ในระหว่างนี ฉันเริมติดป้ายกํากับพืนทีเฉพาะของกระบวนการทางธุรกิจ
เริมมองเห็นโมเดลทีเป็ นอิสระซึงสามารถพัฒนาได้อย่างอิสระ โดยมีวตั ถุประสงค์ทีแตกต่างกันและค่อนข้างชัดเจนใน
ระดับหนึง
ฉันไม่ได้คาดหวังความแม่นยําหรือการกําหนดขอบเขตทีชัดเจนในขันตอนนี เพียงแค่โครงสร้างบางอย่างทีเริมปรากฏขึน
ซึงเราจะปรับปรุงในภายหลัง
ปรากฏว่ามีโซลูชนั สําเร็จรูปบางตัวทีพร้อมใช้งานอยู่แล้วสําหรับบางส่วนของกระบวนการ: ไม่จาํ เป็ นต้องพัฒนาขึนมา
เองในบริษัท เว้นแต่วา่ เราจะต้องทําสิงทีแตกต่างอย่างชัดเจน
ใหญ่เกินกว่าจะใส่ในภาพเดียวได้ แต่ยงั คงจัดการได้อยู่.
เมือสินสุดวัน เราได้เติมเต็มกระดาษม้วนสําหรับการสร้างแบบจําลองกระบวนการไปถึง 18 เมตร ผนังเพียงด้านเดียวไม่
เพียงพอทีจะบรรจุทงหมด
ั
เราจึงใช้ผนังฝังตรงข้ามด้วย แม้ว่าจะมีบางพืนทีทียังต้องสํารวจเพิมเติม แต่ภาพรวมของ
กระบวนการดูมนคงดี
ั
หลังจากทีได้พจิ ารณาผลงานของเรา เราไปทานอาหารเย็นพร้อมความรูส้ กึ ว่าทํางานได้สาํ เร็จไปมาก
วันทีสอง
เราเริมเซสชันด้วยการตรวจสอบแบบจําลองทีเราทําไว้เมือวันก่อน กระดาษโน้ตบางแผ่นตอนนีดูเหมือนไม่ลกึ ซึงพอเมือ
เทียบกับระดับความเข้าใจใหม่ของเรา เราเขียนบางแผ่นใหม่ดว้ ยความแม่นยํามากขึน และลบเครืองหมายคําถามสีม่วงบางจุด
ทีเราได้ครอบคลุมในเซสชันของเมือวานออกไป
ถึงเวลาเจาะลึกเกียวกับกลไกของส่วนประกอบหลักของระบบ: เราจะเริมนําความเข้มงวดมากขึนในกระบวนการของเรา
โดยการแนะนําคําสัง (Commands) ซึงแทนความตังใจ/การกระทํา/การตัดสินใจของผูใ้ ช้ (คําสังเหล่านีเป็ นกระดาษโน้ตสีฟา้ ที
เราเขียนสิงต่าง ๆ เช่น สังซือ (Place Order) หรือ ส่งคําเชิญ (Send Invitation)) และผูก้ ระทํา (Actors) (กระดาษโน้ตสีเหลือง
เล็ก ๆ) สําหรับหมวดหมู่ผใู้ ช้เฉพาะกลุ่ม.
การเพิมกระดาษโน้ตสีเหลืองเล็ก ๆ สามารถสร้างความแตกต่างได้ โดยเปลียนโฟกัสไปทีปฏิสมั พันธ์ของผูใ้ ช้
เพือให้ขอ้ มูลพืนฐานเพิมเติม ผมวาดภาพทีอธิบายทุกอย่าง (ดูบทที "ภาพทีอธิบายทุกอย่าง" สําหรับข้อมูลเพิมเติม
เกียวกับเรืองนี) บนกระดานฟลิปชาร์ตและเก็บไว้เป็ นข้อมูลอ้างอิง.
“ภาพทีอธิบายทุกอย่าง” ซึงมีความทะเยอทะยานอย่างเหลือเชือ
การเพิมคําสัง (Commands) และผูก้ ระทําทีเฉพาะเจาะจง (specific actors) กระตุน้ ให้เกิดการพูดคุยเพิมเติมเกียวกับ
เหตุผลทีผูใ้ ช้แต่ละรายจะดําเนินการตามขันตอนทีกําหนดไว้ เมือพิจารณาอีกครัง บางขันตอนอาจดูเป็ นเรืองง่าย ในขณะทีบาง
ขันตอนกระตุน้ ให้เกิดการสนทนาทีลึกซึงขึน เช่น “ทําไมผูใ้ ช้ X ต้องเปิ ดใช้งานบริการ?” ซึงอาจนําไปสู่การตังคําถามกับ
สมมติฐานดังเดิม
มีสงที
ิ น่าสนใจสองสามอย่างเกิดขึนเกียวกับคําสังและผูก้ ระทํา คําสังในทีสุดแล้วเป็ นผลมาจากการตัดสินใจของผูใ้ ช้
บางอย่าง แต่การคิดในแง่ของการตัดสินใจของผูใ้ ช้ (เราจะทําให้มนั ง่ายขึนได้ไหม? เราจะทําให้มนั ดีขึนได้ไหม? เราจะมีอทิ ธิพล
ต่อมันได้ไหม?) บังคับให้เราต้องคิดในแง่ของข้อมูลทีเกียวข้องสําหรับขันตอนการตัดสินใจทีกําหนด
เราจับข้อมูลนีไว้ในแบบจําลองการอ่าน (Read Models) ซึงเป็ นกระดาษโน้ตสีเขียวในพจนานุกรมทีเราใช้สี หรือแม้แต่
ในภาพร่างเล็ก ๆ หากมีความต้องการสําคัญทีปรากฏขึน เช่น “เราต้องการภาพทีนี” หรือ “ราคาจําเป็ นต้องแสดงตรงกลาง
หน้าจอ”.
แบบจําลองการอ่าน (Read Models) กําลังปรากฏขึนในฐานะเครืองมือทีสนับสนุนกระบวนการตัดสินใจทีเกิดขึนในสมองของผูใ้ ช้
ทีน่าสนใจคือ เมือเราคิดถึงแรงจูงใจของผูใ้ ช้ เราตระหนักว่าผูใ้ ช้ในบทบาทเดียวกันไม่ได้คิดเหมือนกันเสมอไป แม้วา่ การ
ตัดสินใจอาจจะเหมือนกัน แต่เหตุผลเบืองหลังจะแตกต่างกันอย่างมาก
สิงทีเคยดูเหมือนผูใ้ ช้หรือผูก้ ระทําธรรมดา กลับกลายเป็ นการรวบรวมกลุม่ บุคคลทีซับซ้อนมากขึน หรือทีเรียกว่า
"Personas" เนืองจากเราอยู่ในโหมด Lean Startup จึงเป็ นเรืองดีทเห็
ี นแนวคิดนีเกิดขึน: ในทีสุดเราอาจใช้มนั เพือปรับปรุง MVP
ของเรา โดยมุ่งเน้นเฉพาะไปที Personas ทีเลือกเพียงไม่กีกลุ่มเท่านัน
อย่างไรก็ตาม เราไม่ได้ใส่ใจในนิยามทีแน่นอน สิงสําคัญกว่าคือการทีเรากําลังมีบทสนทนาเช่นนี ซึงสําคัญกว่าความ
แม่นยําของสัญกรณ์ทใช้
ี
าตัวเองคิดในแง่ของปฏิกิรยิ าต่อเหตุการณ์เฉพาะในโดเมน
ยิงเราศึกษากลไกในระดับเฉพาะเจาะจงมากขึน เราก็ยงพบว่
ิ
(Domain Events) สิงเหล่านีหาได้ง่าย เพราะมักจะเริมต้นด้วยคําว่า "เมือใดก็ตาม" เช่น “เมือใดก็ตามทีค่าการเปิ ดรับแสงเกิน
เกณฑ์ทีกําหนด เราจําเป็ นต้องแจ้งเตือนผูจ้ ดั การความเสียง” หรือ “เมือใดก็ตามทีผูใ้ ช้เข้าสู่ระบบจากอุปกรณ์ใหม่ เราจะส่ง
ข้อความ SMS เตือนเขา”
แทนตรรกะเชิงปฏิกิรยิ าทีเกิดขึนหลังจากเหตุการณ์ และกระตุน้ คําสังในทีอืน เราเรียกสิง
สีม่วงอ่อน (Lilac) คือสีทเราใช้
ี
นีว่า ‘นโยบาย’ (Policy) ในเวิรก์ ชอปนีโดยเฉพาะ.
นโยบายของเรา ไม่วา่ จะเป็ นแบบทําด้วยตนเองหรือแบบอัตโนมัติ
ในสตาร์ทอัพ การบันทึกนโยบายให้เร็วทีสุดเท่าทีจะเป็ นไปได้เป็ นเรืองทีน่าสนใจ โดยไม่ตอ้ งสมมติถงึ วิธีการนําไปใช้
แม้วา่ การกระทําบางอย่างอาจต้องถูกนําไปใช้ในระบบในอนาคต แต่โดยทัวไปแล้ว การเลือนการตัดสินใจ (และค่าใช้จ่ายที
เกียวข้องกับใบอนุญาตและค่าธรรมเนียม) ไปจนถึงช่วงเวลาทีฐานลูกค้าใหญ่พอทีจะคุม้ ค่ากับการลงทุน มักจะเป็ นตัวเลือกที
ดีกว่า
กระบวนการทีต้องทําด้วยมือ และอาจดูย่งุ ยากในวันนี ในทีสุดจะถูกเปลียนเป็ นโซลูชนั ซอฟต์แวร์ในวันพรุง่ นี วิธีนช่ี วยให้
เราจัดการการเติบโตได้ในขณะทียังไม่มีขอ้ มูลทีชัดเจน โดยเฉพาะอย่างยิงจากการตอบรับของตลาด
นักพัฒนากําลังรูส้ กึ ตืนเต้น เพราะเราเริมเข้าสู่เรืองทางเทคนิค และสถาปัตยกรรมแบบขับเคลือนด้วยเหตุการณ์ (EventDriven Architecture) กําลังปรากฏขึนจากมวลกระดาษโน้ตสีตา่ ง ๆ อย่างไรก็ตาม คนในฝ่ ายธุรกิจไม่ได้ถกู กันออกจากการ
สนทนา สัญกรณ์อา้ งอิงยังคงมองเห็นได้บนกระดานฟลิปชาร์ตซึงทําหน้าทีเป็ นตํานานทีชัดเจน และเราส่วนใหญ่กาํ ลังถกเถียง
ถึงเหตุผล (the whys) หรือให้ขอ้ มูลเชิงลึกในส่วนทีซับซ้อน
ในทีสุด ขณะทีผูก้ ่อตังย้ายไปยังสํานักงานอีกแห่ง เราก็ยงั คงสํารวจโมเดลนีร่วมกับนักพัฒนา พวกเขากระตือรือร้นทีจะ
เจาะลึกเรืองทางเทคนิคเหมือนแมวทีได้กลินปลา และผมเห็นด้วยว่าช่วงเวลานีเหมาะสมแล้ว
"Aggregate" หลัก ๆ (ในสีเหลืองอ่อนแบบดังเดิม) เริมปรากฏขึนในลักษณะขับเคลือนด้วยความรับผิดชอบ
(Responsibility-Driven) เมือบริบททีถูกจํากัด (Bounded Contexts) ได้รบั การร่างขึนแล้ว Aggregate ส่วนใหญ่ก็ดคู ่อนข้าง
เรียบง่าย
Aggregate ทีดูเรียบง่ายมาก อย่างเห็นได้ชดั
ทีน่าสนใจคือ การสํารวจนีให้ความรูส้ กึ ว่าสมบูรณ์ แม้วา่ จะเป็ นกระบวนการทีมุง่ เน้นการทํางานอย่างเป็ นขันตอนก็ตาม
เราสามารถจัดการทุกอย่างได้ค่อนข้างดีโดยไม่ตอ้ งใช้คาํ อย่าง ฐานข้อมูล (database), ตาราง (table), หรือ คิวรี (query) ข้อมูล
ส่วนใหญ่ถูกนําเสนอในรูปแบบของข้อกําหนดทีจําเป็ น หรือในฐานะแบบจําลองการอ่าน (read model) ทีจําเป็ นต้องใช้เพือ
สนับสนุนขันตอนของผูใ้ ช้ทีกําหนด มีเพียงไม่กีจุดทียังคงดูเหมือน CRUD แต่ส่วนใหญ่ของธุรกิจถูกอธิบายในแง่ของโดเมน
(Domain) ทีไหลเวียนอยูใ่ นระบบ
และมันให้ความรู ส้ กึ ทีถูกต้องอย่างยิง
ในตอนท้าย ดูเหมือนว่าเราจะครอบคลุมทุกสิงทีสําคัญ สิงทีเคยดูเหมือนความยุ่งเหยิงทีควบคุมไม่ได้ในตอนแรก ตอนนี
ดูเหมือนกระแสการทํางานทีสมเหตุสมผล ความมันใจของทีมพุง่ สูงขึนมาก มีบางพืนทีทีการทดลองจะเป็ นสิงจําเป็ น (ส่วนใหญ่
เพราะเราต้องเข้าใจพลวัตของระบบหลังจากทีมีผใู้ ช้จาํ นวนมากเข้ามาใช้งาน) แต่ความรูส้ กึ โดยรวมคือ การพัฒนาน่าจะ
เดินหน้าไปได้อย่างราบรืน
เพราะทุกคนรูเ้ หตุผลว่าทําไมแต่ละส่วนถึงมีอยู่
และการตัดสินใจหลายอย่างทีมักจะดูไม่
สมเหตุสมผลในภายหลังจะไม่ถกู นํามาใช้
เรากําลังอยูใ่ น “เขตสนธยาของสตาร์ทอัพ” (the startup’s twilight zone): สมมติฐานควรถูกท้าทายด้วยการทดลอง แต่
การเลือกสมมติฐานทีเหมาะสมเพือท้าทายและออกแบบการทดลองทีสอดคล้องกันยังคงเป็ นศิลปะทีซับซ้อน.
การออกแบบฟี เจอร์ใหม่สาํ หรับเว็บแอป
เราเพิงจัดเวิรก์ ชอปภาพรวมในช่วงเช้า แต่ตอนนีถึงเวลาทีต้องจํากัดขอบเขตและมุ่งเน้นไปทีความต้องการใหม่สาํ หรับ
แอปของเรา
เราไม่จาํ เป็ นต้องมีผเู้ ชียวชาญในโดเมนทุกคนทีนี: ขอบเขตของฟี เจอร์ใหม่ค่อนข้างชัดเจนและเกียวข้องกับผูเ้ ชียวชาญ
เพียงสองคนเท่านัน
[FIXME: อาจต้องทําในภายหลังเล็กน้อย] ร่วมกับทีมพัฒนา เราได้เจาะลึกถึงความหมายทางภาษาศาสตร์ของ Domain
Events
เป็ นเรืองน่าสนใจทีได้เห็นว่าเรากําลังเขียนกระดาษโน้ตใหม่หลายครังด้วยชือทีแตกต่างกัน สํารวจรูปแบบทีหลากหลาย
หรือเพิมความแม่นยําให้กบั ภาพทีกําลังสร้างขึน แม้ว่าจะมีการทิงกระดาษโน้ตหลายใบ แต่เรายังคงรูส้ กึ ถึงความก้าวหน้าและ
ความมันคงทีเพิมขึน
ในช่วงเวลานี เราเริมเจาะลึกลงไปในกลไกของกระบวนการทางธุรกิจของเรา: ทุก Domain Event ควรเป็ นผลมาจากบาง
สิงบางอย่าง ผมได้รา่ งบางสิงทีคล้ายกับภาพด้านล่างบนตํานานทีมองเห็นได้
Domain Events มาจากไหน? มีคาํ ตอบทีเป็ นไปได้ แบบสําหรับคําถามนี:
 อาจเป็ น คําสัง (Command) (กระดาษโน้ตสีเหลียมสีนาเงิ
ํ น) ทีถูกกระตุน้ โดยผูใ้ ช้คนใดคนหนึง
 อาจเป็ น Domain Event ทีถูกกระตุน้ โดย ระบบภายนอก (มักจะเป็ นกระดาษโน้ตรูปสีเหลียมผืนผ้าสีชมพู
ขนาดใหญ่กว่า)
 อาจเป็ นเพียงผลลัพธ์ของ เวลา ทีผ่านไป โดยไม่มีการกระทําใด ๆ ทีเฉพาะเจาะจงเข้ามาเกียวข้อง (เช่น
PaymentTermsExpired)
 หรืออาจเป็ นเพียง ผลลัพธ์ของเหตุการณ์อืน: เมือบางสิงเกิดขึน อีกสิงหนึงก็จะเกิดขึนตามมา อย่างไรก็ตาม
มันไม่ได้ชดั เจนเสมอไป ดังนันเราจึงใช้กระดาษโน้ตสีมว่ งอ่อน (Lilac) เพือแสดงถึงสิงนี.
นักพัฒนาบางคนรูส้ กึ สับสน คําสัง (Commands) บางส่วนดูเหมือนเป็ นเพียงการเขียนใหม่ของ Domain Events ที
เกียวข้อง มันน่าสนุกเสมอทีได้เห็นว่าสมองของนักพัฒนาตอบสนองต่อสิงทีดูนา่ เบือและซําซากอย่างไร อย่างไรก็ตาม นันไม่ใช่
ปั ญหา: ทังระบบอาจจะซับซ้อน แต่ก็ไม่ได้หมายความว่าองค์ประกอบเล็ก ๆ ทุกชินจะต้องวุ่นวาย บางส่วนก็จะง่ายดาย
อย่างไรก็ตาม ในบางส่วนของโฟลว์ สิงนีไม่ได้เกิดขึน: ความสัมพันธ์ระหว่างการกระทําของผูใ้ ช้และการตอบสนองของ
ระบบมีความซับซ้อนกว่าทีเราคิดไว้ในตอนแรก และอาจก่อให้เกิดผลลัพธ์ทีแตกต่างกัน
การทํางานร่วมกับนักพัฒนามักนํามาซึงผลลัพธ์ทีน่าสนใจ: พวกเขามักจะคิดหาทางเลือกและเส้นทางทีเป็ นทางเลือก
เสริม โดยมองหาความสมมาตรในเชิงความหมาย (Semantic Symmetry) ตัวอย่างเช่น หากเรามีคาํ สัง ReserveSeat พวกเขา
จะมองหาคําสัง CancelReservation ทันที และเริมสํารวจเส้นทางทางเลือก สิงนีนําเราไปสู่การค้นพบเหตุการณ์เพิมเติมและ
คําถามในลักษณะ "จะเกิดอะไรขึนเมือ...?"
ตอนนีถึงเวลาแนะนํา Aggregate ซึงเป็ นหนึงในแนวคิดสําคัญของ Domain-Driven Design โดยการมองหาความ
รับผิดชอบในระดับท้องถินทีสามารถกระตุน้ การตอบสนองทีแตกต่างกันต่อคําสัง
เราใช้กระดาษโน้ตสีเหลืองแบบธรรมดา
สําหรับเรืองนี
มันให้ความรูส้ กึ เป็ นธรรมชาติในการเริมจัดกลุ่มคําสังและเหตุการณ์รอบ ๆ Aggregate ทีค้นพบใหม่ และสิงนีกระตุน้ ให้
เกิดการสนทนาเพิมเติมในการตามหาความสมมาตร ตอนนี Aggregate เริมดูเหมือนเครืองจักรสถานะเล็ก ๆ (Little State
Machines)
บางคนรูส้ กึ สับสน เพราะในช่วงเวลาทีเราเริมจัดกลุ่มตามความรับผิดชอบ เราได้ทาํ ลายลําดับเวลา นันไม่ใช่ปัญหา ทัง
สองวิธีนีเป็ นอิสระต่อกัน (Orthogonal): เราไม่สามารถมีทงสองได้
ั
ลําดับเวลา (Timeline) เป็ นสิงทียอดเยียมสําหรับการกระตุน้
การคิดภาพรวม แต่ตอนนี ความรับผิดชอบ (Responsibility) เป็ นตัวขับเคลือนทีดีกว่าสําหรับการออกแบบระบบทีแข็งแกร่ง
"ภาพทีอธิบายทุกอย่าง" (The picture that explains everything) กลับมาเป็ นผูช้ ว่ ยของเราอีกครัง และผมอ้างอิงถึงภาพ
นีเพือแนะนํา Read Models ในกระดาษโน้ตสีเขียว เพือสนับสนุนการตัดสินใจของผูใ้ ช้ และกระบวนการต่าง ๆ บนกระดาษโน้ต
สีม่วงอ่อน (Lilac) ซึงดูแลตรรกะเชิงปฏิกิรยิ าของระบบ
[FIXME: จบกระบวนการ!]
การทํา EventStorming แบบรวดเร็วใน Avanscoperta5
ถึงเวลาทีเราจะทําการย้อนทบทวน (Retrospective) ในบริษัทของเรา ยอดขายคลาสฝึกอบรมในช่วงไม่กีสัปดาห์ทีผ่าน
มาไม่ดเี ท่าทีคาดไว้ จึงสมเหตุสมผลทีจะสํารวจปั ญหาทีเราเจอระหว่างทาง
เนืองจากเราให้ความสําคัญกับพืนผิวสําหรับการสร้างโมเดลขนาดใหญ่ เราจึงมีพืนทีมากมายสําหรับการสร้างโมเดล:
ทุกผนังในสํานักงานใหญ่ของเรา (ห้องเดียวขนาด
ตารางเมตร) สามารถเขียนได้ ดังนันจึงไม่จาํ เป็ นต้องใช้กระดาษม้วน
ทัวไป อย่างไรก็ตาม การมีกระดาษโน้ตสีสม้ ในปริมาณมากเป็ นสิงจําเป็ น
จํานวนคนในบริษัทเราไม่ได้มากนัก จริง ๆ แล้ว แกนหลักของบริษัทมีเพียง - คนเท่านัน อย่างไรก็ตาม เรามีความเป็ น
อิสระมากในการตัดสินใจด้านกระบวนการ และเราได้ทดลองเปลียนแปลงบางอย่างในช่วงทีผ่านมา จึงสมเหตุสมผลทีจะรวม
การรับรูท้ แตกต่
ี
างกันของกระบวนการเข้าไว้ดว้ ยกันเพือสร้างความสอดคล้อง
เราทุกคนได้ปากกามาคนละแท่ง เราเริมเขียน Domain Events (ประโยคสัน ๆ เช่น "เผยแพร่รายละเอียดการฝึ กอบรม"
หรือ "ขายบัตรแล้ว") ลงบนกระดาษโน้ตสีสม้ และวางตามลําดับเวลา จากซ้ายไปขวา
ไม่มีการบังคับเรืองลําดับทีเคร่งครัด: ทุกคนเขียนในหัวข้อทีตัวเองรูด้ ีทสุี ด และหาตําแหน่งทีเหมาะสมในกระแสการ
ทํางาน (Flow) หากตําแหน่งของกระดาษโน้ตรอบข้างแน่นเกินไปหรือลําดับดูเกะกะ ทุกคนสามารถปรับตําแหน่งได้
ระหว่างทาง เราพบว่าเราพูดถึง ระบบภายนอก (External Systems) บ่อยครัง (ซึงเราใช้กระดาษโน้ตสีชมพูขนาดใหญ่
กว่า) และยังเจอบางสิงทีไม่ได้อยูใ่ นเครืองมือ EventStorming แบบปกติ: ชุมชน (Communities) สิงเหล่านีมีความหมายพอใน
บริบทของเรา จนสมควรทีจะใช้สญ
ั ลักษณ์เฉพาะ เราเลือกสี (ฟ้าอ่อน) ทียังไม่ได้ใช้ และเพิมเข้าไปในระบบสัญกรณ์ของเรา
เมือกระแสการทํางานโดยรวมเริมสมเหตุสมผล เราเริมสํารวจปัญหาและเขียนมันลงบนกระดาษโน้ตสีม่วง แล้ววางไว้
ใกล้ ๆ กับ Domain Events ทีเกียวข้อง ในกรณีของเรา มีปัญหาทีเขียนไว้ เช่น "รายละเอียดคลาสฝึ กอบรมไม่ดี!" (Training
Class Description Sucks!), "นโยบายส่วนลดไม่ชดั เจน" (Unclear Discount Policy) หรือ "นโยบายการโฆษณา!!!"
(Advertising Policies!!!) เพือเน้นว่าเราไม่มวี ิธีการโฆษณาทีสามารถทําซําได้
ไอเดียเริมหลอมรวมกัน และสุดท้ายเราก็ได้ความเป็ นไปได้สาํ หรับการปรับปรุงประมาณ
ข้อ.
ผลลัพธ์จากเซสชัน EventStorming ของเราใน Avanscoperta (หนึงในหลาย ๆ ครัง).
เมือสํารวจในขอบเขตทีกว้างขนาดนี เป็ นเรืองง่ายทีปั ญหาต่าง ๆ จะปรากฏขึนแบบสุ่ม โดยผสมผสานสิงทีสําคัญมาก
กับเรืองเล็กน้อยเข้าด้วยกัน ดังนัน - เช่นเดียวกับทีเราทําในเซสชันการย้อนทบทวน (Retrospective) - เราจะจัดลําดับ
ความสําคัญของปัญหา โดยคํานึงถึงผลกระทบ: "ปัญหาใดทีจะมีผลกระทบมากทีสุดเมือได้รบั การแก้ไข?"
เราเลือกทีจะมุง่ เน้นไปทีความน่าสนใจของผลิตภัณฑ์ทีเรากําลังขาย การตัดสินใจซือบัตรเข้าคลาสฝึกอบรม - ซึงเราจะ
แทนด้วยกระดาษโน้ตสีนาเงิ
ํ น - เป็ นการตัดสินใจของผูใ้ ช้ทเกี
ี ยวข้องกับทังตรรกะและความคิดเชิงอารมณ์
ในแง่ตรรกะ เรามีปัญหาเล็กน้อยเกียวกับข้อมูลทีแสดง: แม้ว่าราคาปั จจุบนั จะถูกแสดง แต่ชือเรียกเกียวกับส่วนลดของ
เรากลับทําให้ผใู้ ช้สบั สน: มีการแสดงราคา ราคา และผูใ้ ช้บางคนสงสัยว่ามันนําไปสู่คลาสบริการทีแตกต่างกันหรือไม่ แม้จะ
ไม่ใช่อปุ สรรคใหญ่ แต่ประสบการณ์การซือกลับดูย่งุ เหยิง
แต่สิงทีเป็ นอุปสรรคใหญ่อยู่ตรงหน้าเรา: กระดาษโน้ตสีมว่ งทีเขียนว่า "รายละเอียดคลาสฝึกอบรมไม่ดี!" (Training
Class Description Sucks!) บอกเราชัดเจนว่ามูลค่าทีผูใ้ ช้รบั รูเ้ กียวกับสิงทีเราขายนันไม่เพียงพอทีจะกระตุน้ การซือ
การตรวจสอบรายละเอียดของคลาสฝึกอบรมทีขายดีทีสุด เทียบกับคลาสทีขายได้อ่อนกว่า ยืนยันสมมติฐานนี: แม้จะมี
ครูทีดีและหัวข้อทีน่าสนใจ แต่คลาสทีแสดงบนเว็บไซต์ไม่ได้กระตุน้ ความรูส้ กึ หรือเรียกร้องให้ดาํ เนินการใด ๆ อย่างชัดเจน
ตอนนีเรารูแ้ ล้วว่าเราต้องทุ่มเทความพยายามมากขึนในการสร้างเนือหาสําหรับคลาสฝึ กอบรม: มันต้องพูดกับความคิด
ในเชิงเหตุผล แต่ก็ตอ้ งดึงดูดใจในเชิงอารมณ์ดว้ ย (หรือ ‘หัวใจ’ หากคุณรูส้ กึ โรแมนติกมากกว่าวิทยาศาสตร์)
ในทีสุด สมองของผมก็รูส้ กึ ขัดแย้งกันเล็กน้อย ในฐานะผูป้ ระกอบการ ผมค่อนข้างพอใจทีสามารถระบุปัญหาหมายเลข
หนึงในรายการได้ และตอนนีผมมีแผนการดําเนินงานไปสู่การแก้ปัญหาทีเป็ นไปได้ แต่ในฐานะนักพัฒนา ผมรูส้ กึ ผิดหวัง
เล็กน้อย เพราะวิธีแก้ปัญหาไม่ได้เกียวข้องกับการเขียนโค้ดเลย
ผมหวังว่าอุปสรรคถัดไปจะเกียวข้องกับงานด้านเทคนิคมากกว่านี.
รูปแบบทีเป็ นไปได้
ศาสตร์นียังค่อนข้างใหม่ (การทดลองครังแรกของผมเริมในปี
) แต่ตอนนีก็มีรูปแบบทีชัดเจนบางอย่างทีได้รบั การ
ยอมรับแล้ว ผมชอบคิดถึงมันเหมือนกับพิซซ่า: มีฐานทีเหมือนกัน แต่ท็อปปิ งต่างกัน
นีคือตัวเลือกในเมนูของผม:
 Big Picture EventStorming: ใช้เพือเริมต้นโครงการ โดยมีผมู้ ีส่วนได้ส่วนเสียทังหมดเข้าร่วม
ี นไปได้ มักอยูใ่ นสไตล์ DDD-CQRS/ES
 Design Level EventStorming: เจาะลึกถึงการนําไปใช้ทเป็
 Value-Driven EventStorming: วิธีทีรวดเร็วในการเข้าถึงการทําแผนทีกระแสคุณค่า
Mapping) โดยใช้การเล่าเรืองเป็นแพลตฟอร์มทีเป็ นไปได้
(Value-Stream
 UX-Driven EventStorming: คล้ายกับแบบด้านบน แต่เน้นทีเส้นทางของผูใ้ ช้/ลูกค้า (User/Customer
Journey) เพือค้นหาความสามารถในการใช้งานและการดําเนินงานทีไร้ขอ้ ผิดพลาด
 EventStorming as a Retrospective: ใช้ Domain Events เป็ นฐานเพือสร้างกระบวนการและขยายขอบเขต
เพือค้นหาโอกาสในการปรับปรุง
 EventStorming as a Learning Tool: เหมาะสําหรับการเพิมการเรียนรูใ้ ห้กบั พนักงานใหม่
ในบทถัดไป เราจะเริมจากแนวทาง Big Picture ซึงเป็ นวิธีทเปิ
ี ดทางสําหรับการสํารวจเพิมเติม.
ภาพรวมของเส้นทางทีแตกต่างกันทีเป็ นไปได้
การเจาะลึกสู่พืนทีของปั ญหา
“ความจริงเดียวเกียวกับธรรมชาติของมนุษย์คือทุกคนโกหก
ความแตกต่างเพียงอย่างเดียวคือเรืองทีโกหกเกียวกับ
อะไร”
— Dr. Gregory House
ส่วนนีจะสํารวจลึกถึงธรรมชาติของปั ญหาที EventStorming พยายามจัดการ ปัญหาเหล่านีใหญ่โตและฝังรากลึก แม้ว่า
ผมจะพยายามอย่างเต็มทีทีจะทําให้ส่วนนีกระชับ แต่มนั ก็ยงั คงมีเนือหามากอยู่
อย่ามองผมนะ! ผมไม่ได้เป็ นคนสร้างปัญหา มันเป็ นธรรมชาติของมนุษย์ เป็ นผลจากสมมติฐานทีผิดเกียวกับการพัฒนา
ซอฟต์แวร์มานานหลายทศวรรษ และอืน ๆ อีกมากมาย ผมแค่ตอ้ งเปิ ดเผยปั ญหาในความยิงใหญ่ทีน่ากลัวของมัน
ในบทที : "มองลึกลงไปในพืนทีของปั ญหา" เราจะพิจารณาปัญหาทัวไปทีเราอาจเผชิญเมือดําเนินการ Big Picture
EventStorming เราจะ (กลับมา) ค้นพบความผิดปกติในองค์กรแบบคลาสสิก และอาจเปิ ดเผยสิงทีไม่คาดคิดบางอย่าง
ในบทที : "การแสร้งแก้ปัญหาโดยการเขียนซอฟต์แวร์" เราจะเจาะลึกถึงความเชือผิด ๆ ทัวไปของวิศวกรรมซอฟต์แวร์
และเหตุผลทีแนวทางบางอย่างไม่เหมาะสมในการจัดการกับปั ญหาทีเราต้องแก้
ทังสองบทนีส่งเสริมกัน และควรอ่านต่อเนืองกัน อย่างไรก็ตาม หากคุณกระตือรือร้นทีจะเรียนรูก้ ลไกของการจัดเวิรก์ ช
อปครังแรก คุณอาจข้ามบทที และ ไปก่อนได้ หากคุณสัญญาว่าจะกลับมาอ่านในภายหลัง
คุณจะไม่เสียใจเลย.
2 การพิจารณาเชิงลึกเกียวกับพืนทีของปัญหา - 80%
ในสถานทีทํางานทุกแห่ง มีคนสองประเภท: คนทีเข้าใจความซับซ้อนและคนทีไม่เข้าใจ
ความซับซ้อนในสัน ๆ หรือให้นอ้ ยกว่านัน
ความซับซ้อนเป็ นหัวข้อทีน่ากังวล มันทําให้ผคู้ นรูส้ ึกกลัวตามนิยาม - “โอ้พระเจ้า นีมันซับซ้อนมาก!” - และจุดเริมต้น
ทัวไปของเรืองนีมักจะเป็ นคํากล่าวของวิทยากรในทีประชุมทีพูดถึงความแตกต่างระหว่างคําว่า ‘ซับซ้อน’ (complex) และ
‘ซับซ้อนยุง่ ยาก’ (complicated) ซึงฟั งดูคล้ายกันสําหรับคนทัวไป และมีความหมายเกือบเหมือนกัน แต่มีความแตกต่างอย่าง
มากเมือเราเข้าสู่ขอบเขตของความซับซ้อน
อย่างไรก็ตาม เมือพูดถึงองค์กรทีผูค้ นทํางานร่วมกันเพือเป้าหมายร่วมกัน เราสามารถเดิมพันได้อย่างปลอดภัยว่าเรา
กําลังอยูใ่ นรูปแบบใดรูปแบบหนึงของระบบปรับตัวทีซับซ้อน (Complex Adaptive System) คุณอาจต้องการเข้าไปดูนิยามที
เป็ นทางการมากขึนในวิกิพีเดีย แต่ฉันชอบนิยามทีง่ายกว่าและสามารถนําไปปฏิบตั ิได้มากกว่า
ดังนัน นิยามทีไม่เป็ นทางการของฉันเกียวกับระบบปรับตัวทีซับซ้อนคือ
เครือข่ายของตัวแทนทีพึงพาอาศัยกันและมีอทิ ธิพลต่อกันและกัน
บริษัทของคุณ ชุมชนของคุณ ครอบครัวของคุณ ล้วนสามารถมองได้ว่าเป็ นระบบปรับตัวทีซับซ้อน (Complex Adaptive
Systems) แล้วมันหมายถึงอะไรในทางปฏิบตั ิ? เอาล่ะ... กฎง่าย ๆ ทีดีทีสุดทีฉันรูค้ ือ
ระบบปรับตัวทีซับซ้อนไม่มีทางแสดงพฤติกรรมตามทีคาดหวังไว้
ุ เข้าใจภาพ
นีคือตัวอย่างเรืองราวสองสามเรืองเพือให้คณ
ในบริษัท TXZ (ซึงไม่ใช่บริษัททีแต่งขึนเสียทีเดียว) หัวหน้า "ขอ" ให้พนักงานมาถึงออฟฟิ ศก่อน 9:00 น. อย่างเคร่งครัด
เพือปรับปรุงประสิทธิภาพการทํางาน พนักงานปฏิบตั ิตามคําขอ แม้วา่ จะทํางานจนดึกบ่อยครัง แต่ผคู้ นก็เริมตืนเช้าและเผชิญ
กับการจราจรยามเช้าเพือมาถึงออฟฟิ ศตรงเวลาและสแกนบัตร อย่างไรก็ตาม พนักงานปรับเปลียนพฤติกรรมโดยเริมทาน
อาหารเช้าและดืมกาแฟเล็ก ๆ น้อย ๆ หลังจากเช็กอิน การทานอาหารเช้าร่วมกับเพือนร่วมงานกระตุน้ ให้เกิดการพูดคุยซุบซิบ
เล็ก ๆ น้อย ๆ เพิมขึน วันแล้ววันเล่า การทานอาหารเช้ากลายเป็ นกิจกรรมทางสังคม และแม้แต่คนทีทานอาหารเช้าทีบ้าน
มาแล้วก็ยงั มาร่วมวงด้วยเพียงเพือดืมกาแฟหนึงแก้ว งานจริง ๆ จึงไม่ได้เริมก่อนเวลา 9:30 น. ชัวโมงการทํางานจริง ๆ กลับ
ลดลง
Kaboom! (อีกหนึงองค์กรทีไม่ใช่เรืองแต่งเสียทีเดียว) เคยนําเสนอนโยบายการให้รางวัลตามเวลาการแก้ไขข้อผิดพลาด
(bugs) โดยมีเป้าหมายเพือปรับปรุงคุณภาพซอฟต์แวร์ เมือพนักงานเริมคุน้ เคยกับระบบใหม่ พวกเขาก็เริมปรับเปลียนนโยบาย
เกียวกับการเปิ ดรายงานข้อผิดพลาด: มีการป้อนข้อผิดพลาดเล็กน้อยจํานวนมากเข้าในตัวติดตามปั ญหาใน "วันทีว่าง" และ
แก้ไขไม่นานหลังจากนัน ตัวชีวัด (และโบนัสทีเกียวข้อง) ดีขึน แต่คณ
ุ ภาพของซอฟต์แวร์กลับไม่ได้ดีขึน ในความเป็ นจริง ปั ญหา
ทีสําคัญและแก้ยากทีรายงานโดยลูกค้าจริงถูกจัดลําดับความสําคัญตําในเบืองหลัง
คุณเห็นปัญหาไหม? ใช่แล้ว มันคือมนุษย์และความสามารถทีน่ารําคาญของพวกเขาในการตัดสินใจเฉพาะบุคคล โดย
การปรับตัวให้เข้ากับบริบทโดยรอบ หรือทีเรียกว่าความมีอสิ ระทางความคิด (free will) หากคุณชอบคํานี
ทีน่าสนใจยิงกว่านันคือ คําสัง การให้รางวัล และนโยบายทีกําหนดจากเบืองบน มักเป็ นวิธีทีไม่ได้ซบั ซ้อนนักในการ
เปลียนพฤติกรรมของผูค้ นในระดับระบบ บุคคลมักตัดสินใจโดยอิงจากบริบททีกว้างขึน ซึงรวมถึงความเป็ นอยู่สว่ นตัวของพวก
เขา พฤติกรรมของเพือนร่วมงาน จริยธรรมของพวกเขา และอืน ๆ
บางคนอาจเรียกสถานการณ์ทีฉันอธิบายมาข้างต้นว่า "การโกง" แต่หากระบบกําลังหลอกคุณ หากผูค้ นไม่ได้แสดง
พฤติกรรมตามทีคาดไว้ มีความเป็ นไปได้สงู ว่าคุณกําลังเผชิญกับระบบปรับตัวทีซับซ้อน (Complex Adaptive System) และใช้
กลยุทธ์ทีผิด
ทีน่าสนใจยิงไปกว่านันคือ การตัดสินใจในระดับบุคคลมักก่อให้เกิดพฤติกรรมทีปรากฏขึนใหม่ (emerging behaviors)
เช่น "เวลาซุบซิบนินทายามเช้า" หรือ "สมรูร้ ว่ มคิดเรืองบักง่าย ๆ" ซึงอาจปรับเปลียนระบบทังระบบในวิธีทีคาดเดาไม่ได้
ระบบทีซับซ้อนเป็ นระบบทีไม่กาํ หนดผลลัพธ์ลว่ งหน้าได้
ระบบทีซับซ้อนไม่สามารถคาดเดาได้งา่ ย ๆ และนีไม่ใช่เพราะโชคร้าย แต่มนั เป็ นคุณสมบัติทีแท้จริงของระบบเอง
เมือสิงทีไม่คาดคิดเกิดขึน ผูค้ นมักจะหาคําอธิบายในเชิงของเหตุและผลหลังจากเหตุการณ์นนเกิ
ั ดขึน แต่ก่อนทีสิงนันจะ
เกิดขึน มันจะไม่ได้ดชู ดั เจนขนาดนัน คุณอาจทราบว่าคุณกําลังรับมือกับระบบอยู่ แต่ขอ้ จํากัดทีแท้จริงของระบบนันจะเข้าใจได้
ก็ต่อเมือมองย้อนกลับไป
ในความเป็ นจริง ฉันเองใช้เวลาสักพักกว่าจะคุน้ เคยกับแนวคิดนี ด้วยพืนฐานในด้านการเขียนโปรแกรมคอมพิวเตอร์ ฉัน
มักจะมีความคิดในเชิงกําหนดผลลัพธ์ (deterministic mindset) ซอฟต์แวร์คอมพิวเตอร์ ต้อง สามารถคาดเดาได้ แม้ในบาง
กรณีทผลลั
ี พธ์จะหลอกเรา
เมือระบบทีกําหนดผลลัพธ์ล่วงหน้าได้แสดงพฤติกรรมทีไม่คาดคิด นันหมายความว่ายังมีรายละเอียดบางอย่างทีซ่อน
อยู่ซงเราไม่
ึ
ได้พจิ ารณา เมือเราค้นพบส่วนทีขาดหายไปนัน เราอาจสามารถอธิบายปั ญหาได้และอาจจําลองสถานการณ์นนั
ขึนมาใหม่ในทีสุด
ุ ประหลาดใจเสมอ ผูค้ น
แต่ระบบทีประกอบไปด้วยผูค้ น... นันเป็ นอีกเรืองหนึง ไม่ว่าจะด้วยวิธีใด พวกเขามักจะทําให้คณ
เรียนรู ้ และโดยทัวไปแล้ว คุณไม่สามารถหลอกพวกเขาได้แบบเดิมสองครัง
การอธิบายย้อนหลัง
หลังจากเหตุการณ์เกิดขึนแล้ว จะมีใครสักคนทีให้คาํ อธิบายทีดูดีเสมอ พร้อมคุณสมบัติทีน่ารําคาญคือ มันฟังดูชดั เจน
เหลือเกิน!
อย่างน้อยเราก็ได้เรียนรูอ้ ะไรบางอย่าง
เราสามารถเรียนรู บ้ ทเรียนจริง ๆ ได้หรือไม่?
น่าเสียดายทีแม้แต่การวิเคราะห์ยอ้ นหลังก็ไม่ได้รบั ประกันว่าจะค้นพบเหตุผลทีแท้จริงว่าทําไมสิงต่าง ๆ ถึงเกิดขึน การ
สรุปบทเรียนจากประสบการณ์ในอดีตสามารถเป็ นเรืองทียากลําบากได้ เพราะมนุษย์มีความต้องการโดยธรรมชาติทีจะมองหา
คําอธิบายทีเรียบง่ายสําหรับสถานการณ์ทซัี บซ้อน ไล่หาคนผิด (ซึงให้ความรูส้ กึ สบายใจเมือสามารถโยนความผิดให้คนอืน
แทนทีจะยอมรับว่าปัญหาอยูใ่ นระบบทีเราเป็ นส่วนหนึง) โทษโชคร้าย หรืออะไรก็ตามทีช่วยรักษาสถานะเดิมของตัวเองไว้
ให้ฉนั พูดให้ชดั เจนยิงขึน:
 ในระบบทีซับซ้อน ความสัมพันธ์ระหว่างสาเหตุและผลลัพธ์จะเห็นได้ชดั เจนก็ต่อเมือมองย้อนหลังเท่านัน นี
ไม่ใช่โชคร้าย แต่มนั เป็ นคุณสมบัติโดยนิยามของระบบ
 ชัดเจนไม่ได้หมายความว่าเข้าใจ สมองของมนุษย์ถกู ตังโปรแกรมมาให้มองหาความสัมพันธ์แบบง่าย ๆ
ระหว่างสาเหตุและผล แม้ในสถานการณ์ทีมันไม่สามารถนํามาใช้ได้ การเล่าเรืองทีเรียบง่ายและดูน่าเชือถือ
มักจะเป็ นตัวเลือกทีถูกนํามาใช้เพืออธิบายผลลัพธ์ทไม่
ี คาดคิด มากกว่าการอธิบายทีซับซ้อนกว่า
การเล่าเรืองทีเรียบง่ายและน่าเชือถือโดยทัวไปมักจะเป็ นการ
 ในสภาพแวดล้อมขององค์กรหรือการเมือง
กล่าวโทษใครบางคน และตามมาด้วยการไล่ออก (หรือเลือนตําแหน่ง) หากมีการชีนิวไปทีบุคคลทีกําหนดไว้
แล้ว คําพูดทีน่าจะได้ยินออกมาจากปากของพวกเขาก็คือ “โชคร้าย” หรือ “สถานการณ์ทีไม่ธรรมดา”
 การกล่าวโทษระบบไม่ใช่สิงทีดึงดูดใจ ระบบคือทุกคน และมันไม่ได้สร้างเรืองเล่าทีเข้าใจง่าย ยิงไปกว่านัน
หลังจากเกิดปั ญหาร้ายแรงขึน ผูค้ นมักต้องการประกาศว่าปั ญหานันจบลงแล้ว ความวิตกกังวลและความรูส้ กึ
ผิดทีเกียวข้องกับปั ญหาทียังไม่ได้รบั การแก้ไขมักจะเป็ นสิงทีเกินกว่าจะรับมือได้
พักผ่อนหลังจากนัน
เราจําเป็ นต้องนอนหลับ
น่าเสียดาย ความจริงทีว่า "เรากําลังแสร้งว่ากําลังบริหารระบบทีพฤติกรรมของมันยังคงเป็ นปริศนาสําหรับเรา" ไม่ใช่
คําพูดทีสามารถนําไปใช้ในเชิงการเมืองได้
ํ อย่าง
ในระบบทีซับซ้อน บริบทจะกลายเป็ นแรงขับเคลือนสําคัญ: กลยุทธ์และวิธีแก้ปัญหาไม่สามารถนํามาใช้ซาได้
ปลอดภัย ข้อมูลบริบทเฉพาะพืนทีจะเป็ นสิงทีสร้างความแตกต่าง
ความต้องการวิธีแก้ปัญหาทีพิสจู น์ได้
องค์กรทีมีแนวคิดอนุรกั ษ์นยิ มมักจะลังเลทีจะยอมรับผลทีตามมาของความซับซ้อนอย่างเต็มที วัฒนธรรมทีหลีกเลียง
ความเสียงแสดงออกมาในรูปแบบของการแสวงหาวิธีแก้ปัญหาทีพิสจู น์ได้ แทนทีจะเลือกแนวทางทดลองทีมีความเสียง
น่าเสียดายทีในโดเมนทีซับซ้อน ไม่มีสิงทีเรียกว่า “วิธีแก้ปัญหาทีพิสจู น์ได้” การจ้างโค้ชทีดีทีสุดทีมีสถิติชนะติดต่อกัน
ยาวนานทีสุดไม่ได้รบั ประกันว่าทีมของคุณจะคว้าแชมป์ ในปี หน้า
ในทางปฏิบตั ิ การยึดมันกับการหลีกเลียงความเสียงอย่างเคร่งครัดกลับกลายเป็ นกลยุทธ์ทีมีความเสียงสูงในโดเมนที
ซับซ้อน
บทบาทของผูเ้ ชียวชาญ
ในสถานทีทีธรรมชาติของความซับซ้อนไม่ถกู เข้าใจอย่างถูกต้อง “ผูเ้ ชียวชาญ” กลายเป็ นบทบาททีสร้างความขัดแย้ง
การรับรูท้ วไปเกี
ั
ยวกับผูเ้ ชียวชาญมักได้รบั อิทธิพลจากโดเมนทีซับซ้อนยุ่งยาก (complicated domains): ช่างเทคนิคบอกเราได้
ว่าทําไมรถของเราถึงมีเสียงแปลก ๆ ทําไม ADSL ของเราไม่ทาํ งาน และอืน ๆ เราคาดหวังการวินิจฉัยและวิธีแก้ปัญหาทีแม่นยํา
แพทย์มกั ถูกคาดหวังความแน่นอนในระดับเดียวกัน แม้วา่ พวกเขาอาจไม่สามารถมันใจในผลการวินิจฉัยได้ 100%
เมือเข้าสู่ขอบเขตของความซับซ้อน ผูเ้ ชียวชาญจะเผชิญกับปั ญหาด้านความคาดหวัง ผูค้ นมองหาคําตอบทีแน่ชดั และ
สูตรสําเร็จง่าย ๆ แต่สิงเหล่านันเป็ นพืนทีของนักฉวยโอกาส (demagogues) ไม่ใช่ของผูแ้ ก้ปัญหา ยกเว้นในบางกรณีทีมีการสือ
ข้อความทีซับซ้อนและตรงเป้าได้ดีมากจนติดอยูใ่ นใจของทุกคน
บ่อยครัง การต่อสูแ้ ย่งชิงอํานาจ (power play) เข้ามามีบทบาท: “ฉันต้องการคําตอบเดียวนี!” (โดยมีตวั อักษร “ฉัน”
ขนาดใหญ่) กลายเป็ นประโยคทีได้ยินบ่อยเมือผูบ้ ริหารไม่สบายใจกับระดับความไม่แน่นอนสูง ๆ เห็นได้ชดั ว่าคําตอบทีผิด
ตอนนียังดูนา่ สนใจกว่าการไม่มีคาํ ตอบทีดีในตอนนี
สรุปง่าย ๆ คือ ในสภาพแวดล้อมทีซับซ้อน ผูเ้ ชียวชาญไม่มีคาํ ตอบทังหมด พวกเขามีประสบการณ์ ความคล้ายคลึงกัน
(analogies) ไอเดีย และเครือข่ายเพือนร่วมงานทีช่วยให้คาํ แนะนํา แต่สิงเหล่านีไม่ได้รบั ประกันว่าพวกเขาจะตัดสินใจได้
ถูกต้อง
กลยุทธ์ในการตัดสินใจ
หากการพึงพาวิธีปฏิบตั ิทีดีทีสุดทีพิสจู น์ได้ไม่ใช่กลยุทธ์ทีเหมาะสม
ขององค์กร การตัดสินใจจะเพิมขึนทังในด้านจํานวนและความสําคัญ
ภาระจะตกไปอยู่ทีความสามารถในการตัดสินใจ
เนืองจากผลลัพธ์ไม่ได้รบั การรับประกัน การตัดสินใจหลายอย่างจะต้องถูกปฏิบตั ิเหมือนเป็ นการทดลอง ฟั งดูนา่ กลัว แต่
นีคือกลยุทธ์ทีสมเหตุสมผลทีสุดในสภาพแวดล้อมทีซับซ้อน โดยมีเงือนไขว่าคุณจะต้องใส่ใจกับการออกแบบการทดลองและ
เรียนรูใ้ ห้ได้มากทีสุดจากสิงเหล่านัน
แต่การตัดสินใจไม่ได้เกิดขึนฟรี ในความเป็ นจริง ในองค์กรส่วนใหญ่ การตัดสินใจทีสําคัญคือกิจกรรมทีใช้พลังงานมาก
ทีสุด และนีคือจุดทีองค์กรเผยให้เห็นถึงความบกพร่องทีน่ารําคาญทีสุด
หากมีเพียงไม่กีคนทีเข้าใจระบบอย่างแท้จริงและได้รบั สิทธิในการจัดการกับระบบนัน
อํานาจในการตัดสินใจก็จะ
กลายเป็ นทรัพยากรทียิงหายากยิงขึน บางคนอาจเริมหาวิธีลดั หรือเลียงกฎเพือให้งานสําเร็จลุล่วง ในขณะทีคนอืน ๆ กลายเป็ น
ผูเ้ ชียวชาญในเรืองระบบราชการทีจําเป็ นต้องผ่านเพือปฏิบตั ิตามกฎระเบียบ
ความซับซ้อนยังสร้างความท้าทายอีกอย่างหนึงสําหรับองค์กรแบบดังเดิม: เมือกลยุทธ์ทีสามารถทําซําได้ไม่สามารถ
ใช้ได้ ความจําเป็ นในการตัดสินใจทีสําคัญในทันทีจงึ กลายเป็ นสิงทีสําคัญมาก แต่ขอ้ มูลสําคัญส่วนใหญ่ทีจําเป็ นต่อการ
ตัดสินใจทีมีเหตุผลกลับมาจากบริบทโดยตรง และมักอยู่ใกล้กบั ผูท้ ีทํางานภาคสนามมากกว่าชันบริหาร
ในองค์กรทีมีลาํ ดับชันแบบชันตามแนวตัง (hierarchical organization) การตัดสินใจจากเบืองบนมักไม่สอดคล้องกับ
ธรรมชาติของความซับซ้อน การตัดสินใจจากฝ่ ายบริหารมีความเสียงทีจะมาถึงช้าเกินไป หลังจากทีข้อมูลไต่ขึนไปตามชันของ
ลําดับชัน และยังอาจมีขอ้ บกพร่องจากการสูญเสียข้อมูลระหว่างทาง
ในสภาพแวดล้อมทีซับซ้อน ความสามารถของผูท้ ีมีขอ้ มูลทีถูกต้องในการตัดสินใจทีเหมาะสมกลายเป็ นสิงสําคัญยิง คํา
ว่า "การจัดการตัวเอง" (self organization) เป็ นคําทีนิยมใช้เพืออธิบายถึงความสามารถของกลุ่มคนในการตอบสนองต่อปั ญหา
ได้อย่างรวดเร็วและร่วมมือกัน
อุปสรรคต่อการจัดการตัวเอง
น่าเสียดายทีการจัดการตัวเองไม่ได้เกิดขึนเพียงเพราะมีใครบางคนหาเวลาอ่านบทความบนเว็บได้ การบอกให้ผคู้ น
จัดการตัวเองโดยไม่สร้างสภาพแวดล้อมทีเหมาะสมไม่เพียงพอทีจะจุดประกายให้เกิดสิงทีวิเศษขึนมา เราอยูใ่ นระบบปรับตัวที
ซับซ้อน (Complex Adaptive System) ซึงท้ายทีสุดผูค้ นจะปรับตัวให้เข้ากับสถานการณ์ทีเกิดขึนในรูปแบบทีเราไม่สามารถ
คาดการณ์ได้
เหมือนกับแนวปฏิบตั ิทีดีหลายอย่างในระบบทีซับซ้อน การจัดการตัวเองไม่ได้รบั ประกันว่าจะเกิดขึน มันอาจเกิดขึนได้
หลังจากทีเราสร้างสภาพแวดล้อมทีเหมาะสมและขจัดสิงกีดขวาง ทีขวางทางออกไปแล้ว
รายการของสิงกีดขวาง (blockers) อาจยาวเหยียด วัฒนธรรมแห่งการตําหนิและความกลัวคือศัตรูตวั ฉกาจของการ
จัดการตัวเอง (self organization) ผูค้ นอาจมีไอเดีย แต่ถา้ พวกเขาถูกลงโทษแทนทีจะได้รบั คําชม พวกเขาจะเรียนรูท้ ีจะเก็บ
ไอเดียไว้กบั ตัวเองอย่างเงียบ ๆ อย่างน้อยในทีสาธารณะ และเลือกทําตามคําสังแทนทีจะเสนอวิธีแก้ปัญหาหรือทําการทดลอง
แต่ถึงแม้วา่ “ทุกองค์กรจะมีความพิเศษในแบบของตัวเอง” ความเป็ นเอกลักษณ์ของพวกเขาก็มกั จะถูกพูดเกินจริง ใน
ฐานะทีเป็ นระบบ องค์กรมักแสดงลักษณะร่วมบางอย่าง บางสถานการณ์สามารถคาดเดาได้ในระดับหนึง ในทางปฏิบตั ิ มีสิง
กีดขวางบางอย่างทีเกิดขึนซํา ๆ ซึงเป็ นอุปสรรคต่อความคิดริเริมทีดีหลายประการ
สิงกีดขวางอันดับ 1: การขาดความเข้าใจในระบบโดยรวม
การทําความเข้าใจระบบ
นักศึกษามหาวิทยาลัยทีแชร์อพาร์ตเมนต์รว่ มกันจะต้องหาวิธีจดั การตัวเองเกียวกับงานพืนฐาน เช่น การทําความ
สะอาด การซือของเข้าบ้าน และการทําอาหาร อาจต้องใช้เวลา แต่วนั หนึงพวกเขาจะรวมตัวกันในห้องเดียวกัน มีการพูดคุยกัน
อย่างตรงไปตรงมา และในทีสุดก็หาข้อตกลงใหม่ ๆ ได้ ในสถานการณ์แบบนี การหาข้อตกลงทําได้งา่ ยเพราะวงจรป้อนกลับ
(feedback loops) นันสัน และไม่มีแหล่งภายนอกมากนักให้โยนความผิด
ในระบบทีใหญ่ขึน การจัดการตัวเองอาจทําได้ยากกว่า: วงจรป้อนกลับใช้เวลานานกว่าจะเห็นผล ผลกระทบจากการ
กระทําบางอย่างอาจปรากฏให้เห็นได้ในทีอืนของระบบเท่านัน (ดังนันจึงไม่ใช่ปัญหาของเราอีกต่อไป) ในองค์กรขนาดใหญ่
แผนกต่าง ๆ จะถูกมองว่าเป็ นหน่วยงานแยกออกจากกัน หรือแม้แต่ถกู จ้างให้บคุ คลภายนอกทําแทน (outsourced) ซึงเพิม
โอกาสในการโยนความผิดให้คนอืนมากขึน
เรามีปัญหา -> ปัญหามาจากแหล่งภายนอก -> ฉันทําอะไรไม่ได้เกียวกับมัน -> ปั ญหาแก้ได้แล้ว! -> ฉันจะทํางาน
แบบเดิมต่อไป
แน่นอนว่าปั ญหาไม่ได้ถกู แก้ไขจริง ๆ แต่ฉันเชือว่ากระบวนการคิดแบบนีคงคุน้ เคยสําหรับผูอ้ ่านหลายคน
อย่างไรก็ตาม นีคือสิงกีดขวางหลักของฉันต่อการจัดการตัวเอง (self organization):
ผูค้ นจะไม่สามารถจัดการตัวเองในระบบทีพวกเขาไม่เข้าใจ
หากผูค้ นไม่เข้าใจระบบโดยรวม การจัดการตัวเองเป็ นสิงทีทําได้ยากมาก
ผูค้ นจะไม่สามารถจัดการตัวเองในระบบทีพวกเขาไม่มีอทิ ธิพลต่อมัน
การอ่านค่าระบบ (readability) และการเข้าใจผลลัพธ์ทตามมาเป็
ี
นสิงสําคัญ
การแยกส่วนในองค์กร (Organization silos)
การแยกส่วนในองค์กรเป็ นตัวอย่างทีดีของการใช้แนวคิดทีซับซ้อนยุ่งยาก (complicated thinking) กับโดเมนทีซับซ้อน
(complex domain) หากองค์กรเป็ นเหมือนเครืองจักร การแบ่งแยกออกเป็ นหน่วยย่อยทีชัดเจนอาจดูเหมือนเป็ นทางเลือกที
สมเหตุสมผล แต่ลกู สูบ (piston) ไม่ได้หยุดงานยกเลิกหน้าทีของตัวเอง ยางรถยนต์ไม่ได้หมดกําลังใจและตัดสินใจไปทํางานให้
รถคันอืน และเกียร์ (gearbox) ก็ไม่ได้ใช้เวลาว่างไปบ่นเกียวกับสไตล์การขับรถของผูข้ บั
อย่างไรก็ตาม องค์กรส่วนใหญ่สดุ ท้ายแล้วก็ถกู จัดโครงสร้างให้อยู่ในรูปแบบของการแยกส่วน (silos) ไม่จาํ เป็ นต้องเป็ น
องค์กรขนาดใหญ่เพือแสดงอาการเหล่านี แม้แต่องค์กรเล็ก ๆ ผูค้ นก็มกั จะแสดงพฤติกรรมสองอย่างนีอย่างเลียงไม่ได้:
1. มุ่งเน้นไปทีขอบเขตความรับผิดชอบของตัวเอง (ซึงดูเหมือนจะเป็นความคิดทีดี);
2. ค่อย ๆ เพิกเฉยต่อสิงทีเกิดขึนในแผนกอืน ๆ
ทุกคนล้วนเป็ นผูเ้ ชียวชาญในส่วนงานของตนเอง (silo)
โดยดังเดิมแล้ว การแยกส่วนงาน (silos) ถูกมองว่าเป็ นสิงไม่ดี เนืองจากมันค่อย ๆ บ่อนทําลายความสามารถขององค์กร
ในการพัฒนาและตอบสนองต่อความท้าทายได้อย่างรวดเร็ว แต่จากมุมมองเชิงวิวฒ
ั นาการ การแยกส่วนงานกลับเป็ น “สาย
พันธุท์ ชนะ”
ี
ดังนันต้องมีบางอย่างพิเศษเกียวกับ silos ทีทําให้มนั ประสบความสําเร็จอย่างมาก
ในความเป็ นจริง silos มีความโดดเด่นในสิงหนึง: พวกมันช่วยลดปริมาณการเรียนรูท้ ีจําเป็ นสําหรับพนักงานใหม่
พนักงานทีเพิงเข้ามาไม่จาํ เป็ นต้องเรียนรูท้ ุกอย่างของระบบเพือทีจะรูส้ กึ ว่าตัวเองมีประสิทธิผล เพียงแค่เรียนรูส้ ่วนทีจําเป็ น
สําหรับงานของตัวเองก็เพียงพอแล้ว
ความเชียวชาญเฉพาะทาง (specialization) เป็ นทังผลลัพธ์ของ silos และเป็ นสิงทีช่วยให้เกิด silos เพิมขึนในอนาคต
อีกด้วย โอ๊ะ!
ด้านกลับทีอธิบายตัวเองได้งา่ ย:
Silos เพิมพูนความไม่รูโ้ ดยรวมในองค์กร
…ซึงอาจเป็ นเรืองดี หากคุณเกียวข้องกับสิงทีผิดกฎหมายหรือมีจริยธรรมทีน่าสงสัย แต่สาํ หรับองค์กรส่วนใหญ่ทีต้อง
เผชิญกับความท้าทายในตลาดและคู่แข่ง สิงนีจะย้อนกลับมาสร้างปัญหาในไม่ชา้ ก็เร็ว
อย่างไรก็ตาม มีสามประเด็นสําคัญทีเกียวข้องกับเรืองนี:
1. แรงผลักดันทีทําให้องค์กรทุกแห่งเกิด silos นันแข็งแกร่ง แรงผลักดันเหล่านีไม่ได้มาจากความชัวร้าย: ไม่
มีการสมคบคิดทีจะทําให้องค์กรกลายเป็ น silos สิงทีเกิดขึนคือผูค้ นพยายามทํางานของตัวเองและใช้วิธี
แก้ปัญหาเฉพาะทีซึงดูสมเหตุสมผลสําหรับปั ญหาในบริบทท้องถินของพวกเขา ในขณะเดียวกัน พวกเขา
ก็ค่อย ๆ ละสายตาจากความซับซ้อนทีเพิมขึนในส่วนทีพวกเขาไม่ได้มองเห็น
2. แรงผลักดันเหล่านีจะคงอยู่เสมอ หากไม่มกี ารดําเนินการปรับสมดุลอย่างชัดเจน silos จะเกิดขึนอย่าง
หลีกเลียงไม่ได้ นีคือความรับผิดชอบของเราทีจะต้องเผชิญกับปั ญหานี: การไม่ทาํ อะไรเลยเพือลด
ผลกระทบของ silos ถือเป็ นส่วนหนึงของปั ญหา
3. ปั ญหานีจะค่อย ๆ ยากเกินกว่าจะแก้ไข หรือมีค่าใช้จ่ายสูงเกินไป การเริมต้นองค์กรใหม่ หรือลาออกจาก
งานในทีสุดอาจกลายเป็ นทางเลือกทีน่าสนใจกว่าการทุ่มพลังงานไปกับการเปลียนแปลงสถานะทีเป็ นอยู่
(status quo) อย่างช้า ๆ
ทุกองค์กรแสดงออกถึงพฤติกรรม silo ในระดับหนึง ซึงสิงนีทําให้องค์กรทํางานได้อย่างไม่เต็มประสิทธิภาพ ลด
ความสามารถ หรือในกรณีทีเลวร้ายทีสุด อาจนําไปสู่ความล้มเหลว จุดเด่นทีไม่น่าพึงพอใจทีสุดของ silos คือ ความไม่สมดุล
ของมัน: silos สร้างขึนได้งา่ ย แต่กาํ จัดออกได้ยากมาก
จากมุมมองของเรา นีถือเป็ นโอกาสทีน่าสนใจ: มีปัญหาร่วมทีเกิดขึนซํา ๆ และเราสามารถมีเครืองมือทีทรงพลัง ซึงมุ่ง
เป้าตรงไปยังจุดทีสําคัญทีสุด
การกระจายความเชียวชาญทีไม่สมดุล
อย่างไรก็ตาม เมือเราพยายามจัดการกับปัญหาในพืนทีทีซับซ้อน คุณสมบัติอีกอย่างหนึงของ silos กลับกลายเป็ น
อุปสรรค: silos ส่งเสริมการกระจายความเชียวชาญทีไม่สมดุล
เมือจําเป็ นต้องใช้ความเชียวชาญหลายด้านร่วมกัน
สิงนีจะจํากัดวิธีทเราสามารถรวบรวมความรู
ี
ท้ จํี าเป็ นเพือแก้ไข
ปั ญหาทีซับซ้อน ความซับซ้อนเรียกร้องการเรียนรูแ้ ละการตัดสินใจทีสอดคล้องกับบริบท แต่ silos กลับแบ่งแยกการรับรูแ้ ละทํา
ให้ตน้ ทุนในการรวบรวมชินส่วนของปริศนาเพือนําไปสู่การแก้ปัญหาทีไม่ใช่เรืองง่ายเพิมขึนอย่างมาก
โดยปกติแล้ว เราจะต้องรับมือกับความรูแ้ ละความเชียวชาญทีหลากหลาย และข้อมูลทีเราได้รบั มักจะสอดคล้องกันใน
บริบทเฉพาะทีเท่านัน: ไม่มใี ครทีครอบครองความจริงทังหมด
ความเชียวชาญทีทับซ้อนและขัดแย้งกัน รวมถึงความไม่รูเ้ ช่นกัน
พูดตามตรง สถานการณ์จริงนันแย่ยิงกว่าทีคิด แม้แต่ความสอดคล้องกันในระดับท้องถินของความรูก้ ็ไม่ได้รบั การ
รับประกัน พนักงานเข้ามาและจากไป พวกเขาเรียนรูส้ าขาวิชาเดียวกันจากโรงเรียนหรือสถานทีทํางานก่อนหน้าทีแตกต่างกัน
พวกเขาอาจไม่เห็นด้วย บางครังถึงขันรุนแรง หรืออาจเห็นด้วยในแก่นของปั ญหา แต่ใช้คาํ ศัพท์ทีแตกต่างกันในการอธิบาย
พวกเขามักผสมปัญหาเข้ากับวิธีแก้ปัญหา หรืออธิบายความเป็ นจริงในแง่ของซอฟต์แวร์ทีใช้งานอยู่ในปัจจุบนั มันช่าง
ยุ่งเหยิงจริง ๆ
ดีล่ะ หยุดแสร้งทําเป็ นว่าสถานการณ์ไม่เป็ นเช่นนันกันเถอะ
ตอนนี แค่แนวคิดง่าย ๆ ในการรวบรวมข้อกําหนดสําหรับโครงการซอฟต์แวร์ท่ามกลางความยุ่งเหยิงนีก็ดเู ป็ นเรืองทีน่า
หวาดหวันแล้ว และจริง ๆ แล้วยังแย่กว่านันอีก เราจะพูดถึงเรืองนีในหัวข้อ Requirements Gathering is broken ในอีกไม่กีหน้า
ถัดไป
การทําเงินจากความยุ่งเหยิงนี
องค์กรควรมีจดุ มุง่ หมาย บางทีอาจเป็ นการให้บริการแก่ลกู ค้าหรือพลเมือง อาจเป็ นการทําเงินจํานวนมาก หรือเหมือน
ในภาพยนตร์ของ James Bond ทีมีเป้าหมายเพือปกครองโลกและเลียงแมวขนปุยสีขาว
ธุรกิจทุกอย่างจําเป็ นต้องใช้ความเชียวชาญและทักษะทีหลากหลายเพือประสบความสําเร็จ ลองพิจารณาธุรกิจร้านค้า
ออนไลน์ขนาดเล็ก เช่น Etsy12 สําหรับขายสินค้าทีทําด้วยมือ แม้แต่ธุรกิจขนาดเล็กทีสุดแบบนีก็ยงั ต้องการความเชียวชาญใน
หลายด้าน เช่น:
 ออกแบบ (Design): เจ้าของร้านต้องคิดว่าจะผลิตอะไร
 การจัดหา (Supply): ต้องซือขนสัตว์และเครืองมือถัก หากคุณต้องการผลิตสินค้าทีไม่เหมือนใคร การหา
วัตถุดิบพิเศษจึงกลายเป็ นสิงสําคัญ
 การผลิต (Production): ต้องมีใครสักคนทํางานฝี มือ และต้องมีความเชียวชาญพอทีจะสร้างสิงทีสวยงาม
 เนือหา (Content): สินค้าต้องถูกอธิบายและแสดงผลให้ดี ภาพทีสวยงามและเรืองราวเล็กน้อยสามารถสร้าง
ความแตกต่างอย่างมากบนโลกออนไลน์
 การจัดส่ง (Delivery): ผูใ้ ห้บริการทีแตกต่างกันจะทําหน้าทีจัดส่งสินค้า แต่ยงั ไงก็ตอ้ งมีคนเรียนรูว้ ธิ ีโต้ตอบกับ
พวกเขา
 การบรรจุภณ
ั ฑ์ (Packaging): การหาวิธีทีสวยงามและเหมาะสมในการปกป้องสินค้าของคุณอาจเป็ นเรือง
ยุ่งยาก
 การจัดการคําร้องเรียน (Claims): คุณจะต้องกลายเป็ นผูเ้ ชียวชาญทันทีทีคุณได้รบั คําร้องเรียนครังแรก
 การทําบัญชี (Bookkeeping): การติดตามต้นทุนและรายได้
 ภาษีและกฎระเบียบ (Taxes and regulations): คุณคิดว่ามันง่าย แต่จากนันด้วยเหตุผลบางอย่าง คุณก็พบว่า
สินค้าสีชมพูมอี ตั ราภาษีทแตกต่
ี
างในประเทศทีคุณไม่เคยรูว้ า่ มีอยู่
 การเผยแพร่ (Publishing): แพลตฟอร์มอาจซ่อนความซับซ้อนมากมายจากผูใ้ ช้ แต่ยงั ไงก็ตอ้ งมีคนเรียนรูว้ ิธีใช้
งานแพลตฟอร์ม
 SEO (Search Engine Optimization): ใครจะขายของออนไลน์ได้โดยไม่หมกมุ่นกับสถิตกิ ารเข้าชม และหาวิธี
ปรับปรุงมัน เช่น การเลือกคียเ์ วิรด์ ทีเหมาะสม และอืน ๆ
 การสร้างชุมชน (Community Building): แน่นอนว่ามันคือการสนทนาก่อนการขาย และชุมชนก็ตอ้ งการการมี
ส่วนร่วมด้วย
ฮืม... ดูเหมือนจะไม่งา่ ยอย่างทีคิด แล้วลองนึกถึงบริษัทขนาดใหญ่สิ
ฮืม…
อย่างไรก็ตาม ขอบเขตความรูท้ ต้ี องเชียวชาญเพือดําเนินธุรกิจนันมีหลากหลาย แต่ละด้านมีความเชียวชาญเฉพาะตัว
ไม่ใช่ทุกคนทีจะต้องเป็ นผูเ้ ชียวชาญในทุกเรือง: บางคนอาจเก่งมากในบางสิง และเพียงแค่ "พอใช้ได้" ในด้านทีไม่สาํ คัญมากนัก
ในร้านเล็ก ๆ อย่าง Etsy ของเรา สิงเหล่านียังไม่ใช่ silos แต่เราพอจะเดาได้วา่ ทําไม silos ถึงเกิดขึน: เมือบริษัทเติบโต
ขึน การจ้างพนักงานใหม่ทาํ ให้บางคนสามารถละเลยบางพืนทีของงานได้ เพราะไม่มใี ครอยากรูเ้ รืองราวทังหมด
กระบวนการทางธุรกิจตัดผ่าน silos
กระแสงาน (business flow) ในองค์กรไม่ได้จาํ กัดอยูใ่ นพืนทีใดพืนทีหนึงเท่านัน แต่ปกติแล้วจะครอบคลุมหลายด้าน
ของความเชียวชาญ
กระแสงาน (business flow) ตัดผ่าน silos และขอบเขตของความเชียวชาญ
หลักฐานทีชัดเจนคือ แหล่งความรูเ้ พียงแหล่งเดียวไม่เพียงพอทีจะแก้ปัญหาทีครอบคลุมหลายด้านได้
องค์กร
องค์กรไม่ใช่เครืองจักรทีสมบูรณ์แบบ ไม่ว่าคุณจะใส่ความคาดหวังหรือความเชือเกียวกับพลังการเยียวยาของตลาดเสรี
มากแค่ไหน องค์กรก็ไม่ใช่ผลลัพธ์ทีน่าทึงของพลังวิวฒ
ั นาการแบบดาร์วิน เช่น การอยู่รอดของผูท้ ีเหมาะสมทีสุด (survival of
ั เป็ นจริงแค่ในระดับหนึงเท่านัน
the fittest) จริงอยู่... แต่นนก็
องค์กรไม่จาํ เป็ นต้องสมบูรณ์แบบ หากพวกเขาอยู่ในตลาด สิงทีพวกเขาต้องทําคือเอาชนะคูแ่ ข่ง หรือหาช่องทาง
เฉพาะทีรับประกันการอยู่รอด ไม่ใช่เรืองแปลกทีจะพบองค์กรทีมีความบกพร่อง แม้กระทังในตลาดทีมีการแข่งขันสูง โดยเฉพาะ
อย่างยิงหากคู่แข่งมีพืนฐานทางวัฒนธรรมทีคล้ายคลึงกัน
นอกจากนี การพบองค์กรทีเติบโตตามแผนการออกแบบเฉพาะนันค่อนข้างหายาก โดยทัวไปแล้ว องค์กรมักจะ
ตอบสนองและปรับตัวให้เข้ากับปั จจัยขับเคลือนตลาด (รวมถึงตลาดแรงงาน) ทีหล่อหลอมพวกเขา
ขอบเขตความเชียวชาญเฉพาะทาง
สถานการณ์ไม่ได้ดีขึนเมือเราซูมเข้าไปดูในแต่ละขอบเขตของความเชียวชาญ สิงทีดูเหมือนฟองอากาศในภาพก่อนหน้า
นี แท้จริงแล้วพร่ามัวกว่าทีเราต้องการ
สิงทีผูเ้ ชียวชาญรูแ้ ละสิงทีพวกเขาคิดว่ารู ้ อาจไม่ใช่สิงเดียวกัน เมือถูกถามเกียวกับสิงทีพวกเขาคิดว่ารู ้ พวกเขาอาจให้
คําตอบทีไม่ถกู ต้องได้โดยสุจริตใจ กล่าวอีกนัยหนึงคือ ผูค้ นจะให้คาํ อธิบายตามระดับความเข้าใจในปั จจุบนั ของพวกเขาใน
โดเมนของปั ญหา ประสบการณ์และความตังใจดีไม่เพียงพอทีจะรับประกันว่าคําอธิบายนันจะสอดคล้องกับความเป็ นจริง
เมือผูเ้ ชียวชาญถูกถามถึงสิงทีอยูน่ อกขอบเขตความเชียวชาญของพวกเขา พวกเขาอาจให้คาํ ตอบกับคุณได้ (ซึงอาจ
ช่วยแก้ปัญหาให้คณ
ุ ในขณะนัน หากคุณกําลังสืบค้นอยู่) แต่ไม่จาํ เป็ นต้องบอกคุณว่าคุณควรถามคนอืนเพือให้ได้ความแม่นยํา
ทีมากขึน
ขอบเขตความเชียวชาญเฉพาะทาง
สถานการณ์ไม่ได้ดีขึนเมือเราซูมเข้าไปดูในแต่ละขอบเขตของความเชียวชาญ สิงทีดูเหมือนฟองอากาศในภาพก่อนหน้า
นี แท้จริงแล้วพร่ามัวกว่าทีเราต้องการ
 สิงทีผูเ้ ชียวชาญรูแ้ ละสิงทีพวกเขาคิดว่ารู ้ อาจไม่ใช่สิงเดียวกัน เมือถูกถามเกียวกับสิงทีพวกเขาคิดว่ารู ้ พวก
เขาอาจให้คาํ ตอบทีไม่ถกู ต้องได้โดยสุจริตใจ กล่าวอีกนัยหนึงคือ ผูค้ นจะให้คาํ อธิบายตามระดับความเข้าใจ
ในปั จจุบนั ของพวกเขาในโดเมนของปั ญหา
ประสบการณ์และความตังใจดีไม่เพียงพอทีจะรับประกันว่า
คําอธิบายนันจะสอดคล้องกับความเป็ นจริง
 เมือผูเ้ ชียวชาญถูกถามถึงสิงทีอยูน่ อกขอบเขตความเชียวชาญของพวกเขา พวกเขาอาจให้คาํ ตอบกับคุณได้
(ซึงอาจช่วยแก้ปัญหาให้คณ
ุ ในขณะนัน หากคุณกําลังสืบค้นอยู่) แต่ไม่จาํ เป็ นต้องบอกคุณว่าคุณควรถามคน
อืนเพือให้ได้ความแม่นยําทีมากขึน
 สิงนีเป็ นจริงอย่างยิงเมือจัดการกับลูกค้าหรือผูใ้ ช้งานทีอยู่นอกองค์กร
ผูเ้ ชียวชาญสามารถบอกได้อย่าง
แม่นยําในระดับหนึงว่าทําไมพวกเขาถึงทําสิงต่าง ๆ ทีกําหนดไว้ แต่เมือพวกเขาพูดถึงผูใ้ ช้หรือลูกค้า สิงทีพวก
เขานําเสนอจะเป็ นการคาดเดาทีมีขอ้ มูลสนับสนุนเป็ นหลัก
มีสงที
ิ ฉันรู ้ และสิงทีฉันรูเ้ ป็ นอย่างดี
แม้แต่ในด้านทีเรารูด้ ี ก็ยงั สามารถมีความไม่สอดคล้องกันเกิดขึนได้ เราไม่ได้เรียกสิงต่าง ๆ ด้วยคําเดียวกันเสมอไป ฉัน
ยังจําบทเรียนเก่าจากอาจารย์สอนภาษาอิตาลีของฉันได้ดี ทีสอนให้ฉนั ใช้คาํ พ้องความหมาย (synonyms) ทุกครังทีทําได้ เพือ
หลีกเลียงการทําให้ผอู้ ่านเบือกับการใช้คาํ ซํา ๆ ลองจินตนาการถึงผลกระทบของวิธีการนีในเอกสารข้อกําหนดทางเทคนิคดูสิ
เรืองราวส่วนตัวก็อาจผสมเข้ามาได้เช่นกัน คนทีมาจากบริษัทอืนอาจมีศพั ท์เฉพาะทางทีแตกต่าง และอยู่ในระหว่างการ
เปลียนแปลงศัพท์นนให้
ั เป็ นสิงใหม่ โดยทัวไป เรามักมองว่าภาษาเป็ นเครืองมือทีสอดคล้องกันสําหรับแสดงความรูข้ องเรา แต่
ในความเป็ นจริง มันไม่เป็ นเช่นนัน
ยิงไปกว่านัน ผูค้ นมักสับสนระหว่างข้อเท็จจริงและความคาดหวัง เช่น ประโยคทีว่า “การชําระเงินควรจะมาถึงตรงเวลา
เสมอ” อาจสร้างความเข้าใจผิดได้อย่างมากเกียวกับข้อเท็จจริงทีว่า “ในความเป็ นจริง การชําระเงินอาจมาถึงแบบสุ่มเวลา จาก
ลูกค้าทีเราต้องการ และหวังว่าจะมีจาํ นวนเงินตามทีคาดหวัง” และเรามีการควบคุมเรืองนีได้เพียงเล็กน้อยเท่านัน
ผลลัพธ์โดยรวมคือ เราไม่สามารถเชือมันในสิงทีผูค้ นบอกเราได้อย่างสุ่มสีสุ่มห้า เราไม่สามารถสมมติได้วา่ ความรูข้ อง
ผูเ้ ชียวชาญนันสอดคล้องกัน แต่ - ในฐานะผูเ้ รียนรู ้ - เราไม่ควรละเลยข้อจํากัดนี
ลําดับชัน (Hierarchy)
การมีอยูข่ องลําดับชันมีความสัมพันธ์อย่างมากกับ silos ในองค์กร ลําดับชันเป็ นรูปแบบการจัดองค์กรทียืดหยุ่น และ
สําหรับหลายคนในองค์กรต่าง ๆ มันเป็ นวิธีเดียวทีจะจัดโครงสร้างองค์กรได้
การพูดถึงรูปแบบทางเลือกของการจัดองค์กรอยู่นอกขอบเขตของหนังสือเล่มนี แต่ฉนั ขอแนะนําให้ดหู นังสือ
Connected Company โดย Dave Gray ทีสํารวจโครงสร้างองค์กรแบบต่าง ๆ และหลักการทีเป็ นแนวทางของมัน
The
เช่นเดียวกับ silos เราอาจต้องยอมรับการมีอยู่ของลําดับชันว่าเป็ นข้อเท็จจริงในชีวิต แต่เราต้องคํานึงถึงผลทีตามมาที
พบบ่อยด้วยเช่นกัน:
 ลําดับชันเสริมสร้าง silos: ผูค้ นมักจะถูกจ้าง ฝึกอบรม และเลือนตําแหน่งภายใน silo และหน้าทีรวมถึงรางวัล
ของพวกเขาก็มกั จะอยู่ภายในขอบเขตของ silo นัน
 ลําดับชันแบ่งแยกความรับผิดชอบ: แต่องค์กรสามารถซับซ้อนเกินกว่าจะเป็ นเพียงผลรวมของแผนกต่าง ๆ ใน
องค์กร
 ปั ญหาภายในขอบเขตของ silos มักจะได้รบั การแก้ไขเร็วกว่าปั ญหาทีข้าม silos หรือปัญหาใน "พืนทีไร้
เจ้าของ" (no man’s land) ในความเป็ นจริง ปั ญหาทีไม่ได้อยู่ภายใต้ความรับผิดชอบทีชัดเจน มักมีแนวโน้มที
จะกลายเป็ นปั ญหาเรือรัง
การปะทะกันระหว่างลําดับชัน (Hierarchy) และกระแสงาน (Business Flow)
เมือสองสามปี ก่อน ฉันมีโอกาสได้เห็น Niels Pflaeging ทําการบรรยายที Stoos Stampede ในอัมสเตอร์ดมั ซึงเรียกได้
ว่าเป็ นเซสชันทีเปรียบเสมือน "หมัดตรงเข้าทีหน้า"
เขาได้อธิบายว่าในทุกองค์กร มีเครือข่ายสามประเภทหลักทีเชือมโยงผูค้ นเข้าด้วยกัน:
 ลําดับชัน (Hierarchy): โครงสร้างแบบบนลงล่างทีเป็ นแบบคงที ซึงมักอธิบายผ่านผังโครงสร้างองค์กร
(organization chart)
 โครงสร้างทีไม่เป็ นทางการ (Informal Structure): เครือข่ายทีเกิดขึนจากความสัมพันธ์และความสามารถ
(affinity- and competence-based network) ซึงเป็ นกลุม่ คนทีเรามักจะขอความช่วยเหลือในหัวข้อต่าง ๆ
 เครือข่ายการสร้างมูลค่า (Value Creation Network): เครือข่ายทีเกียวข้องกับกลุ่มคนทีเราจําเป็ นต้องร่วมมือ
กันเพือส่งมอบสินค้าและบริการ
ข้อสรุปของเขาคือ: “มีเพียงเครือข่ายทีสองและสามเท่านันทีสร้างมูลค่า ลําดับชันไม่ได้สร้างมูลค่า” โอ้โห
รูปร่างของปั ญหา
ลองมองข้อความข้างต้นในมุมกลับ: มีปัญหาบางประเภททีมักจะคงอยู่นานในองค์กร บางครังปัญหาเหล่านีมีมานาน
จนผูค้ นไม่ได้มองว่ามันคือปัญหาอีกต่อไป แต่กลับมองว่ามันเป็ นเพียงส่วนหนึงของภูมิทศั น์ในองค์กร
ปั ญหาประเภทนีมีลกั ษณะดังนี:
 ยากทีจะแก้ไข: เพราะต้องการความเห็นชอบจากผูม้ ีส่วนได้ส่วนเสียจํานวนมาก
 ยากทีจะพูดถึง: เพราะเกียวข้องกับผูค้ นหลายกลุ่ม ซึงมักพยายามหลีกเลียงการถูกตําหนิโดยทําสิงต่าง ๆ ให้
ถูกต้องในขอบเขตของ silo ของตัวเอง การสนทนามักวนเวียนอยู่กบั ประโยคทีว่า “คุณก็รู ้ ปั ญหาทีแท้จริงคือ
[ปัญหาของคนอืน]”
 ยากทีจะมองเห็น: เพราะเกียวข้องกับแง่มมุ ทีพึงพาอาศัยกันในด้านความเชียวชาญทีแตกต่างกัน
ข่าวดี
EventStorming ช่วยให้การเรียนรูเ้ กิดขึนข้ามขอบเขตของ silos ได้ มันไม่ใช่โครงการเพือเปลียนแปลงองค์กร แต่เป็ น
เครืองมือทีช่วยให้เข้าใจว่าอะไรเกิดขึนในระดับทีกว้างขึน
เราจะเห็นว่า การขอให้ผมู้ ีส่วนได้ส่วนเสียมาร่วมกันสร้างแบบจําลองกระแสงานทีซับซ้อน (complex business flow) จะ
เปิ ดเผยความขัดแย้งและความไม่สอดคล้องกันทีเกิดขึนตรงขอบเขตระหว่าง silos ได้มากมาย
มันยังช่วยให้เรามองหาวิธีแก้ปัญหาทีเหมาะสมทีสุดในระดับระบบ (system-optimal solutions) ซึงเป็ นเรืองยาก เพราะ
ระบบโดยรวมมักมองเห็นได้ยาก แทนทีจะหาวิธีแก้ปัญหาเฉพาะจุดทีด้อยประสิทธิภาพ (local sub-optimal solutions) และ
การเมืองทีไร้ประโยชน์เพือรองรับมัน
ข่าวร้าย
ผลลัพธ์ทมีี คุณค่าทีสุดจากเวิรก์ ช็อป Big Picture EventStorming คือการสร้างการรับรูต้ นเองในระดับลึกขององค์กร แต่
ในขณะเดียวกัน นีก็เป็ นหนึงในจุดขายทีแย่ทสุี ดเช่นกัน
“เวิรก์ ช็อปนีจะช่วยให้คณ
ุ เข้าใจบริษัทของคุณดีขึน”
คุณกําลังจะบอกว่าฉันไม่เข้าใจบริษัททีฉันทํางานมาหลายปี แล้วอย่างนันหรือ? แม้ว่าคุณจะพูดถูก และคุณจะมอบ
ข้อมูลเชิงลึกทีมีคุณค่าให้ก็ตาม แต่ช่วยตัวเองเถอะ และอย่าใช้ประโยคนีเป็ นจุดขาย เพราะมีโอกาสสูงทีมันจะกลายเป็ น "การ
ฆ่าตัวตายทางการเมือง" ในบริษทั ของคุณเอง
เป้าหมายของบทนี:
 พืนฐานของความซับซ้อนและความจําเป็ นในการจัดการตัวเอง (self organization)
 ไม่สามารถจัดการกับระบบทียังไม่เข้าใจได้
 เกือบทุกองค์กรมีความบกพร่องทีคล้ายกับ silos และการเรียนรูภ้ าพรวม (big picture) จะไม่ก่อให้เกิดผลเสีย
3 ทําเป็ นว่าแก้ปัญหาได้ดว้ ยการเขียนซอฟต์แวร์
ซอฟต์แวร์มกั ถูกมองว่าเป็ นหัวใจสําคัญของการดําเนินงานในองค์กรและธุรกิจ
เพราะช่วยให้การทํางานราบรืนและ
รวดเร็วกว่าขันตอนแบบดังเดิม นอกจากนี ซอฟต์แวร์ยงั เป็ นเครืองมือสําคัญสําหรับแพลตฟอร์มธุรกิจแนวใหม่ทีสร้างความ
เปลียนแปลงในวงการต่างๆ ได้อย่างมหาศาล
แต่ความจริงแล้ว ไม่ใช่ทกุ ปั ญหาทีซอฟต์แวร์จะแก้ไขได้ บ่อยครังซอฟต์แวร์ทีพัฒนาเพือแก้ปัญหาอย่างหนึง กลับสร้าง
ปั ญหาใหม่ในอีกจุดหนึงโดยไม่ตงใจ
ั
บทนีจึงมุ่งทําความเข้าใจว่าทําไม และอย่างไรทีนักพัฒนาซอฟต์แวร์หรือสถาปนิก
ซอฟต์แวร์ แม้จะมีความตังใจดี แต่ก็มกั ทําให้เกิดปั ญหาทีซับซ้อนขึนในกระบวนการทํางาน
มันไม่ใช่แค่ ‘การส่งมอบซอฟต์แวร์’
บาปดังเดิมในวงการพัฒนาซอฟต์แวร์คือการเข้าใจผิดเกียวกับธรรมชาติทีแท้จริงของงานนี นักพัฒนาซอฟต์แวร์มกั ถูก
ฝึ กและจ่ายเงินตามความเชือว่าผลลัพธ์ทมีี ค่าเพียงอย่างเดียวคืองานทีส่งมอบได้ นันคือซอฟต์แวร์ททํี างานได้จริง
นักพัฒนามักมองว่าตนเองเป็ นเหมือนช่างฝี มือ ผูส้ ร้างสิงใหม่ ซึงเป็ นสิงทีดึงดูดใจและให้พลังในตัวเอง เพราะการสร้าง
ซอฟต์แวร์ทีไม่เคยมีมาก่อนและสามารถใช้งานได้จริงนัน เป็ นความรูส้ กึ ทียอดเยียมและสร้างความตืนเต้นแบบเสพติดได้
อย่างไรก็ตาม การเขียนโค้ด แม้จะต้องใช้ทกั ษะทีซับซ้อนและเครืองมือทีเชียวชาญ แต่แท้จริงแล้วเป็ นเพียงส่วนยอดของ
ภูเขานําแข็ง การพัฒนาซอฟต์แวร์ทีดีในระดับองค์กร สิงสําคัญยิงกว่าคือการเข้าใจปัญหาทีแท้จริง
เรืองนีคล้ายกับดนตรี การเล่นเพลงอาจไม่ยากสําหรับนักดนตรีทีมีประสบการณ์ แต่การแต่งเพลงนันต้องใช้พรสวรรค์!
เพือสรุปในรูปแบบทีทวีตได้:
การพัฒนาซอฟต์แวร์คือกระบวนการเรียนรู ้ โค้ดทีใช้งานได้ เป็ นเพียงผลพลอยได้
คนทีอธิบายเรืองนีได้ดีทีสุดคือ Dan North ในบทความบล็อกของเขาเรือง “Introducing Deliberate Discovery” ซึง
ชีให้เห็นอย่างชัดเจนว่าการเรียนรูเ้ ป็ นอุปสรรคสําคัญทีแท้จริงในกระบวนการพัฒนาซอฟต์แวร์ระดับองค์กร
ปั ญหาไม่ได้อยู่ทีการเขียนโค้ด แต่อยู่ทีการเข้าใจปั ญหาอย่างลึกซึง อย่างไรก็ตาม เมือคุณยอมรับความจริงข้อนี คุณจะ
เริมเห็นความไม่สอดคล้องกันในหลายๆ ด้านของกระบวนการพัฒนาซอฟต์แวร์ทีค่อยๆ เผยตัวออกมา
เราแก้ผิดที!
ปั จจุบนั เราสามารถติดตังส่วนประกอบแบบไร้เซิรฟ์ เวอร์บนคลาวด์ได้ในไม่กีนาที ซึงเป็ นเรืองน่าทึงเมือย้อนคิดว่าการ
พัฒนาซอฟต์แวร์เริมต้นจากการใช้การ์ดเจาะรู ตอนนีเราสามารถเขียนโค้ดได้เร็วกว่าหลายเท่า และเราใช้ความเร็วนีเพิมชันโค้ด
ในระบบ ตังแต่คอมพิวเตอร์ขนาดห้องไปจนถึงสถาปัตยกรรมทีกระจายตัว
อย่างไรก็ตาม แม้เราจะเร่งความเร็วในการเขียนโค้ดจนถึงจุดทีมันไม่ใช่ขอ้ จํากัดหลักอีกต่อไป การมีเครืองมือพัฒนา
(IDE) ลําสมัยพร้อมฟี เจอร์ช่วยเขียนโค้ดดูนา่ ทึง แต่ถา้ เราไม่สามารถเข้าถึงข้อมูลทีถูกต้อง ก็ไม่ได้ช่วยให้ส่งมอบซอฟต์แวร์ทีดี
ขึนได้มากนัก
ั นาการเรียนรูใ้ นกระบวนการพัฒนาซอฟต์แวร์ให้ดีขึนมากนัก ในซอฟต์แวร์ระดับองค์กร
สิงทีน่าอายคือเรายังไม่ได้พฒ
ใหญ่ๆ นักพัฒนามักถูกแยกออกจากผูใ้ ช้จริงและไม่ได้รบั ข้อมูลโดยตรง มีหลายบทบาทเข้ามาเป็ นตัวกลางจนการเรียนรูถ้ กู
มองข้าม
แนวคิดแบบ “แค่ทาํ ตามข้อกําหนดไปสิ” ยังคงเป็ นเรืองปกติ แต่ถา้ พูดตรงๆ หลายๆ แนวทางการจัดการพัฒนา
ซอฟต์แวร์ในองค์กรนันไร้ประสิทธิภาพ เพราะเน้นการเพิมผลผลิตมากกว่าการเรียนรู ้ ซึงเหมือนกับการพยายามลดนําหนักโดย
ไม่ใส่ใจพฤติกรรมการกิน การออกกําลังกาย หรือไลฟ์ สไตล์ประจําวันเลย
คุณค่าของโค้ดทีเขียนตรงเวลาและอยู่ในงบประมาณโดยคนทีไม่เข้าใจปัญหาคืออะไร?
นีเป็ นทังปัญหา - ทรัพยากรมหาศาลถูกใช้อย่างสินเปลืองไปกับโครงการซอฟต์แวร์ขนาดใหญ่ทีไม่เคยสามารถสร้าง
คุณค่าตามทีคาดหวังได้ - และเป็ นโอกาส ในช่วงเวลาทีเราเริมทํางานโดยมุง่ เน้นไปทีปั ญหาทีแท้จริง เราอาจมีโอกาสทีจะ
ปรับปรุงสถานการณ์ได้อย่างมีนยั สําคัญ
ปั ญหาของ 'ผลลัพธ์ทีมองไม่เห็น'
การเปรียบเทียบงานพัฒนาซอฟต์แวร์กบั งานก่อสร้างเป็ นเรืองทีน่าดึงดูดและพบได้บ่อย เพราะงานก่อสร้างให้ผลลัพธ์ที
ชัดเจนและน่าภาคภูมใิ จ เช่น การสร้างสะพานทีช่วยเชือมโยงระหว่างประเทศ หรือช่วยลดเวลาการเดินทางได้ยาวนานหลาย
สิบหรือหลายร้อยปี แม้คณ
ุ จะมีส่วนร่วมเพียงเล็กน้อย คุณก็สามารถภูมใิ จในสิงทีคุณทําได้ ซอฟต์แวร์บางตัวก็ให้ความรูส้ กึ
แบบเดียวกัน แม้บางส่วนของมันจะฝังอยูใ่ นโครงสร้างลึกๆ ทีไม่มใี ครมองเห็นก็ตาม
การเป็ นผูเ้ รียนรูแ้ ทนทีจะเป็ นผูส้ ร้างไม่ใช่เรืองง่าย นักพัฒนาทีมีความสามารถมักเป็ นผูท้ ีชอบเรียนรูด้ ว้ ยความอยากรู ้
อยากเห็น และภูมใิ จเมือสามารถแก้ปัญหาได้ แต่การนําการเรียนรูม้ าเป็ นศูนย์กลางของทุกสิงนันทําได้ยากเพราะ:
• เราไม่มเี กณฑ์ชดั เจนหรือจุดสินสุด: เราควรหยุดเรียนรูเ้ มือไร? เรียนรูม้ ากพอหรือยัง?
•
•
•
•
•
การวัดผลการเรียนรูท้ าํ ได้ยาก: เราจะติดตามความคืบหน้าของการเรียนรูอ้ ย่างไร?
การมองการเรียนรูเ้ ป็ นทรัพย์สินหรือภาระ: เราควรจัดการการเรียนรูอ้ ย่างไร?
หลังจากซอฟต์แวร์เสร็จแล้ว การเรียนรูห้ ายไปไหน: มันถูกบันทึกไว้ในซอฟต์แวร์หรือเอกสารหรือไม่?
ความรูท้ ีไม่ได้ถกู ใส่ลงในซอฟต์แวร์จะเป็ นอย่างไร: จะหายไปตลอดกาลหรือเปล่า?
ั
ญหายหรือไม่?
เมือผูท้ ีเข้าใจปั ญหาลึกซึงลาออก: ความรูน้ นจะสู
การวัดผลเพียงแค่สิงทีส่งมอบเป็ นเรืองง่ายกว่า แต่ความง่ายนีเป็ นอันตราย เพราะมูลค่าทีแท้จริงขององค์กรไม่ได้อยู่ที
ตัวซอฟต์แวร์ แต่อยู่ทีความสามารถขององค์กรในการใช้ซอฟต์แวร์เพือสร้างคุณค่า
ความไม่แน่นอนของการเรียนรู ้
ในมุมมองของการจัดการ การเรียนรูอ้ าจเป็ นสิงทีน่ารําคาญ เพราะถ้าลองตังการเรียนรูใ้ ห้เป็ นศูนย์กลางของงาน คุณ
อาจต้องยอมรับว่าองค์กรของคุณเคยทําผิดพลาดอย่างมาก
ตัวอย่างเช่น หากคุณจ้างผูร้ บั เหมาสําหรับโครงการเชิงกลยุทธ์ เมือโครงการเสร็จสิน หากผลลัพธ์ทีต้องการคือโค้ด คุณ
อาจคิดว่าทุกอย่างเรียบร้อยแล้ว แต่ถา้ ผลลัพธ์ควรเป็ น "การเรียนรู"้ การทํางานร่วมกับผูร้ บั เหมาในลักษณะนีอาจทําให้ความรู ้
ทังหมดหายไปพร้อมกับจบโครงการ
การประหยัดต้นทุนทีดูเหมือนจะเกิดขึนจริง ๆ แล้วเป็ นเพียงภาพลวงตา กลยุทธ์ทดูี สมเหตุสมผลนี กลับเป็ นทางลัดทีทํา
ให้องค์กรสูญเสียความสามารถและศักยภาพไปในระยะยาว
ภาพลวงของโมเดลพืนฐาน
แทบทุกคนทีมีส่วนร่วมในการเขียนซอฟต์แวร์มกั มีเป้าหมายทีซ่อนอยู่ นันคือพวกเขาอยากทํางานให้ดี ฟังดูไม่น่ากลัวใช่
ไหม? และยังสอดคล้องกับแนวคิด "สามประการ" ของ Daniel Pink คือ อิสระในการทํางาน (Autonomy), ความเชียวชาญ
(Mastery) และ เป้าหมายทีมีความหมาย (Purpose) ดังนันจึงไม่น่าจะเป็ นปัญหา
แต่ปัญหาคือ นักพัฒนาซอฟต์แวร์จาํ นวนมากไม่มีประสบการณ์ว่า "งานทีดี" ควรมีหน้าตาเป็ นอย่างไร หากงานหลักที
พวกเขาทําคือการแก้บกั พวกเขาอาจมองว่าตัวเองเป็ นแค่ "ผูแ้ ก้บก"
ั
การจมอยู่กบั การแก้ปัญหาเดิมๆ หรือพูดกับตัวเองว่า "ถ้าฉันมีเวลา ฉันคงออกแบบระบบทีดีกว่านีได้" อาจทําให้คณ
ุ
มองข้ามจุดบอดสําคัญ นันคือการขาดตัวอย่างทีดีจากโลกอุตสาหกรรมจริงๆ
เมือไม่มตี วั อย่างจริงให้เรียนรู ้ สิงทีเหลืออยู่ให้ยึดถือคือ "สิงทีเราเคยเรียนในโรงเรียน" แต่ปัญหาคือ โครงการทีเราเคยทํา
ในมหาวิทยาลัยมักเป็ นโครงการจําลองเล็กๆ ทีไม่มีความซับซ้อนเทียบเท่าระบบในโลกธุรกิจจริง และยังขาดองค์ประกอบ
สําคัญหลายอย่างทีจําเป็ นในการพัฒนาซอฟต์แวร์ระดับองค์กร
สิงทีมหาวิทยาลัยมักลืมสอน
มีลกั ษณะร่วมบางอย่างในวิธีการสอนวิทยาการคอมพิวเตอร์ในหลายแห่งทัวโลก ซึงไม่สอดคล้องกับทักษะทีจําเป็ นใน
โลกความเป็ นจริงสําหรับมืออาชีพด้านซอฟต์แวร์ เรืองนีส่วนใหญ่เกียวข้องกับรูปแบบการศึกษา และบางสถาบันได้
พยายามแก้ปัญหานีและพัฒนาขึนอย่างมาก แต่สาํ หรับส่วนใหญ่แล้ว…
 แบบฝึ กหัดการเขียนโปรแกรมมักเป็ นเรืองของการแปลงข้อกําหนดไปเป็ นโค้ด: งานทีได้รบั มอบหมายเขียนโดย
อาจารย์และมักจะเหมือนกันสําหรับนักเรียนทุกคน แต่ในโลกความเป็ นจริง เราอาจต้องสํารวจความต้องการ
ของผูใ้ ช้อย่างแท้จริง และการแปลงข้อกําหนดไปเป็ นโค้ดนันช่างน่าหงุดหงิด
 งานทีได้รบั มอบหมายมักถูกออกแบบให้ชดั เจนและเข้าใจง่าย แต่ในความเป็ นจริง ข้อกําหนดไม่เคยชัดเจน
 งานทีได้รบั มอบหมายมาจากอาจารย์เพียงคนเดียว แต่ในโลกความเป็ นจริง ผูม้ ีส่วนได้ส่วนเสียหลายคนทีมี
ความต้องการขัดแย้งกันเป็ นเรืองปกติ
 แบบฝึ กหัดมักเริมต้นจากศูนย์ ไม่มีซากโค้ดหรือความพยายามครังก่อนทีไม่มีเอกสารให้พึงพาหรือโทษเมือเกิด
ความล้มเหลว แต่ในโลกความเป็นจริง การเริมต้นจากศูนย์เป็ นสิทธิพิเศษทีมีให้เพียงไม่กีคน โดยปกติโค้ดเก่า
จะเป็ นสิงทีต้องเผชิญ
นักพัฒนาและนักวิเคราะห์ทีไร้เดียงสาอาจมีภาพลวงตาว่ามีโมเดลอยู่แล้ว
กระจายไป คุณแค่ตอ้ งค้นหาชินส่วนเหล่านันและนํามาประกอบเข้าด้วยกัน
เพียงแต่ชินส่วนของปริศนาถูกกระจัด
ในตอนเริมต้นมันสนุกจริง ๆ สําหรับคนทีหมกมุ่นในรายละเอียดอย่างผม การมองหาข้อมูลเพือออกแบบโมเดลข้อมูลที
สามารถแทนความเป็ นจริงและแก้ปัญหาได้มากกว่าทีมันถูกออกแบบไว้ในตอนแรก เป็ นความสุขลับ ๆ ทีให้ความรูส้ กึ คุม้ ค่า มัน
ทําให้ผมพิสจู น์ตวั เองว่าผมเก่ง ด้วยการคาดการณ์ความต้องการของลูกค้าและตอบสนองต่อการเปลียนแปลงได้อย่างรวดเร็ว
แต่น่าเสียดาย มันไม่ใช่ปริศนาทีแบนราบซึงชินส่วนข้อมูลใหม่ ๆ สามารถเข้ากันได้อย่างลงตัวเพือสร้างภาพรวมที
สอดคล้องกัน ในการทีเราจะสามารถค้นหาวิธีแก้ปัญหาสําคัญได้ เราต้องแน่ใจว่าเราไม่ได้แกล้งทําเป็ นว่าปั ญหานันเป็ นสิงที
แตกต่างจากสิงทีมันเป็ นจริง ๆ
นีคือข่าวร้าย…
ภาพรวมทังหมดนันไม่ได้สอดคล้องกัน
ดังทีเราได้คน้ พบในบทก่อนหน้า การแบ่งส่วนงานและความเชียวชาญเฉพาะทางก่อให้เกิดความยุ่งเหยิงของโมเดล
อิสระ ซึงแต่ละโมเดลมีไว้เพือวัตถุประสงค์เฉพาะเจาะจง
แม้วา่ จะไม่สมบูรณ์แบบ แต่นีก็ใช้ได้ในชีวติ จริง ผูค้ นพูดคุยกัน และบางครังพวกเขาก็เข้าใจกัน พวกเขาอาจตีความ
ข้อมูลทีไม่ได้ระบุไว้อย่างชัดเจนจากบริบท (เช่น ในงานแฟชันโชว์ คําว่า "โมเดล" อาจหมายถึงคนทีหน้าตาดี ในการประชุมของ
นักพัฒนา เราอาจหมายถึงไดอะแกรมบางอย่างแทน) หรืออาจมีการสนทนาทียาวนานพร้อมกับสีหน้าฉงน ก่อนทีจะหัวเราะ
ออกมาเมือพบว่าพวกเขาหมายถึงสิงทีแตกต่างกัน พวกเขาอาจสงสัยในบางช่วง แต่ความคลุมเครือเล็ก ๆ น้อย ๆ นีทําให้การ
สนทนาน่าสนใจยิงขึน
ซอฟต์แวร์ไม่ได้ทาํ งานเช่นนัน ความเข้าใจผิดไม่ใช่เรืองน่าขํา แต่กลับมีแนวโน้มทีจะเป็ นข้อผิดพลาดทีอาจทําให้ตอ้ งเสีย
เงินจํานวนมาก หรือแม้กระทังชีวิตมนุษย์ การเขียนโค้ดและความคลุมเครือไม่สามารถไปด้วยกันได้ดี การเขียนโค้ดเป็ น
ช่วงเวลาทีความคลุมเครือถูกเปิ ดเผย ในรูปแบบของข้อผิดพลาดการคอมไพล์ พฤติกรรมทีไม่คาดคิด หรือบัก การสนทนา
ยอมรับความคลุมเครือได้ แต่การเขียนโค้ดจะไม่ให้อภัยมัน
การเก็บรวบรวมคํานามจะไม่พาคุณไปถึงไหน
มันเป็ นเรืองประชดทีต้องตระหนักว่าวิศวกรซอฟต์แวร์พยายามสร้างโมเดลสําหรับแอปพลิเคชันองค์กรโดยการค้นหา
คํานามทีเกียวข้อง ทังทีจริง ๆ แล้วคํานามเป็ นส่วนหนึงของความรูใ้ นองค์กรทีมีแนวโน้มจะคลุมเครือทีสุด
ยังจําเรืองการแบ่งส่วนงาน (silos) ได้ไหม? ลองถามคําถามว่า “คุณรูไ้ หมว่า Order คืออะไร?” กับแผนกต่าง ๆ เช่น ฝ่ าย
ขาย แผนกบรรจุภณ
ั ฑ์ แผนกจัดส่ง แผนกการเงิน หรือฝ่ ายบริการลูกค้า คําตอบอาจคล้ายกันหากคุณแสดงโครงสร้างแบบคงที
ของ Order (หรือเวอร์ชนั ทีพิมพ์ออกมา) Order จะมี Order_ID, Net_Total_Amount และ Gross_Total_Amount โดย
Net_Total_Amount จะเป็ นผลรวมของ Unit_Price ของ Line_Items คูณด้วย Quantity ของพวกมัน ลบด้วย Discount ที
นํามาใช้ และมันจะเชือมโยงกับลูกค้ารายหนึง ซึงเราจะต้องรูท้ งั Billing_Address และ Delivery_Address ของลูกค้าคนนัน
ผมขอหยุดตรงนี เราทุกคนรูว้ า่ มันยังมีรายละเอียดมากกว่านีอีก
คุณอาจพบความเห็นพ้องต้องกันในคําจํากัดความนี ซึงฟังดูสมเหตุสมผลสําหรับทุกคน แต่น่าเสียดาย หากคุณขุดลึกลง
ไปในพฤติกรรมของระบบ คุณจะพบว่า:
 ในฝ่ ายขาย พนักงานขายจะเปิ ดคําสังซือแบบร่าง (draft order) เพิมและลบรายการสินค้า และใช้ส่วนลด
หลังจากนันจึงยืนยันคําสังซือเมือได้รบั ความยินยอมจากลูกค้า
ั ฑ์ เจ้าหน้าทีคลังสินค้าจะหยิบสินค้าจากชันวาง โดยอาจอัปเดตสถานะความพร้อมใช้งาน
 ในแผนกบรรจุภณ
ของสินค้าและรายงานสินค้าทีขาดหายหากพบปั ญหา เมือเสร็จสิน เจ้าหน้าทีจะปิ ดผนึกบรรจุภณ
ั ฑ์และ
ประกาศว่าพร้อมสําหรับการจัดส่ง
 ในแผนกจัดส่ง การจัดส่งหนึงหรือหลายครังจะถูกวางแผนสําหรับคําสังซือนัน ๆ คําสังซือจะถือว่าสมบูรณ์เมือ
สินค้าทังหมดถูกส่งมอบเรียบร้อยแล้ว
 ในแผนกการเงิน เราจะส่งใบแจ้งหนีสําหรับคําสังซือตามนโยบายการเรียกเก็บเงินของเรา เช่น เรียกเก็บเงิน
50% เมือยืนยันคําสังซือ และอีก 50% หลังจากส่งมอบสินค้าแล้ว
 ในแผนกการเรียกร้อง (Claims) ลูกค้าสามารถเปิ ดคําร้องเกียวกับคําสังซือทีได้รบั หากมีบางอย่างไม่ตรงกับ
ความคาดหวัง เช่น สินค้าเสียหายหรือสินค้าหาย เป็ นต้น แน่นอนว่าคําร้องสามารถเปิ ดได้ก็ต่อเมือคุณเป็ น
ลูกค้าทีทําคําสังซือนัน และคําร้องต้องเกียวข้องกับสินค้าทีรวมอยู่ในคําสังซือเท่านัน
นักสร้างโมเดลผูเ้ ชียวชาญในด้านนีอาจรูส้ กึ ขนลุกกับความไร้เดียงสาของผม ยังมีอีกหลายสิงทีผมสามารถสร้างโมเดล
ให้แม่นยํากว่านีได้ เช่น การแยกคําสังซือ (Orders) ออกจากบรรจุภณ
ั ฑ์ (Packages) และการจัดส่ง (Shipments) อย่างชัดเจน
1. เมือเรียนรูโ้ ดเมนใหม่ ๆ 'ข้อผิดพลาด' เหล่านีมักจะรออยู่ใกล้ ๆ เสมอ เมือเผชิญกับปัญหาใหม่ วันพรุง่ นีเราก็
อาจถูกหลอกอีกครัง
2. ความซับซ้อนทีเพิมขึน (Multiplicity) เป็ นหนึงในปัจจัยสําคัญทีช่วยให้เราค้นพบข้อบกพร่องของโมเดลทีไร้
เดียงสา เราจะต้องแยกคําสังซือออกจากการจัดส่ง เพราะคําสังซือหนึงรายการอาจต้องใช้การจัดส่งหลายครัง
เพือให้เสร็จสมบูรณ์ เป็ นต้น
เราเผชิญกับปั ญหาทีเกิดซําในกระบวนการพัฒนาซอฟต์แวร์องค์กร นันคือความไม่น่าเชือถือของความรู ้ และกลยุทธ์ใน
การสร้างโมเดล (โดยเน้นทีคํานามและข้อมูลก่อน) ซึงดูเหมือนจะสมบูรณ์แบบสําหรับการถูกหลอก
ความเชือผิดเกียวกับ Product Owner
หากคุณยอมรับแนวคิดว่าการพัฒนาซอฟต์แวร์เป็ นส่วนใหญ่คือกระบวนการเรียนรู ้ แนวปฏิบตั ิทัวไปบางอย่างก็จะเริมดู
ไม่เหมาะสม
ใน Scrum มีการมอบความรับผิดชอบจํานวนมากไว้บนบ่าของ Product Owner ซึงทําหน้าทีเป็ นตัวกลางหลักระหว่าง
ทีมพัฒนาและผูม้ ีส่วนได้สว่ นเสียทางธุรกิจ อย่างไรก็ตาม การตีความบทบาทสําคัญนีมักขัดแย้งกับมุมมองด้านการเรียนรู ้
บ่อยครัง ทีมถูกแยกออกจากกันเพราะ Product Owner เป็ นผูจ้ ดั การบทสนทนาทีจําเป็ นทังหมดกับผูม้ ีส่วนได้ส่วนเสียต่าง ๆ
ค่อย ๆ Product Owner กลายเป็ นบุคคลเดียวทีมีสิทธิเรียนรู ้ ขณะทีทีมพัฒนากลายเป็ นเพียงผูแ้ ปลงข้อกําหนดไปเป็ น
โค้ด สิงนีเริมมีกลินอายคล้ายการแบ่งแยกระหว่างนักวิเคราะห์ (Analysts) และนักพัฒนา (Developers) ทีเคยเป็ นทีนิยมใน
สภาพแวดล้อมแบบ Waterfall
แต่หากเรามองว่าการพัฒนาซอฟต์แวร์คือการเรียนรู ้ ก็จะเห็นได้ทนั ทีว่าการเรียนรูม้ ือสอง (second-hand learning)
ไม่ใช่วิธีทีดีทีสุดในการเรียนรู ้
หากเป้าหมายของคุณคือการเรียนรูก้ ารขีจักรยาน คุณสามารถเลือกได้ระหว่าง:
 ได้จกั รยานมาแล้วลองขีด้วยตัวเอง,
 พูดคุยกับนักปั นจักรยานโดยตรง,
 พูดคุยกับเพือนทีรูจ้ กั นักปั นจักรยาน,
 อ่านเอกสารสเปกทีเขียนโดยเพือนซึงเคยพูดคุยกับนักปั นจักรยาน
ทางเลือกเป็ นของคุณ
จุดบกพร่องทีเกิดจากจุดเดียวเป็ นสิงไม่ดี
การวางภาระของการทําความเข้าใจระบบทังหมดไว้บนบุคคลหรือบทบาทเดียวฟั งดูเป็ นความคิดทีแย่มาก แม้ในเชิงกล
ยุทธ์ก็ตาม
รายการตรวจสอบ: มีคนกีคนทีเข้าใจระบบของคุณ?
 ไม่มีใครเลย -> คุณอาจกําลังเจอปั ญหาใหญ่
 มีแค่คนเดียว -> คุณอาจเจอปัญหาหนักกว่าเดิม แต่ยากทีจะยอมรับ
 มีบางคนทีมีความสามารถพอสมควรในภาพรวม -> ปลอดภัยขึน
 ทุกคนรูเ้ รืองทังหมด -> น่าชืนชมมาก
การปรับมุมมองของปั ญหา
สิงที Scrum ชีให้เห็นจริง ๆ ก็คือ ทีมพัฒนามักจะจัดการกับลําดับความสําคัญทีขัดแย้งกันได้ไม่ดีนกั และเป็ นความ
รับผิดชอบของ Product Owner ทีจะต้องจัดการเรืองเหล่านีให้เรียบร้อยก่อนทีการพัฒนาจะเริมต้นในแต่ละรอบ
สิงที Scrum ไม่ได้กาํ หนดไว้คือการทีการเรียนรูท้ งหมดควรเกิ
ั
ดขึนผ่าน Product Owner นีคือความผิดปกติทีลดทอน
คุณภาพของการเรียนรูโ้ ดยรวมและผลิตภัณฑ์ทีได้
ความเชือผิดเกียวกับ Backlog
ในปี
ผมอาจสันนิษฐานได้ว่าหากคุณมีส่วนร่วมในกระบวนการพัฒนาซอฟต์แวร์ คุณน่าจะใช้งานกระบวนการเชิง
Agile ในบางรูปแบบ เช่น Scrum หรือ Kanban และคุณคงคุน้ เคยกับแนวคิดของ Product Backlog ซึงเป็ นการรวบรวมฟี เจอร์
ต่าง ๆ ทีทีมพัฒนาจะต้องดําเนินการทีละรอบ
เมือถูกจัดเตรียมไว้ Product Backlog มักจะดูเหมือนคิว
Backlog ทีเหมือนคิว
ปั ญหาของ Backlog คืออะไร? การทํางานแบบ Iterations ไม่ใช่สงที
ิ ดีหรอกหรือ
สิงทีผมไม่ชอบเกียวกับ Backlogs คือมันสร้างภาพลวงตาว่าโครงการทังหมดเป็ นเพียงผลรวมของส่วนประกอบต่าง ๆ
ซึงน่าเสียดายทีความจริงไม่ได้เป็ นเช่นนัน
Backlog ถูกออกแบบมาให้เหมาะสมกับการส่งมอบ การมีจงั หวะทีแน่นอน (cadence) และการปล่อยฟี เจอร์เล็ก ๆ เป็ น
ระยะนันทํางานได้ดเี พือสร้างจังหวะการทํางานและแสดงให้เห็นความคืบหน้าในเชิงปริมาณ
แต่จงั หวะทีทําให้แต่ละสัปดาห์วนซํากับรูปแบบพืนฐานเดิม ๆ เช่น การวางแผน การพัฒนา และการปล่อย อาจไม่เหลือ
พืนทีเพียงพอสําหรับกิจกรรมอืน ๆ ทีไม่ได้อยู่ในแผน
ในความเป็ นจริง โครงการบางโครงการปฏิบตั ิตามแผนได้ค่อนข้างดี โดยปกติแล้วจะเป็ นโครงการทีไม่ตอ้ งมีการค้นพบ
หรือสํารวจอะไรมากนัก โครงการทีเกียวกับการปฏิบตั ิตามกฎระเบียบ (Compliance projects) เป็ นตัวอย่างทีชัดเจน: เมือมี
ข้อบังคับใหม่ทกํี าหนดข้อกําหนดบางอย่าง เราก็แค่ตอ้ งจัดการกับรายการตรวจสอบ
น่าเบือ
การทําลายความเคยชินจากการทํางานแบบ Iteration
ผมเคยเห็นความเคยชินเหล่านีกลายเป็ นอุปสรรคต่อการพัฒนาผลิตภัณฑ์ทีมีความหมาย กิจกรรมทีไม่เป็ นไปตามแบบ
แผน เช่น "ออกไปภาคสนามเพือดูว่าผูใ้ ช้ใช้ซอฟต์แวร์ของเราอย่างไรจริง ๆ" หรือ "จัดเวิรก์ ช็อปขนาดใหญ่เพือทําความเข้าใจ
ปั ญหาทีซอฟต์แวร์ของเราต้องแก้ให้ดียิงขึน" มักจะไม่เกิดขึน เพราะมีสิงทีสําคัญกว่าและถูกวางแผนไว้สาํ หรับสัปดาห์นีอยู่แล้ว
ความเคยชินนันดีในแง่ทช่ี วยสร้างกิจวัตรทีมีสขุ ภาพดี
เปลียนแปลงหรือลองทําสิงทีแตกต่างออกไป
แต่พวกมันก็สร้างความต่อต้านอย่างมากเมือคุณจําเป็ นต้อง
ถ้ากิจวัตรของคุณคือ "ไปทีออฟฟิ ศ - ดืมกาแฟ - ยืนประชุม - เปิ ด IDE" การทําอะไรทีแตกต่างออกไปจะต้องใช้ความ
พยายามมาก
สัปดาห์ทีถูกออกแบบมาให้ทาํ ซําเพือเพิมประสิทธิภาพในการวางแผนและส่งมอบไม่ได้ถูกออกแบบมาให้เหมาะกับการ
ค้นพบ ในความเป็ นจริง การค้นพบมีแนวโน้มทีจะเกิดขึนเมือเราทําลายความเคยชินและทําสิงทีแตกต่างอย่างชัดเจน
ยอมรับการเปลียนแปลง
นันแหละคือประเภทของ Backlog ทีผมชอบทีสุด
การยอมรับการเปลียนแปลงนันไม่ใช่สิงทีเหมาะสมทีสุด
มีบางอย่างเกียวกับแนวคิดของการยอมรับการเปลียนแปลงและการพัฒนาซอฟต์แวร์แบบ Iterative ทีมักจะดูเหมือน
ปั ญหาใหญ่ทีถูกมองข้ามสําหรับผม
การทําสิงเดิมสองครังมีตน้ ทุนมากกว่าการทําให้ถูกต้องตังแต่ครังแรก
ไม่มีเหตุผลทีจะไม่พยายามทําสิงต่าง ๆ ให้ถูกต้อง
ใช่ ผมรู ้ ผมเป็ นคนเดียวกันทีพูดถึงความเชือผิดเกียวกับ Backlog เมือไม่กีบรรทัดก่อนหน้านี แต่การพัฒนาแบบ
Iterative ไม่ได้หมายความว่าเราไม่ควรพยายามเริมต้นให้ถกู ต้องตังแต่แรก
ผมมีปริญญาด้านอิเล็กทรอนิกส์ ซึงหมายความว่าผมเคยใช้เวลาหนักไปกับการแก้สมการทีต้องใช้การประมาณค่า
(interpolation): คุณเลือกค่าหนึงสําหรับตัวแปร X ซึงจะนําไปสู่ค่าของ Y จากนันคุณใช้คา่ Y นันเพือหาค่า X ทีแม่นยําขึน
และทําซําไปเรือย ๆ จนกระทังค่าต่างระหว่างตัวแปรเก่าและตัวแปรใหม่ตากว่
ํ าค่าทีกําหนด ซึงแสดงให้เห็นว่าระบบกําลัง
เข้าใกล้ชดุ คําตอบทีกําหนดไว้
แต่... ผมได้เรียนรูใ้ นทางทียากว่าการเลือกจุดเริมต้นทีถูกต้องนันสําคัญมาก: คู่ตวั แปรทีดูเหมาะสมสามารถนําไปสู่
ผลลัพธ์ทคาดหวั
ี
งได้ใน 2-3 ขันตอน ในขณะทีจุดเริมต้นทีผิดอาจใช้รอบการคํานวณมากกว่านันมาก ซึงใช้เวลานานขึน
และทําให้โอกาสในการผ่านการสอบของผมลดลงอย่างมาก
จบเรืองนอกประเด็น แต่ผมหวังว่าสารทีต้องการสือจะชัดเจน: การพัฒนาแบบ Iterative นันมีตน้ ทุนสูง
Lean
มันเป็ นแนวทางทีดีทีสุดสําหรับการพัฒนาซอฟต์แวร์ในโดเมนทีมีความซับซ้อนสูงและมีความต้องการแบบ
อย่างไรก็ตาม จุดเริมต้นแรกนันสําคัญมาก การปรับปรุงครังใหญ่ (big refactoring) จะมีคา่ ใช้จา่ ยมากกว่าการปรับแต่งเล็ก ๆ
น้อย ๆ ทีละขันตอน (ลองเปรียบเทียบการแบ่งฐานข้อมูลออกเป็นส่วน ๆ กับการเปลียนชือตัวแปร) ดังนันผมจะพยายามทุก
วิถีทางเพือเริมต้นกระบวนการ Iterative จากจุดเริมต้นทีเหมาะสมทีสุด
ผมไม่สามารถสัญญาได้ว่าวิธีนีจะได้ผล ผมไม่สามารถรับประกันได้ว่าจะไม่มเี รืองไม่คาดฝันเกิดขึนระหว่างทาง
ในความเป็ นจริง ผมจะรูส้ กึ ยินดีอย่างยิงหากได้คน้ พบความก้าวหน้าทีพิสจู น์ได้ว่าข้อสมมติฐานเริมต้นของผมนันผิด
แม้วา่ มันจะหมายถึงการทิงสิงทีเคยดูเหมือนจะเป็ นไอเดียทียอดเยียมก็ตาม
ผมทําอย่างดีทีสุดเพือเริมต้นในทางทีถูกต้อง เพราะการ Iteration มีค่าใช้จ่ายสูง และยิงทําน้อยครังก็ยิงดี
การแก้แค้นของคําว่า U?*
คําว่า "Upfront" เป็ นคําทีไม่พึงประสงค์อย่างมากในศัพท์แสงของ Agile เพราะมันชวนให้นึกถึงช่วงเวลาของการ
วิเคราะห์ล่วงหน้าในยุคของกระบวนการ Waterfall แบบองค์กรทีเลวร้ายทีสุด ด้วยมรดกทีไม่ดนี ี คําดังกล่าวจึงถูกห้ามใช้ใน
สภาพแวดล้อม Agile ราวกับเป็ นคําพูดดูหมินศาสนา
แต่น่าเสียดาย... ยังไงก็ตอ้ งมีบางสิงทีเกิดขึนล่วงหน้าอยูด่ ี แม้แต่นกั พัฒนาทีแย่ทสุี ดก็ยงั ต้องคิดก่อนจะพิมพ์โค้ดบรรทัด
แรก
อย่างไรก็ตาม สิงนีไม่ใช่จดุ ประสงค์ของ EventStorming
ไม่มีเหตุผลทีจะไม่คาดการณ์หรือเริมต้นการเรียนรู ล้ ่วงหน้า ปัญหาเกิดขึนเมือเราตังข้อจํากัดโดยสมมติวา่ เราได้เรียนรูท้ กุ สิงทุก
อย่างแล้ว ซึงเป็ นสิงทีนําไปสู่ความยุ่งเหยิง
แล้วการออกแบบแบบ Emergent Design ล่ะ?
ครังหนึงมีคนถามผมว่า “คุณต่อต้านการออกแบบแบบ Emergent Design ใช่ไหม?” ...จริง ๆ แล้วไม่ใช่ ผมไม่ได้ต่อต้าน
ผมแค่คิดว่าการออกแบบแบบ Emergent Design เป็ นเครืองมือทียอดเยียมสําหรับการค้นหาเส้นทางในสถานการณ์ทีเต็มไป
ด้วยความไม่แน่นอน หากคุณไม่มีไอเดียเลยว่าผลลัพธ์จะออกมาเป็ นอย่างไร การออกแบบแบบ Emergent Design ก็เป็ น
เครืองมือทีเหมาะสมสําหรับคุณ
แต่นนไม่
ั ใช่กรณีเมือพูดถึงการสร้างโมเดลกระบวนการธุรกิจ แม้วา่ บริษัทต่าง ๆ จะอธิบายตัวเองว่าไม่เหมือนใครหรือ
แหวกแนว แต่กระบวนการทํางานมักจะไม่ได้แตกต่างกันมากนัก หรือให้พดู อย่างแม่นยํากว่านัน ส่วนประกอบพืนฐานของ
ั ตน้ ก็เหมือนกับการดูหนัง
กระบวนการ (process building blocks) จะเหมือนกันอย่างแน่นอน การค้นพบสิงเหล่านีใหม่ตงแต่
สัตว์ประหลาด แต่ทาํ เหมือนว่าเราไม่รูว้ ่าใครจะเป็ นฮีโร่ทีรอดชีวิตในตอนจบ
มันอาจจะสนุกทีจะนําหลักการของการออกแบบแบบ Emergent Design มาใช้กบั ปั ญหาทีมีวธิ ีแก้ไขอยู่แล้ว แต่ก็
เหมือนกับการโยนเงินลงชักโครก
เข้าสู่ Domain-Driven Design
ในบรรดาแนวทางการพัฒนาซอฟต์แวร์ทงหมด
ั
Domain-Driven Design (DDD) เป็ นแนวทางเดียวทีมุ่งเน้นไปที "ภาษา"
ในฐานะเครืองมือสําคัญสําหรับการทําความเข้าใจความซับซ้อนของโดเมนทีกําหนด
DDD ไม่ได้ตงสมมติ
ั
ฐานว่าพืนทีความเชียวชาญทีแตกต่างกันจะต้องมีความสอดคล้องกัน ในความเป็ นจริง มันระบุวา่
ความสอดคล้องสามารถทําได้เฉพาะในระดับโมเดลเท่านัน และโมเดลดังกล่าวไม่ควรมีขนาดใหญ่
เมือสร้างโมเดลสําหรับระบบขนาดใหญ่ เราไม่ควรมุ่งเป้าไปที "โมเดลองค์กรขนาดใหญ่" เพราะนันเป็ นจุดดึงดูดความ
คลุมเครือและความขัดแย้ง แต่เราควรมุ่งเน้นไปที สิง:
 โมเดลทีมีขนาดเล็กและมีความสอดคล้องทางความหมายในระดับสูง,
 วิธีการทําให้โมเดลทีพึงพากันเหล่านันทํางานร่วมกันได้
โมเดลขนาดเล็กทีมีความสอดคล้องทางความหมายอย่างเข้มงวดนีใน DDD ถูกเรียกว่า Bounded Context
ตัวอย่าง Bounded Context แบบดังเดิม
ผมเป็ นคนอิตาเลียน ตามภาพลักษณ์ทวไป
ั ผมควรจะชอบกาแฟ ปัญหาคือสิงทีผมเรียกว่า ‘กาแฟ’ อาจไม่ใช่สิงทีคุณ
เรียกว่า ‘กาแฟ’ เว้นแต่วา่ คุณจะเป็ นคนอิตาเลียนเหมือนกัน
เมือพูดถึงกาแฟ ทุกคนมักจะทําเหมือนเข้าใจสิงทีคุณกําลังพูดถึง แต่ถา้ คุณลงลึกไปในรายละเอียดของการใช้งานจริง
คุณจะค้นพบว่า ‘กาแฟ’ สําหรับคนอิตาเลียนมักหมายถึงสิงทีชาวต่างชาติเรียกว่า ‘เอสเปรสโซ’ ซึงเป็ นเครืองดืมในถ้วย
เล็ก ๆ ทีดืมอย่างรวดเร็วขณะยืนทีบาร์ ในประเทศอืน ๆ (โดยเฉพาะประเทศทีอากาศหนาว) กาแฟจะเกียวข้องกับถ้วย
ขนาดใหญ่ (mug) และแนวคิดของการดืมอย่างช้า ๆ ขณะนังทีโต๊ะ หรือแม้กระทังบนโต๊ะทํางาน
นีคือสิงทีผมขอเมือเดินทาง: "เอสเปรสโซ่หนึงแก้วครับ" แต่เมืออยู่ในอิตาลี ผมแค่ขอว่า "กาแฟหนึงแก้วครับ"
ถ้าผมขอเอสเปรสโซ่ในอิตาลี ผมก็จะได้สิงเดียวกันเป๊ ะ พร้อมกับคิวทียกขึนจากบาริสต้า: เพราะมีแต่ชาวต่างชาติเท่านัน
ทีเรียกมันว่าเอสเปรสโซ่
ถ้าผมต้องการความแม่นยํา – และซอฟต์แวร์ทีทํางานได้ดกี ็ไม่ชอบความคลุมเครือ – มันเป็ นหน้าทีของผมทีจะต้อง
กําหนดขอบเขตของการสนทนาให้ชดั เจน เพือหลีกเลียงความสงสัยเกียวกับความหมายของคําทีใช้
Bounded Context ก็คือสิงนันเอง: ส่วนหนึงของโมเดลทีเราต้องทําให้ปลอดจากความคลุมเครือ ทุกคําในโมเดลนัน
จะต้องมีความหมายทีชัดเจนและแม่นยํา
แผนทีบริบท (Context Map) จะสะท้อนถึงพืนทีของความเชียวชาญ แต่มีความแตกต่างทีสําคัญ: เราไม่สามารถสมมติ
ได้ว่าพืนทีของความเชียวชาญภายในนันจะมีความสอดคล้องกันโดยอัตโนมัติ ในขณะทีความสอดคล้องภายในเป็ นเป้าหมาย
หลักของเราภายใน Bounded Context
ความเชือผิดเกียวกับ Backlog
แนวทาง Agile เช่น Scrum และ XP ได้ให้คาํ แนะนํามากมายเกียวกับวิธีการจัดการโครงการพัฒนาซอฟต์แวร์ โดยการ
เปลียนความคาดหวังของผูม้ ีส่วนได้ส่วนเสียให้กลายเป็ นฟี เจอร์หรือ User Stories และแบ่งการส่งมอบออกเป็ นลําดับของ
Iterations ผมชอบสิงเหล่านีมาก แต่ก็ยงั มีคาํ ถามทีค้างคาใจอยู่
คําถามของผมคือ "เราควรเริมต้นอย่างไร?" ผมชอบทีไม่มีขอ้ กําหนดทีเข้มงวดเกียวกับการเริมต้นโครงการ Agile แต่…
วงจรการส่งมอบ…จริงหรือ?
สิงทีผมชอบเกียวกับ Iterations
• การได้รบั ข้อเสนอแนะบ่อยครัง: สําหรับทีมทีต้องการเข้าใจว่าพวกเขากําลังดําเนินไปในทิศทางทีถูกต้องหรือไม่
ข้อเสนอแนะถือเป็ นสิงทีมีคา่ ทีสุด ไม่ว่าทีมจะชอบหรือไม่ก็ตาม นีคือสิงทีพวกเขาต้องการ
สิงทีฉันไม่ชอบเกียวกับการทํางานแบบ Iterations
• Iterations มักจะซําเดิม: ทีมประมาณการตามความเร็ว (velocity) โดยทีความเร็วถูกคํานวณจาก Iterations ทีผ่าน
มา ซึงเป็ นตัวกระตุน้ ทางอ้อมให้ทาํ ให้ Iteration มีความคล้ายคลึงกับ Iteration ก่อนหน้า อาจจะเพียงเพือแสดงให้
เห็นว่าเราพัฒนาขึนเล็กน้อย
• มีพนที
ื น้อยสําหรับการทําสิงทีแตกต่างออกไป:
มีแรงกระตุน้ ทีเข้มแข็งในการเปลียนการส่งมอบบ่อยครังให้
กลายเป็ นนิสยั สิงนีมีพลังแต่ไม่เหมาะสมทีสุด มี Iterations บางครังทีควรจะทําสิงทีแตกต่างออกไปจากการ
วางแผน Sprint การออกแบบ การพัฒนา การส่งมอบ การสาธิต ฯลฯ เช่น “เฮ้ สัปดาห์นีเราลองใช้เวลาสองสามวัน
ในสนามเพือดูวา่ ผูใ้ ช้ของเราทําอะไรกับซอฟต์แวร์ของเราจริง ๆ” ...แต่สิงเหล่านีมักไม่อยูใ่ นแผนเลย
ขอพูดให้ชดั เจนขึน: การทําสิงเดิมซําไปซํามาทุกสัปดาห์เป็ นเรืองทีน่าเบือ และ
ความเบือหน่ายคือตัวร้ายอันดับหนึงของการเรียนรู ้
หากการเรียนรูค้ ือเป้าหมายหลักของเรา เราควรจะกําจัดทุกอุปสรรคทีขัดขวางการเรียนรูท้ ีดียงขึ
ิ นอย่างเป็ นระบบ และ
การทําพิธีกรรมทีว่างเปล่าซําแล้วซําเล่าในแต่ละ Iteration อาจจะไม่ใช่แนวคิดทีดีทีสุด
การสร้างแบบจําลองมีปัญหา
แบบจําลองเป็ นเพียงเครืองมือสําหรับการเรียนรูท้ ลึี กซึงยิงขึน
การรวบรวมข้อกําหนดมีปัญหา
สถาปั ตยกรรมองค์กร (Enterprise Architecture) มีปัญหา
หากเราคิดถึงขนาดใหญ่ ในทีสุดคําว่า "สถาปัตยกรรมองค์กร" จะเริมโผล่ขึนมาในการสนทนา
การมองว่าเป็ นระบบนิเวศ
การสร้างแบบจําลองทีอิงกับข้อมูลมีความยืดหยุ่น
อย่าเข้าใจผิดว่าประโยคข้างต้นเป็ นคําชืนชม เพราะมันไม่ใช่ มันเป็ นเพียงเรืองของเอนโทรปี เท่านัน
ลองเอากล่องเลโก้สองกล่องมา เปิ ดออก ผสมชินส่วนเข้าด้วยกัน แล้วลองแยกมันออก
รูส้ กึ โง่ไหม? แปลกจัง เพราะสิงทีฉันเพิงบรรยายไปคือสถาปัตยกรรมองค์กรทีพบได้บ่อยทีสุดบนโลกใบนี ซึงในเชิง
เทคนิคก็คือฐานข้อมูลทีเต็มไปด้วยข้อมูลทีกําหนดไว้อย่างคลุมเครือ พร้อมกับชัน (layers) บางอย่างอยูด่ า้ นบน
มีเหตุผลทางประวัตศิ าสตร์ว่าทําไมสถาปั ตยกรรมแบบนีถึงพบได้บ่อย และในตอนนี วิศวกรทีจบการศึกษาจาก
มหาวิทยาลัยหลายคนยังไม่เข้าใจเลยว่าทําไมวิธีการนีถึงผิด อย่างไรก็ตาม ในเชิงสถิติ นีคือสถาปัตยกรรมทีพบได้มากทีสุด
การแยกแบบจําลองมีค่าใช้จ่ายสูง
การแยกแบบจําลองทีมีอยูแ่ ล้วในสถาปั ตยกรรมทีเน้นฐานข้อมูลถือเป็ นหนึงในกระบวนการปรับปรุง (refactoring) ทีมี
ค่าใช้จา่ ยสูงทีสุดในกระบวนการพัฒนาซอฟต์แวร์ บ่อยครัง ความเสียงนันประเมินได้ยากจนโครงการถูกยุติก่อนทีจะเริมต้น
แม้แต่ทีมทียอมรับแนวทาง Agile การปรับปรุง (refactorings) เหล่านีก็มกั จะวนเวียนอยู่ใน Backlog ในวงจรของการ
ผัดวันประกันพรุง่ อย่างต่อเนือง ในขณะทีบักซึงไม่มใี ครรูว้ า่ มาจากไหน มักจะได้รบั ลําดับความสําคัญสูงสุดเสมอ
ฉันไม่มีวิธีแก้ปัญหานีทีแน่นอน
แนวทาง EventStorming
มีความเชือมโยงระหว่างปัญหาต่าง ๆ ทีเราเพิงกล่าวถึง หากคุณตัดบริบทออกไป ทังหมดจะสรุปเหลือเพียงสิงสําคัญ
ไม่กีอย่างเท่านัน
•
•
•
•
มองระบบเป็ นภาพรวมทังหมด
ค้นหาปั ญหาทีคุม้ ค่าทีจะแก้ไข
รวบรวมข้อมูลทีดีทีสุดทีสามารถหาได้ทนั ที
เริมต้นการแก้ปัญหาจากจุดเริมต้นทีดีทีสุดเท่าทีจะเป็ นไปได้
นีคือสิงทีเราทําใน EventStorming: เรารวบรวมผูเ้ ชียวชาญทีดีทสุี ดสําหรับงานนี และเราร่วมกันสร้างแบบจําลองของ
พืนทีปั ญหาทีซับซ้อนมากร่วมกัน
4 การจัดเวิรก์ ช็อปภาพรวมทังหมด
ในสองบททีผ่านมานี เราได้เห็นว่าองค์กรหลายแห่งมักจะลงเอยด้วยการมีปัญหาแบบเดียวกัน และไม่มีวิธีแก้ไขที
ง่ายดายหากไม่ได้เปลียนมุมมองความคิด โดยความเป็ นจริงแล้ว ปั ญหาส่วนใหญ่ในปัจจุบนั ล้วนมีตน้ กําเนิดมาจากวิธีแก้ไข
ปั ญหาในอดีต
การพัฒนาซอฟต์แวร์บนพืนฐานของปั ญหาทีมีอยู่แล้วจะยิงทําให้สถานการณ์แย่ลง ซอฟต์แวร์ยิงมีราคาสูงเท่าใด ก็จะ
ยิงยากต่อการละทิงในภายหลัง ผลลัพธ์ทีไม่พึงประสงค์คือการเปลียนแปลงทีจําเป็ นในอนาคตจะยิงยากขึนและมีค่าใช้จ่าย
สูงขึน
ในองค์กรในจินตนาการทีสมบูรณ์แบบ ทุกคนจะมีความเข้าใจอย่างชัดเจนเกียวกับสิงทีพวกเขากําลังทํา และสามารถให้
ข้อมูลทีถูกต้องแก่ทีมพัฒนาซอฟต์แวร์ เพือให้ได้ซอฟต์แวร์ทีดีทีสุดเท่าทีจะเป็ นไปได้
แต่ในความเป็ นจริง ไม่มีองค์กรใดทีไร้ทีติ ถึงแม้วา่ จะมีคาํ กล่าวอ้างอย่างเป็ นทางการ แต่กระบวนการ บุคลากร
เทคโนโลยี และเครืองมือต่าง ๆ ก็ลว้ นมีจุดอ่อนและข้อบกพร่องทีต้องการการปรับปรุง
การแสร้งว่าจะแก้ปัญหาโดยสมมติวา่ ส่วนทีเหลือของระบบจะไม่เปลียนแปลงในระหว่างนัน เป็ นการมองปั ญหาอย่าง
ง่ายเกินไปในกรณีทีดีทีสุด และอาจเป็ นอันตรายได้ในหลายกรณี
องค์กรเอง รวมถึงสภาพแวดล้อมทางธุรกิจและตลาดแรงงานก็เช่นกัน การสมมติว่าส่วนประกอบใดส่วนประกอบหนึ งจะ
ไม่เปลียนแปลงระหว่างการดําเนินการเปลียนแปลงทีซับซ้อนนัน ไม่ใช่การทําให้เรืองง่ายขึนอย่างเหมาะสม แต่มนั เป็ นเพียง
ความคิดทีไร้เดียงสา
แต่ยงั มีสิงหนึงทีเราสามารถทําได้: เราสามารถจับภาพความเป็ นจริงในปัจจุบนั และทําให้มนใจว่
ั าผูม้ ีบทบาทสําคัญทุก
คนมองเห็นสิงเดียวกัน ไม่ว่าจะเป็ นเป้าหมายในการพัฒนาซอฟต์แวร์ทีสําคัญสําหรับองค์กร ออกแบบการดําเนินธุรกิจใหม่
สําหรับสตาร์ทอัพ หรือปรับปรุงกระบวนการธุรกิจทีสําคัญสําหรับสายธุรกิจทีมีอยู่ สิงนีหมายถึงการมีความเข้าใจร่วมกันอย่าง
ชัดเจนเกียวกับภูมทิ ศั น์ของปั ญหาและทางแก้ไขทีเป็ นไปได้
สูตรของเราในการบรรลุผลลัพธ์นีง่ายมาก:
รวบรวมบุคคลสําคัญทังหมดมาอยู่ในห้องเดียวกัน
และร่วมกันสร้างแบบจําลองของความเข้าใจในปัจจุบนั เกียวกับระบบ
น่าเสียดายทีการประชุมทีน่าเบือและไม่มีประสิทธิภาพตลอดหลายทศวรรษทีผ่านมาได้สอนเราว่า การรวบรวมผูค้ นมา
ไว้ดว้ ยกันโดยไม่มีรูปแบบทีชัดเจนจะไม่ช่วยให้บรรลุผลลัพธ์ใด ๆ แต่ข่าวดีกค็ ือ เรามีรูปแบบสําหรับแก้ไขปั ญหานี ซึงเรียกว่า
Big Picture EventStorming
Big Picture EventStorming คือเวิรก์ ช็อปขนาดใหญ่ครังเดียวทีรวมบุคคลสําคัญทุกคนทีเราคาดหวังว่าจะร่วมมือกัน
เพือแก้ไขปัญหาทางธุรกิจทีสําคัญ
หากการเข้าใจระบบเป็ นส่วนประกอบสําคัญในการเลือกทางแก้ไขทีมีแนวโน้ม
และในทีสุดเพือพัฒนาซอฟต์แวร์ที
เหมาะสม การเรียนรูใ้ ห้ได้มากทีสุดเท่าทีจะทําได้ก่อนทีจะเสียเงินไปกับการริเริมทีผิดพลาด จึงเป็ นหนทางทีควรปฏิบตั ิ
ในเวิรก์ ช็อปนี:
• เราจะสร้างแบบจําลองพฤติกรรมของสายธุรกิจทังหมด โดยเน้นความร่วมมือ ขอบเขต ความรับผิดชอบ
และมุมมองทีแตกต่างของผูม้ ีบทบาทและผูม้ ีส่วนได้ส่วนเสียทีเกียวข้อง
• เราจะค้นหาและยืนยันปัญหาทีน่าสนใจทีสุดซึงควรแก้ไข
• เราจะเน้นความเสียงสําคัญทีเกียวข้องกับสถานการณ์ปัจจุบนั และแนวทางแก้ไขใหม่ทีเป็ นไปได้
ส่วนประกอบสําคัญสําหรับ Big Picture EventStorming
นีคือรายการส่วนประกอบสําคัญสําหรับเวิรก์ ช็อปทีประสบความสําเร็จ
• เชิญบุคคลทีเหมาะสม โดยเรากําลังมองหาการผสมผสานทีลงตัวระหว่างความอยากรูอ้ ยากเห็นและความ
เชียวชาญ ซึงมีเป้าหมายร่วมกันในการพัฒนาระบบ
• สถานทีทีเหมาะสม อาจเป็ นห้องทีกว้างพอทีจะสร้างความรูส้ กึ เหมือนมีพืนทีสําหรับการสร้างแบบจําลองที
ไม่จาํ กัด
ั าทุกอย่างดําเนินไป
• ผูด้ าํ เนินเวิรก์ ช็อปอย่างน้อยหนึงคน ทีรับผิดชอบในการให้คาํ แนะนําและทําให้มนใจว่
อย่างราบรืน
แค่นนเอง!
ั
และเนืองจากเวลาของผูเ้ ข้าร่วมมีค่า... ทุกอย่างจะต้องเกิดขึนภายในเวลาเพียงไม่กีชัวโมง!
ั
จําเป็ นสําหรับการจัดเซสชัน Big Picture EventStorming ทียอดเยียมกัน แน่นอนว่าจะมี
ตอนนี ลองมาดูขนตอนที
คําแนะนํามากมายเกียวกับวิธีการนําไปปฏิบตั ิจริง และคําอธิบายว่าทําไมวิธีการนีถึงได้ผล เพือทําให้ความมหัศจรรย์เกิดขึนได้
เชิญบุคคลทีเหมาะสม
เพือให้เวิรก์ ช็อปประสบความสําเร็จ คุณจําเป็ นต้องมีคนทีเหมาะสมเข้าร่วม: การผสมผสานทีดีระหว่างความรูแ้ ละความ
อยากรูอ้ ยากเห็น แต่ทีสําคัญทีสุดคือคุณต้องการคนทีใส่ใจในปั ญหาจริง ๆ
ความหลากหลายในพืนฐานและทัศนคติเป็ นสิงสําคัญมาก EventStorming ช่วยสร้างพืนฐานทีมันคงสําหรับการ
สนทนาทีมีความหมายข้ามขอบเขตของแผนกต่าง ๆ และรูปแบบทีปรับเปลียนได้ (ดูเพิมเติมในหัวข้อ fuzzy by design และ
incremental notation) ทีช่วยให้เกิดความร่วมมือระหว่างหลายสาขาวิชา ซึงหมายความว่าผูเ้ ชียวชาญด้านธุรกิจ ผูเ้ ชียวชาญ
ด้านลีน นักออกแบบบริการ และนักพัฒนาซอฟต์แวร์สามารถเป็ นส่วนหนึงของการสนทนาเดียวกันได้
การนําคนเหล่านีทังหมดมาอยูใ่ นห้องเดียวกันในเวลาเดียวกันอาจเป็ นภารกิจทียากในตัวเอง เราจะพูดถึงรายละเอียด
เพิมเติมในหัวข้อการจัดการคําเชิญในบทถัดไป
การจัดเตรียมห้อง
เราจะต้องมีการจัดเตรียมห้องแบบพิเศษสําหรับเวิรก์ ช็อปนี
เวิรก์ ช็อปในองค์กรทัวไปมักมีผเู้ ข้าร่วมประมาณยีสิบคน แต่จาํ นวนนีอาจเพิมขึนได้อย่างรวดเร็ว ผูเ้ ข้าร่วมจะไม่ได้เพียง
นังรอบโต๊ะ แต่จะเคลือนไหวไปรอบ ๆ เพือสนทนากับผูค้ นต่าง ๆ และสํารวจส่วนต่าง ๆ ของพืนทีสร้างแบบจําลอง
สําหรับสตาร์ทอัพ จะมีผเู้ ข้าร่วมจํานวนน้อยกว่า และมีลกั ษณะการทํางานของเวิรก์ ช็อปทีแตกต่างกัน แต่จะใช้พืนที
สําหรับสร้างแบบจําลองในปริมาณใกล้เคียงกัน
เพือให้เวิรก์ ช็อปดําเนินไปอย่างราบรืน เราจําเป็ นต้องปรับเปลียนพืนทีให้เอือต่อการทํางาน และจัดสภาพแวดล้อมทีไม่มี
สิงกีดขวางต่อกระบวนการเวิรก์ ช็อปทีเหมาะสม เราจะพูดถึงหัวข้อนีอย่างละเอียดในส่วนของการเตรียมห้องทีเหมาะสม
สําหรับตอนนี ขอสมมติว่ามีการปฏิบตั ิตามเกณฑ์บางประการดังนี:
• ห้องควรมีผนังยาวตรงทีสามารถติดกระดาษม้วนไว้เป็ นพืนทีสร้างแบบจําลองได้ โดยความยาวขันตําคือ 8
เมตร ยิงยาวยิงดี
• มีพนที
ื เพียงพอให้ผเู้ ข้าร่วมเคลือนไหวไปมาใกล้กบั พืนทีสร้างแบบจําลอง ผูค้ นจําเป็ นต้องสามารถมองเห็น
ภาพรวมทังหมด (the forest) และรายละเอียดเฉพาะจุด (the trees) ได้
• เก้าอีไม่ควรตังไว้ให้หยิบใช้งา่ ยในช่วงเริมต้น อาจจะจําเป็ นหลังจากผ่านไปสองสามชัวโมง แต่ในตอนแรก
เก้าอีจะเป็ นอุปสรรค ควรวางซ้อนกันไว้ทีมุมห้องเพือส่งสัญญาณทีชัดเจน
• กระดาษม้วนควรถูกติดตังไว้ทีผนังยาวตรง
• มีฟลิปชาร์ตหรือเครืองมือทีเทียบเท่าไว้ใช้สาํ หรับทําตํานาน (legend) ของเวิรก์ ช็อป
• มีโพสต์อิทโน้ตและปากกาเมจิกจํานวนมากเพียงพอสําหรับทุกคน
• มีอาหารและเครืองดืมทีดีต่อสุขภาพอย่างเพียงพอ เพือให้แน่ใจว่าไม่มีใครรูส้ กึ หิว
• มีนาฬกิ าจับเวลา บางช่วงของเวิรก์ ช็อปจะต้องกําหนดเวลาด้วยการจับเวลา นาฬิกาทีมองเห็นได้อาจมี
ประโยชน์
ก่อนเริมเวิรก์ ช็อป ห้องของคุณควรมีลกั ษณะใกล้เคียงกับภาพด้านล่าง (ถ้ามีภาพประกอบในเอกสารต้นฉบับ)
การจัดเตรียมห้อง
ทุกอย่างพร้อมหรือยัง? ยอดเยียมมาก! นันคือทังหมดทีคุณต้องการเพือเริมต้นได้เลย.
โครงสร้างเวิรก์ ช็อป
กิจกรรมจะดําเนินไปตามลําดับขันทีมีความซับซ้อนเพิมขึน เราจะเริมต้นด้วยสิงทีง่ายก่อน แล้วค่อย ๆ เพิมรายละเอียด
เมือผูเ้ ข้าร่วมเริมมีความมันใจในรูปแบบการทํางาน
เราจะใช้แนวคิดของ "การเพิมข้อมูลทีละขัน" (incremental notation) เพือให้เวิรก์ ช็อปอยู่ในสถานะที "พอดี" ตลอดเวลา:
ไม่ยากเกินไป ไม้ง่ายเกินไป แต่กาํ ลังเหมาะสม
เพือให้คณ
ุ สัมผัสถึงกระบวนการอย่างแท้จริง จะไม่มกี ารบอกล่วงหน้าถึงโครงสร้างหรือรายการขันตอนต่าง ๆ แต่ฉนั
สัญญาว่าคุณจะได้รบั บทสรุปทีดีในตอนท้ายของบทนี!
ขันตอน: เริมต้นเวิรก์ ช็อป (Kick-off)
ห้องพร้อมแล้ว ผูเ้ ข้าร่วมก็พร้อมแล้ว ถึงเวลาทีจะเริมต้นเวิรก์ ช็อป
โดยปกติฉันจะเริมเวิรก์ ช็อปด้วยการแนะนําตัวกันแบบรวดเร็วและไม่เป็ นทางการ เพือทําความรูจ้ กั พืนฐาน ทัศนคติ และ
เป้าหมายของแต่ละคน รวมถึงเปิ ดโอกาสให้ทกุ คนแนะนําตัวเอง การแนะนําตัวนีควรทําให้รวดเร็ว (เพราะการแนะนําตัวแบบ
รอบโต๊ะทียืดยาวอาจสินเปลืองเวลาอย่างมาก) แต่ฉันขอแนะนําว่าอย่าข้ามส่วนนี เพราะการเริมต้นทีผิดพลาดอาจส่งผลเสีย
ตามมาในภายหลัง
คุณอาจต้องการระบุเป้าหมายของเวิรก์ ช็อปอย่างชัดเจน เช่น:
“เราจะสํารวจกระบวนการทางธุรกิจทังหมด โดยการวางเหตุการณ์สาํ คัญต่าง ๆ ลงบนไทม์ไลน์ และเราจะเน้นยําถึง
แนวคิด ความเสียง และโอกาสต่าง ๆ ระหว่างกระบวนการนี”
ในตอนเริมต้น ฉันจะแจ้งเตือนผูเ้ ข้าร่วมเกียวกับสิงทีอาจทําให้พวกเขารูส้ กึ ไม่สบายใจ เช่น เวิรก์ ช็อปจะเต็มไปด้วยความ
วุ่นวาย เป็ นการทํางานในลักษณะยืนเสียส่วนใหญ่ และอาจมีชว่ งเวลาทีรูส้ กึ อึดอัด ซึงทังหมดนีเป็นเรืองปกติ
สําหรับผูเ้ ข้าร่วมส่วนใหญ่ นีจะเป็ นประสบการณ์ทีแปลกใหม่ เพราะเรากําลังพาพวกเขาออกจากเขตสบายของตัวเอง
แต่คณ
ุ ต้องทําให้พวกเขามันใจว่าพวกเขาจะไม่ทาํ อะไรผิดพลาด และต้องจําไว้ว่ายิงคุณจัดเวิรก์ ช็อปมากเท่าไร คุณจะยิงมี
ความมันใจมากขึน แต่ก็จะมีผเู้ ข้าร่วมทีเป็ นมือใหม่เสมอในทุกครังทีจัดเวิรก์ ช็อป
ฉันยังแจ้งให้ทกุ คนทราบด้วยว่าคําอธิบายเบืองต้นของฉันจะสันมาก เพราะบางคนมักคาดหวังการแนะนําทียาวนาน
และคําแนะนําอย่างละเอียด ในขณะทีกลินอายของความน่าเบือในช่วงเริมต้นของการประชุมทีไม่มปี ระสิทธิภาพอาจทําให้บาง
คนรูส้ กึ สบายใจได้ แต่สาํ หรับบางคน โดยเฉพาะผูท้ ีเคยชินกับการเป็ นผูน้ าํ ในการประชุมเหล่านัน อาจรูส้ กึ หงุดหงิดอย่างมาก
เมือไม่ได้เป็ นผูน้ าํ ในครังนี
ส่วนตัวแล้ว ฉันมองว่าการเข้าสูก่ ารลงมือทําโดยเร็วทีสุดนันมีประสิทธิภาพมากกว่า ซึงมักหมายความว่าจะมีบางคน
รูส้ กึ เหมือนถูก "โยนลงสระนํา" โดยไม่ได้เตรียมตัว หน้าทีของคุณคือสือสารความรูส้ กึ ว่า “ไม่ตอ้ งกังวล ฉันอยู่ทีนีเพือช่วย!” อีก
ไม่นานพวกเขาจะรูส้ กึ ดีขึน แต่กต็ อ้ งยอมรับว่า… ไม่มใี ครชอบถูกโยนลงสระนําตังแต่แรก!
เพือนของฉัน Paul Rayner ชอบเริมต้นด้วยการทําแบบฝึ กหัดอุ่นเครืองแบบกําหนดเวลา โดยการสร้างแบบจําลอง
ร่วมกันจากเรืองราวทีทุกคนรูจ้ กั ดี (เช่น ซินเดอเรลล่า ซึงเป็ นเรืองโปรดของหลายคน) เพือให้ผเู้ ข้าร่วมได้ทาํ ความคุน้ เคยกับ
พืนฐานของวิธีการ โดยทียังไม่ตอ้ งกังวลเกียวกับปั ญหาของพวกเขาเองในตอนแรก
สรุปสัน ๆ: ดูแลความรูส้ กึ ของผูค้ น เพราะนีไม่ใช่การทํางานกับเครืองจักร แต่เป็ นการทํางานกับคน คุณจะไม่เสียใจทีใส่
ใจกับสิงนี
สิงทีฉันไม่ทาํ ตอนนี
แม้วา่ ฉันจะชอบวิธีการนีมาก แต่ฉนั พยายามไม่ขายไอเดียของมัน EventStorming เป็ นวิธีทีดี แต่แม้ในสตาร์ทอัพสุดลํา
มันก็เป็ นแค่เครืองมือ ไม่ใช่เป้าหมายสุดท้าย ฉันแทบจะไม่อธิบายวิธีการนีเลยก่อนเริม เพราะการอธิบายมักนําไปสู่คาํ ถามที
เสียเวลาไปจากเป้าหมายของเวิรก์ ช็อป
ดังนัน...ไม่ตอ้ งพูดเยอะ แต่ลงมือทํา
ทําให้เกิดขึนจริง
ถ้าคุณทําได้ดี คุณจะได้รบั คําถามมากมายตอนพักดืมกาแฟทีหลังเอง
ขันตอน: การสํารวจอย่างไร้ระเบียบ
ั ลักษณ์ทีง่ายทีสุด: เราจะเรียกกระดาษโน้ตสีสม้ ว่า Domain Events และวางเรียงไว้ตามลําดับบน
ขันตอนแรกจะใช้สญ
ไทม์ไลน์เพือแสดงกระบวนการทังหมดของธุรกิจของเรา
ผูเ้ ข้าร่วมส่วนใหญ่ในห้องอาจจะไม่คนุ้ เคยกับแนวคิดของ Domain Event ดังนันจึงจําเป็ นต้องอธิบายเล็กน้อย
โดยทัวไปแล้วมันมักจะสรุปได้เป็ น 3 แนวคิดพืนฐาน:
1. ต้องเป็ นกระดาษโน้ตสีสม้
2. ต้องเขียนในรูปอดีตกาล เช่น เพิมสินค้าใส่ตะกร้าแล้ว หรือ ซือตัวแล้ว
3. ต้องมีความสําคัญสําหรับผูเ้ ชียวชาญในโดเมน
ทุกสิงทีคุณจําเป็ นต้องรู เ้ กียวกับเหตุการณ์โดเมน
คําว่า “เหตุการณ์โดเมน” (Domain Event) มาจากสถาปั ตยกรรมซอฟต์แวร์ และไม่ได้เป็ นคําทีครอบคลุมทีสุดในบาง
สถานการณ์ บางครังฉันเรียกมันว่าเพียงแค่ “เหตุการณ์” (Event) และมันก็ใช้งานได้ดี
เหตุการณ์จะเป็ นองค์ประกอบพืนฐานของการเล่าเรืองทีเกียวข้องกับธุรกิจของเรา เราจะสร้างเรืองราวของเราเป็ นลําดับ
ของเหตุการณ์ทเกี
ี ยวข้องกัน
การใช้คาํ กริยาในรูปอดีตอาจฟั งดูไม่สมเหตุสมผลสําหรับบางคน มีเหตุผลดี ๆ บางประการทีจะใช้คาํ พูดในลักษณะนี
ํ ยงในลักษณะ “เชือฉัน ฉันรูว้ ่ากําลังทําอะไร
แต่เหตุผลเหล่านันอาจไม่ชดั เจนก่อนทีการกระทําจะเกิดขึน ฉันพยายามใช้นาเสี
อยู่” เพือหลีกเลียงการอธิบายยืดยาวก่อนการกระทํา
การทําให้รูปแบบคําอธิบายชัดเจนตังแต่เริมต้นในตํานานทีมองเห็นได้จะช่วยได้อย่างแน่นอน
การเข้าสูส่ ภาวะของการไหลลืน
ฉันคาดว่าช่วงแรก ๆ จะดูเก้กงั เล็กน้อย: ผูค้ นส่วนใหญ่อาจไม่รูว้ า่ ควรทําอะไร และจะมองไปรอบ ๆ เพือหาคําใบ้จาก
เพือนร่วมกลุ่ม เกิดเป็ นสถานการณ์ทีหยุดชะงัก
นีเป็ นช่วงเวลาทียากทีสุดสําหรับผูอ้ าํ นวยความสะดวก เพราะผูเ้ ข้าร่วมจะมองหาคําแนะนําจากพวกเขา แต่หน้าทีของผู้
อํานวยความสะดวกคือการสนับสนุน ไม่ใช่การนําอย่างกระตือรือร้น
ผูท้ ีทําลายความเงียบได้ คนทีวางกระดาษโน้ตสติกกีใบแรกลงกลางพืนผิวการสร้างโมเดลของคุณ จะเป็ นพันธมิตรทีดี
ทีสุดของคุณ กระดาษโน้ตสติกกีใบแรกของพวกเขาจะส่งสัญญาณถึงคนอืน ๆ ในห้องว่า: “มันไม่ได้ยากขนาดนัน จริง ๆ แล้วก็
แค่เขียนข้อความลงบนกระดาษโน้ตสติกกี โดยใช้คาํ กริยาในรูปอดีต แล้ววางมันไว้ตรงไหนสักแห่ง” แต่ทีสําคัญยิงกว่าคือ
ข้อความทีสือโดยนัย: “คุณก็ทาํ ได้เหมือนกัน ไม่มใี ครจะได้รบั อันตราย”
เมือสิงนีเกิดขึน ให้ชืนชมผูท้ ีเริมต้น ชัยชนะทีได้รบั การตอบแทนจะช่วยให้ผเู้ ข้าร่วมคนอืน ๆ เห็นว่าการลงมือทําคือ
พฤติกรรมทีควรค่าในเวิรก์ ชอปนี
ถ้าไม่มใี ครกล้าพอทีจะเริมต้น
อาจเป็ นหน้าทีของผูอ้ าํ นวยความสะดวกทีจะต้องแก้ปัญหานีด้วยการวางตัวอย่าง
เหตุการณ์โดเมนลงไปตรงกลาง แต่ฉนั มักจะหลีกเลียงการทําเช่นนี เพราะอาจทําให้ผเู้ ข้าร่วมคนอืน ๆ อยู่ในโหมดเฉือยชา และ
พึงพาผูอ้ าํ นวยความสะดวกมากเกินไปในขันตอนต่อไป หากฉันต้องทํา ฉันจะถอยออกมาจากพืนผิวการสร้างโมเดลทันที:
“ตอนนีขึนอยู่กบั พวกคุณแล้ว ไม่ใช่ฉนั ”
เมือความเก้กงั เริมหายไป เวิรก์ ชอปก็จะเริมต้นขึนอย่างแท้จริง มันน่าสนใจทีได้เห็นว่ากระบวนการนีกลายเป็ นกิจกรรมที
วุ่นวายและขนานกันอย่างมหาศาล ซึงทุกคนมีส่วนร่วมในการสร้างโมเดลด้วยความเร็วทีน่าประหลาดใจ
การเปลียนคําให้เป็ นรูปอดีต
ฉันไม่ได้คาดหวังว่าข้อกําหนดเริมต้นเกียวกับการใช้คาํ กริยาในรูปอดีตจะถูกปฏิบตั ิตามโดยทุกคน ข้อนีได้ถกู ประกาศไว้
ตังแต่เริมต้นและมองเห็นได้ในตํานาน แต่ฉนั พยายามไม่กดดันผูเ้ ข้าร่วมเกียวกับเรืองนี บางคนอาจพบว่าเป็ นเรืองยากทีจะ
ปรับเปลียนการเล่าเรืองภายในของตนเองให้อยู่ในรูปของคํากริยาในอดีต และความมันใจรวมถึงการมีส่วนร่วมก็สาํ คัญกว่า
ความแม่นยําหรือการปฏิบตั ิตามมาตรฐานทีดูจะกําหนดขึนตามอําเภอใจในช่วงนี ดังนัน ฉันอาจปล่อยผ่านไปก่อน และกลับมา
ดูทบัี นทึกในภายหลัง
อย่างไรก็ตาม การใช้ถอ้ ยคําทีแตกต่างออกไป เช่น รูปกริยาเชิงกระทําอย่าง “วางคําสังซือ” (Place Order) แทน “คําสัง
ซือถูกวาง” (Order Placed) ถือเป็ นประเด็นเล็กน้อยในช่วงเวลานี แต่การใช้ชือเฟสอย่าง “การลงทะเบียน” (Registration),
“การสมัคร” (Enrollment) หรือ “การดึงดูดผูใ้ ช้” (User Acquisition) จะกรองรายละเอียดสําคัญหลายอย่างออกจากโมเดล บาง
คนอาจถูกล่อลวงให้ไม่ขดุ ลึกลงไปในเฟสเหล่านัน แต่เราสนใจในรายละเอียดเหล่านี
เราได้จดั เตรียมพืนผิวสําหรับการสร้างโมเดลแบบไม่จาํ กัดไว้โดยเฉพาะ เพือให้สามารถมองเห็นกระบวนการเหล่านีใน
ระดับของรายละเอียดทีเหมาะสม และระดับทีเหมาะสมนันคือเหตุการณ์โดเมน (Domain Events) ส่วนเฟสต่าง ๆ จะปรากฏขึน
เองในภายหลังอยู่แล้ว
การขยายไทม์ไลน์อย่างเป็ นธรรมชาติ
ในช่วงทีวุ่นวาย จะไม่มีพฤติกรรมร่วมกันทีเป็ นมาตรฐานของผูค้ นเลย ทีจริงแล้ว การสังเกตวิธีทีผูค้ นจัดการตัวเองเพือ
ทํากิจกรรมสร้างโมเดลสามารถบอกอะไรได้มากมาย
 บางคนอาจรวมกลุ่มเล็ก ๆ เพือพยายามตกลงกันในถ้อยคําทีใช้ ผูอ้ าํ นวยความสะดวกควรเข้าแทรกแซงอย่าง
สุภาพและแยกกลุ่มนันออก เพราะการถกเถียงเพือหาข้อตกลงในทุก ๆ กระดาษโน้ตก่อนทีจะเขียน จะลด
ประสิทธิภาพของเวิรก์ ชอปลง และยังปิ ดบังความขัดแย้งทีเราต้องการสํารวจอีกด้วย
 บางคนอาจทํางานส่วนใหญ่ตามลําพัง โดยทิงความเชียวชาญส่วนตัวจํานวนมากไว้ในกระดาษโน้ตสีสม้ เพียง
แถบเดียว โดยไม่สนใจสิงรอบข้าง
 บางคนอาจไม่มไี อเดียเลยว่าจะเขียนอะไร และพวกเขาจะต้องได้รบั การสร้างความมันใจว่าการเดานันเป็ นสิง
ทียอมรับได้อย่างสมบูรณ์ในกระบวนการ EventStorming
ฉันไม่ได้คาดหวังว่าจะมีการสนทนามากนักในช่วงนี หลังจากการแยกวงของกลุ่มย่อยออกไป ผูค้ นจะเริมทํางานของ
ตัวเองในทีสุด: ฉันเรียกช่วงนีว่า "ความวุ่นวายทีเงียบสงบ" โมเดลจะเริมเติบโตอย่างรวดเร็วและเป็ นธรรมชาติในลักษณะที
ควบคุมได้เพียงหลวม ๆ
โมเดลทีได้ออกมามักจะมีขนาดใหญ่และดูย่งุ เหยิง มีกระดาษโน้ตหลายสิบแผ่น หรืออาจถึงหลายร้อย บางแผ่นซํากัน
หลายแผ่นอาจไม่ได้เรียงลําดับอย่างถูกต้อง และบางแผ่นอาจอ่านไม่ออก ไม่เป็ นไร เพราะเราไม่ได้ม่งุ หวังความสมบูรณ์แบบ
ตังแต่แรก
ผูม้ ีบทบาททีแตกต่างกันอาจสร้างกลุ่มทีมีลาํ ดับในท้องถินแตกต่างกันออกไปภายในความยุ่งเหยิงทังหมด
ให้พดู ให้ชดั เจนยิงขึน ฉันคาดว่าจะมีกลุ่มทีมีลาํ ดับในท้องถินอยูภ่ ายในความยุง่ เหยิงทังหมด และข้อจํากัดของไทม์ไลน์
อาจถูกละเมิดในบางจุด
ไม่เป็ นไร เราจะจัดการความยุ่งเหยิงนีในขันตอนถัดไป
ช่วงผ่อนคลาย
ในทีสุด ผูเ้ ข้าร่วมจะหยุดเพิมกระดาษโน้ตลงบนผนัง และเริมเปลียนเป็ นท่าทีทีครุน่ คิดมากขึน โดยมองภาพรวมมากกว่า
ทีจะสนใจกระดาษโน้ตของตัวเอง และอาจเดินถอยหลังออกมาสองสามก้าว
นีเป็ นช่วงเวลาทีดีในการชืนชมผูเ้ ข้าร่วมสําหรับผลงานทียอดเยียม อนุญาตให้มคี าํ ถามทีน่าสนใจ และพักเบรก ขันตอน
ต่อไปจะต้องใช้พลังงานมาก
ขันตอน: การจัดระเบียบตามไทม์ไลน์
ในระหว่างการสํารวจทีวุ่นวาย เราได้ขอให้ผเู้ ข้าร่วมวางเหตุการณ์โดเมนตามไทม์ไลน์ ซึงเราไม่ควรคาดหวังว่าผลลัพธ์
จะสมบูรณ์แบบ
หากช่วงการสํารวจมีความวุ่นวายเพียงพอ ตอนนีคุณควรจะเห็นไทม์ไลน์คร่าว ๆ ทีมีกระดาษโน้ตซํากัน และกลุ่มทีมี
ลําดับในท้องถินซ่อนอยู่ในกระแสทียุ่งเหยิง
ผูม้ ีบทบาททีแตกต่างกันอาจสร้างกลุ่มทีมีลาํ ดับในท้องถินแตกต่างกันออกไปภายในความยุ่งเหยิงทังหมด
ยิงมีการทํางานแบบขนานกันมากขึน (ซึงดีต่อความเร็วและข้อมูล) ผลลัพธ์ก็ยิงยุ่งเหยิงมากขึน ผูเ้ ชียวชาญอาจใช้
ปากกาเน้นข้อความและเขียนทุกอย่างทีพวกเขารูเ้ กียวกับโดเมนนัน แล้วติดทุกอย่างไว้บนผนังในครังเดียว ในขณะทีผูท้ ี
พยายามทําให้เส้นเวลาเป็ นไปอย่างสอดคล้องกันจะล้มเลิกความพยายามในบางจุด
การจัดวางห้องก็มีบทบาทสําคัญเช่นกัน: หากไม่มีพืนทีเพียงพอสําหรับเดินไปมาหน้าพืนทีสําหรับสร้างแบบจําลอง คน
จะไม่ค่อยเคลือนไหว และจะมุ่งเน้นทีการทํางานของตนเองก่อน แล้วค่อยดูภาพรวมในภายหลัง
ตอนนีเป้าหมายของเราคือการทําให้แน่ใจว่าเรากําลังติดตามเส้นเวลาอยู่จริง:
สอดคล้องกันตังแต่ตน้ จนจบ
เราต้องการให้ลาํ ดับเหตุการณ์มีความ
นีคือช่วงทีการสนทนาเริมร้อนแรง: ลําดับเหตุการณ์ในท้องถิน - “นีคือวิธีทมัี นทํางานในพืนทีของฉัน” - ต้องถูกรวมเข้ากับ
มุมมองของคนอืนในเหตุการณ์เดียวกัน และทังหมดนีจําเป็ นต้องสมเหตุสมผล ความไม่สอดคล้องกันจะเริมมองเห็นได้ชดั เจน
และเมือมันชัดเจน... ก็จะมีคนพูดถึงมัน!
การสนทนาสําคัญ ๆ มักจะเกิดขึนเองตามธรรมชาติ นีเป็ นช่วงเวลาทีความสามารถของทีมในการจัดการตัวเองอาจทํา
ให้คณ
ุ ประหลาดใจ แต่การแนะนําจากผูป้ ระสานงานอาจจําเป็ นเพือให้เกิดโครงสร้างทีเหมาะสม
การสร้างโครงสร้าง
เพียงแค่ ‘จัดลําดับเหตุการณ์’ เพือบังคับให้เป็ นไปตามเส้นเวลา ไม่ได้ง่ายอย่างทีฟั งดู ผูเ้ ข้าร่วมจะพยายามกรูกนั ไปที
พืนผิวสําหรับการสร้างแบบจําลอง เพือจัดการกับกระดาษโน้ตทีไม่เข้าทีอย่างถูกต้อง ในความพยายามทีจะแก้ความยุง่ เหยิง
แต่สดุ ท้ายก็จะค้นพบว่า การใช้กาํ ลังแก้ปัญหาอย่างตรงไปตรงมาไม่ใช่วิธีทีมีประสิทธิภาพทีสุด
ตรวจสอบให้แน่ใจว่ามีพืนทีเพียงพอ
อุปสรรคหลักของการจัดลําดับให้มีประสิทธิภาพคือการมีพืนทีว่างไม่เพียงพอ:
เกินไปจะกลายเป็ นปัญหาเชิงปริศนาไปเอง ซึงเราไม่ตอ้ งการเพิมความซับซ้อนนัน
การจัดลําดับบนพืนผิวทีมีพนที
ื น้อย
นีเป็ นช่วงเวลาทีเหมาะสมทีจะเพิมพืนที อาจจะติดกระดาษม้วนอีกแผ่นไว้ดา้ นล่างของแผ่นเดิม หากอัตราส่วนระหว่างสี
ส้มกับสีขาวสูงเกินไป หากตัวเลือกนีไม่สามารถทําได้ คุณอาจต้องดูบท "การจัดลําดับ" ในอีกไม่กีหน้า
เลือกกลยุทธ์ในการจัดลําดับ
วิธีการจัดลําดับแบบใช้กาํ ลังตรงไปตรงมาไม่ค่อยได้ผลดีนกั กับชุดข้อมูลขนาดใหญ่และยุง่ เหยิง การจัดลําดับจะได้ผล
ดีกว่าหากใช้กลยุทธ์ทีซับซ้อนกว่า มีวิธีทีพบบ่อยอยู่ไม่กีแบบ ได้แก่ เหตุการณ์สาํ คัญ (Pivotal Events), เลนการทํางาน
(Swimlanes), เหตุการณ์ตามช่วงเวลา (Temporal Milestones), การจัดลําดับเป็ นบท (Chapter Sorting) และกลุ่มทีต้อง
ตรวจสอบปกติ (The Usual Suspects)
คุณอาจเริมต้นด้วยการเลือกวิธีทีดูมแี นวโน้มว่าจะเหมาะสมทีสุดกับบริบทของคุณ
เหตุการณ์สาํ คัญ (Pivotal Events)
สําหรับเหตุการณ์สาํ คัญ เราจะเริมมองหาสิงทีเป็ นเหตุการณ์สาํ คัญเพียงไม่กีอย่างในกระแสงาน ตัวอย่างเช่น สําหรับ
เว็บไซต์อคี อมเมิรซ์ เหตุการณ์สาํ คัญอาจได้แก่ การเพิมสินค้าในแคตาล็อก (Article Added to Catalog), การสังซือสินค้า
(Order Placed), การจัดส่งสินค้า (Order Shipped), การชําระเงิน (Payment Received) และการส่งมอบสินค้า (Order
Delivered) เหตุการณ์เหล่านีมักจะเป็ นเหตุการณ์ทีมีผคู้ นให้ความสนใจจํานวนมาก (เช่น การสังซือสินค้าอาจกระตุน้ การ
ตอบสนองในฝ่ ายบัญชี ฝ่ ายจัดส่งสินค้า รวมถึงระบบตรวจจับการฉ้อโกงหรือการสะสมคะแนนสะสม)
เครืองมือทีฉันชอบใช้ในกรณีนคืี อเทปป้ายฉลากสี ซึงฉันจะติดไว้ดา้ นล่างกระดาษโน้ตของเหตุการณ์สาํ คัญ เพือทํา
หน้าทีเป็ นเส้นแบ่งระหว่างแต่ละช่วงของกระแสธุรกิจ
เน้นเหตุการณ์สาํ คัญ เพือให้งา่ ยต่อการจัดเรียงสิงทีอยู่ระหว่างกลาง
ฉันจะไม่เสียเวลามากเกินไปกับการมองหาเหตุการณ์สาํ คัญทีสมบูรณ์แบบ โปรดจําไว้ว่า ในตอนนีเรากําลังพยายามเร่ง
กระบวนการจัดเรียง ดังนัน การรักษาความต่อเนืองของกระแสงานจึงสําคัญกว่าการได้ขอ้ สรุปทีทุกคนเห็นพ้องกัน
โดยปกติ เหตุการณ์สาํ คัญ 4-5 เหตุการณ์ก็เพียงพอทีจะช่วยเร่งการจัดเรียงเหตุการณ์ทีเหลือได้: ผูเ้ ข้าร่วมจะสามารถจัด
วางกระแสงานของพวกเขาให้อยูใ่ นส่วนทีเหมาะสมของกระแสงานโดยรวมได้ง่ายขึน และในทีสุดก็เริมสนทนากับเพือนร่วม
กลุ่มทีอยู่ใกล้เคียง
เลนว่ายนํา (Swimlanes)
การแยกกระแสงานทังหมดออกเป็ นเลนว่ายนําในแนวนอน ซึงกําหนดให้กบั ผูม้ ีบทบาทหรือแผนกต่าง ๆ เป็ นอีกหนึง
ทางเลือกทีน่าสนใจ (นีดูเหมือนจะเป็ นตัวเลือกทีชัดเจนทีสุด หากคุณมีพนฐานด้
ื
านการสร้างแบบจําลองกระบวนการ)
เนืองจากมันช่วยให้การอ่านข้อมูลทําได้ง่ายขึน
เลนว่ายนําแนวนอนช่วยให้การอ่านข้อมูลทําได้ง่ายขึน แต่ในทีสุดก็ใช้พนที
ื มากขึนอย่างมาก
น่าเสียดายทีความสามารถในการอ่านทีดีขึนมาพร้อมกับต้นทุน: เลนว่ายนําแต่ละเลนจะใช้พืนทีในแนวตังเป็ นจํานวน
มาก ซึงมีอยู่อย่างจํากัด และเราจะไม่มีเพียง 3 หรือ 4 เลนเท่านัน เพราะเราไม่ได้กาํ ลังทําแผนทีกระบวนการเดียว แต่กาํ ลังทํา
แผนทีกระบวนการหลายอย่างพร้อมกัน ซึงหมายความว่า:
1. มีผมู้ ีบทบาทมากขึน จึงต้องมีเลนว่ายนํามากขึนทีต้องซ้อนกันในแนวตัง
2. มีพนที
ื ว่างมากขึนตามแนวเลนว่ายนํา เนืองจากการซิงโครไนซ์ระหว่างกระแสงานต่าง ๆ
โดยทัวไปแล้ว เลนว่ายนําจะทํางานได้ดมี ากสําหรับกระบวนการเดียว หรือสําหรับกระบวนการทีแยกจากกันไม่กีอย่าง
ซึงมักจะเกิดขึนขนานไปกับกระแสธุรกิจหลัก
สําหรับเรา นีหมายความว่าการใช้เลนว่ายนํามักจะมีประสิทธิภาพมากกว่าหากนํามาใช้หลังจากทีได้จดั โครงสร้างตาม
เวลาแล้ว เช่น การกําหนดเหตุการณ์สาํ คัญหรือจุดอ้างอิงทางเวลา
ในระดับทีเล็กลง ฉันชอบใช้ปา้ ยชือแนวนอนเพือระบุชือกระบวนการขนานกัน แม้จะอ่านได้งา่ ยน้อยกว่าเลนว่ายนําจริง
เล็กน้อย แต่กใ็ ช้พืนทีได้อย่างมีประสิทธิภาพมากกว่า
จุดอ้างอิงทางเวลา (Temporal Milestones)
สําหรับบางธุรกิจ การกําหนดเหตุการณ์สาํ คัญอาจไม่ใช่ตวั เลือกทีดีทีสุด อาจมีหลายกระบวนการทีเกิดขึนพร้อมกัน
(การจัดการประชุมเป็ นตัวอย่างทีชัดเจน) หรือมีความไม่สอดคล้องกันมากเกินไปเกียวกับสิงทีเกิดขึนก่อน ในสถานการณ์
เหล่านี คุณอาจเลือกใช้จดุ อ้างอิงทางเวลาแทน โดยทําให้กรอบเวลาโดยประมาณปรากฏให้เห็นบนพืนผิว เพือให้ทกุ คน
สามารถวางรายการของพวกเขาไว้ในตําแหน่งทีเหมาะสมได้มากหรือน้อย
ฉันมักจะใช้กระดาษโน้ตสีฟ้าวางไว้ดา้ นบนของพืนผิวการสร้างโมเดล พร้อมตัวบ่งชีเวลาแบบทัวไป เช่น "1 ปี ก่อน," "6
เดือนก่อน," "1 เดือนก่อน" และอืน ๆ (โดยปกติจะเลือกช่วงเวลาทีเล็กลงเมือเข้าใกล้แกนกลางของกระบวนการมากขึน)
สิงนีช่วยให้การวางเหตุการณ์อยูใ่ นตําแหน่งทีเหมาะสมได้ง่ายขึน โปรดจําไว้ว่า เราอาจยังไม่ทราบแน่ชดั ว่าควรใช้พืนที
เท่าใดสําหรับกิจกรรมใด ๆ ดังนัน ควรเตรียมพร้อมทีจะปรับเปลียนจุดอ้างอิงหรือแทนทีมัน หากคุณค้นพบข้อมูลทีแม่นยํามาก
ขึน
เวลาอาจเป็ นตัวแบ่งทีดีกว่าเหตุการณ์ในบางกรณี
แน่นอนว่าเราไม่ได้สนใจลําดับทีชัดเจนและง่ายดาย
ซับซ้อนมากกว่า
สิงทีเราสนใจคือบทสนทนาทีเกิดขึนจากลําดับทีไม่ชดั เจนและ
การจัดเรียงบท (Chapters Sorting)
เราจะจัดการสิงต่าง ๆ อย่างไรหากมีพืนทีสําหรับการจัดการน้อยเกินไป? เช่น มีกระดาษโน้ตสีสม้ มากเกินไป แต่มีพืนที
ว่างสําหรับการเคลือนย้ายหรือเพิมพืนทีได้นอ้ ยมาก?
วิธีสดุ ท้ายทีฉันใช้คือการจัดเรียงบท (Chapters Sorting): แทนทีจะจัดเรียงทุกอย่างพร้อมกัน เราทําดังนี:
1. ดําเนินการรอบการสกัดอย่างรวดเร็วเพือหาบทสําคัญ (Key Chapters) ของเรืองราวทางธุรกิจทังหมด โดย
ปกติจะนําไปสู่การได้บท 15-25 บท (ฉันมักเขียนสิงเหล่านีลงบนกระดาษโน้ตสีเหลืองทีมีขนาดใหญ่กว่า)
2. จัดเรียงบทเหล่านีอย่างรวดเร็วบนพืนผิวทีแยกออกมาต่างหาก (บ่อยครังใช้กระจกหน้าต่าง) ซึงจะได้โครงร่าง
โครงสร้างทีต้องการของกระแสงาน
3. นําโครงสร้างบททีได้ไปใช้กบั กระแสงานหลัก และปรับโมเดลทังหมดให้สอดคล้องกับโครงสร้างนัน
การจัดเรียงบทเพียงไม่กีบทบนพืนผิวทีสะอาดใช้พลังงานน้อยกว่าการจัดเรียงทุกอย่างทังหมด เมือเราเห็นโครงสร้างทีชัดเจน
แล้ว เราสามารถนําไปใช้กบั โมเดลจริงได้
“แต่...ทําไมเราไม่เริมจากการจัดบทตังแต่แรก ก่อนทีจะถูกท่วมท้นด้วยเหตุการณ์ตา่ ง ๆ?” เอ่อ...เพราะเรายังไม่สามารถ
มันใจในบทเหล่านันได้ก่อนทีจะมีการสํารวจทีวุ่นวาย
พูดอีกอย่างคือ ฉันแค่ไม่ไว้ใจในเวอร์ชนั ทีเป็ นทางการ
การผสมผสานกลยุทธ์หลายรูปแบบ
ตอนนีน่าจะชัดเจนแล้วว่ากลยุทธ์เพียงอย่างเดียวไม่เพียงพอทีจะจัดการกับความซับซ้อนทังหมด คุณจะต้องผสมผสาน
วิธีการทีหลากหลายเข้าด้วยกัน
นีคือตัวอย่างของรูปร่างโครงสร้างโครงร่างทีอาจปรากฏในตอนท้าย
คุณสามารถผสมผสานวิธีการทีแตกต่างกันเข้าด้วยกันให้ซบั ซ้อนยิงขึนได้ แต่เป็ นเรืองยากทีจะกําหนดโครงสร้างล่วงหน้า
ฉันอาจจะสามารถตรวจจับโครงสร้างได้ค่อนข้างรวดเร็ว เพราะฉันเคยเห็นสิงเหล่านีมาบ้างแล้ว และเรืองราวเกียวกับ
ธุรกิจก็เริมมีลกั ษณะคล้ายกับภาพยนตร์แนวสยองขวัญหรือภาพยนตร์เกียวกับสัตว์ประหลาด: แบบทีคุณสามารถบอกได้วา่
ใครจะรอดหลังจากผ่านไปเพียง 5 นาทีแรก แต่โครงสร้างนันจะต้องเกิดจากการทํางานหนักของทีม
มันต้องเกิดขึนทีละขันตอน เพือให้ทกุ คนสามารถเข้าใจได้อย่างถ่องแท้ และมันต้องเป็ นผลลัพธ์จากความพยายาม
ร่วมกัน เพือให้ทกุ คนมีสิทธิได้รบั รางวัล
ฉันยังคงไม่มนใจกั
ั บข้อโต้แย้งทีว่า
“เราได้สร้างแบบจําลองของกระบวนการทังหมดไว้แล้ว”
เพราะบ่อยครังที
และจุดเริมต้นทียุง่ เหยิงก็นาํ ไปสู่
กระบวนการทีถูกสร้างแบบจําลองไว้กบั กระบวนการทีเกิดขึนจริงนันมักจะแตกต่างกัน
ข้อยกเว้นทีน่าสนใจกว่าการสร้างแบบจําลองตาม “เวอร์ชนั ทางการ”
เน้นความไม่สอดคล้องด้วยจุดสําคัญ (Hot Spots)
การบังคับให้เกิดความสอดคล้องกันในระดับโลกจะไม่เกิดขึนโดยปราศจากความขัดแย้ง ในความเป็ นจริง เราคาดว่า
ความไม่สอดคล้องกันและความเข้าใจผิดส่วนใหญ่ของเราจะปรากฏในช่วงนี
นีคือช่วงเวลาทีบทบาทของผูด้ าํ เนินงานกลายเป็ นสิงสําคัญ ในขณะทีทุกคนกําลังยุง่ อยู่กบั การพยายามทําความเข้าใจ
กับกระดาษโน้ตสีสม้ ผูด้ าํ เนินงานควรมองหาสถานทีทีการอภิปรายเริมร้อนแรง และทําการทําเครืองหมายด้วยกระดาษโน้ตสี
ม่วง
การมีสถานทีเหล่านี - ฉันเรียกมันว่า Hot Spots - ถูกเน้นให้ชดั เจนเป็ นประโยชน์อย่างมาก ฉันชอบปล่อยให้การระบุ
จุดสําคัญ (Hot Spots) เป็ นหน้าทีของผูด้ าํ เนินงานในช่วงนี เพราะการขอให้ระบุปัญหาอย่างชัดเจนเร็วเกินไปในเวิรก์ ชอป อาจ
ทําให้เกิดปั ญหามากมายทีมีสญ
ั ญาณต่อเสียงรบกวนในระดับตํา เราจะทําให้จดุ สําคัญเหล่านีเข้าถึงได้ในภายหลังในส่วนของ
ปั ญหาและโอกาส
เป้าหมายทีปลอดภัยกว่าสําหรับการชีนิวตําหนิ
Hot Spots เป็ นสิงทีใช้บนั ทึกความคิดเห็นและข้อสังเกตเกียวกับปั ญหาในเรืองราว และฉันคาดว่าจะพบสิงเหล่านีอยู่ไม่
น้อยเลย ในความเป็ นจริง EventStorming สร้างสภาพแวดล้อมทีปลอดภัยมากขึนสําหรับการเผชิญหน้ากับปั ญหาอย่างจริงจัง
(ซึงตอนนีมองเห็นได้บนผนัง) ในขณะทียังคงมีความอ่อนโยนต่อผูค้ น
ผูค้ นและระบบ
เหตุการณ์ต่าง ๆ ไม่ได้เกิดขึนในสุญญากาศ เราจําเป็ นต้องรวมผูค้ นและโลกภายนอกเข้ามาในแบบจําลองของเรา
เพือทีจะเข้าใจแรงผลักดันและข้อจํากัดทีมีอยู่ได้ดีขึน
เราจะใช้กระดาษโน้ตเล็กสีเหลืองสําหรับแทนผูค้ น และกระดาษโน้ตสีชมพูขนาดใหญ่สาํ หรับแทนระบบภายนอก
สัญลักษณ์แทนผูค้ นและระบบ
และเราจะวางสัญลักษณ์เหล่านีบนพืนผิวของแบบจําลอง ในตําแหน่งทีพวกเขามีบทบาทในกระแสของเหตุการณ์
ความไม่ชดั เจนในทางปฏิบตั ิ
ฉันชอบใช้คาํ ว่า "ผูค้ น" แทนคําว่า นักแสดง (actors), ผูใ้ ช้งาน (users), บทบาท (roles) หรือ บุคคลสมมติ (personas)
เพราะมันไม่ได้ผกู ติดกับวิธีการสร้างแบบจําลองระบบใดๆ โดยเฉพาะ
การกําหนดทีไม่ชดั เจนช่วยให้ผเู้ ข้าร่วมทุกคนสามารถมีส่วนร่วมในการอภิปรายได้
โดยไม่ตอ้ งมีความรูเ้ ฉพาะทาง
ผูเ้ ชียวชาญในสาขาเฉพาะ เช่น การออกแบบประสบการณ์ผใู้ ช้หรือการสร้างแบบจําลองกระบวนการทางธุรกิจ อาจต้องลด
ความแม่นยําลงบ้างเพือแลกกับการสนทนาทีมีความครอบคลุมและเป็ นกลางต่อพืนฐานความรูข้ องแต่ละคน
ความไม่ชดั เจนนีจะนําไปสู่ตวั แทนทีหลากหลาย ตังแต่ผใู้ ช้ทวไป
ั (User) ไปจนถึงผูใ้ ช้งานเฉพาะเจาะจง เช่น จอห์นและ
เอมี รวมถึงตัวแปรทีเป็ นไปได้ทงหมด
ั
เช่น ลูกค้าใหม่ (New Customer) และลูกค้าเดิม (Returning Customer) เป็ นต้น
รูปแบบการเขียนเกียวกับผูค้ นสามารถปรับเปลียนได้หลากหลาย!
เป้าหมายไม่ได้อยู่ทการจั
ี บคู่กระดาษโน้ตสีเหลืองทีถูกต้องกับเหตุการณ์ในกระบวนการทุกอย่าง การเพิมบุคคลสําคัญ
ช่วยเพิมความชัดเจนมากขึน แต่เป้าหมายคือการกระตุน้ ให้เกิดการสนทนาทีให้ขอ้ คิด เช่น พฤติกรรมทีขึนอยูก่ บั ผูใ้ ช้ประเภท
ต่างๆ หรือกรณีทต้ี องดําเนินการพิเศษ เป็ นต้น
อย่ากังวลหากการสนทนาเหล่านีรบกวนรูปแบบทีคุณใช้อยูใ่ นปัจจุบนั นีเป็ นสิงทีดี! มันหมายความว่าคุณเริมขุดลึกลง
ไปและเรียนรูม้ ากขึน ความแม่นยําจะค่อยๆ เข้ามาแทนทีความคลุมเครือ
ระบบภายนอก
ระบบภายนอกคือส่วนสําคัญถัดไปทียังขาดหายไปจากโมเดลของเรา ธุรกิจไม่ได้เกิดขึนในสุญญากาศ และเพือให้เห็น
ระบบทังหมด เราจําเป็ นต้องมองเห็นส่วนประกอบทีเคลือนไหวและสภาพแวดล้อมรอบข้างด้วย
ระบบภายนอกคือส่วนหนึงของกระบวนการทังหมดทีอยู่นอกเหนือการควบคุมของเราอีกครัง เราจะใช้ความคลุมเครือ
เพือกระตุน้ ให้เกิดปฏิกิรยิ าบางอย่าง: บางระบบอาจเป็ นระบบภายใน (พัฒนาโดยองค์กรของเราเอง) แต่ก็อาจเป็ นระบบ
ภายนอกได้ดว้ ย (เราไม่ได้เป็ นผูส้ ร้าง แต่เป็ นเพียงผูด้ แู ล และเราก็ไม่ชอบดูแลมันด้วยซํา) ซึงการทําความเข้าใจในจุดนีมักจะ
เผยให้เห็นสิงทีสําคัญ
ระบบภายนอกอาจเป็ นสิงทีแตกต่างจากซอฟต์แวร์อย่างสินเชิง เช่น แผนกอืน - อาจเป็ นแผนกทีไม่ได้รบั เชิญเข้าร่วม
เวิรก์ ช็อป - หรือองค์กรภายนอก
เพือไม่ให้เป็ นทางการเกินไป และเพือให้แน่ใจว่าไม่มสี ิงใดถูกมองข้ามในการสํารวจของเรา โดยปกติฉนั จะให้คาํ จํากัด
ความแบบคลุมเครือสําหรับระบบภายนอกดังนี
“ระบบภายนอกคืออะไรก็ตามทีเราสามารถโยนความผิดไปให้ได้”
สิงนีอาจนําไปสู่กระดาษโน้ตทีดูน่าอึดอัดและดูเหมือนไม่มีประโยชน์ บางครัง “โชคร้าย” ก็ถกู สร้างเป็ นระบบภายนอก
เราเคยมีทงั “ยุโรป”, “Brexit” และ “GDPR” ด้วย!
ไม่มีอะไรผิดปกติกบั เรืองนี จริงๆ แล้วมันกลับกลายเป็ นประโยชน์มาก การสร้างโมเดลโชคร้ายทําให้บางคนเขียน
เหตุการณ์ในโดเมนเกียวกับเหตุการณ์ทีโชคร้ายซึงอาจขัดขวางกระบวนการ เช่น การพลาดเครืองบินในงานประชุม สิงทีเป็ น
อันตรายสําคัญบางอย่างกลายเป็ นสิงทีมองเห็นได้ชดั เจน
เมือใดก็ตามทีไม่แน่ใจ และคุณรูส้ กึ ว่ามีบางอย่างทีอาจเข้ากันหรือไม่เข้ากันกับภาพรวม ก็เพียงแค่ติดมันไว้บนผนัง สิงที
ยากต่อการจัดประเภท เช่น “ตลาด” อาจมีคณ
ุ ค่าอย่างมากในการกระตุน้ ความคิดทีน่าสนใจ หากมันแค่เพิมความวุ่นวาย ก็ไม่
เป็ นไร… คุณแค่เปลืองกระดาษโน้ตแผ่นหนึงเท่านัน ไม่ใช่เรืองใหญ่
นีคือระบบภายนอกหรือไม่?
คําจํากัดความทีคลุมเครือจะกระตุน้ ให้ผคู้ นจัดประเภทของพวกเขาเองด้วย: “นีคือตัวแสดงหรือระบบ?” อาจเป็ นคําถาม
ทีน่าสนใจในการถาม (ผูค้ นอาจไม่ใส่ใจเรืองบุคลิกภาพของระบบมากนัก แต่ใส่ใจเรืองมนุษย์มากขึนเล็กน้อย)
น่าสนใจเช่นกันทีได้เห็นพฤติกรรมของนักพัฒนาทีมีต่อซอฟต์แวร์เก่า: บางครังมันเป็ นระบบภายนอก บางครังซอฟต์แวร์
ชินนีก็คือตัวเราเอง ความแตกต่างเล็กน้อยในภาษาอาจบอกอะไรได้มากเกียวกับความเป็ นเจ้าของทีแท้จริง รวมถึงระดับความ
มุ่งมันหรือการไม่ใส่ใจกับส่วนประกอบของซอฟต์แวร์
อีกเป้าหมายหนึงสําหรับการชีนิวตําหนิอย่างปลอดภัย
เมือระบบต่างๆ กลายเป็ นสิงทีมองเห็นได้ มันจะยากทีจะเพิกเฉยต่อพวกมัน ความแตกต่างในวัฒนธรรมท้องถินและ
ทัศนคติอาจส่งผลต่อขันตอนนี แต่โดยปกติฉนั จะคอยสังเกตความคิดเห็นทีเกิดขึนเอง (มักจะเป็ นการบ่นแบบเสียดสี) ซึงเราควร
บันทึกไว้ดว้ ย Hot Spots
จะไม่มีความปรานีสาํ หรับระบบภายนอก
การเพิมระบบใหม่มกั จะกระตุน้ ให้เกิดความจําเป็ นในการเพิมเหตุการณ์เพิมเติมเกียวกับสิงทีอาจเกิดขึนรอบๆ
เหล่านัน เช่น ความจําเป็ นในการต่ออายุใบอนุญาต หรือกิจกรรมธรรมดาๆ ทีเกิดขึนบริเวณขอบเขตของระบบ
ระบบ
เมือมีหลายระบบเข้ามาเกียวข้อง ฉันมักจะหลีกเลียงการสรุปมากเกินไป: หากพืนทีเริมจํากัด มักจะพบว่าผูค้ นเขียนคํา
อย่าง “โซเชียล” แทนทีจะระบุอย่างชัดเจนว่าเป็ น Facebook, Twitter, LinkedIn, YouTube และอืนๆ ซึงอาจทําให้รายละเอียด
ทีน่าสนใจถูกซ่อนจากการสนทนา
เช่นเดียวกันกับเหตุการณ์ หากข้อมูลเพิมเติมเหล่านีช่วยเพิมคุณค่าให้กับโมเดลของคุณ ก็เพียงแค่เพิมเหตุการณ์ที
เกียวข้องเข้าไป!
ขันตอน: การเดินผ่านอย่างชัดเจน
ตอนนีเวอร์ชนั ทีมีโครงสร้างมากขึนของกระบวนการกําลังค่อยๆ ปรากฏขึน แม้วา่ จะยังดูย่งุ เหยิงและไม่ชดั เจนในบางจุด
แต่ภาพรวมทังหมดก็ยงั ไม่รูส้ กึ มันคงดี
วิธีทียอดเยียมในการสร้างความสมําเสมอในช่วงนีคือการขอให้ใครสักคนเดินผ่านลําดับเหตุการณ์
เชือมโยงเหตุการณ์เหล่านันเข้าด้วยกัน
โดยเล่าเรืองราวที
เมือฉันพูดว่า "เดินผ่าน" ฉันหมายถึงในเชิงปฏิบตั ิจริง: การพูดถึงเหตุการณ์ต่างๆ ในขณะทีเดินผ่านหน้าพืนผิวทีใช้สร้าง
โมเดล ซึงจริงๆ แล้วจะช่วยกระตุน้ "พลังพิเศษ" บางอย่างของนักออกแบบโมเดล
เสียงของเราจะพยายามเล่าเรืองราวทีสอดคล้องกัน: “ผูใ้ ช้จะเข้าเยียมชมเว็บไซต์ของเรา ค้นหาข้อเสนอพิเศษในหน้า
แรก...” ในเวลาเดียวกัน ร่างกายของคุณจะค่อยๆ เดินไปข้างหน้า และคุณจะรูส้ กึ แปลกถ้ากระบวนการยังไม่สอดคล้องกัน และ
คุณต้องเดินถอยหลังหรือเดินไปเดินมาเพือสัมผัสกับเหตุการณ์ทเกี
ี ยวข้อง
อย่างไรก็ตาม การพูดออกเสียงเพือเล่าเรืองราวจะบังคับให้สมองของคุณคิดให้รอบคอบก่อนจะพูดอะไรออกไป หรือ
อาจต้องคิดเพิมอีกทีหลัง
ในทางปฏิบตั ิ คุณอาจพบความคิดเพิมเติม เช่น “เดียวนะ! ผูใ้ ช้จะรูจ้ กั เว็บไซต์ของเราได้อย่างไร? แย่แล้ว เราลืม
พิจารณาเกียวกับแคมเปญโปรโมชันและการทํา Search Engine Optimization!”
ุ ต้องเพิมเหตุการณ์เข้าไปเรือยๆ
นีเป็ นสัญญาณทีดีถา้ การเล่าเรืองของคุณมีสะดุดและบังคับให้คณ
สมองของคุณแปลว่ามันกําลังทํางานจริงๆ
ผูเ้ ล่าเรืองกําลัง “จัดเรียง” กระบวนการโดยรวมใหม่
ความเจ็บปวดใน
สิงนียังหมายความว่าการเป็ นผูเ้ ล่าเรืองต้องใช้พลังงานอย่างมาก เพราะทุกคนในห้องสามารถ (และควร) ขัดจังหวะคุณ
เพือท้าทายการเล่าเรืองทีกําลังดําเนินอยู่
เป็ นความคิดทีดีทีจะเปลียนผูเ้ ล่าเรืองในลักษณะคล้ายการวิงผลัด เมือถึงเหตุการณ์สาํ คัญ เช่น “และนีคือจุดทีทีม
ของแมรีเข้ามารับช่วงต่อ” ซึงเปิ ดโอกาสให้ผเู้ ชียวชาญได้แสดงความสามารถในพืนทีทีพวกเขาเชียวชาญ
ผูด้ แู ลควรตรวจสอบให้แน่ใจว่าการเล่าเรืองด้วยคําพูดสอดคล้องกับโมเดล:
ขณะทีผูเ้ ล่าเรืองกําลังดําเนินการอยู่
เหตุการณ์หรือระบบทีขาดหายไปสามารถเพิมเข้าไปได้ทนั ที
การจัดการการสนทนา
บางการสนทนาไม่สามารถหาข้อสรุปได้ในระหว่างเวิรก์ ช็อป และการมุ่งเน้นไปทีประเด็นเดียวอาจไม่ใช่วธิ ีทีดีทีสุดใน
การใช้เวลาของทุกคนอย่างคุม้ ค่า เมือการสนทนาเริมไม่มีขอ้ สรุป ฉันมักจะทําเครืองหมายด้วย Hot Spot (เพือแสดงว่าจะไม่ถกู
ลืม) และดําเนินการต่อไป
ในทางกลับกัน บางการสนทนาอาจน่าสนใจสําหรับทุกคน และเวิรก์ ช็อปนีอาจเป็ นโอกาสครังเดียวในชีวิตทีจะได้รบั คํา
ชีแจงทีรอคอยมานาน
ไม่มีกลยุทธ์ตายตัวในการจัดการการสนทนา ณ จุดนัน ฉันชอบสังเกตภาษากายของผูเ้ ข้าร่วม ซึงมักจะบอกอะไรได้มาก
ตังแต่ “โอ้ อย่าอีกเลย!” ไปจนถึง “เอาป๊ อปคอร์นมาเลย อันนีแหละทีรออยู่!” และ/หรือถามพวกเขาโดยตรงว่าต้องการทําอะไร
มันไม่มีเหตุผลทีจะยุติการสนทนาทีทุกคนรอคอย เพียงเพือทําตามตารางเวลาของผูด้ แู ล เพราะเวิรก์ ช็อป Big Picture
เป็ นเวิรก์ ช็อปสําหรับการค้นพบ เราไม่สามารถคาดเดาได้วา่ ความประหลาดใจจะเป็ นอย่างไร และเราควรพร้อมทีจะทิง
บางส่วนของแผน หากเราค้นพบสิงทีน่าสนใจกว่า
การเล่าเรืองย้อนกลับ
การทําความเข้าใจกระบวนการทังหมดโดยการรวมเรืองราวทีเป็ นอิสระเข้าด้วยกันอาจเป็ นกิจกรรมทีต้องใช้ความ
พยายามมากทีสุดในเวิรก์ ช็อป Big Picture ซึงมักจะต้องได้รบั รางวัลเป็ นการพักเบรก...เพราะเรายังไม่เสร็จสิน
ตอนนีกระบวนการทังหมดควรดูมีความหมายและสมเหตุสมผลสําหรับผูเ้ ข้าร่วม
การมีสว่ นร่วมของพวกเขาใน
กระบวนการโดยรวมสามารถมองเห็นได้ชดั เจนในภาพรวม อย่างไรก็ตาม นีก็ยงั ไม่ใช่เรืองราวทีแท้จริง การเล่าเรืองทีเราเพิง
ปรับให้ลนไหลผ่
ื
านการเดินเรืองนันยังไม่ได้สะท้อนความซับซ้อนทังหมดของกระบวนการ
ตอนนีถึงเวลาทีจะท้าทายโมเดลของเราด้วยวิธีคิดทีแตกต่างออกไป ด้วยเทคนิคเล็กๆ ทีเรียกว่า Reverse Narrative
แนวคิดมีดงั นี:
1. เลือกเหตุการณ์จากตอนท้ายของกระบวนการ แล้วค้นหาเหตุการณ์ทีทําให้มนั เกิดขึนได้ เหตุการณ์ตอ้ งมีความ
สอดคล้องกัน: ต้องเป็ นผลโดยตรงจากเหตุการณ์ก่อนหน้า โดยไม่มีช่องว่างทีอธิบายไม่ได้เกิดขึนระหว่างนัน
การพูดออกเสียงอีกครังจะมีประโยชน์มาก ช่วยเผยให้เห็นสมมติฐานทีไม่สอดคล้องกัน
2. หากมีขนตอนหรื
ั
อข้อมูลบางอย่างทีขาดหายไป
เราจําเป็ นต้องเพิมเหตุการณ์หรือกระบวนการย่อยที
สอดคล้องกันลงไปในโมเดลของเรา
3. เหตุการณ์อืนๆ ทุกเหตุการณ์กต็ อ้ งมีความสอดคล้องเช่นกัน ดังนันคุณอาจต้องทําซําขันตอนนีตามทีจําเป็ น
จนกว่ากระบวนการทังหมดจะสมบูรณ์
การเล่าเรืองย้อนกลับในทางปฏิบตั ิ
คุณอาจต้องการตังคําถามทีท้าทายผูฟ้ ั ง เช่น “ดังนัน [เหตุการณ์ A] คือทังหมดทีจําเป็ นเพือให้เกิด [เหตุการณ์ B] ใช่
หรือไม่?” หรือ “อะไรคือสิงทีต้องเกิดขึนเพือให้ [เหตุการณ์ C] เกิดขึน?”
นีคือตัวอย่างเล็กๆ จากขอบเขตงานของบริษัทของฉัน
บริษัทของเราจัดเวิรก์ ช็อปสาธารณะ และเราต้องการมอบใบรับรองการเข้าร่วมให้กบั ผูเ้ รียนของเรา
เริมต้นจากตอนท้าย เราจะพบกับเหตุการณ์ทีว่า ใบรับรองได้ถกู ส่งมอบแล้ว ใบรับรองกระดาษของเราจะต้องได้รบั การ
เซ็นชือโดยผูส้ อน แต่ตอ้ งพิมพ์ออกมาก่อนการจัดเวิรก์ ช็อป ซึงหมายความว่าจะต้องมีเหตุการณ์ ใบรับรองได้รบั การเซ็น
โดยผูส้ อน และ ใบรับรองได้รบั การพิมพ์ แต่กระบวนการยังไม่จบเพียงเท่านี: ใบรับรองเป็ นข้อมูลเฉพาะบุคคล เรา
จําเป็ นต้องได้รบั ชือของผูเ้ ข้าร่วมก่อนทีจะพิมพ์ใบรับรอง
“เรามีขอ้ มูลชือในข้อมูลตัวแล้ว!” มีคนกล่าว แต่ปรากฏว่าไม่ใช่กรณีเสมอไป: ตัวแบบรายบุคคลอาจมีขอ้ มูลนี แต่ในกรณี
ทีซือตัวแบบกลุ่มโดยองค์กรขนาดใหญ่ ข้อมูลเหล่านีอาจไม่ได้ระบุไปยังผูเ้ ข้าร่วม หรืออาจมีการเปลียนแปลงชือในนาที
สุดท้าย
ในทางปฏิบตั ิ สิงนีหมายความว่าเรามีเหตุการณ์เพิมเติมอีกสองสามอย่าง: ชือผูเ้ ข้าร่วมได้รบั การบันทึก (Participant
Name Acquired) หรือ ผูเ้ ข้าร่วมลงทะเบียน (Participant Registered) ซึงเป็ นผลโดยตรงจากการขายตัว (Ticket Sold)
แต่ก็อาจเกิดขึนเป็ นเหตุการณ์อิสระได้เช่นกัน แน่นอนว่าเราอาจต้องการเหตุการณ์ทีชือว่า เปลียนชือผูเ้ ข้าร่วม
(Participant Name Changed) ในกรณีทีบริษัทโอนตัวให้กบั ผูอ้ ืน
อืม… จริงๆ แล้ว ฉันชอบคําว่า ตัวถูกโอน (Ticket Transferred) มากกว่า
การเล่าเรืองย้อนกลับ (Reverse Narrative) เป็ นเครืองมือทีทรงพลังในการเสริมสร้างความสอดคล้องของระบบ แม้วา่
เราจะคิดว่าเราสํารวจไปข้างหน้าเสร็จสินแล้ว เรามักจะค้นพบส่วนสําคัญของระบบ (ประมาณ 30-40%) ทีถูกมองข้าม
เนืองจากความคิดทีมองโลกในแง่ดีเกินไป
ทังการทบทวนอย่างชัดเจน (Explicit Walk-through) และการเล่าเรืองย้อนกลับ (Reverse Narrative) อาจใช้เวลามาก
แต่เวลาทีใช้นถืี อว่าคุม้ ค่า: มันให้ขอ้ มูลเชิงลึกและความมันคงทีขาดหายไปในขันตอนก่อนหน้า อย่างไรก็ตาม หากคุณมี
ข้อจํากัดด้านเวลาทีเข้มงวด คุณอาจต้องเลือกทีจะลดความลึกของขันตอนเหล่านีลง เพือให้สามารถดําเนินการในขันตอนถัดไป
ได้ทนั เวลา
การเลือกเหตุการณ์ทีเป็ นตัวเลือก
บางเหตุการณ์เป็ นตัวเลือกทีเหมาะสมสําหรับการสํารวจย้อนกลับ: เหตุการณ์ปลายทาง (terminal events) ซึงเป็ น
เหตุการณ์ทีอยู่ตอนท้ายของกระบวนการและดูเหมือนจะ "ปิ ดทุกอย่าง" เป็ นตัวเลือกทีเหมาะสมตามธรรมชาติสาํ หรับบทบาทนี
ฉันยังชอบเริมสํารวจจากเหตุการณ์สาํ คัญ (pivotal events) ซึงเป็ นเหตุการณ์ทีปิ ดแต่ละช่วงเฉพาะ โดยมักจะมี
โครงสร้างคล้ายกับรายการตรวจสอบ (checklist)
ขันตอนพิเศษ: เพิมเรืองเงินเข้าไป
เมือใดก็ตามทีฉันจัดเวิรก์ ช็อปกับนักพัฒนาซอฟต์แวร์ พวกเขามักจะละเลยส่วนทีเกียวข้องกับกระแสเงินเสมอ: ผู้
ให้บริการไม่ได้รบั เงิน, ใบแจ้งหนีไม่ได้รบั หรือไม่ได้ถกู ส่งออกไป และส่วนสําคัญของระบบทีเกียวข้องกับเรืองเงินมักถูกมองข้าม
หรือข้ามไป
ฉันคาดว่าคําอธิบายเกียวกับเรืองเงินสําหรับนักพัฒนาซอฟต์แวร์มกั อยูใ่ นจุดตัดระหว่าง "เรืองทีชัดเจน" และ "เรืองทีน่า
เบือ" มักมีบางสิงทีน่าตืนเต้นมากกว่าการตรวจสอบรอบการจ่ายเงิน เว้นแต่ว่าคุณกําลังสํารวจกระบวนการทางธุรกิจของบริษัท
ทีเกียวกับฟิ นเทคหรือสกุลเงินดิจทิ ลั
อย่างไรก็ตาม การทําความเข้าใจกลไกทางการเงินเป็ นสิงสําคัญต่อการอยู่รอดขององค์กร และอาจสําคัญยิงกว่าสําหรับ
สตาร์ทอัพทีพยายามไปสู่ความยังยืน หากการสํารวจเรืองนีดูไม่ครอบคลุม หรือคําเชิญทีส่งไปไม่สามารถดึงตัวผูท้ ีดูแลเรืองเงิน
เข้ามาในห้องได้ การจัดรอบสํารวจสันๆ ทีมุ่งเน้นไปทีกระแสเงิน (money flow) ก็เป็ นความคิดทีดีเพือปรับสมดุลจุดบอดเหล่านี
เพือให้ยตุ ิธรรม เรืองเงินเป็ นเพียงหนึงในหลายๆ สกุลค่าต่างๆ (value currencies) ทีอาจตกเป็ นเหยือของการมองข้าม
อย่างเลือกสรร เราจะพูดถึงเรืองนีเพิมเติมในบททีว่าด้วยการเล่นกับมูลค่า (playing with value)
เรืองเล่าทีสอดคล้องกันเริมปรากฏขึน
ทุกขันตอนของการสํารวจช่วยเพิมความชัดเจน รายละเอียด และความสอดคล้องต่อความเข้าใจในพลวัตทางธุรกิจของ
เรา โครงสร้างทีเกิดขึนจากแบบจําลองมีคณ
ุ ค่าอย่างมาก: รูปร่างของแผนทีจะติดอยู่ในความทรงจําของเราไปอีกนาน
โดยเฉพาะอย่างยิงเพราะเราต้องพยายามอย่างหนักเพือให้ได้มนั มา
กระบวนการสํารวจนําไปสู่บทสนทนาทีน่าสนใจ คนทีเคยมีความเข้าใจเพียงบางส่วนเกียวกับกลไกและข้อจํากัดของ
กระแสงาน ตอนนีสามารถมองเห็นภาพรวมทังหมดในรูปแบบของเรืองเล่าทางธุรกิจทีสอดคล้องกัน ทังหมดนีอาจไม่สมบูรณ์
แบบหรือสวยงาม แต่ควรมีความสมเหตุสมผลในแง่ของการเล่าเรือง
เรืองเล่าทางธุรกิจทีชัดเจน ซึงส่งมอบคุณค่าให้กบั ผูเ้ ล่นหลักในระบบ นีคือสิงทีฉันคาดหวังว่าจะ “เห็น” ในตอนจบ
ก็…นันคือความตังใจ! ความพยายามในการเล่าเรืองควรจะช่วยเน้นให้เห็นถึงความไม่สอดคล้องในกระบวนการ ซึง
ตอนนีได้รบั การท้าทายและตรวจสอบอย่างเป็ นทางการแล้ว
บางขันตอนอาจขาดเหตุผลทีชัดเจน ดูลา้ สมัย หรือไม่เป็ นธรรมชาติ ยิงองค์กรมีขนาดใหญ่เท่าไร วิธีแก้ปัญหาในอดีตยิง
มีแนวโน้มทีจะคงอยู่ต่อไป แม้วา่ ปั ญหาเดิมทีมันถูกสร้างขึนมาเพือแก้ไขจะหายไปนานแล้ว
ขันตอนอืนๆ อาจดูเป็ นปั ญหา โดยเฉพาะอย่างยิงหากกระบวนการหรือซอฟต์แวร์เก่าทีมีอยู่บงั คับให้ลกู ค้าและพนักงาน
ต้องทํากิจกรรมเพิมเติมทีไม่มรี างวัลชัดเจนอยู่เบืองหน้า
ฉันไม่สามารถบอกล่วงหน้าได้วา่ คุณจะพบอะไร แต่คณ
ุ จะรูว้ า่ คุณพบมันแล้วเมือคุณเห็นมัน การค้นพบความไม่
สอดคล้องอาจทําให้รูส้ กึ อึดอัดใจในบางครัง แต่มนั จะดีกว่าหากเรามุ่งเน้นไปทีโอกาสทีข้อบกพร่องทีถูกเปิ ดเผยในเรืองเล่าของ
เราจะนําพาเราไปสู่ทางแก้ใหม่ๆ
ขันตอน: ปัญหาและโอกาส
และได้แสดงความคิดเห็นเกียวกับพวกเขาผ่านจุดร้อนเชิงเสียดสี
เมือเราได้รวมผูค้ นและระบบภายนอกเข้ามา
(sarcastic hot spots) เราก็ได้บรรลุเป้าหมายระหว่างทางทีน่าสนใจมาก
ตอนนีระบบทังหมดควรจะมองเห็นได้อย่างชัดเจน
เราอาจไม่ได้สนใจในรายละเอียดเชิงกลไกของสิงทีเกิดขึนภายในระบบภายนอกมากนัก เว้นแต่วา่ กลไกภายในเหล่านัน
จะมีความสําคัญต่อองค์กรของเรา (ลองนึกถึงบริษัททีตลาดถูกควบคุมอย่างเข้มงวด พวกเขามักจะใส่ใจมากกับสิงทีเกิดขึน
ภายในองค์กรของผูก้ าํ กับดูแล)
สิงทีเราสนใจเป็ นพิเศษคือสิงทีเกิดขึนบริเวณขอบเขตระหว่างเราและระบบภายนอก
และเพือทีจะมองเห็นขอบเขต
เหล่านัน หรือพืนทีทีไม่มีใครครอบครอง (no-man’s land) ระหว่างกัน จําเป็ นต้องมองเห็น “อีกฝังหนึง” บ้างเล็กน้อย
นีเป็ นช่วงเวลาทีดีสาํ หรับการเกิดความเข้าใจอย่างฉับพลัน (spontaneous insights) สมมติว่าทุกอย่างสามารถมองเห็น
ได้ แต่ก็อาจหมายความว่าบางคนยังไม่เห็นสิงทีพวกเขาคาดหวังว่าจะได้เห็น ในเวิรก์ ช็อปบางครัง ความรูส้ กึ นีอาจนําไปสู่
ขันตอนเพิมเติมทีตรวจสอบคุณค่าทีถูกสร้างขึนและถูกทําลายลงตลอดกระบวนการไหล ขันตอนนีมีความสําคัญมากจนสมควร
ทีจะมีบทเฉพาะของตัวเอง
มองหาสิงกีดขวางทีสําคัญ
ในขันตอนนี ความยิงใหญ่ของกระบวนการธุรกิจของเรา รวมถึงข้อจํากัดและอุปสรรคต่างๆ ควรจะสามารถมองเห็นได้
อย่างชัดเจนในทุกแง่มมุ ถึงเวลาแล้วทีจะตัดสินใจว่าควรทําอะไรต่อไป แต่ก่อนทีจะเลือกดําเนินการขันต่อไป ควรให้ทกุ คนมี
โอกาสสุดท้ายในการแสดงความคิดเห็นให้ปรากฏอย่างชัดเจน
เพือทําเช่นนัน ฉันขอเสนอเวลาแบบจํากัด 10-15 นาทีอย่างเป็ นทางการ เพือเพิม "ปั ญหา" และ "โอกาส" ลงใน
แบบจําลองของเรา ปัญหาจะถูกนําเสนอด้วยสัญลักษณ์จดุ ร้อน (Hotspot) ทีเราคุน้ เคย ขณะทีโอกาสจะสร้างสมดุลด้วยสีเขียว
ในเชิงมองโลกในแง่ดี เพือเติมเต็มสีม่วงทีเคยใช้นาํ เสนอปั ญหา
การสร้างสมดุลระหว่างปัญหาและโอกาส: นําท่วมของปัญหาสีม่วงอาจดูน่าหนักใจ แต่…เราก็มีไอเดียสีเขียวมากมายทีจะเข้า
มาช่วยกูส้ ถานการณ์!
ฉันคาดหวังว่าปั ญหาส่วนใหญ่จะได้ถูกเปิ ดเผยออกมาแล้วในขันตอนก่อนหน้านี แต่ขนตอนนี
เปิ ดโอกาสให้ทกุ คนแสดง
ั
ความคิดเห็นอย่างปลอดภัย โดยไม่จาํ เป็ นต้องสร้างความขัดแย้งอย่างเปิ ดเผย ซึงทําให้เหมาะสมอย่างยิงในสถานการณ์ของ
องค์กร หรือในกรณีทีทัศนคติระหว่างบุคคลเป็ นประเด็นสําคัญ ฉันคาดว่าขันตอนนีจะดําเนินไปอย่างรวดเร็วและเงียบสงบ แต่ก็
อาจนําไปสู่ความประหลาดใจทีน่าสนใจได้
โอกาสสีเขียวเข้ามาเป็ นคู่สมดุลทีสมบูรณ์แบบสําหรับ "นําท่วม" ของปั ญหาทีอาจเกิดขึน เรามีทงทางแก้
ไขและผู้
ั
แก้ปัญหาอยูใ่ นห้องนีด้วย! มีความหวังอยูเ่ สมอ!
ขันตอน: เลือกปัญหาของคุณ
ในเซสชันทัวไป ตอนนีคุณน่าจะมีปัญหาและโอกาสหลายสิบรายการติดอยู่บนกระดาน ไม่มีใครทีจะสามารถแก้ไขทุก
อย่างได้อย่างรวดเร็ว และก็ไม่มใี ครทีจะสามารถไล่ตามทุกโอกาสทีเป็ นไปได้ ดังนันเราจะต้องหาวิธีนาํ ทางออกจากสถานการณ์
นี
เวลาอาจใกล้จะหมดลงแล้ว เนืองจากนีเป็ นกิจกรรมปิ ดท้าย แต่เราอาจยังต้องสแกนดูรายการล่าสุดอย่างรวดเร็ว และ
จัดกลุ่มรายการเหล่านันในแบบจําลองก่อนทีจะเริมลงคะแนนเสียง
การลงคะแนนแบบลูกศร (Arrow Voting)
กิจกรรมปิ ดท้ายทีฉันชอบสําหรับ Big Picture EventStorming คือการลงคะแนนแบบลูกศร (Arrow Voting)
หากคุณคุน้ เคยกับการทํา retrospective แบบ Agile คุณอาจจะรูจ้ กั วิธีการลงคะแนนแบบจุด (Dot Voting) อยู่แล้ว ซึง
การลงคะแนนแบบลูกศรนันคล้ายกันมาก…แค่มคี วามแสดงออกมากกว่าเท่านัน!
การลงคะแนนแบบลูกศรในทางปฏิบตั :ิ เลือกเป้าหมายของคุณ!
ํ นรูปลูกศร
1. ผูเ้ ข้าร่วมเวิรก์ ช็อปทุกคนมีสิทธิลงคะแนนได้สองครัง โดยใช้สติกเกอร์สีนาเงิ
2. ลูกศรควรชีไปยังปั ญหาสีมว่ ง (purple problem) หรือโอกาสสีเขียว (green opportunity) ทุกคนสามารถเลือก
เกณฑ์การลงคะแนนของตนเองได้อย่างอิสระ ฉันมักจะใช้คาํ ว่า “ปั ญหาทีสําคัญทีสุดทีต้องแก้ไข” โดยเข้าใจ
ว่า ‘สําคัญ’ เป็ นคําทีขึนอยู่กบั มุมมองของแต่ละบุคคล การลงคะแนนสามารถชีไปทีเป้าหมายเดียวกัน หรือสอง
เป้าหมายทีแยกกันก็ได้
3. การลงคะแนนจะเกิดขึนพร้อมๆ กัน ไม่มีการลงคะแนนแบบทีละคน (no voting catwalk)
การลงคะแนนแบบลูกศรในทางปฏิบตั :ิ เลือกเป้าหมายของคุณ!
ฉันคาดหวังว่าการลงคะแนนรอบนีจะเป็ นไปอย่างรวดเร็ว (ปกติจะใช้เวลาเพียงไม่กีนาที) โดยทีผูเ้ ข้าร่วมจะกลับมา
รวมตัวกันรอบพืนผิวของแบบจําลองอีกครัง เลือกตําแหน่งทีพวกเขาจะวางลูกศรลงไป ภาษากายของผูเ้ ข้าร่วมในช่วงนีอาจเป็ น
แหล่งข้อมูลเชิงลึกทีน่าสนใจอีกครัง
ผูด้ าํ เนินกระบวนการควรตรวจสอบให้แน่ใจว่าไม่มีการใช้อาํ นาจครอบงําเกิดขึนในช่วงนี (โดยเฉพาะในสถานการณ์
องค์กร) เช่น การขอให้ผมู้ ีอิทธิพลหลักในห้องรอเล็กน้อยก่อนลงคะแนน เพือไม่ให้ส่งผลกระทบต่อการตัดสินใจของผูเ้ ข้าร่วมคน
อืน
เมือผูเ้ ข้าร่วมเริมถอยออกจากพืนทีและเข้าสู่โหมดพิจารณาเงียบๆ ก็ถึงเวลาทีจะสรุปกระบวนการนีแล้ว
มองผ่านหมอกควัน
หลังจากการทํางานทังหมดนี (เราเริมต้นจากความยุ่งเหยิงทีไม่เป็ นระเบียบ เราได้เพิมโครงสร้าง รวมผูค้ นและระบบ
ภายนอกเข้ามา สํารวจความไม่สอดคล้องทังในลักษณะเดินหน้าและถอยหลัง) ตอนนีเราควรมีทิศทางทีชัดเจนเกียวกับสิงที
ต้องทําต่อในเช้าวันถัดไปแล้ว
ภาพผลลัพธ์ของเวิร์กช็อปแบบภาพรวมใหญ่: มีสติกเกอร์มากกว่าทีคุณเคยจินตนาการไว้…
ดูเหมือนว่าตอนนีเราจะมีผนังทีเต็มไปด้วยสติกเกอร์หลากสี (ถ้ามีใครเพิงเข้ามาเห็นผลลัพธ์ในตอนนี พวกเขาอาจไม่
เข้าใจอะไรมากนัก) แต่ยงั มีอะไรมากกว่านัน
เราได้บรรลุถึงระดับของการตระหนักรูท้ ีลึกซึงขึน
เรารวมเอาความเชียวชาญและมุมมองทีแตกต่างกันเข้าด้วยกัน
เกียวกับโครงสร้าง จุดมุง่ หมาย และกลไกขององค์กรของเรา และเราได้ลงคะแนนเสียง (พร้อมทังเน้นด้วยลูกศรสีนาเงิ
ํ น) เพือ
ระบุปัญหาทีสําคัญทีสุดทีควรให้ความสําคัญ
พูดอีกอย่างหนึง นีคือสิงทีฉันคาดหวังว่าจะได้มองเห็นผ่านหมอกควัน
ภาพของผลลัพธ์จากเวิรก์ ช็อปภาพรวมใหญ่: มีสติกเกอร์มากกว่าทีคุณเคยจินตนาการไว้…
นีคือจุดทีเราควรมุ่งเน้นความพยายามของเราในเช้าวันถัดไป ขอบคุณทุกคน! วันนีเป็ นวันทียาวนานจริงๆ
เราควรลงคะแนนเสมอหรือไม่?
เอ่อ...ไม่เสมอไป! การลงคะแนนควรเกิดขึนก็ต่อเมือคุณสามารถจัดการผลลัพธ์ทีตามมาได้อย่างเหมาะสม ต่อไปนีคือ
บางเหตุผลทีไม่ควรเรียกให้ลงคะแนน:
1. ส่วนผสมของผูเ้ ข้าร่วมไม่เหมาะสม: มุมมองจากฝ่ ายใดฝ่ ายหนึงอาจเป็ นแหล่งความคิดเห็นทีเชือถือได้ แต่
ไม่ใช่การวินิจฉัยทีครอบคลุมทังระบบ
2. ขอบเขตไม่ถกู ต้อง: การสํารวจทังหมดอาจเกินขอบเขตทีเราสามารถจัดการได้ เราอาจลงคะแนนได้ แต่
ข้อจํากัดสําคัญทีแท้จริงอาจถูกซ่อนอยู่ในทีอืน
3. ข้อจํากัดด้านการเปิ ดเผยข้อมูล: ในสถานการณ์การสํารวจความต้องการก่อนการขาย องค์กรอาจเปิ ดรับการ
สํารวจ แต่ไม่พร้อมทีจะเปิ ดเผยจุดอ่อนของตน
4. เร็วเกินไป: สําหรับสตาร์ทอัพทีอยู่ในระยะเริมต้น พวกเขาอาจยังไม่มีอปุ สรรคทีแท้จริง มีเพียงรายการ
สมมติฐานทีต้องถูกท้าทายและคําถามทีต้องการคําตอบ
โดยทัวไป ยังมีรูปแบบทีน่าสนใจอืนๆ ทีแตกต่างไปจากการทํา Big Picture และบริบทอาจพาเราไปสู่กาํ หนดการที
แตกต่างกัน เราจะพูดถึงหัวข้อนีอย่างลึกซึงในบทว่าด้วย Big Picture Variations
สรุปโครงสร้างทีสัญญาไว้
• การเชิญผูเ้ ข้าร่วม: ตรวจสอบให้แน่ใจว่าคุณมีคนทีเหมาะสมในห้อง ได้แก่ คนทีรูจ้ ริงและคนทีใส่ใจในเรือง
นัน
• การจัดเตรียมห้อง: จัดพืนทีให้เพียงพอสําหรับให้กลุ่มของคุณทํางานบนพืนผิวการสร้างแบบจําลองได้อย่าง
ราบรืนทีสุด อย่าลืมพืนฐานสําคัญ เช่น อาหาร แสงสว่าง และอากาศทีสดชืน
• การเริมต้น: ทําให้แน่ใจว่าทุกคนรูส้ กึ สอดคล้องกับเป้าหมายของเวิรก์ ช็อป อาจมีรอบวอร์มอัพเล็กๆ เพือ
สร้างบรรยากาศ
ทุกคนเริมต้นเพิมเหตุการณ์ในโดเมนทีพวกเขารับรูล้ งบนพืนผิวการสร้าง
• การสํารวจแบบไร้ระเบียบ:
แบบจําลองอย่างกระตือรือร้น การสนทนาทีน่าสนใจอาจเกิดขึน แต่โดยส่วนใหญ่ผคู้ นจะทํางานในโหมดที
เงียบและเป็ นคู่ขนานกันอย่างมหาศาล
ั ความหมายโดยการจํากัดให้กระแสงานอยู่ในไทม์ไลน์เดียว สิง
• จัดการไทม์ไลน์: ทําให้โมเดลขนาดใหญ่นนมี
นีบังคับให้ผคู้ นต้องพูดคุยในสิงทีหลีกเลียงมาตลอดจนถึงตอนนี โครงสร้างจะเริมปรากฏขึนจากแม่แบบ
ร่วมกัน เหตุการณ์เพิมเติมจะถูกเพิมเข้ามา แต่ส่วนใหญ่จะเป็ นการขยับเหตุการณ์เพือให้ได้โครงสร้างทีมี
ความหมาย นีคือช่วงเวลาทีจุดร้อน (Hot Spots) เริมปรากฏขึน
• ผูค้ นและระบบ: บทบาทสําคัญในกระบวนการธุรกิจของเราคืออะไร? เมือทําให้ผคู้ นและระบบปรากฏอย่าง
ชัดเจน เรามันใจได้ในระดับหนึงว่า หากมีกีดขวางในกระบวนการ พวกมันจะสามารถมองเห็นได้โดยทุกคน
ในห้อง ขันตอนนียังเป็ นตัวกระตุน้ จุดร้อน (Hot Spots) อีกด้วย: เมือทุกสิงปรากฏชัด ผูค้ นมักอดไม่ได้ทีจะให้
ความคิดเห็น
• การเดินผ่านกระบวนการอย่างชัดเจน (Explicit Walk-through): ผูบ้ รรยายทีแตกต่างกันจะรับหน้าทีในส่วน
ต่างๆ ของระบบ อธิบายพฤติกรรมทีมองเห็นได้ และยอมรับคําท้าทายหรือคําถามจากผูเ้ ข้าร่วมคนอืนๆ
• การเล่าเรืองย้อนกลับ (Reverse Narrative): หากเรามีความมันใจในกระแสงานโดยรวม เราสามารถขอให้
ผูเ้ ข้าร่วมคิดในลําดับเวลากลับกัน หรือในลําดับเหตุและผลทีเข้มงวดตามทีคุณต้องการ ขันตอนนีมักจะ
นําไปสู่การเพิมเหตุการณ์ใหม่ๆ เข้าไปในโมเดล และทําให้กระบวนการเดิมซับซ้อนยิงขึนกว่าทีเคยเป็ น
• ปั ญหาและโอกาส (Problems and Opportunities): นีคือช่วงเวลาทีเปิ ดโอกาสให้ทกุ คนในห้องได้แสดง
ความคิดเห็นและนําเสนอไอเดียเกียวกับกระแสงานในปัจจุบนั
• เลือกปัญหาทีถูกต้อง: เมือทุกอย่างมองเห็นได้ชดั เจนและถูกทําเครืองหมายด้วยจุดร้อน (Hot Spot) อาจถึง
เวลาทีเหมาะสมทีจะเลือกปัญหาทีสําคัญทีสุด (หรือปั ญหาทีสําคัญทีสุดหลายๆ เรือง) ทีต้องแก้ไข บางครัง
อาจมีฉันทามติทชัี ดเจน และบางครังคุณอาจต้องลงคะแนน ซึงอาจนําไปสู่ความประหลาดใจ
• สรุปขันตอน (Wrapping up): ถ่ายภาพขันตอนสุดท้าย จัดการบทสนทนาปิ ดท้าย ทําความสะอาดพืนทีที
จําเป็ น หรือหากยังไม่สะดวกก็เลือนไปจัดการในภายหลัง
เป้าหมายของบทนี:
• เข้าใจกลไกพืนฐานของ Big Picture EventStorming และแต่ละขันตอนในกระบวนการ
• เข้าใจสิงทีสามารถบรรลุได้ในเวิรก์ ช็อปเพียงครังเดียว
• เตรียมพร้อมสําหรับความประหลาดใจทีอาจเกิดขึนในระหว่างเวิรก์ ช็อปการค้นพบขนาดใหญ่
5 การเล่นกับค่า
ขันตอนทางเลือก
สํารวจค่า
ค้นพบสกุลเงินหลากหลาย
สํารวจเป้าหมาย
คุณถูกปรับให้เหมาะสมสําหรับอะไร?
เป้าหมายของบท:
• ค้นพบวิธีการสํารวจคุณค่าบนพืนฐานของการทําเซสชัน EventStorming
• เตรียมพร้อมทีจะถามและตอบคําถามทียาก
• เตรียมตัวให้พร้อมในการเลือกว่าคุณต้องการเป็ นองค์กรแบบใด
6 ทําให้มนั เกิดขึน
การจัดการประสบการณ์ของผูเ้ ข้าร่วม
ผูด้ าํ เนินการ (Facilitator) เป็ นผูร้ บั ผิดชอบหลักในการสร้างประสบการณ์ทีดีให้กบั ผูเ้ ข้าร่วมเวิรก์ ชอป หน้าทีของเขาคือการ
สอดส่องหาอุปสรรคทีขัดขวางการไหลเวียนทีเหมาะสม และกําจัดอุปสรรคเหล่านันด้วยวิธีทีราบรืนทีสุด
เลือนความแม่นยําออกไปก่อน
ข้อกําหนดเริมต้น (กระดาษโน้ตสีสม้ พร้อมคํากริยารูปอดีตกาล) ดูเหมือนจะเรียบง่ายมากในตอนแรก แต่ในทางปฏิบตั ิ
มักไม่เป็ นไปตามนันในรอบแรก
โดยปกติ ฉันจะเข้มงวดในการบังคับใช้รูปแบบสี (หากมีสีหลายสี จะมีคนเลือกใช้สีผิดเสมอ) แต่ฉนั จะผ่อนปรนมากขึ น
เมือจัดการกับเหตุการณ์ในโดเมนทีใช้รูปแบบผิด
ั าสีอืนๆ ไม่ปรากฏให้เห็น แต่การใช้วลีผิดรูปแบบเป็ นเรืองทีต่างออกไป
ปั ญหาเรืองสีนนแก้
ั ได้ง่าย เพียงแค่ทาํ ให้มนใจว่
ซึงจะกลายเป็ นปัญหาในภายหลัง เนืองจากอาจซ่อนความซับซ้อนทีสําคัญบางอย่างไว้ อย่างไรก็ตาม ในช่วงเริมต้น (Ignition
Phase) สิงสําคัญคือต้องทําให้ผเู้ ข้าร่วมไม่รูส้ กึ ว่ากําลังถูกจับผิด โดยเฉพาะในสถานการณ์องค์กร
ดังนัน โดยปกติฉนั จะตรวจสอบแบบจําลองและปล่อยผ่านไปในช่วงแรก ตราบเท่าทีกระดาษโน้ตทีใช้ผิดรูปแบบไม่ใช่
ส่วนใหญ่
ทรัพยากรการสร้างแบบจําลองทีไม่มขี ีดจํากัด
ต้นทุนทีซ่อนอยู่ของปากกาทีหมดหมึก
คุณกําลังจะเริมการประชุม มีเพือนร่วมงานทียุ่งอยู่ 10 คนเข้าร่วม หลังจากกล่าวต้อนรับอย่างรวดเร็ว คุณหยิบปากกาเม
จิกขึนมาและเริมเขียนเป้าหมายของการประชุมลงบนกระดานไวท์บอร์ด แต่... นันเป็ นเพียงแค่แผน เพราะปากกาหมึกหมดจน
ใช้งานไม่ได้เลย คุณมองหาปากกาด้ามอืน... เจอปากกาสีแดง แต่สภาพก็ไม่ได้ดีกว่าเดิม
ฮึม... มีอาสาสมัครคนหนึงออกจากห้องเพือไปหาปากกาด้ามใหม่ เขากลับมาในอีกสองสามนาทีต่อมา แต่ในระหว่าง
นัน บรรยากาศบางอย่างได้หายไปแล้ว คุณไม่อยากพูดเรืองสําคัญเพราะมีคนหนึงขาดไป แต่ในขณะเดียวกัน ผูค้ นก็ไม่ชอบที
จะอยู่นงเฉย
ิ บางคนเริมสนทนาเล่นกัน บางคนก็เช็กสมาร์ทโฟนเพือทําสิงทีค้างคา
เพือนร่วมงานของคุณกลับมาพร้อมกับปากกาด้ามใหม่ พร้อมเล่าเรืองคําถามน่าอายทีเขาต้องตอบเพือจะได้ปากกามา
คุณลองใช้ปากกาใหม่เพือความมันใจ ผ่านไป 10 นาทีหลังจากกําหนดเวลา คุณก็พร้อมจะเริม แต่มีคนหนึงยังยุง่ อยูก่ ับการ
สนทนาในแชททีเริมขึนตอนรอ
ห้องประชุมถูกจองไว้ 1 ชัวโมง แต่คณ
ุ เสียเวลาไป 16% ของเวลานันแล้ว หากนับคน 8 คนในห้องนี คิดเป็ นเวลา 1 ชัวโมง
20 นาทีของต้นทุนเฉลียรายชัวโมง ซึงมากกว่าราคาของปากกามาก ยิงน่ารําคาญไปกว่านัน การสูญเสียสมาธิและเป้าหมาย
อาจทําให้การประชุมไร้ประสิทธิภาพยิงขึนไปอีก
เวลาทีเสียไปมีความสัมพันธ์เชิงเส้นกับต้นทุนรายชัวโมง แต่ความสัมพันธ์กบั คุณค่าทีได้มานันขึนอยู่กบั สมาธิและการมี
ส่วนร่วมมากกว่าเวลา หากการตังค่าทีไม่กระตุน้ ความสนใจเกิดขึน การประชุมอาจไม่มปี ระโยชน์เลย
ตํานานทีมองเห็นได้
การทําให้แน่ใจว่าทุกคนรูว้ ่ากําลังทําอะไรอยู่เป็ นสิงสําคัญสําหรับการไหลลืนของเวิรก์ ชอป ควรจําไว้วา่ ผูเ้ ข้าร่วมเวิรก์ ช
อปส่วนใหญ่มกั ทําสิงนีเป็ นครังแรก ดังนันพวกเขาจะต้องการความมันใจและความปลอดภัยให้มากทีสุดเท่าทีคุณจะให้ได้ พวก
เขาได้กา้ วออกมานอกเขตความสบายของตนเองแล้ว อย่าทําให้สิงต่างๆ ยากเกินความจําเป็ น
ตํานานทีมองเห็นได้ (Visible Legend) ซึงแสดงสัญลักษณ์หรือเครืองหมายปั จจุบนั ให้ชดั เจนและเข้าใจได้สาํ หรับทุกคน
อาจมีประโยชน์เพือหลีกเลียงอุปสรรคในการไหลของความคิด (เช่น “สิงสีชมพูนนหมายถึ
ั
งอะไรนะ?”)
มันยังช่วยให้...
การจับนิยาม
ในขณะทีทุกคนกําลังยุ่งอยู่กบั การเพิมเหตุการณ์ลงในแบบจําลอง ผูด้ าํ เนินการสามารถใช้ความสามารถของตนเองใน
การถามคําถามทีดูเหมือนโง่... เอ่อ หมายถึงคําถามทีชัดเจนเกินไป
หากทุกคนในห้องพูดถึงคําศัพท์ลกึ ลับหรือคําย่อ และคุณรูส้ กึ ว่าในโดเมนเฉพาะขององค์กร คํานีมีความหมาย
เฉพาะเจาะจงทีชัดเจนสําหรับทุกคนในห้องยกเว้นคุณ สิงทีควรทําคือ... เพียงแค่ถามหาคํานิยาม จากนันเขียนมันลงไป และ
วางไว้ทีด้านล่างของกระแสงาน (Flow)
ฉันมักใช้กระดาษโน้ตสีทีแตกต่างกันสําหรับนิยาม เพือให้แน่ใจว่ามันจะไม่ปะปนกับสัญลักษณ์หลัก ในกรณีนี ทุกคนพูด
ถึง "การลงทุน" (Investments) แต่ความหมายไม่ได้ชดั เจนสําหรับทุกคน
บ่อยครัง ผูด้ าํ เนินการไม่ใช่คนเดียวทีสงสัยว่า "การลงทุน" หมายถึงอะไรจริงๆ แต่คนอืนอาจไม่มนใจพอที
ั
จะถาม หาก
คุณได้รบั การพยักหน้าเงียบๆ แสดงความเห็นด้วย คุณได้ทาํ งานได้ดีแล้ว
สัญลักษณ์แบบเพิมทีละน้อย
ข้อบกพร่องของสัญลักษณ์
ในขณะทีพยายามทําความเข้าใจกับทังหมด ผูเ้ ข้าร่วมจะตระหนักได้อย่างรวดเร็วว่าการบังคับใช้เส้นเวลา (Timeline)
นันเป็ นเรืองยุง่ ยากและอาจง่ายเกินไป แม้ว่ามันจะตอบสนองวัตถุประสงค์หลักในการกระตุน้ การสนทนาทีรอคอยมานาน แต่ก็
มีขอ้ บกพร่องทัวไปอยู่
เราใช้ลกู ศรไม่ได้หรือ?
ลูกศรน่าจะเป็ นตัวเลือกทีสมบูรณ์แบบในเซสชัน EventStorming แต่น่าเสียดายทีกระดาษโน้ตสามารถเปลียนทีได้ แผ่น
รองเขียนทีอยู่กบั ทีสามารถสับเปลียนได้ แต่ลกู ศรนันถูกวาดไว้ ซึงหมายความว่าเมือคุณเขียนอะไรบางอย่างลงไป (และม้วน
กระดาษก็ดงึ ดูดให้ทาํ แบบนัน) คุณไม่สามารถลบมันได้ง่ายๆ
ดูเหมือนจะไม่ใช่เรืองใหญ่ แต่ปัญหาจะตามมาทันที: พืนผิวจะดูย่งุ เหยิงและสกปรกขึน ซึงเพิมภาระให้สมองของคุณ
ต้องแยกสัญญาณออกจากสิงรบกวน ยิงไปกว่านัน เมือมีลกู ศรวาดไว้แล้ว สมองของคุณจะพยายามสร้างแบบจําลองกระแส
งานโดยไม่ขยับกระดาษโน้ตเพือไม่ให้ลกู ศรทีมีอยู่เสียไป นีคือตัวอย่างเล็กๆ ของ "Sunken Cost Fallacy" ซึงมีพลวัตแบบ
เดียวกัน: มันจะผลักดันให้คณ
ุ ทําผิดพลาดทีมีตน้ ทุนสูงขึนเพียงเพือไม่ตอ้ งยอมรับข้อผิดพลาดในอดีต
ฉันพบว่าผูค้ นสามารถทํางานได้ดีโดยไม่ใช้ลกู ศร หากเส้นเวลาได้รบั การแสดงผลอย่างชัดเจน ในกรณีทีความใกล้ชิด
และลําดับเวลาไม่เพียงพอทีจะบ่งบอกความเชือมโยงระหว่างเหตุการณ์ (อาจเป็ นเพราะมันอยู่ห่างกันในแบบจําลอง) เรา
สามารถทําให้ชดั เจนขึนได้โดยเพิมโน้ตเล็กๆ ลงในเหตุการณ์ผลลัพธ์ หรือทําซําเหตุการณ์ตน้ กําเนิดแล้ววางสําเนาไว้ใกล้กบั
เหตุการณ์ผลลัพธ์ทีห่างไกล เพือให้อ่านง่ายขึน
เส้นเวลาเข้มงวดเกินไป
แต่ไม่ใช่ทกุ กระบวนการทางธุรกิจทีสามารถจัดให้เข้ากับลําดับที
เวลาเป็ นฐานทีสมบูรณ์แบบสําหรับการเล่าเรือง
เข้มงวดได้ง่าย โดยปกติ ในช่วงนีคําถามทีเกิดซําอาจเป็ น: “เราจะจัดการกับเหตุการณ์ทีเกิดซําได้อย่างไร?” หรือ “เราจะวาง
เหตุการณ์ทีไม่เกียวข้องโดยตรงไว้ทีไหน?”
เส้นเวลาเป็ นวิธีทยอดเยี
ี
ยมในการบังคับให้เกิดความสมบูรณ์ในระดับหนึงระหว่างเรืองเล่าทีทับซ้อนกัน แต่การปฏิบตั ิ
ตามเส้นเวลาอย่างเข้มงวดไม่ใช่เป้าหมายของเรา มันเป็ นเพียงเครืองมือทีดีทีสุดในการสร้างความสมําเสมอให้กบั การสนทนา
เท่านัน
อย่างไรก็ตาม นีคือเคล็ดลับการสร้างแบบจําลองสองสามข้อทีอาจน่าสนใจสําหรับผูท้ ีใส่ใจรายละเอียดเล็กๆ น้อยๆ
เหตุการณ์ทีถูกกระตุน้ โดยเวลา
บางเหตุการณ์เกิดขึนเพราะถึงเวลาแล้ว เช่น การปิ ดงบการเงินอาจเกิดขึนเมือสินเดือน รายงานทีมีรายละเอียดมากขึน
อาจจําเป็ นเมือสินไตรมาสหรือสินปี
เหตุการณ์ทเกิ
ี ดขึนตามเวลาทีกําหนดไว้ แม้ว่าจะเป็ นเรืองทียากต่อการจินตนาการก็ตาม
ถ้าเวลาถูกกําหนดในระดับวัน ฉันชอบใช้สญ
ั ลักษณ์รูปปฏิทินประจําวัน แท้จริงแล้วไม่จาํ เป็ นต้องเป็ นศิลปิ นเพือวาดมัน
ั ลักษณ์นสามารถสื
ี
อความหมายได้ชดั เจน
ขึนมา แต่สญ
โดยทัวไป เมือสิงต่าง ๆ เกิดขึน "ในเวลาทีเหมาะสม" มักจะมีเหตุการณ์ทีเกิดขึนตามเวลาทีกําหนดซ่อนอยู่เบืองหลัง การ
แนะนําแนวคิดนีในฐานะเหตุการณ์ทีชัดเจน อาจทําให้กระบวนการทังหมดชัดเจนยิงขึน
เหตุการณ์ทีเกิดซํา
บางเหตุการณ์อาจเกิดขึนซําได้ แม้แต่เหตุการณ์ทเกิ
ี ดตามเวลาทีกําหนดดังทีกล่าวถึงก่อนหน้านี ก็อาจเกิดขึนใน
ช่วงเวลาทีกําหนดไว้ หากการเกิดซําเป็ นรายละเอียดทีสําคัญสําหรับเหตุการณ์ในโดเมนเฉพาะ เราอาจต้องระบุเหตุการณ์ใน
โดเมนนันให้ชดั เจน
ไม่มีลาํ ดับหลัก
ไม่มีธุรกิจใดทีเป็ นเพียงแค่ลาํ ดับของสิงทีเกิดขึนอย่างเคร่งครัดเสมอ จะมีวงจรป้อนกลับ (feedback loops) และสิงที
เกิดขึนในช่วงเวลาทีไม่ได้เชือมโยงกับการไหลหลักอยู่เสมอ
แต่ไทม์ไลน์ยงั คงเป็ นเครืองมือทีดีทีสุดทีสามารถใช้เพือสร้างความสอดคล้องของมุมมองทีเป็ นอิสระ และกระตุน้ การ
สนทนาทีมีความหมาย มันช่วยทําให้เรืองราวทังหมดสอดคล้องกัน และมนุษย์กเ็ ก่งในการเข้าใจเรืองราวต่าง ๆ
ยิงฉันศึกษาเรืองนีมากขึนเท่าไหร่ ฉันยิงตระหนักว่า EventStorming เป็ นเครืองมือทีสนับสนุนการเล่าเรืองทีเกียวข้องกับ
ธุรกิจเป็ นหลัก ในฐานะนักวิเคราะห์หรือผูพ้ ฒ
ั นาซอฟต์แวร์ เราควรสนับสนุนให้ผเู้ ชียวชาญในโดเมนบอกเล่าเรืองราวให้เราฟั ง
และตรวจสอบให้แน่ใจว่าชินส่วนของแบบจําลองทีเราสร้างขึน สามารถเล่าเรืองเดียวกันได้โดยไม่มคี วามขัดแย้ง
การจัดการความขัดแย้ง
Big Picture EventStorming ไม่ใช่เวิรก์ ชอปสําหรับคนทีชอบปั ดปั ญหาไว้ใต้พรม แท้จริงแล้ว มันเหมือนกับปาร์ตีทีเชิญ
ชวนให้เรามองดูสงที
ิ ซ่อนอยูใ่ ต้พรมมากกว่า
เป้าหมายของบทนี:
• บทบาทของผูด้ าํ เนินการ
• เคล็ดลับในการแก้ไขความขัดแย้ง
• คนทีแตกต่างกันสร้างกลุ่มทีแตกต่างกัน
7 การเตรียมเวิรก์ ชอป
การเลือกห้องทีเหมาะสม
หลายครังทีฉันเห็นความตังใจทีดีทีสุดล้มเหลวเพราะการจัดเตรียมทีผิดพลาด
น่าเสียดายทีคุณไม่ตอ้ งทําอะไรมากนักเพือให้การจัดเตรียมผิดพลาด เพราะโดยปกติแล้วมันมักจะเป็ นแบบนันอยู่แล้ว
ในองค์กรของคุณ
อาคารของคุณอาจถูกออกแบบและสร้างขึนตามภาพลักษณ์ทีผิดพลาดของลักษณะการทํางานของพนักงาน แม้วา่ คุณ
จะมีสิทธิพิเศษในการออกแบบพืนทีสํานักงานให้ตรงกับความต้องการของคุณ
แต่บ่อยครังห้องประชุมก็มกั จะถูกปรับให้
เหมาะสมกับวัตถุประสงค์อืน (ซึงมักจะกลายเป็ น "จัดการประชุมทีไม่มีประสิทธิภาพ จนต้องมีการประชุมใหม่อีกครัง")
ดังทีซุนวูกล่าวไว้ว่า:
"ทุกชัยชนะถูกตัดสินไว้ก่อนทีจะต่อสู"้
ห้องประชุมของคุณคือสนามรบของคุณ มันไม่ได้ให้ความได้เปรียบแก่คณ
ุ เลย ในความเป็ นจริง การจัดห้องแบบปกติ
พฤติกรรมของผูค้ น และความเฉือย จะทําให้คณ
ุ ต้องจัดการประชุมทียาวนาน น่าเบือ ไร้ประสิทธิภาพ และเหนือยล้าอีกครัง
เหมือนทีเคยเกิดขึนมาหลายครัง คนจะนังลง เปิ ดแล็ปท็อป และเริมทําอย่างอืนในขณะทีใครบางคนกําลังเป็ นผูน้ าํ การประชุม
คราวนีคุณต้องทําอะไรทีแตกต่างออกไป
มันเป็ นหน้าทีของคุณทีจะต้องเปลียนสนามรบให้เป็ นประโยชน์ สร้างสภาพแวดล้อมพิเศษทีนิสยั ส่วนตัวและวัฒนธรรม
องค์กรจะไม่เป็ นอุปสรรค เป้าหมายของคุณคือการค้นหาปัญหาทีถูกต้องเพือแก้ไข ไม่ใช่การค้นหาปั ญหาทีถูกต้องเพือแก้ไขทัง
ทีต้องเผชิญกับข้อจํากัดของสภาพแวดล้อมทีไม่เอืออํานวย
แทนทีจะเตรียมข้อแก้ตวั ว่า “เราได้หอ้ งทีไม่เหมาะสมสําหรับเวิรก์ ชอป” ให้เราควบคุมทุกอย่างก่อนการต่อสู้ เหมือนทีแม่
ทัพผูย้ ิงใหญ่ทาํ
นีคือการดําเนินการสําคัญบางประการทีคุณควรพิจารณา ไม่ว่าคุณจะได้รบั ห้องประชุมในพืนทีของคุณเองหรือจะต้อง
เช่าห้องพิเศษ:
• จัดเตรียมพืนทีสําหรับการสร้างแบบจําลองแบบไม่จาํ กัด: โดยปกติหมายถึงการติดกระดาษม้วนจากเครือง
พล็อตเตอร์ให้ครอบคลุมผนังยาวทีสุดเท่าทีจะทําได้ อย่าลืมเตรียมแผนการขยายพืนทีไว้ดว้ ย เพราะปัญหา
อาจใหญ่กว่าทีคุณคาดการณ์ไว้
และสิงทีดูเหมือนไม่มขี ีดจํากัดในตอนแรกอาจกลายเป็ นข้อจํากัดใน
ภายหลัง
• จัดเตรียมตํานานหรือคําอธิบายทีมองเห็นได้ชดั เจน: ส่วนใหญ่ผเู้ ข้าร่วมจะยังใหม่กบั EventStorming ดังนัน
ควรมีแนวทางแนะนําไว้เสมอ คุณจะต้องมีพืนทีแยกต่างหากทีไม่กวนกับพืนทีทํางาน กระดานฟลิปชาร์ต
มักจะเหมาะสําหรับการใช้งานนี
• นําเก้าอีออก: คุณอาจต้องการเก็บเก้าอีไว้ใช้ในภายหลัง แต่ในช่วงเริมต้นของเวิรก์ ชอปไม่ควรมีเก้าอี การนัง
จะเชิญชวนให้เกิดพฤติกรรมแบบฟั งอย่างเฉยเมยและขาดการมีส่วนร่วม
อีกทังการทําให้ผคู้ นลุกขึน
หลังจากทีพวกเขานังลงไปแล้วเป็ นเรืองยาก
• ย้ายโต๊ะออกไปด้านข้าง: โต๊ะมักจะเคลือนย้ายได้ยากกว่า โดยเฉพาะโต๊ะขนาดใหญ่ในห้องประชุม อย่างไร
ก็ตาม เราจะต้องมีโต๊ะเล็ก ๆ สําหรับเขียนบนกระดาษโน้ตแบบมีกาวติดได้ โต๊ะเล็กและสูงเป็ นตัวเลือกที
เหมาะสมทีสุด
ห้องจะมีลกั ษณะอย่างไร
การทําลายนิสยั แบบองค์กร
ในองค์กรขนาดใหญ่ ผูค้ นมักคุน้ เคยกับการประชุมทีไร้ประสิทธิภาพจนเกิดการตอบสนองแบบปาวโลฟ (Pavlovian
reaction) โดยสมมติว่าการประชุมเชิงปฏิบตั ิการ (เวิรก์ ชอป) ของคุณก็จะไร้ประสิทธิภาพเช่นกัน เมือถึงเวลาเริมประชุม (พร้อม
ด้วยความแตกต่างทางวัฒนธรรมทีเป็ นเอกลักษณ์ของแต่ละที) ผูเ้ ข้าร่วมจะเริมมาถึง จับจองทีนัง เปิ ดแล็ปท็อป และรอให้การ
ประชุมเริมต้น
อย่าปล่อยให้สิงนีเกิดขึน! ในการประชุมแบบนี ผลลัพธ์ทีได้มีความสําคัญอย่างมาก คุณจําเป็ นต้องใช้ทกุ เครืองมือทีมี
อยู่ และอาวุธอันดับหนึงของคุณคือการปรับสภาพแวดล้อมให้เป็ นประโยชน์ต่อตัวคุณเอง
โดยทัวไป ทุกครังทีคุณปรับเปลียนพืนทีก่อนเริมเวิรก์ ชอปหรือการประชุม คุณจะได้รบั สิงทีเรียกว่า "ความได้เปรียบจาก
ความแปลกใจ" (surprise effect advantage): ผูเ้ ข้าร่วมหลายคนทีมาประชุมจะสังเกตเห็นว่าสิงแวดล้อมดูแปลกใหม่และ
ผิดปกติ ซึงจะกระตุน้ ความอยากรูเ้ กียวกับสิงทีจะเกิดขึนต่อไป
ความอยากรูน้ ีจะกลายเป็ นเพือนทีดีทีสุดของคุณ
จัดเตรียมพืนทีสําหรับการสร้างแบบจําลองแบบไม่จาํ กัด
ในบทก่อนหน้านี เราได้พดู ถึงผลกระทบของ "ไซโล" (silos) ทีมีต่อการกระจายความรูเ้ กียวกับผูม้ ีสว่ นได้ส่วนเสียหลัก ซึง
มักจะนําไปสู่ปัญหาทียากต่อการแสดงให้เห็นบนสือดังเดิม เช่น กระดานฟลิปชาร์ตหรือไวท์บอร์ด
EventStorming แก้ปัญหานีโดยการจัดเตรียมพืนทีสําหรับการสร้างแบบจําลองทีไม่มขี ีดจํากัด: พืนทีสร้างแบบจําลองที
ใหญ่พอทีจะไม่จาํ เป็ นต้องกําหนดขอบเขตล่วงหน้าก่อนเริมดําเนินการ
ในทางปฏิบตั ิ สิงนีมักหมายถึงการมีมว้ นกระดาษยาว ๆ เพือแปะบนผนังตรงยาว ๆ
หากต้องการพูดคุย
หลายครังทีการพูดคุยของเราถูกจํากัดด้วยขนาดของพืนทีสําหรับการสร้างแบบจําลองทีมีอยู่
เกียวกับประเด็นใหญ่ ๆ พืนทีทีใช้ได้มีความสําคัญอย่างมาก เพือแก้ไขปั ญหานี ในบริษัทของฉัน ทุกผนังสามารถเขียนได้ และ
การหาพืนทีสําหรับการสร้างแบบจําลองปั ญหาขนาดใหญ่ก็ไม่ใช่เรืองยากอีกต่อไป อย่างไรก็ตาม สภาพแวดล้อมการทํางาน
ส่วนใหญ่อาจไม่มีความสะดวกเช่นนี และการเรียกช่างทาสีมาก่อนอาจไม่ใช่วธิ ีเริมต้นทีดีทีสุด
โฟกัส 100%
ผลกระทบทีน่าสนใจจากนโยบาย "ไม่มีโต๊ะ" คือจะไม่มีพืนทีสําหรับแล็ปท็อป
ฉันต้องขอโทษด้วยสําหรับเรืองนี
...ไม่ ฉันไม่ขอโทษ ในความเป็ นจริง ฉันแค่ตอ้ งการให้แน่ใจว่าผูเ้ ข้าร่วมจะมีสว่ นร่วมในเวิรก์ ชอปอย่างเต็มที สิงนีจะ
เกิดขึนเองอยู่แล้ว เพราะ EventStorming น่าสนใจกว่าการเช็คอีเมลของบริษัท แต่ยงั มีผลกระทบด้านลบอืน ๆ จากการใช้แล็ปท็
อปในทีประชุมทีควรหลีกเลียงอย่างจริงจัง
ุ ค่าจะเกิดขึนอย่างต่อเนือง
การสนทนาทีมีคณ
แต่แล็ปท็อปทีเปิ ดอยู่กลับกลายเป็ นสิงทียึดตัวบุคคลสําคัญให้อยูใ่ น
สภาวะทีขาดการมีส่วนร่วม การสนทนาบางอย่างอาจไม่เกิดขึนเลยเพียงเพราะมีคนกําลังยุ่งกับการคุยเรืองการเบิกค่ารถแท็กซี
บางคนอาจเปิ ดแล็ปท็อปไว้เพือใช้เป็ นข้อมูลอ้างอิง โดยมีเจตนาไม่ให้ลืมสิงสําคัญ แม้วา่ ความเป็ นมืออาชีพนีน่าชืนชม
แต่ผลลัพธ์กลับไม่เป็ นไปในทางทีดี การสือสารโดยนัยจะกลายเป็ นสิงทีเหมือนกับการบอกว่า "ไม่จาํ เป็ นต้องเสียเวลาถกเถียง
เรืองนี ฉันได้สาํ รวจข้อมูลมาให้แล้ว" ซึงฉันมองว่าเป็ นคําพูดทีน่ารําคาญมาก
บางทีคณ
ุ อาจไม่จาํ เป็ นต้องใช้หอ้ งประชุม
บางครัง ปัญหาเรืองการหาห้องทีเหมาะสมสําหรับการทํา EventStorming อาจไม่จาํ เป็ นต้องแก้ไข เพราะทางเดินที
กว้างพออาจใช้ได้ดเี ช่นกัน:
• ไม่มีทีนัง โดยตังใจให้เป็ นเช่นนัน
• ผนังยาวตรง
• ไม่มีโต๊ะ
ในกรณีนี คุณอาจต้องจัดเตรียมโต๊ะเล็ก ๆ สําหรับการเขียนเพิมเติม ซึงก็เพียงพอแล้ว นอกจากนี การไม่มีหอ้ งประชุมยัง
ช่วยให้การทํางานมองเห็นได้ชดั เจนขึน และอาจดึงดูดให้คนอืนเข้าร่วมได้ง่ายขึน
อย่างไรก็ตาม อย่าลืมว่าปั จจัยอย่างแสงสว่างและอุณหภูมกิ ม็ ีความสําคัญเช่นกัน อีกทังการประชุมแบบยืนเท่านันไม่
ควรนานเกิน 60-90 นาที มิฉะนันผูเ้ ข้าร่วมอาจเกิดความเหนือยล้าได้
ให้พืนทีสําหรับการทิงข้อมูลไว้รอบ ๆ
การเลือกห้องประชุมชัวคราวสําหรับการจัดเวิรก์ ชอปอาจไม่ใช่ตวั เลือกทีดีทีสุด โดยเฉพาะอย่างยิงหากคุณต้องรีบเก็บ
ทุกอย่างเพือปล่อยห้องให้กบั การประชุมอืน
แม้วา่ เวิรก์ ชอปจะเสร็จสินอย่างเป็ นทางการแล้ว แต่ผลลัพธ์ทีมองเห็นได้ยงั คงมีคุณค่า หากสามารถปล่อยให้มนั อยูใ่ นที
เดิมได้อกี สองสามวัน เพราะไม่ใช่ทกุ การสนทนา หรือกระแสความคิดทีเกิดขึนระหว่างเวิรก์ ชอปจะสามารถจํากัดเวลาได้
ความคิดทีมองไม่เห็นบางส่วนอาจต้องการพืนทีทีปลอดภัยสําหรับการพัฒนาและตกผลึกต่อไป
นอกจากนี เวิรก์ ชอปมักจะเหมาะกับคนทีมีลกั ษณะเปิ ดเผย (extroverted) แต่ผเู้ ข้าร่วมทีมีลกั ษณะเก็บตัว (introverted)
อาจมีสงที
ิ น่าสนใจมาก ๆ ทีจะนําเสนอในบรรยากาศทีสงบกว่า ดังนันควรเตรียมพืนทีไว้เพือรองรับข้อมูลหรือความคิดเหล่านี
และอาจอยูใ่ กล้พืนทีสร้างแบบจําลอง (modeling surface) สักสองสามชัวโมงหลังเวิรก์ ชอป
ช่วงเช้าวันถัดไปมักจะมีคณ
ุ ค่าอย่างมากสําหรับการคิดทบทวน สิงทีเหมาะสมทีสุดคือการมีพืนทีพร้อมใช้งานสําหรับ
หนึงวันครึง แต่เนืองจากนีเป็ นสถานการณ์ในอุดมคติ คุณจึงต้องเตรียมพร้อมสําหรับการปรับตัวตามสถานการณ์ ฉันจะเล่า
เพิมเติมในส่วนของการสรุปงาน
จัดเตรียมกําหนดการทีมองเห็นได้ชดั เจน
ผูค้ นมักจะมีแนวโน้มเข้าร่วมกิจกรรมทีไม่มีกาํ หนดเวลาแน่นอน หากพวกเขารูส้ กึ ว่าผูอ้ าํ นวยการเวิรก์ ชอปใช้เวลาของ
พวกเขาอย่างคุม้ ค่า อย่าลืมว่า ยิงผูเ้ ข้าร่วมสําคัญมากเท่าไร สิงทีพวกเขาเลือนออกไปเพือเข้าร่วมเวิรก์ ชอปของคุณก็สาํ คัญ
มากขึนเท่านัน
กําหนดการทีมองเห็นได้ชดั เจน (visible agenda) จะเป็ นเพือนทีดีทีสุดของคุณ เพือให้ผเู้ ข้าร่วมรูส้ กึ สบายใจว่าเวิรก์ ช
อปมีแผนการทีชัดเจนและมีคนทีรูว้ ่าควรทําอะไรต่อไป
กําหนดการเริมต้นสําหรับ Big Picture EventStorming
ฉันมักจะพยายามเน้นยําถึงเป้าหมาย แม้ว่าฉันจะทราบดีว่าเป้าหมายเหล่านันอาจมีความคลุมเครือโดยธรรมชาติ แต่
เป้าหมายหลักคือการจัดเตรียมข้อมูลอ้างอิงทีเข้าถึงได้แบบอะซิงโครนัส เพือให้ไม่มใี ครติดขัด
หากมีขอ้ จํากัดด้านเวลาอย่างเข้มงวด คุณอาจต้องกําหนดแผนงานทีชัดเจนสําหรับกิจกรรมต่าง ๆ และจัดสรรเวลาให้
แต่ละกิจกรรม (timebox) อย่างไรก็ตาม อย่าลืมว่า Big Picture เป็ นกิจกรรมเชิงค้นหา (discovery activity) ดังนันความ
ประหลาดใจหรือสิงทีคาดไม่ถงึ อาจทําให้แผนทีวางไว้เปลียนแปลงได้
เมือสิงนีเกิดขึน ควรทําให้การเปลียนแปลงดังกล่าวชัดเจน และหากจําเป็ น ให้เรียกประชุมโหวตสัน ๆ เพือตัดสินใจ
ร่วมกัน
ทีนังคือยาพิษ
การจัดการคําเชิญ
มีคนสามประเภททีคุณต้องการให้เข้าร่วมในเวิรก์ ชอป Big Picture EventStorming:
• คนทีมีคาํ ถาม
• คนทีมีคาํ ตอบ
• ผูด้ าํ เนินการ (facilitator)
นีคือการผสมผสานของผูเ้ ข้าร่วมทีเหมาะสมทีสุด แต่เช่นเดียวกับในงานเลียงหรืองานแสดงดนตรี แต่ละกลุ่มจะมี "เคมี"
ของตัวเองทีต้องจัดการ ขออธิบายเพิมเติมดังนี:
คนทีมีคาํ ถาม
โดยทัวไป คําอธิบายนีควรรวมถึงทุกคนทีมีสว่ นเกียวข้องในการออกแบบและดําเนินการแก้ปัญหาทีเราจะค้นพบในเวิรก์
ชอป สําหรับโครงการทีมีความซับซ้อน อาจเกียวข้องกับคนจากหลายด้าน เช่น การจัดการองค์กร การออกแบบบริการ การ
พัฒนาซอฟต์แวร์ หรือแม้กระทังการพัฒนาผลิตภัณฑ์
ความอยากรูอ้ ยากเห็นเป็ นตัวกระตุน้ หลัก ความปรารถนาอย่างแท้จริงทีจะเรียนรูค้ ือเหตุผลทีดีทสุี ดสําหรับการเข้าร่วม
เวิรก์ ชอป ไม่วา่ คุณจะเป็ นผูบ้ ริหารระดับสูงทีต้องการเข้าใจสิงทีเกิดขึนในรายละเอียดเบืองลึก หรือคุณเป็ นพนักงานใหม่ล่าสุด
ของบริษัททีต้องการเข้าใจว่าเกิดอะไรขึนเพือช่วยหาทางแก้ปัญหา คุณจะมีเหตุผลมากมายทีดีในการเข้าร่วมเวิรก์ ชอปนี
คนทีมีคาํ ตอบ
การมีผเู้ ชียวชาญทุกคนอยู่ในทีทีเหมาะสมและในเวลาทีเหมาะสม อาจถือได้ว่าเป็ น "นิพพาน" ของการรวบรวมความ
ต้องการ (requirements gathering)
การรวบรวมคนทีอยากรูอ้ ยากเห็นเป็ นเรืองง่ายในตัวมันเอง หากพวกเขาเห็นโอกาสในการเรียนรูอ้ ย่างมหาศาล พวกเขา
ก็จะมาร่วมงานโดยธรรมชาติ เหมือนแมวทีวิงมาหาเวลาคุณเปิ ดตูเ้ ย็น แต่เมือพูดถึงผูเ้ ชียวชาญในโดเมน (domain experts)
สิงมีชวี ิตในตํานานทีเราคาดหวังให้แบ่งปันความรูข้ องพวกเขาแก่ผพู้ ฒ
ั นาซอฟต์แวร์เพือสร้างโซลูชนั ทียอดเยียม บางครังการ
พาพวกเขาเข้ามาร่วมงานอาจไม่ใช่เรืองง่าย โดยเฉพาะเมือพูดถึงการให้พวกเขามาร่วมกันทังหมดในเวลาเดียวกัน
ถึงกระนัน …ส่งคําเชิญไปยังพวกเขาอยูด่ ี หากพวกเขาใส่ใจ พวกเขาก็จะมา
คนทีมีคาํ ตอบทีขัดแย้งกัน
ดังทีได้กล่าวไว้ในบททีสามแล้วว่า จะไม่มีแหล่งข้อมูลทีเป็ นแหล่งเดียวของความรูท้ งหมด
ั
ลองสรุปอีกครัง:
จะไม่มีผเู ้ ชียวชาญในโดเมนเพียงคนเดียวทีมีความรูเ้ ชิงลึกในทุกแง่มุมของปัญหา แต่จะมีหลายคน โดยแต่ละคนมีมมุ มองที
บางส่วน อาจล้าสมัย หรือขัดแย้งกันเกียวกับปัญหาในโดเมนนัน
พืนทีความเชียวชาญจะมีการซ้อนทับกัน แต่แน่นอนว่าผูเ้ ชียวชาญจะไม่เห็นด้วยในเรืองการให้คาํ นิยามในภาพรวมทีกว้างขึน
พืนทีสีแดง ซึงเป็ นพืนทีทีความเชียวชาญซ้อนทับกันและอาจขัดแย้งกัน เป็ นสิงทีเราคาดหวังจะพบในการทํางานร่วมกัน
ผูเ้ ข้าร่วมบางคนจะมีเรืองราวทีแตกต่างกันออกไป แต่ละคนจะบอกเล่าความจริงบางส่วน และการค้นพบจะเกิดขึนจากการตัง
คําถามทีเหมาะสมกับคนทีเหมาะสม
พืนทีเหล่านีมักซ่อนโอกาสทีดีทีสุดสําหรับการปรับปรุง
มากเข้าร่วม
ดังนันอย่าลังเลทีจะเชิญคนทีมีความคิดเห็นแตกต่างกันอย่าง
การจัดการความขัดแย้ง การทําให้ประเด็นเหล่านันชัดเจน และทําให้มนั มองเห็นได้ เป็ นหนึงในผลลัพธ์สาํ คัญของ
EventStorming ดังนัน …เชิญคนคนนันมาด้วย!
คุณอาจจะเดาได้ว่าฉันพยายามหลอกคุณ
ความแตกต่างระหว่าง "คนทีมีคาํ ถาม" และ "คนทีมีคาํ ตอบ" นัน ในความเป็ นจริงแล้วมักเป็ นสิงทีปลอมและประดิษฐ์ขึน
ไม่มีใครรูท้ กุ สิง และคนทีฉลาดจะมีความอยากรูอ้ ยากเห็นและมีคาํ ถามอยูเ่ สมอ! ในเวิรก์ ชอปทีดี ทุกคนทีเข้าร่วมจะได้เรียนรู ้
อะไรมากมาย
แต่ในตอนนี เวิรก์ ชอปยังไม่เกิดขึน ผูค้ นอาจสงสัยในเรืองการลงทุนเวลาอันมีค่าของพวกเขาไปกับกิจกรรมแปลก ๆ และ
ยิงพวกเขามีอีโก้มากเท่าไร คําว่า "การเรียนรูร้ ว่ มกัน" ก็จะยิงดูไม่นา่ สนใจสําหรับพวกเขา
ดังนัน ความแตกต่างระหว่าง "คนทีมีคาํ ถาม" และ "คนทีมีคาํ ตอบ" มีไว้เพียงเพือขยายขอบเขตของคนทีควรเชิญมาเข้า
ร่วม ให้ครอบคลุมทุกคนทีสามารถมีส่วนช่วยให้เกิดประโยชน์ต่อกลุ่มโดยรวม
เรืองจริงก็คือ ณ จุดนี เราไม่มีไอเดียชัดเจนเลยว่า "ปั ญหาทีแท้จริง" จะมีลกั ษณะอย่างไร ดังนันการกําหนดข้อจํากัด
เกียวกับรูปร่างของวิธีแก้ปัญหาในช่วงแรก ๆ คงไม่มีความหมายอะไรเลย จะเป็ นซอฟต์แวร์เพิมเติมหรือไม่? หรือจะเป็ นการลบ
ซอฟต์แวร์รุน่ เก่าทีกลายมาเป็ นอุปสรรค? หรือจะเป็ นเพียงกระบวนการใหม่และข้อตกลงการทํางานทีแตกต่าง? เรายังไม่รู ้
ดังนัน แทนทีจะสร้างความแตกแยกระหว่าง "คนทีมีคาํ ถาม" และ "คนทีมีคาํ ตอบ" อาจจะดีกว่าถ้าเชิญ "คนทีใส่ใจ" เข้า
ร่วมเวิรก์ ชอป
ผูด้ าํ เนินการ (Facilitator)
มีงานเบืองหลังมากมายทีเกิดขึนระหว่างการจัดเวิรก์ ชอป EventStorming และแน่นอนว่าจะมีความคิดเห็นทีไม่ตรงกัน
ซึงอาจนําไปสู่ทางตัน
เนืองจากเราจะมุ่งเป้าไปทีปั ญหาทีถูกปัดไว้ใต้พรมมาเป็ นเวลานาน จึงควรพึงพาคนทีสามารถจัดการกับความขัดแย้ง
ได้โดยไม่มีภาระทางอารมณ์มากนัก หรือไม่มีท่าทีทีกําหนดไว้ล่วงหน้าเกียวกับประเด็นเหล่านัน
หน้าทีของผูด้ าํ เนินการจะรวมถึงการเตรียมเวิรก์ ชอป จัดหาวัสดุเครืองเขียนทีจําเป็ นทังหมด และสร้างภาพลวงตาว่าทุก
อย่างอยู่ภายใต้การควบคุม
ใช่ ฉันพูดว่า "ภาพลวงตา"
“ถ้าทุกอย่างอยู่ภายใต้การควบคุม แสดงว่าคุณยังไปได้ไม่เร็วพอ”
Mario Andretti
คนทางเทคนิคหรือคนทางธุรกิจ?
"เราควรเชิญใครเข้าร่วมดี? คนทีมีความรูท้ างเทคนิค หรือคนทีเชียวชาญด้านธุรกิจ?"
การข้ามลําดับชัน
ฉันไม่ใช่แฟนของระบบลําดับชัน โดยเฉพาะอย่างยิงหากมันกลายเป็ นอุปสรรคต่อการแก้ปัญหา EventStorming ช่วย
สร้างพืนทีส่วนกลางสําหรับคนทีมองเห็นวิธีแก้ปัญหาในระดับท้องถิน และคนทีจําเป็ นต้องมองเห็นภาพรวมทีใหญ่กว่า
ไม่จาํ เป็ นต้องสร้างความแตกต่างระหว่าง "การประชุมของชนชันสูง" และ "การประชุมของคนธรรมดา" อย่างไรก็ตาม ใน
หลายองค์กร ช่องว่างระหว่างลําดับชันนันมีอยูจ่ ริง และมันจะไม่หายไปง่าย ๆ
เรืองทีน่าขันคือ องค์กรทีการจัดการประชุมข้ามแผนกหรือข้ามลําดับชันเป็ นเรืองยุง่ ยาก กลับเป็ นองค์กรทีสามารถได้รบั
ประโยชน์สงู สุดจากการประชุมลักษณะนี แต่แน่นอนว่าพวกเขาจะไม่รูเ้ รืองนีล่วงหน้า
การเตรียมกําหนดการ (Agenda)
มันยากทีจะโน้มน้าวให้คนเข้าร่วมการประชุมทีดูเหมือนไม่มกี ารควบคุม ดังนันควรเตรียมสิงทีดูเหมือนกําหนดการไว้
และจัดโครงสร้างการประชุมแบบกําหนดกรอบเวลา (time-boxed) สําหรับแต่ละช่วง อย่างไรก็ตาม ในทางปฏิบตั ิ ผูด้ าํ เนินการ
(facilitator) จะต้องจุดประกายการสํารวจทีค่อนข้างยุง่ เหยิงในลักษณะทีคุมให้หลวมทีสุด
การสนทนาจะเกิดขึนอย่างคึกคัก บางการสนทนาจะน่าสนใจอย่างเหลือเชือ อาจเป็ นเรืองทีทังองค์กรรอคอยมานาน
หลายปี ผูด้ าํ เนินการเพียงแค่สงั เกตและจดบันทึกไว้เท่านัน ขณะทีการสนทนาอืนอาจเป็ นพิษ เช่น การทําซําพิธีกรรมทีน่าเบือ
และทําให้คนเบือนหน้าหนี ในกรณีนี ผูด้ าํ เนินการจะต้องหาวิธีหยุดหรือปรับกรอบการสนทนาใหม่ เพือรักษาคุณค่าของเวิรก์ ช
อปให้อยู่ในระดับทีเหมาะสม
การเชิญชวนจะไม่สมบูรณ์แบบ
กระบวนการเชิญชวนไม่มีความสมบูรณ์แบบ หรือบางทีฉันอาจจะยังหาไม่เจอก็ได้
• ยิงเราชวนคนเข้าร่วมมากเท่าไร ก็ยิงยากทีจะหาช่วงเวลาทีเหมาะสมให้คนสําคัญทังหมดมารวมตัวกันใน
เวลาและสถานทีเดียวกัน
• ยิงเรารอนานเท่าไร สถานการณ์ทีเป็ นอยู่ก็จะยิงเสือมโทรมลง
• ผูค้ นมักจะตังข้อสงสัยกับสิงใหม่ ๆ ทีดูแปลกไปโดยธรรมชาติ พวกเขาอาจพอใจกับผลลัพธ์ในภายหลัง แต่
การเชิญชวนจําเป็ นต้องทําก่อนการเวิรก์ ชอป
สถานการณ์ทดีี ทีสุดทีฉันเคยเจอคือกรณีทีองค์กรมี "ความรูส้ กึ ร่วมถึงเป้าหมาย" อยู่แล้ว ทังองค์กรตระหนักว่ามีความ
จําเป็ นต้องทําอะไรบางอย่าง เพียงแต่พวกเขาสับสนว่าจะทําอย่างไรดี
และนันคือเป้าหมายของเวิรก์ ชอป
ความวุ่นวายในกระบวนการเชิญชวนกําลังบอกอะไรคุณบางอย่าง
หากองค์กรของคุณซับซ้อนถึงขนาดทีการรวบรวมตัวแทนสําคัญจาก "ไซโล" อิสระต่าง ๆ เป็ นเรืองทียากลําบาก …นีเป็ น
ตัวชีวัดทีชัดเจนว่าโครงสร้างองค์กรของคุณกําลังจํากัดการเรียนรูม้ ากเพียงใด
นีเป็ นการแลกเปลียน (trade-off) ทีคุณสามารถยอมรับได้หรือไม่? คําตอบนันขึนอยูก่ บั คุณ
การจัดการความคาดหวัง
8 ผลลัพธ์หลังเวิรก์ ชอป
โดเมนทีทํางานร่วมกัน
โครงสร้างโดเมนย่อยทีกําลังเกิดขึนจากสายงานฝึ กอบรมสาธารณะของบริษัทของฉัน
เมือไหร่ควรหยุด?
ฉันอยากจะกล่าวอะไรบางอย่างเช่น: “คุณสามารถหยุดได้เมือคุณมีความเข้าใจในระดับทีน่าพึงพอใจเกียวกับโดเมน
พืนฐาน” หรือ “การเวิรก์ ชอปสินสุดลงเมือทุกกระบวนการถูกจําลองเสร็จสมบูรณ์บนผนัง” แต่น่าเสียดายทีไม่ใช่กรณีน:ี
ข้อจํากัดหลักสําหรับการเวิรก์ ชอปภาพรวมใหญ่คือความพร้อมของบุคคลสําคัญ ดังนัน เว้นเสียแต่วา่ คุณจะจัดหาอาหารและ
เครืองดืมคุณภาพสูงมาก ๆ เวลาทีคาดไว้จะอยู่ทประมาณสองชั
ี
วโมง
นีเปลียนเป้าหมายของเราใหม่: เราควรเพิมคุณค่าของผลลัพธ์ให้มากทีสุด โดยคํานึงว่าเราไม่สามารถทําทุกอย่างให้
เสร็จสมบูรณ์ได้ ความกังวลหลักของเราคือการทําให้มนใจว่
ั าเราได้สาํ รวจสิงสําคัญทีมีความสําคัญอย่างลึกซึง [FIXME:
รูปภาพทีชีแจงตรงนีจะดีมาก] ในขณะทียังคงรักษาโฟกัสในภาพรวมไว้ได้
ง่ายทีจะพูดแต่ยากทีจะทํา เราจะเจาะลึกประเด็นนีเพิมเติมใน
เราจะรูไ้ ด้อย่างไรว่าทํางานได้ดี?
ขอให้ฉนั พูดให้ชดั เจน แบบจําลองทีเรากําลังสร้างบนกระดาษม้วนไม่ใช่เป้าหมาย
แบบจําลองนันโดยพืนฐานแล้วมีสองสิง:
• เป็ นข้ออ้างในการกระตุน้ ให้เกิดการสนทนาทีถูกต้องกับคนทีเหมาะสม,
• เป็ นเครืองมือในการปรับปรุงคุณภาพของการสนทนาทีกําลังเกิดขึน
ความรูส้ กึ
หาก EventStorming ดําเนินไปได้ดี คุณจะไม่ตอ้ งการรายการตรวจสอบใด ๆ เซสชันทียอดเยียมจะจบลงด้วยความรูส้ กึ
เหนือยล้าแต่มีความสุข และความรูส้ กึ ทีว่าประสบความสําเร็จแล้ว
คุณอาจจับตัวเองอยู่ในโหมดครุน่ คิด มองไปทีผนังทีเต็มไปด้วยโน้ตสติกเกอร์สีสนั สดใส และความรูส้ กึ ว่า “ไม่มอี ะไรให้
เพิมอีกแล้ว” ฉันชอบเรียกช่วงเวลานีว่า:
“ความยุง่ เหยิงนีคือพวกเรา!”
โอ้ พระเจ้า มันแย่มาก!
หากความรูส้ กึ แตกต่างออกไป ก็ไม่ได้หมายความว่าเวิรก์ ชอปนันล้มเหลวเสมอไป การนัดบอดก็ไม่จาํ เป็ นต้องเป็ น
จุดเริมต้นของเรืองราวความรักเสมอไป
ในความเป็ นจริง EventStorming ทีมีประสิทธิภาพมากทีสุดบางครังก็ไม่ได้ส่งมอบสิงทีคาดหวังไว้อย่างแน่นอน
ในบริษัท X การกระตุน้ ให้เกิดการสนทนาเป็ นเรืองยากมาก เจ้าของบริษัททําตัวเป็ นผูเ้ ชียวชาญระดับสูง (über-Domain
Expert) และผูใ้ ต้บงั คับบัญชาไม่กล้าทีจะโต้แย้งเขา เวิรก์ ชอปกลายเป็ นบทสนทนาทีไม่สมดุล โดยมีผฟู้ ั งทีเงียบสนิท
ควรจะมองว่านีเป็ นความล้มเหลวหรือไม่? จริง ๆ แล้วฉันค่อนข้างพอใจ: ใช้เวลาน้อยกว่าสองชัวโมงในการรวบรวม
ข้อมูลทังหมดทีจําเป็ นเพือยุติโครงการทีมีแนวโน้มจะล้มเหลว ด้วยปั ญหาส่วนตัวมากมายทีเกียวข้อง ความเป็ นไปได้ททีี ม
พัฒนาจะสร้างซอฟต์แวร์ทดีี ในสภาพแวดล้อมทีไม่เป็ นมิตรนันแทบไม่มีเลย
ในบริษัท Y ผูม้ ีส่วนได้ส่วนเสียหลักคนหนึงตีความเวิรก์ ชอปในแบบของเขาเอง ขณะทีทุกคนเริมวางอีเวนต์ของโดเมนลง
ในโฟลว์ เขากลับใส่สิงของของเขาลงในส่วนทีแยกต่างหากของพืนผิวการจําลอง ความไม่เชือมโยงนันเห็นได้ชดั เราสามารถ
รวมโมเดลทังสองเข้าด้วยกันได้ แต่ความรูส้ กึ ทีออกมานันก็ยงั ค่อนข้างแปลก
ในกรณีนี ปั ญหาชัดเจนก่อนจะถึงแบบจําลอง ภาษากายและปฏิสมั พันธ์ทีมองเห็นได้แสดงให้เห็นถึงช่องว่างระหว่างผูม้ ี
ส่วนได้ส่วนเสียหลัก
คุณคิดว่าจะสามารถแก้ปัญหานีได้ดว้ ยการเขียนซอฟต์แวร์ทีดีหรือ?
ขอให้โชคดี
ถึงแม้ผลลัพธ์ของเวิรก์ ชอปจะออกมาดูไม่ราบรืนนัก แต่เราก็มไี อเดียทีชัดเจนว่าควรทําอะไรต่อไป ซึงก็คือการแก้ไข
ปั ญหาส่วนตัวและการเมือง การเริมต้นแก้ปัญหาด้วยการแสร้งทําเป็ นว่าทุกอย่างจะเรียบร้อยนันไม่ใช่ทางเลือก
การตรวจสอบด้วยภาพ
นีคือลิสต์เล็ก ๆ ของสิงทีฉันตรวจสอบด้วยสายตา เพือให้แน่ใจว่าเราได้สาํ รวจอย่างลึกซึพอแล้ว:
1. เรามีจดุ ทีน่าสนใจ (hot spots) หรือไม่? เราได้มีการพูดคุยอย่างดีเกียวกับปั ญหาทีดูเหมือนจะน่าสนใจทีสุดที
จะต้องแก้ไขหรือไม่? เราได้ทาํ เครืองหมายมันไว้ดว้ ยโน้ตสติกเกอร์สีม่วงหรือเปล่า? การไม่มคี วามขัดแย้งหรือ
ปั ญหาไม่ได้หมายความว่าทุกอย่างราบรืน แต่มนั อาจหมายถึงว่ามีคนสําคัญขาดหายไป หรืออาจจะมีใครบาง
คนโกหก
2. มี Domain Events เกิดขึนกีเหตุการณ์ระหว่างการพูดคุย? สําหรับการเวิรก์ ชอปสองชัวโมง จํานวน 100 ถึง
200 เหตุการณ์น่าจะเป็ นตัวเลขทีสมเหตุสมผล ถ้าน้อยกว่าหนึงร้อย อาจบ่งบอกว่าเราเพียงแค่ขีดเขียนอยู่บน
ผิวของปัญหาเท่านัน กรณีพเิ ศษอาจเกิดขึนหากคุณกําลังทํางานกับสตาร์ทอัพ
3. คุณได้รวบรวมระบบภายนอกทังหมดหรือยัง? ระบบภายนอกมักเป็ นแหล่งของความแปรปรวนและปั ญหา
หากมันไม่ได้ถกู แสดงไว้บนพืนผิวการจําลอง แสดงว่าคุณยังไม่ได้สาํ รวจในมุมกว้างเพียงพอ
4. คุณได้ตรวจสอบอย่างชัดเจนหรือยังว่า “อะไรทีขาดหายไปจากภาพนี?” หากไม่มกี ารนําเสนอคําถามนีอย่าง
ชัดเจน ผูค้ นอาจข้ามรายละเอียดทีสําคัญบางอย่างไป เพียงเพราะมันดูเหมือนไม่เกียวข้อง
สรุปเวิรก์ ชอปภาพรวมใหญ่
แม้วา่ ดูเหมือนว่าปาร์ตีจะจบลงแล้ว ผูค้ นเริมทยอยออกไป และคุณกับเพือนร่วมงานอีกสองสามคนกําลังทําความ
สะอาดห้องทีเต็มไปด้วยปากกาและอุปกรณ์ต่าง ๆ
จองห้องให้นานขึน
ในบางบริษัท การจองห้องประชุมอาจเป็ นงานทียุง่ ยากมาก หากคุณอยู่ในบริษัทลักษณะนี และการเลิกใช้หอ้ งไม่ใช่
ทางเลือก ให้แน่ใจว่าคุณได้จองเวลาสําหรับการทําความสะอาดไว้เพียงพอ ไม่มีอะไรน่าหดหู่ไปกว่าการทีอีกกลุ่มหนึง
มาเคาะประตูแล้วบอกว่า “เราจองห้องนีไว้” ขณะทีคุณกําลังอยูใ่ นช่วงพูดคุยสําคัญหรือกําลังครุน่ คิดอย่างลึกซึง
คุณจะต้องการเวลาสําหรับการเก็บงานทางกายภาพ การพักใจ และการวิเคราะห์แนวคิด และคุณจําเป็ นต้องทําสิง
เหล่านีในห้องนัน การจัด EventStorming ทีดีมกั จะกระตุน้ ให้เกิดการสนทนาและแนวคิดใหม่ ๆ มากมาย ซึงไม่ใช่ทกุ
เรืองทีมีขอ้ สรุปทีเหมาะสมในระหว่างเวิรก์ ชอป ภาษากายทีปรากฏก็ไม่สามารถจดบันทึกได้ในระหว่างเวิรก์ ชอป แต่การ
ตรวจสอบสัญญาณเหล่านันกับเพือนร่วมงานในตอนท้ายมีความสําคัญมาก
เพือป้องกันการพลาดหรือการตีความ
ข้อมูลโดยนัยผิด
เราควรทําอย่างไรกับอาร์ติแฟกต์การจําลอง?
เก็บไว้สกั สองสามวัน
หากคุณมีโอกาสทีจะเก็บอาร์ติแฟกต์ไว้อยูใ่ กล้ ๆ เพียงทํามัน มีเหตุผลทีดีหลายประการในการทิงสิงทีใหญ่โตนีไว้สกั สอง
สามวัน:
• มันเป็ นแหล่งอ้างอิงทีมองเห็นได้สาํ หรับคนทีไม่ได้เข้าร่วมเวิรก์ ชอป ไม่ว่าจะเป็ นผูท้ ีไม่ได้รบั เชิญ หรือผูท้ ี
ปฏิเสธคําเชิญเพราะคิดว่ามันเป็ นแค่การประชุมธรรมดาอีกครัง
• มันช่วยยึดโยงภาพในใจสําหรับผูท้ ีเข้าร่วมเวิรก์ ชอป
เนืองจากปริมาณข้อมูลทีได้รบั การประมวลผลใน
เวิรก์ ชอปขนาดใหญ่ มีโอกาสสูงทีความคิดเพิมเติมจะเกิดขึนหลังจากกลับไปทํางานต่อในทีอืน การมี
แบบจําลองวางอยูใ่ นเช้าวันถัดไปจะช่วยให้จบั ประเด็นเหล่านันได้ และในทีสุดก็สามารถนํามาพูดคุยกันต่อ
ได้
• มันอาจกระตุน้ การคิดวิเคราะห์ใหม่ ๆ หรือจุดประกายการสนทนาเพิมเติม แบบจําลองนีถูกออกแบบมาให้
อ่านและเข้าใจได้งา่ ย หากมีคนเพิมเติมทีต้องการเข้าร่วมการสนทนา นันมักจะเป็ นสิงทีดี
เก็บรักษาไว้
จัดการด้านจิตวิทยา
เริมจากแบบจําลองภาพรวมใหญ่ ซึงครอบคลุมทังกระบวนการทางธุรกิจโดยไม่ลงลึกถึงอาร์ติแฟกต์เชิงออกแบบ
การจัดการอาร์ตแิ ฟกต์ภาพรวมใหญ่
ผลลัพธ์ทแท้
ี จริงของเซสชัน EventStorming คือการเรียนรูร้ ว่ มกัน แม้ว่าการสร้างภาพรวมใหญ่นนจะรู
ั ส้ กึ เหน็ดเหนือย
แต่ผลลัพธ์ทีแท้จริงก็คือคุณได้อยูต่ รงนัน มีการพูดคุย และสร้างแบบจําลองขึนมา อย่าหลงรักมันมากเกินไป: แบบจําลองนัน
ยังคงมีขอ้ ผิดพลาด สภาพแวดล้อมของเวิรก์ ชอปทําให้ผเู้ ข้าร่วมสามารถมองเห็นข้อผิดพลาดในแบบจําลองได้ง่าย โดยอาศัย
ปั ญญาร่วมของกลุ่ม แต่บางข้อขัดแย้งอาจจะตรวจพบได้กต็ ่อเมือมีการเขียนโค้ดและทดสอบแบบจําลองในโลกจริงกับผูใ้ ช้งาน
จริง
มุ่งเน้นไปทีจุดทีน่าสนใจ (Hot Spot)
บางครัง การสํารวจแบบจําลองจะดึงความสนใจไปยังจุดทีน่าสนใจบางจุด (Hot Spots) ปั ญหาทียืดเยือมักกลายเป็ น
หัวข้อของการสนทนาทีมีสีสนั หากมีฉันทามติในจุดทีน่าสนใจ (เช่น ตําแหน่งของปั ญหา การหาวิธีแก้ปัญหาทีเหมาะสมเป็ น
เรืองทีแตกต่างโดยสินเชิง) ก็ไม่ควรมีขอ้ แก้ตวั ใด ๆ ให้เริมสํารวจปัญหานันเพิมเติมและทํางานแก้ไขทันที สิงทีแย่ทีสุดทีใครบาง
คนอาจทําคือการพบปั ญหา สร้างฉันทามติในปั ญหานัน และจากนันปล่อยให้โมเมนตัมหายไปโดยไปทําอย่างอืนแทน วิธีการนี
มาจาก ทฤษฎีขอ้ จํากัด (Theory of Constraints): เมือคุณพบคอขวดในระบบของคุณ นันคือพืนทีทีการปรับปรุงเล็กน้อยทุก
อย่างมีความสําคัญ
โดยปกติ ฉันมักจะเก็บแบบจําลองไว้ระยะหนึง (ประมาณหนึงสัปดาห์) เพือเปิ ดโอกาสให้เกิดการคิดเพิมเติมและ
ปรับปรุงแบบจําลอง อย่างไรก็ตาม เมือมุมมองภาพรวมถูกบันทึกไว้แล้ว มูลค่าของแบบจําลองทีมองเห็นได้จะลดลง และอาจมี
การใช้ประโยชน์ทีดีกว่าสําหรับพืนทีว่างบนพืนผิวการแสดงผล โดยส่วนใหญ่ เรามักจะถ่ายรูปและม้วนกระดาษเก็บไว้ การทํา
ู เสียผลงาน แต่ความจริงคือเรามักไม่ค่อยกลับไปดูแบบจําลองนันอีก
เช่นนีทําให้เรารูส้ ึกปลอดภัยขึน เพราะเราไม่ได้สญ
อย่างไรก็ตาม คุณต้องพิจารณาว่าฉันพัฒนาความสามารถในการแยกตัวจากอาร์ติแฟกต์ทางกายภาพนีหลังจากทํางาน
ในหลายเซสชัน ผูเ้ ข้าร่วมเวิรก์ ชอปของคุณยังไม่ถงึ ระดับนัน ดังนันอย่าบังคับให้พวกเขาแยกตัวจากแบบจําลองโดยการกําจัด
มันออกไป พวกเขาต้องใช้เวลาในการตระหนักว่าจริง ๆ แล้วพวกเขาไม่ได้ตอ้ งการมันอีกต่อไป
ดังนัน ให้ถ่ายภาพไว้สาํ หรับการใช้งานในรูปแบบดิจิทลั (ถ่ายภาพพาโนรามาสําหรับโฟลว์ทังหมด และภาพบางส่วน
สําหรับการอ่านรายละเอียดทีชัดเจนยิงขึน) ม้วนกระดาษอีกครังพร้อมกับโน้ตสติกเกอร์ทงหมด
ั
และเก็บกระดาษม้วนในที
ปลอดภัย เผือว่าจะต้องใช้งานในอนาคต
จุดทีน่าสนใจหลายจุด (Multiple Hot Spots)
หากมีจดุ ทีน่าสนใจหลายจุดถูกระบุในแบบจําลอง การเก็บกระดาษม้วนไว้สกั ระยะอาจเป็ นความคิดทีดี ในลักษณะของ
“เอาล่ะ จะทําอะไรต่อดี?” เมือจุดทีน่าสนใจเหล่านันถูกแก้ไขหรือถูกแทนทีด้วยการปรับปรุงกระบวนการใหม่ ทีมงานอาจมอง
หาคอขวดถัดไปในลําดับต่อไป หรือปัญหาใหม่ทีเพิงปรากฏขึน กระดาษม้วนกลายเป็ นแหล่งทีดีสาํ หรับการสนทนาเป็ นระยะ ๆ
เกียวกับผลลัพธ์ทีได้ในระหว่างการพยายามปรับปรุงประสิทธิภาพขององค์กร
แน่นอนว่า กระดาษม้วนเพียงอย่างเดียวไม่เพียงพอ การแสดงผลด้วยภาพและสีสนั นันมีประโยชน์ แต่ขอ้ มูลทีวัดผลได้
จริงย่อมได้รบั การต้อนรับเป็ นพิเศษ
การจัดลําดับความสําคัญของจุดทีน่าสนใจ (Hot Spots)
ไม่มจี ดุ ทีน่าสนใจ (No Hot Spots)
การมีปัญหาไม่ได้เป็ นสิงจําเป็ นเสมอไป หากไม่มีจดุ ปวดร้าว (pain points) ใด ๆ ถูกระบุบนกระดาษม้วน สิงทีควรทําคือ
จับความรูเ้ กียวกับโครงสร้างของกระบวนการ แทนทีจะเน้นไปทีการกําจัดอุปสรรคทีมองเห็นได้ เป้าหมายหลักจะเปลียนไปเป็ น
การจับโอกาส เช่น การเพิมคุณสมบัติใหม่ ๆ หรือการเพิมความหลากหลายให้กบั กระบวนการทีมีอยู่
การบันทึกผลลัพธ์ - ยุ่งยาก (TRICKY)
โครงสร้างทีเกิดขึน (Emerging Structure)
เรากําลังมองหาอะไร?
เราจะรูไ้ ด้อย่างไรว่ากําลังมุ่งหน้าไปในทิศทางทีถูกต้อง? เราจะได้เห็นในหัวข้อ “เมือไหร่ควรหยุด?” ภายหลังว่าเวิรก์ ชอป
ของเรามักจะถูกจํากัดด้วยปัจจัยภายนอก เช่น ความพร้อมของผูค้ นและห้องประชุม ดังนันเราจะไม่มีสิทธิตัดสินใจว่าเวิรก์ ชอป
ควรสินสุดเมือใด
อย่างไรก็ตาม เราจําเป็ นต้องมีวิธีเข้าใจว่าการค้นพบของเรากําลังไปในทิศทางทีถูกต้องหรือไม่ การอบเค้กอาจง่ายขึนถ้า
คุณมีภาพในใจทีชัดเจนว่าผลลัพธ์สดุ ท้ายจะหน้าตาเป็ นอย่างไร
หลายแบบจําลอง (Multiple Models)
• แบบจําลองควรมีความสอดคล้องภายในในแง่ของภาษา
หากคุณมีพืนฐานด้านการพัฒนาซอฟต์แวร์ คุณอาจจะรูจ้ กั แนวคิดทีคุน้ เคยจาก Domain-Driven Design อยู่สองอย่าง:
• Ubiquitous Language (ภาษาเฉพาะทีทุกคนเข้าใจตรงกัน)
• Bounded Contexts (บริบททีมีขอบเขตชัดเจน)
อย่างไรก็ตาม จิตวิญญาณของเวิรก์ ชอปไม่ได้มีเป้าหมายเพือแนะนําแนวคิดใหม่ ๆ ให้กบั ผูเ้ ชียวชาญในโดเมน ดังนัน ได้
โปรดต่อต้านความต้องการทีจะอธิบายเรือง Domain-Driven Design ให้หวั หน้าของคุณฟั ง และเพียงใช้มนั ให้เป็ นประโยชน์
สําหรับตัวคุณเอง
ขันตําสุดทีจําเป็ นสรุปได้ใน 2 แนวคิดนี:
• ภาษาเปิ ดเผยข้อมูล (Language is revealing): ให้ตืนตัวสําหรับความแตกต่างและคําพ้องความหมาย
เพราะสิงต่าง ๆ มักไม่เหมือนกันทังหมดเสียทีเดียว
• ทังระบบจะไม่สอดคล้องกันทังหมด (The whole thing won’t be consistent): จะมีเพียงบางส่วนเล็ก ๆ
เท่านันทีมีความสอดคล้องกัน ดังนันหยุดพยายามทีจะเปลียนมันทังหมด
9 ความหลากหลายในภาพรวม
การค้นพบโครงการซอฟต์แวร์
รูปแบบความหลากหลายในภาพรวมสามารถนํามาใช้เมือสํารวจภูมิทศั น์สาํ หรับโครงการซอฟต์แวร์ใหม่ได้ โดยนีเป็ น
สถานการณ์ทวไปสํ
ั าหรับบริษัทซอฟต์แวร์หรือบริษัททีปรึกษาทีได้รบั การว่าจ้างเพือพัฒนาซอฟต์แวร์เฉพาะสําหรับองค์กรอืน
ในสถานการณ์นี สภาพแวดล้อมจะไม่สามารถสมบูรณ์แบบได้: บริษัทซอฟต์แวร์อาจพยายามเชิญบุคคลสําคัญทังหมด
ในองค์กรลูกค้า เพือเรียนรูใ้ ห้ได้มากทีสุดจากเวิรก์ ชอป แต่บคุ คลสําคัญเหล่านันอาจไม่ได้มีความพร้อมหรือมีเวลามากนัก
เนืองจากคุณค่าทีแท้จริงของเวิรก์ ชอปจะมองเห็นได้ก็ต่อเมือมองย้อนกลับไปในภายหลัง อีกทังยังมีปัญหาทางการเมืองและ
การแย่งชิงอํานาจเข้ามาเกียวข้องด้วย แต่ปัญหาทีท้าทายทีสุดคือระดับความพร้อมขององค์กรลูกค้า: หากพวกเขาคุน้ เคยกับ
การพัฒนาโครงการซอฟต์แวร์แบบลําดับขัน (waterfall approach) หรือการกําหนดงบประมาณและขอบเขตงานทีเข้มงวดแล้ว
การโน้มน้าวให้พวกเขาเห็นความสําคัญของเวิรก์ ชอปแทนทีจะใช้เอกสารกําหนดคุณสมบัติโครงการแบบเดิมอาจเป็ นเรืองยาก
บางครัง วิธีทีดีทีสุดคือไม่ตอ้ งพูดถึง EventStorming เลย แต่เพียงแค่พกโพสต์อิทและกระดาษม้วนไปด้วย และ
ดําเนินการเวิรก์ ชอปขนาดเล็กเพียงเพราะว่า “พวกเราเคยชินกับการมองสิงต่างๆ ในลักษณะนี” วิธีนีสามารถช่วยหลีกเลียง
ความพยายามในการโน้มน้าวให้คนทําสิงทีพวกเขาไม่เคยรูจ้ กั และอาจทําให้พวกเขารูส้ กึ แปลกใจและสนใจ
หรืออีกทางเลือกหนึง คุณอาจต้องการเรียกเวิรก์ ชอปอย่างชัดเจนให้เป็ นเงือนไขเบืองต้นในการรับโครงการ เพราะมัน
เป็ นความพยายามลดความเสียงครังใหญ่สาํ หรับทังสองฝ่ าย แต่การรับรูเ้ กียวกับเวิรก์ ชอปนันอาจแตกต่างกันไปมาก ขึนอยูก่ บั
สถานะทางการตลาดของทังสองฝ่ ายทีเกียวข้อง
และเพือให้ได้ประโยชน์สงู สุดจากสิงทีสามารถทําได้ พร้อมกับการปูพืนฐานสําหรับการจัดเวิรก์ ชอปทีสมบูรณ์แบบใน
ครังถัดไป เมือเวิรก์ ชอปถูกรวมอยู่ในรอบการเจรจาก่อนการขาย มันมักจะเผชิญกับปัญหาทังหมดทีเกียวข้องกับการเจรจาใน
สถานการณ์ทซัี บซ้อน
ปั ญหาหลักหรือแค่สนับสนุน?
เพือสร้างผลกระทบสูงสุด บริษัทซอฟต์แวร์อาจตังคําถามกับองค์กรลูกค้าเพือทําความเข้าใจปัญหาทีพวกเขาเผชิญหน้า
และขอบเขตโดยรวมได้ดยี ิงขึน
ตามทีได้กล่าวไว้ ไม่ใช่ว่าทุกปัญหาจะมีลกั ษณะเหมือนกัน: บางปั ญหาอาจเปลียนเกมได้ [FIXME: ตรวจสอบให้แน่ใจว่า
มีการอธิบายแนวคิดนีก่อนหน้านี] ในขณะทีบางปัญหาเป็ นเพียงประตูหรือเครืองมือสนับสนุนเท่านัน ความสนใจสูงสุดของ
บริษัทซอฟต์แวร์อาจเป็ นการมองหาความเหมาะสมทีสุดตามความสามารถของพวกเขา:
โครงการบางโครงการต้องการ
บุคลากรพิเศษ (เช่น บุคคลทีมีความคิดสํารวจหรือบุกเบิก) และสามารถสร้างรายได้เพิมขึน ในขณะทีโครงการอืนๆ จะเป็ นเพียง
ประตูบงั คับเพือให้ยงั คงอยูใ่ นตลาดนันได้ แต่โครงการเหล่านันจะขับเคลือนด้วยงบประมาณเป็ นหลัก
เป้าหมายทีขัดแย้งกันโดยไม่ได้พดู ออกมา
หลายครัง ขอบเขตของโครงการทีต้องสํารวจเป็ นเพียงส่วนหนึงของภาพรวมทีใหญ่กว่า:
มุมมองย้อนหลังขององค์กร
การปฐมนิเทศสําหรับพนักงานใหม่
บางบริษัทเริมใช้ EventStorming เป็ นวิธีการนําพนักงานใหม่เข้าสู่กระบวนการได้อย่างรวดเร็ว ฉันเองก็ทาํ เช่นเดียวกัน
ในบริษัทของฉัน และมันได้ผลดีอย่างน่าทึง
อย่างไรก็ตาม มีความแตกต่างทีสําคัญบางประการจากรูปแบบมาตรฐานทีควรกล่าวถึง
1. ไม่สามารถเชิญทีมทังหมดได้อีกครัง
หากบริษัทกําลังอยูใ่ นช่วงเร่งจ้างพนักงานใหม่เข้ามาทุก
สัปดาห์ การจัดเวิรก์ ชอปภาพรวม (Big Picture) ซําอาจเป็ นไปไม่ได้ แต่ข่าวดีก็คือ “หากคุณเคยจัด
เวิรก์ ชอปภาพรวมไปแล้ว ผูเ้ ข้าร่วมทุกคนจะมีความเข้าใจในภาพรวมมากขึน” ดังนัน การให้
ผูเ้ ข้าร่วมทีเหลืออยูเ่ ป็ นผูเ้ ชียวชาญตัวแทนในเวิรก์ ชอปขนาดเล็กจึงไม่ใช่ความเสียงมากนัก
2. ยังคงมีเหตุผลทีควรค้นพบสิงทังหมดใหม่อีกครัง การแค่แสดงผลลัพธ์จากเซสชันก่อนหน้าอาจไม่ได้
ผลดีนกั : สําหรับผูท้ ีเคยเข้าร่วมเวิรก์ ชอปมาก่อน มันอาจเป็ นเพียงบทสรุปและการเตือนความจําทีดี
เกียวกับการสนทนาทีเกิดขึนในเวิรก์ ชอป แต่สาํ หรับผูท้ ีเข้ามาใหม่และไม่ได้เข้าร่วมครังก่อน พวกเขา
จะไม่มีความทรงจําใดๆ ให้ยึดโยงกับเนือหา
คําแนะนําในทีนีคือให้จดั เวิรก์ ชอปใหม่ โดยมอบบทบาทผูน้ าํ ให้กบั ผูท้ ีเข้ามาใหม่ เริมต้นการสร้างโมเดลระบบโดยอิง
จากการคาดเดาและสมมติฐานของพวกเขา และค่อยๆ ปรับแก้ไปเรือยๆ วิธีทเราทํ
ี าคือการถามว่า “ลองเริมสร้างโมเดลสิงทีคุณ
คิดว่ากําลังเกิดขึนในองค์กรนี!” และดูว่ามันนําไปสู่จดุ ไหน ไม่ควรมีความคาดหวังว่าคําตอบจะถูกต้อง - เพราะคนใหม่ยงั ไม่มี
ประสบการณ์เพียงพอ - แต่การทีสมมติฐานทีผิดพลาดของพวกเขาปรากฏให้เห็นเป็ นจุดเริมต้นทีดี สมาชิกอาวุโสในทีมจะต้อง
อธิบายเหตุผลทีอยู่เบืองหลังการแก้ไข และทุกคนควรพัฒนารูปแบบ (โมเดล) ร่วมกันตามความเหมาะสม
ทําไมมันถึงได้ผล?
ฉันใช้เวลาสักพักเพือทําให้มนั ใช้งานได้ และฉันใช้เวลานานมากกว่าจะเข้าใจว่าทําไมมันถึงได้ผล
10 แท้จริงแล้วการพัฒนาซอฟต์แวร์คืออะไร
มีคนไม่กีคนทีทําให้วิชาชีพการพัฒนาซอฟต์แวร์เสียหายได้มากเท่ากับคนทีสนับสนุนความคิดทีว่า
“การพัฒนาซอฟต์แวร์กเ็ หมือนกับการสร้างบ้าน”
การพัฒนาซอฟต์แวร์คอื การเขียนโค้ด
นีคือการพูดถึงสิงทีชัดเจนอยู่แล้ว: ทุกคนรูว้ ่าการพัฒนาซอฟต์แวร์คือการเขียนโค้ด
นีคือเหตุผลทีเราใช้เฟรมเวิรก์ ต่างๆ เพือลดการเขียนโค้ดและเร่งกระบวนการพัฒนาซอฟต์แวร์ ทําให้เราส่งมอบงานใน
เวลาวันทีเคยใช้เวลาเป็ นเดือน
นีคือเหตุผลทีนักพัฒนารุน่ พีมีประสิทธิภาพมากกว่านักพัฒนารุน่ ใหม่: พวกเขาพิมพ์เร็วกว่าและรูจ้ กั คียล์ ดั มากกว่า ทํา
ให้พวกเขามีประสิทธิผลมากกว่า
นีคือเหตุผลทีการเขียนโปรแกรมแบบคู่ (pair programming) เป็ นเรืองหลอกลวง: ถ้ามีเพียงคนเดียวในสองคนทีพิมพ์
โครงการก็จะเสร็จเพียงครึงหนึงของความเร็ว
นีคือเหตุผลทีการเพิมคนในโครงการมากขึนจะช่วยให้สง่ มอบได้เร็วขึนแน่นอน ยิงมีคนเข้าร่วมมากเท่าไรยิงดี พิมพ์ให้
เร็วเหมือนสายลมเลย เพือน!
นีคือเหตุผลทีการพัฒนาซอฟต์แวร์นนสามารถคาดการณ์
ั
ได้อย่างมาก เราเพียงแค่ตอ้ งประมาณจํานวนบรรทัดของโค้ด
ทีต้องเขียนเพือให้ได้การคาดการณ์วนั ทีส่งมอบทีมีคณ
ุ ภาพสูง/ความน่าเชือถือสูง
จนถึงตอนนี ระดับของการประชดประชันในข้อความของฉันน่าจะถึงขันทีน่ารบกวนแล้ว
ประสบการณ์ทกุ คนรูว้ า่ ข้อความข้างต้นนันไร้สาระ แต่นา่ เสียดายทีเรืองราวไม่ได้งา่ ยอย่างนัน
นักพัฒนาซอฟต์แวร์ทีมี
นักพัฒนาไม่ได้เป็ นคนเดียวทีคิดเกียวกับการพัฒนาซอฟต์แวร์
ทุกคนทีเกียวข้องกับการพัฒนาภายในบริษัทของคุณก็มกั จะคิดถึงการพัฒนาซอฟต์แวร์ในลักษณะนี อาจรวมถึงหัวหน้า
ของคุณด้วย ลูกค้าของคุณก็มกั จะคิดถึงการพัฒนาซอฟต์แวร์ในลักษณะนีเช่นกัน มีโอกาสทีแม้แต่ตวั คุณเองก็อาจคิดใน
ลักษณะนี เมือพูดถึงซอฟต์แวร์ของคนอืนหรือเมือเจอเครืองมือสร้างโค้ดใหม่ทดูี น่าสนใจ
แม้วา่ คุณจะตระหนักถึงระดับของความซับซ้อนจนหลีกเลียงการตกหลุมพรางความคิดนันได้ แต่ก็จะมีคนรอบตัวคุณที
ยังคงคิดในลักษณะนีเสมอ
บางครังการพัฒนาซอฟต์แวร์ก็เป็ นแค่การพิมพ์เท่านัน
โชคร้ายทีคุณอาจต้องใช้เวลานานมากในการโน้มน้าวหัวหน้าของคุณว่าการพัฒนาซอฟต์แวร์เป็ นสิงทีซับซ้อนกว่าการ
พิมพ์โค้ดธรรมดา แต่สดุ ท้ายวันหนึงคุณอาจเจอกับงานบางอย่างทีมันเป็ นแค่การทํางานซําซากจริงๆ งานทีไม่ซากั
ํ นมาก
พอทีจะสร้างเป็ นสคริปต์ แต่ก็งา่ ยพอทีจะแสดงผลการคาดการณ์ทีดูค่อนข้างตรงไปตรงมา เช่น “ฉันใช้เวลา 2 ชัวโมงในการ
แก้ไขหน้านัน คงต้องใช้เวลาประมาณ 3 วันในการแก้ไขอีก 15 หน้าทีเหลือ”
สิงทีผูจ้ ดั การหลายคนไม่เข้าใจก็คือ นีเป็ นเพียงข้อยกเว้นจากกระบวนการปกติ การพัฒนาซอฟต์แวร์ไม่ใช่กระบวนการที
ทําซําได้ และเมือใดทีมันทําซําได้ เราสามารถแทนทีมันด้วยสคริปต์ แต่การประมาณการแบบเชิงเส้นกลับดูเป็ นตัวเลขทีคํานวณ
ได้ง่าย และดูเรียบร้อยสวยงามในสเปรดชีต Excel (ระดับการประชดประชันกําลังเพิมขึนอีกครัง)
การพัฒนาซอฟต์แวร์คือการเรียนรู ้
ความจริงคือ นักพัฒนาซอฟต์แวร์ใช้เวลาเป็ นจํานวนมากในการเรียนรูเ้ พือทําสิงทีพวกเขาไม่มคี วามรูอ้ ะไรเลยเกียวกับ
มัน นีไม่ได้เกียวข้องแค่กบั เทคโนโลยีหรือภาษาการเขียนโปรแกรมเท่านัน แต่ยงั เกียวข้องกับโดเมนของปั ญหา บริบท และอืนๆ
อีกมากมาย
แตกต่างจากวิชาชีพอืนๆ นักพัฒนากําลังทําสิงใหม่เป็ นครังแรกเกือบตลอดเวลา (แม้ว่าจากมุมมองภายนอกมันอาจดู
เหมือนแค่การพิมพ์โค้ดซําๆ ก็ตาม)
ส่วนใหญ่เมือเรารูเ้ กียวกับโดเมนของปั ญหามากพอ
(โดยสมมติว่าเราไม่มีสิงรบกวนใดๆ)
เราสามารถเดินหน้าต่อไปเพือแก้ปัญหาไปทีละขันโดยไม่ติดขัด
แต่นนก็
ั หมายความว่า หลายๆ ครังเมือเราเริมงานพัฒนา เราแทบจะไม่มีความคิดเลยว่าโซลูชนั ทีเราจะทําออกมานันจะ
มีหน้าตาเป็ นอย่างไร
จุดทีลงตัวของการเขียนโปรแกรม
ลองคิดดูสิ: หากปัญหายังไม่ได้รบั การแก้ไข นันแหละคือเหตุผลทีควรเขียนโค้ดบางบรรทัด แต่ถา้ ไม่...
เมือเราดูเหมือนกําลังทํางานอย่างมีประสิทธิภาพมากทีสุด อาจเป็ นช่วงเวลาทีเราไม่ได้สร้างคุณค่ามากนัก2
คุณสามารถประเมินการเรียนรูไ้ ด้หรือไม่?
จริง ๆ แล้ว คุณทําได้หรือเปล่า? ลองหยิบหนังสือมาหนึงเล่ม เช่น Domain-Driven Design ซึงเป็ นหนังสือเกียวกับการ
จัดการความซับซ้อนในกระบวนการพัฒนาซอฟต์แวร์ แล้วตอบคําถามสองข้อนี (สมมติว่าคุณยังไม่เคยอ่านมันมาก่อน):
1. คุณสามารถประเมินเวลาทีต้องใช้ในการอ่านได้หรือไม่?
2. คุณสามารถประเมินเวลาทีต้องใช้ในการทําความเข้าใจได้หรือไม่?
คําตอบของคําถามแรกค่อนข้างง่าย มันเป็ นการคาดการณ์อย่างง่าย ๆ สําหรับงานทีเป็ นกลไก: การอ่านวันละสิบกว่า
หน้าก่อนนอนจะทําให้คณ
ุ อ่านจบได้ในเวลาทีเหมาะสม แต่คาํ ถามทีสองล่ะ?
ความจริงทีไม่อาจพูดได้ของการเรียนรู ใ้ นระบบสถาบัน
แนวคิดทังหมดทีว่าการเขียนโค้ดเป็ นการเรียนรูจ้ ริง ๆ และการเขียนโปรแกรมในโลกความเป็ นจริงคือการตามล่าหา
เป้าหมายทีเคลือนทีนันขาดหายไปจากการเรียนรูใ้ นระบบสถาบันอย่างสินเชิง แบบฝึ กหัดการเขียนโค้ดในระบบสถาบัน
มักถูกกําหนดไว้ตามโจทย์ทมีี นิยามชัดเจน เขียนไว้อย่างชัดเจน และไม่เปลียนแปลงระหว่างทาง ฉันรูส้ กึ ว่ามุมมองนีอาจ
ไม่เพียงพอ
โปรแกรมเมอร์ทีเรียนรูด้ ว้ ยตัวเอง มีใครบ้าง?
ตลอดหลายปี ทีผ่านมา ฉันเริมสังเกตเห็นกลุ่มโปรแกรมเมอร์อีกประเภทหนึง: คนทีตกหลุมรักการเขียนโค้ดและก้าวไป
ไกลเกินความคาดหวัง มันสามารถเกิดขึนได้หลายวิธี โครงการส่วนตัว (pet project) เป็ นรูปแบบทีคลาสสิก ในฐานะ
โปรแกรมเมอร์วยั รุน่ ฉันเคยเริมทําวิดีโอเกมอยู่บา้ ง แม้แต่ในงานทีมหาวิทยาลัย ฉันมักจะลงเอยด้วยการเพิมฟี เจอร์
เพิมเติมให้กบั แบบฝึกหัดการเขียนโค้ด เพียงเพราะมันเจ๋ง
แต่ในโครงการส่วนตัว คุณเป็ นทังโปรแกรมเมอร์และผูท้ ีเกียวข้องกับโครงการ คุณเปลียนใจ คุณต้องทําการแลกเปลียน
(trade-off) และทังสองบทบาทนีเรียนรูไ้ ปพร้อม ๆ กัน
สิงนีไม่ได้เกิดขึนในระบบการเรียนรูข้ องสถาบัน และเรากําลังเผชิญกับผลลัพธ์จากสิงนัน
การพัฒนาซอฟต์แวร์คือการตัดสินใจ
นีเป็ นเรืองทีซับซ้อน และอาจเป็ นเหตุผลทีทําให้วิชาชีพการพัฒนาซอฟต์แวร์ใกล้เคียงกับการเขียนเชิงสร้างสรรค์ เรา
กําลังตัดสินใจอยู่ตลอดเวลา เราตัดสินใจเรืองเล็กน้อย เช่น การตังชือคลาส เมธอด หรือตัวแปร (ซึงอาจส่งผลร้ายแรงในระยะ
ยาว) แต่เราก็ตอ้ งตัดสินใจในเรืองทีไม่เล็กน้อยด้วย เช่น วิธีการนําเสนอวิธีแก้ปัญหาหนึง ๆ การเลือกใช้ไลบรารี คอมโพเนนต์
ผลิตภัณฑ์ หรือแม้กระทังภาษาการเขียนโปรแกรมสําหรับโครงการถัดไป ซึงทังหมดนีอยูใ่ นสเปกตรัมของ...
โอ้ เอาเถอะ ทุกคนก็ตอ้ งตัดสินใจ!
การพัฒนาซอฟต์แวร์คอื การรอ
ใช่แล้ว นีคือความลับเล็ก ๆ น้อย ๆ ทีนักพัฒนาซอฟต์แวร์ทกุ คนไม่อยากพูดถึง เรารอ เรารอเยอะมาก เรารอให้
คอมไพเลอร์สร้างโปรแกรมเสร็จ เรารอให้ลกู ค้าส่งคําชีแจงเพิมเติมมาให้เรา เรารอให้ชดุ การทดสอบรันจนเสร็จสิน เรารอให้แอด
มินระบบอนุญาตให้เราเข้าถึงไฟร์วอลล์ เรารอให้หอ้ งประชุมว่างสําหรับการประชุมสายหรือการทําโมเดล เรารอให้มกี ารจัดหา
มาร์กเกอร์และกระดาษโน้ตมาใหม่ เรารอให้หวั หน้าส่งคําติชมทีอาจทําลายความพยายามหนึงเดือนของเรา
เรารอ ทุกวัน และรอเยอะมาก
แต่ส่วนทีแย่ทีสุดไม่ใช่การรอ ส่วนทีแย่ทีสุดคือเรารูส้ กึ อายหรือเบือกับการรอมากเสียจนระหว่างทีเรารออะไรบางอย่าง
เราเริมทําอย่างอืนแทน
เป้าหมายของบทนี:
 โมเดลทางความคิดของเราทีมีตอ่ การพัฒนาซอฟต์แวร์ส่วนใหญ่นนผิ
ั ดพลาด
 เรากําลังพยายามปรับปรุงสิงทีไม่ถกู จุด
 ลองทําความรูจ้ กั กับ Kanban
 ลองศึกษา Theory of Constraints
11 การเรียนรูค้ ือปั ญหา แล้วไงต่อ?
การเข้าใจความไม่รูข้ องเรา
ช่วงเวลาทีฉันตระหนักว่าการเรียนรูค้ ือข้อจํากัดสําคัญในวิชาชีพของฉัน ฉันรูส้ กึ เหมือนถูกหักหลัง ฉันใช้เวลาหลายปี ใน
โรงเรียนและมหาวิทยาลัยบนเส้นทางการเรียนรูท้ ีดูเหมือนไร้ประโยชน์และไม่สนใจธรรมชาติทีแท้จริงของปั ญหา: ถ้าการพัฒนา
ซอฟต์แวร์เป็ นกระบวนการเรียนรู ้ ฉัน - ในฐานะนักพัฒนาซอฟต์แวร์มืออาชีพ - มีหน้าทีทีจะต้องเป็ น (หรือกลายเป็ น) ผูเ้ รียนรู ้
มืออาชีพ แต่ไม่มีอะไรในเส้นทางอาชีพของฉันทีนําพาฉันไปสู่จดุ นัน หรืออย่างน้อยฉันก็คิดเช่นนัน
การเรียนรูไ้ ม่ใช่การศึกษา
ช่วงเวลาทีฉันให้ความสําคัญกับการเรียนรูเ้ ป็ นจุดศูนย์กลาง ฉันก็ตระหนักว่าหลาย ๆ คนทีเป็ นเพือนร่วมงานของฉันมี
ทางลัดทางความคิดนี: การเรียนรูเ้ ท่ากับการศึกษา
การเรียนรูเ้ กิดขึนได้อย่างไร?
แรงกดดันทําลายการเรียนรู ้
โมเดลของ Dreyfus ในฐานะข้อจํากัดของการเรียนรู ้
ผลลัพธ์ทีมองไม่เห็น
ได้เวลาพูดถึงช้างในห้องแล้ว
ทุกครังทีฉันพูดคุยกับนักพัฒนาซอฟต์แวร์เกียวกับการพัฒนาซอฟต์แวร์ในฐานะ
กระบวนการเรียนรู ้ ฉันมักจะได้รบั การเห็นด้วยอยู่เสมอ
ฉันตระหนักถึงอคติทีผูกติดกับตําแหน่งของฉัน: ฉันพูดว่า "นักพัฒนาซอฟต์แวร์" แต่ในความเป็ นจริง ตัวอย่างของฉัน
ส่วนใหญ่ประกอบด้วยนักพัฒนาซอฟต์แวร์ทีสนใจใน Domain-Driven Design หรือโดยทัวไปคือคนทีอยู่ในชุมชนเดียวกับทีฉัน
อยู่ แต่ประเด็นนีไม่ใช่สาระสําคัญ
ปั ญหาทีแท้จริงคือ
วงจรชีวิตของเอกสาร
การเรียนรูโ้ ดยไม่มกี ารลงมือทําคือการเสียเปล่า
ข้อโต้แย้งเกียวกับการเรียนรูน้ นมี
ั ขอ้ เสียอยู่บา้ ง
กระบวนการพัฒนาซอฟต์แวร์แบบ Waterfall
ผูค้ นมักเชือมโยงการเรียนรูก้ บั ขันตอนวิเคราะห์ทถูี กตําหนิใน
แต่นนไม่
ั ใช่กรณีของ EventStorming อย่างแน่นอน
คอขวดคือการเรียกร้องให้ลงมือทํา
อีกเหตุผลหนึงทีคุณไม่ควรปล่อยให้ผลลัพธ์จากเซสชัน Big Picture EventStorming จางหายไป คือธรรมชาติของ
กระบวนการสํารวจนันเอง
ทบทวนทฤษฎีขอ้ จํากัด (Theory of Constraints) แบบรวดเร็ว
ในระบบการผลิต จะมีขอ้ จํากัดอยู่เสมออย่างน้อยหนึงอย่างทีจํากัดผลผลิตของระบบ การปรับปรุงประสิทธิภาพใน
ข้อจํากัดของระบบ - หรือทีเรียกว่า "คอขวด" (bottleneck) ในภาษาของ ToC - จะช่วยปรับปรุงประสิทธิภาพของระบบ
ทังหมด
พิสจู น์การเรียนรูข้ องคุณด้วยการเขียนโค้ดบางส่วน
การเรียนรู ้
กระบวนการทีแท้จริงคือการทําซํา (Iterative Process)
เป้าหมายของบทนี
 การเรียนรูไ้ ม่สามารถถูกผลักดันได้
 มองหาสิงกีดขวางทีขัดขวางการเรียนรู ้
 แม้กระนัน ยังต้องใช้เวลาและการทําผิดพลาดเพือให้การเรียนรูเ้ กิดขึน
ปฏิสมั พันธ์ระหว่างผูค้ น
ั
“มันเหมือนกับนิวทีชีไปยังดวงจันทร์ อย่ามัวแต่จอ้ งมองทีนิว มิฉะนันคุณจะพลาดความงดงามของสวรรค์ทงหมด”
บรู ซ ลี
12 ผูค้ นในระหว่างการลงมือทํา
มีบางสิงทีทําให้ฉันรูส้ ึกกลัวเมือได้ยินคําว่า “ให้ทกุ คนทีเกียวข้องมาอยูใ่ นห้องเดียวกัน” ไม่ใช่วา่ มันเป็ นแนวคิดทีแปลก
ใหม่ ฉันเองก็หวังว่าฉันจะเป็ นคนคิดอะไรแบบนันได้ แต่มนั ไม่ใช่กรณีนีเลย การนําคนสําคัญทังหมดมาอยู่ในห้องเดียวกันเป็ น
เรืองทีชัดเจนอย่างทีสุด
อย่างไรก็ตาม ยังมีเหตุผลทีทําให้ผคู้ นไม่ทาํ เช่นนัน
ฉันเดาว่าสิงทีฉันทําอาจคล้ายกับการพูดว่า “จักรพรรดิเปลือย” (The Emperor is Naked) ถ้าเราลองมองในแง่ลบ
(devil’s advocate) เกียวกับแนวคิดของการให้ทกุ คนสําคัญมาอยู่ในห้องเดียวกัน เราอาจจะได้รายการข้อคัดค้านทีน่าสนใจ
ดังนี:
 จะเป็ นการเสียเวลาของคน: ยิงคนมาก ยิงหมายถึงต้นทุนต่อชัวโมงทีเพิมขึน (เป็ นเชิงเส้น) และต้นทุนการ
จัดการทีเพิมขึนอย่างรวดเร็ว
(ใกล้เคียงกับการเพิมขึนแบบเอ็กซ์โพเนนเชียล)
ผลตอบแทนทีคุม้ ค่ากับเวลาทีใช้เพือให้ความพยายามนีสมเหตุสมผล
ดังนันเราจําเป็ นต้องมี
 เราเคยเข้าร่วมประชุมแบบนีมาก่อน: มันไม่มีประสิทธิภาพ ยืดเยือ และกลายเป็ นพิธีกรรมทีน่าเบือหน่ายใน
การพูดในสิงทีเรารูอ้ ยู่แล้ว
 ถ้าโชคดี เราอาจได้เห็นอีกตอนของ “การปะทะอีโก้ขององค์กร”
การจัดการคําเชิญ
ในสตาร์ทอัพ การเชิญคนทีเหมาะสมมาไม่ควรเป็ นปั ญหา บริษทั มีขนาดเล็กพอทีการรวบรวมทุกคนในห้องเดียวกันจะ
กลายเป็ นวิธีปฏิบตั ิเริมต้นอยู่แล้ว
แต่ในองค์กรขนาดใหญ่ แม้แต่การเข้าถึงคนทีเหมาะสมก็อาจเป็ นปัญหา ปั จจัยสําคัญคือระดับของการสนับสนุน
(sponsorship) ทีคุณมีในองค์กร ในฐานะทีปรึกษา ฉันมักจะอยู่ในตําแหน่งทีได้เปรียบ เนืองจากระดับของการสนับสนุน
สามารถมองเห็นได้ตงแต่
ั ขนตอนการเจรจา
ั
แต่ถา้ คุณอยู่ในองค์กรนันแล้ว มันยากมากทีจะฝ่ าฝื นกฎระเบียบและเรียกประชุม
เชิงปฏิบตั กิ ารพิเศษทีเกียวข้องกับคนทียุ่งมาก แพงมาก หรืออยู่สงู ในลําดับชันองค์กรจนคุณรูจ้ กั พวกเขาแค่จากการอ่านข่าว
การเงินเท่านัน
“ฉันจะทําอย่างไรให้หวั หน้าของฉันยอมเชือ?” เป็ นวิธีคิดทีมักจะล้มเหลว การโน้มน้าวใครบางคนให้ยอมเสียงกับสิงใหม่
ๆ ทีอธิบายได้ยากก่อนจะได้ลองสัมผัสจริง อาจจะจบลงด้วยทางตัน
สิงทีฉันมักจะแนะนําคือ เริมต้นจากสิงเล็ก ๆ โดยจัดเวิรก์ ชอปทีกําหนดเวลาและขอบเขตอย่างชัดเจน (อาจเริมจาก
ฟี เจอร์สาํ คัญเพียงไม่กีอย่าง) เพือสร้างคุณค่าบางอย่าง และค้นพบอุปสรรคทีซ่อนอยู่ซงอาจขั
ึ
ดขวางการทํางาน คุณจะไม่ตอ้ ง
ท้าทายรากฐานของโครงการหรือกลยุทธ์ของบริษัท แต่คณ
ุ จะรวบรวมข้อมูลมากพอทีจะทํางานได้ดีขึนในโครงการของคุณ และ
มีเครืองมือทีดีกว่าในการยกระดับไปสู่ Big Picture EventStorming
การจุดประกายเวิรก์ ชอป
ความสอดคล้องของกลุ่ม (Group Conformity)
ทุกกลุ่มมักจะแสดงระดับของความสอดคล้องกันในบางจุด หากทุกคนในบริบทหนึง (เช่น ห้องประชุมสําหรับเรา)
ประพฤติตวั ในแบบเดียวกัน เราจะรูส้ กึ กดดันให้ปฏิบตั ิตามมาตรฐานนัน แม้แต่ในกรณีทีการตัดสินใจของกลุ่มนันผิดชัดเจน คน
ส่วนใหญ่ก็ยงั เลือกทีจะทําตามกลุ่มแทนทีจะยืนหยัดในความเชือของตัวเอง
ถ้าคุณอยากรูส้ กึ ประหลาดใจกับเรืองนี ลองดูวิดีโอการทดลองของ Solomon Asch คุณอาจเปลียนความเห็นเกียวกับ
ธรรมชาติของมนุษย์เลยทีเดียว
วงจรสัญญาณ (Signaling Loop)
สิงทีเกิดขึนในสมองของคุณ ก็เกิดขึนในสมองของคนอืน ๆ ในห้องเดียวกันด้วย น่าเสียดายทีเราไม่ได้ตระหนักถึง
สัญญาณทีเรากําลังส่งออกไปอย่างเต็มที
ปั ญหากับเสียงเตือนภัยไฟไหม้
ปรากฏว่าถ้าหากมีไฟไหม้ในอาคารทีคุณอยู่ คุณมีโอกาสรอดชีวิตสูงกว่า ถ้าคุณอยู่คนเดียวในห้องในขณะทีเสียงเตือน
ภัยไฟไหม้ดงั ขึน
เหตุผล? อีกครังทีคําตอบคือ ความสอดคล้องของกลุ่ม (Conformity) เสียงเตือนภัยไฟไหม้ทาํ ให้คนอยู่ในสถานการณ์ทีไม่
คุน้ เคย ปฏิกิรยิ าทัวไปคือการมองหาคนอืนเพือดูว่าควรทําอย่างไรจึงจะถูกต้อง ถ้าคุณอยูค่ นเดียวในห้อง คุณมักจะใช้
วิจารณญาณของตัวเอง และรีบออกจากอาคารอย่างรวดเร็ว (อาจจะถือแล็ปท็อปออกมาด้วย)
แต่ถา้ คุณกําลังประชุมอยู่กบั เพือนร่วมงาน คุณจะมองดูพฤติกรรมของคนอืนในห้องเพือหาเบาะแส น่าเสียดายทีในกรณี
ุ เช่นกัน การรอว่า "เดียวดูวา่ คนอืนจะทําอะไร" ถูก
ทีไม่มีผเู้ ชียวชาญจริง ๆ คนอืน ๆ ก็จะทําสิงเดียวกัน นันคือมองดูคณ
ตีความผิดว่า "นีคงไม่อนั ตรายจริง ๆ" และคุณอาจอยู่ในอาคารนานกว่าทีควร
มีวิดีโอทีค่อนข้างน่าหวาดหวันเกียวกับการทดลองนีทีจับภาพไว้ดว้ ยเช่นกัน
การกระทําทียากจะย้อนกลับ
เพือจัดการเวิรก์ ชอปให้สาํ เร็จ เราจําเป็ นต้องตระหนักถึงบทบาทของแรงกดดันทีมองไม่เห็นเหล่านี ซึงมันจะมีอยูเ่ สมอไม่
ว่าคุณจะรับรูห้ รือไม่ก็ตาม
การนังลง: เมือคุณเลือกนังลง คุณกําลังส่งสัญญาณให้คนอืน ๆ ในห้องว่า ตอนนีโอเคทีจะนังได้แล้ว เมือคุณนังลง คน
อืน ๆ ก็มกั จะตามมานังเช่นกัน อย่างไรก็ตาม ความวุ่นวายจะหมดไป: แทนทีทุกคนจะทํางานร่วมกันเหมือนฝูงผึงอยู่หน้าพืนที
สําหรับทําโมเดล ทุกคนจะเริมมีแนวโน้มทีจะกลายเป็ นผูช้ มทีคอยดูวา่ คนอืนกําลังทําอะไร โดยเฉพาะอย่างยิงถ้าคุณนังอยู่ฝัง
ตรงข้ามของห้อง
การยืนขึน: การยืนขึนเพือไปเพิมโน้ตแผ่นหนึงบนกระดานอาจดูเหมือนไม่ใช่เรืองยาก แต่เมือทุกคนได้นงลงแล้
ั
ว การลุก
ขึนและวางโน้ตสีม่วง (เช่น การชีจุดสําคัญหรือปั ญหา) กลายเป็ นการกระทําทีดูเหมือนสร้างความแตกต่างใหญ่หลวง ต้องใช้
พลังงานมากขึนในการทําเช่นนัน โดยเฉพาะอย่างยิงถ้าโน้ตของคุณสามารถตีความได้วา่ เป็ นการวิจารณ์ใครบางคนในห้อง
โดยทัวไป เมือคนเริมนังลงแล้ว การให้พวกเขายืนขึนอีกครังกลายเป็ นเรืองทียากมาก
การเชียวชาญพลวัตของเวิรก์ ชอป
แนวทาง GameStorming
แหล่งข้อมูลทีดีทีสุดสําหรับการจัดการพลวัตในเวิรก์ ชอปคือหนังสือ GameStorming ของ Dave Gray ซึงนําเสนอโมเดล
ทีเรียบง่ายแต่ทรงพลังสําหรับกิจกรรมแบบร่วมมือ (Collaborative Activities)
ขันตอนหลักของการดําเนินเวิร์กชอปตามหลัก GameStorming (โดย Dave Gray / @davegray @xplane)
• ในขันตอนการเริมต้น (Opening phase) เราพยายามเพิมความคิดเชิงแตกแขนงให้ได้มากทีสุด: เราจะ
ต้องการความคิดเห็นทีเป็ นอิสระ และจัดการไดนามิกของเวิรก์ ชอปให้เหมาะสม
• ในขันตอนการสํารวจ (Exploring phase) เราจะพูดคุยและผสมผสานความคิดทีเป็ นอิสระของแต่ละบุคคล
ซึงมักจะกระตุน้ ให้เกิดมุมมองใหม่และความคิดทีเกิดขึนใหม่
• ในขันตอนการปิ ดท้าย (Closing phase) เราจะมุ่งเน้นไปทีการสรุปผลลัพธ์ทแน่
ี นอน โดยมักจะเลือก
ความคิดหรือมุมมองทีสําคัญทีสุด และคัดกรองความคิดทีอ่อนแอบางส่วนออกไป
ในทางปฏิบตั ิ ผูด้ าํ เนินเวิรก์ ชอปมีเครืองมือทีทรงพลังสองอย่างทีช่วยให้เขาจัดการการดําเนินเวิรก์ ชอปได้: การจัดเตรียม
ห้อง และกฎของเกม
การเชียวชาญในงานคูข่ นาน
เมือพูดถึง EventStorming เราต้องตระหนักว่ามีแรงผลักดันทีแตกต่างกันซึงกําลังทํางานอยู่ และบางส่วนอาจขัดแย้ง
กัน: *
การสังเกตภาษากาย
นีคือพืนทีของฉัน
นีคือปัญหา
ความไม่สอดคล้องทีมองเห็นได้มกั จะกระตุน้ ปฏิกิรยิ าทันที
การโจมตีปัญหา ไม่ใช่ตวั บุคคล
ขอยําอีกครัง: การนําเสนอภาพแทนทางกายภาพทีละเอียดของโดเมนช่วยให้ปัญหาถูกเน้นและแก้ไขได้โดยไม่ทาํ ให้เรือง
นันกลายเป็ นความขัดแย้งส่วนตัว เมือเผชิญกับปัญหาหรือภัยคุกคาม สมองของเรามีแนวโน้มทีจะมองหาภาพแทนทีชัดเจน
ของปัญหา หากสิงนีขาดหายไป เรามักจะเริมมองหาตัวเลือกทีดีทสุี ดรองลงมา ซึงโดยปกติจะเป็ นคนทีรายงานปั ญหา หรือคนที
ด้วยเหตุผลบางอย่างถูกเชือมโยงกับปัญหานัน
น่าเสียดายทีหากเราตอบโต้ปัญหาอย่างก้าวร้าว เรามักจะลงเอยด้วยการโจมตีบคุ คลแทน ซึงกระบวนการแก้ไขปั ญหา
จะกลายเป็ นปั ญหาส่วนตัวทีเลวร้าย พร้อมด้วยอารมณ์เชิงลบทีไม่ตงใจและไม่
ั
จาํ เป็ น เพือหลีกเลียงปัญหานี บางคนอาจลังเลที
จะพูด เพือหลีกเลียงการตําหนิใคร แต่การหลีกเลียงการพูดถึงปัญหาสําคัญไม่เคยเป็ นกลยุทธ์ทดีี
โน้ตสติกเกอร์สีแดงบนผนังพร้อมชือปั ญหาเป็ นเป้าหมายทีดีและง่ายสําหรับการวิพากษ์วจิ ารณ์และตําหนิ แทนทีจะเป็ น
เพือนร่วมงาน โน้ตสติกเกอร์ไม่รูส้ กึ ขุ่นเคืองหรือมีปฏิกิรยิ าเกินจริงต่อคําตําหนิ ปั ญหาสําคัญสามารถถูกพูดคุยได้ดว้ ยความ
เสียงทีจะกลายเป็ นเรืองส่วนตัวทีตํากว่า
บางครังผูค้ นก็ตอ้ งการทําให้เรืองนันเป็ นเรืองส่วนตัว
การพยายามรักษาความถูกต้องทางการเมือง (political correctness) ในทุกกรณีอาจไม่สามารถทําได้เสมอไป เรากําลัง
พยายามสืบสวนปั ญหา แต่เราอาจยังไม่รูม้ นั อย่างแท้จริง ฉันรูส้ กึ ยินดีมากเมือสามารถมองเห็นปั ญหาส่วนบุคคลเป็ น
ปั ญหาของระบบ และโจมตีระบบแทน แต่ก็ยงั มีกรณีที...
เวทมนตร์ของการค้นพบทังหมด
ฉันไม่รูเ้ ลย
ฉันไม่ใช่ส่วนหนึงทีนี
ความใกล้ชิดและระยะห่าง
เวิรก์ ชอปสามารถเป็ นโอกาสทียอดเยียมในการสังเกตไดนามิกของผูค้ นทีเกิดขึนจริง ความใกล้ชดิ ทางกายภาพสามารถ
เป็ นตัวบ่งชีทีดีถึงไดนามิกแปลกๆ ทีอาจเกิดขึน
การสร้างเรืองเล่าให้มีความชัดเจน
ไม่มีใครชอบความวุ่นวาย
การค้นพบทีไม่น่าแปลกใจมากนักคือ แม้จะไม่มีการชีนําทีชัดเจน ทีมต่างๆ ก็ยงั คงปรับตัวเองไปสู่การจัดระเบียบรูปแบบ
สําหรับเหตุการณ์ในโดเมนของพวกเขาโดยอัตโนมัติ
• บางทีมเลือกทีจะเรียงลําดับตามเวลาแบบซ้ายไปขวา: เช่น ไทม์ไลน์ทีกล่าวถึงก่อนหน้านี
• บางทีมจัดกลุ่มเหตุการณ์ตามความเชือมโยงเฉพาะโดเมน (เช่น เหตุการณ์ทีเกียวข้องกับการขายแยกออก
จากเหตุการณ์การส่งสินค้า และอืนๆ)
• บางทีมจัดกลุ่มเหตุการณ์ตามผูม้ สี ่วนเกียวข้องทีเกียวข้องในลักษณะทีมุ่งเน้นผูใ้ ช้งานมากขึน
• แม้วา่ เราจะพยายามหลีกเลียงการให้คาํ แนะนําเฉพาะ
แต่ไม่มีทีมใดทีอยูใ่ นโหมดระดมสมองแบบไร้
ระเบียบโดยสมบูรณ์
• สิงนีบอกอะไรบางอย่างเกียวกับ "ตาข่ายนิรภัย" ของเรา ซึงยังคงหนาแน่นเมือเราพยายามเข้าสูก่ ารสร้าง
โมเดลแบบอิสระเสรีอยู่เสมอ เพราะมักจะมีใครบางคนพยายามเพิมโครงสร้างให้กบั ข้อมูลดิบ
วิธีการทีแตกต่างกันนําไปสู่การค้นพบใหม่ได้รวดเร็วขึน แต่ก็อาจซ่อนศักยภาพบางส่วนของวิธีการใช้ไทม์ไลน์ไว้เช่นกัน
ทําไมไทม์ไลน์ถึงดีกว่า
อย่างไรก็ตาม หลักฐานทีโดดเด่นทีสุดคือ การไม่ปฏิบตั ิตามไทม์ไลน์ทาํ ให้สิงต่างๆ ยากกว่าทีควรจะเป็ น
การสํารวจแบบลําดับเหตุการณ์นนเป็
ั นธรรมชาติมากกว่า
“ลูกค้าเพิมสินค้าในตะกร้า แล้วดําเนินการเช็คเอาท์เพือชําระเงิน” หรือ “เมือมีการสังซือ คําแนะนําการบรรจุสินค้าที
เกียวข้องจะถูกส่งไปยังคลังสินค้า” ในการสํารวจกระบวนการทางธุรกิจ เรามักจะลําดับเหตุการณ์ในแบบลําดับต่อเนือง
โดยประมาณ คําว่า “แล้ว” (Then) คือคําสําคัญทีเชือมโยงเหตุการณ์บางอย่างเข้ากับเหตุการณ์ต่อเนือง
การบังคับใช้ไทม์ไลน์ชว่ ยให้ผคู้ นมองเห็นลําดับเหตุการณ์และจุดช่องว่างระหว่างเหตุการณ์ได้งา่ ยขึน เช่น “ควรมี
เหตุการณ์ ‘ยืนยันการชําระเงิน’ ระหว่าง ‘เช็คเอาท์ตะกร้า’ และ ‘จัดส่งสินค้า’!” ความไม่สอดคล้องจะมองเห็นได้ชดั เจนขึน
(เพราะการมองเห็นช่องว่างในเรืองราวเล่าง่ายกว่าการมองในรูปแบบการจัดหมวดหมู)่ และสิงนีช่วยส่งเสริม "ความฉลาดร่วม
ของกลุ่ม" ให้แข็งแกร่งยิงขึน
การสร้างเรืองเล่าให้ชดั เจน
ฉันตระหนักได้ว่าหนึงในแหล่งแรงบันดาลใจทีฉันไม่ได้ตงใจมาจากรายการที
ั
วีเรือง ‘LOST’ ขณะดูเนือหาเสริมใน DVD
ฉันรูส้ กึ ประทับใจกับวิธีทีพวกเขาวางโครงเรืองด้วยโน้ตสติกเกอร์ เพือติดตามเรืองราวคู่ขนานต่างๆ และเหตุการณ์ทีเกียวข้อง
ผูเ้ ขียนไม่ได้อธิบายว่าพวกเขาเขียนเรืองอย่างไร แต่สงที
ิ ฉันเห็นในพืนหลังระหว่างการสัมภาษณ์นนก็
ั สร้างแรงบันดาลใจให้ฉนั
แล้ว
ต่อมา การได้เห็น Movie Narrative Charts อันยอดเยียมจาก XKCD4 อาจทําให้ทกุ อย่างสมบูรณ์ขึน สมองของฉันรูส้ กึ
ถูกดึงดูดทันที
ประเด็นก็คือ…เราไม่ได้กาํ ลังรวบรวมความต้องการ! เรากําลังมีบทสนทนาทีมีความหมาย! และในบทสนทนา ผูค้ นมัก
ชอบเล่าเรือง
เรืองราวคือวิธีทีความรูถ้ กู ถ่ายทอดระหว่างผูค้ น “การขับรถและดืมเครืองดืมแอลกอฮอล์เป็ นอันตราย” ดูจืดชืดเมือเทียบ
กับ “คืนนัน บ็อบกําลังขับรถกลับบ้านหลังจากดืมเบียร์ไปสองสามขวด เขาชนรถคันหนึง และเด็กผูห้ ญิงสองคนได้รบั บาดเจ็บ
ตอนนีเขากําลังเผชิญกับการพิจารณาคดีและมีความเสียงทีจะติดคุกอย่างจริงจัง”
เรืองราวคือวิธีทีตํานานและศาสนาแพร่กระจายไปในกลุ่มคนทีไม่รูห้ นังสือ
เรืองราวคือสิงทีทําให้ผคู้ นติดรายการทีวี วัยรุน่ ติดโทรศัพท์ เพือนร่วมงานคุยกันทีเครืองทํานําเย็น และเพือนเก่าเล่าให้
กันฟังในผับ
เรืองราวคือสิงทีผูค้ นชอบเล่า และยังเป็ นสิงทีผูค้ นพร้อมจะรับฟั ง
เรืองราวยังมีความสอดคล้องในบางแง่มมุ ผูค้ นมักจับความสัมพันธ์ระหว่างเหตุและผลระหว่างข้อเท็จจริงต่างๆ อย่าง
กระตือรือร้น และบางครังพวกเขาก็พยายามหาเหตุและผลเชือมโยง แม้ในสถานการณ์ทีไม่มคี วามเกียวข้องกันก็ตาม
การเดินผ่านสถานการณ์
คําถามทีดูเหมือนไร้เดียงสาจากเครืองทํานําเย็น
ในเวิรก์ ชอป EventStorming มักมีลกั ษณะนิสยั สองอย่างทีเกิดซําในส่วนผสมของบุคลิกภาพ:
• นักพัฒนาซอฟต์แวร์มกั จะมุ่งเน้นไปทีกรณีเลวร้ายทีสุดทีไม่นา่ จะเกิดขึน
• ผูเ้ ชียวชาญด้านโดเมนมักจะนําเสนอภาพรวมทีดูเรียบง่ายเกินไป เพือไม่ให้สร้างความสับสนให้กบั
นักพัฒนา
Walking Skeleton - นิยามใหม่
คําว่า Walking Skeleton ได้รบั ความนิยมจาก Steve Freeman และ Nat Pryce ในหนังสือ Growing Object-Oriented
Systems, guided by tests และหมายถึง [FIXME - อ้างอิงคําจํากัดความต้นฉบับ] แต่คาํ จํากัดความดังเดิมมาจาก Alistair
Cockburn5:
Walking Skeleton คือการสร้างระบบขนาดเล็กทีสามารถทํางานแบบครบวงจรได้ในขอบเขตเล็กๆ ไม่จาํ เป็ นต้องใช้
สถาปั ตยกรรมขันสุดท้าย แต่ควรเชือมโยงส่วนประกอบหลักของสถาปั ตยกรรมเข้าด้วยกัน จากนันสถาปั ตยกรรมและฟังก์ชนั
การทํางานสามารถพัฒนาไปพร้อมกันได้
มันเป็ นความล้มเหลวจริงหรือไม่?
ในบางกรณี ผลลัพธ์ของ...
ไม่มใี ครอยากผิด
อคติในการระดมสมอง
ช่วงหลังมานี มีการถกเถียงกันมากเกียวกับประสิทธิภาพทีแท้จริงของการจัดเซสชันระดมสมอง (Brainstorming)
EventStorming ไม่ใช่การระดมสมอง (Brainstorming)
แม้วา่ ชือจะมีคาํ ว่า storming แต่ EventStorming มีความเกียวข้องเพียงเล็กน้อยกับวัตถุประสงค์ดงเดิ
ั มของเซสชันระ
ดมสมอง
เวิรก์ ชอป Big Picture เป็ นเวิรก์ ชอปทีเน้นการค้นพบ (Discovery Workshop) เป็ นหลัก: ไม่ได้มีความคิดสร้างสรรค์เข้า
มาเกียวข้องมากนัก และผูค้ นทีหลากหลายควรมีส่วนร่วมจากมุมมองทีแตกต่างกันในโครงเรืองเดียวกัน อย่างไรก็ตาม ความ
เสียงของการคิดเป็ นกลุ่ม (Groupthink) ทีอาจนําไปสู่ผลลัพธ์ทีด้อยกว่ายังคงมีอยู่
นีคือหน้าทีเฉพาะของผูด้ าํ เนินเวิรก์ ชอปทีจะต้องมองหาสัญญาณของการแสดงอํานาจและความสอดคล้องทีอาจลด
ความหลากหลายของข้อมูล และจัดการมันให้เหมาะสม (ดูเพิมเติมในหัวข้อ single out the alpha male ในส่วน Patterns)
เป้าหมายของบทนี
•
•
•
•
ั (The Ubiquitous Body Language)
ภาษากายทีมีอยู่ทวไป
คนสําคัญกว่ารูปแบบ (People matter more than the model)
Walking Skeleton, นิยามใหม่ (The Walking Skeleton, redefined)
เกณฑ์ความสําเร็จของเวิรก์ ชอป (Workshop success criteria)
13 การอํานวยความสะดวกในการจัดเวิรก์ ช็อป
ในบทก่อนหน้านี เราได้กล่าวเป็ นนัยว่าเวิรก์ ช็อป EventStorming นันเหมือนกับการจัดปาร์ตี และนีคือจุดทีเราจะอธิบาย
วิธีการเป็ นดีเจทียอดเยียม
เศรษฐศาสตร์ของการประชุมกับผูบ้ ริหารระดับสูง
เพือไม่ให้ดนู า่ เบือ เรามาดูคณิตศาสตร์พืนฐานกันหน่อย:
การประชุมมีค่าใช้จ่ายเท่าไหร่?
เอาล่ะ...นีจะช่วยให้เรากําหนดเป้าหมายของเราได้เช่นกัน [FIXME: มีการซําซ้อนในประเด็นนี]:
เป้าหมายคือการทําให้แน่ใจว่าเวิร์กช็อปจะมีคณ
ุ ค่ามากกว่าระยะเวลาทีลงทุนไปทังหมด
แล้วโอกาสทีพลาดไปล่ะ?
มีผลเสียมากมายจากการคิดแค่ในแง่ของค่าใช้จา่ ย วิธีคิดทีแม่นยํากว่าคือการพิจารณาเรือง "โอกาสทีพลาดไป" มัน
ไม่ใช่แค่ตน้ ทุนรายชัวโมง แต่มนั คือ "สิงทีฉันอาจทําได้แทนทีจะมาประชุม"
เวลานันไม่ได้เป็ นเส้นตรงอยู่แล้ว
ถึงแม้ว่าเราจะคํานวณต้นทุนการเข้าร่วมของแต่ละบุคคลได้ แต่ผลตอบแทนจากการลงทุน (Return on Investment) นัน
ไม่ได้เป็ นเส้นตรงเลย [FIXME: อ้างอิงถึงบทเรียนในบทก่อนหน้า] และยังถูกจํากัดอย่างมากโดยเรืองสรีรวิทยาและรอบพลังงาน
เมือคนเริมเหนือย การยืนยันทีจะทําต่อไปเพียงเพือให้ได้ติดสติกเกอร์บนผนังทังหมดก็อาจไม่สมเหตุสมผล ถ้าคนเริมเหนือย
ั งดูดความสนใจทังหมดของเราไปแล้ว บางทีการ
อาจจะดีทีสุดทีจะหยุดพัก ออกไปเดินเล่น ผนังทีเราใช้ติดสติกเกอร์นนดึ
สนทนาทีน่าสนใจอาจเกิดขึนเมือเราอยูใ่ นทีทีผนังไม่ใช่จดุ สนใจหลักก็ได้
กระตุน้ คําถาม
อนุญาตให้ผคู้ นถอนตัว
หลังจากเริมต้นเวิรก์ ช็อปไปแล้ว
อาจจะเห็นได้ชดั ว่าผูเ้ ข้าร่วมบางคนไม่ได้มีบทบาทสําคัญในประเด็นทีกําลังจะถูก
อภิปราย มีหลายเหตุผลทีทําให้บางคนไม่สามารถมีส่วนร่วมได้อย่างเต็มที และหากมีใครคิดว่าตนเองไม่เหมาะสมทีจะอยู่ต่อ ก็
ควรเปิ ดโอกาสให้พวกเขาถอนตัวได้
อนุญาตให้ผคู้ นอยู่ต่อ
ในทางกลับกัน สิงนีก็ใช้ได้เช่นกัน บางครังการประชุมมีวาระทีกําหนดไว้อย่างชัดเจนอยู่แล้ว เช่น “ตอนเช้าเราจะสํารวจ
ภาพรวมใหญ่ และตอนบ่ายจะประชุมกลุ่มเล็กทีมุ่งเน้นในรายละเอียดทางเทคนิคของฟี เจอร์ X” ฉันเองเคยมีการสนทนาทีดี
ทีสุดครังหนึงในช่วงการประชุมกลุ่มเล็ก กับผูเ้ ชียวชาญในโดเมนทีไม่ใช่สายเทคนิคซึงขออยู่ต่อเพียงเพราะความอยากรูอ้ ยาก
เห็น
เก็บปากไว้เงียบ
สําหรับคนทีมีบุคลิกชอบเก็บตัวและคนทีชอบแสดงออก
14 การทําลายข้อจํากัดของพืนที
เกิดอะไรขึนในสมองของเราเมือเรามีพนที
ื สําหรับการสร้างแบบจําลองทีไม่จาํ กัด?
แล้วถ้าเราไม่มีสิทธินันล่ะ จะเป็ นอย่างไร?
อะไรทีทําให้ EventStorming แตกต่างจากการสร้างแบบจําลองบนไวท์บอร์ด? นีคือเหตุผลบางประการ:
• การใช้กระดาษม้วนหรือพืนผิวการสร้างแบบจําลองทีไม่จาํ กัดช่วยให้ทีมสามารถสร้างแบบจําลองหัวข้อที
ซับซ้อนมากขึนได้
• การใช้กระดาษโน้ตแบบกาวช่วยให้เพิมจํานวนรายการในพืนทีเดียวกันได้มากขึน
• การใช้สีช่วยให้เข้าใจโครงสร้างได้ดีขึน ส่งเสริมรูปแบบการสร้างแบบจําลองทีเกิดขึนซําๆ อย่างมีแบบแผน
• การมีพนที
ื และปากกามากขึนช่วยให้สามารถสร้างแบบจําลองแบบขนานในพืนทีต่างๆ ได้
• การใช้กระดาษโน้ตช่วยลดต้นทุนในการเขียนใหม่หรือย้ายตําแหน่ง
• การมีพนที
ื มากขึนและคนจํานวนมากขึนช่วยให้สามารถจัดกลุ่มผูค้ น ธีม และแนวคิดได้อย่างเป็ นธรรมชาติ
การเอาชนะข้อจํากัดโดยนัยของไวท์บอร์ด
ขนาดตัวอักษรมีความสําคัญ
ยังมีเคล็ดลับเล็กๆ น้อยๆ ในการสร้างแบบจําลองโดยใช้กระดาษโน้ตแบบกาว: เราใช้พืนทีทีมีอยู่ได้อย่างมีประสิทธิภาพ
มากขึน
ลองพิจารณาพืนทีทีต้องใช้ในการเขียนชือคลาส เช่น ItemAddedToCart ด้วยลายมือบนไวท์บอร์ดของคุณ เปรียบเทียบ
กับพืนทีทีใช้เขียนสิงเดียวกันบนกระดาษโน้ตแบบกาว คุณจะเห็นความแตกต่างได้อย่างชัดเจน
มันชัดเจนจนรู ส้ กึ น่าอาย...
ปลายปากกาไวท์บอร์ดมักจะหนากว่า ทําให้ไม่มที างเขียนตัวเล็กๆ แล้วอ่านออกได้ การเขียนบนไวท์บอร์ดใช้พืนที
ประมาณสามเท่าของพืนทีทีต้องการสําหรับการเขียนข้อความเดียวกันบนกระดาษโน้ตแบบกาว
เดียวก่อน! คุณใช้สองบรรทัด! คุณกําลังบอกว่าฉันโกงหรือเปล่า? ใช่ ฉันกําลังบอกแบบนัน! กระดาษโน้ตแบบกาวบังคับ
ให้เราใช้พืนทีน้อยลง ในขณะทีไวท์บอร์ดไม่ทาํ หรือหากทําก็ในลักษณะทีน่ารําคาญกว่า
ความผิดพลาดจากการจมทุน (Sunken Cost Fallacy)
ไม่ว่าคุณจะเก่งแค่ไหน แบบจําลองของคุณก็จะผิดอยู่ดี
ลายมือของฉันแย่มาก
หลายคนคิดว่าการมีลายมือสวยเป็ นเหมือนพรสวรรค์ และไม่มีอะไรทีเราจะทําได้เพือปรับปรุงมัน แต่ความจริงแตกต่าง
ออกไป: ลายมือจะดีขึนเมือคุณฝึกฝนมากขึน นีคือเคล็ดลับเล็กๆ ของฉัน: หาปากกามาร์คเกอร์ดๆี สักแท่ง เขียนให้สามารถอ่าน
ได้ ไม่ชอบผลลัพธ์ทได้
ี เหรอ? ไม่เป็ นไร ผ่อนคลาย ทิงกระดาษโน้ตแบบกาวแผ่นนันไป แล้วเขียนใหม่อีกแผ่น
ภาพลวงตาของแบบจําลองทีไม่จาํ กัด
พืนผิวสําหรับการสร้างแบบจําลองในอุดมคติควรมีความกว้างและความสูงทีไม่มีทีสินสุด
แนวนอนได้ แต่เราไม่สามารถบินได้ ดังนันพืนผิวทีสูงอย่างไม่มที ีสินสุดจึงไม่ได้ชว่ ยอะไร
ปั ญหาคือ
เราเดินไปใน
ความกว้างของกระดาษม้วนเพียงพอหรือไม่?
ในรอบสํารวจครังแรก กระดาษม้วนเพียงม้วนเดียวก็น่าจะเพียงพอ แต่ในภายหลัง คุณอาจถึงจุดทีกระดาษม้วนเดียวไม่
เพียงพอ และนีคืออาการบางอย่างทีบ่งบอกว่าเกิดปั ญหา: การเพิมข้อมูลในแบบจําลองเริมช้าลง ผูค้ นเริมขมวดคิวบ่อยขึน และ
ปั ญหาดูเหมือนจะยากขึนทีจะสร้างแบบจําลอง มีคนขอให้เพิมความชัดเจนหรือแยกโฟลว์ออกเป็ น "ช่องทางว่ายนํา" (swimlanes)
คุณมีกระดาษโน้ตแบบกาวสีสม้ เพียงพอหรือไม่?
มี "กฎลับ" ของโรงแรมในการจัดการบุฟเฟต์ คือ การมีอาหารในปริมาณมากพอเพือลดการสูญเสียอาหาร เมือต้อง
เผชิญหน้ากับบุฟเฟต์ทเต็
ี มไปด้วยอาหาร ผูค้ นมักจะตักเฉพาะสิงทีพวกเขาต้องการกิน (สมองทีหิวโหยจะรูส้ กึ พอใจเมือเห็นว่ามี
อาหารเพียงพอสําหรับรอบทีสอง) ในขณะทีถ้าอาหารมีนอ้ ย ผูค้ นจะตักจนเต็มจาน เพราะกลัวว่าอาหารจานพิเศษบางอย่างจะ
หมดในรอบหน้า
สมองของเรากับกระดาษโน้ตสีสม้ ก็ไม่ตา่ งกัน: พยายามเตรียมกระดาษโน้ตสีสม้ ให้มากทีสุดเท่าทีจะทําได้ เมือมีเพียง
ไม่กีแผ่น สมองของคุณอาจส่งสัญญาณว่า “ถ้าฉันเริมสร้างแบบจําลองอย่างละเอียด เราอาจจะใช้กระดาษไม่พอ” ซึงจะทําให้
การสร้างแบบจําลองกลายเป็ นการทําในระดับมหภาคทีไม่น่าสนใจ
ทังหมดนีขัดกับหลักการในหนังสือ Elements of UML Style หรือไม่?
ใช่ หนึงในจุดสําคัญในหนังสือของ Scott Ambler คือ ไม่ควรวาดกล่องเกินเจ็ดกล่องในไดอะแกรมเพือให้เข้าใจได้ง่าย
อย่างไรก็ตาม ปัญหาในทีนีต่างออกไป: เรากําลังสร้างแบบจําลองร่วมกัน และเมือสํารวจระบบขนาดใหญ่ ข้อจํากัดนีจะ
ไม่สมเหตุสมผล อย่างไรก็ตาม เมือเรากําลังเจาะลึกในส่วนใดส่วนหนึงของระบบ ข้อเสนอแนะของฉันคือ ให้ลบ
สิงรบกวนออก และเริมสํารวจบนพืนผิวใหม่
เป้าหมายของบทนี:
•
•
•
•
อะไรเกิดขึนในสมองของเราเมือเราไม่มีพืนทีเพียงพอ?
จะเข้าใจความรูส้ กึ ไม่สบายใจในสมองของเราได้อย่างไร?
จะทําอย่างไรให้ได้พนที
ื ไม่จาํ กัด?
จะเชียวชาญกลไกของพืนทีไม่จาํ กัดได้อย่างไร?
การฝึ กเขียนตัวอักษร (The Lettering Kata)
นีคือสิงทีคุณสามารถทําได้เพือพัฒนาทักษะการเขียนตัวอักษรของคุณ
การสร้างแบบจําลองกระบวนการและบริการ
ในส่วนนี เราจะสํารวจว่า EventStorming สามารถเปลียนจากเครืองมือสําหรับการค้นหา (discovery tool) ไปเป็ นเครืองมือ
สําหรับการออกแบบร่วมกัน (collaborative design tool) ได้อย่างไร โดยส่งเสริมความร่วมมือระหว่างสาขาวิชาต่างๆ ของผูม้ ี
ส่วนได้ส่วนเสีย เพือออกแบบบริการ ฟี เจอร์ และผลิตภัณฑ์ทีมีความหมาย
15 แพลตฟอร์มสําหรับความร่วมมือ
การสร้างแบบจําลองกระบวนการเป็ นสถานการณ์ทีได้รบั ประโยชน์มากทีสุดจากความร่วมมือระหว่างสาขาวิชาต่างๆ
เพือให้ได้แบบจําลองทีน่าพอใจ สิงสําคัญคือผูม้ ีส่วนได้ส่วนเสียทีสําคัญทังหมดต้องมีส่วนร่วม เช่น ผูม้ ีส่วนได้ส่วนเสียทางธุรกิจ
นักออกแบบบริการ นักออกแบบประสบการณ์ผใู้ ช้ และนักพัฒนาซอฟต์แวร์ เป็ นต้น
16 การสํารวจคุณค่า
จุดประสงค์สงู สุดของกระบวนการทีคุณกําลังออกแบบคืออะไร? หรือซอฟต์แวร์ทีคุณกําลังพัฒนาล่ะ? คุณจะทําให้
ผูใ้ ช้งานของคุณมีความสุขได้อย่างไร?
คําถามเหล่านีมักถูกมองข้ามในโครงการพัฒนาซอฟต์แวร์ ฟี เจอร์นนอยู
ั ่ในแบ็คล็อกอยู่แล้ว ดังนันจึงเห็นได้ชดั ว่ามี
คุณค่าทางธุรกิจบางอย่างเกียวข้องกับมัน หรือพูดอีกแบบ... [FIXME: ยังเขียนไม่สมบูรณ์]
เมือคุณมีภาพรวมของกระบวนการทางธุรกิจทังหมดอย่างชัดเจน คุณอาจต้องการตรวจสอบให้ละเอียด โดยการทดสอบ
ปั จจัยมนุษย์
นีอาจเป็ นเรืองยาก เพราะทุกคนในองค์กรควรจะรูเ้ กียวกับธุรกิจของตัวเองอยู่แล้ว และการถามคําถามทีทุกคนดูเหมือน
จะรูอ้ ยู่แล้วก็อาจดูเหมือนเป็ นการเสียเวลา
กล่าวอีกแบบ: นีคือคําถามประเภททีดูเหมือนไร้สาระ ซึงผูช้ ว่ ยภายนอกจะมีสิทธิถามได้มากกว่าพนักงานภายในองค์กร
สํารวจคุณค่าทีสร้างขึนและถูกทําลาย
มองหาธุรกรรมหลัก
กระบวนการทางธุรกิจมักจะเกิดขึนรอบๆ ธุรกรรมเฉพาะอย่าง ในความเป็ นจริง หลายกระบวนการมีอยูเ่ พียงเพือทําให้
ธุรกรรมนันเป็ นไปได้
บริษัทของฉัน Avanscopertaa ให้บริการการอบรมสาธารณะสําหรับวิชาชีพขันสูง ในสถานการณ์เช่นนี ธุรกรรมหลัก
เกิดขึนเมือการอบรมถูกส่งมอบ และผูเ้ ข้าร่วมได้รบั ความรูต้ ามสิงทีพวกเขาจ่ายเงินมา แต่...มันไม่ได้ทาํ งานแบบนัน!
การดําเนินการแบบพืนฐานของกระบวนการนี อาจดูเหมือนว่าผูค้ นจ่ายเงินทีหน้าประตูเพือเข้าร่วมการอบรมและสร้าง
ความรูโ้ ดยการเรียนรู ้ แต่ในความเป็ นจริง นันจะไม่เวิรก์ ในทางปฏิบตั ิ เพราะบัตรเข้าร่วมต้องถูกขายล่วงหน้าเพือไม่ให้
วันจัดงานเสียงต่อการล้มเหลว และเพือให้สามารถวางแผนได้อย่างมันคงยิงขึน การขายบัตรล่วงหน้าจึงสร้างคุณค่าใน
แง่ของการลดความไม่แน่นอนเกียวกับวันทีจัดการอบรม บัตร Early Bird แบบมีส่วนลดจึงเป็ นวิธีทีใช้กนั ทัวไปเพือลด
ความไม่แน่นอนนี
ธุรกรรมหลักจึงถูกแบ่งออกเป็ นส่วนต่างๆ: เงินถูกโอนให้ผจู้ ดั งานทันทีทีขายบัตรได้ (ขึนอยู่กบั ประเภทการชําระเงินที
เลือก) ในขณะทีความรูจ้ ะถูกส่งมอบให้ผเู้ ข้าร่วมในระหว่างคลาสการอบรม ช่วงเวลาทีห่างกันระหว่างสองช่วงเวลา
สําคัญนี เปิ ดโอกาสให้เกิดปัญหาการยกเลิกและการคืนเงินทีซับซ้อนทีสุด
จากมุมมองของผูฝ้ ึ กอบรม คุณค่าถูกสร้างขึนและถูกทําลายไปตลอดกระบวนการ บางคนอาจมองว่าการปรากฏตัวใน
เว็บไซต์ของบริษัทร่วมกับผูเ้ ชียวชาญคนอืนๆ มีคุณค่าต่อชือเสียงของพวกเขา ขณะทีบางคนอาจรูส้ ึกรําคาญเมือถูก
ขอให้ส่งรูปถ่ายและประวัติส่วนตัว
เมือพูดถึงการวางแผน ผูฝ้ ึ กอบรมเองก็ตอ้ งจัดการกับความไม่แน่นอนเช่นกัน: การยกเลิกในนาทีสดุ ท้ายอาจกลายเป็ น
ปั ญหา เพราะอาจไม่มเี วลาพอทีจะหาช่องทางรายได้อืนมาทดแทนในวันทีว่างเปล่านัน
จะเกิดอะไรขึนหากธุรกรรมหลักไม่อยู่ในขอบเขต?
ในระบบซอฟต์แวร์ มักจะค่อนข้างหายากทีธุรกรรมจริงจะเกิดขึนภายในซอฟต์แวร์เอง ตัวอย่างเช่น ใน Amazon ลูกค้า
ทําการสังซือบนเว็บไซต์ แต่สินค้าถูกส่งมอบในโลกจริง Kindle Reader อาจเป็ นข้อยกเว้น แต่ในขณะทีการครอบครองหนังสือ
แบบกระดาษสามารถสร้างคุณค่าได้ดว้ ยตัวมันเอง เวอร์ชนั Kindle กลับไม่ได้ทาํ งานในลักษณะนัน คุณค่าจะถูกสร้างขึนก็
ต่อเมือลูกค้าได้อา่ นหนังสือจริงๆ เท่านัน
สํารวจสกุลเงินหลายประเภท
จะทําอย่างไรเมือไม่มคี ณ
ุ ค่า?
มองหาความไม่สอดคล้องกัน
เป้าหมายของบทนี:
• กระบวนการต่างๆ ไม่ได้เป็ นสิงทีกําหนดแน่นอนเสมอไป พวกมันต้องพิสจู น์ว่ามีความถูกต้อง
ุ ค่าเดียวทีต้องค้นหา
• เงินไม่ใช่คณ
• บางครัง การสร้างคุณค่าอาจอยูใ่ กล้แค่เอือม
17 การสังเกตสถานะโดยรวม
ธนาคารกังวลมากเกียวกับความสอดคล้องในทีสุด (eventual consistency) แต่ทกุ ครังทีฉันโอนเงิน ฉันจะเห็นเงินหายเข้าไป
ในรูหนอน และปรากฏขึนอีกครังในทีอืนหลังจากสองสามวัน
ความหลงใหลในธุรกรรม
ทุกธุรกรรมทางธุรกิจสามารถมองได้วา่ เป็ นกระบวนการของการปรับสมดุล (reconciliation) ทีเติมเต็มช่องว่างระหว่าง
สถานะปั จจุบนั และสถานะทีต้องการ
ตัวอย่างเช่น ฉันอาจรูส้ กึ หิวขณะเดินผ่านรถขายอาหารของ John’s Street Food ถ้ากลินหอมน่าทานและฉันมีเงินใน
กระเป๋ าสตางค์ สถานการณ์นีอาจกระตุน้ ให้เกิดธุรกรรมทางธุรกิจ เช่น การซือฮอทด็อก และการดําเนินการทีจําเป็ นเพือเติมเต็ม
ความต้องการนี
อย่างไรก็ตาม ธุรกรรมนีไม่ได้เกิดขึนในลักษณะอะตอมมิก (atomic) เหมือนธุรกรรมในฐานข้อมูล ฉันไม่ได้ยืนธนบัตร 5
ยูโรด้วยมือซ้ายและปล่อยมันให้กบั John หลังจากทีฉันกินฮอทด็อกด้วยมือขวาเสร็จในคําเดียว
ในความเป็ นจริง ฉันจะเพียงแค่ขอฮอทด็อกและจ่ายเงินสําหรับมัน โดยเปิ ดโอกาสให้ John สามารถวิงหนีไปเริมต้นชีวิต
ใหม่พร้อมกับธนบัตร 5 ยูโรของฉันโดยไม่เสิรฟ์ ฮอทด็อกให้ฉัน ในช่วงเวลาประมาณหนึงนาที ฉันอาจรูส้ กึ ตืนเต้นกับความ
เป็ นไปได้ทจะเสี
ี ยเงิน หรืออาจจะไม่ เพราะเงิน 5 ยูโรอาจไม่น่าสนใจมากพอ และถ้าสมมติว่า John เป็ นคนทีมีเหตุผล มันคงไม่
สมเหตุสมผลนักทีจะหนีไปพร้อมกับธนบัตรของฉันโดยหวังว่าจะไม่พบหน้าฉันอีกเลย
ธุรกรรมเป็ นเพียงกระบวนการหนึง
หากเราซูมเข้าไปดูธุรกรรมในธุรกิจ เราจะพบว่ามันไม่เคยเป็ นแบบ "อะตอมมิก" แต่มนั เป็ นลําดับของสถานะทีมีความไม่
สอดคล้องกันอยู่บา้ ง ลองมาสํารวจในรายละเอียดเพิมเติม ผ่านสถานการณ์ทีแตกต่างออกไปเล็กน้อย เช่น การทีฉันนังลงและ
จ่ายเงินค่าฮอทดอกก่อนออกไป
1. ฉันหิว มีเงินอยูใ่ นกระเป๋ าสตางค์ ร้านของจอห์นเปิ ดอยู่ และกลินฮอทดอกลอยอบอวลในอากาศ รายการราคา
มองเห็นได้ชดั เจน และฉันสามารถซือฮอทดอกได้
2. ฉันทักทายจอห์น ตอนนีจอห์นรูแ้ ล้วว่าฉันอาจต้องการสังอะไรบางอย่าง เขาจะไม่เมินเฉยต่อส่วนถัดไปของ
การสนทนา
3. ฉันสังฮอทดอก 1 ชินและนําดืม 1 ขวด ตอนนีจอห์นรูแ้ ล้วว่าฉันต้องการอะไร และฉันก็รูว้ ่าจอห์นรูว้ ่าฉัน
ต้องการอะไร
4. จอห์นยืนนําดืมให้ฉนั และบอกให้ฉนั ไปหาทีนัง ตอนนีฉันมีนาดื
ํ มทียังไม่ได้จา่ ยเงิน แต่ฉนั ยังไม่ได้ฮอทดอก
5. ฉันได้ยินจอห์นตะโกนว่า "ฮอทดอก 1 ชิน!" ก่อนทีเขาจะพูดคุยกับลูกค้าคนถัดไป ฉันมันใจแล้วว่ามีคนกําลังทํา
ฮอทดอกของฉันอยู่
6. ฉันเปิ ดขวดนําและดืมเล็กน้อย นีเป็ นการกระทําทีไม่สามารถย้อนกลับได้ ฉันไม่สามารถคืนขวดนําได้แล้ว หรือ
อาจจะทําได้ แต่ฉันก็สภุ าพเกินกว่าจะลองทํา
7. ผ่านไปสองสามนาที และฉันเริมรูส้ ึกหงุดหงิด อย่ามาเล่นกับฉันเวลาฉันหิว สองนาทีก็เพียงพอสําหรับการทํา
ฮอทดอกแล้ว
8. ฮอทดอกของฉันทําเสร็จแล้ว แต่ฉนั ไม่สามารถมองเห็นมันจากโต๊ะของฉัน แม้ว่าฉันจะมองไปทางจอห์นด้วย
ความกระวนกระวายก็ตามนีเป็ นสถานการณ์ทีไม่ดีเอามาก ๆ เพราะทุกวินาทีทีเสียไปจะทําให้ฮอทดอกเย็นลง
(ลดมูลค่าลง) และทําให้ฉนั หงุดหงิดมากขึน การทําให้ฉนั รอนานแล้วเสิรฟ์ ฮอทดอกเย็นเป็ นกลยุทธ์ทีแย่มาก
9. ฉันได้ยินชือของฉันถูกเรียก ตอนนีฉันรูแ้ ล้วว่าฉันจะได้รบั ฮอทดอกของฉัน
ข้อผิดพลาดของการทําธุรกรรม
มีความสมําเสมอมากกว่าทีเห็นได้ชดั
เป้าหมายของบทนี
• มองความสมําเสมอจากมุมมองทีแตกต่าง
• ออกแบบกระบวนการทีมีความแข็งแกร่งมากขึนและยังคงใช้งานง่าย
• เพิมความแม่นยําในกระบวนการสร้างแบบจําลอง
การสร้างแบบจําลองระบบซอฟต์แวร์
18 การจัดทํา EventStorming ระดับการออกแบบ
ขอบเขตทีแตกต่างกัน
การประชุมเชิงปฏิบตั ิการ Big Picture มุ่งเน้นไม่ให้จาํ กัดกรอบ แต่เปิ ดรับความซับซ้อนทังหมดและเพิมพูนการเรียนรูใ้ ห้
ได้มากทีสุด ตอนนีจุดเริมต้นแตกต่างออกไป:
เราสามารถสมมติว่าเรามีความเข้าใจร่วมกันทีดีขึนเกียวกับโดเมนพืนฐาน
ของซอฟต์แวร์ทีแก้ปัญหาเฉพาะด้าน
ทีนีเราจะมุ่งเน้นไปทีการพัฒนาคุณสมบัติ
ผูเ้ ข้าร่วมทีแตกต่างกัน
ในระหว่างการประชุมเชิงปฏิบตั กิ าร Big Picture เป็ นเรืองปกติทีจะมีผเู้ ข้าร่วมจํานวนมากจากฝ่ ายธุรกิจ (รูปแบบนี
เหมาะสมแม้ในกรณีทีไม่มีการวางแผนกิจกรรมพัฒนาซอฟต์แวร์)
ผลลัพธ์ทีแตกต่างกัน
ความรูห้ รือการเรียนรูค้ ือผลลัพธ์ทีมีค่ามากทีสุดของ EventStorming แบบ Big Picture นอกจากนี เรายังพบว่าเวลาเป็ น
ข้อจํากัดทีใหญ่ทีสุด ดังนันจึงมีความเสียงทีทราบกันดีว่าจะหมดเวลาก่อนทีจะเสร็จสิน ไม่วา่ จะนิยามคําว่า “เสร็จสิน” ไว้
อย่างไรก็ตาม แต่ก็ไม่เป็ นไร: เราไม่ได้สนใจทุกจุดทีสําคัญ เพียงแค่จดุ ทีสําคัญทีสุด จุดทีคุม้ ค่าต่อการลงทุนทังเวลาและเงินเพือ
หาทางแก้ไข
สําหรับกรณีนี เรากําลังพยายามหาหนึงหรือหลายทางแก้ไขสําหรับปั ญหาทีคุม้ ค่าทีจะแก้ไข ซึงหมายความว่าการ
ประชุมเชิงปฏิบตั ิการจะยังไม่จบจนกว่าเราจะได้สิงทีดูเหมือนเป็ นตัวเลือกทีแข็งแกร่งสําหรับการแก้ปัญหา
เราจะทําอะไรกับ Big Picture Artifact?
• มันมีพจนานุกรมของเหตุการณ์ในโดเมนทีเพียงพอ
• มันแสดงให้เห็นปั ญหาทีเราพยายามจะแก้ไข โดยปกติจะแสดงเป็นจุดสําคัญ (hot spot)
• มันแสดงระดับความเข้าใจปัจจุบนั เกียวกับบริบทภายนอกทีเรากําลังทํางานอยู่
เริมต้นใหม่จากศูนย์
นีเป็ นตัวเลือกทีชัดเจนทีสุด หมายความว่าเรามีโอกาสทีจะเพิมพืนทีหรือขยายการสํารวจเพิมเติม
ทํางานบนโมเดลทีมีอยู่เดิม
กรณีใดทีวิธีนีเหมาะสมทีสุด?
การสร้างแบบจําลองกระบวนการและการเพิมแนวคิดใหม่ลงบน Artifact เดิมทํางานได้ดีในกรณีของกลุ่มขนาดเล็ก
และ/หรือเมือคุณมีโอกาสจัดการประชุมเชิงปฏิบตั ิการแบบเต็มวัน (หรือมากกว่าหนึงวัน) ในสถานการณ์เช่นนี ความทรง
จําจากการสํารวจ Big Picture ยังคงชัดเจน ดังนันจึงไม่จาํ เป็ นต้องทบทวนหรือมองย้อนกลับไปยัง Big Picture ในฐานะ
ข้อมูลอ้างอิง โปรดจําไว้ว่า: Big Picture เป็ นโมเดลทีสะท้อนระดับความเข้าใจปัจจุบนั ของเรา เมือเราขุดลึกลงไปใน
ปฏิสมั พันธ์ทีสําคัญ เราก็กาํ ลังทําให้โมเดลนันล้าสมัยไปโดยปริยาย
เหตุการณ์มาจากไหน?
ในระบบธุรกิจ แหล่งทีมาหลัก 4 แหล่งของเหตุการณ์ในโดเมน ได้แก่:
•
•
•
•
การกระทําของผูใ้ ช้
ระบบภายนอก
เวลา
เหตุการณ์ในโดเมนอืน (ผ่านรูปแบบของปฏิกิรยิ าอัตโนมัติบางอย่าง)
มาพิจารณาสถานการณ์ทีแตกต่างกันในรายละเอียด
การกระทําของผูใ้ ช้
เหตุการณ์ "การซือตัว" (Ticket Purchased) อาจเป็ นผลโดยตรงจากการกระทํา "ซือตัว" (Buy Ticket) ซึงดําเนินการโดย
นักแสดงทีเป็ นลูกค้า (Customer actor)
ทําไมเราไม่สามารถใช้ชือของ UML ได้?
ผูอ้ ่านบางคนอาจรูส้ กึ ผิดหวังกับความไม่แม่นยําของฉันเมือพูดถึงการกําหนดแนวคิดสําคัญใน EventStorming นันเป็ น
เพราะสิงนีตังใจทําให้ไม่แม่นยํา: ฉันเคยทํางานกับ UML และเครืองมือกรณีศกึ ษา (case tools) มาเยอะในอดีต และฉัน
ก็เคยสอน UML ด้วย
ค้นหา Aggregates
เลือนการตังชือออกไปก่อน
หนึงในเคล็ดลับทีน่าสนใจทีสุดคือการพยายามเลือนการตังชือ Aggregate (หรือโพสต์อิทสีเหลืองขนาดใหญ่ ซึงฉันก็
พยายามเลือนการตังชือด้วยเช่นกัน) การเลือนนีไม่ใช่เรืองง่าย เพราะในขณะนันทุกคนมักคิดว่าพวกเขามีชือทีเหมาะสม
สําหรับมันอยู่แล้ว และนิสยั ของการตังชือสิงต่าง ๆ ก็แข็งแกร่งเกินไป ลองทําในวิธีทีตรงกันข้าม: มองหาความรับผิดชอบ
ก่อน: โพสต์อิทสีเหลืองนีมีหน้าทีรับผิดชอบอะไร? ระบบคาดหวังอะไรจากมัน? มองหาข้อมูลทีจําเป็ น: ข้อมูลอะไรที
จําเป็ นในการทําให้ความรับผิดชอบนีสําเร็จลุล่วง? เมือสิงเหล่านีชัดเจนแล้ว ให้ถามตัวเองว่า: "ฉันจะตังชือคลาสทีมี
ข้อมูลและวัตถุประสงค์เหล่านีว่าอะไร?" ปั ญหาของฉันกับ UML ก็คือมันไม่ได้ชว่ ยสร้างการสนทนาทีเหมาะสมขึนมาได้
เลย ในความเป็ นจริง การใช้ UML ทําให้โอกาสทีจะเกิดการสนทนาทีสําคัญลดลงอย่างมาก และนีคือเหตุผลหลักทีเรา
เริมใช้การเขียนเชิงสัญลักษณ์แบบเพิมทีละน้อย (Incremental Notation) ในระหว่างการประชุมเชิงปฏิบตั ิการ
(workshops)
เราจะรูไ้ ด้อย่างไรว่ามันจบแล้ว?
เมือถูกแปลงให้อยู่ในรูปแบบแบนราบ นีคือสิงทีเราคาดหวังให้เกิดขึนในกระบวนการทีสมําเสมอ.
เป้าหมายของบทนี
• กลไกของการทํา EventStorming ในระดับการออกแบบ
• การสร้างความสมําเสมออย่างก้าวหน้า
• กระบวนการเพือหลีกเลียงการหลงทางในความยุ่งเหยิง
19 ภาพทีอธิบายทุกอย่าง
ภาพหนึงภาพมีคา่ มากกว่าคําพูดนับพันคํา และภาพนีอาจมีค่ามากกว่านันอีกเล็กน้อย
ภาพทีอธิบายทุกอย่าง
เรากลับมาอีกครังกับภาพทีกล้าหาญนี ซึงอธิบายทุกอย่างด้วยความงดงามทังหมดของมัน.
เมือถูกทําให้อยู่ในรูปแบบแบนราบ นีคือสิงทีเราคาดหวังในกระบวนการทีมีความต่อเนืองสมําเสมอ.
20 ตัวขัดขวาง 3 ประเภท
การตัดสินใจของผูใ้ ช้
ร่างภาพของรูปแบบทีเกิดซํากันบ่อยทีสุด
ช่วยการตัดสินใจของผูใ้ ช้
UI ทีเกิดจากงานทีปรากฏขึน
การกระตุน้ พวกเขา
กระบวนการและนโยบาย
เกิดอะไรขึนกับ Aggregates?
เป้าหมายของบทนี:
• วิธีคิดทีแตกต่างทีนํามาใช้
• เมือ Read Model มีความสําคัญ
• ลืม CRUD ไปตลอดกาล
21 เคล็ดลับการสร้างโมเดลในระดับการออกแบบ
สิงทีเกิดขึนใน EventStorming ระดับการออกแบบนันแตกต่างอย่างมากจากการค้นพบขนาดใหญ่ในลักษณะของเวิรก์ ช็
อป Big Picture แม้ว่าหลายหลักการจะเหมือนกัน แต่ทีนีเรากําลังพยายามออกแบบทางแก้ปัญหาอย่างร่วมมือกัน
พลวัตในกระบวนการจะแตกต่างออกไป: ในแง่ของ GameStorming ตอนนีเราอยูใ่ นช่วงของการบรรจบกันมากขึน เรา
ยังคงเปิ ดกว้างต่อการค้นพบใหม่ ๆ แต่เราจะต้องตกลงกันในทางแก้ปัญหาทีเป็ นไปได้
สิงนีจะเป็ นเรืองยาก:
เซสชันการออกแบบทีเกียวข้องกับสถาปนิกซอฟต์แวร์และนักพัฒนาระดับอาวุโสสามารถ
กลายเป็ นสนามรบได้งา่ ย ๆ การเลือกทางแก้ปัญหาสามารถเปลียนเป็ นการแข่งขันเพือแย่งชิงความเป็ นผูน้ าํ ได้อย่างรวดเร็ว:
ทําให้ตวั เลือกทีเป็ นไปได้ชดั เจน
ฉันไม่สญ
ั ญาปาฏิหาริย:์ ไม่มีการรับประกันว่าคุณจะตกลงในทางแก้ปัญหาได้เมือจบเซสชัน แต่ฉนั รับรองได้ว่าคุณจะไม่
สามารถตกลงกันได้ก่อนทีจะสร้างโมเดล
เมือใดก็ตามทีคุณติดอยู่ใน "สงครามความเชือ" [FIXME: Finish]
เลือกภายหลัง
เริมจากปั ญหา
หลังจากกระบวนการวุ่นวายในขนาดใหญ่...
เขียนใหม่ แล้วเขียนใหม่อีกครัง แล้วก็เขียนใหม่อกี ครัง
ยิงคุณเจาะลึกลงไปในกระบวนการของคุณมากเท่าไร
คุณก็ยิงรูส้ กึ ถึงความจําเป็ นในการปรับเปลียนคําพูดของ
เหตุการณ์ (Events) และคําสัง (Commands) ของคุณมากขึนเท่านัน
สิงนีอาจดูเหมือนเป็ นการเสียเวลา แต่จาํ ไว้สองสิงนี:
1. นียังไม่ใช่ซอฟต์แวร์จริง ความผิดพลาดจากการคิดว่าต้นทุนทีจมไปแล้ว (Sunken Cost Fallacy) อาจยังคงอยู่
ในสมองของเรา แต่ตอนนีเราแค่ใช้โพสต์อิท หากเราอยู่ในโหมดทีมีวสั ดุไม่จาํ กัด สิงนีไม่ควรเป็ นปัญหา
2. เมือถูกใช้งานในระบบจริง เหตุการณ์ในโดเมน (Domain Events) มีตน้ ทุนการอัปเดตทีน่ารําคาญมาก
เนืองจากมีผฟู้ ั งทีอาจเกิดขึนจํานวนมาก การเปลียนชือเหตุการณ์ในโดเมนเพือเพิมความแม่นยํา อาจทําให้
ส่วนประกอบซอฟต์แวร์อืน ๆ หลายตัวต้องถูกอัปเดตไปด้วย ดังทีผูป้ ฏิบตั ิ Domain-Driven Design ทุกคนรูด้ ี
การตังชือนันเป็ นปัญหาทีซับซ้อนมาก ดังนันการจัดการกับปัญหาเหล่านีล่วงหน้าในขณะทีโมเดลยังเป็ นแค่
กระดาษ อาจเป็ นความคิดทีดี
ดังนัน... เตรียมพร้อมทีจะเขียนโพสต์อิทใหม่ซาแล้
ํ วซําเล่าเหมือนไม่มีวนั พรุง่ นี
ซ่อนความซับซ้อนทีไม่จาํ เป็ น
หลังจากแก้ปัญหาทียุ่งยากแล้ว ทางแก้มกั จะดูซบั ซ้อนกว่าทีเราเข้าใจในตอนแรก การสํารวจของเรานําไปสู่ความเข้าใจ
ทีลึกซึงยิงขึน และค้นพบว่าโมเดลพืนฐานซับซ้อนกว่าทีเราคาดไว้
อย่างไรก็ตาม สิงนีไม่ได้หมายความว่าโมเดลทีมองเห็นได้จะต้องสะท้อนถึงความซับซ้อนทีอยูเ่ บืองหลัง
ผูอ้ อกแบบระบบ เรามีโอกาสทีจะสํารวจลึกลงไป แต่ผใู้ ช้ทวไปไม่
ั
ได้มีโอกาสนี
ในฐานะ
แทนทีจะเปิ ดเผยความซับซ้อนนีต่อผูใ้ ช้ เราอาจหาวิธีทีจะทําให้มนั ดูเรียบง่ายจากภายนอก [FIXME: finish this one]
เหตุการณ์ (Events) อาจไม่สมบูรณ์แบบ แต่…
หากคุณกําลังนําเวิรก์ ช็อป EventStorming ไปสู่ขนตอนสุ
ั
ดท้ายของการพัฒนาซอฟต์แวร์แบบ Event-Driven คุณอาจ
ทราบแล้วว่าการเปลียนแปลงลายเซ็นของเหตุการณ์ในโดเมน (Domain Events Signature) อาจมีผลกระทบแบบลูกโซ่
สูง โดยเฉพาะอย่างยิงหากคุณเปลียนชือสิงต่าง ๆ และมีผสู้ มัครสมาชิก (Subscribers) หลายคน
ความสมมาตรอาจไม่ใช่เพือนของคุณเสมอไป
ในระหว่างรอบแรกของการจับคูค่ าํ สัง (Commands) กับเหตุการณ์ (Events)
เหตุการณ์ภายในและภายนอก
เลือนการตังชือ Aggregates ออกไปก่อน
22 ส่วนประกอบสําคัญ
ทําไม Domain Events ถึงมีความพิเศษ?
Domain Events เข้าใจง่าย
ฉันเคยเห็นการประชุมทีไม่ก่อให้เกิดผลมากมาย ซึงนักพัฒนาพยายามใช้เวลาอธิบายความหมายของแผนผัง UML ของ
ตัวเอง ในขณะทีผูเ้ ข้าร่วมประชุมคนอืน ๆ กลับไม่สนใจ และไม่สามารถให้ขอ้ เสนอแนะทีเกียวข้องต่อเซสชันการสร้างโมเดลใน
ปั จจุบนั ได้
แต่ทีสําคัญยิงกว่านัน... ฉันไม่เคยเห็นการประชุมแบบนันอีกเลย การประชุมทีดูเหมือนว่าจะเน้นการทํางานร่วมกัน
เหล่านันค่อย ๆ หายไป เพราะไม่มกี ารร่วมมือกันอย่างแท้จริง และเวลาของผูม้ ีส่วนได้สว่ นเสียก็ไม่ถกู ใช้อย่างเกิดประโยชน์
หลักการสําคัญของ EventStorming คือการเพิมการมีส่วนร่วมของผูเ้ ข้าร่วมทุกคนให้มากทีสุด [FIXME: ฉันควรระบุ
หลักการนีให้ชดั เจนไหม? หรือควรรวมสิงนีไว้ดว้ ยหรือเปล่า?] Domain Events ทํางานได้ดีเมือเทียบกับเทคนิคทีเป็ นทางการอืน
ๆ ซึงมักมีอปุ สรรคสูงกว่าทีจะเริมการสนทนา
ในความเป็ นจริง การเริมต้นเวิรก์ ช็อป EventStorming ไม่จาํ เป็ นต้องมีประสบการณ์ล่วงหน้าสําหรับผูเ้ ข้าร่วมส่วนใหญ่
แต่เรายังคงสามารถทําให้มนั ทํางานได้ดีมาก ความลับคืออะไร? Domain Events นันดูเหมือนง่ายอย่างหลอกลวง: เป็ นเพียงสิง
สําคัญทีเกิดขึนในธุรกิจของเรา เขียนลงบนโพสต์อิทสีสม้ พร้อมคํากริยาในรูปอดีตกาล แม้ว่าผูเ้ ข้าร่วมเวิรก์ ช็อปจะไม่เคยมี
ประสบการณ์ในการสร้างโมเดลมาก่อน พวกเขาจะตระหนักได้อย่างรวดเร็วว่าสิงนีง่ายพอทีพวกเขาจะมีส่วนร่วมได้
ในความเป็ นจริง ฉันมองหาคําจํากัดความทีสามารถนําไปปฏิบตั ิได้ทนั ที หลังจากทีมีการเขียนโพสต์อิทใบแรกในช่วง
Ice Breaker เราจะได้เห็นในภายหลังว่า Domain Events จะช่วยเพิมความแม่นยําให้กบั โมเดลของเราได้อย่างไร แต่เราต้องจํา
ไว้ว่าการเพิมความแม่นยําตังแต่เนิน ๆ อาจไม่ใช่ความคิดทีดี [FIXME: เพิมรายละเอียดในส่วนนีภายหลัง]
ไม่จาํ เป็ นต้องมีประสบการณ์มาก่อน
ต่างจากเทคนิคการสร้างโมเดลแบบดังเดิมทียึดติดกับรูปแบบสัญลักษณ์เฉพาะ (ไม่ว่าจะเป็ น UML, BPMN, E-R
diagrams หรือรูปแบบโปรดของคุณ) ใน EventStorming เราไม่ได้ม่งุ เน้นการใช้สญ
ั ลักษณ์ทกํี าหนดไว้ล่วงหน้าใด ๆ รูปแบบ
การเขียนทีใช้งานจริงจะถูกกําหนดร่วมกันแบบเรียลไทม์ โดยเพิมทีละองค์ประกอบ
นีคือวิธีทเรารั
ี กษาการมีส่วนร่วมของผูเ้ ข้าร่วมในบทสนทนา: การใช้รูปแบบทีเรียบง่ายทีสุดเท่าทีจะเป็ นไปได้ จะช่วยให้
ทุกคนในห้องมีส่วนร่วมได้อย่างกระตือรือร้น ในทุกเวิรก์ ช็อป จะมีใครบางคนทีไม่เคยเข้าร่วม EventStorming มาก่อน และคน
เหล่านันมักจะนําเสนอสิงทีน่าสนใจทีสุดเข้ามา สิงสําคัญคือหน้าทีของเราคือต้องทําให้มนใจว่
ั าไม่มสี ิงใดเป็ นอุปสรรค
ยินดีรบั ฟั งทุกความคิดเห็น!
EventStorming เป็ นกระบวนการเรียนรูร้ ว่ มกัน เราไม่รูว้ ่าใครคือผูท้ ีมีขอ้ มูลทีถูกต้องทีสุด และทีจริงแล้ว เรารูว้ ่าคงไม่มี
ใครมีความจริงทังหมด สิงทีเราทําได้คือเปิ ดพืนทีให้ความคิดเห็นทีหลากหลาย
เราจะทําให้มนั ง่ายกว่านีได้ไหม?
คําว่า "Domain Event" อาจเข้าถึงผูฟ้ ังกลุ่มหนึงได้ดี คํานีมีทีมาจากชุมชน Domain-Driven Design ซึง Greg Young
และ Eric Evans ได้นาํ รูปแบบนีทีเดิมได้รบั การ formalized โดย Martin Fowler มาเผยแพร่จนเป็นทีรูจ้ กั
จะทําอย่างไรถ้า Domain Events ไม่เข้ากับผูฟ้ ั งของฉัน?
แม้วา่ Domain Events จะดูเหมือนเป็ นแนวคิดทีเรียบง่าย แต่บางครังมันก็อาจไม่ตรงกับความเข้าใจหรือไม่เข้าถึงบาง
กลุ่มผูฟ้ ังได้ ในบางกรณี สาเหตุนีเกิดจากคําว่า Domain Event อาจฟั งดูเหมือนคําศัพท์ทางเทคนิค ทําให้ผทู้ ีไม่
เชียวชาญด้านเทคนิคเกิดความรูส้ ึกตังรับหรือระแวดระวัง
เป็ นหน้าทีของผูด้ าํ เนินการ (Facilitator) ทีจะช่วยให้ทกุ คนสามารถมีส่วนร่วมได้: หากการยึดติดกับคําว่า Domain
Event กลายเป็ นปั ญหา ให้ลองเปลียนไปใช้คาํ ว่า Fact หรือ Thing that happened แทน การตกลงในความหมายที
ชัดเจนของโพสต์อิทสีสม้ ในช่วงแรกอาจไม่สาํ คัญ (แต่อาจมีผเู้ ชียวชาญด้านเทคนิคในห้องทีให้ความสําคัญกับเรืองนี
มาก) โปรดจําไว้วา่ ช่วงนาทีแรก ๆ ของเวิรก์ ช็อปนัน การมีส่วนร่วมสําคัญกว่าความแม่นยํามาก
อย่างไรก็ตาม การแสดงตัวอย่างสด ๆ มีประโยชน์มากกว่าการหาคําทีเหมาะสม ถ้าผูฟ้ ังยังไม่เข้าใจ คนทีเขียนโพสต์อิท
ใบแรกและติดมันบนผนังจะกลายเป็ นพันธมิตรทีดีทีสุดของคุณ
เหตุการณ์ (Events) มีความแม่นยํา
ความสําคัญของคํากริยา
ในชีวติ การทํางานของฉัน ประโยคทีมีคุณค่าต่อจํานวนตัวอักษรสูงทีสุดน่าจะมาจากคําพูดของ Greg Young:
“ใช้คาํ กริยาในรูปอดีตกาล”
ไม่มกี ารจํากัดขอบเขตโดยนัย
เหตุการณ์ (Events) คือข้อเท็จจริงทีเกิดขึนในโดเมน โดยไม่มีตวั กรองแหล่งทีมาอย่างชัดเจน: ในความเป็ นจริง
เหตุการณ์อาจเกิดขึนได้จากหลายสาเหตุ:
•
•
•
•
สิงเหล่านีอาจเป็ นผลมาจากการกระทําทีผูใ้ ช้เริมต้นขึน
สิงเหล่านีอาจมาจากระบบภายนอก
สิงเหล่านีอาจเป็ นผลจากการทีเวลาผ่านไป
สิงเหล่านีอาจเป็ นผลโดยตรงจากเหตุการณ์อืน
เหตุการณ์โดเมน (Domain Events) มาจากทีใด? มีคาํ ตอบทีเป็ นไปได้ 4 แบบ
ในทางปฏิบตั ิ หมายความว่าเราไม่ได้ม่งุ เน้นเฉพาะการโต้ตอบของผูใ้ ช้เท่านัน — เช่นเดียวกับทีเกิดขึนเมือมุ่งเน้นไปที
คําสัง (Commands) หรือการกระทําของผูใ้ ช้ (User Actions) — แต่เรามุ่งเน้นไปทีทังระบบแทน
การเลือกเหตุการณ์โดเมน (Domain Events) เป็ นจุดเริมต้นช่วยให้เราขจัดจุดบอด (Blind Spot) ออกไป
เหตุการณ์โดเมนในฐานะการเปลียนแปลงสถานะ
การใช้คาํ กริยาในรูปอดีตกาล (Past Tense) บังคับให้เราสํารวจโดเมนทังหมดโดยเน้นไปทีการเปลียนแปลงสถานะ
(State Transitions) ซึงหมายถึงช่วงเวลาทีบางสิงเปลียนแปลงไปอย่างชัดเจน วิธีนีอาจให้ความหมายเชิงเหตุผล (Semantic) ที
แตกต่างออกไปในเชิงรูปแบบอย่างเป็ นทางการ
ลองจินตนาการว่าเรากําลังรวบรวมข้อมูลอุณหภูมจิ ากระบบภายนอก เหตุการณ์โดเมน (DomainEvent) ทีอาจเป็ น
ตัวเลือกแรกคือ "อุณหภูมสิ งู ขึน" (Temperature Raised) แต่เมือพิจารณาอย่างละเอียด เราอาจพบว่าสิงนีไม่ได้สะท้อนสิงที
เกิดขึนอย่างถูกต้องจริงๆ เพราะแท้จริงแล้วเราอาจต้องมีการผสมผสานระหว่างเหตุการณ์ "อุณหภูมิถูกบันทึก" (Temperature
Registered) จากแหล่งข้อมูลภายนอก และการเพิมขึนของอุณหภูมิ (Temperature Increment) ทีถูกวัดผลเป็ นผลสืบเนือง สิง
นีทําให้เราเข้าใจว่า แม้การเขียนในขันต้นจะถูกต้อง แต่แท้จริงแล้วมันอาจใกล้เคียงกับ "บทสนทนาเรืองสภาพอากาศ" มากกว่า
การออกแบบระบบจริง
เพือบอกเล่าเรืองราวทังหมด สิงนีไม่ได้หมายความว่าการเขียนครังแรกผิดแต่อย่างใด มันถือว่าเหมาะสมดี โดยเฉพาะ
อย่างยิงถ้ามันช่วยกระตุน้ การคิดเชิงลึกเพิมเติม โปรดอย่าพยายามทําให้มนั แม่นยําเกินไปตังแต่เริมต้น (ดูเพิมเติมในหัวข้อ
"ยอมรับความคลุมเครือ" (Embrace Fuzziness) ในส่วนของรูปแบบแนวทาง)
ถ้าภาษาของฉันไม่มีรูปกริยาในอดีตกาลล่ะ?
เพือนร่วมงานคนหนึง [FIXME: ใส่ชอที
ื ต้องการ] ทําให้ฉนั สังเกตเห็นว่าข้อกําหนดทีดูเหมือนเล็กน้อยเกียวกับการใช้
คํากริยาในรูปอดีตกาล อาจเป็ นเรืองยุ่งยากทีจะนําไปใช้ในบางภาษา ตัวอย่างเช่น ภาษาจีนกลาง (Mandarin Chinese)
ไม่มีรูปกริยาในอดีตกาล
ุ ตรวจสอบให้แน่ใจว่า...
ในกรณีนี ฉันไม่สามารถชีไปทีวิธีแก้ปัญหาเฉพาะเจาะจงได้ แต่คาํ แนะนําของฉันคือให้คณ
เหตุการณ์โดเมนเป็ นตัวกระตุน้ ให้เกิดผลลัพธ์
มองป่ าและต้นไม้
คําถามทีพบบ่อยเมืออธิบายเกียวกับเหตุการณ์โดเมน (Domain Events) คือ: “เราไม่กาํ ลังเจาะลึกเกินไปหรือ?” คนมัก
กังวลว่าการวิเคราะห์ในระดับเหตุการณ์จะพาผูค้ นหลงเข้าไปในรายละเอียดปลีกย่อยจนละเลยภาพรวมทังหมด (Big Picture)
มีบทบาทของ ผูอ้ าํ นวยความสะดวก (Facilitator) อย่างชัดเจนในทีนี ทีต้องจัดการการสนทนาทีอาจเริมแยกประเด็น
ออกไปอย่างนุม่ นวล
เหตุการณ์โดเมนพาเราไปสู่จดุ คอขวด
ถ้าคุณสนใจใน ทฤษฎีขอ้ จํากัด (Theory of Constraints), [FIXME: เติมข้อมูลทียังไม่สมบูรณ์].
แนวทางทางเลือก
เริมต้นด้วยคําสัง (Commands)
เริมต้นด้วยผูค้ น (People)
มุ่งเน้นไปทีสิงประดิษฐ์สาํ คัญ (Key Artifacts)
สรุปภาพรวมทังหมด
ลองมาสรุปเหตุผลเบืองหลังความนิยมในเหตุการณ์โดเมน (Domain Events) เผือว่ามีคนถามถึงอย่างชัดเจน:
• เข้าใจง่าย พอสําหรับทุกคนในห้องทีจะเข้าใจ
• ชัดเจนพอ ทีจะช่วยลดความกํากวมจากการสนทนาได้มาก
• มีความหมาย โดยธรรมชาติ ถ้าไม่มีใครสนใจสิงใด เช่น กระดาษโน้ตทีแปะไว้ อาจเป็ นไปได้วา่ สิงนันไม่
สําคัญต่อระบบของคุณ
• แสดงถึงการเปลียนแปลงสถานะ (State Transitions) ทีสามารถเชือมโยงกับตรรกะเชิงปฏิกิรยิ า (Reactive
Logic) ได้
• พวกมันสามารถชีให้เราเห็นถึงจุดคอขวด (Bottleneck) ของกระบวนการปัจจุบนั ซึงอาจเป็ นปัญหาทีสําคัญ
ทีสุดทีควรแก้ไข
• พวกมันสามารถรองรับการเล่าเรืองและเทคนิคการสร้างแบบจําลองทีหลากหลาย การสนทนาจากพืนฐานที
แตกต่างกันมากสามารถเริมต้นขึนได้จากโมเดลเดียวกัน
คําสัง - การกระทํา - การตัดสินใจ
กระดาษโน้ตสีฟ้าเป็ นส่วนสําคัญสําหรับการโต้ตอบของผูใ้ ช้ พวกมันเป็ นผลลัพธ์จากการตัดสินใจของผูใ้ ช้ (ซึงอาจต้อง
ใช้ความคิดทีซับซ้อน) และเป็ นตัวกระตุน้ ให้เกิดการคํานวณในอีกฝั งหนึง
หากคุณมุ่งเน้นไปทีพฤติกรรมของมนุษย์ คุณอาจมองว่ากระดาษโน้ตสีฟ้าเป็ นการกระทําบางอย่างทีผูใ้ ช้กาํ ลังทํา เช่น
การลงทะเบียนในระบบหรือการสังซือสินค้า หากคุณมุง่ เน้นไปทีการนําระบบไปใช้งาน กระดาษโน้ตสีฟ้าอาจแสดงถึงคําสัง
(Command) ทีระบบของคุณได้รบั และต้องดําเนินการให้สาํ เร็จ
ความไม่ชดั เจนในการนิยามความหมายทีแน่นอนของกระดาษโน้ตสีฟ้าอาจทําให้คณ
ุ ผิดหวังได้ แต่ในบางกรณี ความ
คลุมเครือนีสามารถช่วยให้เกิดความยืดหยุ่นในการออกแบบ
เป้าหมายของบทนี:
• ข้อดีและข้อเสียของการเลือกเหตุการณ์โดเมน (Domain Events) เป็ นองค์ประกอบหลัก
• ศักยภาพของความแม่นยํา
• การใช้เหตุการณ์โดเมนเพือสร้างแบบจําลองความก้าวหน้าของคุณในรูปแบบ Lean-Agile
23 รูปแบบการสร้างแบบจําลองสี (Color Modeling Patterns)
นโยบาย (Policies)
โครงสร้างพืนฐาน
นโยบาย (Policy) แสดงด้วยกระดาษโน้ตสีมว่ งอ่อน (Lilac) ซึงวางอยู่ระหว่างเหตุการณ์ (Event) สีสม้ และคําสัง
(Command) สีนาเงิ
ํ น
นโยบายใช้ในการจับตรรกะเชิงปฏิกิรยิ า (Reactive Logic) ของกระบวนการของเรา โดยสามารถแสดงออกเป็ นคําพูดได้
ดังนี:
ทุกครังที [เหตุการณ์(หลายเหตุการณ์)] ให้ [คําสัง(หลายคําสัง)]
คําว่า 'ทุกครังที' (Whenever) เป็ นคําสําคัญ (Keyword) ซึงช่วยให้เราชีชัดถึงปฏิกิรยิ าของระบบทีคาดหวังได้ ทุกครังทีมี
เหตุการณ์หนึงหรือชุดของเหตุการณ์เกิดขึน
จากนโยบาย (Policies) สู่การนําไปใช้งาน (Implementation)
เรามองหานโยบาย (Policies) ในฐานะกาวเชือมทีขาดหายไประหว่างเหตุการณ์โดเมน (Domain Event) และคําสัง
(Command) ทีตามมา หรือกล่าวอีกอย่างคือ "จะต้องมีกระดาษโน้ตสีม่วงอ่อนอยู่ระหว่างกระดาษสีสม้ และสีนาเงิ
ํ น"
อย่างไรก็ตาม ไม่ใช่วา่ นโยบายทุกอย่างจะถูกเขียนเป็ นซอฟต์แวร์เสมอไป ในทางปฏิบตั ิ กระดาษโน้ตสีม่วงอ่อนสามารถ
สะท้อนการนําไปใช้ทีหลากหลาย ตังแต่นิสยั ทีเป็ นทียอมรับของพนักงานในองค์กร ไปจนถึงการนํากระบวนการซอฟต์แวร์แบบ
กระจายตัว (Distributed Software Processes) ทีซับซ้อนมาใช้งาน
สิงทีเราต้องมองหาในทุกกรณียงั คงเหมือนเดิม: ปฏิกิรยิ าทีสามารถทําซําได้ต่อเหตุการณ์ทีกําหนด
กิจวัตรทีไม่ได้เขียนเป็ นระบบ (Uncodified Routine)
ในบริษัทขนาดเล็ก การนํา นโยบาย (Policy) ไปใช้งานอย่างง่ายทีสุดอาจเป็ นเพียงกิจวัตรประจําวันของบุคคลคนเดียว
เมือตรวจสอบนโยบายเหล่านี เรากําลังเปิ ดเผยวิธีการทํางานตามปกติของพวกเขา
ผูเ้ ชียวชาญทีเกียวข้องอาจรูส้ กึ สนุกทีมีโอกาสอธิบายงานของตัวเอง หรืออาจไม่พอใจเลยก็ได้ เพราะรูส้ กึ เหมือนถูก "ลํา
แดน" ความรูส้ กึ นีเป็ นสิงปกติเมือเราพยายามทําความเข้าใจว่าสิงต่างๆ กําลังดําเนินไปอย่างไร
บางครังไม่มีคนคนเดียวทีทําตามนโยบาย แต่มีหลายคนทีนํามันไปใช้ในวิธีทีแตกต่างกัน และทีจริงแล้ว อาจไม่มใี คร
เรียกมันว่า "นโยบาย" เลย แค่คิดว่า "นีคือสิงทีเราทําอยู่" แต่ทนั ทีทคุี ณถามคําถามว่า "เกิดอะไรขึนเมือเหตุการณ์นีเกิดขึน?" แล้ว
ได้คาํ ตอบสองแบบ คุณจะรูว้ ่าการสืบสวนของคุณนันคุม้ ค่า
ตัวอย่างหนึง: ขณะทีจัดการประชุม ฉันและผูจ้ ดั ร่วมคนอืนๆ ไม่ได้ตกลงกันในนโยบายส่วนลดอย่างชัดเจน หลังจากนัน
ไม่นาน เราก็พบว่าลูกค้ากําลังติดต่อเราหลายคนเพือเลือกเงือนไขทีดีทีสุด
ข้อตกลงของมนุษย์ (Human Agreements)
ข้อตกลงทีชัดเจน (Explicit Agreement) มีความซับซ้อนเล็กน้อยกว่าการไม่มีขอ้ ตกลงเลย รูปแบบคําพูดทัวไปทีใช้ใน
การอธิบายคือ:
"เมือใดก็ตามที X เราต้องจําไว้วา่ ต้องทํา Y"
คําว่า "เรา" (We) เป็ นคําสําคัญในทีนี เพราะมันหมายความว่าเราคาดหวังให้เพือนร่วมงานของเราทําสิงเดียวกัน
บางครังข้อตกลงอาจง่ายเพียงแค่ "เมือใดก็ตามทีหัวหน้าบอกให้เราทําอะไร เราก็ทาํ มัน" แต่บ่อยครัง ข้อตกลงโดย
ปริยาย (Implicit Agreement) อาจซับซ้อนกว่านัน เช่น:
"ฉันจะเตือนถ้างานนันเกินความสามารถของฉัน หรือไม่สามารถเสร็จทันกําหนดเวลา และแน่นอนว่าฉันไม่ใช่ทาส ฉันจะ
ปฏิเสธงานทีขัดต่อกฎหมายหรือจริยธรรมส่วนตัวของฉัน"
ในองค์กรทีซับซ้อน การสํารวจข้อตกลงของมนุษย์ (Human Agreements) มักจะเป็ นแหล่งของความประหลาดใจอย่าง
ต่อเนือง เช่น คุณอาจพบว่าพนักงานพึงพาข้อตกลงโดยปริยาย (Implicit Agreement) ทีมีขอ้ บกพร่องและไม่สามารถใช้งานได้
จริง หรือคุณอาจค้นพบว่าไม่มขี อ้ ตกลงทีแท้จริงเลย และระบบไม่ได้แสดงพฤติกรรมทีคาดการณ์ได้
เมือความไม่สอดคล้องกันถูกเปิ ดเผยขึน มักไม่ใช่เรืองแปลกทีจะมีการแก้ไขปั ญหาแบบทันที หากคนสําคัญอยู่ในห้อง
ประชุมพร้อมข้อมูลทีจําเป็ นทังหมด ก็ไม่มเี หตุผลทีจะต้องเรียกประชุมอีกครัง เพราะคุณกําลังประชุมอยู่แล้ว
อย่างไรก็ตาม ความแปรผันในระบบทีตอบสนองต่อเหตุการณ์ทีกําหนด อาจเป็ นวิธีหนึงทีช่วยทําให้ระบบมีความ
"Antifragile" มากขึน (สามารถปรับตัวและแข็งแกร่งขึนเมือเผชิญกับความไม่แน่นอน) เป้าหมายของเราในระหว่างการสํารวจ
นโยบายคือการค้นพบ "ความจริงทีซ่อนอยู่" ไม่ใช่เพือทําให้ทกุ อย่างดูเหมือนกันไปหมด
การแสดงความชัดเจน (Being Explicit) และพูดออกมาอย่างตรงไปตรงมาจะช่วยได้มากในการตรวจจับความไม่
สอดคล้องเล็กๆ น้อยๆ
ภายใต้เรดาร์ (Below Radar)
ผลข้างเคียงทีน่าสนใจของการมองหานโยบายทีชัดเจนคือ:
ไม่ใช่ว่านโยบายทุกอย่างจะมีเรืองเซอร์ไพรส์ บางครังการมองหาความสอดคล้องของสี (เช่น "ต้องมีสีม่วงอ่อนระหว่างสี
ส้มและสีนาเงิ
ํ น") อาจเพียงแค่บงั คับให้คณ
ุ ตังชือสิงทีชัดเจนเกินกว่าจะสังเกตเห็น เช่น
"เมือใดก็ตามทีผูใ้ ช้โทรมายกเลิกการจอง ฉันก็ยกเลิกการจองให้"
หรือ "เมือใดก็ตามทีเราบอกลูกค้าว่าเราจะคืนเงินให้ เราก็ทาํ ตามนันจริงๆ"
แต่การค้นพบรายละเอียดเล็กๆ เหล่านีคือสิงทีทําให้นโยบายเข้าใจได้และสมเหตุสมผล ลองคิดดูว่าคุณเคยบอกใครว่า
"ฉันจะทําเดียวนีเลย" แต่ทนั ทีทีพูดจบ คุณกลับรับสายโทรศัพท์ททํี าให้คณ
ุ เสียสมาธิจากงานทีกําลังทํา แล้วรีบออกจากออฟฟิ ศ
เพือไปขึนรถไฟหรือไม่? บางครังนโยบายก็ไม่ได้แข็งแรงขนาดนัน
ในความเป็ นจริง เมือนโยบายง่ายจนเกินไป การหาชือทีเหมาะสมอาจยากกว่าทีคาดไว้ อย่ากังวล หากตอนนีคุณยังหา
ชือไม่ได้ ให้ใช้ตวั แทนชัวคราว (Placeholder) ไปก่อน มักจะพบว่าปฏิกิรยิ าหลายๆ อย่างเป็ นส่วนหนึงของนโยบายเดียวกัน และ
การหาชือทีเหมาะสมจะชัดเจนในภายหลังเมือคุณเชือมโยงจุดทังหมดเข้าด้วยกัน
แล้วผูใ้ ช้งานภายนอกล่ะ?
เราควรสร้างแบบจําลองพฤติกรรมของผูใ้ ช้งานภายนอก (External Users) ในลักษณะเดียวกับทีทํากับผูใ้ ช้งานภายใน
หรือไม่? ตัวอย่างเช่น ลูกค้าบางคนอาจมีนโยบายของตนเอง เช่น การซือตัวเมือมีส่วนลดพิเศษ
อย่างไรก็ตาม ในขณะทีเราสามารถมีอิทธิพลต่อผูใ้ ช้งานภายในได้บา้ ง การพยายามเปลียนพฤติกรรมของผูใ้ ช้งาน
ภายนอกเป็ นเรืองทีแตกต่างไปโดยสินเชิง ผูใ้ ช้งานภายนอกอาจมีพฤติกรรมทีคาดการณ์ได้ในระดับหนึง แต่ในกรณีที
พฤติกรรมของพวกเขาไม่คาดเดาได้ เราอาจได้เรียนรูอ้ ะไรบางอย่างทีมีประโยชน์เกียวกับพวกเขา การจับความแปรผันนี
ด้วยนโยบายทีสามารถคาดการณ์ได้อาจไม่...ยุติธรรมนัก
ในทางปฏิบตั ิ ไม่มเี ส้นแบ่งทีชัดเจนระหว่างสองสิงนี คําแนะนําง่ายๆ คือ ฉันพยายามจับข้อตกลงโดยปริยายของผูใ้ ช้งาน
ภายในผ่านนโยบาย และสํารวจผูใ้ ช้งานภายนอกด้วยการใช้ "บุคลิกจําลอง" (Personas) ทีซับซ้อนกว่า
แต่ความสนุกจริงๆ อยู่ทการค้
ี นพบ: ทุกครังทีรูปแบบการวิเคราะห์ของเราดูเหมือนจะไม่สามารถจับความซับซ้อนของ
ความเป็ นจริงทีอยูเ่ บืองหลังได้ นันคือเวลาทีคุณสามารถลองทดลองสิงใหม่ๆ ได้
EventStorming ไม่ใช่ระบบทีมีกฎตายตัว แต่เป็ นแพลตฟอร์มสําหรับการค้นพบ ดังนันคุณสามารถขยายและปรับแต่ง
มันได้ตามความต้องการ!
กฎและขันตอนทีเป็ นลายลักษณ์อกั ษร (Codified Rules and Procedures)
ในบางองค์กร อาจมีกฎหรือระเบียบปฏิบตั ิทีถูกเขียนขึนอย่างชัดเจน ซึงทุกคนจําเป็ นต้องปฏิบตั ติ าม ลองนึกถึงสิงที
เกิดขึนเมือผูป้ ่ วยเข้ามาในโรงพยาบาล ในสถานการณ์เหล่านี คุณอาจไม่ได้คน้ พบอะไรมากนัก แต่สาํ หรับนักพัฒนาแล้ว พวก
เขาอาจเรียนรูอ้ ะไรได้มากมายจากกระบวนการทีชัดเจนนี
ตรรกะเชิงปฏิกิริยาในซอฟต์แวร์ (Reactive Logic in Software)
เราควรเลือนการใช้เทคโนโลยีไปนานแค่ไหน?
ในช่วงแรกของการสร้างแบบจําลอง
ความเข้าใจหรือการสนทนาระหว่างทีม
ฉันมักพยายามหลีกเลียงการใช้คาํ ศัพท์ทางเทคนิคเพือไม่ให้สิงนีขัดขวางการทํา
คําอธิบายทีมองเห็นได้ (Visible Legend)
ไม่ว่าคุณจะใช้กลยุทธ์ใดก็ตาม สิงทีช่วยคุณได้ดีทีสุดคือการสร้างความเชือมโยงทีชัดเจนระหว่างคําจํากัดความ เช่น
"เหตุการณ์โดเมน (Domain Event) คือสิงทีสําคัญและเกิดขึนในระบบ ซึงแสดงออกด้วยกริยาในรูปอดีตกาล" กับ
ตัวอย่างทีชัดเจนในรูปของคําอธิบายทีมองเห็นได้ (Visible Legend) ในระหว่างการสร้างแบบจําลอง สีจะมีความสําคัญ
มากกว่าชือทีเราใช้เสียอีก
การเปลียนแปลงทางภาษา (Language Drift)
ในเวิรก์ ช็อป EventStorming ผูค้ นจากภูมหิ ลังทีแตกต่างกันจะมาร่วมมือกันเพือสร้างแบบจําลองกระบวนการทางธุรกิจ
หนึงหรือหลายกระบวนการ ความแตกต่างในภูมิหลังมักหมายถึงวิธีการตังชือสิงต่างๆ ทีไม่เหมือนกัน: สถาปนิกซอฟต์แวร์
(Software Architects), นักออกแบบประสบการณ์ผใู้ ช้ (User Experience Designers) และผูม้ ีส่วนได้ส่วนเสียทางธุรกิจ
(Business Stakeholders) มักจะฝึ กฝนการสร้างแบบจําลองในโรงเรียนทีต่างกันและมีลกั ษณะเฉพาะตัว
เมือคนในกลุ่มจํารูปแบบทีพวกเขาคุน้ เคยได้ พวกเขามักจะพยายามยึดติดกับคําจํากัดความทีพวกเขารูจ้ กั เช่น:
"โอเค ตกลงกันว่าจากนีไปเราจะเรียกสิงนีว่า Actors"
แต่ฉันจะไม่ทาํ แบบนัน ฉันพยายามอย่างหนักทีจะไม่ยดึ ติดกับคําจํากัดความเฉพาะหรืออคติใดๆ ยกเว้นสิงทีมองเห็นได้
ชัดเจนในปั จจุบนั การใช้สญ
ั กรณ์ทีแม่นยํา เช่น UML หรือ BPMN จะทําให้เกิดแนวคิดโดยนัย (Implicit Concepts) ทีไม่จาํ เป็ น
ในพืนหลัง ซึงอาจชัดเจนสําหรับผูเ้ ข้าร่วมบางคน แต่กลับไม่สามารถเข้าใจได้สาํ หรับคนอืน
ดังนัน ฉันจึงยึดตามคําจํากัดความทีอิงตามสี (Color-Based Definition) ซึงแสดงใน Visible Legend แทน แม้ว่ามันจะ
ไม่แม่นยําเลย แต่กง็ ่ายพอทีจะเชิญชวนให้ทกุ คนเข้าร่วมการสนทนา และช่วยให้เกิดการสือสารระหว่าง "ชนเผ่า" (Inter-Tribe
Communication) ต่างๆ ได้
ตัวอย่าง: ฉันรูว้ ่า Actor ไม่ใช่ Persona อย่างสมบูรณ์แบบ แต่ในระหว่างเวิรก์ ช็อป ฉันไม่ใส่ใจในจุดนีเลย
ดูเพิมเติม: Embrace Fuzziness
นีคือตัวช่วยเล็กๆ ทีอาจมีประโยชน์:
Business → Software Design → DDD/CQRS
สีสม้ : Fact → Domain Event
สีนาเงิ
ํ น: Decision → Action → Command
ไลแลค: นโยบาย (‘เมือใดก็ตาม’) –> ตรรกะตอบสนอง –> Listener, Process Manager (หรือ Saga)
เหลือง (รูปเล็ก): นักแสดง/ผูใ้ ช้งาน –> บุคลิกภาพ –> บทบาท
เหลือง (รูปใหญ่): ? –> ตรรกะเฉพาะที –> Aggregate
เขียว: ข้อมูลสําคัญ –> Read model
ทําไมต้องสีสม้ ?
เหตุการณ์ทถูี กกระตุน้ ตามเวลา
เป้าหมายของบท:
• ทําไมสีถึงมีพลังมาก
• เราสามารถทําอะไรได้บา้ งเพือช่วยผูท้ ีมีความบกพร่องทางการมองเห็น
• รูปแบบการให้เหตุผลทีแตกต่าง