ในแต่ละวันเราต้องตัดสินใจนับไม่ถ้วน ตั้งแต่เรื่องเล็กอย่างจะลองใช้เครื่องมือใหม่ ไปจนถึงเรื่องใหญ่อย่างจะวางสถาปัตยกรรมระบบแบบไหน

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

ช่วงนี้ผมงานของผมคือการ review กลางปีกับน้องภายในบริษัท ทำให้เห็นน้องที่ไม่กล้าตัดสินใจอยู่บ้าง เลยให้แนวคิดในการตัดสินใจเรื่องนี้ไป นั่นคือ

เฟรมเวิร์ก "ประตูทางเดียว กับ ประตูสองทาง" (One-way & Two-way Door Decisions) ที่มันจะช่วยให้เราแยกแยะ 2 อย่างนี้ออกจากกัน

แนวคิดนี้เป็นที่รู้จักในวงกว้างจากการที่ Amazon นำมาใช้ และช่วยให้ทีมสมดุลระหว่างการกล้าทดลองสิ่งใหม่ กับ การระวังความเสี่ยงในเรื่องที่เดิมพันสูง

ประตูสองแบบนี้ต่างกันตรงไหน

หัวใจของ framework นี้อยู่ที่คำเดียว คือ

ย้อนกลับได้ไหม?

ประตูทางเดียว (One way door) คือ การตัดสินใจที่ย้อนกลับได้ยาก มีผลกระทบยาวนาน และมักส่งผลต่อทิศทางของโปรเจกต์ หรือ ทั้งองค์กร

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

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

ถ้าเปรียบเทียบให้เห็นภาพ

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

ตัวอย่างของประตูทางเดียว

การตัดสินใจกลุ่มนี้มีผลผูกพันระยะยาว จึงควรใช้เวลาคิดให้คุ้ม

• การออกแบบสถาปัตยกรรม เช่น จะเลือกแบบ monolithic หรือ microservices เป็นเรื่องที่แก้ทีหลังยากและกระทบโปรเจกต์ในระยะยาว
• การเลือกภาษาโปรแกรม เป็นการตัดสินใจพื้นฐานที่ส่งผลไปถึงการรับสมัครคน ประสิทธิภาพของซอฟต์แวร์ และระบบนิเวศในการพัฒนา เช่น การเลือก Python แทน Java มีผลต่อ performance และ การ scale ของแอปพลิเคชันอย่างมาก
• การเลือกโซลูชันเก็บข้อมูล เช่น จะใช้ SQL หรือ NoSQL หรือ จะเลือกผู้ให้บริการฐานข้อมูลเจ้าไหน (MySQL, PostgreSQL, MongoDB) ล้วนมีผลระยะยาวต่อประสิทธิภาพ การ scale และความถูกต้องของข้อมูล
• การเลือกกลุ่มลูกค้าเป้าหมาย เช่น จะเปิดตัวสินค้ากับลูกค้ากลุ่มไหน หรือจะวางโมเดลหารายได้อย่างไร

ตัวอย่างของประตูสองทาง

การตัดสินใจกลุ่มนี้เอื้อต่อความคล่องตัวและการทดลอง เพราะถอยกลับได้ง่าย

• การนำเครื่องมือหรือกระบวนการใหม่มาใช้ ถ้าเครื่องมือจัดการโปรเจกต์ตัวใหม่ หรือกระบวนการรีวิวโค้ดแบบใหม่ไม่เวิร์ก ก็เปลี่ยนหรือถอยกลับได้ไม่ยาก
• การทดลองฟีเจอร์ ฟีเจอร์ใหม่ที่ซ่อนไว้หลัง feature flag ถ้าผู้ใช้ไม่ตอบรับ ก็ roll back ได้ง่าย
• การปรับ UI/UX การเปลี่ยนแปลงเล็กๆ บนหน้าจอหรือประสบการณ์ใช้งาน สามารถย้อนกลับหรือปรับต่อได้ตาม feedback และตัวเลขการใช้งานจริง
• การทำ Experiment เช่น การทดสอบฟีเจอร์แบบ A/B test หรือการลองปรับ pricing tier ที่ยกเลิกได้ถ้าไม่ได้ผล

เส้นแบ่งไม่ได้ตายตัวเสมอไป

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

ยกตัวอย่าง เช่น

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

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

ดังนั้นก่อนตัดสินใจ อย่าเพิ่งรีบจัดกลุ่ม ให้ดูขนาด และ ผลกระทบ (scale & impact) จริงเป็นเรื่องๆ ไป

สมดุลระหว่างความเสี่ยงกับผลกระทบ

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

ที่สำคัญ การตัดสินใจในงาน engineering นั้น เป็นกระบวนการที่วนซ้ำและปรับปรุงได้ตลอด การทบทวนและปรับแก้เป็นระยะจึงเป็นเรื่องจำเป็น

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

เช็กลิสต์ก่อนเดินผ่านประตู

ครั้งหน้าที่ต้องตัดสินใจ ลองหยุดถามตัวเองสักครู่ว่ากำลังจะเดินผ่านประตูบานไหน

ชุดคำถามด้านล่างช่วยนำทางไปสู่คำตอบได้

ผลกระทบและขอบเขต

• การตัดสินใจนี้มีผลกระทบระยะยาวแค่ไหน
• จะกระทบคน ระบบ หรือแผนกจำนวนเท่าไหร่
• มันจะเปลี่ยนกลยุทธ์ สถาปัตยกรรม หรือทิศทางของสินค้าหรือไม่
• มันล็อกเราไว้กับเทคโนโลยี เครื่องมือ หรือ vendor เจ้าใดเจ้าหนึ่งหรือเปล่า

ความสามารถในการย้อนกลับ

• การถอยกลับจะยากหรือแพงแค่ไหน
• ต้องทำอะไรบ้างถึงจะย้อนการตัดสินใจนี้ได้
• ถ้าต้องถอย เราจะเสียเวลาไปเท่าไหร่
• กระบวนการ เครื่องมือ หรือฟีเจอร์นั้น roll back ได้ง่ายไหม

ความเสี่ยงและความไม่แน่นอน

• ถ้าตัดสินใจผิด ความเสี่ยง คือ อะไร
• การตัดสินใจนี้ตั้งอยู่บนความไม่แน่นอนหรือสมมติฐานที่ยังไม่ผ่านการทดสอบหรือเปล่า
• เราลองทดสอบในสเกลเล็ก ๆ ก่อนได้ไหม

ผู้เกี่ยวข้องและทรัพยากร

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

ความคล่องตัวและความยืดหยุ่น

• เราปรับหรือทำซ้ำการตัดสินใจนี้ได้เรื่อยๆ ไหม
• มันสร้าง dependency ที่เปลี่ยนยากขึ้นมาหรือเปล่า

สรุป

One-way & Two-way Door framework ไม่ได้ช่วยตัดสินใจแทนเรา แต่ช่วยให้เรารู้ว่าควรลงแรงกับการตัดสินใจไหนมากน้อยแค่ไหน

เรื่องที่เป็น ประตูทางเดียว ควรค่อยๆ คิด ค้นคว้า และ ดึงคนที่เกี่ยวข้องเข้ามาร่วม

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

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