สืบเนื่องมาจากบทความ Playing the Devil’s Advocate ที่ผมได้เข้าไปก่อกวนมา 
บทความนั้นเริ่มมาจาก status ใน facebook ของพี่ @sinapam ที่กล่าวว่าเราไม่ควรนำเอา story point หรือจำนวน story ที่นักพัฒนาทำได้ มาเป็นตัวชี้วัดผลงาน ผมทำงานในสายพัฒนาซอฟต์แวร์มาตลอด จึงไม่แปลกที่จะเห็นด้วยกับความคิดนี้ แต่พอลองสวมหมวกใบอื่นดูบ้าง หรือ นึกถึงหัวหน้าที่ต้องพิจารณาผลงานของผู้ใต้บังคับบัญชา กลับนึกไม่ออกว่าจะเอาอะไรมาเป็นตัวชี้วัดดี?
ผมตั้งข้อสงสัยไว้อย่างหนึ่ง ว่าทีมอื่นๆทั่วโลกที่ใช้ Agile เขาใช้อะไรเป็นตัวชี้วัด… แหม มันต้องมีสักอย่างสิ! ให้ตายเถิด!!
ในมุมมองของผม ตัวชี้วัดผลงาน ควรมีความสมดุลกันระหว่าง ปริมาณ (Productivity) และ คุณภาพ (Quality) ซึ่งก็จะคล้ายกับของพี่ @sinapam ที่ว่า เราควรวัดผลงานกันด้วย “คุณภาพ” ของ code ซึ่งก็จะมีคำถามตามมาอีกเยอะแยะเชียว ว่าแล้วอะไรล่ะที่จะเป็นตัวชี้วัดคุณภาพ?
>> โค้ดอ่านง่าย ?… ถ้าผมเป็นคนชอบเขียนโค้ดโดยใช้ pattern หนึ่งๆเป็นประจำ หากใครเขียน pattern นี้มา ผมก็ว่าอ่านง่ายหมด นี่ก็แสดงว่าวิธีนี้มี bias (อคติ) และไม่อาจเป็นตัวชี้วัดที่ดีได้เสมอไป
>> ความง่ายของการดูแลรักษา (ease of maintenance) ?… อันนี้ยิ่งตีมูลค่าเป็นตัวเลขยากใหญ่เลย จะวัดความง่ายของการดูแลรักษาได้อย่างไร หรือผมต้องมาคิดว่า “เขียนโค้ดแบบนี้ ถ้าอนาคตมาแก้จะใช้ 5 วัน แต่ถ้าเขียนอีกแบบ อนาคตมาแก้จะใช้ 8 วัน” ผมว่ามันยังขาดความชัดเจนไปครับ
จะวัดคุณภาพได้ ก็ต้องตรวจโดยละเอียด แต่ในระดับผู้บริหารที่ต้องดูแลผู้ใต้บังคับบัญชาจำนวนมาก การจะมาดูรายละเอียดทุกจุด ก็ดูจะเป็นไปได้ยาก หรือเป็นไปไม่ได้เลย ก็แบบที่พี่ @kluak110 กล่าว ผู้บริหารทั้งหลายเขาชอบกราฟและตัวเลขครับ มันเปรียบเทียบกันได้ง่ายและชัดเจนกว่า
ณ ขณะนี้ ผมเองก็ยังไม่มีคำตอบที่ถูกต้องในเรื่องนี้เหมือนกัน คงต้องศึกษาและทดลองกันต่อไป
… พูดมาตั้งนาน ยังไม่ได้เข้าเรื่องตามหัวข้อ Agile กับ Organizational Behavior เลย… เศร้าจริง…
[เข้าเรื่อง] จากประสบการณ์และการเฝ้าสังเกต Agile ทีมจะเน้นความคล่องตัวและยืดหยุ่น และใช้การสื่อสารและปฎิสัมพันธ์ ระหว่างสมาชิกในทีมและลูกค้าเป็นหลัก ดูได้จาก Agile Manifesto บรรทัดที่ 1, 3, และ 4 และผมเชื่อว่าเป้าหมายหลักของ Agile ไม่ใช่อื่นใด แต่คือ
Working software
ซึ่งบัญญัติทั้งหลายทั้งปวงนี้ ล้วนต้องตั้งอยู่บนพื้นฐานของความมีวินัย (Discipline) ของนักพัฒนา เมื่อทีมมีวินัย ความไว้วางใจ (Trust) และความน่าเชื่อถือ (Reliability) จากบุคคลอื่นๆ ก็จะก่อร่างสร้างตัวขึ้น เมื่อถึงระดับหนึ่ง Agileทีมจะทำงานกันด้วยความราบรื่นและเป็นจังหวะ ตัวเลขทั้งหลายจะเป็นเรื่องไม่จำเป็นเลย ใครจะไปสนใจตัวเลขเยอะแยะพวกนั้น หากทีมสามารถส่งมอบ Working software ได้เสมอ!
จุดนี้ดูมีความเชื่อมโยงกับทฤษฏีพฤติกรรมองค์กร (Organizational Behavior) อยู่หัวข้อหนึ่ง ซึ่งก็คือ ทฤษฏี X และ ทฤษฏี Y
ทฤษฏี Y กล่าวว่า ผู้บริหารมองว่าพนักงานมีความกระตือรือร้นโดยธรรมชาติ และสามารถสร้างแรงกระตุ้นและควบคุมงานได้ด้วยตัวเอง และที่สำคัญคือพนักงานมองงานเป็นเรื่องสนุกและมีความสุขกับการทำงาน
“Management assumes employees may be ambitious and self-motivated and exercise self-control. It is believed that employees enjoy their mental and physical work duties… to them work is as natural as play.“
ทฤษฏี X กล่าวว่า ผู้บริหารมองว่าพนักงานมีความขี้เกียจเป็นนิสัย และจะเลี่ยงงานทันทีหากสบโอกาส ดังนั้นจึงควรทำการควบคุมและดูแลอย่างใกล้ชิด และ มีระบบตรวจสอบที่เข้มงวด
“Management assumes employees are inherently lazy and will avoid work if they can and that they inherently dislike work. Thus, management believes that workers need to be closely supervised and comprehensive systems of controls developed.“
ผมมองว่าวิถีแห่ง Agile นั้น มีแนวทางที่เหมือนทฤษฏี Y คือให้รูปแบบการทำงานเป็นไปตามธรรมชาติ มีการดูแลอย่างสม่ำเสมอแต่ไม่ได้เข้าควบคุม… ในขณะที่การนำเอา story point หรือจำนวน story มาวัดผลงานของนักพัฒนานั้น คล้ายกับแนวคิดของทฤษฏี X ซึ่งแนวคิดแบบนี้นอกจากจะโบราณแล้ว ยังก่อให้เกิดปัญหาระยะยาวอื่นๆอีกมาก (ขอละที่จะกล่าวถึงปัญหาเหล่านี้ก่อนนะครับ)
ตรงจุดนี้แหละ ที่ทำให้เกิดคำถามขึ้นว่า
1. “ไปทำยังไง ผู้บริหารถึงเกิดทัศนคติแบบนั้น ?” และ
2. “จะเปลี่ยนทัศนคติแบบนั้นของผู้บริหารได้อย่างไร ?“
ผมเชื่อว่า สิ่งสำคัญที่ต้องมีอยู่ในคำตอบของคำถามข้างต้นอย่างแน่นอน คือ “วินัย” และ “คำมั่นสัญญา” (Discipline and Commitment) ของทีมครับ เพราะหากขาดสิ่งนี้แล้ว สิ่งที่จะเหลือให้ผู้บริหารเชื่อถือได้ ก็คงไม่พ้น ตัวเลข และ กราฟ…
พี่คงอยู่ในบริษัทที่อะไรมัน control ง่าย มานานไปหน่อย
อย่างไรก็ดี การหาค่าวัดด้วยตัวเลข สำหรับงานการพัฒนา software ที่มีทั้งศาสตร์และศิลป์อยู่ด้วย คงจะไม่สามารถให้มุมมองที่ครอบคลุมได้ค่ะ และที่น่ากลัวยิ่งกว่าก็คือการเล่นเกมกับตัวเลข เหมือนกับ story points vs. man day เช่นเดียวกัน
พี่มีอีกค่าวัดนึงค่ะ ปริมาณความสุขของลูกค้าและคนทำงานค่ะ
ถ้าสิ่งที่เราทำไปตรงตามที่ลูกค้าต้องการ (แม้ว่าส่วนใหญ่เค้าไม่รู้ว่าเค้าต้องการอะไร แต่เราทำให้สามารถสนองเป้าหมายท้ายที่สุดของเค้าได้) มี defect น้อย (ซึ่งมันจะทำให้ลูกค้ามีความสุข โดยที่เค้าไม่รู้ตัว) คนทำก็ไม่ต้องมาตามเก็บ defect จำนวนมาก (คนทำก็มีความสุขโดยไม่รู้ตัวเหมือนกัน) และเป็นไปตามจำนวน iterations ที่ตกลงกันไว้ (ซึ่งที่บริษัทพี่คิดตังค์ตาม iteration ดังนั้น มันก็จะแปรตามความสุขของลูกค้าด้วยเช่นเดียวกัน) แล้วอย่างนี้ ถือว่าประสบความสำเร็จใน software project นี้ได้รึยังคะ?
ควบคุมดูแลง่ายที่พี่พูดถึง ผมขอตีความเอาเองว่า พื้นฐานก็มาจากวินัยของทีมนั่นแหละ หากเอาวิธีทำงานแบบ Agile ไปใช้กับทีมที่ขาดวินัยแล้ว มันจะไม่ได้ผลครับ ลองมาแล้ว
ทีมที่ผมคุ้นเคยจะชอบทำงานแบบ “ฝูงปลา” คือไม่ชอบให้ใครมาสั่งหรือควบคุมมากนัก ในขณะที่โลกการทำงานอื่นๆ ซึ่งมิได้จำกัดอยู่แค่สายIT ส่วนมากเขาไม่คุ้นกับวิธีแบบนี้ครับ แต่ก็ไม่ได้หมายความว่าเขาจะทำไม่ได้นะครับ ทุกอย่างล้วนเริ่มจากศูนย์
ค่าวัด “ปริมาณความสุขของลูกค้าและคนทำงาน” อันนี้ผมก็ชอบครับ แต่เกิดสถานการณ์เป็น “คนทำงานมีความสุข แต่ลูกค้าไม่สุขด้วย” อย่างนี้พี่แป๋มคิดว่า ต้องเปลี่ยนวิธีวัดไหมครับ?
“คนทำงานมีความสุข แต่ลูกค้าไม่สุขด้วย” ก็เป็นตัววัดที่เตือนว่า นี่เรากำลังเดินไปทางที่เหมาะสมรึเปล่า ลูกค้าเป็นคน set goal เราเป็นคนหาวิธี ดังนั้น ถ้าลูกค้าจะไม่สุข ก็คงเป็นเพราะ เราไม่ได้เดินไปทางซึ่งไปยัง goal ของเค้า รึเปล่า แล้วเราก็ต้องกลับมาคิดแล้วรึเปล่า ว่าจะต้องพัฒนา ปรับเปลี่ยน ตรงไหน
พี่ก็เลยว่า ค่าวัดพี่ก็ยังใช้ได้อยู่นะ
แต่ลูกค้าที่ไม่เข้าใจ agile นั้นยากนักที่จะทำให้เค้ามีความสุข agile มันเป็น another way of thinking สำหรับเค้า อันนี้ก็คงจะต้องแก้กัน case-by-case เท่าที่ทำได้ล่ะค่ะ อย่างที่หนังสือ agile retrospectives ว่าไว้ เราแก้ไขได้แค่ที่ตัวเอง ถ้าเรา set goal ของการแก้ไข ไว้ที่คนอื่น ยังไงก็ fail
และพี่ลืม login – -”