เข้าใจประวัติศาสตร์ เพื่อเปลี่ยนแปลงอนาคต
สาเหตุหนึ่งที่เมื่อก่อนผมไม่อยากเข้าไปโค้ชในองค์กรใหญ่ ๆ เพราะ องค์กรใหญ่ ๆ มีกฎมากมายที่แม้แต่คนทำก็ไม่รู้ว่าทำไปทำไม เป็นกฎที่เค้าทำตาม ๆ กันมา เช่น ต้องแยกคนที่มีสิทธิ์เข้าถึง production (operation) และคนที่มีความรู้ในการดูแล production (developer) ออกจากกัน หรือการจะเอาของขึ้น production ได้ ต้องมี log เพื่อที่จะใช้เป็นหลักฐานในการยืนยันว่าระบบที่เราดูแลทำงานถูกต้อง ผมก็ไม่เข้าใจว่าในสถานการณ์ที่ user ใช้งานระบบไม่ได้ การหาคำตอบเจอว่าฉันไม่ผิดนะมันมีประโยชน์ยังไง ในเมื่อความเสียหายทางธุรกิจก็ยังดำเนินต่อไป พอผมลองออกเสียงถามไปตามความสงสัย ถ้าไม่ได้คำตอบที่มันเป็นแนวปรัชญาฟังไม่รู้เรื่องกลับมา ก็โดนโมโหใส่ จนไม่กล้าถามอีกต่อไป “เพิ่งเข้ามาจะไปเข้าใจอะไร” กับ “outsource ยังไงก็ยังเป็น outsource” เป็นสัญญาณผมได้ยินบ่อย ๆ ว่าผมได้ล้ำเส้นเข้าไปแล้ว
ช่วงที่ต้องทำงานในสิ่งแวดล้อมที่ผมไม่เข้าใจมันอึดอัดมาก มีของหลายอย่างที่ต้องทำ ๆ ไป ทั้ง ๆ ที่ไม่เข้าใจ พอไม่เข้าใจ ก็ไม่รู้ว่าจะทำมันให้ดีได้ยังไง รู้แค่ทำให้มันพอผ่าน บางครั้งพอได้ feedback มาว่ามันไม่ผ่าน ก็ไม่รู้จะปรับยังไง เพราะไม่เข้าใจตั้งแต่แรกแล้วว่าจะทำไปทำไม
สิ่งยึดเหนี่ยวเดียวที่คอยเติมกำลังใจให้อดทนใช้ชีวิตในองค์กรใหญ่ ๆ ต่อไป คือคำของ Bas Vodde ที่เป็นทั้งเพื่อนร่วมงานและเป็นเหมือนอาจารย์สอน Scrum ผมบอกผมว่า สำหรับบาส ถ้าเมื่อไหร่ที่บาสเป็นโค้ชในองค์กรนั้นจนเข้าใจว่าทำไมระดับคนทำงานถึงรู้สึกหงุดหงิดกับการตัดสินใจของเบื้องบน ว่าทำไมตัดสินใจทำอะไรโง่ ๆ แบบนี้ ขณะเดียวกันก็เข้าใจผู้บริหารระดับสูงว่าในสถานการณ์ที่มีแต่ทางเลือกแย่ ๆ ให้เลือก และต้องเลือกอันที่แย่น้อยที่สุดมันลำบากยังไง นั่นแหละ เรียกว่าบาสอยู่ในธุรกิจโดเมนนั้นมานานพอจนเข้าใจมันจริง ๆ แล้ว
หลังจากสั่งสมประสบการณ์ในการทำงานในองค์กรใหญ่ ๆ มากขึ้น บวกกับอ่านหนังสือที่มันบอกเล่าเรื่องราวของพลวัตรที่มันเกิดขึ้นในองค์กรขนาดใหญ่ เช่น The Phoenix Project หรือ Moral mazes ก็ค่อย ๆ เข้าใจว่าทำไมสิ่งต่าง ๆ ถึงถูกวางไว้แบบนี้
ก็ต้องยอมรับว่าตอนแรก ๆ ที่ไม่เข้าใจว่าเค้าทำไปเพราะอะไร ทำไมเค้าถึงยอมทนลำบากเพื่อทำสิ่งที่ดูเหมือนพิธีกรรมเหล่านั้นต่อไป ไม่ว่าผมจะไปชวนให้เค้าเห็น “แนวทางที่ดีกว่า” ซักเท่าไหร่ เค้าก็ไม่ซื้อ ตัวอย่างที่ชัดมาก ๆ เลยคือ วันหนึ่งที่ผมมีโอกาสได้คุยกับ business analyst คนหนึ่งที่มีหน้าที่เซ็นรับผล test UAT เพื่อยืนยันว่าระบบนี้ผ่านการ test แล้วนะ สามารถเอาขึ้น production ได้อย่างมั่นใจ ในช่วงนั้นผมกับผู้บริหารระดับสูงหลายคนช่วยกันปรับปรุง engineering practice ในองค์กร เพื่อให้รองรับการเปลี่ยนแปลงที่รวดเร็วได้มากขึ้น เราพบว่า แม้เราจะเอา UAT test case มาทำ automate แล้วก็ตาม จำนวน test case ที่เพิ่มขึ้นเรื่อย ๆ ก็ทำให้การทำ regression test มันช้าลงเรื่อย ๆ ตามจำนวน test case ที่เพิ่มมากขึ้นอยู่ดี
ผมไปขุดจนพบแล้วว่า automate UAT test เหล่านี้มันซ้ำซ้อนกับ unit test ที่ developer เค้าทำขึ้นมา และหลักฐานหนึ่งที่สนับสนุนสิ่งที่ผมค้นพบคือ UAT test บาง case ไม่เคย fail เลยตั้งแต่วันแรกถึงมันเกิดขึ้นมาจนถึงวันนี้ ผมไปถาม business analyst คนนี้ว่า ผมขอ ‘ลบ’ UAT test case ที่มันซ้ำซ้อนได้ไหม? คำถามที่ผมได้ยินกลับมาคือ
BA: ถ้า test ที่ลบไปแล้วมันเกิด fail ขึ้นมา หนูโดนหัวหน้าด่าไหม?
ผม: โดน
BA: งั้นลบไม่ได้ค่ะ!
ผม: แล้วถ้าผมไปขอหัวหน้ามาให้น้องไม่โดนหล่ะ ถ้าน้องเห็นผล unit test นั้นรวมกับ UAT test นี้แล้ว ถือว่าน้องไม่ผิดแล้ว ถ้ามันยัง fail ขึ้นมา ให้มาด่าผมแทน
BA: หนูไม่ต้องดูผล unit test ประกอบให้วุ่นวายก็ได้ค่ะ แค่หนูไม่โดนด่า หนูก็ยอมให้ลบแล้ว
วินาทีนั้นผมเห็นภาพชัดมาก ว่าทุกคนที่ผมร่วมงานด้วย เค้ารู้นะ ว่าบางอย่างที่ทำมันไม่มีประโยชน์ และอยากจะกระชับกระบวนการเพื่อให้องค์กรก้าวไปข้างหน้าได้เร็วขึ้น แต่พอ KPI เค้ามันไม่มีความคล่องตัวขององค์กรอยู่ในนั้นเลย มีแต่ถ้าผลลัพธ์อันนี้ผิด คนนี้ต้องโดนลงโทษ การที่ผมไปชวน BA ให้เค้าเอาชีวิตการทำงานตัวเองไปเสี่ยง เพื่อความก้าวหน้าขององค์กร โดยไม่มีคำตอบให้เค้าว่าถ้าเค้าโดนไล่ออกมาเค้าจะเอาค่านมลูกจากไหน เหมือนการช่วนคนจมน้ำกำลังจะขาดอากาศไปปลูกป่าชายเลนเพื่ออนุรักษ์สิ่งแวดล้อมเลย
ถึงตรงนี้ก็นึกถึง talk เรื่อง How Too Many Rules at Work Keep You from Getting Things Done ของ อีฟส์ มูริเย่ ขึ้นมา…
We pay more attention on knowing who to blame in case we fail, than creating the conditions to succeed. — Yves Morieux
เป็นอีกครั้งที่ผมย้ำเตือนตัวเองว่า ก่อนจะไปแนะนำคนอื่นให้ทำอะไร ต้องไปเข้าใจเค้าก่อน เพราะคนเราไม่เชื่อคนฉลาด เราเชื่อคนที่เราไว้ใจ ส่วนตอนที่เค้ายังไม่ไว้ใจ ก็วิ่งเหยาะ ๆ ไปเรื่อย ๆ ระวังไม่ให้โดนเป่าล้ำหน้าก็พอ
อ้างอิง
ขอบคุณพี่รูฟที่เป็นแรงบันดาลใจให้เกิดบทความนี้
