Playbook thành công cho hệ thống kỹ thuật của GitHub

• Để thành công trong kỹ thuật, điều quan trọng là phải duy trì sự hài hòa giữa ba lĩnh vực chất lượng (Quality), tốc độ (Velocity), mức độ hài lòng của lập trình viên (Happiness)
• ESSP (Engineering System Success Playbook) cung cấp một khung 3 bước nhằm cải thiện các lĩnh vực này một cách tích hợp để tối đa hóa kết quả kinh doanh
• Thông qua 12 chỉ số cốt lõi được thiết kế dựa trên nhiều framework như SPACE, DevEx, DX Core 4, DORA, tổ chức có thể nắm được hiện trạng, thiết lập thứ tự ưu tiên theo mục tiêu cải thiện, đồng thời từng bước triển khai và điều chỉnh thay đổi
  • 12 chỉ số này được cấu thành để có thể theo dõi định lượng từng lĩnh vực và có thể tùy biến theo bối cảnh của từng tổ chức
• Mọi cải tiến đều dựa trên tính bền vững ở cấp độ nhóm và tư duy hệ thống, nhấn mạnh cách tiếp cận cân bằng khi cùng xem xét chỉ số dẫn dắt và chỉ số kết quả
• Theo đuổi thay đổi dài hạn bền vững thay vì cải thiện nhanh trong ngắn hạn
• Có thể bắt đầu ESSP ngay cả khi chưa có công cụ đo lường riêng, và chẩn đoán ban đầu bằng các phương pháp định tính như khảo sát cũng rất hữu ích
• GitHub nhấn mạnh qua chính trường hợp của mình rằng các cải tiến tập trung vào chất lượng cuối cùng cũng tạo tác động tích cực đến tốc độ và mức độ hài lòng của lập trình viên

Các chỉ số thành công kỹ thuật của GitHub

• Quality
  • Change failure rate: Tỷ lệ thay đổi thất bại
    → Tỷ lệ các thay đổi gây ra sự cố hoặc vấn đề
    • Cách tính: (số lần triển khai thất bại / tổng số lần triển khai) × 100
    • Mẹo: Cần thống nhất rõ trong nhóm tiêu chí nào được xem là thất bại (ví dụ: có rollback hay không, cảnh báo từ hệ thống giám sát, v.v.)
  • Failed deployment recovery time: Thời gian khôi phục sau triển khai thất bại
    → Thời gian cần để hoàn tác một lần triển khai thất bại hoặc khôi phục về trạng thái bình thường
    • Cách tính: trung vị của khoảng thời gian từ thời điểm xảy ra lỗi đến thời điểm hoàn tất khôi phục của từng lần triển khai thất bại
    • Mẹo: Khuyến nghị trích xuất tự động từ hệ thống cảnh báo hoặc log. Nên dùng trung vị thay vì giá trị trung bình để tránh ảnh hưởng của các giá trị cực đoan
  • Code security and maintainability: Bảo mật và khả năng bảo trì mã nguồn
    • Cách tính: Đánh giá tổng hợp các yếu tố như số lượng lỗ hổng, độ phức tạp, độ bao phủ thông qua công cụ phân tích tĩnh, GitHub Advanced Security, CodeQL, v.v.
    • Mẹo: Thiết lập quét tự động định kỳ. Có thể dùng để đo hiệu quả của việc refactor hoặc thay đổi chính sách bảo mật
• Velocity
  • Lead time: Lead time
    → Thời gian từ khi thay đổi mã nguồn được tạo ra đến khi được phản ánh lên production
    • Cách tính: Thời gian từ lúc PR được tạo cho đến khi được merge và triển khai sau đó
    • Mẹo: Dùng trung vị thay vì trung bình sẽ giảm méo số liệu. Nếu lead time dài, nên đo riêng thời gian chờ PR hoặc độ trễ trong review
  • Deployment frequency: Tần suất triển khai
    → Việc triển khai lên production diễn ra thường xuyên đến mức nào
    • Cách tính: Số lần triển khai trong một khoảng thời gian nhất định (theo ngày/tuần)
    • Mẹo: Cần làm rõ có tính cả triển khai tự động hay không; với nhóm nhỏ, mốc theo tuần có thể phù hợp hơn
  • PRs merged per developer: Số PR được merge trên mỗi lập trình viên
    • Cách tính: Tổng số PR được merge / số lập trình viên có đóng góp
    • Mẹo: Hãy dùng chỉ số này để đo hiệu quả workflow của nhóm, không phải làm công cụ so sánh. Cần diễn giải cùng với kích thước hoặc độ phức tạp của PR
