Trở thành Project Manager (quản lý dự án) công ty phần mềm

Chương 2 · Bài 1.1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là bài mở đầu chương về bảo mật thông tin trong dự án — và không phải ngẫu nhiên nó được đặt ngay đầu tiên. Điểm mấu chốt đáng nhớ: trong ngành gia công phần mềm (outsourcing), chỉ cần một lần vi phạm bảo mật thông tin là khách hàng có thể dừng ngay dự án, dù dự án đang gấp đến đâu — hậu quả cực kỳ nghiêm trọng.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao bảo mật thông tin là yếu tố sống còn trong outsourcing.
• Nắm được bốn phần nội dung mà chương này sẽ đi qua.
• Biết nơi lấy tài liệu để chuẩn bị cho các bài giải thích chi tiết sau.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao bảo mật thông tin được học đầu tiên

Bảo mật thông tin quyết định rất nhiều yếu tố trong dự án phần mềm outsourcing. Giảng viên nhấn mạnh: chỉ cần vi phạm ở một thời điểm nào đó, hầu hết khách hàng sẽ stop ngay dự án. Giảng viên từng chứng kiến những dự án rất lớn bị dừng dứt khoát, khiến toàn bộ đội ngũ "ngồi chơi". Vì mức độ rủi ro đó, đây là nội dung cần học rất kỹ.

▸ 2. Bốn phần nội dung của chương

Chương này sẽ đi qua bốn phần:

1. Nguyên tắc bảo mật thông tin.
2. Các sự cố bảo mật thông tin.
3. Bảo mật thông tin khi tham gia dự án.
4. Xử lý sự cố bảo mật thông tin.

▸ 3. Tài liệu đi kèm

Giảng viên cung cấp một tài liệu qua đường link (kèm QR code) để bạn truy cập. Các video phía sau sẽ giải thích chi tiết từng phần trong tài liệu này. Hãy mở sẵn tài liệu để theo dõi cùng bài giảng, vì đây là chủ đề nền tảng bạn cần nắm vững trước khi đi vào các nội dung quản lý dự án tiếp theo.

Chương 2 · Bài 1.2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là phần tiếp theo về bảo mật thông tin (ISMS) trong dự án phần mềm, tập trung vào ba nguyên tắc cơ bản khi xử lý tài sản thông tin và các sự cố bảo mật hay gặp trong thực tế. Điểm mấu chốt đáng nhớ: phần lớn sự cố không đến từ công nghệ mà đến từ ý thức con người — và hậu quả có thể nghiêm trọng tới mức mất khách hàng, bị sa thải, thậm chí công ty phá sản.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm ba nguyên tắc khi mang tài sản thông tin ra ngoài khu vực làm việc.
• Nhận diện các loại sự cố bảo mật điển hình và vì sao chúng nguy hiểm.
• Biết quy trình hai bước để xử lý khi có sự cố xảy ra.

─── NỘI DUNG CHÍNH

▸ 1. Ba nguyên tắc bảo mật thông tin

• Không mang tài sản thông tin ra khỏi khu vực làm việc: giấy tờ in ra, thiết bị test… đều không được tự ý đem ra ngoài.
• Phải được phê duyệt: muốn mang ra thì cần cấp trên (PM, senior manager) duyệt trước.
• Phải có biện pháp bảo mật phù hợp: ví dụ laptop mang ra ngoài phải đặt mã BIOS, đặt username/password đăng nhập máy.

▸ 2. Các sự cố bảo mật thường gặp

Bài liệt kê nhiều tình huống thật: rò rỉ dữ liệu từ FTP server quên tắt rồi bị Google crawl phát tán; chạy chương trình test nhưng gửi dữ liệu vào email thật của khách hàng; push source của khách hàng lên GitHub của công ty; dùng chung email khiến người đã rời dự án vẫn nhận thông tin mật; gửi nhầm tài liệu, dùng phần mềm không có license. Tất cả đều là vi phạm bảo mật thông tin.

▸ 3. Cách xử lý sự cố

Khi có sự cố, làm hai việc: (1) xử lý ngay lập tức để chặn thiệt hại, (2) điều tra nguyên nhân gốc rễ bằng phương pháp 5 Why để ngăn tái diễn. Với rò rỉ dữ liệu, việc đầu tiên là thông báo cho khách hàng (tinh thần Horenso) để cùng xử lý, đồng thời liên hệ bên liên quan (như Google) nhờ gỡ dữ liệu, và sửa lại quy trình — nhờ đội QA kiểm tra để lỗ hổng không lặp lại.

▸ Lưu ý quan trọng: ý thức là hàng rào cuối cùng

Không thể ngăn 100% sự cố bằng công nghệ. Phần lớn rủi ro nằm ở thói quen và ý thức của mỗi thành viên, nên bảo mật thông tin là điều kiện tiên quyết khi tham gia bất kỳ dự án nào.

Chương 2 · Bài 1.3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Phần cuối của chủ đề bảo mật thông tin đi vào các quy định cụ thể phải tuân thủ khi tham gia dự án: dùng máy tính, thiết bị ngoại vi, tài nguyên mạng, quản lý tài sản khách hàng, phân quyền và quy trình xử lý sự cố. Điểm mấu chốt: mỗi hành động tưởng nhỏ (cắm USB, gửi Gmail, giữ email cũ) đều có thể thành lỗ hổng, nên phải làm đúng quy định và báo cáo sự cố trong thời gian rất ngắn.

─── SAU BÀI HỌC, BẠN SẼ

• Biết cấu hình bảo mật tối thiểu cho máy tính và cách dùng thiết bị ngoại vi, tài nguyên mạng an toàn.
• Hiểu quy trình quản lý tài sản khách hàng và nguyên tắc phân quyền theo CMP.
• Nắm các bước bắt buộc khi xử lý một sự cố bảo mật.

─── NỘI DUNG CHÍNH

▸ 1. Máy tính, thiết bị ngoại vi và tài nguyên mạng

Máy tính (nhất là laptop) phải đặt mật khẩu BIOS, mật khẩu ổ cứng, mật khẩu login, cập nhật hệ điều hành và antivirus, mã hóa dữ liệu, chỉ dùng phần mềm có license. Thiết bị ngoại vi (USB, CD, ổ cứng ngoài) chỉ dùng khi được đăng ký, không lưu thông tin mật lên đó. Với mạng: không tự đổi cấu hình (IP, DNS), không dùng công cụ vượt tường lửa, không dùng free mail (Gmail, Yahoo) mà phải dùng email domain của công ty.

▸ 2. Quản lý tài sản khách hàng và hủy dữ liệu

Tài sản khách hàng (thiết bị test, đĩa CD, phần mềm) đi theo quy trình: giao nhận → dán nhãn (mã, QR code) → sử dụng → bảo quản → trả/hủy. Thiết bị mượn–trả trong ngày phải có biên bản ký nhận; thiết bị nhỏ, giá trị cần kiểm kê định kỳ. Khi kết thúc dự án, hủy dữ liệu đúng cam kết, lập biên bản và chụp bằng chứng trước–trong–sau khi hủy.

▸ 3. Phân quyền và xử lý sự cố

Quyền truy cập quản lý theo CMP (Configuration Management Plan): khi thành viên rời dự án phải deny toàn bộ quyền; muốn truy cập dữ liệu dự án đã đóng phải request và được leader approve. Đặc quyền (dùng laptop, USB, gửi free mail) phải có giới hạn thời gian và phạm vi. Khi có sự cố: báo cho quản lý/ISMS team trong khoảng 2 tiếng, lưu bằng chứng, không tự ý xử lý theo cách riêng, rồi phân tích 5 Why để phòng ngừa.

▸ Lưu ý quan trọng: máy nhiễm virus thì làm gì trước?

Ưu tiên rút dây mạng và tắt nguồn để chặn lây lan, sau đó mới chụp evidence và báo IT — đừng loay hoay tự diệt khi chưa đủ chuyên môn.

Chương 2 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu bốn yếu tố cơ bản ràng buộc mọi dự án: Cost (chi phí), Time (thời gian), Scope (phạm vi) và Quality (chất lượng). Điểm mấu chốt đáng nhớ: bốn yếu tố này ràng buộc lẫn nhau như một dây xích — khi bạn "cứu" yếu tố này thì yếu tố khác sẽ chịu ảnh hưởng, nên PM phải biết chọn ưu tiên đúng thay vì cố ôm cả bốn.

─── SAU BÀI HỌC, BẠN SẼ

• Định nghĩa được một dự án qua bốn yếu tố Cost, Time, Scope, Quality.
• Nhận ra khi thiếu định nghĩa rõ một yếu tố thì dự án chưa đủ rõ ràng.
• Biết cách chọn yếu tố ưu tiên và đánh đổi hợp lý khi dự án gặp áp lực.

─── NỘI DUNG CHÍNH

▸ 1. Bốn yếu tố cơ bản của mọi dự án

Bất kỳ dự án nào — làm phần mềm hay mở quán cà phê — cũng nằm trong bốn yếu tố: Cost (budget bỏ ra), Time (thời gian thực hiện), Scope (phạm vi, đối tượng khách hàng, khối lượng làm) và Quality (tiêu chuẩn chất lượng). Nếu ai đó rủ bạn làm một dự án mà chưa định nghĩa rõ đủ bốn yếu tố (ví dụ "mở quán 300 triệu trong 3 tháng" nhưng không rõ làm gì mỗi tháng, khách hàng là ai), thì dự án đó còn mơ hồ, chưa thể gọi là một dự án đầy đủ.

▸ 2. Bốn yếu tố ràng buộc lẫn nhau

Thực tế PM hiếm khi đạt được cả bốn; giữ được hai trên bốn đã là giỏi. Khi dự án gấp và bạn muốn cứu Time, thường phải đổ thêm người → Cost tăng, communication phức tạp hơn → Quality giảm. OT cũng làm tăng Cost và hại sức khỏe, ảnh hưởng Quality nên không phải giải pháp tốt. Cách xử lý thường thấy khi cứu Time là giảm Scope để giữ Quality, thay vì cố ôm nguyên Scope và Time ban đầu.

▸ 3. Ưu tiên yếu tố nào là chiến lược của dự án

Tại mỗi thời điểm nên ưu tiên một (hoặc hai) yếu tố tùy tính chất dự án: dự án ngân hàng, ngành nhiều tiền thường cứu Quality; dự án start-up thường cứu Time để kịp gọi vốn. Việc chọn cứu yếu tố nào cần cân nhắc kỹ vì nó quyết định các đánh đổi còn lại. Các bài sau sẽ đi sâu vào từng yếu tố trong bối cảnh ngành outsourcing.

Chương 2 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu Redmine — công cụ quản lý dự án mà cả khóa sẽ dùng làm hệ thống chính. Điểm mấu chốt đáng nhớ: Redmine là phần mềm open source miễn phí, chi phí triển khai thấp mà vẫn quản lý được issue, Gantt chart và toàn bộ tiến độ dự án — rất hợp cho các công ty vừa và nhỏ theo mô hình outsourcing.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu Redmine là gì và vì sao chọn Redmine để quản lý dự án.
• Biết những chức năng chính Redmine cung cấp: issue tracking, Gantt chart, wiki.
• Biết cách xin tài khoản để thực hành trên hệ thống Redmine mẫu của giảng viên.

─── NỘI DUNG CHÍNH

▸ 1. Redmine là gì và vì sao dùng

Redmine là công cụ theo dõi các vấn đề (issue) xảy ra trong dự án, mã nguồn mở và miễn phí, nên chi phí xây dựng rất thấp. Nó cho phép quản lý bằng Gantt chart và theo dõi chi tiết từng issue một cách rõ ràng. Giảng viên khuyến cáo Redmine phù hợp với các công ty vừa và nhỏ (dưới 100 người), nhưng thực tế có cả những công ty 300–400 người vẫn dùng Redmine cho dự án của họ.

▸ 2. Bản Redmine đã được customize

Bản Redmine dùng trong khóa được custom lại một chút: cài thêm một số plugin và cấu hình lại cho phù hợp với đặc thù dự án outsourcing. Giảng viên cũng có một khóa riêng trên Udemy hướng dẫn xây dựng và tích hợp hệ thống Redmine từ đầu đến cuối, để ai muốn dựng hệ thống của riêng mình có thể tham khảo.

▸ 3. Thực hành trên hệ thống Redmine mẫu

Giảng viên đã setup sẵn một hệ thống Redmine để học viên thực hành. Ai tham gia khóa học có thể đăng ký và nhắn vào group Zalo hỗ trợ để được cấp một tài khoản đăng nhập. Sau khi đăng nhập, bạn sẽ thấy giao diện Redmine với đầy đủ issue, Gantt chart và wiki — đây chính là môi trường bạn sẽ dùng xuyên suốt các bài sau để luyện quản lý dự án thực tế.

Để có tài khoản, bạn vui lòng đăng ký với tác giả qua zalo của nhóm hỗ trợ

Chương 2 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu template Excel để thống kê toàn bộ tiến độ, chi phí, lịch trình và chất lượng của dự án. Điểm mấu chốt đáng nhớ: một file quản lý hoàn chỉnh thường gồm khoảng 4 sheet đi từ raw data → công thức tính toán → chart → phân tích rủi ro, và mục tiêu là hiểu nguyên lý hoạt động để tự tinh chỉnh, chứ không chỉ copy template.

─── SAU BÀI HỌC, BẠN SẼ

• Biết những trường dữ liệu quan trọng cần theo dõi cho mỗi task.
• Hiểu cách công thức tính phần trăm hoàn thành và độ trễ của task.
• Nắm cấu trúc 4 sheet của một file quản lý dự án bằng Excel.

─── NỘI DUNG CHÍNH

▸ 1. Sheet Tracker List — dữ liệu gốc

Sheet đầu tiên là Tracker List, chứa raw data của dự án. Mỗi task có các trường: key/ID, tracker/type (loại ticket), subject (tiêu đề), mô tả, trạng thái, priority, người làm (assignee), người log ticket, start date / end date (plan), estimate, phần trăm done, ngày tạo, ngày update. Các trường quan trọng nhất được tô vàng — đặc biệt là key, loại tracker, subject/trạng thái/priority, và start–end + estimate — vì chúng quyết định việc tính được tiến độ và độ trễ.

▸ 2. Công thức tính phần trăm và độ trễ

Quy ước tính phần trăm hoàn thành: task ở trạng thái resolved / closed / cancel / rejected thì tính 100%; còn new / reopen / in progress thì tính theo spend time so với estimate (ví dụ estimate 8 tiếng, làm 4 tiếng → 50%). Từ phần trăm và spend time, công thức tính ra độ trễ / độ sớm của từng task so với kế hoạch.

▸ 3. Dashboard và cấu trúc 4 sheet

Sau khi tính toán, dữ liệu lên dashboard đo theo từng phase / màn hình, thể hiện trễ hay không trễ và tiến độ tại ngày báo cáo; đồng thời vẽ các chart về số bug, số người, tiến độ (các bài sau hướng dẫn cách dựng). Một file quản lý thường có 4 sheet: (1) raw data, (2) tính toán ra báo cáo, (3) vẽ chart để đánh giá, (4) rủi ro/phân tích — và có thể thêm sheet phụ để tham khảo.

▸ Mẹo quan trọng: công cụ nào cũng được, miễn quản đủ 4 yếu tố

Dù dùng Excel hay Google Sheet, cốt lõi là file phải quản được Time, Cost, Quality, Scope. Quản đủ bốn yếu tố và tracking mỗi ngày thì dự án gần như chắc chắn nằm trong tầm kiểm soát.

Chương 2 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Nối tiếp bài Excel, bài học giới thiệu template báo cáo thống kê bằng Google Sheet (Spreadsheet) để quản lý dự án. Điểm mấu chốt đáng nhớ: bản chất giống hệt file Excel — cũng đi từ load data → công thức tính trễ → chart — nhưng chạy trên nền cloud, và bạn có thể dùng ngay template có sẵn thay vì tự dựng từ đầu.

─── SAU BÀI HỌC, BẠN SẼ

• Biết template Google Sheet quản lý dự án gồm những phần thống kê nào.
• Hiểu các loại summary giúp nhìn ra vấn đề chất lượng của dự án.
• Biết cách lấy và dùng trực tiếp template mẫu của giảng viên.

─── NỘI DUNG CHÍNH

▸ 1. Template Google Sheet gồm những gì

Truy cập template qua link hoặc quét QR code. Template có nhiều phần: task list (công việc PM cần làm), chart liên quan tới dự án, bảng phân quyền (PM, risk… ai được làm gì), theo dõi LOC đo mỗi tuần để thấy chênh lệch, số lượng test case, và progress tiến độ dự án. Mỗi bài học trong khóa còn kèm một file resource Spreadsheet tương ứng để bạn vừa xem video vừa thực hành.

▸ 2. Các báo cáo summary

Template tổng hợp dữ liệu theo nhiều chiều: summary theo person in charge, summary theo số bug (coi lỗi nào nhiều, lỗi logic ra sao), summary theo số lượng Q&A, theo từng phase, theo function/màn hình. Nhờ đó bạn nhìn nhanh ra chất lượng (quality) đang có vấn đề ở đâu, cùng danh sách các task bị trễ cần xử lý.

▸ 3. Burndown chart và sheet xử lý dữ liệu

Template có sẵn burndown chart thể hiện tổng số task, plan và số còn lại (remain). Cơ chế bên dưới giống file Excel: một sheet load data đổ dữ liệu về, rồi các công thức tính độ trễ xử lý phía sau để ra báo cáo. Trong khóa này giảng viên không hướng dẫn dựng template đến mức chi tiết (phần đó thuộc khóa Google Sheet riêng) — bạn có thể lấy template dùng luôn và tinh chỉnh theo dự án của mình.

