- เพื่อความสำเร็จด้านวิศวกรรม สิ่งสำคัญคือการสร้างความสมดุลระหว่าง 3 ด้าน ได้แก่ คุณภาพ (Quality), ความเร็ว (Velocity), ความพึงพอใจของนักพัฒนา (Happiness)
- ESSP (Engineering System Success Playbook) มอบเฟรมเวิร์ก 3 ขั้นตอนเพื่อปรับปรุงสิ่งเหล่านี้แบบบูรณาการ และ เพิ่มผลลัพธ์ทางธุรกิจให้สูงสุด
- ใช้ ตัวชี้วัดหลัก 12 รายการ ที่ออกแบบบนพื้นฐานของหลายเฟรมเวิร์ก เช่น SPACE, DevEx, DX Core 4, DORA เพื่อทำความเข้าใจสถานะปัจจุบันขององค์กร, กำหนดลำดับความสำคัญ ตามเป้าหมายการปรับปรุง และค่อย ๆ นำการเปลี่ยนแปลงไปใช้และปรับจูน
- ตัวชี้วัดทั้ง 12 รายการนี้ถูกออกแบบมาให้ติดตามแต่ละด้านได้ในเชิงปริมาณ และ ปรับให้เหมาะกับแต่ละองค์กรตามบริบทได้
- การปรับปรุงทั้งหมดตั้งอยู่บนพื้นฐานของ ความยั่งยืนในระดับทีม และ แนวคิดเชิงระบบ โดยเน้นแนวทางที่สมดุลซึ่งพิจารณาทั้ง ตัวชี้วัดนำและตัวชี้วัดตาม
- มุ่งเน้น การเปลี่ยนแปลงระยะยาวที่ยั่งยืน แทนการปรับปรุงแบบเร่งด่วน
- ESSP สามารถเริ่มต้นได้แม้ยังไม่มีเครื่องมือวัดของตัวเอง และการวินิจฉัยเบื้องต้นด้วยวิธีเชิงคุณภาพ เช่น แบบสำรวจ ก็มีประโยชน์
- GitHub เน้นย้ำผ่านกรณีศึกษาของตนเองว่า การปรับปรุงที่เน้นคุณภาพเป็นศูนย์กลาง ท้ายที่สุดแล้วส่งผลเชิงบวกต่อทั้งความเร็วและความพึงพอใจของนักพัฒนา
เมตริกความสำเร็จด้านวิศวกรรมของ GitHub
- Quality
- Change failure rate: อัตราความล้มเหลวของการเปลี่ยนแปลง
→ สัดส่วนของการเปลี่ยนแปลงที่ก่อให้เกิดเหตุขัดข้องหรือปัญหา
- วิธีคำนวณ:
(จำนวนการ deploy ที่ล้มเหลว / จำนวนการ deploy ทั้งหมด) × 100
- เคล็ดลับ: ควรตกลงกันภายในทีมให้ชัดเจนว่ากรณีใดจึงจะถือว่าเป็นความล้มเหลว (เช่น มีการ rollback, มี monitoring alert เป็นต้น)
- Failed deployment recovery time: เวลาฟื้นตัวจากการ deploy ที่ล้มเหลว
→ เวลาที่ใช้ในการย้อนกลับการ deploy ที่ล้มเหลว หรือกู้คืนให้กลับสู่สถานะปกติ
- วิธีคำนวณ: ค่ามัธยฐาน ของเวลา
จุดที่กู้คืนเสร็จสมบูรณ์ − จุดที่เกิดความล้มเหลว สำหรับแต่ละการ deploy ที่ล้มเหลว
- เคล็ดลับ: แนะนำให้ดึงข้อมูลอัตโนมัติจากระบบแจ้งเตือนหรือ log และควรใช้ ค่ามัธยฐาน แทนค่าเฉลี่ย (เพื่อหลีกเลี่ยงผลกระทบจากค่าผิดปกติ)
- Code security and maintainability: ความปลอดภัยและความสามารถในการบำรุงรักษาของโค้ด
- วิธีคำนวณ: ประเมินแบบองค์รวมจาก จำนวนช่องโหว่, ความซับซ้อน, coverage เป็นต้น ผ่าน static analysis tools, GitHub Advanced Security, CodeQL ฯลฯ
- เคล็ดลับ: ตั้งค่าการสแกนอัตโนมัติเป็นประจำ และใช้วัดผลของการ refactor หรือการเปลี่ยนนโยบายด้านความปลอดภัย
- Velocity
- Lead time: ระยะเวลานำ
→ เวลาที่ใช้ตั้งแต่มีการเปลี่ยนแปลงโค้ดจนถูกนำขึ้น production
- วิธีคำนวณ: เวลาตั้งแต่สร้าง PR ไปจนถึง deploy หลัง merge
- เคล็ดลับ: การใช้ ค่ามัธยฐาน แทนค่าเฉลี่ยจะช่วยลดความบิดเบือน หาก lead time ยาว ควรวัดเวลา waiting ของ PR หรือความล่าช้าในการรีวิวแยกต่างหาก
- Deployment frequency: ความถี่ในการ deploy
→ มีการ deploy ขึ้น production บ่อยเพียงใด
- วิธีคำนวณ: จำนวนครั้งของการ deploy ในช่วงเวลาที่กำหนด (รายวัน/รายสัปดาห์)
- เคล็ดลับ: ควรกำหนดให้ชัดเจนว่าจะนับการ deploy แบบอัตโนมัติรวมด้วยหรือไม่ และสำหรับทีมขนาดเล็ก การวัดรายสัปดาห์อาจเหมาะสมกว่า
- PRs merged per developer: จำนวน PR ที่ merge ต่อหนึ่งนักพัฒนา
- วิธีคำนวณ: จำนวน PR ที่ merge ทั้งหมด / จำนวนนักพัฒนาที่มีส่วนร่วม
- เคล็ดลับ: ใช้เพื่อวัดประสิทธิภาพของ workflow ของทีม ไม่ใช่เพื่อการเปรียบเทียบ และควรตีความร่วมกับขนาดหรือความซับซ้อนของ PR
- Developer Happiness
- Flow state experience: ประสบการณ์ภาวะลื่นไหลในการทำงาน
- วิธีคำนวณ: ประเมิน “ความถี่/ระยะเวลา” ของประสบการณ์การมีสมาธิจดจ่อในช่วงหลัง ผ่านแบบสำรวจนักพัฒนา
- เคล็ดลับ: แนะนำให้สำรวจเป็นประจำอย่างน้อยเดือนละครั้ง และหากมีคำตอบแบบบรรยายอิสระด้วย จะช่วยให้ได้ข้อมูลเชิงคุณภาพเพิ่มเติม
- Engineering tooling satisfaction: ความพึงพอใจต่อเครื่องมือวิศวกรรม
- วิธีคำนวณ: รวบรวมความพึงพอใจในการใช้เครื่องมือและข้อเสนอที่อยากให้ปรับปรุงผ่านแบบสำรวจนักพัฒนา
- เคล็ดลับ: หากแยกเป็นหัวข้อย่อยตามเครื่องมือแต่ละประเภท (เช่น IDE, CI, issue tracking ฯลฯ) จะช่วยให้หาแนวทางปรับปรุงที่ใช้งานได้จริง
- Copilot satisfaction: ความพึงพอใจในการใช้ Copilot
- วิธีคำนวณ: สำรวจความพึงพอใจของผู้ถือไลเซนส์ Copilot (NPS หรือคะแนน)
- เคล็ดลับ: แนะนำให้เปรียบเทียบตามช่วงเวลา เช่น ทันทีหลังเริ่มใช้งาน และ หลังผ่านไป 3 เดือน และสามารถใช้ feedback เพื่อปรับปรุงการอบรม/กรณีใช้งานได้
- Business Outcomes
- AI leverage: ระดับการใช้ประโยชน์จาก AI
- วิธีคำนวณ: สัดส่วน commit ที่ใช้ Copilot, อัตราการยอมรับคำแนะนำโค้ดจาก AI, เวลาใช้งาน เป็นต้น
- เคล็ดลับ: สามารถใช้ Copilot Telemetry API ของ GitHub หรือระบบวัดผลภายในได้ และจะมีประสิทธิภาพมากขึ้นเมื่อวิเคราะห์ร่วมกับ feedback เชิงคุณภาพ
- Engineering expenses to revenue: สัดส่วนรายจ่ายด้านวิศวกรรมต่อรายได้
- วิธีคำนวณ:
ค่าใช้จ่ายที่เกี่ยวข้องกับวิศวกรรม / รายได้รวม
- เคล็ดลับ: จำเป็นต้องจัดมาตรฐานเกณฑ์บัญชีภายใน และแนะนำให้วิเคราะห์แนวโน้มรายเดือนหรือรายไตรมาสเพื่อใช้ในการเปรียบเทียบ
- Feature engineering expenses to total engineering expenses: สัดส่วนค่าใช้จ่ายด้านการพัฒนาฟีเจอร์ต่อค่าใช้จ่ายด้านวิศวกรรมทั้งหมด
- วิธีคำนวณ:
(ค่าใช้จ่ายที่เกี่ยวข้องกับการพัฒนาฟีเจอร์ / ค่าใช้จ่ายด้านวิศวกรรมทั้งหมด)
- เคล็ดลับ: เพื่อให้วัดได้อย่างแม่นยำ ควรกำหนดเกณฑ์การจัดหมวดหมู่ ค่าใช้จ่ายที่ไม่เกี่ยวกับฟีเจอร์ เช่น การบำรุงรักษา, infrastructure, การทดสอบ ฯลฯ ไว้ล่วงหน้าให้ชัดเจน
[3 ขั้นตอนสู่ความสำเร็จด้านวิศวกรรม]
ขั้นตอนที่ 1: ระบุอุปสรรคต่อความสำเร็จในปัจจุบัน
- สิ่งสำคัญคือการระบุ ปัญหาของกระบวนการพัฒนาในปัจจุบัน และ อุปสรรคที่ขัดขวางความสำเร็จด้านวิศวกรรม
- สิ่งนี้ทำหน้าที่เป็น baseline สำหรับการกำหนดทิศทางและลำดับความสำคัญของการปรับปรุงในอนาคต
- แนวทาง
- วิเคราะห์ภาพรวมของ SDLC (Software Development Life Cycle) เพื่อค้นหาจุดคอขวด
- ที่ GitHub ใช้การวิเคราะห์โดยอิงจาก ตัวชี้วัดมาตรฐาน 12 รายการ แต่ก็สามารถเลือกใช้เพียงบางส่วนให้เหมาะกับลักษณะขององค์กรได้
- การมีส่วนร่วมของทีม
- ไม่ใช่ให้ผู้นำเพียงคนเดียว แต่ สมาชิกทั้งทีมต้องร่วมกันกำหนดกระบวนการปรับปรุง
- การเริ่มต้น บทสนทนาที่มีความหมาย ด้วยตัวชี้วัดเพียงไม่กี่ตัวก็เพียงพอแล้ว
- วิธีการ
-
1. ทำความเข้าใจกับโฟลว์พื้นฐาน
- แบ่งดูภาพรวมของกระบวนการวิศวกรรมดังนี้:
- วางแผน (Plan) → พัฒนา (Develop) → ตรวจทาน (Review) → บิลด์ (Build) → ทดสอบ (Test) → รีลีส (Release) → ปฏิบัติการ (Operate)
-
2. เก็บสัญญาณเชิงปริมาณ
- วิเคราะห์ข้อมูลเชิงปริมาณต่อไปนี้:
- รอบการ deploy: deploy บ่อยแค่ไหน
- Lead time: เวลาตั้งแต่เริ่มเขียนโค้ดจนถึง deploy
- อัตราความล้มเหลวของการเปลี่ยนแปลง: สัดส่วนที่เกิดข้อผิดพลาดหลัง deploy
- MTTR (เวลาเฉลี่ยในการกู้คืน): เวลาที่ใช้ในการกู้คืนหลังเกิดปัญหา
-
3. เก็บสัญญาณเชิงคุณภาพ
- รวบรวม ฟีดแบ็กจากประสบการณ์จริง ของนักพัฒนาและทีม:
- สมาชิกในทีม รู้สึกถึงความไร้ประสิทธิภาพเมื่อใด
- เครื่องมือหรือขั้นตอนใด ก่อปัญหาซ้ำ ๆ
- กิจกรรมใดสร้าง ภาระทางจิตใจมากที่สุด
- วิธีการ:
- ใช้ แบบสอบถาม, retrospective, การสัมภาษณ์ 1:1 เป็นต้น
- จะใช้ชุดคำถาม ESSP ที่กำหนดไว้ล่วงหน้าก็ได้
-
4. กำหนดปัญหาหลัก
- ใช้ข้อมูลที่เก็บมาเพื่อกำหนด อุปสรรค (Barrier)
- ตัวอย่าง:
- "Lead time ยาว ทำให้การพัฒนาฟีเจอร์ใหม่ล่าช้า"
- "Build ล้มเหลวบ่อย ทำให้ความน่าเชื่อถือของการ deploy ต่ำ"
- "นักพัฒนาต้องสลับบริบท (Context switching) บ่อย"
- ต้องอธิบายปัญหาให้อยู่ในรูปแบบที่ เฉพาะเจาะจงและสังเกตได้
-
5. จัดลำดับความสำคัญของตัวชี้วัด
- แทนที่จะพยายามปรับปรุงทุกตัวชี้วัดพร้อมกัน ให้โฟกัสที่ ตัวชี้วัด 1 หรือ 2 ตัวที่มีผลกระทบมากที่สุด
- ลำดับความสำคัญนี้จะกลายเป็น เกณฑ์สำหรับการทดลองปรับปรุงและการวัดผลลัพธ์ ใน Step 2 และ Step 3 ต่อไป
- เคล็ดลับเพื่อทำ Step 1 ให้สำเร็จ
- 1. โฟกัสที่ต้นตอ ไม่ใช่แค่สิ่งที่เห็นภายนอก
- อย่าตัดสินจากอาการที่ผิวเผินเท่านั้น แต่ต้อง เจาะลึกไปถึงรากของปัญหา
- ตัวอย่าง: สาเหตุที่ดูเหมือนว่าความเร็วช้าอาจเป็นเพราะ 'การทดสอบแบบแมนนวล' แต่สาเหตุจริงอาจเป็น การขาดความเชื่อมั่นใน automated test
- เพื่อการนี้ การอ้างอิง antipattern ที่พบบ่อยในงานวิศวกรรมซอฟต์แวร์จะเป็นประโยชน์
- 2. อ้างอิง antipattern
- antipattern หมายถึง แนวทางที่ถูกใช้บ่อย แต่ไม่ได้แก้ปัญหาจริง และอาจก่อให้เกิดผลข้างเคียงเสียด้วยซ้ำ
- ที่ GitHub มีการจัดเตรียมตัวอย่าง antipattern ที่อาจมีอยู่ในทีมไว้เป็นทรัพยากรแยกต่างหาก จึงสามารถ นำมาใช้เป็นเครื่องมือสำหรับการทบทวนภายในได้
- 3. ให้คนที่เหมาะสมเข้ามามีส่วนร่วม
- ใน Task 1 ของ Step 1 การ รับข้อมูลจากสมาชิกที่มีบทบาทหลากหลายเป็นเรื่องสำคัญ
- เช่น นักพัฒนา, ผู้ทดสอบ, ฝ่ายปฏิบัติการ, ฝ่ายความปลอดภัย, โปรดักต์แมเนเจอร์ เป็นต้น
- วิธีนี้ช่วยให้ เข้าใจ workflow โดยรวมได้อย่างรอบด้าน และไม่พลาดมุมมองเฉพาะด้านใดด้านหนึ่ง
- 4. ใช้ข้อมูลเชิงปริมาณและเชิงคุณภาพอย่างสมดุล
- ตัวชี้วัดเพียงอย่างเดียวไม่สามารถทำให้เข้าใจบริบททั้งหมดได้
- นอกจากการวิเคราะห์เชิงปริมาณแล้ว ยังต้องเก็บ ฟีดแบ็กเชิงคุณภาพเกี่ยวกับปัญหาทางจิตใจ วัฒนธรรม และการทำงานร่วมกันของทีม ด้วย
- ตัวอย่าง: ขวัญกำลังใจของทีมที่ตกต่ำ, การสื่อสารที่ขาดหาย, ความไม่พอใจที่สะท้อนในการ retrospective ล้วนไม่ปรากฏออกมาเป็นตัวเลข
- 5. อย่าเลือกอุปสรรคมากเกินไป
- อย่าพยายามแก้ทุกปัญหาในคราวเดียว แต่ให้โฟกัสที่ อุปสรรคที่มีผลกระทบสูงและเร่งด่วนที่สุด
- หากตั้งเป้าปรับปรุงหลายเรื่องเกินไปตั้งแต่แรก อาจ เสี่ยงต่อการสูญเสียแรงขับและโมเมนตัมในการลงมือทำ
- 6. สร้างความปลอดภัยทางจิตใจ
- ต้องสร้าง สภาพแวดล้อมที่สมาชิกในทีมสามารถแสดงความคิดเห็นอย่างตรงไปตรงมาได้ โดยไม่ต้องกลัวผลเสียหรือการตอบโต้
- นี่คือ เงื่อนไขสำคัญในการเปิดเผยปัญหาที่แท้จริง และช่วยเพิ่มความน่าเชื่อถือกับประสิทธิผลของกิจกรรมการปรับปรุง
- 7. การเปรียบเทียบมีไว้เพื่อการเรียนรู้ ไม่ใช่เพื่อการประเมิน
- การเปรียบเทียบตัวชี้วัดระหว่างทีมหรือความแตกต่างของ workflow ควรถูกใช้เพื่อ ดึง insight ออกมา มากกว่าการประเมินผลงานเชิงปริมาณ
- เนื่องจากแต่ละทีมมีสถานการณ์ เป้าหมาย tech stack และข้อจำกัดต่างกัน การเปรียบเทียบแบบตรง ๆ อาจนำไปสู่ความเข้าใจผิดได้
- ควรส่งเสริมวัฒนธรรมการเรียนรู้ที่ แบ่งปันว่าอะไรได้ผลดี และสกัดบทเรียนจากสิ่งนั้น
Step 2: ประเมินว่าสิ่งใดต้องทำเพื่อให้บรรลุเป้าหมายที่ตั้งไว้
- วัตถุประสงค์
- เป็นขั้นตอนในการ วิเคราะห์ว่าต้องดำเนินการเปลี่ยนแปลงอะไรบ้าง เพื่อแก้ไข ปัญหาหลัก (Barrier) ที่กำหนดไว้ใน Step 1
- ไม่ได้หยุดอยู่แค่การเพิ่มฟีเจอร์หรือเปลี่ยนเครื่องมือ แต่เป็นการระบุ ต้นเหตุเชิงรากและแนวทางแก้ไขในระดับองค์กร เทคโนโลยี และวัฒนธรรม
-
1. วิเคราะห์สาเหตุรากของสถานะปัจจุบัน
- อย่ามองแค่ผลลัพธ์อย่าง "ช้า" หรือ "ความพึงพอใจต่ำ" เท่านั้น แต่ต้องดูให้ลึกว่า
- ทำไม จึงช้า
- มีเหตุผลเชิงโครงสร้างหรือเชิงองค์กรอะไรอยู่เบื้องหลัง
- และต้องแยกให้ออกว่า อะไรเปลี่ยนได้และอะไรเปลี่ยนไม่ได้
- เครื่องมือที่ใช้ได้:
- เทคนิค 5 Whys
- แผนภาพ Fishbone (สาเหตุ-ผลลัพธ์)
- การวิเคราะห์ฟีดแบ็กเชิงคุณภาพจากการ retrospective ของทีม
-
2. หาแนวทางแก้ไขที่เป็นไปได้
- ระดมสมองหาแนวทางแก้ไขปัญหาในมิติ เทคนิค วัฒนธรรม และกระบวนการ
- ตัวอย่าง:
- ด้านเทคนิค: เพิ่มความเร็วในการทดสอบ, ปรับปรุง CI/CD pipeline
- ด้านวัฒนธรรม: ปรับแนวปฏิบัติการ code review, ปรับปรุง onboarding
- ด้านกระบวนการ: จำกัดขนาด PR, เปลี่ยนเกณฑ์การ merge
- แนวทางที่ GitHub แนะนำ:
- ใช้วิธีผสมระหว่าง แนวทางแก้ไขที่อิงจากการสังเกต กับ การปรับปรุงที่ยึดผู้คนเป็นศูนย์กลาง
-
3. ประเมินผลลัพธ์และความเสี่ยง
- สำหรับแต่ละแนวทางแก้ไข ให้ประเมินองค์ประกอบต่อไปนี้:
- ผลลัพธ์ที่คาดหวัง: จะส่งผลต่อเมตริกการปรับปรุงใดได้บ้าง
- ความเป็นไปได้ในการทำจริง: ทรัพยากรของทีมและความสามารถในการดำเนินการอย่างสมจริง
- การยอมรับในระดับองค์กร: ระดับการต่อต้านต่อการเปลี่ยนแปลง
- การแยกผลระยะสั้น/ระยะยาว: เห็นผลเร็วหรือเป็นการเปลี่ยนแปลงที่ยั่งยืน
- เพื่อการนี้ แนะนำให้ทำ Pilot (การทดลองใช้งานนำร่อง)
- ทดลองกับทีมขนาดเล็กก่อน แล้วเก็บฟีดแบ็กเพื่อตัดสินใจว่าจะขยายผลหรือไม่
-
4. จัดลำดับความสำคัญและสื่อสาร
- จากหลายแนวทางแก้ไข ให้ จัดลำดับความสำคัญ ตามเกณฑ์ต่อไปนี้:
- สิ่งที่สร้าง ผลกระทบมากที่สุด
- สิ่งที่ ลงมือทำได้จริงมากที่สุด
- สิ่งที่แก้ จุดเจ็บปวดที่เร่งด่วนที่สุด
- การตัดสินใจนี้ควร สื่อสารร่วมกับทีมและสร้างความเห็นพ้องร่วมกัน และ
- ควรระบุให้ชัดเจนในรูปแบบ OKR หรือเป้าหมายการปรับปรุง
- เคล็ดลับเพื่อทำ Step 2 ให้สำเร็จ
- 1. ต้องคำนึงถึงความยั่งยืนระยะยาวเสมอ
- หาก โฟกัสแต่ผลลัพธ์ระยะสั้น อาจยิ่งก่อให้เกิดปัญหาระยะยาว
- ตัวอย่าง: การนำเครื่องมือใหม่มาใช้อาจช่วยเพิ่มความเร็วได้ทันที แต่หากไม่มี การอบรม การสนับสนุน และการจัดการการเปลี่ยนแปลง ก็อาจยิ่งทำให้เกิดความผิดพลาดและความสับสน
- ดังนั้นทุกความพยายามในการปรับปรุงควรเป็น กลยุทธ์ที่คำนึงถึงทั้งการบำรุงรักษาและความสามารถในการขยายผล
- 2. คำนึงถึง trade-off ระหว่างแต่ละโซน (zone)
- ต้องระวังไม่ให้การเปลี่ยนแปลงที่ช่วยปรับปรุงด้านหนึ่ง (เช่น ความเร็ว) ไปแลกกับการเสียสละอีกด้านหนึ่ง (เช่น ความพึงพอใจของนักพัฒนา หรือคุณภาพ)
- ตัวอย่าง: การผ่อนปรนเกณฑ์การรีวิวอาจทำให้เร็วขึ้น แต่คุณภาพโค้ดหรือความเหนื่อยล้าของนักพัฒนาอาจแย่ลง
- ควรใช้แนวทางที่สมดุล โดย ตระหนักเสมอว่าผลกระทบมักครอบคลุมหลายด้านพร้อมกัน
- 3. ให้ทีมมีส่วนร่วมตั้งแต่ต้น
- ยิ่งเป็นการเปลี่ยนแปลงที่ทีมมีส่วนร่วมและร่วมกันสร้าง โอกาสสำเร็จก็ยิ่งสูง
- รับฟังความคิดเห็นของสมาชิกเพื่อให้การเปลี่ยนแปลงเกิดขึ้นแบบ bottom-up
- การเปลี่ยนแปลงแบบสั่งการจากบนลงล่างเพียงฝ่ายเดียว (top-down) อาจก่อให้เกิด แรงต้านและความไม่ใส่ใจ
- 4. กำหนดตัวชี้วัดความสำเร็จให้ชัดเจน
- ก่อนเริ่มใช้การเปลี่ยนแปลง ต้อง ตกลงร่วมกันก่อนว่าอะไรคือความสำเร็จ
- ตัวอย่าง: หากเป้าหมายคือ “ลดเวลาในการ deploy”
- ตัวชี้วัดตามหลัง: เวลาการ deploy จริงลดลง
- ตัวชี้วัดนำ: เวลารอของ PR ลดลง, จำนวนคำตอบในแบบสำรวจนักพัฒนาที่ระบุว่า 'รู้สึกว่า PR เร็วขึ้น' เพิ่มขึ้น
- อุดมคติคือการกำหนดทั้ง Leading Indicator และ Lagging Indicator ร่วมกัน
- 5. มุ่งทำการทดลองอย่างรวดเร็วมากกว่าทำแผนให้สมบูรณ์แบบ
- แนวทางแบบวนซ้ำที่ ลองเปลี่ยนแปลงเล็ก ๆ อย่างรวดเร็ว แล้วรับฟีดแบ็กมาปรับปรุง มีประสิทธิภาพมากกว่า
- ในช่วงแรก แม้จะยังไม่สมบูรณ์ก็ให้ ทดสอบในขนาดเล็ก ก่อน แล้วค่อยขยายผลเมื่อพิสูจน์แล้วว่าได้ผล
- วิธีนี้ช่วยลดโอกาสล้มเหลว และเอื้อต่อการเสริม ความคล่องตัวและความสามารถในการปรับตัว ของทีม
- 6. เริ่มจากการเปลี่ยนแปลงที่ใช้แรงน้อยแต่ให้ผลมาก
- เมื่อรายการสิ่งที่ต้องเปลี่ยนมีจำนวนมากและซับซ้อน ควรเลือกทำ แนวทางปรับปรุงในกลุ่ม “ผลสูง-ต้นทุนต่ำ” ก่อน
- ตัวอย่าง: การเพิ่มคู่มือรีวิวแบบง่าย ๆ หรือการลบการแจ้งเตือนที่ไม่จำเป็น สามารถทำได้รวดเร็วและส่งผลต่อความพึงพอใจได้มาก
- ประสบการณ์ความสำเร็จในช่วงต้น จะช่วยสร้างความมั่นใจให้ทีม และมอบ แรงขับเคลื่อน ให้เดินหน้าสู่ปัญหาที่ยากขึ้น
Step 3: นำการเปลี่ยนแปลงไปใช้ ติดตามผลลัพธ์ และปรับแก้
- นำ ความพยายามในการปรับปรุง (Intervention) ที่ได้จาก Step 2 ไปใช้จริงภายในองค์กร
และมุ่งสู่ความสำเร็จด้านวิศวกรรมอย่างต่อเนื่องด้วยการ วัดผลลัพธ์ พร้อมทั้ง ปรับแก้หรือปรับปรุงซ้ำ เมื่อจำเป็น
-
1. การนำไปปฏิบัติ (Implement the change)
- ก่อนลงมือทำ ต้องทำให้ชัดเจนในเรื่องต่อไปนี้:
- จะมีการเปลี่ยนแปลงอะไรบ้าง?
- ใครจะเป็นผู้รับผิดชอบ?
- จะประเมินโดยอิงจากตัวชี้วัดใด?
- จะวัดผลตั้งแต่เมื่อใดถึงเมื่อใด?
- สิ่งที่ควรพิจารณาระหว่างการดำเนินการ:
- กำหนดผู้รับผิดชอบ: ทำให้ความเป็นเจ้าของชัดเจน
- การ onboarding และการฝึกอบรมทีม: สมาชิกทุกคนในทีมต้องเข้าใจว่าทำไมการเปลี่ยนแปลงนี้จึงจำเป็น และอะไรที่จะเปลี่ยนไป
- จัดทำเอกสารการเปลี่ยนแปลง: เก็บบันทึกไว้เพื่อใช้อ้างอิงในการทบทวนย้อนหลังและการทำซ้ำในอนาคต
- ตัวอย่างการนำไปใช้:
- เปลี่ยนกลยุทธ์ build cache เพื่อปรับปรุงความเร็วของ CI/CD
- เปลี่ยนนโยบาย code review (เช่น กำหนดกติกาให้ตอบกลับภายใน 1 วัน)
-
2. การติดตามผล (Monitor the change)
- หลังจากนำแนวทางปรับปรุงไปใช้แล้ว ให้ ติดตามสังเกตผลลัพธ์ โดยใช้ตัวชี้วัดที่กำหนดไว้ล่วงหน้า
- lead time สั้นลงหรือไม่
- อัตราความล้มเหลวลดลงหรือไม่
- ความพึงพอใจของนักพัฒนาเพิ่มขึ้นหรือไม่ เป็นต้น
- เครื่องมือ:
- GitHub Insights, Copilot Telemetry, ระบบ BI ภายใน
- แดชบอร์ดรายงานรายสัปดาห์/รายเดือน
- แบบสำรวจนักพัฒนาหรือ feedback จาก retrospective
- ประเด็นสำคัญ:
- ต้องสามารถเปรียบเทียบกับ baseline ได้
- สิ่งสำคัญคือการดู แนวโน้ม (trend) ไม่ใช่ตัวเลขเพียงค่าเดียว
-
3. การเก็บ feedback (Collect feedback)
- นอกเหนือจากตัวชี้วัดเชิงปริมาณแล้ว ยังจำเป็นต้องเก็บ feedback ว่า จากมุมมองของนักพัฒนา การเปลี่ยนแปลงนี้ช่วยได้จริงหรือไม่
- ใช้ retrospective, แบบสำรวจนิรนาม, การประชุม 1:1 เป็นต้น
- ตรวจสอบว่า “ความรู้สึกที่รับรู้ได้” ของการปรับปรุงสูงหรือไม่ หรือกลับกลายเป็นการเปลี่ยนแปลงที่สร้างความเหนื่อยล้าหรือไม่
- การเปลี่ยนแปลงที่รีบดำเนินการโดยไม่มีฉันทามติในองค์กรอาจก่อให้เกิด การต่อต้านและแรงตีกลับ ได้
-
4. การปรับแก้หรือทำซ้ำ (Adjust as needed)
- หากผลของความพยายามในการปรับปรุงไม่เป็นไปตามที่คาดหวัง หรือมีผลข้างเคียง ให้รับมือดังนี้:
- ย้อนกลับหรือเสริม การเปลี่ยนแปลง
- คงไว้เพียงบางองค์ประกอบและ ลดขอบเขตลง
- ขยายการใช้งาน ไปยังวงกว้างขึ้น
- ไม่ว่าการเปลี่ยนแปลงจะสำเร็จหรือล้มเหลว ต้องเรียนรู้สิ่งต่อไปนี้เสมอ:
- องค์ประกอบใดได้ผล?
- อะไรคือปัจจัยที่เป็นอุปสรรค?
- ครั้งต่อไปควรเปลี่ยนอะไร?
- เคล็ดลับเพื่อให้ทำ Step 3 ได้สำเร็จ
- 1.อย่าคาดหวังความสมบูรณ์แบบในทันที
- ไม่ใช่ทุกการเปลี่ยนแปลงที่จะ สร้างการปรับปรุงที่เห็นได้ชัดทันที
- อาจต้องใช้ เวลา กว่าผลลัพธ์จะปรากฏ
- ทีมเองก็ต้องการ ช่วงเวลาในการปรับตัวต่อการเปลี่ยนแปลง ดังนั้น ความอดทนและการติดตามอย่างต่อเนื่อง จึงสำคัญ
- ในช่วงแรก การใช้ เครื่องมือ feedback เชิงคุณภาพ เช่น แบบสำรวจ เพื่อจับความรู้สึกต่อการเปลี่ยนแปลงถือว่ามีประโยชน์
- 2.ทำซ้ำและปรับปรุงการเปลี่ยนแปลงอย่างต่อเนื่อง
- แม้จะสำเร็จครั้งหนึ่ง ก็ไม่ใช่ว่า ต้องคงไว้แบบเดิม, เพราะการเปลี่ยนแปลงเองก็ต้อง พัฒนาและปรับให้เหมาะสม อย่างไม่หยุดนิ่ง
- เมื่อเกิดปัญหาใหม่หรือสภาพแวดล้อมภายนอกเปลี่ยนไป ก็อาจจำเป็นต้อง ทบทวนแนวทางปรับปรุงเดิมอีกครั้ง
- ควรสนับสนุนให้ทีม มองสิ่งนี้เป็นกิจกรรมประจำและรักษาวงจรการปรับปรุงอย่างต่อเนื่อง
- 3.ระวังผลข้างเคียงที่ไม่ได้ตั้งใจ
- การเปลี่ยนแปลงบางอย่างอาจก่อให้เกิด แรงเสียดทานที่คาดไม่ถึงในด้านอื่น
- เช่น: การเพิ่มความเร็วในการ deploy เป็นการเปลี่ยนแปลงที่ดี แต่ถ้าการตรวจสอบคุณภาพอ่อนแอ ก็อาจ นำไปสู่การเพิ่มขึ้นของบั๊กได้
- นอกจากตัวชี้วัดแล้ว ต้องดู การเปลี่ยนแปลงของ flow ของ workflow โดยรวม ควบคู่กันไป และหากพบสัญญาณผิดปกติต้อง รีบดำเนินการทันที
- 4.ตรวจสอบระดับความปลอดภัยทางจิตใจอย่างต่อเนื่อง
- แม้หลังการเปลี่ยนแปลงแล้ว ก็ต้องรักษา สภาพแวดล้อมที่ทีมสามารถหยิบยกปัญหาขึ้นมาพูดได้อย่างอิสระ
- เพื่อไม่ให้ “ปัญหาที่ไม่ถูกพูดถึง” สะสม จำเป็นต้องสร้าง บรรยากาศที่สมาชิกทีมสามารถให้ feedback อย่างตรงไปตรงมาได้
- เช่น ความไม่พอใจต่อ process ที่เปลี่ยนไป ภาระงานที่เพิ่มขึ้นมากเกินไป หรือความเครียดที่ไม่คาดคิด
- 5.ประเมินผลกระทบระยะยาวอย่างต่อเนื่อง
- หัวใจสำคัญไม่ใช่ผลลัพธ์ระยะสั้น แต่คือ ผลลัพธ์ที่ยั่งยืนและขวัญกำลังใจของทีมที่ดีขึ้น
- เมื่อเวลาผ่านไป ให้ ตรวจสอบอย่างต่อเนื่อง ว่า:
- การเปลี่ยนแปลง ฝังรากแล้วหรือยัง
- มี ผลข้างเคียงหรือปัญหาใหม่ เกิดขึ้นหรือไม่
- มี การรักษาระดับผลลัพธ์หรือการถดถอย หรือไม่
- 6.ใช้ feedback เป็นโอกาสในการเรียนรู้
- แม้แต่การเปลี่ยนแปลงที่ล้มเหลวก็เป็น ทรัพย์สินการเรียนรู้ที่มีค่า
- ต้อง วิเคราะห์จากข้อมูลและ feedback ว่าอะไรผิดพลาด และนำไปสะท้อนในการลองครั้งถัดไป
- วัฒนธรรมที่สำคัญคือการสนับสนุนให้ทีม มองความล้มเหลวเป็นโอกาสในการเรียนรู้ ด้วย
Beyond the steps: Make the playbook work for you
-
การปรับให้เหมาะกับบริบท (Tailoring)
- เลือก ตัวชี้วัดและวิธีการวัด (telemetry vs แบบสำรวจ) ให้เหมาะกับลักษณะขององค์กร
- อย่าให้การวัดกลายเป็นเป้าหมายในตัวเอง แต่ควรใช้เป็นเครื่องมือเพื่อการปรับปรุงที่เป็นรูปธรรม
-
การบริหารการเปลี่ยนแปลง (Change management)
- การใช้ เฟรมเวิร์กการบริหารการเปลี่ยนแปลง เช่น ADKAR หรือโมเดล Kotter มีความสำคัญในการช่วยให้องค์กรปรับตัวกับการเปลี่ยนแปลงได้ดี
-
แนวคิดแบบเติบโต (Growth mindset)
- มองทุกความพยายามเป็นโอกาสในการเรียนรู้ และ ทัศนคติที่ยอมรับความล้มเหลว คือหัวใจของการปรับปรุงอย่างต่อเนื่อง
-
Gamification
- การออกแบบรางวัลที่อิงกับแรงจูงใจ อาจสร้างผลเชิงบวกได้ แต่ถ้า ออกแบบไม่ดี ก็อาจทำให้คุณภาพลดลงหรือเกิดความไม่สมดุลได้
Alternatives to the GitHub Engineering System Success Playbook
- ขึ้นอยู่กับสถานการณ์ อาจใช้แนวทางที่ไม่ใช่ ESSP เช่น การวิเคราะห์แบบเรียบง่ายที่เน้นการใช้งานฟีเจอร์ หรือ กลยุทธ์การปรับปรุงที่อิงกับเครื่องมือรายตัว ได้
- สิ่งสำคัญคือ แนวทางที่สอดคล้องกับสภาพจริงของทีมและองค์กร พร้อมความพยายามในการปรับปรุงอย่างต่อเนื่อง
ยังไม่มีความคิดเห็น