• Developer Happiness
  • Flow state experience: Trải nghiệm trạng thái tập trung cao độ
    • Cách tính: Đánh giá bằng khảo sát lập trình viên về “tần suất/thời lượng trải nghiệm trạng thái tập trung gần đây”
    • Mẹo: Khuyến nghị khảo sát định kỳ ít nhất mỗi tháng một lần. Nếu có thêm câu trả lời dạng tự do, có thể thu được insight định tính
  • Engineering tooling satisfaction: Mức độ hài lòng với công cụ kỹ thuật
    • Cách tính: Thu thập mức độ hài lòng khi sử dụng công cụ và các hạng mục mong muốn cải thiện thông qua khảo sát lập trình viên
    • Mẹo: Nếu chia chi tiết theo từng loại công cụ (IDE, CI, theo dõi issue, v.v.) thì có thể rút ra các điểm cải thiện thực tế
  • Copilot satisfaction: Mức độ hài lòng khi sử dụng Copilot
    • Cách tính: Khảo sát mức độ hài lòng đối với những người có giấy phép Copilot (NPS hoặc chấm điểm)
    • Mẹo: Nên so sánh theo từng mốc thời gian như ngay sau khi triển khai và sau 3 tháng. Có thể cải thiện hoạt động đào tạo/case ứng dụng thông qua phản hồi
• Business Outcomes
  • AI leverage: Mức độ tận dụng AI
    • Cách tính: Tỷ trọng commit dùng Copilot, tỷ lệ chấp nhận gợi ý mã của AI, thời gian sử dụng, v.v.
    • Mẹo: Có thể dùng Copilot Telemetry API của GitHub hoặc hệ thống đo lường nội bộ. Khi phân tích cùng phản hồi định tính sẽ hiệu quả hơn
  • Engineering expenses to revenue: Tỷ lệ chi phí kỹ thuật trên doanh thu
    • Cách tính: chi tiêu liên quan đến kỹ thuật / tổng doanh thu
    • Mẹo: Cần chuẩn hóa tiêu chuẩn kế toán nội bộ. Khuyến nghị phân tích xu hướng theo tháng hoặc theo quý để so sánh
  • Feature engineering expenses to total engineering expenses: Tỷ trọng chi phí phát triển tính năng trên tổng chi phí kỹ thuật
    • Cách tính: (chi tiêu liên quan đến phát triển tính năng / tổng chi tiêu kỹ thuật)
    • Mẹo: Để đo chính xác, cần làm rõ trước tiêu chí phân loại các chi phí ngoài tính năng như bảo trì, hạ tầng, kiểm thử

[3 bước để đạt thành công trong kỹ thuật]

Bước 1: Xác định các rào cản hiện tại đối với thành công

• Việc xác định các vấn đề trong quy trình phát triển hiện tại và những rào cản cản trở thành công kỹ thuật là then chốt
• Đây đóng vai trò là đường cơ sở (baseline) để thiết lập hướng cải thiện và mức độ ưu tiên trong tương lai
• Cách tiếp cận
  • Phân tích toàn bộ luồng SDLC (Software Development Life Cycle) để xác định các điểm nghẽn
  • Tại GitHub, việc phân tích dựa trên 12 chỉ số tiêu chuẩn, nhưng cũng có thể chỉ sử dụng một phần tùy theo đặc thù tổ chức
• Sự tham gia của nhóm
  • Không phải một lãnh đạo đơn lẻ mà toàn bộ thành viên trong nhóm phải cùng nhau xác định quy trình cải thiện
  • Chỉ cần bắt đầu một cuộc đối thoại có ý nghĩa bằng một số ít chỉ số cũng là đủ
