ล่า Ghost Engineer: มองให้เห็นผลงานที่แท้จริงของนักพัฒนา

“Ghost engineer” — นักพัฒนาหนึ่งในสิบแทบไม่ได้สร้างงานที่มีประโยชน์ แต่แสดงบทคนยุ่งได้อย่างแนบเนียน สาเหตุที่แท้จริง ไม่ว่าจะรับงานซ้อน หมดไฟ หรือเพียงแค่ไม่ยอมทำงาน อาจหลบสายตาฝ่ายบริหารได้นานมาก (งานวิจัย Stanford ปี 2024: เธรดต้นฉบับ)

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

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

แต่ปล่อยผีเหล่านั้นไปไม่ได้หรือ อย่างไรเสียบริษัทก็คงไม่เดือดร้อนกับเงินแค่นี้หรอก

ทว่าปัญหาอยู่ตรงนี้เอง…

เมื่อผมพูดถึงผลงานต่ำ ผมไม่ได้หมายถึง Alex ที่นั่งทำงานหนัก แต่ทำได้น้อยกว่า Ben อยู่ 10% ผมหมายถึงอีกแบบหนึ่ง: ทุกครั้งที่ stand-up ทั้งทีมต้องนั่งฟังเรื่องรันทดตอนใหม่—ทีมอื่นทำให้ล่าช้า ticket เขียนไม่ชัด ดวงไม่เป็นใจ แต่พรุ่งนี้งานเสร็จแน่นอน สาบานได้

เพียงแต่ “พรุ่งนี้” นั้นเคยเป็นเมื่อวานและเมื่อวานซืนมาแล้ว จนตอนนี้กลายเป็นธรรมเนียมประจำทีม

ทีมมองเรื่องแบบนี้ออกอย่างรวดเร็ว คนที่แบกงานจริงย่อมเริ่มสงสัยว่า จะทำงานจนหมดแรงไปทำไม ในเมื่อแค่เล่าเรื่องให้เก่งก็ไม่ต้องรับผลอะไรเลย

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

นั่นคือจุดเริ่มต้นของเรื่องยาว: รวบรวมข้อเท็จจริง ฟังทั้งสองฝ่าย ให้ feedback และให้เวลาสถานการณ์ดีขึ้น จากประสบการณ์ของผม ตอนจบที่พบบ่อยที่สุดคือ ghost engineer ย้ายไปหานายจ้างรายใหม่—ผู้โชคดีอย่างยิ่ง

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

ผู้จัดการจะเห็นปัญหาให้เร็วกว่านี้ได้ไหม—สังเกตความผิดปกติ ขอข้อมูลประกอบ และตรวจสอบก่อนทีมหมดความอดทนและบริษัทเสียทั้งเวลาและเงิน

เมื่อมีประสบการณ์มากพอ เรามักมองสถานการณ์เหล่านี้ล่วงหน้าได้จากรูปแบบพฤติกรรมบางอย่าง:

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

แต่ความสงสัยต้องมีร่องรอยดิจิทัลรองรับ

ลองดูเครื่องมือยอดนิยมสำหรับวัดประสิทธิภาพงานวิศวกรรม และดูว่ามันช่วยเปิดโปง ghost engineer ได้หรือไม่

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

หากต้องประเมินงานวิศวกรรมซอฟต์แวร์โดยตรง—ไม่ใช่ธุรกิจหรือผลิตภัณฑ์โดยรวม—ผมใช้สามแกนง่าย ๆ คือ ความเร็ว คุณภาพ และปริมาณ DORA บอกเรื่องความเร็ว ส่วนการทดสอบและ defect บอกเรื่องคุณภาพ ปริมาณนั้นยากกว่า นี่คือพื้นที่ที่ยังมีคนสำรวจน้อยที่สุด—และเป็นที่ที่ผีซึ่งเราตามหามักซ่อนตัว

DORA: ความเร็วและความน่าเชื่อถือของการ release

DORA แสดงว่าทีมส่งการเปลี่ยนแปลงขึ้น production ได้เร็วและเชื่อถือได้เพียงใด โมเดลปัจจุบันใช้ห้าตัวชี้วัด ได้แก่ เวลาจาก commit ถึง production ความถี่ในการ deploy สัดส่วน deployment ที่ทำให้เกิดความล้มเหลว เวลากู้คืน และสัดส่วนงานแก้ซ้ำที่ไม่ได้วางแผนไว้

