WaterScrumfall เกมสัญญาระหว่าง business กับไอที

Photo by Kelly Sikkema on Unsplash

ผมเจอหลายทีมทำงานแบบสกรัมใบบริบทที่ fix-time, fix-scope บางครั้งคนในทีมก็เรียกการทำงานของตัวเองแบบแซว ๆ ว่า WaterScrumfall เพื่อสะท้อนว่ามีแค่ท่อนตรงกลางที่เป็นสกรัม แต่ต้นน้ำกับปลายน้ำของกระบวนการพัฒนาซอฟต์แวร์ก็ยังเป็นแบบ Waterfall อยู่ดี

ผมกำลังอ่านหนังสือ Practices for Scaling Lean & Agile Development โดย Craig Larman และ Bas Vodde ผมเอาเล่มนี้กลับมาอ่านใหม่ เมื่อประมาณ 5 ปีที่แล้วอ่านไม่รู้เรื่องเพราะประสบการณ์ไม่ถึง รอบนี้ดีขึ้นเยอะ

Contract game

ในหนังสือบทหนึ่งเล่าถึง contract game หรือเกมสัญญา โดยมีผู้เล่น 2 ฝ่ายคือ Product management กับ Research and development ถ้าเทียบกับบ้านเราก็เหมือนฝั่ง business กับไอทีเนี่ยแหละ

ซึ่งในระยะเวลาตั้งแต่โปรเจคเริ่มจนถึงวัน release จะมีวันที่โดนปักขึ้นมาลอย ๆ วันหนึ่ง เรียกว่า milestone ส่วนใหญ่เป็นวันมงคล เหมาะกับการ launch หรือบางที milestone ก็ปักไว้หลวม ๆ เช่น ของเสร็จ 80% หรือว่านายเครียดแล้วแต่ว่าอะไรถึงก่อน

source: Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum by Craig Larman, Bas Vodde

เกมเริ่มต้นโดยฝั่ง business เพราะพวกเขามีโอกาสที่ยิ่งใหญ่โอกาสเดียวที่จะ (1) รีดของออกจากฝั่งไอทีให้เยอะที่สุด และ (2) ตั้งโล่สะท้อนการกล่าวโทษภายหลังเวลาลูกค้าไม่พอใจขึ้นมา ซึ่งบ่อยครั้งถูกเรียกสวย ๆ ว่า มอบหมายความรับผิดชอบ ในตาแรกนี้ ฝั่ง business ต้องยัดของเข้าไปในสัญญาให้เยอะที่สุดด้วยความหวังว่าต่อให้โดนตัดภายหลังก็ยังเหลือของอยู่เยอะพอ

ชื่อของตาแรกนี้เรียกว่า “โอกาสสุดท้ายที่จะคายมันออกมา” เป็นรูปแบบของ local optimization แบบหนึ่ง

ตาที่สองเล่นโดยฝั่งไอที ซึ่งต้อง ‘commit’ กับแผนหรือคำสัญญา หลังจากจังหวะนี้ก็ยังเปลี่ยนแปลงได้นะ แต่เหนื่อยหน่อย ตาที่สองเล่นโดยฝ่ายไอทีที่พยายามจะตัด scope ออก

source: Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum by Craig Larman, Bas Vodde

ซึ่งนี่ก็เป็น local optimization อีกรูปแบบหนึ่ง

พอเสร็จแล้วก็วนกลับไปตา business อีก วน ๆ แบบนี้เรื่อยไปจนกว่า

1. ถึงวันอังคาร! (วันที่ปักมามั่ว ๆ วันนึง)
2. ได้ scope ที่ตกลงกันประมาณ 80% (ที่เชื่อว่าจะเสร็จ)
3. ต่างฝ่ายต่าง buffer จนรู้สึกปลอดภัยเพียงพอถ้าเกิดเหตุไม่คาดฝัน
4. ผู้บริหาร (กรรมการ) ตัดสินให้หยุดเถียงกันแล้วเดินหน้าต่อ
5. ต่างฝ่ายต่างหมดแรง