• Phương pháp luận

  • 1. Hiểu luồng cơ bản

    • Toàn bộ luồng kỹ thuật được chia ra và xem xét như sau:
      • Lập kế hoạch (Plan) → Phát triển (Develop) → Rà soát (Review) → Build → Kiểm thử (Test) → Phát hành (Release) → Vận hành (Operate)

  • 2. Thu thập tín hiệu định lượng

    • Phân tích dữ liệu định lượng như sau:
      • Chu kỳ triển khai: triển khai thường xuyên đến mức nào
      • Lead time: thời gian từ lúc viết mã đến khi triển khai
      • Tỷ lệ thất bại của thay đổi: tỷ lệ phát sinh lỗi sau khi triển khai
      • MTTR (thời gian khôi phục trung bình): thời gian cần để khôi phục sau khi xảy ra sự cố

  • 3. Thu thập tín hiệu định tính

    • Thu thập phản hồi dựa trên trải nghiệm của lập trình viên và nhóm:
      • Thành viên nhóm cảm thấy sự kém hiệu quả vào lúc nào
      • Công cụ hay quy trình nào liên tục gây ra vấn đề
      • Hoạt động nào gây áp lực tâm lý lớn nhất
    • Cách thực hiện:
      • Sử dụng khảo sát, hồi cứu, phỏng vấn 1:1 v.v.
      • Cũng có thể dùng danh sách câu hỏi ESSP được định nghĩa sẵn

  • 4. Xác định vấn đề cốt lõi

    • Dùng dữ liệu đã thu thập để xác định rào cản (Barrier)
    • Ví dụ:
      • "Lead time dài khiến việc phát triển tính năng mới bị chậm trễ"
      • "Build thường xuyên thất bại nên độ tin cậy của triển khai thấp"
      • "Lập trình viên thường xuyên phải chuyển đổi ngữ cảnh (context switching)"
    • Vấn đề phải được phát biểu dưới dạng cụ thể và có thể quan sát được

  • 5. Chọn mức ưu tiên cho chỉ số

    • Thay vì cải thiện tất cả chỉ số cùng lúc, hãy tập trung vào một hoặc hai chỉ số có tác động lớn nhất
    • Mức ưu tiên này sẽ trở thành tiêu chí để thử nghiệm cải thiện và đo lường kết quả trong Step 2 và Step 3 sau đó
• Mẹo để thực hiện thành công Step 1
  • 1. Tập trung vào nguyên nhân gốc rễ chứ không phải biểu hiện bên ngoài
    • Đừng chỉ nhìn vào triệu chứng bề mặt để phán đoán, mà phải đào sâu đến tận gốc của vấn đề
      • Ví dụ: có vẻ nguyên nhân tốc độ chậm là do 'kiểm thử thủ công', nhưng nguyên nhân thực sự có thể là thiếu niềm tin vào kiểm thử tự động
    • Vì vậy, sẽ hữu ích nếu tham khảo các antipattern thường gặp trong kỹ thuật phần mềm
  • 2. Tham khảo antipattern
    • Antipattern là cách làm thường được sử dụng nhưng không giải quyết được vấn đề thực tế, thậm chí còn có thể gây ra tác dụng phụ
    • GitHub cung cấp riêng các ví dụ về antipattern có thể tồn tại trong nhóm dưới dạng tài nguyên riêng, nên có thể dùng làm công cụ tự rà soát
  • 3. Hãy để đúng người tham gia
    • Ở Task 1 của Step 1, việc nhận đầu vào từ các thành viên thuộc nhiều vai trò khác nhau là rất quan trọng
      • Ví dụ: lập trình viên, tester, vận hành, bảo mật, product manager v.v.
    • Làm như vậy sẽ giúp hiểu quy trình làm việc tổng thể theo góc nhìn đa chiều và tránh bỏ sót một góc nhìn cụ thể nào
  • 4. Cân bằng giữa dữ liệu định lượng và dữ liệu định tính
    • Chỉ riêng metric (chỉ số) là không đủ để hiểu toàn bộ bối cảnh
    • Ngoài phân tích định lượng, còn cần thu thập phản hồi định tính về các vấn đề tâm lý, văn hóa và hợp tác của các thành viên trong nhóm
    • Ví dụ: tinh thần nhóm suy giảm, thiếu giao tiếp, hay bất mãn trong các buổi hồi cứu là những điều không thể hiện qua con số
  • 5. Đừng chọn quá nhiều rào cản
    • Đừng cố giải quyết mọi vấn đề cùng lúc, mà hãy tập trung vào rào cản có tác động lớn nhất và cấp bách nhất
    • Nếu ôm quá nhiều nhiệm vụ cải thiện ngay từ đầu, sẽ có nguy cơ đánh mất năng lực thực thi và đà tiến triển
  • 6. Đảm bảo an toàn tâm lý
    • Cần tạo ra môi trường nơi các thành viên có thể thẳng thắn nêu ý kiến mà không sợ bất lợi hay bị trả đũa
    • Đây là điều kiện cốt lõi để bộc lộ vấn đề thật sự, đồng thời nâng cao độ tin cậy và hiệu quả của hoạt động cải thiện
  • 7. So sánh là để học hỏi chứ không phải để đánh giá
    • Việc so sánh chỉ số giữa các nhóm hay khác biệt trong quy trình làm việc nên được dùng để rút ra insight hơn là để đánh giá hiệu suất định lượng
    • Vì mỗi nhóm có hoàn cảnh, mục tiêu, tech stack và điều kiện ràng buộc khác nhau nên so sánh đơn thuần có thể dẫn đến hiểu lầm
    • Thay vào đó, nên khuyến khích văn hóa học hỏi, chia sẻ điều gì đang hoạt động tốt và rút ra bài học

