Distributed Decision Making

Distributed Decision Making

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

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

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

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

Netflix

Netflix มีคอนเซปต์ (Concept) เรื่อง Informed Captain ซึ่งเป็นบทบาท (Role) ของการตัดสินใจ ใครจะเป็นก็ได้ ขอแคิต้องทำตาม 5 ขั้นตอนด้านล่างนี้ครับ

  1. เก็บเกี่ยวความเห็นต่าง (Farming for Dissent): คือการไปถามคนที่น่าจะคัดค้านไอเดียนี้ ไปฟังดูว่าเขากังวลเรื่องอะไรบ้างในทุก ๆ ระดับ (Level) ขององค์กร และต้องพิมพ์ความเห็นต่างเหล่านั้นแนบไปกับไอเดียอย่างโปร่งใส ห้ามปิดบัง
  2. ทดสอบ [ทางเลือก] (Socializing and Testing): สำหรับไอเดียที่มีความเสี่ยงสูง กัปตันจะลองทำในสเกล (Scale) เล็ก ๆ ก่อน แล้วเขียน Open Memos ให้ทุกคนเข้ามาออกความเห็น
  3. ตัดสินใจ (Making the Call): กัปตันตัดสินใจจากข้อมูลที่มีเพียงลำพัง กัปตันเป็นคนรับผิดชอบผลการตัดสินใจนั้น โดยไม่ต้องขออนุมัติจากใครอีก
  4. Disagree and Commit: ถ้ากัปตันตัดสินใจแล้ว ทุกคน (รวมถึงคนที่เคยแชร์ความกังวลก่อนหน้านี้) จะต้องสนับสนุนการตัดสินใจของกัปตัน และช่วยกันทำมันออกมาให้ดีที่สุด
  5. เก็บเกี่ยวการเรียนรู้ (Sunshine the Outcome): หลังจากผลลัพธ์ออกมาแล้ว กัปตันจะแบ่งปันว่าผลลัพธ์อะไรที่ดีเพื่อเฉลองร่วมกัน และอะไรที่ได้เรียนรู้ เพื่อที่ทั้งองค์กรจะได้ไม่พลาดซ้ำในจุดเดิม

Lyft

ที่ Lyft จะใช้การเขียน 1-Pager (เอกสารสรุปในหน้าเดียว) ขึ้นมาสำหรับการตัดสินใจ แล้วค่อยนัดประชุม การถกเถียงหรือความกังวลต่าง ๆ จะถูกสื่อสารและโต้ตอบกันผ่านตัวหนังสือล่วงหน้า เพื่อให้เมื่อถึงเวลาประชุม ทุกคนจะได้รวบรวมข้อมูล (Gather Data) และตกผลึกไอเดีย (Generate Insights) เรียกว่าเตรียมตัวไปเรียบร้อยแล้ว และใช้เวลาในห้องประชุมสำหรับการ "ตัดสินใจ" เท่านั้น

ถ้าในการเขียนคุยกันนั้นทุกคนเห็นพ้องต้องกันอยู่แล้ว ก็สามารถแคนเซิล (Cancel) การประชุม แล้ว Move-on ไปทำงานต่อได้เลยครับ

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

Read more

The Five Ideals

The Five Ideals

จากหนังสือ The Unicorn Project ในนั้นจะมีที่ปรึกษาเก่ง ๆ คนหนึ่งชื่อ Erik เป็นเหมือนเซ็นเซหาตัวยาก เดี๋ยวก็มา เดี๋ยวก็ไป ถ้าโชคดีก็จะเจอเค้าว่าง แล้วเค้าก็จะสอนอะไรที่สำคัญ ๆ แต่ฟังดูล้ำ ๆ และลึกซึ้ง

By Chokchai Phatharamalai
Communication, Reliability and Modern concepts - System Design, Simply Explained

Communication, Reliability and Modern concepts - System Design, Simply Explained

บทความนี้จะอธิบายพื้นฐานของ System Design โดยต่อยอดจากตัวอย่าง Gym Application เพื่อให้เห็นภาพว่า เมื่อระบบเริ่มเติบโตและถูกแยกออกเป็นหลาย Service แต่ละ Service จะสื่อสารและทำงานร่วมกันอย่างไร งานแบบไหนควรสื่อสารแบบ Synchronous งานแบบไหนควรประมวลผลแบบ Asynchronous รวมถึงอธิบาย Concept พื้นฐานต่าง ๆ ที่ควรรู้ เช่น API

By Boonsong Srithong
Race condition

Race condition

ผมกำลังอ่านหนังสือ The Unicorn Project ซึ่งเป็นนิยายเกี่ยวกับ developer สาวคนหนึ่งที่ใช้ชีวิตในองค์กรท่ามกลางกระแส digital disruption อ่านแล้วสนุกมาก เป็นเรื่องที่ตื่นเต้น และหลาย ๆ dynamic ที่เกิดขึ้นก็คล้ายกับที่ผมพบเจอในบริษัทซอฟต์แวร์ เลยทำให้

By Chokchai Phatharamalai
Distributed Systems Concepts - System Design, Simply Explained

Distributed Systems Concepts - System Design, Simply Explained

ในช่วงแรก Product เราสามารถออกแบบระบบให้อยู่ใน Server และ Database เดียวกันได้ แต่เมื่อระบบโตขึ้น มีผู้ใช้งานเพิ่มขึ้น ข้อมูลเยอะขึ้น ระบบเริ่มทำงานช้าลดเรื่อยๆ สิ่งที่หนีไม่ได้คือการ Decomposition Service ไปเป็น Distributed System เช่น Member Service, Booking Service, Payment

By Boonsong Srithong