Chương 2 · Bài 6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giải thích cách đo chất lượng dự án bằng các chỉ số chuẩn (số NORM) — những ngưỡng tham chiếu giúp biết dự án đang "khỏe" hay "bất thường". Điểm mấu chốt đáng nhớ: mỗi chỉ số có một cận trên, cận dưới và mức trung bình mong muốn; khi số đo vượt ra ngoài vùng cho phép thì đó là dấu hiệu để dừng lại xem xét và cải thiện.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu bản chất của chỉ số NORM và vì sao dự án cần có nó.
• Nắm được các nhóm chỉ số chất lượng thường dùng để đánh giá dự án.
• Biết cách đọc một chỉ số so với cận trên / cận dưới để ra quyết định.

─── NỘI DUNG CHÍNH

▸ 1. Chỉ số NORM là gì

Giảng viên ví chỉ số NORM giống kết quả xét nghiệm máu: mỗi bệnh có ngưỡng bình thường và ngưỡng bất thường, có cận trên và cận dưới. Áp vào dự án phần mềm, chỉ số NORM là các ngưỡng chuẩn cho từng khía cạnh chất lượng — nằm trong khoảng cho phép là ổn, vượt ra ngoài là tín hiệu cần chú ý.

▸ 2. Các nhóm chỉ số chất lượng

Bài giới thiệu một bộ chỉ số đánh giá chất lượng, xoay quanh các nhóm: code review, mật độ test case và mật độ bug ở các mức unit test (UT), integration test (IT) và acceptance test (khách hàng); cùng các chỉ số về billable / calendar / actual effort, effort efficiency (hiệu quả sử dụng nguồn lực), CSS point (độ hài lòng khách hàng) và timeline meet (đúng hạn hay không). Mỗi chỉ số phản ánh một mặt của "sức khỏe" dự án.

▸ 3. Cách đọc chỉ số và điều chỉnh theo dự án

Với mỗi chỉ số, so sánh số đo thực tế với cận trên / cận dưới: vượt ngưỡng nghĩa là chất lượng có vấn đề và cần review, đánh giá lại. Quan trọng nhất: bộ chỉ số này chỉ mang tính tham khảo — nó phải được thống nhất và điều chỉnh khi khởi tạo dự án, tùy tính chất dự án, tùy khách hàng và tùy tổ chức. Không dự án nào cũng đo đủ toàn bộ chỉ số; hãy chọn những chỉ số phù hợp với dữ liệu và bối cảnh của mình.

▸ Lưu ý quan trọng: chuẩn là để tham chiếu, không phải áp cứng

Một số chuẩn (ví dụ theo thị trường Nhật) rất khó đạt tuyệt đối. Hãy hỏi tổ chức của bạn đang theo tiêu chuẩn nào, rồi hiểu và giữ đúng chất lượng theo chuẩn đó — đừng bê nguyên con số của người khác vào dự án của mình.

Chương 2 · Bài 7

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học trình bày mô hình Waterfall (thác nước) — cách thực hiện dự án theo các giai đoạn nối tiếp một chiều. Điểm mấu chốt đáng nhớ: Waterfall không hề lỗi thời; nó vẫn phù hợp với những dự án yêu cầu rõ ràng từ đầu và khó thay đổi, quan trọng là chọn mô hình đúng theo tính chất dự án, chứ không có chuyện "mô hình cũ nên bỏ".

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu Waterfall vận hành theo các giai đoạn tuần tự như thế nào.
• Nắm ưu điểm và nhược điểm của mô hình để biết khi nào nên dùng.
• Nhận ra vì sao thay đổi (change request) trong Waterfall lại tốn kém.

─── NỘI DUNG CHÍNH

▸ 1. Waterfall vận hành ra sao

Waterfall gọi là mô hình thác nước vì các giai đoạn chỉ đổ xuống một chiều, xong giai đoạn này mới sang giai đoạn kế tiếp và rất khó quay ngược lên. Trình tự điển hình: requirements → design → development → test → deployment → maintain. Yêu cầu phải được lấy đầy đủ ngay từ đầu trước khi bước sang thiết kế.

▸ 2. Ưu điểm

Vì nắm rõ toàn bộ requirements và khối lượng công việc ngay từ đầu, dự án dễ hoạch định và kiểm soát. Cấu trúc tuần tự, rõ ràng giúp việc quản lý chi phí và phạm vi trở nên chặt chẽ — phù hợp với các dự án mà yêu cầu ổn định, ít biến động (ví dụ tính chất gần với xây dựng, khó change liên tục).

▸ 3. Nhược điểm

Khi có change request ở giai đoạn muộn (ví dụ đang test), bạn không thể sửa tại chỗ mà phải chạy ngược lên design → develop → test lại, rất tốn chi phí và kém linh hoạt — nên nhiều dự án Waterfall gần như cấm thay đổi. Nhược điểm lớn thứ hai là thời gian giao sản phẩm rất lâu (có khi 6 tháng đến 1 năm): khách hàng lâu không thấy sản phẩm, trong khi thị trường đã biến động, khiến sản phẩm dễ không còn phù hợp thực tế.

▸ Lưu ý quan trọng: chọn mô hình theo tính chất dự án

Điểm cần nhớ: Waterfall là các phase tuần tự, quay lui gần như bất khả thi và delivery lâu. Chính vì hai giới hạn này mà thực tế ngành outsourcing dần chuyển sang các mô hình pha trộn — chủ đề sẽ được nói ở bài sau. Đừng loại bỏ Waterfall, hãy dùng nó đúng chỗ.

Chương 2 · Bài 8

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu V-Model — bản mở rộng của Waterfall, trong đó mỗi giai đoạn thiết kế được ghép cặp với một mức test tương ứng. Điểm mấu chốt đáng nhớ: thay vì chỉ có một khối "testing" chung như Waterfall, V-Model tách rõ từng loại test và gắn mỗi loại với một tài liệu thiết kế, giúp kiểm thử bám sát đúng thứ đã thiết kế.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu V-Model là phần mở rộng của Waterfall như thế nào.
• Phân biệt được các mức test và tài liệu thiết kế tương ứng.
• Biết ai chịu trách nhiệm ở từng mức test trong thực tế.

─── NỘI DUNG CHÍNH

▸ 1. V-Model — mở rộng của Waterfall

Ở Waterfall chỉ có một giai đoạn testing duy nhất. V-Model extend giai đoạn đó ra chi tiết: mỗi cấp độ test được viết rõ ra và tương ứng với một tài liệu thiết kế. Nhờ vậy, phần "test" không còn mơ hồ mà được cụ thể hóa thành nhiều mức, mỗi mức có mục tiêu riêng.

▸ 2. Các mức test ghép với tài liệu thiết kế

Bài nêu các cặp tương ứng: unit test dựa theo tài liệu thiết kế chi tiết (module design / detail design / program design); integration test cho mức tích hợp nhiều màn hình, gắn với thiết kế tích hợp; system test gắn với system design; và trên cùng là acceptance test. Mỗi giai đoạn design bên nhánh trái sẽ có một giai đoạn test tương ứng bên nhánh phải.

▸ 3. Ai test ở mức nào

Trong thực tế: developer thực hiện các mức test thấp (như unit test), tester đảm nhận các mức cao hơn, còn acceptance test là giai đoạn khách hàng kiểm thử. Tuy nhiên có những giai đoạn developer không tự test được, khi đó tester sẽ test luôn phần đó. Bạn nên tham khảo thêm link tài liệu về V-Model để nắm rõ từng mức. Tóm lại, V-Model chính là mô hình extend của Waterfall, làm rõ mối liên hệ giữa thiết kế và kiểm thử.

Chương 2 · Bài 9.1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu phương pháp Agile và mô hình Scrum để thực hiện dự án phần mềm. Điểm mấu chốt đáng nhớ: Agile là tư tưởng/phương pháp, còn Scrum là framework hiện thực hóa tư tưởng đó — giống như Agile là "ngôn ngữ" còn Scrum là "framework" chạy trên nền ngôn ngữ ấy, giúp dự án phát triển theo vòng lặp ngắn và liên tục cải thiện.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt được Agile (phương pháp) và Scrum (framework hiện thực hóa).
• Hiểu vòng đời một sprint và vai trò các thành viên trong Scrum.
• Biết những điều kiện cần để chạy Scrum hiệu quả trong thực tế.

─── NỘI DUNG CHÍNH

▸ 1. Agile và Scrum — phương pháp và framework

Agile Manifesto là gốc của phương pháp, gồm 4 tuyên ngôn và 12 nguyên lý (sẽ nói kỹ ở bài sau). Giảng viên ví von: Agile giống ngôn ngữ lập trình PHP, còn Scrum giống framework Laravel chạy trên nền đó. Một vòng phát triển Agile cơ bản đi qua: plan → thiết kế → develop → test → deploy → review → chạy thực tế.

▸ 2. Vòng đời một sprint trong Scrum

Mọi tính năng nằm trong product backlog; mỗi feature được ước lượng bằng story point. Chọn feature đưa vào sprint backlog, plan trong một timebox, rồi chạy trong một sprint dài 2–4 tuần. Mỗi ngày có daily scrum (daily meeting). Kết thúc sprint làm sprint review để review sản phẩm và báo cho stakeholder, sau đó deliver cho product owner cho chạy; cuối cùng là sprint retrospective (retro) để nhìn lại điểm hợp lý/chưa hợp lý và cải thiện cho sprint sau.

▸ 3. Vai trò và điều kiện chạy Scrum thực tế

Một team Scrum thường nhỏ (khoảng 6–7 người, gồm development team), cùng Scrum Master và product owner phối hợp mỗi ngày để quyết định và làm dự án. Trên thực tế, chạy full Scrum khá khó: team cần năng lực đồng đều để làm việc độc lập, và trong một sprint thì không cho thay đổi — mọi việc được chốt trong phạm vi sprint đó. Cứ 2–4 tuần lại retro, và thường demo cho khách hàng định kỳ. Đây mới là overview; chi tiết (ví dụ sprint planning kéo dài bao lâu, phương pháp estimation) sẽ cần nghiên cứu thêm.

Chương 2 · Bài 10

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu mô hình hybrid — cách pha trộn Waterfall và Scrum trong cùng một dự án. Điểm mấu chốt: trên thực tế hiếm khi bạn chạy được Scrum thuần túy, nên PM giỏi là người biết lúc nào dùng Waterfall, lúc nào dùng Scrum để dự án vừa chạy trơn tru vừa vừa lòng khách hàng.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao Scrum thuần khó áp dụng với khách hàng muốn fix chi phí và deadline.
• Biết cách estimate theo Waterfall nhưng triển khai bên trong theo Scrum.
• Phân biệt cách làm "ngang" và cách làm "dọc" khi delivery từng chức năng.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao khó chạy Scrum thuần túy

Scrum "chuẩn" đòi nhiều điều kiện tiên quyết: phải có Product Owner, khách hàng luôn kè kè với Development Team và hiểu team cần gì, mỗi ngày có daily meeting. Trong khi đó, phần lớn khách hàng không hiểu Scrum là gì, luôn muốn ước lượng trước chi phí và fix cứng, muốn biết deadline và không muốn deadline đổi dù có vài change lặt vặt. Với tính chất đó, ép chạy Scrum hoàn toàn là rất khó.

▸ 2. Cách pha trộn: estimate Waterfall, triển khai Scrum

Giải pháp là kết hợp: khi estimate thì làm theo kiểu Waterfall — tính từ trên xuống, ra một "cục tiền", báo khách hàng, khách duyệt thì bắt đầu làm. Nhưng bên trong, các phần nhỏ lại chạy theo Scrum cho smooth. Thay vì delivery một cục ở cuối, bạn delivery theo từng phần chốt được.

▸ 3. Làm "dọc" để delivery từng chức năng

Giả sử có 10 màn hình / chức năng: bạn design → development → testing → release xong chức năng số 1, rồi mới sang chức năng tiếp theo — tức làm dọc xuống chứ không làm ngang. Xong chức năng nào thì deliver chức năng đó, mỗi lần deliver khách hàng lại kiểm tra sản phẩm. Đây chính là tinh thần chia nhỏ của Scrum.

▸ Lưu ý khi vận hành mô hình hybrid

Cách làm này khá loằng ngoằng: nhiều bạn không biết ở thời điểm này đang chạy theo mô hình nào. Vì vậy PM bắt buộc phải chủ động lựa chọn — khi nào là Waterfall, khi nào là Scrum. Bài học có kèm link tài liệu tham khảo để bạn đọc thêm về mô hình hybrid.

Chương 2 · Bài 9.2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giải thích bốn tuyên ngôn (manifesto) của Agile — nền tảng tư duy mà mọi PM cần nắm trước khi triển khai dự án theo Agile. Điểm mấu chốt nằm ở chữ over: mỗi tuyên ngôn đề cao một vế hơn vế kia, nhưng không phủ nhận hoàn toàn vế còn lại.

─── SAU BÀI HỌC, BẠN SẼ

• Thuộc và hiểu đúng ý nghĩa của bốn tuyên ngôn Agile.
• Nắm được sắc thái của chữ over — ưu tiên chứ không loại bỏ.
• Biết vận dụng tinh thần bốn tuyên ngôn khi thực thi dự án thực tế.

─── NỘI DUNG CHÍNH

▸ 1. Individuals and interactions over processes and tools

Đề cao tính cá nhân và sự tương tác hơn quy trình và công cụ. Quy trình và công cụ vẫn cần thiết, nhưng khi một quy trình trở nên vướng bận, làm chậm việc, hoặc khi hai người có thể trực tiếp tương tác, hỗ trợ nhau giải quyết vấn đề, thì không nhất thiết phải phụ thuộc cứng vào quy trình hay công cụ đó.

▸ 2. Working software over comprehensive documentation

Ưu tiên sản phẩm chạy được hơn tài liệu đầy đủ. Khác với tư duy Waterfall "phải có tài liệu mới làm được", tinh thần Agile là: nếu đã Q&A rõ với khách và biết cách làm cho tính năng chạy, thì cứ làm sản phẩm chạy được trước, tài liệu xếp sau.

▸ 3. Customer collaboration over contract negotiation

Đề cao sự cộng tác với khách hàng hơn việc đàm phán hợp đồng. Hợp đồng nhiều lúc ghi không rõ ràng; nếu cứ bám hợp đồng để "fighting" với khách thì không hợp lý. Thay vào đó, hãy dựa trên tinh thần hỗ trợ và cộng tác cùng khách hàng để làm dự án sao cho tốt nhất, hợp lý nhất.

▸ 4. Responding to change over following a plan

Ưu tiên phản hồi với thay đổi hơn bám cứng kế hoạch. Khi khách hàng request một change, đừng deny ngay lập tức mà phải review và phản hồi: có thể điều chỉnh ngay cho phù hợp, hoặc hẹn xử lý ở giai đoạn sau. Tinh thần là luôn welcome change và phản hồi tùy trường hợp. Nắm chắc bốn tuyên ngôn này chính là cơ sở để bạn thực thi dự án Agile cho tốt.

Chương 2 · Bài 9.3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học đi qua 12 nguyên tắc (principles) của Agile — phần triển khai cụ thể hơn từ bốn tuyên ngôn. Điểm mấu chốt: 12 nguyên tắc xoay quanh việc làm hài lòng khách hàng bằng sản phẩm chạy được, giao sớm và liên tục, đề cao con người và khả năng thích ứng với thay đổi.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm được nội dung và ý nghĩa của cả 12 nguyên tắc Agile.
• Hiểu vì sao "phần mềm chạy được" là thước đo tiến độ chính xác nhất.
• Biết vận dụng tinh thần tự tổ chức, phản ánh và điều chỉnh liên tục cho team.

─── NỘI DUNG CHÍNH

▸ 1. Nhóm nguyên tắc về giao hàng và thay đổi (1–4)

• NT1: Ưu tiên cao nhất là làm hài lòng khách hàng qua việc bàn giao sản phẩm có giá trị, sớm và liên tục.
• NT2: Sẵn sàng đón nhận thay đổi, kể cả thay đổi muộn, nhằm gia tăng tính cạnh tranh cho khách hàng.
• NT3: Giao phần mềm chạy được trong thời gian ngắn (vài tuần đến vài tháng), càng ngắn càng được ưu tiên.
• NT4: Business people và developer phải làm việc cùng nhau xuyên suốt dự án.

▸ 2. Nhóm nguyên tắc về con người và giao tiếp (5–8)

• NT5: Xây dựng dự án quanh những cá nhân có động lực; cho họ môi trường, sự hỗ trợ và niềm tin rằng họ sẽ làm tốt.
• NT6: Đối thoại trực tiếp (face to face) là cách truyền đạt thông tin hữu hiệu nhất.
• NT7: Phần mềm chạy được là thước đo tiến độ chính xác và dễ hiểu nhất (rõ hơn báo cáo "50%, 40%" mơ hồ).
• NT8: Phát triển bền vững — sponsor, developer, user đều duy trì nhịp độ ổn định, tránh OT kéo dài; phải tìm root cause của việc OT.

▸ 3. Nhóm nguyên tắc về kỹ thuật và cải tiến (9–12)

• NT9: Liên tục quan tâm tới kỹ thuật và thiết kế để tăng tính linh hoạt và năng suất.
• NT10: Đơn giản — tối đa hóa lượng công việc không cần làm.
• NT11: Development Team tự tổ chức và tự kiến trúc, vì họ là người hiểu rõ yêu cầu nhất.
• NT12: Phản ánh (retrospective) đều đặn sau mỗi sprint rồi điều chỉnh cho phù hợp — làm sớm, đừng đợi đến cuối dự án.