Bước 2: Đánh giá những gì cần làm để đạt được mục tiêu đã đề ra

• Mục đích
  • Đây là bước phân tích cần thực hiện những thay đổi nào để giải quyết vấn đề cốt lõi (Barrier) đã được xác định ở Step 1
  • Không chỉ dừng ở việc đưa vào một tính năng hay thay đổi công cụ đơn thuần, mà còn xác định nguyên nhân gốc rễ và giải pháp ở cấp độ tổ chức, kỹ thuật và văn hóa

• 1. Phân tích nguyên nhân gốc rễ của trạng thái hiện tại

  • Thay vì chỉ nhìn vào kết quả như “tốc độ chậm” hay “mức độ hài lòng thấp”, cần phải phân biệt:
    • vì sao lại chậm,
    • có những lý do mang tính cấu trúc hay tổ chức nào,
    • đâu là những thứ có thể thay đổi và những thứ không thể thay đổi
  • Công cụ có thể sử dụng:
    • kỹ thuật 5 Whys
    • sơ đồ xương cá (nguyên nhân-kết quả)
    • phân tích phản hồi định tính trong các buổi retrospective của nhóm

• 2. Đưa ra các giải pháp khả thi

  • Brainstorm các giải pháp về kỹ thuật, văn hóa và quy trình cho vấn đề
  • Ví dụ:
    • Kỹ thuật: cải thiện tốc độ kiểm thử, cải tiến pipeline CI/CD
    • Văn hóa: chuẩn hóa thực hành code review, cải thiện onboarding
    • Quy trình: giới hạn kích thước PR, thay đổi tiêu chí merge
  • Phương pháp được GitHub khuyến nghị:
    • kết hợp giải pháp dựa trên quan sát với các cải tiến lấy con người làm trung tâm

• 3. Đánh giá hiệu quả và rủi ro

  • Với mỗi giải pháp, hãy đánh giá các yếu tố sau:
    • Hiệu quả kỳ vọng: có thể tác động đến chỉ số cải thiện nào
    • Tính khả thi: nguồn lực của nhóm và năng lực triển khai thực tế
    • Mức độ chấp nhận trong tổ chức: mức độ kháng cự với thay đổi
    • Phân biệt hiệu quả ngắn hạn/dài hạn: cho kết quả nhanh hay là thay đổi bền vững
  • Vì vậy, nên khuyến nghị Pilot (thử nghiệm thí điểm)
    • thử trước với một nhóm nhỏ, thu thập phản hồi rồi quyết định có mở rộng hay không