มันเป็นตัววัดกระบวนการ delivery ที่ดี แต่ไม่ใช่ตัววัดผลงานรายบุคคล หากคนหนึ่งทำงานเท่ากับสามคน ขณะที่อีกคนซ่อนอยู่หลังผลลัพธ์รวมของทีม DORA จะไม่บอกคุณ

ตัวชี้วัดเหล่านี้ยังสะดวกอย่างยิ่งเมื่อนำไปใช้เป็น KPI ในบริษัทแห่งหนึ่งที่ผมเคยทำงาน เรา “รีด” มันมาตั้งแต่ปี 2018—แต่ง dashboard ทุกหน้าให้เป็นสีเขียวได้สำเร็จ และทุกคนก็มีความสุข โมเดล DORA ปัจจุบัน

การทดสอบและ defect: งานทำได้ดีแค่ไหน

วิธีเหล่านี้เป็นที่ยอมรับมานานและใช้ได้จริง เราควบคุมคุณภาพด้วย code review การทดสอบ และ static analysis ส่วนผลลัพธ์ติดตามผ่าน defect และ incident

แต่สัญญาณเหล่านี้ไม่บอกปริมาณงาน patch เล็ก ๆ ที่ไร้ที่ติเพียงชิ้นเดียวก็ทำให้ตัวชี้วัดทุกตัวเป็นสีเขียว—และผียังล่องหนต่อไป

Jira และ story point: ปิด ticket ไปกี่ใบ

Jira แสดง ticket ที่ปิดแล้วและ story point แต่ทีมเป็นผู้ประเมินเอง งานเดียวกันอาจตีเป็น 3 หรือ 13 point แยกเป็น 5 ticket หรือรวมไว้ในใบเดียวก็ได้

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

มันยังเป็น KPI ที่สะดวกอีกด้วย คนกรอกข้อมูลและย้าย ticket ไปมาเพียงเพื่อผ่าน quality gate เกิดงาน manual ไร้ประโยชน์จำนวนมาก

Commit และจำนวนบรรทัดโค้ด: ข้อเท็จจริงที่ไร้บริบท

Git ไม่ขึ้นกับการประเมินของทีม จึงชวนให้เรานับ commit และบรรทัดโค้ด แต่ 5 commit อาจเป็น patch เล็กเพียงชิ้นเดียว ขณะที่ squash commit เดียวอาจแทนงานทั้งสัปดาห์

การจัดรูปแบบ โค้ดที่ generate ขึ้นมา การคัดลอก และการย้ายโค้ด ล้วนทำให้จำนวนบรรทัดพองตัว ขณะที่การแก้ปัญหายาก ๆ อาจมีเพียงสิบบรรทัด

Swarmia, LinearB และ Waydev: ระบบวิศวกรรมทั้งหมดในที่เดียว

Swarmia, LinearB และ Waydev รวม Git, issue tracker และ CI/CD เข้าด้วยกัน ผู้จัดการดู DORA คิว review lead time ของการเปลี่ยนแปลง และผลสำรวจได้

มันให้ภาพที่มีประโยชน์ของระบบวิศวกรรม และบ่อยครั้งชี้ว่าปัญหาอยู่ที่กระบวนการ ไม่ใช่ตัวบุคคล แต่การวัดปริมาณงานของนักพัฒนาแต่ละคนบนสเกลที่เปรียบเทียบกันได้ ไม่ใช่คำถามหลักที่แพลตฟอร์มเหล่านี้ต้องการตอบ Swarmia, LinearB, Waydev

GitClear: สิ่งที่เหลือหลังตัด noise ในโค้ดออก

GitClear แยกโค้ดที่เพิ่ม ย้าย และคัดลอก ตัดไฟล์ที่ generate ขึ้นมาออก และคำนึงด้วยว่าโค้ดใหม่ถูกเขียนใหม่หรือลบทิ้งในภายหลังหรือไม่

ผลลัพธ์คือ Diff Delta—หน่วยเฉพาะของ GitClear สำหรับการเปลี่ยนแปลงที่มีความหมายและยังคงอยู่ใน codebase โค้ดที่คัดลอกมาหรือถูกทิ้งอย่างรวดเร็วมีน้ำหนักน้อยกว่าการเปลี่ยนแปลงขนาดกะทัดรัดที่ยังทำงานอยู่บน production วิธีทำงานของ Diff Delta

