การบรรลุ OKR vs. การทำงานตามหน้าที่

 (jessitron.com)
19 คะแนน โดย GN⁺ 2025-01-07 | 5 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในงานวิศวกรรม OKR (Objectives & Key Results) รายไตรมาสมักให้ความรู้สึกว่าซ้ำซ้อนกับการวางแผนผลิตภัณฑ์
    • โดยทั่วไปมักถูกตีความว่ามีความหมายเดียวกับ "การทำตามโรดแมป"
    • หาก OKR มีเนื้อหาที่ต่างจากโรดแมป ก็จะเกิดความขัดแย้งกับโรดแมป
    • ตัวอย่างสมมติ
      • Objective: ให้บริการ Frontend Observability
      • Key Result: ส่งมอบทุกฟีเจอร์ของเฟส 1
      • Key Result: รักษาอัตราข้อผิดพลาดให้อยู่ที่ 3% หรือต่ำกว่า
      • Key Result: มีผู้ใช้โต้ตอบ 1,000 คนต่อวัน
  • ในฝั่งการตลาด OKR รายไตรมาสช่วยสื่อเจตนาของบริษัทได้อย่างชัดเจนและทำงานได้อย่างมีประสิทธิภาพ
    • ทีมการตลาดมีข้อบ่นเรื่องการเขียน OKR น้อยกว่า
    • ตัวอย่างสมมติ
      • Objective: กระตุ้น pipeline ด้วยการเปิดตัว Frontend Observability
      • KR: มีสื่อ 3 แห่งรายงานข่าวการเปิดตัว
      • KR: Landing Page มียอดเข้าชม 2,000 ครั้ง
      • KR: ได้ Marketing Qualified Leads (MQL) 100 รายจากบัญชีเป้าหมาย
  • ทำไม OKR ในการตลาดถึงง่ายกว่า
    • ส่วนหนึ่งเป็นเพราะ:
      • งานการตลาดมีลักษณะคล้ายงานแบบโปรเจกต์ จึงสามารถทำเสร็จได้ภายในหนึ่งหรือสองไตรมาส
      • งานวิศวกรรมคล้ายงานผลิตภัณฑ์ที่ต้องดำเนินต่อเนื่อง และเดินไปตามจังหวะของการอัปเดตอย่างสม่ำเสมอ
    • แน่นอนว่าการตลาดก็มีจังหวะของงานที่ทำซ้ำเช่นกัน
      • โฆษณา, webinar, การส่งอีเมล, งานอีเวนต์ ฯลฯ
      • OKR ช่วยระบุให้ชัดว่าในไตรมาสนี้จะโฟกัสที่โฆษณา, webinar, หรืออีเวนต์ใด
      • สิ่งนี้อาจซ้ำกับ campaign brief ได้ แต่จะเน้นไปที่แคมเปญใหม่ กลุ่มเป้าหมายใหม่ หรือช่องทางใหม่
      • มันพูดถึงเพียงว่าในไตรมาสนี้ เราจะลงต้นทุนและเวลาไปกับ สิ่งใหม่ที่ไม่ได้ทำทุกไตรมาส อะไรบ้าง

