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

เอาต์พุตที่ขัดแย้งกัน

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

ตัววัด Dev เป็นชุดของตัววัดที่ช่วยให้ทีมวิศวกรติดตามความเร็ว (เคลื่อนที่เร็ว) และคุณภาพ (โดยไม่ทำให้สิ่งใดเสียหาย) โดยพื้นฐานแล้ว สามารถใช้เมตริกต่างๆ เพื่อวัดแอตทริบิวต์เหล่านี้ได้ รอบเวลา จำนวน PRs หรือปัญหาที่ปิดติดตามความเร็ว หากต้องการติดตามคุณภาพ ให้ตรวจสอบจำนวนข้อบกพร่อง เวลาเฉลี่ยในการแก้ปัญหา หรือจำนวนการปรับใช้ที่ทำให้เกิดความล้มเหลว เมตริกแต่ละรายการเหล่านี้จะให้ข้อมูลเชิงลึกที่แตกต่างกันเกี่ยวกับแอตทริบิวต์ที่คุณตรวจสอบ ตัวชี้วัดบางอย่างยังช่วยในการวิเคราะห์แอตทริบิวต์ของพร็อกซี ติดตามการทำงานซ้ำเพื่อวิเคราะห์ประสิทธิภาพ ซึ่งส่งผลต่อความเร็ว ความแม่นยำในการวางแผนเป็นตัวบ่งชี้ที่ดีของความสามารถในการคาดการณ์ ซึ่งช่วยให้ทั้งความเร็วและคุณภาพมีค่าในตัวมันเอง

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

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

วัดสิ่งที่สำคัญ

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

ประการแรก มันทำให้การสื่อสารง่ายขึ้น คู่ผลิตภัณฑ์ของคุณจะเข้าใจได้ง่ายขึ้นว่าเหตุใดจึงจำเป็นต้องจัดลำดับความสำคัญของการอัปเกรด DB เมื่อคุณระบุ KPI ที่ใช้ร่วมกันซึ่งจะได้รับอันตราย เพียงเพราะคุณทราบดีว่าหากคุณไม่จัดลำดับความสำคัญของการอัปเกรดฐานข้อมูล เรื่องราวของผู้ใช้สองสามรายต่อไปนี้จะใช้เวลานานเป็นสองเท่า และคุณจะต้องใช้เวลาในการบำรุงรักษา ซึ่งจะทำให้การเปิดตัวฟีเจอร์ล่าช้าไปจนถึงจุดที่คุณชนะ มีเวลาไม่เพียงพอที่จะบรรลุเป้าหมายการใช้งานที่คุณกำหนดเป็น KPI ไม่ได้หมายความว่าผลิตภัณฑ์ของคุณมีความชัดเจน ฉันหมายความว่านั่นเป็นการกระโดดมากมาย ทำไมไม่เริ่มต้นด้วยสิ่งที่สำคัญ? (ไม่ มันไม่ใช่การอัปเกรด DB)

ประการที่สอง การวัดทีมของฉันตามตัวชี้วัดทางธุรกิจทำให้ฉันเห็นว่าเราสามารถส่งผลกระทบต่อพวกเขาได้ไม่น้อย:

• เราสามารถระบุคุณสมบัติที่เราสามารถสร้าง 80% ของมูลค่าผู้ใช้สำหรับ 20% ของความพยายาม สิ่งนี้สามารถเพิ่มทรัพยากรเพื่อช่วยขับเคลื่อน KPI ของเราได้เร็วยิ่งขึ้น ในการทำเช่นนั้น ทีมจะต้องเข้าใจอย่างชัดเจนถึงเป้าหมายทางธุรกิจ ความต้องการของผู้ใช้ และแรงผลักดันในการปรับปรุง
• เราสามารถใช้ KPI เพื่อเป็นแนวทางว่าเราควรสะสมหนี้เทคโนโลยีใด: เรากำลังพยายามหาผู้ใช้ฟีเจอร์แรกของเรา และความล้มเหลวของฟีเจอร์เป็นตัวเลือกหรือไม่? ปล่อยตัวให้เร็วที่สุดแล้วค่อยมากังวลเรื่องหนี้เทคโนโลยีทีหลัง เรากำลังพยายามปรับปรุงการรักษาฐานลูกค้าจำนวนมากหรือไม่? มารับประกันคุณภาพสูงกันเถอะ
• เราสามารถแนะนำวิธีแก้ปัญหาสำหรับผลิตภัณฑ์ที่ไม่รู้จักแก้ไขได้ โดยอิงจากความก้าวหน้าทางเทคโนโลยีใหม่หรือมุมวิศวกรรมที่เป็นนวัตกรรมใหม่
• เราสามารถใช้ KPI เพื่อทำความเข้าใจว่าไม่มีประเด็นใดในการแสวงหาโซลูชันทางเทคโนโลยีที่ยอดเยี่ยมที่เราต้องการนำไปใช้ เนื่องจากปัญหานั้นไม่ได้มีความสำคัญต่อธุรกิจ