• 4. Chọn ưu tiên và truyền đạt

  • Trong nhiều giải pháp, hãy ưu tiên hóa theo các tiêu chí sau:
    • những gì có thể tạo ra tác động lớn nhất
    • những gì khả thi nhất để thực hiện
    • những gì giải quyết điểm đau cấp bách nhất
  • Quyết định này cần được chia sẻ với các thành viên trong nhóm và tạo được sự đồng thuận, đồng thời
    • nên được nêu rõ dưới dạng OKR hoặc mục tiêu cải tiến
• Mẹo để thực hiện Step 2 thành công
  • 1. Nhất định phải cân nhắc tính bền vững dài hạn
    • Nếu chỉ tập trung vào thành tích ngắn hạn thì ngược lại có thể gây ra vấn đề dài hạn
      • Ví dụ: việc đưa vào công cụ mới có thể cải thiện tốc độ ngay lập tức, nhưng nếu không đi kèm đào tạo, hỗ trợ và quản lý thay đổi thì ngược lại có thể gây ra sai sót và nhầm lẫn
    • Vì vậy, bất kỳ nỗ lực cải tiến nào cũng phải là chiến lược có tính đến cả khả năng bảo trì và mở rộng
  • 2. Cân nhắc trade-off giữa các vùng (zone)
    • Cần chú ý để thay đổi giúp cải thiện một vùng (ví dụ: tốc độ) không làm hy sinh vùng khác (ví dụ: mức độ hài lòng của nhà phát triển, chất lượng)
      • Ví dụ: nới lỏng tiêu chí review có thể làm tăng tốc độ nhưng lại làm xấu đi chất lượng mã hoặc mức độ mệt mỏi của nhà phát triển
    • Luôn cần một cách tiếp cận cân bằng, có tính đến việc phạm vi ảnh hưởng trải dài trên nhiều vùng
  • 3. Hãy cho nhóm tham gia ngay từ đầu
    • Thay đổi mà chính nhóm trực tiếp tham gia và cùng tạo ra sẽ có xác suất thành công cao hơn
    • Thu thập ý kiến của các thành viên để thay đổi có thể diễn ra theo hướng bottom-up
    • Thay đổi mang tính chỉ đạo một chiều theo kiểu top-down có thể dẫn đến sự kháng cự và thờ ơ
  • 4. Hãy định nghĩa rõ các chỉ số thành công
    • Trước khi triển khai thay đổi, cần thống nhất điều gì được xem là thành công
    • Ví dụ: nếu mục tiêu là “rút ngắn thời gian triển khai”,
      • chỉ số kết quả: thời gian triển khai thực tế giảm
      • chỉ số dẫn dắt: thời gian chờ PR giảm, số câu trả lời trong khảo sát nhà phát triển cho biết “cảm nhận tốc độ PR được cải thiện” tăng lên
    • Lý tưởng nhất là định nghĩa cả chỉ số dẫn dắt (Leading Indicator) và chỉ số kết quả (Lagging Indicator)
  • 5. Ưu tiên thử nghiệm nhanh hơn là lập kế hoạch hoàn hảo
    • Cách tiếp cận lặp lại với việc nhanh chóng thử ngay cả những thay đổi nhỏ, nhận phản hồi rồi cải thiện sẽ hiệu quả hơn
      • Ban đầu, dù thử nghiệm chưa hoàn hảo thì vẫn nên thử ở quy mô nhỏ, rồi mở rộng khi hiệu quả đã được chứng minh
    • Điều này có lợi cho việc giảm khả năng thất bại và tăng cường sự linh hoạt và khả năng thích ứng của nhóm trước thay đổi
  • 6. Hãy bắt đầu từ những thay đổi tạo hiệu quả lớn với ít công sức
    • Khi số lượng hạng mục thay đổi nhiều và phức tạp, trước tiên hãy chọn các phương án cải tiến thuộc nhóm “hiệu quả cao - chi phí thấp”
    • Ví dụ: áp dụng hướng dẫn review đơn giản, loại bỏ các thông báo không cần thiết là những việc có thể triển khai nhanh nhưng vẫn tạo ảnh hưởng lớn đến mức độ hài lòng
    • Những thành công ban đầu sẽ giúp nhóm có thêm tự tin và cung cấp động lực để tiến tới giải quyết các vấn đề khó hơn