โดยทั่วไป งานที่ทำเป็นประจำอย่างต่อเนื่องจะไม่แสดงอยู่ใน OKR และนั่นคือหน้าที่ของ KPI (ดัชนีชี้วัดผลงานหลัก)

  • ฝั่งการตลาดมี KPI สำหรับงานหลักอย่างการดึงดูด Lead ซึ่งจะกลายเป็น "โอกาสทางการขาย" และมีการติดตามตัวเลขเหล่านี้
    • เฝ้าดู web traffic, ประสิทธิภาพโฆษณา, อันดับ SEO, การเข้าร่วม webinar, และจำนวนการติดต่อจากอีเวนต์
    • ตัวเลข KPI เหล่านี้จะปรากฏใน OKR ก็ต่อเมื่อต้องการปรับปรุงหรือหาวิธีใหม่ เช่น กลุ่มเป้าหมายใหม่หรือข้อความสื่อสารใหม่
    • OKR ใช้เพื่อบอกถึงการเปลี่ยนจุดโฟกัส การเปลี่ยนกระบวนการ หรือบทสนทนาที่เราจำเป็นต้องมี
    • ตัวอย่างสมมติ
      • Objective: ขยายการรับรู้ของ Honeycomb ใน 3 ประเทศ
      • Objective: ลดต้นทุนต่อโอกาสทางการขาย
        • KR: เพิ่มอัตราแปลงจาก MQL ไปเป็น SQL จาก 7% เป็น 10%
      • Objective: หา 2 use case ที่คุ้มค่าแก่การลงทุน
  • ฝั่งวิศวกรรมมี KPI สำหรับงานหลักอย่างการรันซอฟต์แวร์และปล่อยอัปเดต
    • เราจะรู้ได้ว่าการทำงานราบรื่นจาก SLOs (Service-Level Objectives) และตัวชี้วัดด้านความเร็วอย่าง Deployment Frequency
    • การปล่อยฟีเจอร์ตามโรดแมปเป็นหนึ่งในงานหลัก และโดยทั่วไปไม่ควรถูกใส่ไว้ใน OKR
      • OKR ควรบอกว่าในไตรมาสนี้อะไรจะเปลี่ยนไป อะไรที่เราจะเปลี่ยน และอะไรที่เรากำลังพยายามค้นหา
    • ตัวอย่างสมมติ
      • Objective: เปิดตัว Frontend Observability อย่างราบรื่น
        • KR: อัตรา error ไม่เกิน 3%
      • Objective: ให้สมาชิกทีมใหม่ 3 คนเข้าไปอยู่ในตารางเวร On-Call
      • Objective: นำบริการของทีมอื่นมาใช้ 2 บริการ
      • Objective: ปรับปรุง responsiveness ของ Timeline View
        • KR: ระบุส่วนที่ทำให้เกิด latency ผ่าน distributed tracing
    • ในตัวอย่างข้างต้นมีคำว่า "เปิดตัว Frontend Observability อย่างราบรื่น" แต่แบบนั้นไม่ถือว่ารวมอยู่ใน "การปล่อยตามโรดแมป" อยู่แล้วหรือ?
      • การเปิดตัวฟีเจอร์เป็นเพียงส่วนหนึ่งของการเปิดตัวอย่างราบรื่น แต่ไม่ใช่ทั้งหมด
      • ในบรรดาฟีเจอร์ทั้งหมดที่เปิดตัวในไตรมาสนี้ ฟีเจอร์นี้คือสิ่งที่สำคัญต่อธุรกิจที่สุด
      • การที่ฟีเจอร์นี้อยู่ใน OKR เป็นการบอกให้ทุกคนรู้ว่าจะมีการผลักดันงานอื่นเพิ่มเติม ตอบสนองต่อรายงานบั๊กอย่างรวดเร็ว และสนับสนุนรีลีสนี้อย่างเต็มที่
    • หาก OKR ของทีมเป็นเพียงการพูดซ้ำโรดแมป ก็อาจตีความได้ว่าเป็น "ความตั้งใจจะรักษาสภาพเดิมไว้โดยไม่พยายามปรับปรุง"
      • กล่าวคือ มันอาจหมายถึง "ไตรมาสนี้เป็นไตรมาสแห่งการคงสภาพเดิม" ซึ่งไม่ใช่เรื่องดี
  • OKR คือการตอบคำถามว่า "อะไรคือความแตกต่างของไตรมาสนี้?" "มีอะไรใหม่?" "เราอยากเปลี่ยนไปอย่างไร?" "เราอยากค้นหาอะไร?"
    • ทำให้ OKR เน้นจุดโฟกัสที่พิเศษจริงๆ และ อย่าพยายามใส่ทุกอย่างลงไปใน OKR

บทความที่เกี่ยวข้อง

5 ความคิดเห็น

 
jhj0517 2025-01-07

ต่อไปคงต้องแยกให้ออกให้ดีระหว่างเป้าหมายที่สามารถแสดงผลลัพธ์เป็นตัวเลขได้ภายหลัง กับเป้าหมายที่ทำแบบนั้นไม่ได้
 
aer0700 2025-01-08

เวลาวางแผน ย่อมมีการคาดการณ์เกี่ยวกับสภาวะตลาดรวมอยู่ด้วย แต่ในบรรดาการคาดการณ์นั้น มีกี่เปอร์เซ็นต์ที่เป็นสถิติ และมีกี่เปอร์เซ็นต์ที่เป็นความหวังของ CEO กันแน่? คงเป็นเรื่องที่ยากจะอธิบายออกมาเป็นตัวเลขได้
 