จะวัดความสำเร็จได้อย่างไร?

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

ที่ Epsagon เรามี OKR สำหรับทุกทีมผลิตภัณฑ์ และเป็นเป้าหมายของวิศวกร ผลิตภัณฑ์ และผู้ออกแบบที่สร้างทีมผลิตภัณฑ์ เมื่อดำเนินการแล้ว เรามีความร่วมมือที่ดีขึ้นระหว่างผลิตภัณฑ์และวิศวกรรม เถียงกันเรื่องข้อกำหนดน้อยลงและให้ความร่วมมือในการแก้ปัญหามากขึ้น นอกจากนี้ เรายังสังเกตเห็นว่าการเพิ่มขึ้นของความเป็นอิสระที่เกิดจากการกำหนดเป้าหมายเหนืองานช่วยเพิ่มนวัตกรรมและความเป็นเจ้าของเหนือผลลัพธ์ ทีมงานกำหนดแผนงาน และโซลูชันมาจากวิศวกรรมเช่นเดียวกับผลิตภัณฑ์

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

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

การสื่อสารคือกุญแจสำคัญ

เมื่อเรากำหนด KPI ของธุรกิจแล้ว ขั้นตอนต่อไปคือการปฏิบัติตาม จากประสบการณ์ของฉัน มีสองแง่มุมที่สำคัญในการสื่อสารและนำการเปลี่ยนแปลงนี้ไปใช้ ข้อแรกคือความสอดคล้อง: การตั้งเมตริกเหล่านั้นและกลับมาตรวจสอบอีกครั้งในอีก 3 เดือนให้หลังเท่านั้นยังไม่พอเพื่อดูว่าเราพลาดคะแนนของเรา ในฐานะผู้นำ เป็นหน้าที่ของเราในการตรวจสอบเมตริกเหล่านี้อย่างต่อเนื่องและตรวจสอบให้แน่ใจว่าสถานะและแผนการทำงานเพื่อปรับปรุงเมตริกนั้นได้รับการแจ้งไปยังทีมงานทั้งหมดของเราเสมอ

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

Dev Metrics เลิกใช้แล้วหรือไม่

แม้จะมีพาดหัวข่าวเกี่ยวกับการคลิกเหยื่อของบทความนี้ คำตอบคือไม่ — ควรใช้อย่างถูกต้องเท่านั้น ประการแรก เมตริกสำหรับนักพัฒนาคือเครื่องมือที่มีประสิทธิภาพสำหรับการแก้ปัญหาเมตริกธุรกิจของคุณ ตัวอย่างเช่น การลดลงของการรักษาผู้ใช้อาจอธิบายได้จากจำนวนข้อบกพร่องที่เพิ่มขึ้น ในกรณีนี้ คุณสามารถใช้เมตริก dev เป็นตัวบ่งชี้นำ: แทนที่จะรอให้การเก็บรักษาลดลง คุณควรตรวจสอบจำนวนข้อบกพร่องเพื่อป้องกันไม่ให้ลดลง (คล้ายกับวิธีที่คุณจะตรวจสอบการใช้งาน CPU เพื่อหลีกเลี่ยงข้อผิดพลาด 5xx API จำนวนนับ จากการขัดขวางและก่อให้เกิดอันตรายต่อผู้ใช้งานจริง) กรณีการใช้งานอื่นคือ dev metrics เป็นตัวบ่งชี้หลักสำหรับประสบการณ์และความพึงพอใจของนักพัฒนา (ซึ่งจะส่งผลต่อการรักษาของนักพัฒนา)

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

อะไรต่อไป?

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

• ฉันรู้หรือไม่ว่าผลลัพธ์ทางธุรกิจใดที่คาดหวังจากฉัน
• ฉันกำลังทำทุกวิถีทางเพื่อเพิ่มประสิทธิภาพให้กับผลลัพธ์เหล่านี้หรือไม่
• ฉันจะติดตามความสำเร็จได้อย่างไร อะไรคือเกณฑ์ในการยกธงหรือเปลี่ยนแผนของฉัน?
• ทีมของฉันทราบเป้าหมายทางธุรกิจและแผนงานที่จะบรรลุเป้าหมายหรือไม่ ข้อมูลของพวกเขาคืออะไร?
• KPI ของธุรกิจใดของฉันที่สามารถปรับปรุงได้โดยการปรับปรุงเมตริก dev ตัวใด