Khóa học ứng dụng Excel vào trong quản lý dự án phần mềm

Chương 2 · Bài 1-2-3-4

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

Bài này trả lời câu hỏi: tại sao một Project Manager bắt buộc phải biết Excel? Bảng tính (spreadsheet) là công cụ phổ biến bậc nhất trong ngành phần mềm — hơn 80% tài liệu (đặc biệt ở thị trường Nhật) được làm bằng Excel. Điểm mấu chốt: với vị trí quản lý, biết Excel là mandatory (bắt buộc), không chỉ để tính toán mà để quản lý và báo cáo được toàn bộ dự án.

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

• Hiểu bản chất "bảng tính" và vì sao nó khác phần mềm soạn thảo như Word.
• Nắm được mức độ phổ biến và sức mạnh của Excel trong công việc thực tế.
• Biết vì sao khóa học chọn Excel thay vì Google Sheets, và sẽ quản lý những gì bằng Excel.

─── NỘI DUNG CHÍNH

▸ 1. Bảng tính là gì?

Excel là một bảng tính: gồm dòng, cột, ô, và nhiều sheet, giúp bạn tính toán trên dữ liệu, số liệu, thông tin. Khác với Word (trình bày văn bản), bảng tính sinh ra cho những việc cần tính toán. Ngoài tính toán, Excel còn dùng để tạo template cho coding, và để report, monitoring, tracking, summary dự án.

▸ 2. Mức độ phổ biến và sức mạnh

Bảng tính hiện diện gần như mọi ngành nghề: quản lý dữ liệu, làm tài liệu thiết kế (basic design, detail design), estimation, proposal, báo giá, tài liệu test case, guidelines, thống kê. Trong cuộc sống nó còn dùng cho bán hàng, quản lý nhân viên, quản lý chi tiêu. Nhiều bộ phận (như kế toán) làm toàn bộ trên Excel, đặt password và tính ra lương, số liệu. Vì phổ biến như vậy nên đây là công cụ bắt buộc phải học — kể cả kỹ năng format, định dạng cho đẹp, dễ nhìn.

▸ 3. Vì sao chọn Excel, và quản lý những gì?

Khóa học tập trung vào Excel thay vì Google Sheets vì nhiều công ty bảo mật, ngắt Internet hoặc yêu cầu gửi báo cáo dạng Excel; Google Sheets chỉ tiện khi công ty mua tài khoản Google có support. Với Excel, bạn sẽ quản lý: scope, time (schedule), cost, quality, con người (human resource), risk, issue — tất cả. Bài thực hành sẽ bắt đầu từ một bảng tính trắng và làm dần để bạn hiểu cách ứng dụng, từ đó áp dụng được cho cả những việc khác ngoài quản lý dự án.

Chương 3 · Bài 1

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

Trước khi dùng Excel để quản lý dự án, bạn cần nắm dự án là gì và những yếu tố cốt lõi phải quản lý. Bài học làm rõ định nghĩa dự án (có thời hạn, có nguồn lực giới hạn, cho ra kết quả duy nhất) và bốn yếu tố nền tảng — Scope, Time, Cost, Quality — mà một Project Manager phải kiểm soát được ở mọi thời điểm.

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

• Hiểu định nghĩa "dự án" và hai ràng buộc bắt buộc: thời hạn và nguồn lực.
• Nắm được 4 yếu tố Scope / Time / Cost / Quality cần định nghĩa và quản lý.
• Biết những câu hỏi PM phải luôn trả lời được về tình trạng dự án.

─── NỘI DUNG CHÍNH

▸ 1. Dự án là gì?

Dự án là một tập hợp các hành động có liên quan, được thực hiện trong một khoảng thời gian có thời hạn với nguồn lực đã được giới hạn, để tạo ra một sản phẩm/dịch vụ có kết quả duy nhất. Điểm mấu chốt: không thể gọi "khơi khơi" một việc là dự án nếu thiếu hai ràng buộc — thời gian nhất định và nguồn lực cụ thể.

▸ 2. Bốn yếu tố cần quản lý: Scope, Time, Cost, Quality

Mọi dự án (kể cả mở một quán cà phê) đều phải định nghĩa đủ 4 yếu tố:

• Scope (phạm vi): làm những gì — ví dụ toàn bộ tính năng của một website.
• Time (thời gian): làm trong bao lâu — 3–6 tháng tùy estimation của bạn.
• Cost (chi phí): quy ra tiền từ effort ước lượng — ví dụ 2 người × 4 tháng = 8 man-month.
• Quality (chất lượng): tiêu chí "đạt" — ví dụ hệ thống chạy được, không còn lỗi.

Định nghĩa đủ 4 yếu tố này thì mới gọi là một dự án đúng nghĩa.

▸ 3. Quản lý được nghĩa là trả lời được

Khi thực hiện dự án, bạn phải quản lý được 4 yếu tố đó — bằng công cụ nào cũng được, nhưng phải trả lời được: dự án đang được bao nhiêu phần trăm, đã tốn bao nhiêu chi phí, chất lượng ra sao, có đúng scope hay bị out scope / scope creep không. Một dự án chạy mà không biết deadline, không biết chi phí thì coi như fail. Nắm được hết những điều đó mới là làm đúng vai trò quản lý dự án.

Chương 3 · Bài 2

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

Bài này giới thiệu vòng đời (lifecycle) của một dự án và các quy trình phần mềm phổ biến. Điểm mấu chốt cần nhớ: dù bạn chạy theo mô hình nào — Waterfall, V-Model, Scrum hay Hybrid — mục tiêu cuối cùng luôn là quản lý được 4 yếu tố: cost, quality, time, scope của dự án.

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

• Nắm 5 giai đoạn trong vòng đời dự án và vai trò của monitoring & controlling.
• Phân biệt các mô hình Waterfall, V-Model, Scrum và Hybrid.
• Hiểu vì sao mọi quy trình đều quy về việc quản lý scope, time, cost, quality.

─── NỘI DUNG CHÍNH

▸ 1. Vòng đời dự án — 5 giai đoạn

Một dự án đi qua 5 nhóm quy trình:

1. Initiating (khởi tạo): làm hợp đồng, lấy requirement ban đầu của khách hàng.
2. Planning (lên kế hoạch): plan chi phí, schedule, con người, scope.
3. Executing (thực thi): trong quá trình làm, nếu cần thì quay lại update plan — nên có vòng lặp giữa planning và executing.
4. Monitoring & Controlling: bao trùm mọi giai đoạn. Có việc bạn control được, có việc chỉ monitor (ví dụ cách mọi người giao tiếp) để theo dõi, phát hiện vấn đề thì nhảy vào xử lý.
5. Closing (đóng): chốt data, báo cáo các bên và đóng dự án.

▸ 2. Các mô hình quy trình phần mềm

• Waterfall: làm tuần tự từng bước, xong tài liệu này mới sang tài liệu khác.
• V-Model: mở rộng của Waterfall, chia nhỏ khâu testing — mỗi mức test ứng với một loại tài liệu (ví dụ unit testing ứng với module design, integration testing ứng với software design), giúp dự án chất lượng hơn.
• Scrum: mô hình phổ biến hiện nay (chi tiết ở khóa học trước của giảng viên).
• Hybrid: kết hợp các mô hình cũ và mới, lấy phần cần dùng của mỗi loại.

▸ 3. Điểm cốt lõi của Scrum

Scrum có product backlog (chứa requirement, user story, epic, task), product owner quản lý backlog và cùng team định story point để xác định độ ưu tiên. Team chọn task đưa vào sprint backlog qua sprint planning, rồi chạy sprint với các hoạt động daily scrum, sprint review, sprint retrospective trong timebox nhất định. Trong một sprint: không thay đổi ngang chừng, quality không được giảm, scope phải rõ ràng và cần thì renegotiate với product owner.

Chương 3 · Bài 3

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

Bài này điểm qua các công cụ quản lý dự án phổ biến mà bạn thường gặp và ưu/nhược của từng loại. Điểm mấu chốt: hầu hết công cụ mạnh đều tính phí; muốn quản lý đầy đủ time, cost, quality thường phải mua bản trả phí. Nếu không, hướng đi hợp lý là dùng open source như Redmine (miễn phí, tự cấu hình) hoặc Excel / Google Sheets.

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

• Biết các công cụ quản lý dự án thường dùng và đặc điểm chi phí của chúng.
• Hiểu giới hạn của bản miễn phí so với bản tính phí.
• Biết vì sao khóa học chọn Redmine và Excel làm công cụ chính.

─── NỘI DUNG CHÍNH

▸ 1. Các công cụ phổ biến

• Jira: công cụ quản lý rất mạnh, nhiều tính năng, nhưng tính phí; bản miễn phí có nhưng không đầy đủ.
• Redmine: open source, miễn phí, được giảng viên setup sẵn để học viên thực hành — khóa học sẽ chú tâm vào công cụ này.
• Google Sheets / Excel: dùng để quản lý dự án; khóa học tập trung vào Excel, dù thực tế nhiều nơi cũng dùng Google Sheets.
• Microsoft Project: dùng để lên plan, tracking dự án khá tốt, nhưng phần mềm có bản quyền, phải mua mới dùng đầy đủ.

▸ 2. Miễn phí và tính phí

Hầu hết công cụ đều đáp ứng được các yếu tố time, cost, quality, nhưng bản miễn phí thường bị giới hạn, không quản lý đủ. Muốn quản lý đầy đủ, bạn phải mua bản tính phí. Đây là điều cần cân nhắc khi chọn công cụ cho dự án.

▸ 3. Hướng đi khi không mua bản trả phí

Nếu không có bản tính phí mà vẫn muốn quản lý dự án tốt, giảng viên gợi ý tự xây dựng hệ thống open source như Redmine: chỉ cần chịu khó học, tự thiết kế và kiến trúc thì kết quả tốt hơn nhiều so với dùng một hệ thống miễn phí bị giới hạn. Đây cũng là lý do khóa học kết hợp Redmine với Excel.

Chương 3 · Bài 4

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

Bài này chỉ ra những tính năng cốt lõi mà mọi công cụ quản lý dự án (Jira, Trello, Backlog, Redmine...) đều phải có, và cách bạn dùng tiêu chí đó để đánh giá một công cụ. Điểm mấu chốt: dù là hệ thống chuyên dụng hay chỉ là một file Excel / Google Sheets, miễn nó quản lý được scope, time, cost, quality thì coi như thành công.

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

• Nắm các tính năng bắt buộc của một công cụ quản lý dự án.
• Biết dùng bộ 4 yếu tố scope/time/cost/quality để đánh giá công cụ.
• Hiểu vì sao Excel hay Redmine vẫn quản lý dự án tốt nếu thiết kế đúng.

─── NỘI DUNG CHÍNH

▸ 1. Các tính năng cơ bản của mọi công cụ

Hầu hết công cụ quản lý dự án đều giống nhau ở những điểm nền tảng:

• Quản lý và chia sẻ thông tin dự án.
• Phân quyền truy cập: mỗi role có workflow và cách truy cập riêng.
• Quản lý được scope (phạm vi), time (schedule), cost (chi phí) và quality (chất lượng).

Nếu một công cụ chưa quản lý được những yếu tố này thì chứng tỏ nó chưa hợp lý — bạn nên cân nhắc thay đổi.

▸ 2. Công cụ nào cũng được, miễn quản lý được 4 yếu tố

Kể cả khi bạn dùng một file Excel hay Google Sheets, nếu bạn thiết kế kiến trúc và tổ chức dữ liệu tốt để lưu trữ, xử lý được scope, time, cost, quality thì coi như thành công. Đây chính là yếu tố cần cân nhắc khi apply bất kỳ công cụ nào.