Diff Delta ไม่ตอบว่าต้องใช้แรงงานเท่าไร แต่มันตอบว่าหลังตัด noise และการแก้งานซ้ำแล้ว มีการเปลี่ยนแปลงที่มีความหมายเหลืออยู่เท่าไร จุดแข็งของ GitClear คือการวัดความคงทนและคุณภาพของโค้ด รวมถึงวิเคราะห์ผลกระทบของ AI

เริ่มใกล้ขึ้นแล้ว บริการนี้เผยแพร่ benchmark แต่ Diff Delta ยังเป็นหน่วยของตัวเอง ตัวเลขอย่าง 10,000 บอกอะไรได้น้อยหากไม่มีตัวเปรียบเทียบที่เหมาะสมและไม่เข้าใจวิธีคำนวณ ไม่มีจุดอ้างอิงชัด ๆ อย่าง “100% คือปกติ” Benchmark ของ Diff Delta

BlueOptima: คำถามเดียวกันในระดับองค์กรขนาดใหญ่

ผมรู้จัก BlueOptima จากประสบการณ์ตรง เริ่มใช้แพลตฟอร์มนี้ในปี 2019 และประสบการณ์นั้นเองเป็นแรงบันดาลใจให้ผมสร้างผลิตภัณฑ์ของตัวเอง

อัลกอริทึม Coding Effort วิเคราะห์การเปลี่ยนแปลง source code ทุกครั้งด้วยชุด static metric โดยคำนึงถึงขนาด ความซับซ้อน และความสัมพันธ์กับโค้ดส่วนอื่น แล้วแสดงผลออกมาเป็นจำนวนชั่วโมง

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

ในกรณีของผม การใช้ความสามารถระดับองค์กรเหล่านั้นต้องผ่านการติดตั้งที่ค่อนข้างหนัก ต้อง deploy agent ภายในเครือข่ายปิด ราคาสูง และผลลัพธ์ต้องอาศัยผู้เชี่ยวชาญตีความ

สำหรับบริษัทที่มีนักพัฒนาหลายพันคน เรื่องนี้อาจคุ้มค่า แต่สำหรับ startup หรือทีมเล็กอาจไม่ใช่ ช่องว่างนี้กลายเป็นหนึ่งในเหตุผลที่ DevGhost ถือกำเนิดในเวลาต่อมา

ไม้บรรทัดเดียวกัน โดยไม่ต้องผ่านการประมูล

ตอนสร้าง DevGhost ผมไม่ได้พยายามทำแพลตฟอร์ม all-in-one อีกตัวที่ยัดทุก metric ด้านวิศวกรรมเท่าที่นึกออก

ผมต้องการคำตอบเดียวกับที่ BlueOptima ให้—มีเนื้องานจริงอยู่เบื้องหลังการเปลี่ยนแปลงมากเพียงใด—แต่อยู่ในรูปที่เจ้าของ startup หรือทีมเล็กใช้ได้โดยไม่ต้องประมูล ไม่ต้องติดตั้งยืดเยื้อ และไม่ต้องมีทีมที่ปรึกษา

หลักการตรงไปตรงมา: DevGhost วิเคราะห์การเปลี่ยนแปลงโดยตรง—เพิ่มอะไร ลบอะไร ปรับโครงสร้างอะไร และผลลัพธ์นั้นสร้างและตรวจสอบยากเพียงใด การจัดรูปแบบ การย้ายโค้ด การแทนค่าจำนวนมากแบบอัตโนมัติ และโค้ดที่ generate ขึ้นมา จะถูกแยกออกจากเนื้องานจริง

ผลลัพธ์คือการประเมินความพยายามในรูปชั่วโมงเทียบเท่า: นักพัฒนาระดับกลางที่รู้จัก codebase และทำงานโดยไม่ใช้ AI จะต้องใช้เวลาเท่าไรจึงเขียนโค้ดเดียวกันได้ มันไม่ใช่เวลาที่นั่งกดแป้นพิมพ์จริง ไม่ใช่การตัดสินคุณภาพหรือคุณค่าทางธุรกิจของโค้ด แต่เป็นไม้บรรทัดร่วมสำหรับเปรียบเทียบการเปลี่ยนแปลง อ่านวิธีของ DevGhost เพิ่มเติม

Ghost% เปรียบเทียบค่าประเมินนั้นกับผลงานที่คาดจากนักพัฒนาระดับกลาง โดยคำนึงด้วยว่าเจ้าตัวใช้เวลาทำ development จริงมากน้อยเพียงใด ผล 100% หมายถึงอยู่ในเกณฑ์ ต่ำกว่านั้นเป็นเหตุให้ตรวจสอบ สูงกว่านั้นเป็นสิ่งที่ควรศึกษาและอาจพัฒนาเป็น best practice

