Retro on planning and Coding balance

ช่วงก่อนสิ้นปีมีงานนึงในออฟฟิศที่อยาก Push ออกไป แล้วส่วนตัวเกิดความกังวลใจที่จะทีมบอกว่าจะจัดประชุมวางแผนการทำงาน (ซึ่งฟังดู Absurd มากๆ แต่เกิดความรู้สึกนี้ขึ้นจริงๆ ว่าทำเลยดีกว่ามั้ย อย่าวางแผนมากเลย)

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

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

เรามองเห็นว่าสิ่งที่เรากังวลมีประเด็นตามนี้

Decision fatigue and Ideal searching

พอเราโฟกัสกับการวางแผนไปจนเกินสมดุลที่ดี มันเป็นไปได้ที่เราจะลืมเป้าหมายแล้วพยายามสร้าง “แผนในอุดมคติ” ทั้งๆ ที่จริงๆ แผนที่ดีที่สุดเท่าที่มีปัญญาคิด กับแผนที่พาไปถึงเป้า มันต่างกันแค่ Trade-off มีอะไรบ้าง

ถ้าเราโฟกัสกับการวางแผนมากว่าแผนจะต้องออกมาดีไม่มีที่ติ ไม่ว่าจะในแง่แบ่งงานหรือ Architecture ผลที่ตามมาคือเกิด Decision fatigue ไม่กล้าเลือกสิ่งที่พาไปถึงเป้าหมาย เพราะมัน “ไม่ดีที่สุด” ยังพยายามคิดหาสิ่งที่ดีกว่านี้อีกเรื่อยๆ

สิ่งนี้แหละที่ทำให้บางที ระหว่างคนอื่นวางแผนกันอยู่ว่าทำแบบไหนดีกว่ากัน อีกคนโค้ดเสร็จแล้วไม่พอยังเป็นโค้ดที่ Maintain ได้ไปเป็นปี (ผมเคยโค้ดเสร็จระหว่างคนอื่นวางแผนอยู่จริงๆ)

ในทางกลับกันวิธีการคิดที่พยายามหาสิ่งที่ดีกว่าเดิมเสมอไม่ใช่เรื่องไม่ดี มันก็เป็น Mindset และวิธีคิดที่ดีเหมือนกัน แต่บนเวลาที่มีจำกัด เราไม่สามารถมองข้าม Cost of planning ได้ (คนส่วนมากมักจะมองข้ามและ Take for grant ว่า Planning ราคาถูกกว่า Doing ซึ่ง ส่วนมากใช่ แต่ไม่จำเป็นและไม่ใช่ทุกครั้ง) บางครั้งกลายเป็นว่าจะทำอะไรซักทีต้องประชุม 3 ครั้ง แถมว่างไม่ตรงกัน ได้แค่อาทิตย์ละครั้ง กลายเป็นกว่าจะเริ่มงานได้ต้องผ่านไปเกือบเดือน Cost ของการประชุมและ Planning บางทีมันแพงมากนะ ใช่คือ 90% มันจะถูกกว่าทำโดยไม่วางแผนให้ดีก่อน แต่ก็อย่ามองข้าม 10% ที่มันแพงกว่า

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

Unresolvable argument / Addiction to debate

เวลามีความเห็นต่างบางครั้งมันยากที่จะสรุปอะไรบางอย่างออกมา ซึ่งบางทีมันกินเวลามากๆ ในการจัดการกับความเห็นต่าง

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

ถ้าทำดีหน่อยเราจะเดาแบบมีข้อมูลรองรับบ้าง แต่มันก็คือเดาอยู่ดี

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

“คุณเสนอให้ทำแบบนี้นี้คุณรู้ได้ยังไงว่ามันจะเวิร์ค เอาเหตุผลที่ไหนมารองรับ”

วิธี Debate แบบนี้ถือว่าไม่ดีต่อบรรยากาศ (และเรามักจะติด รวมถึงผมด้วยในบางครั้ง)

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