▸ 3. Lưu ý: đánh đổi giữa mua sẵn và tự làm

Với các công cụ tính phí, bản miễn phí hầu như không quản lý đủ các yếu tố; muốn đủ thì phải tốn nhiều công hoặc mua bản trả phí (như Jira, Backlog). Ngược lại, Redmine là open source, cấu hình khá dễ, bạn có thể tự xây. Bản chất là đánh đổi: mua sẵn thì có ngay nhưng tốn tiền; tự thiết kế (Redmine, Excel) thì tốn công nhưng chủ động — vì vậy khóa học hướng dẫn bạn chuyên sâu về Excel để quản lý dự án mà không cần phụ thuộc hệ thống nào.

Chương 4 · Bài 1-1

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

Bài này mở đầu chương về các hàm cơ bản trong Excel mà một Project Manager cần biết để xử lý dự án. Excel có rất nhiều hàm, nhưng khóa học giới hạn lại đúng những nhóm hàm cần dùng cho công việc quản lý. Điểm mấu chốt: bạn không cần học hết — chỉ cần nắm các nhóm hàm cần thiết, và biết cách tự tra cứu khi gặp hàm lạ.

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

• Biết các nhóm hàm cơ bản mà PM thường dùng trong Excel.
• Biết cách tra cứu công dụng, cú pháp và ví dụ của một hàm ngay trong Excel.
• Biết tận dụng ChatGPT và tài liệu online để tự học các hàm dễ.

─── NỘI DUNG CHÍNH

▸ 1. Các nhóm hàm cần để ý

Giảng viên nhóm các hàm cơ bản theo mục đích sử dụng trong quản lý dự án, ở mức khái niệm:

• Nhóm logical: một số hàm điều kiện, dùng để kiểm tra và xử lý theo logic đúng/sai.
• Nhóm text: dùng để cắt chuỗi, tách và phân tích dữ liệu dạng chữ — rất cần khi làm dự án.
• Nhóm date and time: dùng để tính toán liên quan ngày tháng.

Khóa học thiên về thực hành, nên các hàm dễ sẽ không giảng lý thuyết nhiều; phần demo sẽ nói cụ thể từng hàm dùng như thế nào khi gặp trong tình huống thực tế.

▸ 2. Tự tra cứu ngay trong Excel

Với mỗi hàm, khi bạn gõ tên hàm, Excel hiển thị luôn cú pháp, phần help giải thích và ví dụ; click vào có thể mở trang web hướng dẫn chi tiết. Nếu bạn chỉnh ngôn ngữ sang tiếng Việt, phần giải thích cũng hiển thị tiếng Việt — rất dễ tự học. Vì vậy các hàm đơn giản bạn hoàn toàn có thể tự tra mà không cần giảng kỹ.

▸ 3. Học hàm khó và cách được hỗ trợ

Những hàm khó hơn và thường dùng sẽ được giảng viên demo cụ thể trong quá trình thực hành, kèm cách lồng hàm và xử lý tình huống. Ngoài Excel, bạn có thể dùng ChatGPT hoặc tra trên mạng để học nhanh. Khi gặp khó khăn lúc làm bài, bạn có thể liên hệ giảng viên để được hướng dẫn cách viết và xử lý cùng.

Chương 4 · Bài 1-2

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

Nối tiếp phần liệt kê hàm ở slide trước, bài này demo trực tiếp các hàm cơ bản trên một file đã có sẵn công thức. Điểm mấu chốt: bản thân mỗi hàm trong Excel đã có phần giải thích và ví dụ ngay trong công cụ, nên việc học từng hàm không khó — cái khó thật sự là biết ứng dụng hàm nào vào tình huống quản lý dự án.

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

• Biết mở mục Formula để tra danh sách hàm cùng phần giải thích và ví dụ có sẵn.
• Hiểu ý nghĩa vài hàm ngày tháng thường dùng: DATE, DATEVALUE, NETWORKDAYS.
• Biết cách tự tra cứu một hàm lạ mà không cần học thuộc.

─── NỘI DUNG CHÍNH

▸ 1. Tra hàm ngay trong Excel

Trong file mẫu, bạn click vào tab Formula để thấy toàn bộ các hàm đã liệt kê ở slide trước. Mỗi hàm khi click vào mũi tên sẽ dẫn tới ví dụ minh họa và phần chữ giải thích ý nghĩa. Ví dụ hàm LOWER có chú thích là "chuyển chữ về chữ thường". Nhờ vậy, khi gặp hàm như CHAR(34) hay CODE, bạn chỉ cần đọc phần mô tả kèm ví dụ ngay tại đó là hiểu.

▸ 2. Vài hàm ngày tháng đáng nhớ

• DATE: nhận ba tham số theo định dạng year, month, day rồi trả về một giá trị kiểu ngày tháng.
• DATEVALUE: từ một chuỗi ngày (viết theo nhiều kiểu khác nhau) tính ra giá trị của ngày đó.
• NETWORKDAYS: tính số working day giữa hai mốc, tự trừ đi ngày nghỉ. Nếu có từ hai ngày nghỉ trở lên, bạn đưa thêm danh sách ngày nghỉ vào công thức.

▸ 3. Học hàm nào, ứng dụng ra sao

Tài liệu các hàm này được đính kèm trong slide để bạn tải về xem và luyện tập. Những hàm cơ bản đều rất phổ biến, bạn có thể tra thêm trên mạng hoặc YouTube. Giảng viên nhấn mạnh: nắm cú pháp hàm chỉ là bước đầu, biết dùng đúng hàm cho đúng bài toán quản lý dự án mới là phần giá trị của khóa học.

Chương 4 · Bài 2

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

Excel có rất nhiều định dạng file, nhưng khi quản lý dự án bạn chỉ cần nắm 3 loại: XLS (bản cũ), XLSX (bản mới, không chứa macro) và XLSM (bản mới, có chứa macro). Bài học giải thích khác biệt giữa chúng và điểm mấu chốt dễ mất dữ liệu: nếu file có code mà lưu sai định dạng thì macro sẽ bị mất.

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

• Phân biệt 3 định dạng XLS, XLSX, XLSM và chọn đúng loại khi Save As.
• Hiểu macro là gì và khi nào cần đến file chứa macro.
• Tránh lỗi mất code VBA do lưu file sai định dạng.

─── NỘI DUNG CHÍNH

▸ 1. Ba định dạng cần để ý

Khi Save As, Excel cho rất nhiều loại, nhưng chỉ cần nhớ 3:

• XLS — phiên bản cũ (Excel 97–2003); loại này chứa được macro bên trong.
• XLSX — phiên bản mới, không chứa macro.
• XLSM — phiên bản mới, có chứa macro (Excel Macro-Enabled Workbook).

Điểm khác biệt: bản cũ (XLS) gộp chung, còn bản mới tách rõ hai loại có/không có macro.

▸ 2. Macro là gì?

Macro là phần cho phép bạn lập trình / viết code để xử lý dữ liệu trong Excel nhiều hơn mức công thức thông thường, xử lý bằng code VBA. Khóa học sẽ giới thiệu VBA ở phần sau; hiện tại chỉ cần hiểu macro = "có support code bên trong".

▸ 3. Cạm bẫy: lưu sai định dạng làm mất macro

Nếu bạn viết sub code (Alt + F11) trong một file rồi lưu ở định dạng không hỗ trợ macro (XLSX), khi mở lại code sẽ biến mất. Muốn giữ code, phải lưu ở định dạng XLSM (hoặc XLS). Đây là lỗi rất hay gặp khi làm báo cáo có macro.

▸ Mẹo: khi nào cần macro, khi nào không

Với đa số công việc quản lý dự án, chỉ cần học công thức và cách liên kết là đủ để thống kê và quản lý — dùng file XLSX thường. Chỉ khi bạn muốn lấy dữ liệu real time, tự động, kết nối nhiều nguồn, hoặc muốn xử lý nhanh hơn thì mới cần đến macro (VBA) và file XLSM.

Chương 4 · Bài 3

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

Đây là bài chia sẻ những thủ thuật Excel cốt lõi mà giảng viên đúc kết sau nhiều năm làm việc — chỉ cần nắm nhóm này là đủ dùng cho hầu hết công việc quản lý dự án. Bài đi qua năm nhóm tip: Data Validation, Conditional Formatting, quy tắc màu sắc, font chữ, và cuối cùng là bộ công cụ format do tác giả tự viết tặng học viên.

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

• Tạo được combo box chọn giá trị bằng Data Validation → List.
• Tô màu ô tự động theo điều kiện bằng Conditional Formatting.
• Trình bày bảng gọn, thống nhất về màu và font theo quy tắc đơn giản.

─── NỘI DUNG CHÍNH

▸ 1. Data Validation và Conditional Formatting

• Data Validation: chọn cột cần giới hạn, vào Data → Data Validation → List, trỏ tới vùng nguồn để tạo combo box (ví dụ cột status: chưa làm / đang làm / hoàn thành).
• Conditional Formatting: dùng Manage Rule → New Rule → "Use a formula to determine which cells to format" để tô màu theo trạng thái (đang làm màu cam, hoàn thành màu xám). Nhớ cố định cột bằng dấu $ và chỉnh đúng vùng Apply to. Ngoài công thức, còn có sẵn Data Bar, Color Scale, Icon Set để trực quan hóa số liệu.

▸ 2. Quy tắc màu sắc và font chữ

Một tip đơn giản mà hiệu quả: nền lợt thì chữ đen, nền đậm thì chữ trắng. Tiêu đề nên merge, căn giữa, cho font lớn hơn; hoặc dùng Insert → Table để Excel tự áp quy tắc màu. Nếu merge cell gây khó filter, bạn có thể không merge mà vẫn trình bày đẹp. Về font, dùng font mặc định cùng các font đơn giản như Times New Roman, Tahoma, Cambria (hiển thị tiếng Việt tốt), và giữ size đồng nhất (ví dụ 11 cho nội dung, 18 cho header).

▸ 3. Bonus: công cụ format của tác giả

Cuối bài, giảng viên tặng công cụ format tự viết với nhiều tính năng: unmerge toàn bộ, zoom mọi sheet, bật page break preview, remove hyperlink/data connection lỗi, đếm số page, tìm và thay text trong shape, tạo shape index, unhide all sheets, remove conditional formatting, set font đồng loạt, export/clear comment và note. Bạn có thể tải về dùng ngay cho dự án.

Chương 4 · Bài 4

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

Bài hướng dẫn bạn tham gia các kênh hỗ trợ miễn phí của khóa học để được giải đáp trong lúc thực hành. Có ba kênh chính: nhóm Zalo, forum của khóa, và link tải công cụ đã demo ở bài trước. Điểm cần nhớ: mọi hỗ trợ đều miễn phí, bạn chỉ cần chủ động đặt câu hỏi khi gặp vướng mắc.

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

• Biết cách tham gia nhóm Zalo và nhắn tin cho giảng viên.
• Biết đăng ký tài khoản forum để đặt câu hỏi và lưu lại nội dung.
• Biết nơi tải bộ công cụ format kèm hướng dẫn cài đặt.

─── NỘI DUNG CHÍNH

▸ 1. Nhóm Zalo và forum

