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
