Tôi sẽ chia làm 2 nhóm để đánh giá chất lượng của 1 dự án, 1 cái là đo lường bằng con số cụ thể và 2 là cảm quan:

1. Đánh giá bằng định lượng

Phương pháp này áp dụng KPI, sử dụng các số liệu, đo lường metrics để đánh giá hiệu quả của dự án.

1.1 Goal – đã đạt được mục tiêu chung

1. Cuối cùng dự án đã xong và đạt được mục tiêu đề ra ban đầu hay chưa?
2. Đã deliver được hay chưa?

1.2 Dựa trên ràng buộc CTS

Cost – Time – Scope (dotrinh.com/ctsc)

1. Chi phí: Dự án được hoàn thành trong phạm vi ngân sách đã được phê duyệt của khách hàng.
2. Thời gian (tiến độ): Dự án được hoàn thành đúng thời hạn hoặc sớm hơn thì càng tốt.
3. Phạm vi: Dự án làm đúng theo yêu cầu kỹ thuật và nghiệp vụ đã được thống nhất, không làm thừa, không làm thiếu.

Ở đây có thể dùng biểu đồ quạt, biểu đồ đường, biểu đồ cột… để tạo báo cáo.

1.3 Tính tỷ lệ %

1. Tỷ lệ hoàn thành: Tỷ lệ phần trăm các mục tiêu dự án đã được hoàn thành.
2. Tỷ lệ lỗi do mình: Ví dụ có bao nhiêu test case và bao nhiêu lỗi trên số test case đó?
3. Tỷ lệ lỗi do khách: Có bao nhiêu lỗi do khách trên tổng số test case?
4. Tỷ lệ chấp nhận: Tỷ lệ người dùng hài lòng với hệ thống.
5. Thời gian phản hồi: Thời gian cần thiết để hệ thống xử lý một yêu cầu.
6. Chi phí bảo trì: Chi phí cần thiết để duy trì và vận hành hệ thống.

Ở đây có thể dùng biểu đồ quạt, biểu đồ đường, biểu đồ cột… để tạo báo cáo.

1.4 Các đánh giá khác

1. Đợt này các PM, Leader… báo giá có sát với thực tế không?
   • Rút ra kinh nghiệm gì? tổ chức đánh giá lại – reflection – 反省会
2. PM, Leader và các member khác có kiểm soát rủi ro tốt không?
   • Có bao nhiêu risk?
   • Không để xảy ra bao nhiêu risk?
3. Bảo mật tốt không?
4. Có tính scale up không?
   • Đặc biệt khách hàng lớn rất quan tâm
5. Tài liệu dự án có lưu trữ đầy đủ không? (Configuration Management)

2. Đánh giá bằng định tính

1. Sự hài lòng của người dùng: Người dùng hài lòng với trải nghiệm hệ thống không?
2. Communication: Giao tiếp nội bộ trong team có thuận lợi không?
3. Communication: Giao tiếp ngoại bộ có thuận lợi không?
4. Có ai nghỉ hay bức xúc?

3. Kinh nghiệm quản lý chất lượng
trong quá trình phát triển phần mềm

1. Theo dõi commit liên tục, sát sao trên git, svn (Configuration Management)
   Ai làm nhánh nào và báo cáo việc đó hàng ngày để theo dõi nội dung thành viên đó đang thực hiện
2. Họp nội bộ team to, team nhỏ hàng ngày – daily MTG
3. Yêu cầu các leader báo cáo tiến độ hàng ngày
4. Hỏi thăm khách hàng
5. Trong quá trình phát triển nhưng cũng nên đưa thử vào môi trường thật để thử nghiệm
6. Truyền thông nội bộ team, nội bộ công ty

4. Bóc term