Chương 3 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài mở đầu chương 3, giới thiệu Project Plan — bản kế hoạch đầu tiên và quan trọng nhất khi bắt tay thực hiện dự án. Điểm mấu chốt: Project Plan trong khóa gồm 13 mục, và tất cả đều xoay quanh 4 nguyên tố cốt lõi của dự án là time, cost, scope, quality.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu Project Plan là gì, vì sao cần có và tầm quan trọng của nó.
• Nắm tổng quan 13 mục thông tin cần fill trong một Project Plan.
• Thấy được mối liên hệ giữa Project Plan và 4 nguyên tố time, cost, scope, quality.

─── NỘI DUNG CHÍNH

▸ 1. Project Plan là gì và vì sao cần có

Project Plan chính là kế hoạch cho dự án — thứ đầu tiên hầu hết mọi PM phải làm khi khởi động dự án. Bài học kèm sẵn một file mẫu Project Plan; bạn có thể mở qua link hoặc quét QR code để xem trực tiếp mẫu này.

▸ 2. Fill Project Plan giúp bạn hiểu lại dự án

Giá trị lớn nhất của việc điền Project Plan không chỉ nằm ở file kết quả. Mỗi lần fill một mục, bạn lại study và định nghĩa lại dự án một lần nữa trong đầu — nhờ đó hiểu rõ hơn dự án cần làm gì, cùng những chiến lược và cách làm phù hợp. Đây là quá trình giúp PM nắm chắc dự án trước khi triển khai.

▸ 3. 13 mục xoay quanh 4 nguyên tố

Project Plan trong khóa gồm 13 mục, mỗi mục có ý nghĩa riêng và sẽ được hướng dẫn điền ở các bài tiếp theo. Dù có 13 mục, tất cả đều xoay quanh 4 nguyên tố của một dự án: time (thời gian), cost (chi phí), scope (phạm vi), quality (chất lượng). Khi làm Project Plan, bạn luôn quy chiếu về 4 nguyên tố này — đó là cách giữ cho kế hoạch bám sát bản chất của dự án.

Chương 3 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn điền sheet Overview — sheet đầu tiên của Project Plan, cho cái nhìn tổng quan về dự án. Điểm mấu chốt: Overview không chỉ có thông tin mô tả cơ bản, mà còn gom cả scope, out of scope, deliverable, ràng buộc, giả định và các điều kiện chấp nhận để mọi bên hiểu rõ dự án ngay từ đầu.

─── SAU BÀI HỌC, BẠN SẼ

• Điền được phần mô tả cơ bản của dự án trong sheet Overview.
• Phân biệt được functional và non-functional requirement.
• Biết cách ghi scope, out of scope, deliverable, ràng buộc và giả định của dự án.

─── NỘI DUNG CHÍNH

▸ 1. Thông tin mô tả dự án

Phần đầu ghi các thông tin nền: tên dự án, mã dự án, loại hợp đồng (ODC, Labo, Body Shopping, Fixed — tùy công ty quy định), tên khách hàng, billable effort (khách order bao nhiêu man-month), project level / rank, business unit, project type (development, website, maintain, new development…), business domain (y tế, giải trí, thể thao…) và loại ứng dụng (web hay mobile).

▸ 2. Functional và non-functional requirement

Ghi rõ các yêu cầu functional — ví dụ chức năng login, đăng nhập của một màn hình. Còn non-functional là những yêu cầu ngoài business requirement, ví dụ xử lý khi hàng nghìn, hàng triệu user đăng nhập cùng lúc. Cả hai đều được liệt kê ở phần này.

▸ 3. Scope, out of scope, deliverable

• Scope: tóm tắt phần WBS mình nhận, ví dụ từ giai đoạn Coding đến UT, IT hay cả System Test.
• Out of scope: những gì không thuộc phạm vi, ví dụ dự án chỉ Coding/UT thì Design là out of scope.
• Deliverable: sản phẩm gửi khách (source code…), ngày gửi và điều kiện chấp nhận khi gửi.

▸ 4. Ràng buộc, giả định và các điều kiện khác

• Ràng buộc (constraints): ví dụ tài liệu khách phải gửi đầy đủ, developer được cấp đúng skill từ lúc đề team.
• Giả định (assumptions): ví dụ giả định không ai nghỉ phép, không ai nghỉ việc, không có trục trặc mạng.
• Critical Dependencies: phụ thuộc bắt buộc để dự án chạy được (ví dụ back-end API do khách làm).
• Security và Acceptance: điều kiện bảo mật (không dùng điện thoại, không private email…) và các điều kiện được khách approve. Chưa rõ mục nào thì ghi to be defined.

Chương 3 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn điền sheet Environment — mô tả các môi trường của dự án. Điểm mấu chốt: một dự án phần mềm thường có 4 môi trường (dev, test, staging, production), và PM phải xác định rõ môi trường nào thuộc trách nhiệm của mình, môi trường nào của khách hàng — đặc biệt với công ty outsource.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt được 4 môi trường: development, test, staging và go-live (production).
• Hiểu vì sao outsource thường không nhận deploy lên môi trường production.
• Biết cách ghi rõ môi trường vào Project Plan và xử lý khi thông tin chưa rõ.

─── NỘI DUNG CHÍNH

▸ 1. Bốn môi trường của dự án

Một dự án thường có: môi trường development, môi trường test, môi trường staging và môi trường go-live (production). Development Team làm việc trên dev và test, rồi deploy lên staging cho khách hàng test. Staging là môi trường gần giống production nhất, nhưng thông thường team không deploy trực tiếp lên production mà chỉ dừng ở staging.

▸ 2. Ranh giới trách nhiệm với production

Việc deploy lên production đòi hỏi nhiều skill về DevOps và IT Infra (kiến trúc hạ tầng, quản lý server, AWS…) — thường nằm ngoài phạm vi của dân lập trình thuần. Vì vậy với outsource, PM thường từ chối phần production ngay trong estimation. Một số khách hàng, sau thời gian tin tưởng, có thể giao luôn phần này cho team — nhưng khi đó cần một hợp đồng khác. Khi khách hỏi, bạn hoàn toàn có thể trả lời rõ mình chỉ support tới đâu.

▸ 3. Điền môi trường vào Project Plan

Trong sheet Environment, ghi thật rõ từng môi trường: môi trường này cần cài gì, deploy gì, môi trường test ra sao. Thông tin này dựa vào estimation ban đầu.

▸ Lưu ý khi thông tin chưa rõ

Nếu estimation chưa rõ ràng về môi trường, hãy confirm với khách hàng trước rồi mới điền. Trong lúc làm mà chưa có hoặc chưa rõ môi trường nào, hãy ghi to be defined vào ô đó để đánh dấu cần hỏi lại khách — tránh điền bừa dẫn tới sai lệch kế hoạch.

Chương 3 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn điền sheet Scope — xác định phạm vi công việc của dự án. Điểm mấu chốt: sheet Scope trả lời câu hỏi "cần làm bao nhiêu để hoàn thành dự án này", và để điền đúng, bạn phải tổng hợp thông tin từ nhiều nguồn chứ không tự nghĩ ra.

─── SAU BÀI HỌC, BẠN SẼ

• Biết các nguồn cần tra cứu trước khi điền scope: estimation, contract, meeting minutes.
• Hiểu sheet Scope liệt kê những gì và nhằm trả lời câu hỏi gì.
• Nắm được rằng scope chỉ mô tả phạm vi, chưa gắn deadline.

─── NỘI DUNG CHÍNH

▸ 1. Tra cứu các nguồn trước khi điền

Trước khi điền sheet Scope, hãy vào estimation (proposal) trước đó để kiểm tra thông tin: ngôn ngữ, server, database, framework… và các mục trong WBS. Tiếp đó kiểm tra lại contract — lưu ý một số công ty outsource để bộ phận pháp lý quản lý hợp đồng nên PM có thể không thấy trực tiếp. Cuối cùng, rà lại các meeting minutes (biên bản họp) qua từng lần họp với khách để lấy phần discussion, summary.

▸ 2. Tổng hợp và điền vào sheet Scope

Sau khi thu thập, tổng hợp tất cả và điền vào sheet Scope trong Project Plan: có bao nhiêu chức năng, mỗi chức năng được implement bởi file nào, version tài liệu là gì. Ghi rõ các loại file sẽ tạo ra như detail design, coding, unit test, integration test case, integration test report — tất cả đều nằm trong phạm vi dự án.

▸ 3. Scope trả lời "cần làm bao nhiêu"

Bản chất sheet Scope là trả lời hai câu hỏi: cần làm bao nhiêu để hoàn thành dự án, và mỗi phần đó sẽ sinh ra bao nhiêu file. Đây là cơ sở để quản lý khối lượng công việc.

▸ Lưu ý: sheet chỉ là template, và scope không có deadline

Mẫu sheet trong khóa chỉ là template tham khảo — bạn không cần bê nguyên 100%, miễn hiểu đúng vai trò của sheet Scope. Ngoài ra, scope không có due date, không có deadline — nó chỉ mô tả phạm vi công việc mà công ty cần quản lý; phần lịch trình sẽ được xử lý ở tài liệu khác.

Chương 3 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn điền sheet Deliverable — quản lý các mốc bàn giao sản phẩm cho khách hàng. Điểm mấu chốt: PM phải nắm được cái gì release, release ngày nào, điều kiện chấp nhận là gì, và hiểu cách bộ phận QA kiểm tra trước khi sản phẩm được gửi cho khách.

─── SAU BÀI HỌC, BẠN SẼ

• Điền được sheet Deliverable: function, ngày commit release và acceptance criteria.
• Hiểu cách tính release đúng hạn (100%) so với release trễ.
• Nắm được release note là gì và quy trình QA check trước khi delivery.

─── NỘI DUNG CHÍNH

▸ 1. Các cột chính trong sheet Deliverable

Với mỗi function, ghi first commit release (ngày release đầu tiên cam kết với khách — đây là kế hoạch), cột replan nếu có thay đổi, và cột actual để điền ngày thực tế về sau. Nếu release đúng first commit thì tính 100%; nếu trễ (ví dụ cam kết 30/4 nhưng thực tế release 2/5) thì điểm số QA tính khác. Cột acceptance criteria ghi điều kiện hoàn thành (ví dụ fix hết bug, fix hết comment); chưa rõ thì ghi to be defined.

▸ 2. Release note

Release note là ghi chú đi kèm khi gửi sản phẩm cho khách. Nó liệt kê: phạm vi lần gửi này gồm những gì, các issue / giới hạn còn tồn đọng, guideline hướng dẫn, và kết quả QA check (cái gì pass, cái gì chưa pass). Mục tiêu là để khách nắm đầy đủ thông tin về những gì họ nhận được.

▸ 3. Quy trình QA check trước khi delivery

Trước khi giao sản phẩm, bộ phận QA kiểm tra: sản phẩm delivery có đủ không (function chạy được không, có guideline, có install, đủ so với estimation và contract chưa), check format tài liệu (đủ link, đã format chưa), và check KPI (số test case, số line of code có đúng target chưa). Đạt chuẩn thì QA approve cho gửi khách; không đạt thì chặn lại để rà soát.

▸ Lưu ý: sheet chỉ là template

Sheet Deliverable trong khóa chỉ là template mẫu — bạn có thể tự làm template theo cách của mình, miễn đủ thông tin. Ngoài ra, file mẫu bản Google Sheets có thể bị lỗi công thức do chuyển từ Excel; khóa học có kèm link tải file Excel gốc không bị lỗi.

Chương 3 · Bài 6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn điền sheet Risk và Issue trong Project Plan. Điểm mấu chốt: phân biệt Risk (rủi ro — chưa xảy ra) với Issue (vấn đề — đã xảy ra), và nắm được ba hướng xử lý khi đối mặt với một rủi ro trong dự án.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt rõ Risk và Issue.
• Nắm ba cách xử lý rủi ro cơ bản và ý nghĩa của từng cách.
• Biết cách điền Risk/Issue vào sheet: category, khả năng xảy ra và mức độ ảnh hưởng.

─── NỘI DUNG CHÍNH

▸ 1. Phân biệt Risk và Issue

Risk là rủi ro chưa xảy ra — một điều có thể xảy đến trong tương lai. Issue là vấn đề đã xảy ra rồi và cần giải quyết ngay. Ví dụ ẩn dụ: thấy trời tối mịt mù (dự đoán trời sẽ mưa) là risk; đang đi mà trời mưa xuống làm bạn ướt là issue. Đây là Risk & Issue Management Plan — vì là plan nên nó ghi lại những gì đang ở dạng dự phòng, chưa xảy ra.

▸ 2. Ba cách xử lý rủi ro

Khi đối mặt một rủi ro, PM có quyền lựa chọn, tựa như gặp một tảng đá trên đường:

1. Đi vòng (mitigate/avoid gián tiếp): chọn đường khác, tốn chút thời gian nhưng né được rủi ro.
2. Đập tảng đá, đi thẳng (chủ động xử lý): bỏ chi phí xử lý trước dù rủi ro chưa xảy ra — đổi lấy sự an tâm, dù có thể tốn công vô ích nếu rủi ro không thành.
3. Mặc kệ (accept): chấp nhận rủi ro, cứ tiến hành; biết đâu rủi ro không xảy ra, khỏi tốn thời gian và tiền bạc.

▸ 3. Cách điền Risk/Issue vào sheet

Liệt kê hàng loạt rủi ro, sau đó với mỗi rủi ro xác định: thuộc category nào (con người, yếu tố phụ thuộc, kiến trúc, quản lý…), khả năng xảy ra cao hay thấp, mức độ ảnh hưởng (impact) tới giai đoạn nào (Coding, UT…) và lợi ích khi xử lý. Đây là một template; file bản Google Sheets có thể bị lỗi hiển thị do chuyển từ Excel — khóa học có kèm link file Excel gốc trong mục tài liệu.

▸ Lưu ý: định nghĩa rủi ro là việc khó

Define rủi ro chính xác không dễ — thường cần người quản lý có kinh nghiệm. Trong thực tế, rủi ro con người là khó lường và chiếm tỷ trọng nhiều nhất (thành viên đột ngột xin nghỉ, nghỉ việc giữa dự án…). Hãy define trước các rủi ro để lưu lại và giúp mọi bên liên quan cùng hiểu.

Chương 3 · Bài 7

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn điền sheet Quality (Quality Plan) — định nghĩa tiêu chuẩn chất lượng cho dự án. Điểm mấu chốt: chất lượng không chỉ là bug, mà là một tập hợp nhiều chỉ số; và tiêu chuẩn chất lượng của mỗi dự án là khác nhau, phải tham chiếu nhiều nguồn trước khi chốt.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu chất lượng dự án gồm nhiều thành phần, không chỉ là số bug.
• Biết các nguồn cần tham khảo để định nghĩa tiêu chuẩn chất lượng.
• Điền được các chỉ số Quality Metrics phù hợp vào Quality Plan.

─── NỘI DUNG CHÍNH

▸ 1. Quality không chỉ là bug

Chất lượng dự án bao gồm nhiều standard: độ hài lòng khách hàng, Process Compliance Rate (tỷ lệ hoàn thành dự án đúng quy trình), Efficiency về chi phí và Timeliness (giao đúng hạn). Ngoài ra Quality Metrics trải qua các giai đoạn kiểm thử: UT, IT, System Test và AT (UAT — User Acceptance Test). Tất cả đều nằm trong Quality Plan, chứ không rút gọn thành "hết bug".

▸ 2. Bốn nguồn tham khảo để định nghĩa tiêu chuẩn

Trước khi điền, hãy tham chiếu: (1) estimation / proposal và nội dung ban đầu — bắt keyword như số lượng test case; (2) hợp đồng — điều kiện chất lượng khách yêu cầu; (3) tiêu chuẩn chất lượng mặc định của công ty (cận trên, cận dưới, các chỉ số đang đo); (4) ý kiến của Site Manager / Senior Manager và bộ phận QA (nhất là Quality Assurance Manager). Từ đó điều chỉnh và đưa vào Project Plan.

▸ 3. Điền các chỉ số Quality Metrics

Thường bạn chỉ điền cột overall, còn cột cận trên / cận dưới tự chạy theo công thức. Một số chỉ số ví dụ trong bài:

• Độ hài lòng khách hàng: số UAT bug khách bắt trên 1 man-month ở mức thấp (ví dụ 0.2 bug/man-month).
• Process Compliance Rate: khoảng 95%.
• Cost Efficiency: khoảng 95% (lấy bill chia cho calendar).
• Timeliness: 100% — sản phẩm giao đúng kế hoạch proposal ban đầu.
• Bug UT / 1000 LOC: nằm trong khoảng hợp lý (ví dụ khoảng 5–7 bug/1000 LOC). Quá ít nghĩa là bắt bug chưa chất lượng; quá nhiều nghĩa là sản phẩm kém.

▸ Lưu ý: mỗi dự án một tiêu chuẩn

Quality Plan mang tính định nghĩa tiêu chuẩn kế hoạch để về sau đo đạc trong quá trình làm dự án. Mỗi dự án không giống nhau nên tiêu chuẩn cũng khác nhau — hãy chọn đúng bộ metrics phù hợp với dự án của mình rồi mới điền vào.

Chương 3 · Bài 8

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn điền sheet Strategy trong Project Plan — nơi bạn ghi ra chiến lược để nâng chất lượng và tăng tốc dự án. Điểm mấu chốt: mọi chiến lược đều xoay quanh tam giác time – cost – quality (và scope ở giữa) — bạn tìm cách tối ưu bốn yếu tố này sao cho dự án chạy nhanh nhất, tốt nhất có thể.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu sheet Strategy ghi thông tin gì và vì sao nó quan trọng với chất lượng dự án.
• Biết cách mô tả từng loại chiến lược: ngăn lỗi, review, test, đào tạo, công cụ.
• Ghi được chiến lược rõ ràng để cả đội cùng thực hiện thống nhất.

─── NỘI DUNG CHÍNH

▸ 1. Sheet Strategy ghi gì và điền thế nào?

