Agile และ ทางเดินสายกลาง ตอน Story Point เจ้าปัญหา

จากบทความของผมเมื่อเดือนกรกฏาคมเรื่อง Agile กับ Organizational Behavior ใจความสำคัญคือ การนำเอาแนวคิดแบบagile และ ทฤษฏีพฤติกรรมองค์กรมาเปรียบเทียบกัน โดยยกวิธีในการวัดผลงานของนักพัฒนามาเป็นจุดเปรียบเทียบ

หนึ่งคำถามที่ผมไม่ได้ตอบในบทความนั้น คือ เราจะใช้อะไรเป็นตัวชี้วัดดี ในเมื่อนักพัฒนาไม่ชอบให้ใช้ story point ในขณะที่ผู้บริหารก็ต้องการใช้ เพราะเป็นชุดตัวเลขและกราฟอันน้อยนิดที่พอจับต้องได้

ผมทิ้งความสงสัยไว้อีกข้อว่า ทั้งๆที่ทุกคนก็รู้ดีว่าเป้าหมายของการพัฒนาซอฟท์แวร์คือ Working Software หรือ ซอฟท์แวร์ที่ใช้งานได้จริง (และนำไปขายอย่างมีมูลค่าได้) แต่ทำไม?? ทำไมผู้บริหารถึงต้องการลงรายละเอียด และพิจารณาปริมาณผลผลิต(productivity) ของนักพัฒนาแต่ละคน โดยตีความจาก story point ที่นักพัฒนาทำได้ในช่วงเวลาหนึ่งๆ เช่น นายไก่ ปีนี้ทำงานได้ 50 พอยท์ ดีกว่านายไข่ ที่ทำได้เพียง 30

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

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

ในบทความก่อน ผมถามว่า “จะเปลี่ยนทัศนคติของผู้บริหารได้อย่างไร?” ซึ่งวิธีคิดของผมแบบนั้น แค่เริ่มก็ผิดทางแล้วครับ ผมไม่ควรเริ่มด้วยความคิดที่จะเปลี่ยนคนอื่น แต่ควรเริ่มที่จะเปลี่ยนตัวเองก่อน ดังนั้นผมจะขอมุ่งประเด็นไปที่การปรับทัศนคติของนักพัฒนาดีกว่า และเพื่อไม่ให้ความคิดของผมชี้นำคุณผู้อ่าน ผมจะนำเสนอเฉพาะมุมมองของผู้บริหารที่มีต่อนักพัฒนา ส่วนจะตอบสนองต่อมุมมองเหล่านั้นอย่างไร ก็แล้วแต่คุณผู้อ่านจะหยิบยกไปคิดพิจารณาครับ

ลองมาดูตัวอย่างมุมมองของผู้บริหารที่เป็นไปได้ครับ
- ทำงานเป็น Iteration แต่พองานในไอเสร็จ กลับนั่งว่างๆ แทนที่จะหยิบงานในไอหน้ามาทำต่อ
- Pair programming เสียนักพัฒนาไปสองคน แต่งานเสร็จเพียงชิ้นเดียว
- Retrospective เหมือนนั่งบ่นกันเฉยๆ เสียเวลาเป็นชั่วโมง แต่จับต้องอะไรไม่ได้เลย
- Bug เยอะแยะ บอกรีบและไม่มีเวลาเขียน Unit Test แต่มาสายกว่าและกลับเร็วกว่าทีม QA
- Velocity ขอเพิ่มก็ไม่ได้ บอกว่าทำเต็มแล้ว แต่มาสายกว่าและกลับเร็วกว่าทีม QA เสียอีก
- Planning poker ใช้เวลาเยอะ วางแผนงานหรือคุยเล่นกันก็ไม่รู้ ดูไม่กระตือรือร้นเลย
- Requirement เปลี่ยนไม่ได้ และ Commitment ก็ให้ไม่ได้อีก
- ฯลฯ

ที่ผมกล่าวมาทั้งหมด ก็เพื่อชี้ให้เห็นว่ามันไม่เสมอไปที่เราจะเจอผู้บริหารที่มีใจรัก Agile และให้อิสระเสรีอย่างสมบูรณ์แก่นักพัฒนา ยอมฟัง ยอมเชื่อ ยอมตามทุกๆอย่าง อยู่ที่เราจะปรับตัวเราอย่างไร หากเราไม่ชอบให้ถูกประเมินผลงานด้วยพอยท์ เราสามารถเสนอทางเลือกอื่นได้บ้างไหม สิ่งสำคัญคือต้องปรับเปลี่ยนเรา ก่อนคิดจะปรับเปลี่ยนเขาครับ และโปรดระลึกไว้ว่า ผู้บริหารของคุณไม่ใช่ผู้ก่อการร้าย หากคุณทำตัวแข็งขืน ต่อต้าน หรือจงใจละเลยสิ่งที่ผู้บริหารต้องการ ปฏิบัติต่อเขาเฉกเช่นประเทศอเมริกาที่ไม่ยอมต่อรองกับผู้ก่อการร้าย ย่อมไม่ก่อผลดี

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

“รุกหนึ่งก้าว ถอยหนึ่งก้าว”
“ถอยหนึ่งก้าว เดินหน้าได้สามก้าว”
“ถอยหนึ่งก้าว เพื่อก้าวที่ยิ่งใหญ่กว่า”

แล้วคุณล่ะครับ ได้คำตอบให้กับตัวเองแล้วหรือยัง?