Bước 3: Triển khai các thay đổi, theo dõi kết quả và điều chỉnh

• Thực hiện thử nghiệm cải tiến (Intervention) được rút ra ở Step 2 trong tổ chức thực tế,
  đo lường kết quả, và khi cần thì điều chỉnh hoặc lặp lại để cải tiến nhằm theo đuổi thành công kỹ thuật một cách liên tục

• 1. Triển khai (Implement the change)

  • Trước khi triển khai, cần làm rõ các điểm sau:
    • Sẽ có thay đổi nào được thực hiện?
    • Ai sẽ chịu trách nhiệm?
    • Sẽ đánh giá theo những chỉ số nào?
    • Sẽ đo lường từ khi nào đến khi nào?
  • Các điểm cần cân nhắc khi triển khai:
    • Chỉ định người phụ trách: làm rõ ownership
    • Onboarding và đào tạo cho team: mọi thành viên cần hiểu vì sao cần thay đổi và điều gì sẽ khác đi
    • Tài liệu hóa thay đổi: lưu lại hồ sơ để có thể tham khảo khi retrospective và lặp lại sau này
  • Ví dụ áp dụng:
    • Thay đổi chiến lược build cache để cải thiện tốc độ CI/CD
    • Thay đổi chính sách code review (ví dụ: áp dụng quy tắc phản hồi trong vòng 1 ngày)

• 2. Giám sát (Monitor the change)

  • Sau khi triển khai phương án cải tiến, theo dõi hiệu quả bằng các chỉ số đã xác định trước
    • Lead time có được rút ngắn hay không
    • Tỷ lệ thất bại có giảm hay không
    • Mức độ hài lòng của developer có tăng hay không, v.v.
  • Công cụ:
    • GitHub Insights, Copilot Telemetry, hệ thống BI nội bộ
    • Dashboard báo cáo hàng tuần/hàng tháng
    • Khảo sát developer hoặc phản hồi từ retrospective
  • Điểm quan trọng:
    • Cần có khả năng so sánh với baseline
    • Điều quan trọng là nhìn vào xu hướng, không phải một con số đơn lẻ

• 3. Thu thập phản hồi (Collect feedback)

  • Ngoài các chỉ số định lượng, cũng cần thu thập phản hồi xem từ góc nhìn của developer, thay đổi đó có thực sự hữu ích hay không
    • Có thể sử dụng retrospective, khảo sát ẩn danh, họp 1:1, v.v.
    • Kiểm tra xem mức độ “cảm nhận được cải thiện” có cao hay không, hay thay đổi đó lại gây mệt mỏi
  • Những thay đổi được triển khai vội vàng mà không có sự đồng thuận trong tổ chức có thể gây ra sự kháng cự và phản ứng ngược

• 4. Điều chỉnh hoặc lặp lại (Adjust as needed)

  • Nếu kết quả của thử nghiệm cải tiến không đạt kỳ vọng hoặc có tác dụng phụ, có thể xử lý như sau:
    • Hoàn tác hoặc bổ sung thay đổi
    • Chỉ giữ lại một số yếu tố và thu hẹp phạm vi
    • Mở rộng áp dụng ra phạm vi lớn hơn
  • Bất kể thay đổi thành công hay thất bại, luôn cần học được các điều sau:
    • Yếu tố nào đã phát huy hiệu quả?
    • Điểm nào là yếu tố cản trở?
    • Lần sau cần thay đổi điều gì?
