Hero Driven Development คืออะไร ?

Hero Driven Development มันเป็นอย่างไร ?

อาจจะเรียกว่า Fire Fighting อาจจะเรียกว่า Dragon Slayer อาจจะเรียกว่า Strong code ownership อาจจะเรียกว่า 10x Developer เป็นคนที่เก่งมากกว่าคนปกติ สามารถเขียน code ได้มากกว่าค่าเฉลี่ย ทุก ๆ บริษัทชอบที่จะจ้างคนเหล่านี้ เพราะว่าคนเหล่านี้สามารถทำงานได้ทุกอย่าง เพราะว่าคนเหล่านี้สามารถทำงานได้ทุกที่ทุกเวลา และเชื่อว่าคนเหล่านี้แก้ไขได้ทุกอย่าง

แล้ว Hero Driven Development มันดีหรือไม่ดี ?

ลองมองกลับไปดูที่บริษัท ที่ทีม ดูสิว่า เมื่อเกิดปัญหาขึ้นมา คนที่จะถูกส่งไปแก้ไขปัญหาคือ ใครบ้าง ? คนเหล่านั้นมักจะถูกเรียกว่า Hero ( The man called Hero ) ในระหว่างการแก้ไขปัญหานั้น อาจจะมีทีมงานมานั่งด้วย เพื่อศึกษาการแก้ไขปัญหา เพื่อมานั่งดูว่า Hero เขาทำงาน และ แก้ไขอย่างไร แต่เชื่อเถอะว่า ไม่รู้เรื่องหรอกนะ ถ้ารู้เรื่องคงแก้ไขเองไปแล้ว !! เมื่อปัญหาถูกแก้ไขเสร็จแล้ว ทีมงานเดิมก็จะทำงานในรูปแบบเดิมต่อไป จนกว่าจะเจอปัญหา แล้วจะเรียก Hero เข้ามาแก้ไขอีกครั้ง และจะเป็นแบบนี้ไปเรื่อย ๆ ไม่รู้จักจบจักสิ้น !!

รูปแบบของทีมที่ต้องการ Hero เป็นอย่างไร ?

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

สาเหตุที่เราต้องการ Hero คืออะไร ?

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

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

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

แล้วจะแก้ไขปัญหาเหล่านี้อย่างไรดี ?

เริ่มต้นอย่างแรกคือ ต้องเชื่อมันในทีม (Trust) มันคือปัญหาของทีม มันคือสิ่งที่ทีมสร้างกันขึ้นมา ดังนั้นให้ทีมช่วยกันแก้ไข โดยหัวหน้า และ ฝ่าย business/management และส่วนที่เกี่ยวข้อง ต้องคอยให้ความช่วยเหลือ หรือ สนับสนุนเมื่อทีมต้องการ แต่ทีมต้องเป็นส่วนหลักในการแก้ไขปัญหา หรือเป็นเจ้าของนั่นเอง แน่นอนว่า สามารถให้ Hero เข้ามาช่วยทีมแก้ไขปัญหาได้ แต่ให้เข้ามาให้ประเมิน และ ให้ความคิดเห็นในแง่มุมของผู้เชี่ยวชาญ ส่วนการตัดสินใจ และ การแก้ไขให้ทีมจัดการ ซึ่งเป็นรูปแบบของการทำงานร่วมกัน ไม่ใช่เข้ามาเพื่อดับไฟ หรือ ให้ผ่านไปที แต่ถ้า Hero เข้ามาช่วยแก้ไขด้วยการเขียน code ก็ต้องผ่านตามขั้นตอนที่ทีมได้ตกลงกันไว้ เช่น coding standard, code review เป็นต้น หรือให้ตรงตาม Definition of Done (DoD) ไม่มีข้อยกเว้นใด ๆ ทั้งสิ้น เพื่อทำให้คนในทีมได้เรียนรู้ และ ปรับปรุงต่อไป นั่นคือกระบวนการ Inspect and Adapt นั่นเอง ลองคิดดูสิว่า ถ้าทุก ๆ คนในทีมคือ Hero มันน่าจะดีกว่ามี Hero เพียงคนเดียวที่ต้องแก้ไขทุกปัญหานะ !!

Collaboration is a key !!

Reference Website http://highlevelbits.com/2014/08/hero-driven-development.html http://scottberkun.com/2007/asshole-driven-development/ http://carlokruger.com/?p=35 http://www.alphadevx.com/a/423-Hero-driven-development