roxie 2025-01-08

เป้าหมายอะไรบ้างที่คุณคิดว่าไม่สามารถวัดออกมาเป็นตัวเลขได้?
 
ethanhur 2025-01-07

OKRs, องค์กรแบบมีเป้าหมาย และ Agile ล้วนดู fancy และให้ความรู้สึกเหมือนจะช่วยแก้ปัญหาขององค์กรได้ แต่ผมคิดว่าอาจเป็นสิ่งที่นำไปปฏิบัติให้ดีได้จริงค่อนข้างยาก

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

https://x.com/sundarpichai/status/1543328071532523521
 
GN⁺ 2025-01-07
ความคิดเห็นจาก Hacker News

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

    • จากมุมมองของการคิดเชิงระบบ มีความคัดค้านต่อ OKRs อย่างเป็นพื้นฐาน เพราะมันลดกิจกรรมของมนุษย์ให้เหลือเป็นตัวเลข และทำให้หลุดออกจากปัญหาจริงจนมุ่งไปผิดทาง
    • นึกถึงเกร็ดที่อ่านในหนังสือ "The Essential Deming" ของ W. Edwards Deming บริษัทพยายามปรับปรุงระบบที่ไม่มีประสิทธิภาพในการขนน้ำมันด้วยเรือบาร์จ โดยผู้จัดการคนใหม่ได้สร้างตัวชี้วัดขึ้นมาแต่ไม่ได้ตั้งเป้าหมายไว้ ผลคือกัปตันเรือบาร์จเริ่มแข่งขันกันลดต้นทุนด้วยความสมัครใจ และโครงการนั้นก็ทำกำไรได้มาก

  • เฟรมเวิร์กสำหรับกำหนดลำดับความสำคัญและเป้าหมายของบริษัทอย่าง OKRs ช่วยให้มองเห็นความไม่สอดคล้องกันในวิธีที่แต่ละทีมจัดลำดับความสำคัญได้ อย่างไรก็ตาม บริษัทมักมองว่านี่เป็นเรื่องน่ารำคาญและพลาดโอกาสในการเรียนรู้

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

    • ในฐานะวิศวกร มีหลายอย่างที่รบกวน OKRs งานปฏิบัติการ และแผนรายสัปดาห์ PM ที่ดีสามารถลดสิ่งเหล่านี้ได้ แต่โดยมากแล้วไม่เป็นเช่นนั้น

  • บางคนไม่ได้สนใจ OKRs เลย ทำงานที่บริษัท 2-3 ปี ได้ขึ้นเงินเดือน ปีแรกทำแบบชิล ๆ ปีที่สองจริงจัง ปีที่สามก็เริ่มหางานใหม่

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

    • ตัวอย่างเช่น ทีมหนึ่งพยายามใช้คอนกรีตให้น้อยลง 15% ขณะที่อีกทีมพยายามทำให้อาคารสูงขึ้น 15% ซึ่งไม่ได้สะท้อนความต้องการของลูกค้าจริง

  • ชอบดูคนที่อยากได้ผลลัพธ์เร็ว ๆ ไปอ่านเรื่อง Agile, OKRs, KPIs แล้วพาตัวเองไปติดกับดัก ผู้จัดการเป็นคนยัดเยียดสิ่งเหล่านี้ และคนที่ไม่มีเวลาแม้แต่จะทำความเข้าใจก็ต้องเป็นคนเอาไปใช้

    • เมื่อคนหนุ่มสาวที่ทะเยอทะยานเป็นคนผลักดัน ทีมก็กลายเป็นไม่มีประสิทธิภาพ และทีมผลิตภัณฑ์ก็หมกมุ่นอยู่กับ OKRs

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

  • การเพิ่มตัวชี้วัดทุกตัวนำมาซึ่งภาษีด้านผลิตภาพ:

    1. เวลาที่ใช้ไปกับการบิดเบือนหรือเล่นกับตัวชี้วัด
    2. เวลาที่ใช้ไปกับการจัดทำเอกสารและทำให้ตัวชี้วัดเหล่านั้นปรากฏชัด