• Mẹo để thực hiện thành công Step 3
  • 1.Đừng kỳ vọng sự hoàn hảo ngay lập tức
    • Không phải mọi thay đổi đều ngay lập tức tạo ra cải thiện rõ rệt
      • Có thể mất thời gian để hiệu quả xuất hiện
      • Team cũng cần một quá trình thích nghi với thay đổi, nên kiên nhẫn và theo dõi liên tục là rất quan trọng
    • Ở giai đoạn đầu, việc dùng các công cụ phản hồi định tính như khảo sát để nắm bắt mức độ cảm nhận về thay đổi là rất hiệu quả
  • 2.Tiếp tục lặp lại và cải tiến thay đổi
    • Không phải cứ thành công một lần là giữ nguyên như vậy, mà bản thân thay đổi cũng cần liên tục tiến hóa và điều chỉnh
    • Khi xuất hiện vấn đề mới hoặc môi trường bên ngoài thay đổi, cũng cần xem xét lại phương án cải tiến hiện có
    • Cần khuyến khích để team coi đây là hoạt động định kỳ và duy trì chu kỳ cải tiến
  • 3.Chú ý đến các tác dụng phụ ngoài ý muốn
    • Một số thay đổi có thể gây ra ma sát ngoài dự kiến ở các khu vực khác
      • Ví dụ: tăng tốc độ triển khai là thay đổi tốt, nhưng nếu khâu kiểm định chất lượng yếu thì có thể dẫn đến gia tăng bug
    • Cần quan sát không chỉ chỉ số mà cả sự thay đổi trong dòng chảy của toàn bộ workflow, và nếu xuất hiện dấu hiệu bất thường thì cần xử lý ngay
  • 4.Liên tục kiểm tra trạng thái an toàn tâm lý
    • Ngay cả sau thay đổi, vẫn cần duy trì môi trường để team có thể tự do nêu vấn đề
    • Để tránh các “vấn đề không được nói ra” tích tụ, cần tạo bầu không khí để các thành viên có thể đưa ra phản hồi trung thực
    • Như bất mãn với quy trình đã thay đổi, khối lượng công việc tăng quá mức, hoặc căng thẳng ngoài dự kiến
  • 5.Đánh giá hiệu quả dài hạn một cách liên tục
    • Trọng tâm không phải là kết quả ngắn hạn mà là hiệu quả bền vững và sự cải thiện tinh thần của team
    • Theo thời gian, cần liên tục kiểm tra:
      • Thay đổi đã được ổn định hay chưa
      • Có phát sinh tác dụng phụ hoặc vấn đề mới hay không
      • Hiệu quả đang được duy trì hay suy giảm
  • 6.Biến phản hồi thành cơ hội học hỏi
    • Ngay cả những thay đổi thất bại cũng là tài sản học hỏi quý giá
    • Cần phân tích dựa trên dữ liệu và phản hồi để hiểu điều gì đã sai và phản ánh vào lần thử tiếp theo
    • Điều quan trọng là xây dựng văn hóa khuyến khích team cũng nhìn nhận thất bại như một cơ hội học hỏi

Beyond the steps: Make the playbook work for you

• Tùy chỉnh

  • Lựa chọn các chỉ số và phương pháp đo lường phù hợp với đặc điểm tổ chức (telemetry vs khảo sát)
  • Không nên coi việc đo lường là mục đích tự thân, mà phải dùng nó như công cụ để tạo ra cải tiến thực chất

• Quản lý thay đổi

  • Điều quan trọng là tận dụng các framework quản lý thay đổi như ADKAR, mô hình Kotter để giúp tổ chức thích nghi tốt với thay đổi

• Tư duy phát triển

  • Coi mọi thử nghiệm là cơ hội học hỏi, và thái độ chấp nhận thất bại là chìa khóa của cải tiến liên tục

• Gamification

  • Thiết kế phần thưởng dựa trên động lực có thể mang lại hiệu quả tích cực, nhưng nếu thiết kế sai thì ngược lại có thể làm suy giảm chất lượng hoặc gây mất cân bằng

Alternatives to the GitHub Engineering System Success Playbook

• Tùy tình huống, ngoài ESSP còn có thể áp dụng phân tích đơn giản tập trung vào việc sử dụng feature hoặc chiến lược cải tiến dựa trên từng công cụ riêng lẻ
• Điều quan trọng là cách tiếp cận thực tế phù hợp với team và tổ chức, cùng nỗ lực cải tiến liên tục