เกณฑ์ตั้งใจสมมติให้ทำงานโดยไม่มี AI DevGhost ไม่พยายามตัดสินว่าโค้ดส่วนหนึ่งเขียนโดยคน Copilot หรือ autonomous agent แต่ประเมินการเปลี่ยนแปลงสุดท้ายว่า นักพัฒนาระดับกลางต้องใช้ความพยายามเท่าไรในการสร้างและตรวจสอบโดยไม่มี AI

เพราะฉะนั้น ผลของ AI จะไม่หายไปใน metric แต่จะมองเห็นได้ หากในช่วงหนึ่งนักพัฒนาสร้างและตรวจสอบผลงานที่เมื่อก่อนต้องใช้ความพยายามมากเป็นสองหรือสามเท่า Ghost% จะสะท้อนสิ่งนั้น การจัดรูปแบบ การ generate จำนวนมาก และ noise ในโค้ดรูปแบบอื่นไม่ควรสร้างผลแบบเดียวกัน

ใครจะตัดสินผู้ตัดสิน

คำถามที่ชัดที่สุดคือ ทำไมเราจึงควรเชื่อค่าประเมินที่เครื่องสร้างขึ้น คำตอบสั้น ๆ คือ ไม่ควรเชื่อแบบหลับหูหลับตา

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

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

นั่นคือเหตุผลที่ Ghost% เป็นสัญญาณ ไม่ใช่คำพิพากษา ผลต่ำอาจหมายถึงผลงานน้อย แต่อาจอธิบายได้ด้วยหน้าที่ team lead งานสถาปัตยกรรม การ mentoring incident หรือ blocker

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

“ผมรู้อยู่แล้วว่าแต่ละคนในทีมทำงานเป็นอย่างไร”

ลูกค้า DevGhost รายหนึ่งเป็นผู้นำฝ่ายวิศวกรรมของบริษัท AI ที่เติบโตเร็ว ช่วงแรกเขากังขาต่อแนวคิดวัดประสิทธิภาพงานวิศวกรรมเสียด้วยซ้ำ จุดยืนของเขาเรียบง่าย: ผู้นำเทคนิคที่ดีย่อมรู้ว่าใครทำงานอย่างไรโดยไม่ต้องมี dashboard

เราวิเคราะห์ประวัติ repository ที่เขารู้จักดี ก่อนหน้านั้นมีข้อสงสัยเกี่ยวกับนักพัฒนาสามคนอยู่แล้ว ticket ของพวกเขาเดินช้า แต่ทั้งสามทำบริการแยกต่างหาก จึงเปรียบเทียบกับคนอื่นในทีมได้ยาก DevGhost แสดงผลต่ำอย่างต่อเนื่องของทั้งสามคนเป็นเวลาราวหกเดือน

ต่อมา เมื่อนักพัฒนาเริ่มลาออก จึงพบว่าตลอดช่วงนั้นพวกเขาสร้างผลิตภัณฑ์ของตัวเองควบคู่ไปด้วย DevGhost ไม่อาจรู้สาเหตุ มันเพียงเปิดเผยสิ่งที่จำนวน commit, pull request และการคุยกันทุกวันใน Slack ไม่แสดงให้เห็น: ปริมาณงานต่ำกว่าที่คาดไว้อย่างชัดเจน

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

นักพัฒนาที่เขามองว่าเก่งก็ปรากฏตรงตำแหน่งที่คาดไว้พอดี และตอนนี้เขาเห็นไม่เพียงว่าใครทำผลงานเหนือความคาดหมาย แต่ยังเห็นว่าทำได้สม่ำเสมอแค่ไหน

แน่นอนว่ากรณีเดียวพิสูจน์ความแม่นยำของวิธีไม่ได้ สิ่งที่ทำให้ลูกค้าประหลาดใจคือภาพรวมตรงกับสิ่งที่ก่อนหน้านี้รู้เพียงจากความรู้สึก—และในบางกรณีเพิ่งชัดเจนเมื่อมองย้อนกลับไป—มากเพียงใด

ถ้านักพัฒนาคนหนึ่งสร้างผลงานเท่ากับสามคนล่ะ

การล่าผีเป็นส่วนที่เรียกความสนใจที่สุดของเรื่องนี้ แต่ส่วนบนของกราฟอาจมีประโยชน์มากกว่า