แล้วต่อให้มีผลจาก A/B Testing ถ้าผมจะพยายามเรียกร้องความแน่นอนทางเหตุผล ผมก็ยังสามารถบอกได้อีกว่า ข้อมูลยังไม่ชัดขนาดนั้น แล้วรู้ได้ไงว่าข้อมูลทางสถิติจากสะท้อนอนาคต User ที่ Target คนล่ะกลุ่มกัน 9ล9 มันเรียกร้องได้ไม่มีที่สิ้นสุด

ผมพบว่า Heuristic หรือแนวทางที่ Healthy กว่าจะมีสองอย่าง

  1. เราพูดในเชิงเปรียบเทียบเท่านั้น ถ้าผมจะบอกว่า Choice นี้ที่เสนอมาไม่เวิร์คเพราะเหตุผลรองรับไม่หนักแน่นพอ ผมต้องเสนอ Choice ที่มีข้อมูลรองรับหนักแน่นกว่า (Choice ที่จะไม่ทำอะไรเลยอยู่เฉยๆ ก็เป็น Choice ได้) หรือไม่งั้นก็ต้องมีข้อมูลฝั่งที่ Counter ซึ่งถ้า Choice ไหนมีข้อมูลรองรับน้ำหนักสูงกว่าก็ถือว่าน่าสนใจกว่าเป็นเหตุให้ตีของเก่าลงไปได้ หรือ ถ้า Choice ไหนไม่มีข้อมูลสนับสนุนแถมมีข้อมูลที่ค้านอีกก็คงไม่เวิร์ค พูดง่ายๆ คือ “ทุก Choice คือการเดา แต่เราเลือกการเดาที่มีข้อมูลน้ำหนักสูงกว่ารองรับ” ซึ่งถ้ามันไม่มี Choice ไหนมีข้อมูลดีๆ รองรับเลย ก็แค่ยอมรับว่าเรายังมีข้อมูลไม่พอ แล้วก็ลงมือทำตามการเดาที่ไม่มีอะไรรองรับไปก่อน เพื่อให้เกิด Feedback ใหม่ๆ มาเป็นข้อมูลในอนาคต ไม่ใช่บอกว่า “ไม่มีข้อมูลรองรับงั้นไม่เอา” (ซึ่งจริงๆ มันมี Subtle message ซ่อนว่า ให้ทำตามเดิมที่เคยทำมา)
  2. คนที่ถือ Stake สูงกว่า ควรจะเป็นคนตัดสินใจและฟันธงบนทางเลือก ที่ข้อมูลเหตุผลรองรับมีน้ำหนักเท่ากันหรือใกล้เคียงกัน ก็ไม่แปลกอะไร ในเมื่อทุกคนเดาและ Bet ร่วมกัน ตามหลักเลยคนที่ถือ Risk มากกว่าก็ควรมีเสียงมากกว่าในการตัดสินใจอยู่แล้วนี่ จริงๆ ข้อนี้มันเป็นกฎตายตัวเลยเพราะตามกฎหมายและกฎองค์กรก็ไม่ได้เขียนไว้ว่าทุกคนต้องทำตามเหตุผลและข้อมูล หัวหน้าและเจ้าของบริษัทสามารถทำการตัดสินใจได้ แต่ผมมองว่า Stakeholder ไม่ควรจะใช้หมวกพร่ำเพรื่อ ในเวลาที่ข้อมูลมันเห็นชัดก็ให้ข้อมูลนำทางไป

สิ่งที่อันตรายมากๆ คือการเรียกร้องความแน่นอนทางเหตุผล มันทำให้เถียงกันไม่จบแล้วหาข้อมูลกันไม่จบไม่สิ้น เพราะการเรียกร้องความแน่นอนมันทำได้ไม่มีวันสิ้นสุด สุดท้ายแล้วส่วนมากที่ว่า “ไม่เวิร์คหรอก ไม่มีอะไรรองรับ” มันมี Subtle message ว่า “ทำแบบเดิมดีกว่า”