จังหวะนี้ทั้งสองฝ่ายได้สร้างสัญญาสำเร็จ และสัญญานี้ถือเป็นที่สิ้นสุดแล้ว บางครั้งจะมีการทำพิธีกรรมเซ็นสัญญาหรือการแสดงเจตจำนงว่าเรา commit แล้ว บางทีมีการใช้เครื่องรางที่เรียกว่า “โบนัสถ้าทำได้” ในจังหวะนี้ด้วย

ทั้งหมดนี้เรียกรวม ๆ ว่า ศรัทธาในไสยศาสตร์

ซึ่งเกมนี้ไม่ใช่ความผิดของใคร ผู้เล่นทั้งสองฝ่ายล้วนติดอยู่ในระบบนี้เหมือนกัน

ประเด็นสำคัญ

พอเกมจบ ฝ่าย business ก็จะจากไป เพราะเค้าเล่นเสร็จแล้ว เค้าได้โป้กเกอร์ชิพของเค้าไปแล้ว รอวันแลกมันเป็นรางวัลตอนท้ายโปรเจคอย่างเดียว

ตอนนี้ถึงคราวที่ไอทีต้องทำให้ contract นี้เป็นจริงใน development phase ละ ฝ่าย business ได้แต่นั่งลุ้นด้วยความเครียดที่มากขึ้นเรื่อย ๆ ตามกาลเวลา เพราะพวกเค้าได้ใส่เงิน, ความหวังและความกลัวเข้าไปใน contract นี้ แต่เค้าไม่มีสิทธิ์ควบคุมอะไรเลย

การพัฒนาและกระบวนการของมันอยู่ในมือไอทีล้วน ๆ

ซ้ำร้าย progress ของงานก็ไม่โปร่งใส ยิ่งถ้าไอทีเลือกมีเป็นขั้น ๆ เช่น design ทั้งหมดให้เสร็จก่อนแล้วค่อยพัฒนาทีเดียว ฝ่าย business จะไม่มีทางเลือกให้ควบคุมอะไรเลย

ท้ายเกม

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

source: Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum by Craig Larman, Bas Vodde

แม้เกมที่เล่ามาจะฟังดูงี่เง่า แต่ความเศร้าคือมันสะท้อนปัญหาในหลาย ๆ องค์กรที่ทำสกรัมแต่ business กับไอทียังสู้กันอยู่ มันเป็น zero sum game ที่ไม่ว่าฝ่ายไหนจะชนะ องค์กรก็แพ้ทั้งนั้น

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

สกรัมแก้ปัญหานี้โดยให้ตัวแทนจากฝ่าย business มาเป็น product owner แล้วมอบอำนาจในการตัดสินใจเรื่องสิ่งที่คุ้มที่สุดที่จะให้ทีมพัฒนาโฟกัสในขณะนี้กลับไปให้ business เลือก ด้วยความหวังว่าแทนที่จะสู้กัน ก็ให้ร่วมมือกันสร้างสรรค์ release plan ที่คุ้มค่าที่สุดภายใต้ขีดจำกัดต่าง ๆ ของสถานการณ์

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

1. พี่ตัดสินใจเองได้ไหมว่าจะ release เมื่อไหร่
2. พี่ตัดสินใจเองได้ไหมว่าฟีเจอร์ไหนจะอยู่หรือไม่อยู่ใน release นี้

ถ้า product owner ไม่มีอำนาจนั้น การจะให้เค้ารับผิดชอบผลการลงทุน (ROI) ของ product ก็ดูไม่ยุติธรรมกับเค้าสักเท่าไหร่

ถ้าฉันทำงานอยู่ใน WaterScrumfall ให้ทำยังไง

เลิกศรัทธาในไสยศาสตร์ แผนที่ปักมาตอนแรกถ้ามันไม่มีประโยชน์แล้วก็ปรับแผนใหม่ที่มันมีประโยชน์

ผมนึกถึงคำแนะนำหนึ่งจากรุ่นพี่ที่ผมเคารพ มันอาจจะไม่เกี่ยวกับสกรัม แต่มีประโยชน์จังหวะแบบนี้

สำหรับข่าวร้าย บอกผู้ใหญ่เนิ่น ๆ เรียกว่าไป ‘ปรึกษา’ บอกช้า ๆ เรียก ‘แก้ตัว’

อ้างอิง

Practices for Scaling Lean & Agile Development: Large, ...