Sheet gồm khoảng 6 mục, mỗi mục là một hướng chiến lược. Với mỗi mục bạn ghi rõ: làm gì, ai làm, khi nào, điều kiện hoàn thành là gì. Cách nghĩ đơn giản: nhìn vào tam giác time – cost – quality – scope, tự hỏi làm sao quản lý và làm nhanh – tốt nhất từng yếu tố. Câu trả lời chính là chiến lược của bạn.

▸ 2. Các loại chiến lược thường gặp

• Ngăn lỗi lặp: lỗi hay phát sinh do communication kém, nhất là dự án outsourcing. Cách chặn: tăng meeting và trao đổi với khách hàng ở giai đoạn đầu, hỏi rõ những phần chưa chắc qua hệ thống (ví dụ Redmine).
• Review: thay vì để 4 Dev làm song song hàng loạt, cho làm xong màn hình đầu tiên thì dừng lại review rồi mới làm tiếp — tránh sai một chỗ sai cả loạt. Ghi rõ: review theo checklist, reviewer là ai, loại review (peer / group / team lead), review bằng tool hay manual.
• Test: ghi kỹ thuật test (black box, white box, smoke, stress), tool dùng, cách chia người test (ví dụ tách nhóm test logic và nhóm test layout).
• Đào tạo & công cụ: có member mới thì lên kế hoạch training (ai, bao lâu); thiếu công cụ thì ghi rõ cần tạo/xin thêm công cụ, license nào để tăng tốc dự án.

▸ Mẹo quan trọng: học chiến lược từ người đi trước

PM mới thường biết làm nhưng khó diễn đạt thành câu chữ trong sheet. Hãy trao đổi với cấp cao hơn để họ chia sẻ cách ghi và cách tư duy — bạn sẽ hiểu và viết chiến lược đúng, hữu ích hơn.

Chương 3 · Bài 9

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn điền sheet Resource Allocation — kế hoạch phân bổ nguồn lực của dự án. Điểm mấu chốt: bạn phải đối chiếu số man-month mình phân bổ với số man-month khách hàng trả (theo bill/estimation), để biết nguồn lực đang thừa hay thiếu so với khối lượng công việc thực tế.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu sheet Resource Allocation ghi gì và vì sao phải cân với estimation ban đầu.
• Biết điền tên người, effort (%), thời gian tham gia để hệ thống tự tính calendar.
• Đọc được chỉ số man-month để nhận ra dự án đang bị thiếu hay đủ người.

─── NỘI DUNG CHÍNH

▸ 1. Sheet Resource Allocation ghi thông tin gì?

Sheet ghi ai tham gia dự án, ở vai trò gì, effort bao nhiêu phần trăm, tham gia từ tháng nào đến tháng nào. Đầu sheet có phần bill — khách hàng trả bao nhiêu man-month, đối chiếu với calendar (số ngày công) mình thực bỏ ra. Bạn đặt target, ví dụ effort 100%, quality 85%, rồi điền dữ liệu vào để hệ thống đánh giá.

▸ 2. Cách điền và công thức tính calendar

Với mỗi người, bạn điền tỷ lệ allocate (ví dụ 100%, hay 50% nếu người đó chỉ tham gia một phần). Công thức tự tính số ngày công theo dạng:

• NETWORKDAYS(from, to) − holiday, rồi nhân cho tỷ lệ allocate.

Cộng toàn bộ lại ra tổng man-month mà dự án đang phân bổ. Giảng viên có kèm một video riêng về calendar effort (link ngay trong template) giải thích kỹ hơn công thức này — bạn nên xem để hiểu cách tính.

▸ 3. Đọc chỉ số để biết thừa hay thiếu người

Ví dụ khách hàng trả 19 man-month nhưng bạn chỉ phân bổ 16 man-month → tỷ lệ vọt lên 122% so với target 85%, nghĩa là đang đổ ít người hơn so với khối lượng công việc. Vậy phần việc của 3 người còn lại nằm ở đâu, hay đang bị thiếu? Đó là dấu hiệu not good. Khi số phân bổ tiến gần 19 (ví dụ 18.5) thì mới coi là hợp lý.

Vì vậy khi lên kế hoạch, luôn so nguồn lực phân bổ với estimation/báo giá ban đầu để chắc chắn kế hoạch cân đối, đủ người thực hiện.

Chương 3 · Bài 10

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn điền sheet Communication Plan — nơi xác định các kênh giao tiếp của dự án. Điểm mấu chốt: ngay khi start dự án bạn phải chốt kênh giao tiếp với khách hàng và nội bộ; template đóng vai trò như một checklist để bạn nhìn vào là nhớ điền đủ các loại meeting và thông tin liên hệ.

─── SAU BÀI HỌC, BẠN SẼ

• Biết sheet Communication Plan cần khai báo những thông tin gì.
• Phân biệt được các loại meeting: daily, weekly, technical/issue/milestone.
• Hiểu vì sao dự án lớn cần quy định rõ ai được liên lạc với ai.

─── NỘI DUNG CHÍNH

▸ 1. Chọn kênh giao tiếp và công cụ

Trước hết chọn công cụ chat/notification tích hợp được với hệ thống quản lý để nhận thông tin real time: Slack, Skype, Chatwork (đều có bản miễn phí). Meeting online thì dùng Google Meet, Zoom, Microsoft Teams. Trong dự án nhỏ, phần này có thể ghi rất gọn (ví dụ "kênh giao tiếp: group Zalo").

▸ 2. Sheet Communication Plan điền gì?

Template ghi rõ từng loại meeting kèm: mục đích (agenda), ai tham gia, công cụ dùng, tài liệu cần chuẩn bị, việc viết meeting minutes và approve, cùng thông tin liên hệ (địa chỉ, người phụ trách). Nội dung có thể không điền hết cũng không sao — quan trọng là dùng nó như checklist để không bỏ sót.

▸ 3. Ba loại meeting cố định

• Daily: họp mỗi ngày.
• Weekly: có hai kiểu — weekly với khách hàng (báo cáo tổng kết tuần) và weekly nội bộ.
• Technical / issue / milestone meeting: họp khi phát sinh vấn đề (ví dụ về database, framework) hoặc theo mốc dự án.

Ngoài các loại cố định, thực tế có thể phát sinh nhiều meeting khác — cứ điền hết vào là xong.

▸ Lưu ý khi làm dự án lớn: quy định luồng liên lạc

Nhiều dự án lớn ghi rõ ai được quyền liên lạc với ai. Ví dụ chỉ PM hoặc communicator được liên hệ trực tiếp khách hàng; mọi người khác phải thông qua họ. Lý do: liên lạc trực tiếp khi chưa nắm đủ thông tin dễ làm mất thời gian của khách hàng — điều nên tránh.

Chương 3 · Bài 11

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn điền sheet OrgChart — sơ đồ tổ chức dự án. Điểm mấu chốt: org chart không chỉ vẽ ai đứng ở đâu, mà còn thể hiện chiến lược đánh dự án của bạn — cách chia team, phân bổ người theo khối lượng công việc chính là cách bạn triển khai dự án.

─── SAU BÀI HỌC, BẠN SẼ

• Biết sheet OrgChart cần thể hiện những thông tin gì.
• Vẽ được sơ đồ tổ chức phản ánh chiến lược phân bổ nguồn lực.
• Ghi rõ vị trí – vai trò – trách nhiệm cho từng thành viên.

─── NỘI DUNG CHÍNH

▸ 1. Sheet OrgChart gồm những gì?

Sheet thể hiện: vị trí và vai trò của từng người, sơ đồ tổ chức, trách nhiệm, thông tin thành viên, và chiến lược tổ chức. Bạn có thể vẽ theo template mẫu hoặc dùng công cụ khác. Sơ đồ đi từ người cao nhất xuống các nhánh; dự án càng lớn thì càng phình ra nhiều team (dev 1, dev 2, team lead...). Với thị trường Nhật thường có thêm role comtor/communicator (translator); ngoài ra có QA, tester, và CM (người quản lý cấu hình dự án).

▸ 2. Org chart thể hiện chiến lược dự án

Cách chia team chính là chiến lược: team nào khối lượng công việc lớn thì nhiều người hơn, ít thì ít người hơn. Bạn có thể nhét BA, tester vào chung từng team dev để họ chịu trách nhiệm theo team đó, hoặc để technical team bên ngoài support toàn bộ vấn đề kỹ thuật. Việc "đánh dọc hay đánh ngang", gộp chung hay tách riêng đều phản ánh cách bạn triển khai dự án, nên org chart mỗi dự án sẽ khác nhau nhiều.

▸ 3. Vị trí – vai trò – trách nhiệm (phần quan trọng)

Một người có thể kiêm nhiều vai trò. Ví dụ anh A vừa là PM (50%), vừa là test lead hoặc BA lead (50%). Phần này phải ghi rất rõ công việc mà mỗi người cần làm, kèm ai là person phụ trách chính. Ngoài ra là thông tin cơ bản của member: tên, tài khoản, email, số điện thoại, địa chỉ, tham gia dự án nào.

▸ Lưu ý sau khi hoàn thành

Làm xong sheet org chart chưa phải là hết — bạn cần có một buổi trình bày với team để mọi người nắm rõ cơ cấu tổ chức và vai trò của mình trong dự án.

Chương 3 · Bài 12

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giải thích Tailoring — các yếu tố/quy định ngoại lệ khi thực hiện dự án. Điểm mấu chốt: khi dự án của bạn không thể chạy đúng theo quy trình chuẩn của công ty, bạn phải xin approve tailoring từ cấp cao hơn để được phép làm khác đi mà vẫn hợp lệ.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu Tailoring là gì và vì sao dự án cần đến nó.
• Biết ai là người approve tailoring và quy trình xin thế nào.
• Đọc được bảng quy định tailoring để chọn đúng điều khoản cho dự án.

─── NỘI DUNG CHÍNH

▸ 1. Tailoring là gì và vì sao cần?

Mỗi công ty có một bộ quy trình chuẩn (theo KPI, quy định nội bộ). Nhưng do tính chất riêng, có quy trình dự án bạn không thể tuân theo đúng chuẩn. Khi đó bạn phải xem kho Tailoring của công ty — nơi lưu các quy định ngoại lệ — rồi đối chiếu xem dự án có phù hợp không. Nếu cần làm khác chuẩn, phải xin approve từ Senior Manager và Quality Assurance Manager.

▸ 2. Đọc bảng tailoring và chọn điều khoản

Tài liệu tailoring thường gồm: quy định role trong file, process life cycle (toàn bộ quy trình dự án), software engineering process group (các quy trình hoạt động development), ID của từng tailoring, và process sẽ apply. Ví dụ điển hình:

• Khách hàng quản lý qua Jira còn công ty bạn chuẩn dùng Redmine → bạn xin tailoring để chạy theo Jira của khách hàng.
• Một tailoring quy định: dự án có duration dưới 1.5 tháng thì chỉ cần control 3 metric, không cần theo dõi các con số khác (bug, test case...).

Đây chỉ là sample — mỗi công ty có bộ tailoring và quy định khác nhau, nên bạn cần hỏi phía dự án/công ty xem có những tailoring nào áp dụng được.

▸ 3. Quy trình xin approve

Khi start dự án, bạn trao đổi với bộ phận QA, nêu rõ dự án muốn áp dụng tailoring nào và điền các ID tương ứng. Cách gửi: gửi mail, hoặc nếu công ty có ticket open dự án thì log lên ticket và ghi rõ lý do. Sau khi được xem xét và feedback OK, dự án của bạn sẽ apply theo tailoring đó, ưu tiên hơn chuẩn chung của công ty.

Chương 3 · Bài 13

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn điền CM Plan (Configuration Management Plan) — tổ chức cấu hình cho dự án. Điểm mấu chốt: CM Plan quy định thống nhất cách đặt tên file, cấu trúc thư mục lưu trữ, cấu trúc source code trên git và phân quyền — nhờ đó cả đội commit, lưu trữ theo cùng một rule, giúp quản lý mọi thứ chặt chẽ.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu CM Plan quy định những nội dung gì và vì sao quan trọng.
• Biết cách tổ chức cấu trúc folder lưu trữ và phân quyền theo group.
• Nắm quy tắc naming convention cho file và source code trên git.

─── NỘI DUNG CHÍNH

▸ 1. CM Plan quy định những gì?

Ba nhóm chính: (1) cấu trúc folder trên SVN / file server — nơi lưu trữ; (2) cấu trúc folder của dự án (ví dụ tổ chức folder test case ra sao); (3) cấu trúc source code trên git cùng naming convention hợp lý. Đầu file còn ghi: dùng Redmine version nào, đường dẫn lưu trữ, communication tool nào và tên quy định của chúng.

▸ 2. Cấu trúc folder và phân quyền

Template mẫu tổ chức thư mục theo nhiều cấp, ví dụ các folder: source/audit, reference, working area, rồi chia theo giai đoạn — project management (project initiation, project plan, estimation, schedule), monitoring (tracking hằng ngày), design (database, basic design, detail design), implementation (review code), testing (template unit/integration test case), delivery (zip file gửi khách hàng theo quy định).

Về permission: mỗi folder quy định group nào có quyền gì (ví dụ group PM và group template được modify), và mỗi account thuộc group nào. Với git, khai báo nhánh master, develop, ai có quyền nào, cùng quy định cho doc, style, refactor, test.

▸ 3. Vì sao phải cập nhật CM Plan liên tục?

CM Plan giúp bạn kiểm soát toàn bộ dự án và giữ rule thống nhất để developer/tester vào dự án commit đúng chuẩn. Thực tế có nhiều tình huống cần đến nó: ví dụ khách hàng muốn nhận từng chức năng đúng tiến độ, nhưng team làm nhanh hơn — khi cho làm trước, việc đặt tên và lưu trữ hợp lý là rất cần thiết. Vì vậy khi dự án phát sinh, phải cập nhật CM Plan và phổ biến cho mọi người.

▸ Lưu ý về đặt tên file

Đặc biệt để ý tên file: quy ước thường đặt version ở phía trước, phần còn lại theo sau — giúp quản lý và tra cứu dễ dàng.

Chương 4 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học mở đầu Chương 4, giới thiệu Detail Schedule (lịch trình chi tiet) — bản chi tiết công việc từng người, từng ngày trong dự án. Điểm mấu chốt: sau khi đã có estimation và Project Plan, bạn cần lên Detail Schedule để mỗi người biết mỗi ngày làm gì, còn PM thì luôn nắm được dự án đang đi tới đâu.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu Detail Schedule là gì và vai trò của nó trong quản lý dự án.
• Nắm 4 yếu tố bắt buộc của một dòng công việc trong lịch trình.
• Hình dung cấu trúc một file Detail Schedule mẫu.

─── NỘI DUNG CHÍNH

▸ 1. Detail Schedule là gì và vì sao quan trọng?

Từ khối lượng công việc đã có (estimation ban đầu) và chiến lược trong Project Plan, bạn lên lịch trình chi tiết các công việc. Nó giúp mỗi thành viên biết hôm nay làm gì và làm thế nào cho kịp tiến độ. Ví dụ: developer A hôm nay coding màn hình A, sau đó unit test màn hình A; tester thì viết test case màn hình A. Khi công việc được chi tiết như vậy, mọi người follow up dễ hơn, và người quản trị dự án luôn biết dự án đang ở đâu. Đây là phần bắt buộc PM phải hiểu và biết làm.

▸ 2. Bốn yếu tố của một dòng công việc

Mỗi công việc trong Detail Schedule gồm:

1. Tên công việc (task).
2. Khối lượng effort dự kiến của công việc đó.
3. Người thực hiện.
4. Kế hoạch ngày bắt đầu và ngày kết thúc.

▸ 3. Đọc file Detail Schedule mẫu

File mẫu liệt kê từng task kèm: ID, thuộc dự án nào, tracker, file, nội dung công việc, người thực hiện, khi nào xong và số giờ (ví dụ 2, 4, 6 giờ). Lưu ý: khi mới lên kế hoạch, cột actual chưa có và mọi task đều ở trạng thái new (vì dự án chưa thực hiện). Ngoài ra file có thêm sheet graph phục vụ burn down — thể hiện tiến độ công việc hiện tại. Đó chính là hình dung cơ bản về một Detail Schedule.

Chương 4 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học phân biệt hai khái niệm Master Schedule (lịch trình tổng quan) và Detail Schedule (lịch trình chi tiết). Điểm mấu chốt: Master Schedule nhìn ở mức phase/function cho khách hàng và top level đọc; Detail Schedule đi vào từng công việc nhỏ (coding, testing) cho đội thực hiện dùng.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt được Master Schedule và Detail Schedule.
• Biết mỗi loại schedule phục vụ đối tượng đọc nào.
• Hiểu vai trò của Gantt chart trong việc thể hiện lịch trình.

─── NỘI DUNG CHÍNH

▸ 1. Master Schedule — góc nhìn tổng quan

Master Schedule là lịch trình lớn, ghi mốc ở cấp phase và function: ngày bắt đầu và ngày kết thúc mỗi phase, mỗi function. Đối tượng đọc chính là khách hàng hoặc top level — họ nhìn vào đây trước để nắm bức tranh tổng thể. Master Schedule không đi vào chi tiết là để hoàn thành một function thì phải coding, testing từ ngày nào đến ngày nào.

▸ 2. Detail Schedule — góc nhìn chi tiết

Ngược lại, Detail Schedule là lịch trình nhỏ hơn, chi tiết đến từng công việc bên trong: việc coding bắt đầu/kết thúc khi nào, việc testing bắt đầu/kết thúc khi nào, ai làm, bao nhiêu giờ. Đây là bản mà đội thực hiện dùng để theo dõi công việc hằng ngày. Đó chính là sự khác nhau cốt lõi: một bên tổng hợp cả phase/function, một bên bóc nhỏ từng task.

▸ 3. Gantt chart và template mẫu