• Nhóm Zalo: click vào đường link group để tham gia. Nếu không muốn vào nhóm, bạn có thể nhắn tin riêng cho giảng viên — Zalo đã mở chế độ cho khách nhắn nên không cần kết bạn vẫn nhắn được.
• Forum: truy cập qua đường link (hoặc gõ "forum") rồi đăng ký một tài khoản. Đây là nơi bạn đặt câu hỏi, chia sẻ code VBA và trao đổi trong các diễn đàn. Ưu điểm của forum là câu hỏi được lưu lại để nhiều người cùng tham khảo về sau.

▸ 2. Hệ sinh thái khóa học

Giảng viên hiện có 6 khóa học trên trang online.smartitsoft, gồm các chủ đề như Google Sheets, VBA, QA, kiến thức cho người mới đi làm và xây dựng hệ thống Redmine. Bạn có thể vào trang khóa học để xem trọn bộ và đặt câu hỏi ở group hoặc forum cho từng chủ đề.

▸ 3. Tải công cụ hỗ trợ

Bộ công cụ format đã demo ở bài trước được chia sẻ qua đường link công cụ học. Bạn vào link, download về và giải nén; bên trong có kèm hướng dẫn cài đặt. Nếu cài không được, hãy liên hệ giảng viên để được gửi video hướng dẫn trên YouTube.

Chương 4 · Bài 5-0

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

Đây là bài giới thiệu chuỗi bài tập thực hành các hàm cơ bản dành cho Project Manager. Mục tiêu là dùng các hàm cơ bản kết hợp Data Validation để làm cho quen tay trước khi đi sâu vào phần quản lý dự án ở các chương sau. Vì nội dung khá dài, giảng viên tách thành bốn bài tập nhỏ để bạn dễ theo dõi.

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

• Nắm được lộ trình bốn bài tập thực hành sắp tới.
• Hiểu mục đích: luyện hàm cơ bản và Data Validation cho thành thạo.
• Biết nơi lấy file/đường link thực hành ở cuối mỗi bài.

─── NỘI DUNG CHÍNH

▸ 1. Mục tiêu của chuỗi bài tập

Sau khi đã học các hàm cơ bản và phần Data Validation ở những bài trước, phần này giúp bạn áp dụng vào bài tập thực tế. Ý tưởng là làm cho quen tay với hàm và cách tổ chức dữ liệu, tạo nền tảng để về sau đi sâu hơn vào các bài toán quản lý dự án.

▸ 2. Bốn bài tập được tách nhỏ

Toàn bộ nội dung được chia thành bốn file, theo thứ tự bạn nên xem lần lượt:

1. Thiết lập file quản lý thông tin nhân viên.
2. Quản lý giờ làm việc của nhân viên.
3. Quản lý công việc của nhân viên.
4. Quản lý chi phí của dự án.

▸ 3. Tài liệu thực hành

Ở cuối mỗi bài, giảng viên sẽ đính kèm đường link file tương ứng để bạn tải về và tự thực hành theo. Bạn nên xem tuần tự từ bài quản lý thông tin nhân viên trước rồi tiếp tục các bài sau để nắm trọn cách làm.

Chương 4 · Bài 5-1

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

Bài tập đầu tiên hướng dẫn bạn dựng một file quản lý thông tin nhân viên trên Excel. Điểm mấu chốt không nằm ở công thức, mà ở tư duy thiết kế trước khi làm: luôn đặt câu hỏi cần quản lý cái gì, phác thảo cấu trúc, rồi mới xác định từng cột và kiểu dữ liệu. Đây là thói quen quan trọng cho mọi file quản lý về sau.

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

• Biết đặt câu hỏi để xác định phạm vi thông tin nhân viên cần quản lý.
• Biết xác định kiểu dữ liệu và tạo combo box cho các cột phù hợp.
• Nắm ý tưởng validate dữ liệu nhập và thống kê danh sách nhân viên.

─── NỘI DUNG CHÍNH

▸ 1. Đặt câu hỏi và thiết kế cột

Trước khi làm, hãy xác định bạn cần quản lý gì: thông tin cơ bản của nhân viên, việc nhân viên rời công ty/dự án, và kỹ năng (skill) của họ. Từ đó liệt kê các cột như: mã nhân viên, họ tên, email, số điện thoại, địa chỉ, vị trí, kỹ năng, trạng thái, ngày rời công ty, ghi chú. Sắp xếp các cột liên quan gần nhau để bảng dễ đọc, và xác định kiểu dữ liệu cho từng cột trước khi nhập.

▸ 2. Combo box và kiểm soát dữ liệu nhập

Với các cột có giá trị cố định như vị trí và trạng thái, tạo combo box bằng Data Validation → List, lấy nguồn từ một sheet config riêng. Với email, dùng kiểu Custom để chỉ chấp nhận giá trị hợp lệ. Với số điện thoại, lưu ý số 0 ở đầu dễ bị mất nếu để kiểu số — nên cân nhắc dùng kiểu chữ. Với ngày, định dạng lại qua Format Cells. Ở mức bài tập, ý chính là mỗi cột cần một cách kiểm soát nhập liệu phù hợp.

▸ 3. Tô màu trạng thái và thống kê

Dùng Conditional Formatting để làm nổi bật các trạng thái (ví dụ nhân viên nghỉ việc), và cảnh báo khi dữ liệu còn thiếu. Cuối cùng, tạo một sheet thống kê: đếm tổng nhân viên, số người đang làm và nghỉ việc, tính tỷ lệ, rồi trực quan hóa bằng chart hoặc pivot table.

Chương 4 · Bài 5-2

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

Bài tập thứ hai hướng dẫn bạn dựng bảng theo dõi (tracking) giờ làm việc của nhân viên theo từng ngày trong tháng. Trọng tâm là dùng hàm WEEKDAY, hàm TODAY và Conditional Formatting để tự động nhận biết ngày cuối tuần và ngày hôm nay, giúp việc nhập và đọc số giờ nhanh, ít sai sót.

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

• Dựng được bảng tracking giờ làm với các cột ngày trải theo tháng.
• Dùng WEEKDAY để hiện thứ và tô màu tự động thứ Bảy, Chủ nhật.
• Dùng TODAY để đánh dấu ngày hiện tại và cố định vùng nhìn bằng Freeze Panes.

─── NỘI DUNG CHÍNH

▸ 1. Dựng bảng và các cột ngày

Tạo một sheet tracking với các cột: số thứ tự, account (tài khoản nhân viên), tổng số giờ làm việc, tiếp theo là các cột ngày trải dài cả tháng (nhập ngày đầu rồi cộng 1 để kéo tiếp). Để bảng gọn, dùng Format Cells → Custom rút gọn hiển thị ngày (ví dụ chỉ còn "dd"). Dùng View → Freeze Panes để cố định cột account khi cuộn sang phải xem nhiều ngày.

▸ 2. Nhận biết thứ trong tuần

Dùng hàm WEEKDAY để lấy thứ của mỗi ngày (Chủ nhật quy ước là 1). Muốn hiển thị tên thứ thay vì số, chỉnh Format Cells → Date với định dạng "ddd". Sau đó dùng Conditional Formatting với công thức để tô xám thứ Bảy và Chủ nhật (khi WEEKDAY bằng 7 hoặc bằng 1). Khi bạn đổi ngày bắt đầu, các ô cuối tuần sẽ tự dịch theo.

▸ 3. Đánh dấu ngày hôm nay và tổng hợp

Số thứ tự tự động bằng công thức dựa trên ROW. Dùng hàm TODAY kết hợp Conditional Formatting để tô màu (ví dụ màu cam) đúng cột ngày hôm nay, giúp bạn biết ngay chỗ cần điền dữ liệu; có thể thêm ô chênh lệch để dịch ngày cần xem. Kết quả là bảng cho ra tổng số giờ làm việc theo tháng.

Giảng viên lưu ý: thực tế nhiều công ty đã có hệ thống chấm công riêng, bài này chủ yếu để luyện hàm và cách làm, không nhất thiết làm thủ công như vậy.

Chương 4 · Bài 5-3

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

Bài tập thứ ba hướng dẫn dựng một file quản lý công việc của nhân viên bằng Excel. Ngoài việc liệt kê và theo dõi danh sách công việc, điểm giá trị nhất là cách tính công việc trễ tiến độ — so trạng thái công việc với một mốc ngày kiểm tra để biết task đang trễ start, trễ end hay vẫn on track.

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

• Định nghĩa được các thuộc tính cần có của một công việc.
• Dùng combo box để quản lý trạng thái và danh mục công việc.
• Hiểu logic phân loại công việc trễ tiến độ theo ngày kiểm tra.

─── NỘI DUNG CHÍNH

▸ 1. Đặt câu hỏi và định nghĩa công việc

Như các bài trước, hãy đặt câu hỏi cần quản lý gì: danh sách công việc mỗi ngày, khối lượng công việc, và các công việc trễ tiến độ. Từ đó định nghĩa các thuộc tính của một công việc: category (danh mục), tên công việc, người tạo, người làm, ngày bắt đầu/kết thúc kế hoạch, ngày bắt đầu/kết thúc thực tế, số giờ dự kiến, số giờ thực tế, trạng thái và ghi chú.

▸ 2. Trạng thái công việc và tổ chức dữ liệu

Trạng thái (chưa làm, đang làm, đã hoàn thành) và danh mục được quản lý bằng combo box qua Data Validation lấy nguồn từ sheet config. Số thứ tự tự động bằng công thức ROW, kẻ khung và Conditional Formatting tô màu theo trạng thái. Giảng viên lưu ý: thực tế trạng thái công việc có thể tới 6 mức, nhưng ở bài tập này chỉ dùng 3 cho đơn giản; và số giờ luôn chỉ là ước lượng.

▸ 3. Cách tính công việc trễ tiến độ

Đặt một cột ngày check tiến độ (thường là ngày hiện tại, có thể cộng/trừ để dịch mốc). Logic phân loại: nếu công việc chưa làm mà đã tới ngày bắt đầu → trễ start; nếu đang làm mà đã tới ngày kết thúc mà chưa xong → trễ end; nếu đã hoàn thành thì không cần check; còn lại là on track. Các điều kiện này viết bằng hàm IF kết hợp AND.

Chương 4 · Bài 5-4

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

Bài tập cuối của chuỗi hướng dẫn dựng file quản lý chi phí dự án, tập trung vào chi phí nhân lực (tiền lương) quy đổi từ effort. Điểm mấu chốt: quy mọi thứ về đơn vị man month (MM) và working day để so sánh ngày công thực tế với budget, đồng thời tính lời/lỗ của dự án.

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

• Hiểu khái niệm man month và cách quy đổi ra số ngày công.
• Dùng NETWORKDAYS và VLOOKUP để tính ngày công và tra mức lương.
• Tính được chi phí lương, so với doanh thu để ra lời/lỗ dự án.

─── NỘI DUNG CHÍNH

▸ 1. Phạm vi và khái niệm man month

Ở vai trò quản lý dự án phần mềm, bạn chủ yếu quản lý chi phí lương theo effort; các khoản như thiết bị, bảo hiểm, khấu hao đã có bộ phận kế toán/vận hành lo. Hai câu hỏi cần trả lời: quản lý được chi phí lương theo giờ, và kiểm tra việc đưa người vào dự án có đúng budget không. Quy ước: 1 man month = 20 working day; ví dụ dự án 5 MM tương ứng khoảng 100 ngày công — đây là mốc budget để đối chiếu.

▸ 2. Tính ngày công và mức lương