หากนักพัฒนาสร้างผลงานสูงกว่าค่าเฉลี่ยหลายเท่าอย่างต่อเนื่อง ก็ควรหาว่าเขาทำได้อย่างไร

ทุกวันนี้คำถามไม่ใช่ว่านักพัฒนาใช้ AI หรือไม่—สำหรับหลายคนมันกลายเป็นส่วนปกติของงานแล้ว คำถามคือเขาเปลี่ยน agent ให้เป็นกำลัง delivery เพิ่มเติมได้มีประสิทธิภาพเพียงใด

คนหนึ่งหยุดแค่ autocomplete อีกคนรู้วิธีให้ context ที่เหมาะสมแก่ agent ตั้งกฎชัดเจน ดำเนินหลายงานพร้อมกัน และตรวจผลงานอย่างละเอียด ดังนั้น การเข้าถึง AI แบบเดียวกันจึงสร้างการเพิ่ม productivity ที่ต่างกันอย่างสิ้นเชิง

Ghost% ที่สูงช่วยค้นหานักพัฒนาที่ใช้การทำงานร่วมกันระหว่างคนกับ agent ได้ผลดีอยู่แล้ว—และทำความเข้าใจว่าแนวปฏิบัติใดส่งต่อให้ทีมที่เหลือได้

หากผลสูงมีคุณภาพงานและการประเมินของผู้จัดการรองรับ นักพัฒนาคนนั้นควรได้รับการยอมรับ ควรรักษาเขาไว้ และควรได้รับการพิจารณาเลื่อนตำแหน่ง ส่วนแนวปฏิบัติของเขาก็ควรศึกษาและเผยแพร่ไปทั่วทีม

อย่าเปลี่ยนไม้บรรทัดให้เป็นอาวุธ

ทุก metric พบชะตากรรมเดียวกัน: ไม่ช้าก็เร็ว จะมีคนพยายามเปลี่ยนมันเป็น KPI Ghost% ไม่เหมาะกับเรื่องนั้น

ตั้ง Ghost% เป็น KPI ของทีม ผู้คนจะเริ่มปรับงานเพื่อเอาใจตัวเลข ประกาศอันดับ ความไว้ใจก็หาย เปลี่ยนคะแนนเป็นปุ่มไล่ออก ความผิดพลาดก็หลีกเลี่ยงไม่ได้

ผมจะตั้งกฎสี่ข้อ:

• อย่าสรุปจากการวัดครั้งเดียวหรือช่วงเวลาสั้น ๆ
• คำนึงถึงบทบาทของบุคคล สัดส่วนเวลาที่ใช้พัฒนา และงานนอกโค้ด
• แสดงผลให้นักพัฒนาดูและให้โอกาสอธิบายบริบท
• อย่าใช้ Ghost% เป็นเหตุผลเพียงอย่างเดียวในการตัดสินใจด้านการจ้างงาน

หากผลต่ำต่อเนื่อง ผู้จัดการควรตรวจสอบเหตุผลก่อน บางทีเจ้าตัวอาจทำผลงานไม่ได้จริง หรืออาจกำลังทำงานสถาปัตยกรรม รับมือ incident ของคนอื่น หรือถูกกระบวนการของทีมขัดขวาง

หากยืนยันว่ามีปัญหา ควรมีแผนปรับปรุงที่เฉพาะเจาะจง และประเมินอีกครั้งหลังระยะเวลาที่ตกลงกัน

การปฏิเสธ metric ไม่ได้ทำให้การประเมินคนหายไป มันเพียงเหลือความรู้สึก เรื่องเล่าใน stand-up และความชอบส่วนตัวของผู้จัดการ

ความเร็ว คุณภาพ และปริมาณต้องใช้เครื่องมือต่างกัน DORA แสดงว่าการเปลี่ยนแปลงเดินทางสู่ production อย่างไร การทดสอบและ defect แสดงคุณภาพ ส่วน DevGhost เพิ่มการประเมินความพยายามเบื้องหลังการเปลี่ยนแปลงโค้ด

ไม่มี metric ใดควรตัดสินใจแทนผู้จัดการ

คุณค่าของตัวเลขไม่ได้อยู่ที่การชี้ขาด แต่อยู่ที่การทำให้บทสนทนาที่ยากเริ่มเร็วขึ้น—และยืนอยู่บนข้อเท็จจริง

คุณประเมินปริมาณงานของนักพัฒนาอย่างไร และขีดเส้นระหว่างความโปร่งใสที่มีประโยชน์กับการสอดส่องไว้ตรงไหน