Bài học kèm hai template tham khảo. Template Gantt chart minh họa Master Schedule: các phase (phase 1, phase 2...) hiện thành thanh ngang từ ngày đến ngày, nhìn tổng quan. Khi bạn thử tăng/giảm một ngày trong template, các mốc phía sau tự chạy theo — cho thấy lịch trình liên động. Template thứ hai là Detail Schedule mẫu đã xem ở bài trước: chi tiết từng người, từng ngày làm gì, kèm số giờ (template mẫu này còn thiếu cột số giờ). Nhờ hai mẫu, bạn hình dung rõ khi nào dùng Master, khi nào dùng Detail.

Chương 4 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn cách phân tích khối lượng công việc từ estimation (ước lượng, báo giá) ban đầu để tạo ra Detail Schedule, dựa trên tư duy WBS — chia nhỏ công việc. Điểm mấu chốt: báo giá ban đầu chỉ nên coi là tham khảo; bạn phải re-estimate khi đã có đủ tài liệu, rồi rã công việc theo từng phase để ra effort thực tế.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao phải re-estimate thay vì tin tuyệt đối vào báo giá ban đầu.
• Biết cách chia công việc theo phase và phân bổ effort bằng tỷ lệ phần trăm.
• Hình dung đường đi từ estimation → danh sách task → Detail Schedule.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao phải re-estimate?

File estimation ban đầu thường được lập khi chưa mường tượng hết hệ thống — người báo giá chỉ ước lượng sơ bộ, và con số thường được nắn cho vừa budget của khách hàng (ví dụ khách có 5.000 đô thì báo giá quanh mức đó để nhận được dự án). Vì vậy hãy mặc định estimation ban đầu chỉ là tham khảo. Khi nhận dự án và có đủ tài liệu hơn, bạn cho team re-estimate lại (trao đổi với cấp cao và các bên liên quan) để có con số hợp lý hơn nhiều.

▸ 2. Rã công việc theo phase (WBS) và phân bổ effort

Từ con số re-estimation, bạn rã ra các công việc chi tiết hơn theo các phase/activity thường gặp trong dự án phần mềm: coding, review code, unit test case, test, feedback. Effort mỗi task nên quy về giờ để nhất quán. Cách phân bổ là chia tỷ lệ phần trăm trên tổng effort của một hạng mục, ví dụ: coding 70% – review code 30%; hoặc tạo test case 50% – test 35% – feedback 15%. Nhờ vậy, từ một con số effort tổng, bạn tính ra effort cho từng phase con của mỗi màn hình.

▸ 3. Từ estimation đến Detail Schedule

Khi đã có effort từng phase cho từng màn hình, bạn ghép lại thành tên task (ví dụ "Coding bài 1", task report, unit test case...) rồi dựng danh sách task. Từ danh sách này lập Detail Schedule gồm: số thứ tự, tên task, priority (độ ưu tiên), người thực hiện, task effort, version, ghi chú. Sau khi điền người và effort, bạn còn phải điền start date / end date.

▸ Lưu ý: start/end date cần công cụ chuyên dụng

Việc tính start date, end date thông minh — tự tránh ngày lễ, ngày nghỉ, thứ Bảy và Chủ Nhật — không làm tốt trên Excel được. Phần này sẽ dùng một phần mềm khác (Microsoft Project) ở các bài sau.

Chương 4 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn dùng Microsoft Project để biến khối lượng công việc (từ Detail Schedule) thành một kế hoạch có start date / finish date thực tế cho từng người. Điểm mấu chốt: cân bằng (allocate) effort giữa các Dev sao cho không ai bị overload, thiết lập lịch nghỉ để ngày tháng tự né cuối tuần / ngày lễ, và hiểu rằng cách sắp task chính là chiến lược thực hiện dự án.

─── SAU BÀI HỌC, BẠN SẼ

• Cân đối khối lượng công việc giữa các Dev bằng hàm UNIQUE, SUMIF và biểu đồ.
• Nhập task, Resource Name, Work vào Microsoft Project và thiết lập calendar ngày nghỉ.
• Dùng Predecessor để tính start/finish date tự động, tránh overload.

─── NỘI DUNG CHÍNH

▸ 1. Cân đối effort trước khi lên lịch

Từ file khối lượng công việc, dùng hàm UNIQUE để lấy danh sách Dev, rồi SUMIF để cộng effort mỗi người. Vẽ thêm column chart để thấy rõ ai đang gánh nhiều: ví dụ Dev 3 chiếm tỷ trọng cao, Dev 4 thấp nhất → san sẻ bớt việc từ Dev 3 sang Dev 4/Dev 1. Lưu ý khi san việc phải xét năng lực người nhận có phù hợp không, đến khi khối lượng tương đối cân bằng.

▸ 2. Nhập dữ liệu vào Microsoft Project

Mở Microsoft Project (blank plan) → tạo plan, tạo các task, rồi điền Resource Name (tên người) và Work (số giờ). Lưu ý đơn vị: mặc định Work tính theo ngày, muốn nhập theo giờ phải gõ đúng định dạng giờ, nếu không nó hiểu là ngày.

▸ 3. Thiết lập calendar ngày nghỉ

Vào Project → chỉnh calendar, đánh dấu các ngày nghỉ (ví dụ 30/04, 01/05, 02/05) vào exception date; các ngày thứ Bảy/Chủ Nhật là non-working. Chọn standard calendar cho toàn dự án. Nhờ vậy lịch trình tự động bỏ qua ngày nghỉ.

▸ 4. Dùng Predecessor và tránh overload

Khai báo Predecessor cho mỗi task (task này xong thì task kia mới bắt đầu) → Microsoft Project tự tính start/finish date phù hợp. Nếu cột đầu còn hiện hình người, nghĩa là người đó bị overload (làm hơn 8 tiếng/ngày, hơn 100%) → cần điều chỉnh lại.

▸ Mẹo quan trọng: đừng quên task "không tên"

Cách sắp task (theo hàng ngang — một người làm hết một loại task, hay theo hàng dọc — một màn hình code xong rồi review xong) chính là chiến lược dự án. Ngoài task chính, nhớ đưa cả các task không tên vào kế hoạch: setup môi trường, release, dịch tài liệu, review test case… — chúng bắt buộc phải hoàn thành nên phải nằm trong plan.

Chương 4 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn đưa Detail Schedule (danh sách task) lên hệ thống quản lý Redmine một cách nhanh chóng, bằng hai cách: dùng chức năng import CSV có sẵn, và dùng một công cụ tự viết trên Google Sheet. Điểm mấu chốt: thay vì tạo tay từng issue, bạn đẩy hàng loạt task lên hệ thống chỉ trong vài thao tác.

─── SAU BÀI HỌC, BẠN SẼ

• Biết cách lấy template import đúng của Redmine bằng mẹo export.
• Import được danh sách công việc lên Redmine qua file CSV.
• Hiểu cách một công cụ tự viết giúp get/update task hàng loạt.

─── NỘI DUNG CHÍNH

▸ 1. Lấy template import và chuẩn bị dữ liệu

Redmine import theo file CSV, nên trước tiên bạn cần đúng template các cột. Mẹo: tạo một issue mẫu (ví dụ task 1, đặt start date), rồi export ra CSV để lấy đúng header/template. Copy header đó sang sheet đang làm, rồi map dữ liệu của bạn vào các cột như subject (tên công việc), start/end date, severity, priority (Normal), estimate time, % done (mới lên thì bằng 0). Bỏ cột ID vì lần đầu chưa có ID.

▸ 2. Lưu ý về các trường phân cấp (depth)

Các trường depth 1, 2, 3, 4 phải khớp với giá trị đã tồn tại trên Redmine, nếu không import lên sẽ bị null. Vì vậy trước khi import, bạn cần tạo sẵn các mục depth tương ứng trên hệ thống. Khi import: chọn file CSV, chọn encoding (UTF-8), chọn format ngày tháng năm, rồi map các trường (tracker, status...) và review lại trước khi chạy. Hệ thống import dần (ví dụ 5/75) tới khi báo thành công.

▸ 3. Công cụ tự viết trên Google Sheet

Ngoài import, giảng viên demo một công cụ tự viết bằng Google Sheet làm việc tương tự nhưng linh hoạt hơn. Nó gọi API của Redmine để: get full issue (kéo toàn bộ task của dự án về sheet), update các dòng đã chọn từ sheet lên Redmine, và bắn task mới (dòng chưa có ID) lên rồi nhận lại ID trả về. Nhờ vậy bạn update hàng loạt trong quá trình làm dự án, kéo data về để báo cáo cho dễ.

▸ Lưu ý: cách làm này áp dụng cho mọi hệ thống

Không riêng Redmine — Jira, Backlog hay hệ thống khác đều có chức năng export/import và API tương tự. Vì vậy bạn dùng đúng cách này để đẩy danh sách task và quản lý công việc trên bất kỳ hệ thống nào.

Chương 4 · Bài 6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học chỉ cách kéo dữ liệu từ Redmine về Excel / Google Sheets để làm báo cáo nhanh. Điểm mấu chốt: bạn chỉ cần một sheet raw data hứng dữ liệu mới nhất mỗi ngày, còn toàn bộ công thức và dashboard phía sau sẽ tự cập nhật theo. Có hai đường lấy data — export sẵn của Redmine, hoặc tự viết tool nếu bạn biết lập trình.

─── SAU BÀI HỌC, BẠN SẼ

• Export toàn bộ issue từ Redmine ra file CSV (chọn all column, filter status là Any).
• Import CSV vào Excel qua Data → Get Data → From File → From Text/CSV rồi Load data.
• Dựng báo cáo bằng pivot và chart theo người, theo status, theo effort.

─── NỘI DUNG CHÍNH

▸ 1. Export dữ liệu từ Redmine

Vào Redmine, dùng chức năng export, lấy hết issue với mọi trạng thái (filter Any). Khi export CSV, chọn all column để có đủ dữ liệu cho báo cáo — đừng chỉ chọn selected column. File ra chứa tất cả các trường của issue.

▸ 2. Import và thống kê trong Excel / Spreadsheet

Mở file Excel mới, vào Data → Get Data → From File → From Text/CSV, chọn file vừa export, review rồi Load data. Có data rồi thì insert pivot để thống kê: tổng task mỗi người, tổng estimate time, số lượng theo status… rồi vẽ chart để nhìn ai đang gánh nhiều, ai ít.

▸ 3. Cập nhật hằng ngày bằng sheet raw data

Mỗi ngày export data mới, dán vào đúng sheet data. Các công thức trong template sẽ tự sum lại, lấy status mới nhất và cho ra báo cáo cập nhật. Muốn chạy đúng thì phải chuẩn hóa data trước khi đổ vào.

▸ 4. Hai cách lấy data và template có sẵn

Cách một: export CSV trực tiếp từ hệ thống — dành cho người không lập trình. Cách hai: tự viết một tool get data, nhấn chuột phải là kéo dữ liệu về, rồi dán vào template. Khóa học có chia sẻ sẵn template báo cáo Spreadsheet tính được độ trễ, độ dư và có sheet dashboard tổng thể — bạn chỉ cần đổ data vào đúng chỗ là chạy.

Chương 5 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Mở đầu chương đo lường số liệu dự án, bài học chỉ cách đếm Line Of Code (LOC) — đơn vị output nhỏ nhất của một developer. Điểm mấu chốt: dùng công cụ StepCounter để tách rõ code thật, comment và dòng trống; và vì đây là tool của Nhật nên phải chuyển locale máy sang tiếng Nhật trước, nếu không sẽ lỗi phông chữ.

─── SAU BÀI HỌC, BẠN SẼ

• Cấu hình locale tiếng Nhật để StepCounter chạy không lỗi phông.
• Đếm được actual code, comment, blank cho từng file, từng folder.
• Định nghĩa thêm ngôn ngữ lập trình mà tool chưa hỗ trợ và copy số liệu ra Excel/Sheets.

─── NỘI DUNG CHÍNH

▸ 1. Cấu hình trước khi dùng StepCounter

Tải StepCounter (có link trong khóa hoặc search trên mạng). Vì là tool của Nhật, vào Region → Administrative, chỉnh locale sang tiếng Nhật rồi khởi động lại máy. Có vậy tool mới đọc đúng source, không bị lỗi phông chữ.

▸ 2. Đếm LOC và định nghĩa ngôn ngữ

Mở tool, kéo (quăng) source vào — nó tự nhận diện encoding rồi tách ra: comment, blank và actual (code thật). Nếu có ngôn ngữ tool chưa hỗ trợ (ví dụ PHP), bạn phải define: khai báo comment theo line (`//`) và theo block, tạo loại file mới, khai phần đuôi (extend) và tên file cần count.

▸ Mẹo quan trọng: dán data không bị lỗi

Copy toàn bộ kết quả rồi dán vào Excel hay Google Sheets thường bị lỗi (nhất là dòng header). Cách xử lý: chuyển bộ gõ ở taskbar sang tiếng Nhật, quay lại tool copy lại rồi dán — lỗi sẽ hết. Thực ra phần lỗi thường chỉ nằm ở header nên vẫn dùng được, chịu khó một chút.

▸ 3. Template đếm LOC tự viết

Khóa học chia sẻ một folder template (cũng chạy trên StepCounter). Bạn bỏ source vào, cấu hình sheet parameter (function của ai, màn hình nào, file/folder nào không count — có cả gitignore), rồi nhấn nút count line code. Tool tự đổ số liệu: LOC theo từng màn hình, trung bình, theo từng người và theo từng ngày để tính năng suất.

Chương 5 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học chỉ cách đếm test case — đơn vị nhỏ nhất phản ánh output của một tester. Điểm mấu chốt: có hai cách gom số liệu test case từ nhiều file rải rác — một tool VBA chạy trên Excel do giảng viên viết, và cách dùng hàm IMPORTRANGE trên Google Sheets để lấy số liệu trực tiếp, cập nhật realtime.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao test case là thước đo khối lượng công việc của tester.
• Dùng tool VBA để count tổng test case và số test case OK từ một folder.
• Dùng IMPORTRANGE để tổng hợp số lượng test case từ nhiều file Spreadsheet.

─── NỘI DUNG CHÍNH

▸ 1. Test case là gì?

Test case chính là đơn vị nhỏ nhất của một người tester — khi test một sản phẩm, họ tạo file test case (có thể là integration test hay unit test). Đếm được số lượng test case giúp bạn đo khối lượng công việc kiểm thử của team.

▸ 2. Đếm test case bằng tool VBA trên Excel

Giảng viên viết sẵn một tool VBA (có chia sẻ trong folder công cụ của khóa). Bạn chỉ cần điền tên file, folder, dòng, column, sheet cần đọc rồi nhấn Go and Get. Tool chạy vào folder, lấy đúng dòng trong từng file test case và trả về tổng số test case cùng tổng số test case OK. Có kèm guideline hướng dẫn từng bước.

▸ 3. Đếm test case trên Google Sheets bằng IMPORTRANGE

Nếu mỗi thành viên viết test case trên một file Spreadsheet riêng, bạn dùng hàm IMPORTRANGE để import data từng file về một sheet tổng. Lần đầu import phải allow permission thì mới lấy được. Ưu điểm: khi tester bên kia cập nhật số lượng test case, con số bên bạn nhảy trực tiếp theo, không cần làm lại thủ công.

Chương 5 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học chỉ cách thống kê bug để đo chất lượng dự án. Không dự án nào là không có bug, nên việc theo dõi chỉ số bug là bắt buộc. Điểm mấu chốt: export bug từ Redmine ra CSV, đổ vào Excel/Google Sheets rồi dùng pivot và chart để nhìn ra bug tập trung ở đâu, thuộc loại nào — từ đó ra được đề nghị cải thiện.

─── SAU BÀI HỌC, BẠN SẼ

• Export danh sách bug từ Redmine ra CSV và import vào Excel/Google Sheets.
• Thống kê bug theo status và assignee bằng pivot và chart.
• Phân tích tỷ trọng loại bug để đề xuất hành động cải thiện chất lượng.

─── NỘI DUNG CHÍNH

▸ 1. Chuẩn bị và export bug từ Redmine

Trong demo, giảng viên chuyển tracker của khoảng 50 issue thành bug (chuột phải → edit → tracker type = bug → Submit) để có data. Sau đó filter tracker là bug, dùng chức năng export CSV, chọn all column và tải file về.

▸ 2. Import và thống kê

Import file vào Excel bằng Data → From File CSV (hoặc đổ vào Google Sheets), rồi insert pivot để thống kê: bao nhiêu bug, ai nhiều bug (assignee), phân bố theo status (ví dụ status new). Vẽ thêm chart để thấy ngay ai đang gánh nhiều bug, trạng thái ra sao.

▸ 3. Phân tích loại bug và ra đề nghị

Khóa học có template thống kê bug sẵn: phân loại bug theo nhóm, vẽ chart bug nhiều nhất / ít nhất. Ví dụ trong mẫu, lỗi layout chiếm khoảng 47% (bug bất cẩn), custom logic chiếm 58% và có tỷ trọng misunderstand requirement cao. Từ đó ra lời khuyên: tăng cường training, và nếu team không nắm nghiệp vụ thì cần BA hoặc khách hàng giải thích thêm nghiệp vụ. Bạn chỉ cần đổ data vào sheet issue của template là báo cáo tự chạy.

Chương 5 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu Calendar Effort — chỉ số đo phần chi phí (nguồn lực) mà bạn thực sự allocate vào dự án, để so với Billable Effort (phần khách hàng trả tiền) mà biết dự án lời hay lỗ. Điểm mấu chốt: Calendar Effort tính bằng số ngày làm việc (NETWORKDAYS) nhân với tỷ lệ tham gia của mỗi người và hệ số hợp đồng, quy về đơn vị MM (man-month).

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt Billable Effort (khách hàng trả) và Calendar Effort (nguồn lực bạn bỏ vào).
• Dùng hàm NETWORKDAYS để tính số ngày làm việc có trừ ngày nghỉ.
• Quy đổi effort của mỗi người theo tỷ lệ tham gia và hệ số hợp đồng.

