How to fail with Agile Measurement

สืบเนื่องจากคราวก่อน ผมเขียนเรื่องเกี่ยวกับ ผลกระทบของการเลือกตัวชี้วัดกับประสิทธิภาพการทำงานขององค์กร มีคำขอตามมาว่าอยากให้ช่วยนำเสนอตัวอย่างของตัวชี้วัด(metrics) ที่จับต้องได้หรือใช้งานได้จริงหน่อย ผมพยายามหาข้อมูลเกี่ยวกับเรื่องนี้ที่โดนใจ(ไปเก็บค่าโฆษณาจากต้องอ๊อฟ ได้มั้ยเนี่ย) แต่ก็หาไม่เจอ มีแต่ที่เป็นหลักวิชาการ เดี๋ยวจะหาว่าจับต้องไม่ได้โกรธกันอีก สุดท้ายก็เลยต้องเขียนเอง คิดไปคิดมาผมมีความรู้สึกว่า ความสำเร็จนั้นก๊อปปี้กันไม่ได้ แต่ความล้มเหลวนั้นก็อปง่าย ถ้าเค้าทำกันแล้วเจ๊งผมมั่นใจว่าถ้าตามเค้าต้องเจ๊งแน่ๆ แต่ถ้าเค้าทำกันแล้วดีเราเอามาทำตามอาจจะไม่ดีก็ได้ สรุปคือ ความสำเร็จก๊อปปี้ไม่ได้ เพราะฉะนั้นมาหาทางทำมันให้ล้มดีกว่า ส่วนชื่อตอนนี่ ได้แรงบันดาลใจมาจาก presentation ที่ผมเคยทำไว้ตอน Barcamp Bangkok 2 (ความจริงเอามาจาก Mountain Goat อีกที)

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

1. Due date จงกำหนดวันที่ทุกอย่างจะต้องเสร็จ หรือไม่ก็ฝึกถามคำถามว่า “เสร็จเมื่อไหร่” ให้ติดปาก และวัดผลว่า เสร็จก่อนกำหนดคือ “ดี” และ เสร็จช้ากว่ากำหนดคือ “แย่” ถ้าทีมลีดคนไหนบอกไม่ได้ว่าโปรเจ็คจะเสร็จเมื่อไหร่ คนนั้นถือว่าแย่มากๆ

2. Working time การทำงานหนักคือสิ่งที่ดี เพราะฉะนั้นคนที่มาทำงานแต่เช้า นั่งทำงานไม่หยุด และกลับดึกๆ คือคนที่มีประสิทธิภาพ พนักงานคนไหนทำงานบ้างหยุดคุยบ้าง อันนี้ใช้ไม่ได้ โดยเฉพาะพวกที่ทำงานเองไม่ได้ ต้องช่วยกันทำสองคนนั้น ถือว่าประสิทธิภาพติดลบ ทางที่ดีใช้ระบบตอกบัตรเข้าออกงาน และ timesheet ในการควบคุมเรื่องนี้ดีที่สุด

3. Velocity ขยันทำงานอย่างเดียวยังไม่ดี ต้องให้ได้งานเยอะๆ ด้วย เพราะฉะนั้นต้องดูว่าได้ผลงานเท่าไหร่ หนึ่ง sprint ยิ่งได้ตัวเลขมาก ยิ่งดี

4. Line of produced code การจะดูแค่ velocity อย่างเดียวนั้นไม่เพียงพอในการวัดปริมาณผลงาน เพราะแต่ละทีมมีขนาดของเนื้องานต่อ story point ไม่เท่ากัน เพราะฉะนั้นจึงต้อง เอาจำนวนโค้ดที่เขียนได้มาดูประกอบด้วย ว่าทำงานได้ปริมาณมากน้อยแค่ไหน ยิ่งมากถือว่ายิ่งดี

5. Number of bug tickets การทำงานนั้นคุณภาพเป็นสิ่งสำคัญ เพราะฉะนั้นถ้า Developers ทำให้เกิด bug เป็นจำนวนมากถือว่าใช้ไม่ได้ และ QA ถ้าค้นหา bug เจอได้มากถือว่าดี

6. Number of change requests ถึงแม้จะบอกว่า welcome change แต่ก็ต้องมีการ track ไม่งั้น analysts ก็ทำกันมั่วๆ และไม่รู้ว่าจะทำ Release planning ไปทำไม เมื่อเริ่ม sprint แรกแล้ว ถ้าจะมีการเพิ่ม requirements ที่อยู่นอก release plan จะต้องทำเป็น Change request ทุกครั้ง ถ้ามีมากถือว่า analyst team ทำงานไม่ดี

7. Document defect rate ถึงแม้จะมีเอกสารเท่าที่จำเป็น แต่เมื่อมีแล้วก็ต้องตรวจสอบด้วยว่า มีข้อผิดพลาดหรือไม่ มีมากแค่ไหน และส่งผลร้ายแรงแค่ไหน ให้ developer รายงาน ข้อผิดพลาดของ requirements (BRD, story, acceptance criteria, 1-page, etc) ส่วน QA ก็เช่นเดียวกัน มีหน้าที่รายงานข้อผิดพลาดของ design (Tech design, UML, workflows, dataflows, etc) ทั้งหมดให้รายงานในรูปของ ticket เพื่อให้นับจำนวนได้ และวิเคราะห์ผลได้ง่าย

8. Code coverage อย่างที่พูดไปแล้วว่าคุณภาพเป็นสิ่งสำคัญ เพราะฉะนั้นต้องมีการทำตรวจสอบว่าทำ Unit test ได้ครอบคลุมแค่ไหน ยิ่งมากยิ่งดี แต่คงไม่สามารถทำได้ 100% เพราะฉะนั้น ควรกำหนดให้เป็นตัวเลขที่เหมาะสมเช่น 90% หรือ 80% เป็นต้น ถ้าโค้ดยิ่งมี coverage มากกว่าเป้ายิ่งดี ถ้าน้อยกว่าเป้าถือว่าไม่ดี

9. Individual measurement การคัดสรรคนเป็นสิ่งสำคัญ ต้องแยกแยะให้ได้ว่า ใครเป็นทำงานได้ดีและใครทำงานได้แย่ เพราะฉะนั้นเราจึงต้องทำการวัดผลเป็นรายบุคคล งานของใครช้ากว่ากำหนด ชั่วโมงของใครทำงานมากเท่าใด หรือ velocity ของแต่ละคน เป็นต้น

ถ้าทำได้ครบ 9 ข้อตามข้างบน ผมสามารถรับประกันได้เลยว่าคำว่า Agile จะหายไปจากองค์กรของคุณได้ในเร็ววันอย่างแน่นอน

Links
https://korn4d.wordpress.com/2010/07/07/metrics-you-are-what-you-measure-1/
https://korn4d.wordpress.com/2010/07/08/metrics-you-are-what-you-measure-2/
http://www.slideshare.net/guestfa16bc/how-to-fail-with-agile-presentation
http://www.mountaingoatsoftware.com/articles/40-how-to-fail-with-agile

Advertisements

ใส่ความเห็น

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s