Lập sheet chi phí lương với full name, account và mức lương từng người. Dùng hàm NETWORKDAYS tính số ngày công theo mốc start/end, rồi Sum lại để so với budget — nếu vượt thì phải điều chỉnh kế hoạch. Mức lương quy về lương/ngày (chia 20) hoặc lương/giờ (chia 8). Dùng VLOOKUP để tra mức lương theo account. Với nhân sự làm qua nhiều tháng, nên tách riêng từng tháng (mỗi tháng số working day khác nhau) để tính chính xác hơn, và dùng IF để xử lý phần ngày vượt quá 20.

▸ 3. Lời/lỗ của dự án

Sau khi có tổng chi phí lương, so với doanh thu (ví dụ báo giá 1 MM = 80 triệu, dự án 5 MM = 400 triệu). Lời/lỗ = doanh thu trừ chi phí. Đừng quên cộng thêm chi phí khác (các bộ phận hỗ trợ như admin...), có thể tính theo số tiền cố định hoặc theo phần trăm tổng chi phí. Nhờ bảng này, khi load người vào dự án bạn biết ngay chi phí và biên lợi nhuận để quản lý dự án chủ động hơn.

Chương 4 · Bài 6

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

Bài hướng dẫn cách dùng ChatGPT như một công cụ tự học hàm Excel. Điểm mấu chốt là kỹ thuật hỏi: bắt đầu từ vấn đề bạn cần giải quyết (chưa biết dùng hàm nào), rồi hỏi sâu dần để lấy công thức, ví dụ và các biến thể. Chỉ vài lượt hỏi là bạn có thể tự tìm ra hàm phù hợp mà không cần học thuộc.

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

• Biết cách đặt câu hỏi cho ChatGPT theo hướng từ tổng quát đến chi tiết.
• Tự tìm được hàm phù hợp cho một bài toán Excel cụ thể.
• Biết cách yêu cầu ví dụ và xử lý các trường hợp đặc biệt.

─── NỘI DUNG CHÍNH

▸ 1. Hỏi từ vấn đề cần giải quyết

Thay vì tìm tên hàm, bạn mô tả bài toán của mình. Ví dụ: "Trong Excel, tôi muốn tính số ngày làm việc của nhân viên và bỏ đi thứ Bảy, Chủ nhật, tôi dùng hàm nào?". ChatGPT sẽ gợi ý hàm phù hợp — ở đây là NETWORKDAYS — kèm giải thích cách dùng.

▸ 2. Hỏi sâu dần để lấy ví dụ

Sau khi có tên hàm, hãy hỏi tiếp "cho tôi một ví dụ cụ thể". ChatGPT sẽ đưa ví dụ dễ hiểu (ví dụ đặt ngày bắt đầu ở A1, ngày kết thúc ở A2 rồi tính NETWORKDAYS giữa hai ô). Muốn xử lý tình huống riêng, bạn hỏi thêm — chẳng hạn "trường hợp có ngày lễ, tôi muốn loại trừ thì làm thế nào" — và nó sẽ hướng dẫn đưa danh sách ngày lễ vào hàm.

▸ 3. Mẹo quan trọng: hỏi nhiều lần cho rõ

Nguyên tắc là hỏi liên tục, chi tiết dần: câu đầu nêu nhu cầu, câu sau xin công thức, câu tiếp xin ví dụ cụ thể hơn. Thường khoảng hai đến ba lượt là bạn đã hiểu cách làm. Nếu vẫn chưa rõ, hãy reset cuộc hội thoại và hỏi lại, hoặc đặt câu hỏi trong nhóm hỗ trợ của khóa học để được giải đáp trực tiếp.

Chương 5 · Bài 1

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

Scope (phạm vi công việc) là yếu tố đầu tiên của bộ Scope – Time – Cost – Quality, và nếu không xác định rõ thì rất nguy hiểm cho dự án. Bài học định nghĩa scope trong dự án phần mềm là danh sách màn hình, danh sách chức năng mà bạn cam kết làm, và chỉ ra những thông tin bắt buộc phải quản lý để không bị out scope / scope creep. Điểm mấu chốt: mọi thứ trong scope phải được chốt (baseline) theo một version tài liệu cụ thể.

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

• Hiểu scope trong phần mềm chính là danh sách màn hình / chức năng đã được chốt.
• Biết những thông tin cần quản lý: tên công việc, giai đoạn, version tài liệu, ngày nhận.
• Nắm nguyên tắc baseline tài liệu để phân biệt việc trong scope và ngoài scope.

─── NỘI DUNG CHÍNH

▸ 1. Scope là gì trong dự án phần mềm?

Dự án mang tính tạm thời, tạo ra sản phẩm duy nhất, trong thời gian và ngân sách cho phép — tất cả đã được fix từ đầu. Với phần mềm, scope được cụ thể hóa thành danh sách màn hình và danh sách chức năng. Ví dụ chức năng quản lý user gồm 4 màn hình: login, tạo user, list user, edit/xóa user. Bạn phải chốt danh sách này lại tại một thời điểm để biết mình làm bao nhiêu function và mỗi function dựa trên version tài liệu nào.

▸ 2. Các thông tin cần quản lý

Với mỗi hạng mục công việc, bạn phải nắm được:

• Tên công việc và mã định danh.
• Giai đoạn: Study → Coding → Testing → Delivery, kèm các task nhỏ bên trong như review code, integration code.
• Tài liệu: tên tài liệu, ngày nhận, version tài liệu design đang áp dụng.

Đặc biệt phải định nghĩa rõ với khách hàng: coding màn hình nào, có tích hợp (integration) hay không, ai chịu trách nhiệm test.

▸ 3. Baseline để quản lý được

Khi nhận phạm vi công việc, bạn baseline tài liệu lại theo ngày và version. Nhờ đó bạn luôn trả lời được: dự án đang code theo tài liệu nào, file hiện tại là gì, việc nào in scope, việc nào phát sinh thêm. Cách kiến trúc file Excel để quản lý những thông tin này sẽ được thực hành ở bài số 2.

Chương 5 · Bài 2

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

Đây là bài thực hành trực tiếp trên Excel: từ một file proposal / báo giá dự án demo, bạn học cách bóc tách phạm vi công việc rồi dựng một file Excel quản lý scope. Bài đi từ việc đọc file đấu thầu (khác với hợp đồng), khẳng định scope là gì, cho tới hai kỹ thuật cốt lõi: đặt mã màn hình duy nhất và baseline tài liệu theo ngày/version để lúc nào cũng biết màn hình nào đang áp dụng tài liệu nào.

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

• Biết đọc file proposal dự án và bóc tách đâu là phạm vi công việc phải làm.
• Dựng được danh sách màn hình có mã định danh duy nhất trong Excel.
• Biết baseline tài liệu theo ngày và dùng filter để tra cứu version tài liệu.

─── NỘI DUNG CHÍNH

▸ 1. Bóc tách scope từ file proposal

File dự án demo có nhiều sheet: lịch sử thay đổi, thông tin dự án (khách hàng, kích cỡ tính bằng man-month), mô tả yêu cầu, danh sách sản phẩm bàn giao, điều kiện nghiệm thu và Work Breakdown Structure. Từ đó bạn khẳng định scope: ví dụ 15 trang website, có multi-language (Việt – Anh – Nhật) nên tổng thành 45 trang, làm từ thiết kế đến hướng dẫn khách hàng, dựa trên hai tài liệu reference đã nhận.

▸ 2. Đặt mã màn hình duy nhất

Bạn định nghĩa lại tên màn hình theo danh mục (website user / admin) rồi gán mã định danh khoảng 7 ký tự, ghép từ: đối tượng (U/A), ngôn ngữ (VN/EN/JP) và loại màn hình (home, intro, product detail…). Nguyên tắc bất di bất dịch: mã màn hình phải duy nhất. Khi tester báo bug kèm mã, bạn đọc mã là biết ngay màn hình nào — cực kỳ tiện.

▸ 3. Baseline tài liệu và tra cứu bằng filter

Mỗi màn hình được gắn với version tài liệu theo ngày customer supply (ví dụ document ngày 15/04 version A/B). Bạn có thể trình bày nối tiếp theo dòng, hoặc đánh dấu chéo giữa mã màn hình và version. Khi cần biết một tài liệu ảnh hưởng những màn hình nào, chỉ cần Data → Filter rồi lọc theo cột đánh dấu là ra ngay. Cách này hơi rối hơn khi nhìn nhanh, nhưng dễ filter và tổng kết — nên khóa học chọn dùng.

Chương 5 · Bài 3

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

Đây là bài case study — giảng viên chia sẻ kinh nghiệm thực chiến khi quản lý scope bằng file Excel. Điểm mấu chốt: một file Excel quản lý scope nếu chỉ nằm trên máy một người thì sẽ trở thành bottleneck (nút thắt cổ chai), và chính những thay đổi nhỏ (Q&A với khách hàng) mà bạn không nắm được mới là ngòi nổ cho out of scope / scope creep.

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

• Hiểu vì sao file scope phải được share, không giữ riêng một mình.
• Nhận ra cơ chế khiến tài liệu bị out of date và kéo cả dự án lệch scope.
• Biết ba nguyên tắc để đồng bộ thông tin scope trong team.

─── NỘI DUNG CHÍNH

▸ 1. File scope phải được share

Làm PM, khoảng 90% thời gian là communication, nên những trao đổi nhỏ giữa developer/PA với khách hàng bạn khó nắm hết. Nếu file scope chỉ nằm trên máy bạn, nó bị bottleneck. Hãy đưa file lên file server, SVN, Git hoặc Google Drive và quy định version tài liệu đang áp dụng cho cả team cùng thấy.

▸ 2. Cạm bẫy: tài liệu out of date

Tình huống điển hình: cả team baseline theo tài liệu ngày 15/04 version B. Khách hàng trả lời một Q&A làm tài liệu đó out of date, nhưng developer đã code theo bản cũ, tester cũng viết test case theo bản cũ mà không biết Q&A kia. Kết quả: file scope không còn hợp lý, sản phẩm cuối lệch nhu cầu khách hàng — coi như thất bại.

▸ 3. Ba cơ chế đồng bộ

Để tránh out of date, giảng viên khuyên:

1. Quy định version tài liệu đang bay cho toàn team; ai có Q&A thay đổi phải báo lại dự án.
2. Cập nhật ngược Q&A vào tài liệu, hoặc yêu cầu khách hàng gửi lại tài liệu mới khi quá nhiều thay đổi.
3. Daily meeting: mỗi ngày dành 10–15 phút để người nắm Q&A inform trạng thái tài liệu, giúp cả team synchronize.

Cuối cùng, việc tô màu cho đẹp không quan trọng bằng việc bạn hiểu đúng logic của hệ thống quản lý mình dựng.

Chương 6 · Bài 1

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

Time ở đây được hiểu là tiến độ (schedule) của công việc. Ai đi làm cũng biết "quản lý tiến độ", nhưng vấn đề lớn nhất là làm sao đo được tiến độ một cách chính xác. Bài học chỉ ra nguyên tắc cốt lõi: muốn biết đúng tiến / trễ / vượt tiến độ, bạn phải quy công việc về một đơn vị đo được rồi so sánh giữa kế hoạch và thực tế tại một mốc thời gian.

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

• Hiểu tiến độ = so sánh phần trăm hoàn thành thực tế với kế hoạch theo thời gian.
• Phân biệt được ba trạng thái: đúng tiến độ, trễ tiến độ, vượt tiến độ.
• Biết quy sản phẩm mỗi giai đoạn về một đơn vị để đo được tiến độ.

─── NỘI DUNG CHÍNH

▸ 1. Thế nào là đúng / trễ / vượt tiến độ