─── NỘI DUNG CHÍNH

▸ 1. Calendar Effort trong bức tranh quản lý dự án

Dự án được quản lý qua Time, Scope, Cost, Quality. Trong đó Cost là thứ phải control rất nhiều bên cạnh tiến độ. Billable Effort là số người-tháng khách hàng cam kết trả; còn Calendar Effort là effort thực tế từ những người bạn đưa vào dự án. So hai chỉ số này với nhau là biết dự án đang lời hay lỗ.

▸ 2. Công thức tính Calendar Effort

Với mỗi người tham gia, effort được tính từ:

1. NETWORKDAYS(start date, end date, ngày nghỉ) — số ngày làm việc thực, đã trừ các ngày nghỉ khai báo sẵn.
2. Nhân với tỷ lệ tham gia dự án của người đó (ví dụ default rate 50%).
3. Nhân với hệ số hợp đồng — nhân viên chính thức để hệ số 1, cộng tác viên để 0.5 (một số công ty quy định khác).

▸ 3. Vì sao dùng hệ số quy đổi

Ở vai trò Project Manager, bạn thường không biết chính xác mức lương từng nhân viên, nên thay vì tính chi phí ra tiền, người ta quy đổi bằng hệ số cho dễ và thống nhất. Cộng tổng effort các tháng lại sẽ ra tổng Calendar Effort của dự án (đơn vị MM). Đem so với tổng số Billable: nếu Calendar nhỏ hơn Billable thì có lợi, lớn hơn thì đang lỗ. Đây là nền tảng cho chỉ số Effort Efficiency ở bài kế tiếp.

Chương 5 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học chỉ cách tính Effort Efficiency (EE) — chỉ số cho biết bạn đang bỏ ra nhiều hay ít nguồn lực so với số khách hàng trả, từ đó biết dự án lời hay lỗ và khối lượng công việc có đúng dự kiến không. Điểm mấu chốt: EE = Billable / Calendar × 100%, và trong ngành outsourcing một mức EE khoảng 85% đã là con số đẹp.

─── SAU BÀI HỌC, BẠN SẼ

• Tính EE từng tháng và cả dự án bằng công thức Billable / Calendar.
• Đọc ý nghĩa của EE cao / thấp để phán đoán lời–lỗ và khối lượng công việc.
• Vẽ combo chart thể hiện tương quan Billable, Calendar và EE.

─── NỘI DUNG CHÍNH

▸ 1. Công thức EE

EE = Billable ÷ Calendar × 100%. Trong demo, tổng Billable là 19 MM còn Calendar là 22 MM → dự án đang lỗ 3 MM (22 − 19). Tính EE cho từng tháng bằng cách lấy Billable tháng đó chia Calendar tháng đó.

▸ 2. Ý nghĩa của chỉ số EE

• EE dưới 100%: bạn đưa vào dự án nhiều người hơn số khách hàng trả → đang lỗ. Cũng có thể do khối lượng công việc nhiều hơn dự kiến, underestimation (ước lượng sai) nên phải thêm người mới hoàn thành.
• EE trên 100%: bạn bỏ ra ít người hơn số khách hàng trả → có lợi.
• EE thấp còn có thể nghĩa là dự án ít việc thừa người, có thể rút bớt một người.

▸ Lưu ý: mức EE hợp lý trong outsourcing

Giữ EE 100% thường không kham nổi; mức bình thường nên nhắm khoảng 85% — tức lúc nào cũng thừa khoảng nửa đến một người để xử lý tình huống phát sinh. Đạt 100% hay hơn (như 150%) thì tuyệt vời nhưng rất khó.

▸ 3. Vẽ combo chart để nhìn tương quan

Select vùng dữ liệu → Insert → Chart, Sheets tự gợi ý combo chart. Đặt Billable và Calendar là cột trục trái (cùng đơn vị MM), còn EE là đường trục phải (đơn vị %). Bật data label để dễ đọc — nhìn chart này thấy tương quan lời–lỗ rõ hơn hẳn so với đọc số thô.

Chương 5 · Bài 6.1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là phần một của bài đo tiến độ dự án — một việc bắt buộc mỗi ngày với người quản lý dự án. Không nắm được tiến độ là cực kỳ nguy hiểm: đến lúc khách hàng nhìn output mới biết chưa xong thì dự án đã "cháy". Điểm mấu chốt: đo tiến độ theo EVM (Earned Value Management) — so giá trị kiếm được với chi phí bỏ ra — và biết phân biệt hai loại task trễ.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu tư duy EVM: khách hàng so % chi phí đã bỏ với % giá trị nhận được.
• Phân biệt trễ ngày bắt đầu và trễ ngày kết thúc của một task.
• Viết công thức IF / IFS để tự gắn nhãn task finish, trễ start, trễ end.

─── NỘI DUNG CHÍNH

▸ 1. Đo tiến độ theo giá trị (EVM)

Khách hàng quan tâm chi phí: bỏ ra bao nhiêu thì phải nhận được giá trị tương ứng. Ví dụ budget 100 ngàn USD cho 5 tháng → plan cost 20 ngàn/tháng, plan progress cộng dồn 20% → 40% → 60% → 80% → 100%. Đến tháng 3, nếu thực tế đã tiêu 6000 USD nhưng tiến độ mới 50% trong khi kế hoạch là 60% thì dự án đang trễ so với chi phí. Đó chính là tinh thần Earned Value Management — đo theo giá trị kiếm được, không chỉ theo tiền đã tiêu.

▸ 2. Hai loại task trễ

• Trễ ngày bắt đầu: đến ngày phải start task mà vẫn chưa bắt đầu (task còn new).
• Trễ ngày kết thúc: đến ngày phải kết thúc mà task vẫn chưa xong.

Muốn tính được, bảng dữ liệu cần các trường cơ bản bắt buộc: status, person in charge, plan start / end date, actual start / end date, estimation hour, spent time.

▸ 3. Viết công thức nhận diện độ trễ

Dùng IF (Excel) hoặc IFS (Google Sheets) so với ngày report:

1. Nếu status = close → finish (bỏ qua, không quan tâm).
2. Nếu khác close và plan end date < ngày report → trễ end.
3. Nếu khác close và plan start date ≤ ngày report → trễ start.

Copy công thức xuống là toàn bộ task tự gắn nhãn finish / trễ start / trễ end. Phần hai sẽ tính phần trăm task trễ và task sớm.

Chương 5 · Bài 6.2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Phần hai nối tiếp bài đo tiến độ: cách tính phần trăm task trễ / task sớm, và dùng Gantt chart cùng burndown chart để nhìn tiến độ toàn dự án. Điểm mấu chốt: số giờ còn lại của một task tính từ Estimate × (1 − % done), nhưng con số này chỉ mang tính tương đối — phải hỏi lại người làm mới ước lượng đúng.

─── SAU BÀI HỌC, BẠN SẼ

• Tính số giờ còn lại và mức trễ/sớm của task dựa trên % done.
• Đọc burndown chart theo hai chiều: số lượng task và số lượng effort.
• Đọc Gantt chart để biết từng task đang sớm hay trễ so với ngày báo cáo.

─── NỘI DUNG CHÍNH

▸ 1. Tính phần trăm task trễ và task sớm

Số giờ còn lại của một task = Estimate hour × (1 − % complete). Vì vậy nên thêm cột % done để người làm (doer) tự nhập. Ví dụ task estimate 7 tiếng, đã spent 7 tiếng nhưng mới 50% → cần thêm khoảng 7 tiếng nữa mới xong. Với task start sớm (bắt đầu trước plan, đang in progress), bạn tính ngược lại phần đã đi trước để biết đang sớm bao nhiêu phần trăm / bao nhiêu tiếng. Chỉ cần một công thức IF là gắn được nhãn sớm/trễ và ra số giờ theo giả định.

▸ Lưu ý: con số trễ chỉ là tương đối

Tính chính xác số giờ còn lại của một task thật sự rất khó — spent đủ giờ không có nghĩa là xong. Bạn phải xác nhận lại % hoàn thành với developer/doer rồi họ estimate lại, con số mới đáng tin. Công thức chỉ cho ước lượng tương đối, mỗi công ty/dự án có thể dùng giả định khác.

▸ 2. Burndown chart và Gantt chart

Tính tiến độ tổng: ví dụ 8 task xong 4 → 50% (một số dự án đo theo story point hoặc estimate hour). Sau đó nhìn chart:

• Burndown chart: thấy tổng thể theo hai chiều — số lượng task còn lại và số lượng effort còn thiếu so với đường kế hoạch.
• Gantt chart: thấy chi tiết từng task, so vị trí % done với ngày báo cáo để biết task đang sớm hay trễ.

▸ 3. Tracking và xử lý khi trễ

Mỗi ngày tracking theo chart và số liệu đổ về. Dự án ok thì keep theo plan; trễ nhiều thì phải có phương án recover độ trễ, đôi lúc phải replan cả kế hoạch. Nhìn chart, phán đoán và xử lý sớm chỗ có vấn đề mới là quản lý dự án tốt.

Chương 6 · Bài 0

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Mở đầu chương báo cáo dự án cho khách hàng, bài học giới thiệu kỹ thuật báo cáo của người Nhật — HORENSO. Toàn bộ thành quả dự án đều thể hiện qua cách bạn báo cáo, nên báo cáo chuyên nghiệp là kỹ năng quan trọng của Project Manager. Điểm mấu chốt: HORENSO ghép từ ba chữ Houkoku – Renraku – Soudan, tương ứng báo cáo, liên lạc và bàn bạc.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu tầm quan trọng của báo cáo trong suốt quá trình làm dự án.
• Nhớ được ba thành phần của HORENSO và ý nghĩa từng chữ.
• Biết cách truy cập slide HORENSO (qua link hoặc QR code) để học chi tiết.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao báo cáo lại quan trọng

Chương này nói riêng về báo cáo. Mọi thành quả của dự án chỉ được khách hàng nhìn thấy thông qua cách bạn báo cáo, nên phải báo cáo cho chuyên nghiệp. Để làm tốt, trước hết cần nắm kỹ thuật báo cáo của người Nhật — HORENSO.

▸ 2. HORENSO gồm những gì

HORENSO ghép từ ba chữ:

• HO – Houkoku: báo cáo.
• REN – Renraku: liên lạc.
• SO – Soudan: thảo luận, bàn bạc.

Đây là bài giới thiệu; nội dung chi tiết nằm trong slide HORENSO mà bạn truy cập qua đường link hoặc QR code đi kèm. Video kế tiếp sẽ đi sâu vào từng phần của slide này.

Chương 6 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học đi sâu vào kỹ thuật báo cáo HORENSO của người Nhật, nối tiếp bài giới thiệu ở phần trước. Nếu bài trước chỉ nêu tên ba thành phần, thì phần này trình bày chi tiết ý nghĩa và khi nào áp dụng từng loại. Nội dung được giảng theo slide HORENSO — bạn truy cập qua đường link hoặc quét QR code đi kèm để mở slide bài học.

─── NỘI DUNG CHÍNH

▸ 1. Ba thành phần của HORENSO

• Houkoku (báo cáo): chủ động cập nhật tình hình, tiến độ và kết quả công việc lên cấp trên hoặc khách hàng.
• Renraku (liên lạc): chia sẻ, thông báo thông tin cần thiết cho các bên liên quan để mọi người cùng nắm.
• Soudan (bàn bạc, tham vấn): hỏi ý kiến, thảo luận khi gặp vấn đề hoặc trước khi ra quyết định quan trọng.

▸ 2. Học chi tiết qua slide

Phần đi sâu này được trình bày trong slide HORENSO. Bạn mở slide qua đường link hoặc QR code trong bài để xem đầy đủ nội dung và ví dụ mà giảng viên chuẩn bị, từ đó hiểu khi nào nên dùng báo cáo, khi nào liên lạc và khi nào cần bàn bạc trong quá trình làm dự án.

Chương 6 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu template báo cáo tuần (weekly report) mà giảng viên hay dùng khi làm dự án với khách hàng. Mỗi tuần bạn thường có một buổi weekly report khoảng nửa tiếng đến một, hai tiếng, xoay quanh đúng bốn yếu tố của "tam giác dự án": time (tiến độ), cost, quality, scope. Điểm mấu chốt: template chỉ là công cụ — bạn có thể customize thoải mái, miễn báo cáo đủ bốn yếu tố và trình bày trực quan để khách hàng nhìn vào là hiểu ngay.

─── SAU BÀI HỌC, BẠN SẼ

• Biết một buổi weekly report cần xoay quanh những yếu tố nào (time, cost, quality, scope).
• Đọc được cấu trúc một template báo cáo tiến độ: sheet overview, detail, graph (burndown chart).
• Hiểu vì sao phải điều chỉnh cách báo cáo theo đối tượng người nghe.

─── NỘI DUNG CHÍNH

▸ 1. Báo cáo xoay quanh bốn yếu tố

Khi báo cáo tuần, khách hàng quan tâm tiến độ (time) nhiều nhất. Nhưng một báo cáo đầy đủ nên đủ bốn phần: time, cost, quality, scope. Về cost, nhiều dự án đã fix giá từ đầu nên khách không hỏi thêm — chỉ khi có change request báo giá thêm mới phát sinh cost, và thường phần tiền do cấp cao hơn PM nắm. Về quality, template mẫu này có thể còn để trống nếu chưa cần đo.

▸ 2. Cấu trúc template báo cáo tiến độ

Mở folder template, chọn mẫu project charter detail. Bạn fill vào tên task, tên file, người thực hiện, độ ưu tiên, estimate (giờ), ngày bắt đầu / kết thúc, status. Từ dữ liệu đó template sinh ra các sheet: overview (tổng thể dự án), detail (chi tiết từng tab, dùng công thức VLOOKUP để tra keyword), và graph — chính là burndown chart. Câu tổng thể kiểu "tiến độ đang sớm hơn 3 ngày" nằm ngay ở overview, kèm so sánh plan với actual cho từng release.

▸ 3. Chọn đối tượng và công cụ báo cáo

Như đã học ở HORENSO, cách báo cáo phụ thuộc đối tượng: khách hàng biết kỹ thuật hay không sẽ cần cách trình bày khác nhau. Template chỉ là một lựa chọn — bạn hoàn toàn có thể báo cáo bằng Redmine, Jira, PowerPoint, file readme/txt… Miễn nội dung đủ mục để khách hàng tham khảo và hiểu được là đạt.

Chương 6 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học chia sẻ kỹ thuật báo cáo trong năm tình huống thường gặp: dự án đúng tiến độ, trễ tiến độ, sớm tiến độ, có vấn đề kỹ thuật, và không thực hiện được vì khách hàng chưa cung cấp tài liệu. Điểm mấu chốt: mọi báo cáo đều dựa trên khung HORENSO — tin càng xấu càng phải báo sớm, và luôn liên lạc, thảo luận (Soudan) hai chiều với khách hàng.

─── SAU BÀI HỌC, BẠN SẼ

• Viết được câu báo cáo cho từng tình huống tiến độ (đúng / trễ / sớm / lỗi kỹ thuật / thiếu tài liệu).
• Trình bày một báo cáo trễ theo mạch: phát sinh → lý do → khắc phục → người hỗ trợ → dự kiến recover.
• Cân bằng thời gian: báo cáo gọn để dành phần lớn effort cho việc đồng hành cùng team.

─── NỘI DUNG CHÍNH

▸ 1. Đúng tiến độ và sớm tiến độ

Dự án đúng tiến độ: chỉ cần ghi "tổng thể dự án đúng tiến độ, không phát sinh chậm trễ", kèm ngày dự kiến gửi sản phẩm cho khách test. Dự án sớm tiến độ: không dùng từ "khắc phục"; nêu sẽ tận dụng thời gian dư để release sớm hoặc chạy thêm test (monkey test, stress test…). Lưu ý quan điểm giảng viên: đừng báo sớm quá — vừa để team có thời gian nghỉ, vừa tránh việc khách nghĩ bạn estimate lệch. Có thể tách schedule internal và external để linh hoạt.

▸ 2. Trễ tiến độ và vấn đề kỹ thuật

Báo cáo trễ theo mạch chuẩn: phát sinh gì → lý do (nhớ ghi "hơn plan ban đầu" để hợp lý) → khắc phục ra sao (nhờ ai support) → dự kiến ngày recover đúng kế hoạch. Với khách khó tính, thêm bước next action / prevent để phòng chặn lần sau — điều khách hàng Nhật rất thích nghe. Với vấn đề kỹ thuật, phần khắc phục nên là thảo luận với khách và nhờ đội technical / solution cấp công ty join hỗ trợ (chú ý ký bảo mật thông tin nếu dự án yêu cầu).

▸ 3. Thiếu tài liệu và điều khách hàng thật sự cần

Khi khách chưa gửi tài liệu, ghi thẳng: tổng thể đang trễ, nhờ khách gửi trước ngày X nếu không sẽ trễ schedule. Thực tế khách hàng ít quan tâm chi tiết gap sớm/trễ, mà quan tâm khi nào giao được sản phẩm để test. Vì vậy nên có thêm một sheet theo function với plan/actual cho coding finish, testing, delivery. Cuối cùng: dành khoảng 20% effort cho báo cáo, 80% cho team.

Chương 6 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn tạo và đọc burndown chart để theo dõi tiến độ dự án. Chart có hai đường: Plan (màu xanh) là tốc độ cần burn xuống mỗi ngày, và Actual (màu đỏ) là tốc độ thực tế. Điểm mấu chốt: biết tạo chart chưa đủ — quan trọng là nhìn được vấn đề từ khoảng cách giữa hai đường và nhảy vào xử lý ngay theo ngày, chứ không để dự án tự chạy.