วิธีการเคลียร์เรื่องนี้คือต้องเอา Legacy หรือ “ทำแบบเดิม” มาเป็น Choice เปรียบเทียบด้วย ไม่ใช่ปล่อยให้มัน Subtle อยู่อย่างนั้น

และอีกข้อนึงคือเผ่าโปรแกรมเมอร์มักเป็นเผ่าที่ชอบการดีเบตเป็นชีวิตจิตใจ จนบางทีเราลืมเป้าหมายไป การดีเบตในเรื่องเล็กน้อยที่การเลือก Choice ที่ต่างกันไม่ได้มีผลกระทบต่อเป้าหมายมากมายนัก (เช่น ใช้สีอะไรดี หรือใช้ Tab/Space) บางครั้งเรายึดติดว่าเราอยากเป็นฝั่งถูก หรืออยากจะได้สิ่งที่ดีที่สุดจนลืมไปว่า ไม่ดีที่สุดก็ถึงเป้าหมายได้

ซึ่งผมย้ำอีกครั้งว่าการหาสิ่งที่ดีที่สุดเป็น Mindset ที่ดี แค่หาสมดุลของมันให้เจอไม่ใช่หาจนสุดท้ายไปไม่ถึงเป้าบนทรัพยากรที่จำกัดเพราะมัวแต่หาสิ่งที่ดีที่สุด ทั้งแง่ Design วิธีเขียนโค้ด หรือ Architect หรือ Stack ที่ดีที่สุด เมื่อไปไม่ถึงเป้า ยังงั้นคงเรียกว่า “ดีที่สุด” ไม่ได้ (เหมือนคนที่หาแฟนที่ “ดีที่สุด”​ ไปเรื่อยจนไม่ได้ลงเอยกับใครเลย)

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

ส่งท้าย

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

ส่วนตัวยังเชื่อว่าการวางแผนก่อนโค้ดเป็นเรื่องดีนะ แต่ประเด็นต่างๆ ที่เขียนไว้ตรงนี้ก็ Valid และคือ ไม่มีอะไรที่ “ดีไร้ที่ติ” ทุกอย่างต้องการสมดุล การวางแผนก็ต้องการสมดุลเช่นกัน การวางแผนและคิดล่วงหน้าก็ช่วยชีวิตให้ดีมาหลายครั้งเช่นกัน เมื่อทำอย่างสมดุล

หวังว่าปีหน้าจะมีโอกาสได้ Facilitate การประชุมและบทสนทนาในทีมมากกว่านี้ บางทีก็ยุ่งจนไม่มีโอกาส และบางที (โดยเฉพาะปลายปีที่แล้ว) ก็ Facilitate ได้ไม่ดีเพราะใจไม่ได้อยู่กับปัจจุบันเต็มที่มีความกังวลอย่างอื่นซ้อนอยู่


หมายเหตุ: เรื่องที่ตลกแต่น่าสนใจเกี่ยวกับ Effect ของการวางแผนกับความสำเร็จของ Software development มันไม่มีใครออกมาบอกหรอกว่า Project ไม่เวิร์คเพราะวางแผนมากไป แต่จะมีคนบอกว่า Project ล่มเพราะวางแผนไม่ดีพออยู่เสมอ เพราะสุดท้ายมันไม่มีใครย้อนทวนได้ไงว่าถ้าวางแผนน้อยกว่านี้จะดีกว่าหรือเปล่า ยิ่งกับ Project ที่ Success ใครมันจะมา Retro ล่ะว่าจริงๆ เราตัดอะไรทิ้งได้บ้าง ดังนั้น เวลาผมอ่านเรื่องที่ว่าบทเรียนสรุปว่าควรวางแผนมากกว่านี้ คิดให้มากกว่านี้ก่อนลงมือ ผมก็แบบ เอิ่ม แล้วใครจะ Counter-argument วิธีสรุปแบบนี้ได้

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

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

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.