Nếu một việc dự kiến làm trong 3 ngày, thì hết ngày thứ nhất bạn phải đạt hơn 30%, hết ngày thứ hai hơn 60%, ngày cuối 100% mới gọi là đúng tiến độ. Ngày đầu chỉ đạt 20% trong khi kế hoạch là hơn 30% nghĩa là trễ. Ngược lại, đến giữa kỳ mà đạt 60–70% so với mốc 50% thì đang vượt tiến độ. Khó khăn thực sự là đo cho ra con số phần trăm đó.

▸ 2. Đo tiến độ bằng đơn vị sản lượng

Mỗi ngành có đơn vị đo riêng. Ngành may mặc đo theo sản lượng (số sản phẩm trên tổng kế hoạch). Với phần mềm, một màn hình có 8 chức năng mà làm xong 4 chức năng thì mới được 50%. Tester có thể đo theo số test case viết được trên tổng số test case dự kiến — lưu ý nếu ước lượng lại tổng tăng lên thì phần trăm hoàn thành sẽ giảm tương ứng.

▸ 3. Quy sản phẩm từng giai đoạn về đơn vị đo

Dự án phần mềm có ba giai đoạn: design – code – test. Mỗi giai đoạn có sản phẩm đầu ra riêng để đo:

• Design: số trang tài liệu.
• Coding: số line of code.
• Testing: số test case, số bug.

Bạn dựa trên output đó, quy đổi ra một đơn vị rồi mới đo được tiến độ. Các phương pháp ước lượng chi tiết hơn (nôm, line of code theo phương pháp Nhật) đã được nói kỹ ở khóa PM trước; khóa này tập trung vào thực hành nên chỉ nhắc lại phần nền.

Chương 6 · Bài 2

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

Đây là bài thực hành dài, hướng dẫn dựng một sheet Time Management trong Excel để theo dõi tiến độ của danh sách công việc (task list). Bài đi từ việc thiết kế các cột thông tin của task, tạo danh sách trạng thái, sinh ID duy nhất, cho tới điểm quan trọng nhất: một cột check tiến độ tự động cảnh báo task đang trễ start hay trễ end, kèm tô màu và filter để nhìn ra ngay.

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

• Thiết kế được template quản lý task với đủ cột dự kiến và thực tế.
• Dùng data validation tạo dropdown trạng thái và loại công việc chuẩn hóa.
• Biết ý tưởng cột check tiến độ để tự phát hiện task trễ start / trễ end.

─── NỘI DUNG CHÍNH

▸ 1. Thiết kế template task list

Sheet Time Management gồm các cột: ID, loại công việc (tracker type: task, Q&A, issue, risk, bug), tên công việc, người tạo, người làm, phần dự kiến (số giờ estimate, ngày bắt đầu, ngày kết thúc) và phần thực tế tương ứng, kèm cột status và ghi chú. Nên để cột trạng thái phía trước và tô màu tách nhóm dự kiến / thực tế cho dễ nhìn.

▸ 2. Chuẩn hóa danh sách và sinh ID

Tạo một sheet cấu hình (99config) chứa danh sách tracker type và status (open, ongoing, result, request review, done/close, pending, cancel), rồi dùng Data → Data Validation → List để đổ vào dropdown. Tên task được ghép tự động từ mã màn hình và giai đoạn (design/code/test) bằng hàm nối chuỗi. Mỗi task cần một ID duy nhất, tăng dần để tham chiếu như ticket trên hệ thống quản lý.

▸ 3. Cột check tiến độ và cảnh báo trực quan

Ý tưởng cốt lõi: thêm một cột check tiến độ dựa vào ngày báo cáo (today) và trạng thái task. Logic ở mức khái niệm:

• Trạng thái open mà đã qua ngày start → trễ start.
• Trạng thái ongoing / review mà đã qua ngày end → trễ end.
• Các trạng thái đã xong (result, done, pending, cancel) → không cần quan tâm.

Dùng Conditional Formatting tô đỏ các task trễ, rồi Filter by Color để tập trung xử lý. Với ngày báo cáo, nên đặt một ô tham số cộng/trừ để đổi mốc kiểm tra nhanh thay vì sửa từng ngày.

Chương 6 · Bài 3

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

Bài case study chia sẻ kinh nghiệm quản lý tiến độ thực tế. Từ file Time Management đã dựng, giảng viên hướng dẫn cách ước lượng độ trễ của cả dự án (sum số giờ các task trễ) và quan trọng hơn — cách đối ứng khi bị trễ. Điểm mấu chốt: dữ liệu chỉ có ý nghĩa khi nó giúp bạn ra được một action hợp lý.

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

• Biết ước lượng tổng số giờ dự án đang bị trễ để lượng hóa vấn đề.
• Nắm các phương án đối ứng khi trễ: thêm người, kéo time hoặc giảm scope.
• Nhận diện hai dấu hiệu cần lưu ý: trễ tập trung ở một người hoặc trễ toàn bộ.

─── NỘI DUNG CHÍNH

▸ 1. Ước lượng độ trễ của dự án

Bằng cách filter các task trễ start rồi sum số giờ estimate, bạn biết dự án đang trễ bao nhiêu tiếng (ví dụ 17 giờ). Với task trễ end đang ongoing, bạn lấy giờ estimate trừ giờ đã làm để biết cần thêm bao nhiêu giờ nữa. Cộng lại là tổng độ trễ sơ bộ — cơ sở để quyết định hành động.

▸ 2. Các phương án đối ứng khi trễ

Khi dự án trễ, có mấy hướng recover:

• Tăng cost: overtime, thêm người vào dự án.
• Kéo time: xin khách hàng giãn schedule.
• Giảm scope: vì schedule thường đã cứng, đây là cách khả thi nhất.

Mẹo quan trọng khi giảm scope: không loại bỏ chức năng mà giảm ở mức functionality — vẫn test đủ 15 function nhưng ở mức đảm bảo chạy được, ưu tiên bug severity cao / mandatory trước, tạm gác các bug độ ưu tiên thấp. Nhờ đó scope co lại vừa đủ để kịp tiến độ.

▸ 3. Hai dấu hiệu cần đọc từ dữ liệu

• Trễ tập trung ở một người: task của người đó kéo lê liên tục — thường do performance chưa đáp ứng khối lượng công việc.
• Trễ toàn bộ dự án: đây là lúc phải xem lại plan / schedule tổng thể, vì kế hoạch không bao giờ trùng thực tế 100%.

Với file Excel, bạn chỉ cần filter và nhìn màu sắc là nhận ra ngay. Các bài sau sẽ dựng dashboard tổng hợp status để nhìn toàn cảnh dự án.

Chương 7 · Bài 1

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

Cost là tất cả các khoản phải chi ra để hoàn thành dự án. Bài học định nghĩa chi phí và chỉ ra rằng với PM phần mềm — nhất là trong ngành outsourcing — chi phí được quản lý chủ yếu qua ngày công (man-month) của nhân sự, vì mọi thứ cuối cùng đều quy về tiền. Điểm mấu chốt: mỗi loại nhân sự có một mức chi phí khác nhau, và đó là thứ bạn cần theo dõi.

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

• Hiểu cost là mọi khoản chi ra để hoàn thành dự án, chủ yếu là chi phí nhân lực.
• Biết vì sao ngày công (man-month) là đơn vị quản lý chi phí phổ biến của PM.
• Nắm được các loại chi phí và nhân sự cần phân biệt khi tính cost.

─── NỘI DUNG CHÍNH

▸ 1. Chi phí là gì?

Chi phí là những khoản phát sinh, những khoản phải chi ra để giúp bạn hoàn thiện dự án. Với PM outsourcing, hầu hết không quản lý chi tiết doanh thu / giá cả với khách hàng, mà tập trung vào ngày công của nhân viên — bao nhiêu ngày công thì tương ứng bấy nhiêu tiền lương, tất cả đều quy về tiền.

▸ 2. Các loại chi phí

Ngoài lương là chính, dự án còn phát sinh các loại chi phí khác:

• Thuê người ngoài làm design hoặc phần việc khó.
• Nhờ một nhân sự level cao trong công ty support vài ngày.

Công ty thường lập một thang bậc chi phí riêng cho từng loại nhân sự để dự án vận hành theo khung chung.

▸ 3. Thông tin cần quản lý: ngày công theo loại nhân sự

Trọng tâm quản lý cost là ngày công làm việc, nhưng phải phân biệt theo loại nhân sự vì mỗi loại có giá khác nhau: nhân viên chính thức, part-time, sinh viên thực tập. Ví dụ dự án 5 man-month gồm 3 người chính thức và 2 sinh viên thực tập thì hai nhóm này có chi phí khác nhau, phải tính riêng. Cách ứng dụng Excel để tính và theo dõi những con số này sẽ được hướng dẫn ở các bài sau.

Chương 7 · Bài 2

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

Bài thực hành dựng sheet Cost Management trong Excel để tính chi phí và lợi nhuận của dự án. Bài phân biệt hai kiểu PM (biết chi phí lương / chỉ biết man-month), hướng dẫn lập bảng chi phí theo kế hoạch – thực tế, và một bảng tính lương riêng theo số ngày công. Điểm mấu chốt: chỉ cần một bảng đơn giản, tách bạch tiền và chữ, là tính được dự án lời hay lỗ.

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

• Dựng được bảng cost quản lý theo danh mục, số tiền kế hoạch và thực tế.
• Biết quy đổi ngày công ra man-month và tính lương theo số ngày làm việc.
• So sánh được lợi nhuận theo kế hoạch và lợi nhuận thực tế của dự án.

─── NỘI DUNG CHÍNH

▸ 1. Hai kiểu quản lý chi phí

Có hai dạng PM: một dạng nắm được toàn bộ chi phí (lương nhân công, domain, hosting…) nên biết dự án lời/lỗ; một dạng chỉ biết man-month, không biết mức lương. Từ sheet Work Breakdown, bạn sum tổng số ngày rồi chia cho 20 để ra man-month (ví dụ 37.5 ngày ≈ 1.87 man-month).

▸ 2. Bảng cost theo kế hoạch – thực tế

Bảng Cost Management gồm: số thứ tự, danh mục (lương, domain, hosting, laptop…), hạng mục, số tiền, ngày chi dự kiến và thực tế, người chi, nội dung, ghi chú. Danh mục được chuẩn hóa bằng Data Validation → List. Bạn nhập kế hoạch chi (lương từng tháng, domain, hosting), tính tổng budget, rồi so với số tiền khách hàng trả để ra lợi nhuận theo kế hoạch (theo %). Khi có số liệu thực tế, bạn tính lại lợi nhuận thực tế để đối chiếu.

▸ 3. Bảng tính lương theo ngày công

Với dự án nhiều người, cần một bảng lương ở mức khái niệm gồm: mã nhân viên, họ tên, lương tháng, ngày bắt đầu / kết thúc effort, số ngày làm việc và số tiền. Các công cụ và ý tưởng chính:

• Lương ngày = lương tháng chia cho số ngày công chuẩn trong tháng.
• Hàm NETWORKDAYS để đếm số ngày làm việc thực tế giữa hai mốc ngày.
• Dùng IF để chặn trần: nếu số ngày vượt ngưỡng ngày công chuẩn thì tính theo ngưỡng, ngược lại tính theo số ngày thực.

Mấu chốt: nắm ý tưởng bảng tính hơn là các con số minh họa — tách bạch dữ liệu để tính được chi phí lương và biết dự án đang lời hay lỗ.

Chương 7 · Bài 3

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