─── SAU BÀI HỌC, BẠN SẼ

• Tạo burndown chart từ template có sẵn (bản Redmine report hoặc bản Excel).
• Đọc được ý nghĩa của hai đường Plan / Actual và các dấu hiệu cảnh báo.
• Chọn đơn vị đo phù hợp: theo task, theo effort, hay theo story point.

─── NỘI DUNG CHÍNH

▸ 1. Tạo burndown chart từ template

Giảng viên có sẵn một clip YouTube và template hướng dẫn chi tiết, kèm data sample chạy ra chart ngay. Template tồn tại ở cả bản Redmine report lẫn bản Excel, cách làm giống hệt nhau — bạn dùng file nào cũng được. Chỉ cần copy link/template về là có burndown chart để dùng.

▸ 2. Đọc hai đường Plan và Actual

Đường Actual thường nằm trên Plan. Khi Actual tiến sát rồi xuống dưới Plan nghĩa là team đang recover tốt, chạy trước kế hoạch. Ngược lại, nếu Actual cứ nằm cao hơn Plan một khoảng cách cố định và không có xu hướng giảm, đó là dấu hiệu team không đủ khả năng recover — bạn phải nhảy xuống xem ai đang burn không tốt, phần nào đang gặp khó. Nếu đường văng lên liên tục (trễ ngày càng lớn), cần action mạnh: đổ thêm người, overtime, hoặc reschedule lại lịch trình.

▸ 3. Chọn đơn vị đo và theo dõi hằng ngày

Chart đo theo cái gì thì thể hiện cái đó. Đo theo số task cho thấy số lượng nhưng không phản ánh trọng lượng (có task 1–2 giờ, có task 15–20 giờ), nên nên đo thêm burndown chart theo effort. Với mô hình Scrum, dùng thêm đơn vị story point. Quan trọng nhất: làm PM phải theo dõi hằng ngày — daily report, daily monitor, daily tracking — chứ không đợi vài tầng mới coi. Ngoài burndown chart, có thể kết hợp thêm Gantt chart để tracking tiến độ.

Chương 6 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn làm và gởi Meeting Minutes — văn bản cuộc họp — sau mỗi buổi họp với khách hàng. Sau khi họp xong, bạn ghi nhận lại nội dung, gởi email cho khách hàng để xác nhận, và đưa những việc cần theo dõi lên hệ thống quản lý dự án thành ticket. Điểm mấu chốt: cứ họp xong là phải có văn bản cuộc họp, và gởi càng sớm càng tốt.

─── SAU BÀI HỌC, BẠN SẼ

• Điền được một template Meeting Minutes với đủ các trường thông tin cần thiết.
• Biết quy trình sau họp: fill minutes → gởi email xác nhận → đưa việc lên hệ thống thành ticket.
• Hiểu vì sao nên gởi Meeting Minutes ngay sau cuộc họp.

─── NỘI DUNG CHÍNH

▸ 1. Template Meeting Minutes gồm những gì

Trong folder template có sẵn mẫu Meeting Minutes, gồm nhiều loại buổi họp: general, kick-off, milestone, call / analytics report, weekly. Mỗi minutes bạn fill vào các trường: cuộc họp với ai, mã dự án, nội dung thảo luận, kết luận, người thực hiện, và trạng thái (chưa làm / đang làm / đã làm). Ví dụ một dòng có thể là: họp phê duyệt dự án, kết luận ra sao, ai chịu trách nhiệm.

▸ 2. Quy trình sau khi họp

Sau khi fill xong minutes, bạn gởi email cho khách hàng để họ nắm được các kết luận của buổi họp và xác nhận lại. Đồng thời, với những việc cần theo dõi, bạn đưa lên hệ thống quản lý dự án, lập thành ticket và tracking từ đó. Nhờ vậy mọi cam kết trong cuộc họp đều được ghi nhận và không bị bỏ sót.

▸ 3. Gởi càng sớm càng tốt

Đẹp nhất là gởi liền sau cuộc họp. Một số trường hợp do rào cản ngôn ngữ (ví dụ khách nói tiếng Nhật, bạn cần dịch) không thể gởi ngay thì có thể gởi qua ngày hôm sau — vẫn chấp nhận được nhưng hơi chậm. Theo thói quen của giảng viên, gởi liền là hợp lý nhất để giữ thông tin nóng và tránh quên nội dung đã thống nhất.

Chương 6 · Bài 6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn làm slide kick-off — slide khởi động dự án — bằng cách tổng hợp thông tin từ project plan thành một bản trình bày sơ bộ cho buổi khởi động. Mục tiêu: tổng kết thông tin ban đầu xem đã đủ chưa, nhờ khách hàng hỗ trợ những gì, và đưa ra ground rule với team. Điểm mấu chốt: buổi kick-off cần có mặt khách hàng, các stakeholder liên quan và nhất là team member của bạn.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm được các đề mục cần có trong một slide kick-off dự án.
• Biết tổng hợp thông tin từ project plan vào slide để trình bày với khách và team.
• Hiểu vai trò của buổi kick-off và những ai cần tham gia.

─── NỘI DUNG CHÍNH

▸ 1. Các đề mục trong slide kick-off

Slide đi từ overview dự án (và overview khách hàng), sau đó tới deliverables, project charter, org chart, cách quản lý dự án, communication tool, và kế hoạch phát triển. Tất cả được tóm tắt gọn cho dự án của bạn. Template có thể là file Excel, Google Docs hay Word — nội dung vẫn như nhau.

▸ 2. Chi tiết từng phần

Overview: loại dự án, quy mô bao nhiêu người, giai đoạn phát triển ở đâu, scope (ví dụ coding, unit test, integration test) và môi trường phát triển (PHP, Laravel…). Deliverables: bạn nhận thông tin gì và giao lại cho khách cái gì. Project charter: các mốc milestone, phần cần làm, phần delivery — thường đã được quy định trong bảng estimation / báo giá ban đầu hoặc chốt trong quá trình thảo luận. Org chart: ai quản lý dự án, ai support, ai chat với khách, ai nằm/không nằm trong hợp đồng.

▸ 3. Quản lý, communication và kế hoạch

Nêu rõ cách quản lý dự án dùng hệ thống nào, weekly report gửi qua tool nào, quản lý task/bug/Q&A ra sao. Phần communication model liệt kê tool dùng (ví dụ Slack để liên lạc, Redmine để quản lý task). Phần kế hoạch / chiến lược nêu ngày start, quy định dự án, và bám đủ bốn yếu tố scope, time, cost, quality. Nếu có quality plan thì có thể đưa luôn vào file kick-off. Tất cả tùy tính chất và nhu cầu của dự án cũng như khách hàng.

Chương 6 · Bài 7

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn làm slide tổng kết (Closing) để đóng dự án và tổ chức buổi post-mortem. Khác với slide kick-off chỉ nêu thông tin tổng quan ban đầu, slide closing tập trung vào tổng kết plan vs actual trên toàn dự án, các bài học kinh nghiệm, và phần hỏi đáp. Điểm mấu chốt: dùng phương pháp KPT (Keep – Problem – Try) để cả team cùng nhìn lại và rút kinh nghiệm cho dự án sau.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm cấu trúc một slide closing: overview + plan/actual, lesson learned, question.
• So sánh được target (plan) với thực tế (actual) về charter, chất lượng, org chart.
• Tổ chức buổi post-mortem theo phương pháp KPT một cách tôn trọng ý kiến team.

─── NỘI DUNG CHÍNH

▸ 1. Cấu trúc slide closing

Slide gồm ba phần chính: overview (nhắc lại scope, công nghệ, charter — nhưng lần này kèm plan/actual để có bức tranh tổng quan toàn dự án), lesson learned and practice (bài học và kinh nghiệm đạt được), và question để sau. Charter tổng kết cho thấy plan/actual của các release, org chart trước và sau, cùng phần communication của dự án.

▸ 2. So sánh target với thực tế

Ở phần chất lượng, bạn compare plan với actual. Ví dụ target đặt ra là 90 test case cho một KLOC, nhưng thực tế mật độ chỉ đạt 38 test case cho một KLOC — con số này giúp thấy rõ chất lượng sản phẩm và vấn đề của dự án khi tổng kết lại. Org chart cũng được so plan với thực tế để nhìn ra điểm tốt và chưa tốt trong quá trình vận hành.

▸ 3. Post-mortem với phương pháp KPT

KPT là Keep (những điều tốt cần giữ), Problem (vấn đề gặp phải cần cải thiện), Try (kế hoạch cải thiện sắp tới). Bạn phát cho từng team member ghi, rồi tổ chức họp để mọi người trình bày kinh nghiệm — nên giới hạn thời gian mỗi người (ví dụ 10 phút) cho vừa timeline. Nguyên tắc quan trọng: tôn trọng ý kiến, không ngắt lời, để mọi người nói hết rồi PM mới tổng kết và đưa hướng giải quyết, hướng Try cho dự án tới. Nên mời cả stakeholder liên quan tham gia để giúp rút kinh nghiệm cho dự án sau.

Chương 7 · Bài 0

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học mở đầu chương 7, giới thiệu cách đánh giá chất lượng dự án thông qua bộ Quality Metrics — các chỉ số chất lượng. Đây là bước cuối cùng, tổng hợp tất cả dữ liệu đầu vào đã học ở các bài trước (LOC, test case, bug, calendar effort, effort efficiency…) để kết luận dự án đạt hay không đạt chuẩn. Điểm mấu chốt cần nhớ: một function đạt chuẩn khi các chỉ số của nó nằm trong số norm, và không đạt khi nằm ngoài.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu Quality Metrics là gì và vai trò của nó ở bước tổng kết chất lượng.
• Biết cách phân định đạt chuẩn / không đạt chuẩn dựa trên số norm.
• Nắm được các chỉ số nguồn (LOC, unit test case, UT bug…) sẽ dùng để đo.

─── NỘI DUNG CHÍNH

▸ 1. Quality Metrics và số norm

Tiêu chuẩn chất lượng của dự án được định nghĩa bằng một bộ metrics (bài học nhắc tới khoảng 10 metrics), nằm trong thư mục template. Mỗi metric có chỉ số trung bình, cận trên và cận dưới — đây chính là số norm. Khi một function được code xong, nếu các chỉ số của nó rơi vào khoảng norm thì đạt chuẩn, còn rơi ra ngoài thì không đạt chuẩn.

▸ 2. Các chỉ số nguồn đã chuẩn bị

Tùy tính chất dự án, bạn đo được những chỉ số như: KLOC (1000 line of code), unit test case, UT bug… Các bài trước đã cung cấp công cụ đo LOC, đếm test case, và cách xuất bug ra từ hệ thống quản lý. Khi tổng hợp lại, bạn đã có đủ số liệu cần thiết để làm bước đánh giá.

▸ 3. Lời khuyên khi tiếp cận chương này

Giảng viên lưu ý đây là phần khá khó nhìn nhận, nên khi làm bạn cần kiên nhẫn hiểu dần và điều chỉnh trong quá trình thực hành. Cả chương 7 sẽ đi vào việc tổng kết báo cáo và vẽ biểu đồ để ra được báo cáo chất lượng hoàn chỉnh; các clip sau sẽ đi chi tiết từng phần.

Chương 7 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn dựng báo cáo chất lượng dự án bằng Excel, dựa trên số norm đã học. Với mỗi function, bạn tính ra bộ chỉ số kế hoạch (plan) từ số norm, rồi collect data thực tế (actual) khi code và test xong, cuối cùng so plan với actual để đánh giá. Điểm mấu chốt: từ số norm bạn suy ngược ra số bug và test case dự kiến, rồi đối chiếu với thực tế để biết chất lượng đang nằm ở đâu.

─── SAU BÀI HỌC, BẠN SẼ

• Tính được chỉ số plan cho từng function từ số norm (LOC, test case, bug).
• Collect và điền số liệu actual từ hệ thống quản lý vào bảng Excel.
• Đọc được bảng đánh giá dựa trên hai tiêu chí test case và defect.

─── NỘI DUNG CHÍNH

▸ 1. Tính chỉ số plan từ số norm

Điền function ID cho từng màn hình, rồi đo line of code bằng công cụ. Ví dụ 0.363 nghĩa là nhân 1000 ra 363 LOC, chia 1000 thành đơn vị KLOC. Từ số norm của công ty (ví dụ 1000 LOC tương ứng một số bug chuẩn, hay 90 test case trên 1 KLOC), bạn suy ngược ra số bug dự kiến, số unit test case và integration test case cần có cho function đó. Cột này là plan — kế hoạch theo phương pháp estimation theo LOC mà khách hàng Nhật hay dùng.

▸ 2. Collect data thực tế (actual)

Khi code và test xong, bạn đo lại thực tế: ví dụ function estimate 363 LOC nhưng thực tế ra 450 LOC. Từ đó tính mật độ bug, số test case và bug thực tế, phần lớn điền tay từ hệ thống quản lý. Lưu ý: test case và bug của integration test thường là số tổng, khó tách theo từng màn hình nên đừng cố phân nhỏ. Bug do khách hàng bắt thì có thể bắt theo đơn vị màn hình.

▸ 3. Bảng đánh giá theo test case và defect

Sang một sheet khác, bạn filter và so plan với actual, tính % chênh lệch (ví dụ LOC lệch 25%) và giải thích lý do. Bảng đánh giá dựa trên kinh nghiệm cộng số liệu công ty, xét theo hai tiêu chí: test case (T) và defect / bug (D). Mỗi tiêu chí được phân mức thấp hơn norm, nằm trong norm, hoặc cao hơn norm (T1/T2/T3 và D1/D2/D3). Tổ hợp hai trục T và D cho ra một ma trận các vùng đánh giá; nhìn function rơi vào vùng nào để biết cần action gì (ví dụ test case dư thừa cần review lại nội dung, hay số test case quá ít cần tăng thêm và bắt thêm bug). Đây là phần khó — nếu chưa rõ, hãy hỏi lại trong group.

Chương 7 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học chuyển báo cáo chất lượng từ Excel sang Google Sheet (Spreadsheet). Về bản chất mọi thứ giống hệt bài trước: cùng template, cùng công thức, cùng cách đánh giá test case và defect — chỉ khác nhau ở nguồn refer data và công cụ. Điểm mấu chốt: chuyển file qua Google Sheet không hề phức tạp, công thức được giữ nguyên, bạn chỉ cần đổ data vào là chạy.

─── SAU BÀI HỌC, BẠN SẼ

• Chuyển được báo cáo chất lượng từ Excel sang Google Sheet mà giữ nguyên công thức.
• Biết lấy nguồn data test case từ các file trên Google Sheet để đổ vào báo cáo.
• Hiểu rằng logic đánh giá (vùng test case, vùng defect) không thay đổi giữa hai công cụ.

─── NỘI DUNG CHÍNH

▸ 1. Chuyển template sang Google Sheet

Bạn chỉ cần đem file Excel bên kia chuyển vào là ra file Google Sheet, công thức cũng được chuyển qua không vấn đề gì. Dùng chính template đã bỏ sẵn trong thư mục folder của khóa học, rồi bỏ data vào — form thông tin hiện ra y chang như bản Excel.

▸ 2. Khác biệt duy nhất: nguồn data

Điểm khác nhau nằm ở nguồn refer data. Thay vì đo test case bằng file Excel, ở đây bạn lấy các file test case liên quan tới Google Sheet, cộng số test case lại theo từng màn hình rồi điền vào. Phần tính mật độ trung bình và tính từng phần được đem qua tương tự, và sheet đánh giá chất lượng vẫn xét test case rơi vào vùng nào, defect rơi vào vùng nào — hoàn toàn giống bản Excel.

▸ 3. Lưu ý về phần vẽ chart

Về cơ bản làm báo cáo chất lượng trên Google Sheet không có gì phức tạp — bỏ data lên là nó chạy. Tuy nhiên, giảng viên lưu ý phần vẽ chart trên Google Sheet khó và khác so với Excel khá nhiều; phần này sẽ được hướng dẫn riêng từng bước ở các bài sau.

Chương 7 · Bài 3.1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn vẽ chart trong Excel để trực quan hóa báo cáo chất lượng đã dựng ở các bài trước. Bạn chỉ cần vài chart cơ bản (column chart, chart mật độ bug, đường xu hướng) là đủ để trình bày. Điểm mấu chốt: chart giúp bạn phát hiện điểm bất thường — như một function có số LOC tăng đột biến, hoặc mật độ bug thấp bất thường cần xem lại chất lượng review.

─── SAU BÀI HỌC, BẠN SẼ

• Chèn được chart cơ bản từ vùng data (Insert → Recommended chart / Column chart).
• Đọc chart để phát hiện function bất thường về LOC và mật độ bug.
• Thêm trendline và dùng Linked Picture để đưa số liệu tổng vào báo cáo.

─── NỘI DUNG CHÍNH

▸ 1. Vẽ chart cơ bản

Kéo chọn vùng data muốn vẽ, nhấn Insert rồi chọn Recommended chart hoặc một loại chart cụ thể như Column chart và nhấn OK. Ví dụ chart về LOC cho thấy phần lớn function đúng như plan, nhưng có vài function (số 12, số 10, 14…) có số LOC cao bất thường so với phần còn lại — đây là điểm cần chú ý.

▸ 2. Chart mật độ bug và ý nghĩa

Copy chart cũ, paste ra chart mới rồi move data sang cột bug trên LOC để có chart mật độ bug. Nhìn tương quan: theo kế hoạch mật độ bug đều nhau, nhưng có function mật độ cao hơn, có function (ví dụ số 4) rất thấp dù số LOC cao — review chỉ ra dưới một bug. Mật độ bug quá thấp là dấu hiệu cần review lại, vì sao lại ít bug bất thường như vậy. Bạn làm tương tự cho các đơn vị khác như UT trên LOC.

▸ 3. Trendline và Linked Picture