1. KPI là viết tắt của cụm từ Key Performance Indicator, có nghĩa là chỉ số hiệu suất quan trọng. KPI là công cụ đo lường, đánh giá hiệu quả công việc được thể hiện qua số liệu, tỷ lệ, chỉ tiêu định lượng, nhằm phản ánh hiệu quả hoạt động của các tổ chức hoặc bộ phận chức năng hay cá nhân.
2. Quality 品質 (Chất lượng)
3. Quality Management (Quản lý chất lượng)
4. Quality Assurance (Bảo đảm chất lượng)
5. Quality Control (Kiểm soát chất lượng)
6. Quality Policy (Chính sách chất lượng)
7. Quality Objectives (Mục tiêu chất lượng)
8. Quality Circle (Nhóm quản lý chất lượng)
9. ISO Standards (Tiêu chuẩn ISO)
10. Compliance (Tuân thủ)
11. Continuous Improvement (Cải tiến liên tục)
12. Continuous Integration (Tích hợp liên tục)
13. Continuous Delivery (Phân phối liên tục)
14. Agile (Phương pháp làm việc theo phong cách Agile)
15. Scrum (Phương pháp Scrum)
16. Sprint (Chu kỳ phát triển trong Scrum)
17. DevOps (Kết hợp phát triển và vận hành)
18. Code Review (Đánh giá mã nguồn)
19. Version Control (Quản lý phiên bản)
20. Release Management (Quản lý phát hành)
21. Configuration Management – Quản lý cấu hình
22. Change Management (Quản lý thay đổi)
23. Risk Management (Quản lý rủi ro)
24. Risk Assessment (Đánh giá rủi ro)
25. Process Improvement (Cải tiến quy trình)
26. Defect (Lỗi, khuyết điểm)
27. Bug (Lỗi phần mềm)
28. User Acceptance Testing (UAT) – Kiểm thử chấp nhận của người dùng
29. Performance Testing – Kiểm thử hiệu năng
30. Load Testing – Kiểm thử tải
31. Stress Testing – Test độ chịu đựng
32. Automated Testing – Kiểm thử tự động
33. Manual Testing – Kiểm thử thủ công
34. Root Cause Analysis (Phân tích nguyên nhân gốc)
35. Testing (Kiểm thử)
36. Test Plan (Kế hoạch kiểm thử)
37. Test Case (Các trường hợp kiểm thử)
38. Test Automation (Tự động hóa kiểm thử)
39. Validation (Xác thực)
40. Verification (Xác minh)
41. Customer Satisfaction (Sự hài lòng của khách hàng)
42. Stakeholder (Bên liên quan, bên liên hệ)
43. Audit (Kiểm toán)
44. Six Sigma
45. Lean (Tinh gọn)
46. Root Cause Analysis (Phân tích nguyên nhân gốc)
47. Benchmarking (So sánh chuẩn)
48. Process Mapping (Ánh xạ quy trình)
49. Software Development Life Cycle (SDLC – Chu kỳ phát triển phần mềm)
50. Service Level Agreement (SLA – Hợp đồng mức dịch vụ)
51. Best Practices (Thực tiễn tốt nhất)
52. Non-Conformance (Không tuân thủ)
53. Traceability (Khả năng theo dõi)
54. Documentation 仕様書 (Tài liệu)
55. Metrics (đo lường, thống kê)

Các bài viết không xem thì tiếc:

• Vòng đời phát triển phần mềm – SDLC
• 7 lời khuyên của Sam Altman để thành công
• LƯU Ý KHI ĐƯA APP LÊN APP STORE & TESTFLIGHT TỪ ĐÔ TRỊNH | dotrinh.com
• Thiết kế website số 1 Việt Nam và thiết kế web top 1 Google
• Thiết kế web có khó không? Thiết kế web là làm gì?
• Công ty SI là gì trong lĩnh vực công nghệ thông tin?
• Đơn vị báo giá cho thị trường Nhật – 人月, 人日, 人時
• Lưu ý khi porting C/C++ sang Java
• Triển lãm quốc tế Inter BEE 2023
• 30 tuổi học lập trình có muộn không?
• Lợi ích của việc livestream trên Facebook, YouTube
• Các loại hợp đồng B2B tại công ty Nhật
• Tại sao đã thêm vào file gitignore rồi mà không có tác dụng?
• Các loại release trong phát triển phần mềm
• Các nguyên tắc thiết kế cho mobile app và desktop app