Bài case study chia sẻ những kinh nghiệm "xương máu" khi quản lý chi phí thực tế — thứ mà bảng tính đơn giản không thể hiện hết. Điểm mấu chốt: quản lý cost không chỉ là tính lương theo tháng, mà phải để ý độ trễ khi load / chuyển giao nhân sự, cách ứng xử với overtime, và hiểu khách hàng ưu tiên gì trước khi ra quyết định tăng cost.

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

• Biết những chi phí ẩn dễ bỏ sót: độ trễ khi nhân sự vào và rời dự án.
• Hiểu vì sao nên minh bạch chi phí và trả tiền overtime cho anh em.
• Biết đọc "buffer" lợi nhuận để quyết định action về mặt chi phí.

─── NỘI DUNG CHÍNH

▸ 1. Những chi phí ẩn cần để ý

Chi phí không chỉ tính tròn theo tháng mà phải chi tiết tới ngày, tới giờ. Nhân sự thường phải vào dự án sớm hơn một tuần đến tuần rưỡi để chuyển giao, và những ngày cuối tháng cũng có độ trễ chuyển giao. Đây là độ trễ cố định — khi estimate và báo giá, hãy tính luôn chi phí load người vào trước, đừng giả định người có mặt ngay đúng thời điểm.

▸ 2. Ứng xử minh bạch với chi phí và overtime

Vài nguyên tắc đạo đức nghề nghiệp giảng viên nhấn mạnh:

• Không đôn chứng từ: mua dịch vụ 5 triệu thì báo khách 5 triệu, đừng khai 10 triệu để ăn chênh lệch.
• Trả tiền overtime cho anh em: cắt tiền OT để đẹp KPI sẽ làm down motivation, anh em không còn muốn overtime nữa. Phần chi phí đó nên để công ty xử lý.

▸ 3. Hiểu khách hàng ưu tiên gì và đọc buffer lợi nhuận

Khách hàng thường chỉ quan tâm dự án có nằm trong budget hay không. Khách ngành ngân hàng nhiều tiền → ưu tiên quality, có thể tăng cost để tăng chất lượng. Khách nhỏ lẻ → nhạy cảm với cost, đừng tùy tiện tăng. Cuối cùng, hãy lập một bảng so sánh lợi nhuận kế hoạch với thực tế để đọc ra phần buffer: nếu plan lãi 19% mà thực tế cao hơn, phần dư chính là khoản dự phòng để bạn action (thuê thêm người, thuê dịch vụ) khi có sự cố mà vẫn còn lợi so với kế hoạch.

Trong Excel, chỉ cần tách bạch "cái nào tiền để riêng, cái nào chữ để riêng" là tính rất dễ, không có gì phức tạp.

Chương 8 · Bài 1

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

Trước khi dùng Excel để quản lý chất lượng, bạn cần thống nhất quality trong dự án phần mềm là gì. Bài học làm rõ một điểm mấu chốt dễ hiểu sai: đạt chất lượng không phải là cố nâng lên vượt mong đợi bằng mọi giá, mà là làm tốt nhất có thể trong phạm vi cho phép về thời gian, chi phí và scope. Chạy theo chất lượng quá mức sẽ kéo dài schedule và đội chi phí.

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

• Hiểu quality là "đạt tiêu chí khách hàng mong muốn" nhưng vẫn nằm trong ràng buộc time – cost – scope.
• Biết vì sao PM phải matching định nghĩa chất lượng của mình với định nghĩa của khách hàng.
• Nắm vai trò của PM: đo đạt, quản lý được chất lượng và ra action cải thiện trước khi delivery.

─── NỘI DUNG CHÍNH

▸ 1. Chất lượng phải nằm trong phạm vi cho phép

Một sản phẩm đạt chất lượng là khi nó đầy đủ, đúng và chính xác nhất cho khách hàng — nhưng trong giới hạn thời gian, tiền bạc và scope. Ví dụ trong một khoảng time chỉ đủ để làm 5 màn hình chạy tốt và integration được với nhau; nếu tham làm 10 màn hình cùng mức chất lượng thì thực tế không kịp. Đặt thêm nhiều quy trình để nâng chất lượng là tốt, nhưng song song schedule sẽ kéo dài và chi phí tăng lên.

▸ 2. Định nghĩa chất lượng phải khớp với khách hàng

Với người dùng, "chất lượng" gồm nhiều mặt: deliver nhanh hay chậm, đúng schedule không, sản phẩm dùng được không, tỷ lệ bug có nằm trong NORM cho phép không. Nhưng nhiều khách hàng không quan tâm tới NORM hay chỉ số bug — họ chỉ cần thấy hài lòng khi dùng. Vì vậy PM phải matching định nghĩa của mình với định nghĩa của khách hàng, rồi đo đạt, báo cáo và trình bày số liệu sao cho khách hàng hiểu là chất lượng đã đạt hay chưa.

▸ 3. PM quản lý chất lượng như thế nào

Chất lượng được đo từ nhiều phía: QA đo theo chỉ số NORM của công ty, QC test theo cảm nhận, developer cũng có góc nhìn riêng. PM tổng hợp lại, dựa trên chỉ số để biết được và quản lý được tình trạng, từ đó ra action cải thiện trước khi delivery. Khuyến cáo: chỉ nên đo những chỉ số cần thiết và khách hàng thực sự hiểu, không phải tự thích đo gì cũng đo. Chi tiết về chỉ số NORM đã có ở khóa học trước; bài này tập trung vào mindset định nghĩa chất lượng.

Chương 8 · Bài 2

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

Bài học thực hành tạo một sheet quản lý quality trong Excel để đo chất lượng từng file/màn hình. Ý tưởng cốt lõi: mọi chỉ số chất lượng đều so sánh giữa kế hoạch (plan) và thực tế (actual), và mỗi chỉ số có một khoảng cho phép giữa cận dưới (LCL) và cận trên (UCL). Nằm trong khoảng là đạt, vượt ra ngoài — thiếu hơn hoặc nhiều hơn — đều là điểm bất thường cần điều tra.

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

• Biết dựng bảng KPI chất lượng theo giai đoạn: coding review, testing, test case.
• Tính được ngưỡng cho phép với control limit (LCL / UCL) quanh giá trị plan bằng phần trăm chênh lệch.
• Dùng công thức IF và conditional formatting để tự đánh giá "OK / not good" và tô màu cảnh báo.

─── NỘI DUNG CHÍNH

▸ 1. Bảng KPI theo giai đoạn và đơn vị đo

Chất lượng được định nghĩa theo từng giai đoạn, mỗi giai đoạn có đơn vị (unit) riêng:

• Coding review: số bug bắt được trên 1000 LOC (line of code).
• Testing: số bug integration test, UAT (user acceptance test) trên 1000 LOC.
• Test case: số test case viết ra trên 1000 LOC.

Đây chính là các chỉ số trong Project Plan — bản kế hoạch dự án. Một số công ty không dùng LOC mà đo bằng khảo sát cảm tính "khách hàng thấy OK" — cũng là một cách.

▸ 2. Control limit: cận trên, cận dưới, điểm bình thường

Mỗi chỉ số plan luôn có một độ chênh lệch cho phép (ví dụ 10%). Từ giá trị bình thường, lấy trừ đi phần trăm chênh lệch ra lower control limit, cộng vào ra upper control limit. Bug tính bằng số nguyên nên thường round up. Nằm trong khoảng LCL–UCL là đạt chất lượng.

▸ 3. So sánh actual với plan và ra action

Đo LOC thực tế, đếm bug review thực tế, quy về cùng đơn vị (dùng quy tắc tam suất), rồi so với ngưỡng. Nếu bug bắt được thấp hơn LCL nghĩa là review thiếu bug — chưa chắc là tốt, có thể do người code giỏi nên phải giải trình cho QA; nếu cao hơn UCL thì sản phẩm nhiều lỗi, cần review lại. PM nhìn vào chỉ số này để phát hiện điểm bất thường và ra action.

▸ Mẹo: tự động hóa bằng IF và conditional formatting

Viết công thức IF so bug actual với LCL/UCL để tự in ra "not good" (quá ít / quá nhiều) hay "ok". Sau đó dùng conditional formatting với hàm LEFT đọc 2 ký tự đầu ô nhận xét: "not good" tô đỏ chữ trắng, "ok" tô xanh — nhìn phát hiện vấn đề ngay. Lưu ý: IF dùng được trên cả Excel cũ; trên Google Sheets có thể dùng IFS.

Chương 8 · Bài 3

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

Đây là bài chia sẻ case study thực tế: chỉ số chất lượng trên Excel chỉ là một góc nhìn để phán đoán, không phải sự thật tuyệt đối. Điểm mấu chốt: quản lý chất lượng phải phòng cháy hơn chữa cháy — đo sớm, đo từng phần deliver, phân tích sâu tới loại bug, và lắng nghe cả team chứ đừng chỉ tin vào một view của PM.

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

• Biết vì sao chỉ đếm số lượng bug là chưa đủ, phải phân tích thêm loại bug (layout vs logic).
• Hiểu tinh thần đo chất lượng sớm theo từng phần deliver, gắn với sprint review và retrospective của Scrum.
• Biết cách huy động input từ nhiều phía để tìm đúng gốc rễ vấn đề chất lượng.

─── NỘI DUNG CHÍNH

▸ 1. Chỉ số chỉ là một góc nhìn — phải phân tích sâu hơn

Dựa vào số lượng LOC hay số bug để phán đoán chất lượng chỉ là một mô hình. Thực tế có khi chỉ số nội bộ toàn "OK" nhưng khách hàng bắt bug rất nhiều. Khi đó phải đi sâu thêm một bước: phân tích loại bug. Ví dụ 10–20 bug nhưng toàn bug layout, thiếu bug logic — mà bug logic mới ảnh hưởng cả hệ thống; khách hàng thấy nhiều bug logic sẽ nghĩ team không test. Nên tạo thêm một file phân tích chi tiết loại bug.

▸ 2. Phòng cháy hơn chữa cháy: đo sớm, đo từng phần

Nếu đợi tới lúc cuối mới đo thì "chuyện đã rồi" — thấy 10 bug cũng đã muộn. Cách làm hiện nay là deliver từng màn hình, từng phần; deliver phần nào là đo phần đó và có action ngay. Gắn với mô hình Scrum: mỗi sprint có sprint review để xem action cải thiện, và retrospective để đúc kinh nghiệm cho sprint sau tốt hơn. Đo đạt lúc production mà không hành động kịp thì gần như không mang lại giá trị.

▸ 3. Lắng nghe input từ nhiều phía

Đừng tự tin rằng một view quản lý của PM là đủ để đánh giá. Khi có vấn đề chất lượng, kéo team vào, phát huy sức mạnh tập thể: training cách đo số, cách thống kê, rồi lắng nghe ý kiến của team. Nhiều bug chưa chắc do dev — có khi do nhiệm vụ không rõ, hoặc bản thân khách hàng không rõ ràng (xác nhận A nhưng lúc bắt bug lại nói B). Dự án càng lớn PM càng không nắm hết chi tiết bên trong; nhiệm vụ của PM là collect số liệu, trình bày để anh em focus vào đúng chỗ cần fix.

Chương 9 · Bài 1

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

Mở đầu Chương 9 về quản lý Human Resource (con người, nhân công) của dự án. Bài học giải thích vì sao công ty dùng hệ số quy đổi thay cho lương thật của từng người, và cách gán effort (hệ số chi phí) cùng năng suất cho từng loại hợp đồng. Điểm mấu chốt: PM thường không biết lương thật của thành viên, nên quản lý qua hệ số để nhẹ đầu và tránh mâu thuẫn nội bộ.

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