Có thể thêm đường xu hướng: nhấp phải chart → Add trendline (ví dụ Linear) để thấy xu hướng đang tăng. Muốn đưa số tổng vào báo cáo, dùng SUM cộng toàn bộ actual (ví dụ tổng LOC ~16 ngàn), highlight rồi nhấp phải chọn Paste Special → Linked Picture để nhúng ảnh liên kết cập nhật được. Cuối cùng, bỏ chart vào PowerPoint, thêm nhận định phía trên là có một báo cáo chất lượng rõ ràng để trình bày. Excel vẽ chart khá dễ; phần vẽ chart trên Google Sheet sẽ hướng dẫn ở video sau.

Chương 7 · Bài 3.2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn vẽ chart cho báo cáo chất lượng ngay trên Google Sheets, thay vì Excel như bài trước. Điểm mấu chốt đáng nhớ: thao tác về bản chất giống Excel, chỉ khác một chút ở cách cấu hình vùng dữ liệu; và mẹo nhanh nhất để vẽ nhiều chart giống nhau là copy một chart mẫu rồi chỉ sửa lại vùng dữ liệu, nhờ vậy giữ nguyên format mà không phải làm lại từ đầu.

─── SAU BÀI HỌC, BẠN SẼ

• Chèn được Column Chart trên Google Sheets từ vùng dữ liệu đã chọn.
• Cấu hình header và label đúng cách (use row 7 as headers, dùng cột B làm label).
• Nhân bản chart bằng cách copy và chỉnh lại range để vẽ nhanh nhiều biểu đồ.

─── NỘI DUNG CHÍNH

▸ 1. Vẽ chart đầu tiên

Chọn (bôi đen) vùng dữ liệu cần vẽ, vào Insert → Chart. Sheets bung ra một chart mặc định. Ở phần Chart type, chọn Column Chart. Tiếp đó bật Use row 7 as headers để dòng 7 làm tiêu đề, rồi bật Data Label để hiện số liệu ngay trên cột. Chỉ với vài thao tác là chart hiện ra đầy đủ.

▸ 2. Nhân bản chart bằng copy

Cách làm nhanh của giảng viên: copy chart đã có ra một chart mới — thao tác này giữ nguyên format. Sau đó nhấn Edit để đổi vùng dữ liệu. Ví dụ muốn vẽ chart từ cột G và cột H: giữ header là cột B (B7 đến B22), nhấn Add another range, thêm dải G7 đến H22, nhấn OK. Chọn hai series Plan và Actual (chính là cột G và H), dùng row 7 làm header và cột B làm label. Kéo xuống là chart mới hiện ra — ví dụ biểu đồ bug trên LOC.

▸ 3. Đổi loại chart

Muốn nhìn dữ liệu theo góc khác, click vào chart và đổi Chart type sang loại khác, ví dụ Line Chart. Cùng một dữ liệu nhưng cách nhìn thay đổi hẳn, giúp bạn linh hoạt chọn biểu đồ phù hợp cho từng báo cáo.

▸ Lưu ý khi làm trên Google Sheets

Cấu hình vùng dữ liệu trên Google Sheets hơi khác Excel (phải Add another range thủ công cho từng dải), nhưng không khó. Nắm được cách copy chart mẫu rồi sửa range là bạn dựng được cả bộ báo cáo chất lượng rất nhanh.

Chương 7 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn cách đọc và diễn giải các chỉ số chất lượng đã thống kê, để từ những con số khô khan rút ra được bức tranh thật về dự án. Điểm mấu chốt đáng nhớ: phân tích chất lượng phải đi theo một quy trình có thứ tự — đặt câu hỏi, lấy dữ liệu, xử lý, phân tích rồi mới đánh giá — và luôn so sánh dữ liệu với tiêu chuẩn chất lượng của công ty chứ không nhìn số một cách rời rạc.

─── SAU BÀI HỌC, BẠN SẼ

• Biết các câu hỏi cần đặt ra trước khi phân tích chất lượng một dự án.
• Đọc được ý nghĩa của các chỉ số (chi phí, effort, loại bug, severity) khi đặt cạnh tiêu chuẩn.
• So sánh bug nội bộ (UT) và bug khách hàng (UAT) để suy ra vấn đề gốc của dự án.

─── NỘI DUNG CHÍNH

▸ 1. Đặt câu hỏi và đi theo quy trình

Trước khi nhìn số, hãy đặt câu hỏi: chất lượng dự án hiện tại có vấn đề không? Quy trình có được thực hiện đúng không? Cần action gì để nâng chất lượng? Kế hoạch sắp tới ra sao? Sau đó đi theo các bước: lấy dữ liệu → xử lý → phân tích → đánh giá. Khi phân tích, đối chiếu dự án với quy trình chuẩn của công ty (đủ các phase chưa), xem Gantt chart để biết plan và thực tế lệch nhau chỗ nào.

▸ 2. Đọc chỉ số chi phí và effort

So số effort thực tế với bill khách hàng trả và với estimate theo khối lượng (LOC) hiện tại. Nếu công ty đã bỏ ra nhiều hơn phần khách hàng trả, đó là dấu hiệu dự án đang lỗ và underestimation — cần cân nhắc bổ sung resource. Cách đọc là luôn đặt con số bên cạnh chuẩn năng suất để biết "đủ hay thiếu".

▸ 3. So sánh bug nội bộ và bug khách hàng

Đặt cạnh nhau bug đội mình bắt (UT) và bug khách hàng bắt (UAT) theo loại bug và severity. Nếu bug layout mình bắt hết nhưng bug logic vẫn lọt sang khách hàng, chứng tỏ phần nghiệp vụ khó, đội chưa hiểu requirement. Nếu khách hàng bắt chủ yếu major trong khi mình bắt chủ yếu minor, nghĩa là khách hàng đang gặp lỗi nghiêm trọng hơn — dấu hiệu họ không hài lòng.

▸ Lưu ý khi diễn giải cho khách hàng

Khách hàng không đọc nổi một chart lớn đầy số liệu. Khi trình bày, hãy tóm gọn theo từng giai đoạn: giai đoạn này gặp vấn đề gì, kèm nhận xét ngắn — thay vì bê nguyên bảng phân tích chi tiết.

Chương 7 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Sau khi đã phân tích và tìm ra vấn đề (bài trước), bài này hướng dẫn biến kết quả phân tích thành hành động cải thiện (action) cụ thể. Điểm mấu chốt đáng nhớ: chất lượng phải được phòng cháy hơn chữa cháy — theo dõi theo chuẩn hằng ngày và warning ngay khi lệch chuẩn, thay vì đợi cuối dự án mới làm báo cáo lớn rồi mới xử lý, lúc đó thường đã muộn.

─── SAU BÀI HỌC, BẠN SẼ

• Đề xuất được action cải thiện gắn với từng vấn đề tìm ra khi phân tích.
• Biết cách điều chỉnh cơ cấu team (thêm BA, giảm dev thuần) khi bug nghiệp vụ nhiều.
• Hiểu tư duy theo dõi chất lượng liên tục để cảnh báo sớm thay vì xử lý muộn.

─── NỘI DUNG CHÍNH

▸ 1. Từ vấn đề ra action

Mỗi vấn đề phát hiện được phải kèm một hành động. Ví dụ: PM đánh giá chưa chính xác → hỗ trợ thêm người quản lý; nguồn lực chưa đủ chất lượng → rà soát và thay thế; chi phí khách hàng trả thấp hơn thực tế → đề nghị tăng bill; nghiệp vụ khó team không hiểu → nhờ khách hàng giải thích và test thêm; và luôn report với stakeholder để thông tin xuyên suốt.

▸ 2. Điều chỉnh cơ cấu team theo loại bug

Khi khách hàng bắt nhiều bug major về nghiệp vụ, nghĩa là phần nghiệp vụ đang bất ổn. Thay vì lót toàn dev (chỉ lo làm ra sản phẩm, không đảm bảo chất lượng), hãy giảm bớt dev và thêm BA vào để củng cố nghiệp vụ. Song song, training cho đội hiểu nghiệp vụ và communicate với khách hàng nhiều hơn để họ transfer nghiệp vụ rõ ràng.

▸ 3. Deliver theo increment

Thay vì gom hết rồi mới giao một cục, hãy deliver theo increment — xong phần nào giao phần đó (ví dụ gom khoảng 3 function một lần) và nhờ khách hàng confirm, test ngay. Cách này giúp khách hàng thấy output sớm, phản hồi kịp thời và hài lòng hơn.

▸ Lưu ý quan trọng: phòng cháy hơn chữa cháy

Đừng đợi cuối dự án mới làm bảng phân tích lớn — như vậy đã muộn. Ngay từ đầu hãy define một chuẩn chất lượng, thống kê hằng ngày, tracking liên tục; hễ chỉ số không đạt chuẩn thì warning và action ngay. Khi cần nhìn tổng thể, có thể dùng biểu đồ xương cá hoặc gom các điểm tương đồng, vẽ chart rồi ra action phù hợp.

Chương 8 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là bài mở đầu chương tổng kết. Giảng viên điểm lại toàn bộ công cụ đã dùng xuyên suốt khóa học và chỉ nơi truy cập chúng. Điểm mấu chốt đáng nhớ: mọi phần mềm, tool và video hướng dẫn đều được gom vào một folder chia sẻ chung kèm đường link, để sau khóa học bạn vẫn tự tải về và tra cứu bất cứ lúc nào.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm được danh sách công cụ đã học và biết tìm chúng ở đâu.
• Biết cách truy cập folder chia sẻ để download phần mềm, tool và video hướng dẫn.
• Biết kênh hỗ trợ khi cần thêm công cụ quản lý dự án.

─── NỘI DUNG CHÍNH

▸ 1. Folder công cụ chia sẻ chung

Toàn bộ công cụ dùng trong khóa được thống kê vào một đường link folder chia sẻ. Ở đó có cả phần mềm lẫn video hướng dẫn: với mỗi tool, giảng viên ghi rõ video hướng dẫn tương ứng (up lên YouTube và share cho học viên). Bạn chỉ cần truy cập folder này là tải được tài liệu cần dùng.

▸ 2. Các công cụ chính đã học

• Tool khảo LOC (test counter) — đếm số lượng LOC của dự án.
• Bộ tool tự viết của giảng viên phục vụ thống kê, quản lý dự án.
• Office 2019 (Excel, Word, PowerPoint) — có link để download về máy.
• Microsoft Project — link tải để trong folder tài liệu.
• Redmine — kèm link tới khóa học Redmine trên Udemy để download và setup phần mềm.

▸ 3. Kênh hỗ trợ khi cần thêm tool

Trong quá trình làm dự án, nếu gặp vấn đề hoặc cần một công cụ để thống kê, quản lý, bạn có thể nhắn vào group Zalo để giảng viên hỗ trợ. Công cụ nào giảng viên có sẽ share, hoặc chỉ bạn nên mua ở đâu cho hợp lý. Folder công cụ được publish công khai nên học viên truy cập và download trực tiếp.

Chương 8 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học chỉ nơi truy cập và download bộ template chuẩn chất lượng dùng trong khóa. Điểm mấu chốt đáng nhớ: các template này nằm trong một folder được cập nhật liên tục, có cả bản Excel lẫn Google Sheets, và bạn có thể yêu cầu thêm template mới qua group hỗ trợ khi cần.

─── SAU BÀI HỌC, BẠN SẼ

• Biết truy cập folder Template Quality để tải các template chuẩn chất lượng.
• Phân biệt được hai định dạng template: Excel và Google Sheets.
• Biết cách xin thêm template (Kick-off, checklist…) qua kênh hỗ trợ.

─── NỘI DUNG CHÍNH

▸ 1. Folder Template Quality

Giảng viên tạo sẵn một folder Template Quality, trong đó có Quality checklist đã được demo xuyên suốt khóa học. Bạn chỉ cần truy cập folder này là download được tài liệu. Folder được update liên tục, nên hãy quay lại kiểm tra để lấy bản mới nhất khi cần.

▸ 2. Hai định dạng template

Template được cung cấp ở hai dạng: một là bằng Excel, hai là bằng Google Sheets. Bạn chọn định dạng phù hợp với cách làm việc của mình. Ngoài checklist chất lượng, còn có thể có các template khác như Kick-off — nếu cần, bạn báo giảng viên để được gửi bổ sung vào folder.

▸ 3. Kênh yêu cầu và hỗ trợ

Nếu bạn cần một template chưa có, hãy tham gia group Zalo hỗ trợ và nói rõ nhu cầu; giảng viên sẽ gửi cho bạn. Trong quá trình dùng template để quản lý dự án, nếu gặp vướng mắc hay thắc mắc, bạn cũng nhắn qua kênh này để được giải đáp.

Chương 8 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Ngoài kỹ năng quản lý dự án đã học, bài này chia sẻ những kỹ năng mềm và kỹ năng phụ trợ mà một PM thực tế cần có nhưng khóa học khó bao quát hết. Điểm mấu chốt đáng nhớ: nghề PM không chỉ là quản lý task — bạn còn phải biết làm báo giá, chỉnh CV, giữ quan hệ với team và các bộ phận, thậm chí tự viết công cụ khi hệ thống quản lý chưa đủ tốt.

─── SAU BÀI HỌC, BẠN SẼ

• Biết những kỹ năng phụ trợ ngoài quản lý: báo giá dự án, chỉnh CV cho phù hợp yêu cầu khách.
• Hiểu vai trò của kỹ năng mềm (team building, làm cầu nối thông tin) trong việc vận hành đội.
• Có tư duy chủ động cải tiến hoặc tự viết công cụ quản lý khi hệ thống hiện tại chưa ổn.

─── NỘI DUNG CHÍNH

▸ 1. Kỹ năng phụ trợ: báo giá và CV

Ngoài làm PM, bạn còn cần biết làm báo giá dự án. Khi khách hàng order nhân sự, bạn phải chuẩn bị CV cho member sao cho phù hợp công nghệ khách yêu cầu — ví dụ khách cần công nghệ này thì CV toàn công nghệ khác sẽ khó được nhận. Trong ngành outsource, việc chỉnh CV cho phù hợp là điều bắt buộc phải làm.

▸ 2. Kỹ năng mềm với team và các bên

Khi setup dự án cần đội QA/AT hỗ trợ, hãy chủ động liên hệ và giữ quan hệ tốt với các bộ phận. Với team, team building rất quan trọng: đôi khi cần lập quỹ, đi ăn uống, trò chuyện — vì trong họp anh em thường không nói hết, nhưng ra ngoài thì câu chuyện dễ mở hơn. Nếu có thành viên khó tiếp cận trực tiếp, hãy nhờ một người thân với họ làm cầu nối để hiểu họ hơn qua kênh thông tin khác.

▸ 3. Chủ động cải tiến hệ thống và công cụ

Làm PM, đừng phụ thuộc hoàn toàn vào hệ thống quản lý sẵn có. Khi thấy hệ thống chưa ổn, chính bạn phải setup lại dựa trên kinh nghiệm, hoặc thậm chí tự viết công cụ quản lý giống các tool đã được chia sẻ trong khóa, để phù hợp nhu cầu thực tế của dự án.

▸ Lưu ý: học đi đôi với thực hành

Kiến thức online có giới hạn vì thiếu tương tác trực tiếp. Muốn thật sự nắm nghề, hãy đi đủ ba bước: học → làm bài tập → thực hành thực tế. Nếu cần, bạn có thể đăng ký học trực tiếp (offline) qua các đường link giảng viên cung cấp để được hướng dẫn sát với hoàn cảnh của mình.

Chương 8 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học demo một công cụ tự viết kết nối hệ thống quản lý Redmine với Google Sheets, tự động kéo dữ liệu dự án về và dựng thống kê chất lượng. Điểm mấu chốt đáng nhớ: khi làm dự án đến mức nhất định, bạn có thể tự động hóa việc thống kê — thay vì mỗi ngày chạy lại data thủ công, chỉ cần vài thao tác là toàn bộ số liệu đổ về template và ra chart sẵn, tiết kiệm rất nhiều thời gian và chi phí.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu ý tưởng kết nối Redmine với Spreadsheet để tự động hóa thống kê dự án.
• Nắm các bước cấu hình tool: nhập API, username và chọn project cần thống kê.
• Thấy được lợi ích của việc tự viết công cụ để đổ data và dựng báo cáo chất lượng.

─── NỘI DUNG CHÍNH

▸ 1. Ý tưởng: tự động hóa việc thống kê

Ở các bài trước, việc thống kê và dùng công cụ còn làm thủ công. Khi dự án đủ lớn, bạn có thể viết công cụ để tổng kết data dự án tự động. Tool này lấy dữ liệu trực tiếp từ Redmine và đổ về một template Google Sheets — chính template đã được demo trong khóa — rồi tự dựng thống kê.

▸ 2. Các bước cấu hình và chạy tool

• Vào đường link tool, nhấn Create project.
• Nhập thông tin kết nối: API của tài khoản Redmine, rồi username.
• Chọn project cần thống kê; copy đường link sample của dự án dán vào tool.
• Nhấn Get full, rồi Submit và đợi. Data sẽ đổ toàn bộ về template Google Sheets.

▸ 3. Kết quả và lợi ích

Sau khi data đổ về, template tự ra thống kê toàn dự án: dự đoán effort từng người, trạng thái bug, các chỉ số chất lượng, kèm biểu đồ, chart. Nhờ vậy bạn thấy ngay tình hình dự án mà không phải chạy lại data mỗi ngày, tiết kiệm thời gian và chi phí.

▸ Lưu ý khi sử dụng

Định dạng ngày trong report có thể khiến bảng ra hơi khó nhìn, nhưng dữ liệu vẫn đúng. Công cụ này được chia sẻ cho học viên tham gia khóa quản lý dự án bằng Redmine; nếu cần hỗ trợ, bạn liên hệ qua group Zalo.