• Phân biệt 3 loại hợp đồng: chính thức, dịch vụ, cộng tác viên / thực tập.
• Hiểu hệ số quy đổi effort (ví dụ chính thức = 1, thực tập = 0.25) và vì sao nó không thể hiện giá tiền.
• Biết gán năng suất (productivity) riêng cho từng người để tính effort allocate vào dự án.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao dùng hệ số thay cho lương thật

PM thường không được biết mức lương của từng nhân viên, thậm chí có developer lương cao hơn cả PM. Nếu biết lương của nhau dễ sinh mâu thuẫn ("mày lương thấp hơn tao sao quản tao"). Vì vậy công ty chọn cách quy đổi ra hệ số — quản lý qua hệ số thì PM nhẹ đầu hơn vì không đụng tới tiền.

▸ 2. Ba loại hợp đồng và hệ số effort

• Hợp đồng chính thức: hệ số thường bằng 1.
• Hợp đồng dịch vụ: thường bằng 1 (có công ty để 0.5).
• Cộng tác viên / sinh viên thực tập (internship): bằng 0.5 hoặc 0.25.

Hệ số này là đơn vị chi phí quy đổi, không thể hiện giá tiền cụ thể — cùng hệ số 1 vẫn có người rất cao và người bình dân.

▸ 3. Năng suất từng thành viên

Ngoài hệ số effort, mỗi người còn có năng suất riêng: nhân viên chính thức thường tính 100% (bằng 1), cộng tác viên / thực tập khoảng 25%, dev mới có thể 50–75%, dev lâu năm làm tốt là 100%. Kết hợp loại hợp đồng, hệ số, năng suất cùng thời gian tham gia (start – end) của từng người, PM tính ra được năng suất mỗi người và biết effort allocate vào dự án là đủ, thiếu hay phù hợp. Các thông số này phải theo khung của công ty / tổ chức. Bài này mới ở mức lý thuyết; phần sau sẽ thực hành chi tiết.

▸ Lưu ý: chỉ apply những gì phù hợp

Không phải công ty nào cũng quản lý sâu tới mức này. Tùy tổ chức mà bạn chọn áp dụng phần phù hợp — công ty nhỏ quản lý ở mức đơn giản, tổ chức lớn thì đi sâu và xa hơn. Đó là lý do nội dung được tách riêng thành nhiều phần.

Chương 9 · Bài 2

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

Bài học định nghĩa billable effort — số đơn vị công sức mà khách hàng trả tiền cho mình, thường tính bằng MM (man-month). Điểm mấu chốt: billable là con số effort theo ngày công, không phản ánh trực tiếp tiền; muốn ra tiền phải nhân với unit price (đơn giá). Cùng một billable, tổng tiền sẽ khác nhau tùy cách công ty định giá.

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

• Hiểu billable effort là gì và vì sao nó độc lập với chi phí bằng tiền.
• Biết từ tổng billable và thời gian dự án suy ra số người cần mỗi tháng (human resource).
• Nắm 3 hình thức quy đổi billable ra giá tiền của dự án.

─── NỘI DUNG CHÍNH

▸ 1. Billable effort và cách suy ra nhân lực

Billable là tổng effort khách hàng trả, ví dụ một dự án có billable 20 MM làm trong 5 tháng. Lấy 20 chia 5 ra khoảng 4 người/tháng — đó là human resource cần bố trí. Bản thân con số billable không cho biết budget bằng tiền là bao nhiêu.

▸ 2. Ba hình thức tính ra giá tiền

• Hình thức 1 — đổ đồng theo MM: quy ước 1 MM = một đơn giá cố định (ví dụ 25 triệu). Budget = đơn giá × tổng MM. Cách này nhanh, mọi role tính cùng một giá.
• Hình thức 2 — nhân đơn giá theo ngày công: mỗi phần việc nhân unit price cho ngày công rồi cộng lại ra tổng tiền, tính theo từng phần.
• Hình thức 3 — rã theo role: chia 20 MM ra cho từng role (dev level 1, dev level 2, test, PM, comtor), mỗi role một đơn giá riêng, nhân ra rồi SUM tổng lại thành budget. Cách này chi tiết hơn theo từng role và từng giá tiền.

▸ 3. Billable tách bạch với tiền

Điểm cần nhớ: billable effort là con số cố định theo ngày công / MM. Còn số tiền phụ thuộc unit price — thay đổi đơn giá thì tiền đổi, nhưng billable không đổi. Vì vậy khi quản lý nhân sự, PM làm việc trên billable (MM) để đơn giản, còn việc quy ra tiền là bước tách riêng tùy cách định giá của công ty.

Chương 9 · Bài 3

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

Bài học giới thiệu calendar effort — effort tính theo lịch làm việc thực tế của thành viên trong dự án. Khác với billable (luôn chia cho 20 ngày/tháng cho đơn giản), calendar phải tính chính xác số ngày công theo từng tháng, vì mỗi tháng có số ngày làm việc khác nhau. Điểm mấu chốt: calendar phản ánh sát thực tế hơn, và cần chừa một khoảng dự trù cho ngày nghỉ.

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

• Phân biệt billable effort (chia đều cho 20) và calendar effort (tính theo lịch thật từng tháng).
• Biết dùng hàm EOMONTH để lấy ngày cuối tháng và ước số ngày làm việc chuẩn của tháng.
• Hiểu vì sao nên chừa khoảng dự trù effort thay vì cố lấp đầy đúng 100%.

─── NỘI DUNG CHÍNH

▸ 1. Calendar effort là gì

Nếu làm từ thứ 2 đến thứ 6 thì mỗi tuần là 5 working day; đó là lịch mình assign người vào dự án — gọi là calendar effort. Một tuần 5 ngày, nhưng mỗi tháng lại có 20, 21 hoặc 22 ngày làm việc, nên calendar phải tính theo từng tháng để ra con số sát thực. Trong khi đó billable luôn quy ước chia cho 20 ngày (160 giờ công) cho đơn giản.

▸ 2. Tính calendar effort bằng Excel

Với mỗi thành viên, khai báo loại hợp đồng, hệ số, ngày start và end. Dùng hàm EOMONTH (đối số thứ hai là 0) để lấy ngày cuối tháng, từ đó ra số ngày làm việc chuẩn của tháng. Số ngày công của mỗi người chia cho 20 sẽ quy về đơn vị MM. Cộng calendar effort của cả đội bằng SUM ra tổng effort đã dùng, đối chiếu với billable kế hoạch để biết đang lời (dùng ít hơn) hay lỗ (dùng nhiều hơn) so với 20 MM dự kiến. Có thể thêm/bớt người rồi xem tổng thay đổi để cân đội hình.

▸ Lưu ý quan trọng: chừa khoảng dự trù cho ngày nghỉ

Đừng cố tính sát nút để lấp đầy đúng bằng billable. Thực tế không nhân viên nào làm đúng 8 tiếng × 20 ngày liên tục nhiều tháng không nghỉ — luôn có người nghỉ 1–2 ngày, bận gia đình, con cái. Vì vậy nên để dư một khoảng effort (khoảng nửa tới một MM) làm "khoảng thở" để khi có người nghỉ vẫn recover và bù lại được, giữ kế hoạch hợp lý hơn.

Chương 9 · Bài 4

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

Bài học định nghĩa chỉ số Effort Efficiency (EE) — thước đo hiệu quả sử dụng nguồn nhân lực — bằng công thức EE = billable / calendar. Điểm mấu chốt: EE cho biết bạn đang dùng người nhiều hơn hay ít hơn so với kế hoạch. EE thấp nghĩa là xài nhiều hơn plan; EE cao nghĩa là xài ít hơn. Nhiều công ty quy định EE phải giữ từ 85% trở lên.

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

• Nắm công thức EE = bill / calendar và cách quy về hệ số phần trăm.
• Đọc được ý nghĩa EE thấp / EE cao so với kế hoạch dùng người.
• Biết EE được đo ở hai mức: tổng thể dự án và từng thời điểm (từng tháng).

─── NỘI DUNG CHÍNH

▸ 1. Công thức và cách tính EE

EE bằng billable chia cho calendar, nhân 100 để ra hệ số phần trăm. Ví dụ dự án billable 20 MM, kế hoạch 4 người/tháng trong 5 tháng. Khi allocate thực tế, mỗi tháng calendar có thể khác plan (4, 5, 6, 2, 3 người tùy tình hình dự án cháy hay bớt cháy), nhưng nếu tổng calendar vẫn bằng 20 MM thì EE tổng = 100% — làm đúng kế hoạch, đúng chi phí, đạt tiến độ.

▸ 2. Đọc ý nghĩa EE

• EE thấp (dưới 100%): calendar cao hơn bill → đang dùng nhiều người hơn so với kế hoạch.
• EE cao (trên 100%): calendar thấp hơn bill → đang dùng ít người hơn so với kế hoạch.

Chỉ số này giúp PM biết mình đang chạy đúng, over hay dưới kế hoạch tại mỗi thời điểm.

▸ 3. EE gắn với loại hợp đồng và KPI của PM

Cách bố trí người phụ thuộc loại hợp đồng: hợp đồng Fixed Price (khách chỉ quan tâm một cục tiền, còn lót bao nhiêu người là việc nội bộ) khác với hợp đồng ODC / Labo (Offshore Software Development Center). Nội bộ vẫn phải lập plan đổ người hợp lý theo từng tháng. EE nhiều khi nằm trong KPI đánh giá PM — công ty quy định phải giữ EE trong một khoảng (ví dụ từ 85% trở lên), dưới ngưỡng coi như lỗ. Vì vậy PM cần đo EE cả tổng thể lẫn từng thời điểm, và làm plan đổ người sao cho hợp lý nhất.

Chương 9 · Bài 5

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

Bài thực hành dựng một file Excel tính EE chi tiết ở ba mức: từng tháng, từng giai đoạn và toàn bộ dự án. Khác với bài trước chỉ điền số tổng, ở đây bạn allocate từng người theo ngày thật (start – end) và để file tự tính lại EE khi thay đổi. Điểm mấu chốt: muốn cộng calendar theo tháng thì phải tạo một cột key tháng làm mốc chung.

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

• Tính calendar effort từng người bằng NETWORKDAYS có trừ ngày lễ (holiday).
• Rã dữ liệu ra từng tháng và dùng key tháng (qua EOMONTH) để gộp số liệu.
• Dùng SUMIF và VLOOKUP để tính EE từng tháng tự động, thay đổi phân bổ là số nhảy theo.

─── NỘI DUNG CHÍNH

▸ 1. Từ plan cơ bản đến allocate chi tiết

Trước hết hình dung plan tổng: dự án 20 MM, 5 tháng, khoảng 4 người/tháng — phác thảo mỗi tháng lót bao nhiêu người sao cho tổng vẫn bằng 20 MM. Sau đó lập danh sách thành viên thật (Dev A, Dev B, Test C…) với ngày start và end dự kiến của từng người.

▸ 2. Tính calendar bằng NETWORKDAYS và EOMONTH

Dùng NETWORKDAYS(start, end, holiday) để ra số working day thật, có trừ danh sách ngày nghỉ lễ (nhớ pin vùng holiday bằng F4). Chia số working day cho 20 để quy về MM — đó là calendar effort. Dùng EOMONTH để lấy ngày cuối tháng khi cần rã một người ra làm nhiều dòng theo từng tháng. Cộng lại bằng SUM để so tổng calendar với billable (biết đang hơn hay kém kế hoạch).

▸ 3. Tính EE từng tháng bằng key, SUMIF, VLOOKUP

Để gộp theo tháng, tạo cột key tháng: luôn quy về ngày cuối tháng bằng EOMONTH (dù người đó bắt đầu giữa tháng), tránh sai lệch khi ngày rơi vào giữa tháng. Lấy bill theo tháng bằng VLOOKUP trên bảng plan, lấy calendar theo tháng bằng SUMIF trên cột calendar theo đúng key. Cuối cùng EE tháng = bill / calendar × 100. Nhờ để file động, khi bạn chỉnh ngày kết thúc của một người hoặc insert thêm một dòng (ví dụ thêm technical leader support 2 tuần), EE của tháng liên quan tự nhảy theo — rất tiện để quản lý resource chi tiết.

▸ Lưu ý: luôn phải có cột key

Không có key thì không gộp (SUMIF/VLOOKUP) được. Nên tô màu riêng cột key (ví dụ màu vàng) để nhớ không xóa nhầm. Phần format, tô màu chỉ là bước làm đẹp cuối cùng; quan trọng là hiểu và ứng dụng được cách tính.

Chương 9 · Bài 6

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

Bài chia sẻ kinh nghiệm thực tế khi quản lý EE (Effort Efficiency). Điểm mấu chốt: trước khi bàn tới con số EE, PM phải nắm được bối cảnh — dự án được cấp bao nhiêu người, estimation thật là bao nhiêu MM, và vì sao. Trong thị trường cạnh tranh hiện nay, EE thấp (dùng nhiều người hơn kế hoạch) là chuyện thường; và EE không phản ánh toàn bộ bức tranh chi phí bằng tiền.

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

• Hiểu ba điều nền tảng cần rõ trước khi quản lý EE: chi phí, bối cảnh tổ chức, con số estimation thật.
• Đọc được ý nghĩa thực tế của EE thấp / EE cao / EE đúng và ngưỡng chấp nhận được.
• Biết vì sao EE không phản ánh được đầy đủ chi phí bằng tiền của dự án.

─── NỘI DUNG CHÍNH

▸ 1. Nắm bối cảnh trước khi bàn con số

Nhiều PM chưa kinh nghiệm chỉ lo làm xong dự án mà không biết bill, calendar hay chi phí dự án tốt hay xấu. Cần rõ ba điều: chi phí (dự án lời hay lỗ để chủ động chiến thuật), bối cảnh tổ chức (nhiều khi công ty nhận dự án 30 MM nhưng chỉ báo giá 20 MM để cứu việc cho anh em, rồi ép team chạy "tét khói", OT liên tục do estimation thấp), và con số estimation thật là bao nhiêu MM. Rõ hết những điểm này rồi mới đi vào quản lý allocate chi tiết.

▸ 2. Ý nghĩa thực tế của EE thấp, cao, đúng

• EE thấp: calendar cao → dùng nhiều người hơn kế hoạch. Rất phổ biến vì báo giá cạnh tranh phải để giá thấp, cộng hao hụt do communication (tiếng Nhật, tiếng Anh) và người không phải lúc nào cũng giỏi đúng 100%. Kinh nghiệm: EE từ 80% trở lên là ổn, trên 90% đã khó.
• EE cao: calendar thấp hơn bill → thường phản ánh dự án đang thiếu người, hiếm khi là đang lời. Ngày xưa còn gặp, nay cạnh tranh khốc liệt nên hiếm.
• EE đúng: hay gặp ở dự án maintain / Labo lâu dài — khách order 3 người, mình làm đúng 3 người. Dự án Fixed Price thì thường khó đạt EE đúng.

▸ 3. EE không phản ánh hết chi phí bằng tiền

EE tính theo bill và calendar (quy về MM) nên đơn giản hóa cho PM, nhưng không phản ánh toàn bộ chi phí bằng tiền. Lý do: lương mỗi người mỗi khác, giá bán mỗi khách mỗi khác, và công ty thường không cho PM biết lương từng người (có khi dev cứng lương cao hơn cả PM, rất tế nhị và khó quản). Ngoài lương còn bảo hiểm xã hội, OT, tiền ăn, đi lại… nên chi phí bằng tiền phức tạp, thuộc phần kết toán riêng. Vì vậy PM chỉ quản lý ở mức EE, bill, calendar — vẫn ok để dùng, nhưng cần hiểu nó không vẽ được toàn bộ bức tranh tiền bạc.

Chương 10 · Bài 1

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

Trước khi dùng Excel để quản lý rủi ro và vấn đề, bạn cần phân biệt rõ hai khái niệm này. Điểm mấu chốt rất đơn giản: risk (rủi ro) là điều CHƯA xảy ra, còn issue (vấn đề) là điều ĐÃ xảy ra. Đây là chương số 10, mở đầu cho phần quản lý risk/issue trong dự án phần mềm.

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

• Phân biệt được risk và issue qua tiêu chí "đã xảy ra hay chưa xảy ra".
• Hiểu các phương án ứng xử với issue và với risk khác nhau ra sao.
• Nắm được những thông tin cần quản lý cho một rủi ro.

─── NỘI DUNG CHÍNH

▸ 1. Risk và Issue khác nhau ở điểm nào?

Giảng viên dùng một ví dụ đời thường: bạn đi làm gặp trời mưa.

• Issue là trời đã mưa rồi mà bạn không mang áo mưa — bạn bị ướt, hỏng điện thoại/laptop, tốn chi phí, lỡ cả cuộc họp với khách hàng. Vấn đề đã phát sinh.
• Risk là trời mới chuyển mây, chưa mưa. Bạn phán đoán "có thể lát nữa sẽ mưa" và cân nhắc: quay về lấy áo mưa, hay cứ chạy thẳng đến công ty.

▸ 2. Cách xử lý issue và risk

Với issue (đã xảy ra) thì chỉ có một phương án duy nhất: xử lý nó. Nếu không xử lý, nó ảnh hưởng rất lớn đến kế hoạch và tốn nhiều chi phí, kéo theo nhiều impact khác.

Với risk (chưa xảy ra) bạn có hai lựa chọn: một là không quan tâm, chừng nào nó xảy ra thì xử lý; hai là dự trù trước (mua/mang áo mưa) — nhưng dự trù thì đã tốn chi phí ngay.

▸ 3. Các thông tin cần quản lý về một rủi ro

Để quản lý risk, bạn ghi nhận: mô tả rủi ro, danh mục (liên quan con người, môi trường...), ảnh hưởng tới yếu tố nào (schedule/time, cost, quality của dự án), rồi đánh giá mức độ. Cụ thể là cho điểm impact (độ ảnh hưởng, ví dụ thang 1–10) và probability (khả năng xảy ra). Bài sau sẽ đi vào ví dụ chi tiết hơn.

Chương 10 · Bài 2

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

Đây là bài thực hành: bạn tự tay dựng trong Excel hai bảng riêng — Issue List và Risk List — để quản lý vấn đề và rủi ro của dự án. Điểm mấu chốt: vì risk và issue là hai thứ khác nhau (một cái đã xảy ra, một cái chưa) nên phải tách chúng ra làm hai bảng với các cột thông tin khác nhau.

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

• Thiết kế được bảng Issue List với đầy đủ cột quản lý một vấn đề.
• Thiết kế được bảng Risk List với impact và probability để ưu tiên xử lý.
• Biết dùng Data Validation lấy danh mục/trạng thái từ sheet Config.

─── NỘI DUNG CHÍNH

▸ 1. Bảng Issue List

Tạo một sheet mới đặt tên Risk/Issue Management. Bảng Issue List gồm các cột: Category (danh mục), mô tả issue, Action (hành động khắc phục) và người thực hiện, Status (trạng thái), người tạo/người phát hiện, kế hoạch (ngày bắt đầu, ngày kết thúc dự kiến), ước lượng (tính theo giờ) so với thực tế, và ghi chú.

Danh mục issue có thể theo file/giai đoạn (design, coding, testing, deployment, UAT) hoặc theo loại vấn đề (human resource, technical, environment, training, other). Trạng thái và danh mục nên đặt bằng Data Validation → List trỏ sang sheet Config để chọn nhanh, tránh gõ tay sai.

▸ 2. Bảng Risk List

Copy bảng issue xuống làm Risk List nhưng thiết kế khác một chút. Risk chưa xảy ra nên không có ngày bắt đầu/kết thúc — chỉ ghi chú trước; khi nó xảy ra thì chuyển thành issue. Các cột đặc trưng của risk: mô tả risk, action plan (hành động dự kiến), probability (khả năng xảy ra: thấp dưới 50%, vừa khoảng 50%, cao trên 80%) và impact (ảnh hưởng tới schedule/cost/quality).

▸ 3. Ưu tiên xử lý và cộng chi phí

Khi nhìn vào bảng, bạn focus vào các risk khả năng xảy ra cao để ra action plan trước (ví dụ hỏi rõ khách hàng sớm, tuyển người backup). Lưu ý quan trọng: nếu cách xử lý phát sinh chi phí (như tuyển người thay thế) thì phải cộng chi phí đó vào dự án — dù nhiều công ty chấp nhận share nội bộ để không ảnh hưởng KPI của PM.

Chương 10 · Bài 3

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

Bài chia sẻ kinh nghiệm thực chiến: những rủi ro thường gặp nhất khi làm dự án phần mềm thực tế và cách đối phó. Điểm mấu chốt giảng viên nhấn mạnh: quản lý risk/issue nói lý thuyết thì dễ, nhưng làm thực tế khá khó — và sức mạnh lớn nhất để xử lý chính là sự minh bạch, chia sẻ với cả team.

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

• Nhận diện được các nhóm rủi ro phổ biến khi làm dự án thực tế.
• Biết tổ chức đội hình dự án hợp lý ngay từ giai đoạn đầu.
• Hiểu vì sao chia sẻ risk/issue minh bạch giúp giảm gánh nặng cho PM.

─── NỘI DUNG CHÍNH

▸ 1. Các nhóm rủi ro thường gặp

• Rủi ro từ requirement của khách hàng: dự án nhỏ khách hàng ít tài liệu, chia sẻ mà mình không hiểu hết ý (do ngoại ngữ, do nghiệp vụ business không rành, thiếu BA).
• Chạy theo estimate ban đầu mà không re-estimation, không dự trù chi phí — cấp trên giao bao nhiêu man-month thì làm cứng bấy nhiêu.
• Rủi ro về con người: thành viên có personal plan, có thể nghỉ; tuyển người mới lại kéo theo issue về cost.
• Rủi ro nghiệm thu: nhiều bên liên quan, không rõ ai là bên chính. Cần định nghĩa kỹ objective, stakeholder, product owner ngay từ đầu.

▸ 2. Tổ chức đội hình dự án

Khi load người vào mà họ chưa đủ kỹ năng, họ chạy task rất nhanh nhưng ra kết quả lẻ tẻ, không verify được output có xài được hay không — code lẹ nhưng tới lúc test thì đầy lỗi. Kinh nghiệm: giai đoạn đầu nên chọn người khá một chút; khi dự án ổn định mới thay đổi mô hình đội hình.

▸ 3. Kinh nghiệm quan trọng: phát huy sức mạnh tập thể

Khi có risk hay issue, hãy chia sẻ cho cả team dự án cùng biết — mọi thứ phải transparent, minh bạch từ cái nhỏ nhất đến cái lớn nhất. Anh em trong dự án sẽ giúp bạn rất nhiều: có người biết framework đang dùng đã xử lý sẵn vấn đề đó, hoặc chủ động xử lý luôn. Cách này nhẹ hơn rất nhiều so với việc PM handle một mình.