Khóa học ứng dụng Google Sheets 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Ì?

Chương này trả lời câu hỏi "Tại sao" một Project Manager cần biết Google Sheets. Bài làm rõ bảng tính (spreadsheet) là gì, ý nghĩa và công dụng đúng của nó, cùng mức độ phổ biến rất lớn trong ngành phần mềm — để bạn thấy đây là công cụ gần như ai đi làm cũng phải dùng.

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

• Hiểu bảng tính là gì và các thành phần cơ bản (workbook, sheet, cột/dòng, vùng dữ liệu).
• Nắm được ý nghĩa và công dụng đúng của bảng tính so với file tài liệu.
• Thấy được mức độ phổ biến và ứng dụng của bảng tính trong quản lý dự án.

─── NỘI DUNG CHÍNH

▸ 1. Bảng tính là gì và ý nghĩa của nó

Bảng tính gồm cột và dòng; cả Excel lẫn Google Sheets đều là bảng tính. Excel thiên về offline (làm ở local), còn Google Sheets ngay từ đầu được phát triển hướng tới online nên thao tác trực tuyến chuyên dụng và mượt hơn. Bảng tính được tạo ra đúng nghĩa là để tính toán số liệu — note các giá trị, cộng trừ nhân chia, dùng công thức. Nếu chỉ để trình bày tài liệu thì nên dùng Google Docs / file Word cho đúng mục đích.

▸ 2. Thành phần và mức độ phổ biến

Một file Google Sheets là một Workbook, bên trong có các Sheets nhỏ và các vùng dữ liệu. Bảng tính phổ biến cực kỳ rộng trong ngành phần mềm: quản lý dữ liệu, viết tài liệu thiết kế (basic/detail/programming design), làm test case (dạng matrix hoặc từng dòng), viết guideline, và thống kê — báo cáo số liệu. Lưu ý: khi dữ liệu quá lớn, bảng tính sẽ chậm, nên cần tổ chức dữ liệu hợp lý (ví dụ tách file theo năm) để tránh treo.

▸ 3. Sức mạnh và ứng dụng trong quản lý dự án

Trong đời sống, dữ liệu đơn hàng online thường xuất ra CSV hoặc Google Sheets; nhiều bộ phận sale, trung tâm ngoại ngữ quản lý thu chi bằng Google Sheets. Trong dự án, hầu hết vai trò — PM, team leader, QA, QC, tester, developer — đều dùng bảng tính. Với quản lý dự án, bạn có thể quản lý scope, time, cost, quality, human resource, risk, issue ngay trên bảng tính. Vì độ phổ biến lớn như vậy, việc học và ứng dụng thành thạo Google Sheets là bắt buộc.

Chương 3 · Bài 1

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

Trước khi dùng Google Sheets để 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. Mấu chốt: 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 giới thiệu vòng đời của một dự án và các quy trình (mô hình) phần mềm thường gặp — Waterfall, V-Model và Scrum. Điểm mấu chốt: dù áp dụng mô hình nào, mục tiêu chung vẫ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 một dự án.
• Phân biệt được ở mức khái niệm các mô hình Waterfall, V-Model và Scrum.
• Hiểu vì sao mọi quy trình đều phải quản lý được cost, quality, time, scope.

─── NỘI DUNG CHÍNH

▸ 1. Vòng đời của một dự án

Vòng đời dự án gồm 5 giai đoạn: Initiating (khởi tạo — làm hợp đồng, lấy requirement ban đầu), Planning (lên kế hoạch chi phí, schedule, con người, scope), Executing (thực thi), Monitoring & Controlling, và Closing (đóng — chốt data, báo cáo các bên). Planning và Executing lặp qua lại liên tục vì trong lúc thực thi thường phải bổ sung, cập nhật kế hoạch. Monitoring & Controlling bao trùm mọi giai đoạn; có những việc (như giao tiếp giữa mọi người) khó control được nên chỉ monitor để theo dõi và xử lý khi phát sinh vấn đề.

▸ 2. Waterfall và V-Model

Waterfall là làm tuần tự từng bước, xong bước này mới sang bước khác. V-Model là bản mở rộng của Waterfall, chia nhỏ khâu testing để mỗi giai đoạn test tương ứ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 dễ kiểm soát và chất lượng tốt hơn.

▸ 3. Scrum và mô hình Hybrid

Scrum là mô hình phổ biến hiện nay. Requirement, user story, epic, task được đưa vào product backlog do Product Owner quản lý và cùng team định story point. Team chọn phần cần làm đưa vào sprint backlog, rồi qua các hoạt động sprint planning, daily scrum, sprint review, sprint retrospective trong các timebox nhất định. Trong một sprint không được thay đổi chen ngang và không được giảm quality. Ngoài ra còn có Hybrid — kết hợp các phần cần thiết của nhiều mô hình. Dù chọn mô hình nào, cái đích vẫn là quản lý được cost, quality, time, scope.

Chương 3 · Bài 3

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

Bài điểm qua các công cụ quản lý dự án phổ biến hiện nay và phân tích một điểm mấu chốt: hầu hết công cụ đều quản lý được time, cost, quality, nhưng để quản lý đầy đủ thì thường phải mua bản tính phí. Bản miễn phí bị giới hạn nhiều, nên đây là lý do các lựa chọn open source hoặc bảng tính trở nên hấp dẫn.

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

• Biết một số công cụ quản lý dự án thường gặp (Jira, Microsoft Project, Redmine…).
• Hiểu vì sao bản miễn phí thường không quản lý đủ time, cost, quality.
• Cân nhắc được hướng đi dùng open source hoặc Google Sheets/Excel để tự quản lý.

─── NỘI DUNG CHÍNH

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

Trên thế giới có rất nhiều công cụ quản lý dự án. Một số cái tên thường gặp: Jira (rất mạnh nhưng tính phí, bản miễn phí không đầy đủ), Microsoft Project (lên plan, tracking dự án tốt nhưng cần mua bản quyền), và Redmine — một mã nguồn mở (open source) miễn phí. Ngoài ra bạn hoàn toàn có thể dùng Google Sheets hoặc Excel để quản lý dự án.

▸ 2. Giới hạn của bản miễn phí

Điểm cần nhớ: để quản lý đầy đủ time, cost, quality, hầu hết công cụ bắt buộc bạn phải mua bản tính phí. Bản miễn phí thường bị giới hạn nhiều yếu tố, khó dùng trọn vẹn. Vì vậy nếu bạn không có ngân sách cho bản tính phí nhưng vẫn muốn quản lý dự án tốt, cần cân nhắc hướng đi khác.

▸ 3. Hướng đi với open source

Một lựa chọn hợp lý là tự xây dựng một hệ thống open source như Redmine. Bạn chỉ cần chịu khó học, rồi tự thiết kế và cấu hình hệ thống theo nhu cầu — kết quả thường tốt hơn nhiều so với dùng một hệ thống miễn phí bị giới hạn. Trong khóa học, Redmine đã được setup sẵn để bạn thực hành, và song song đó là hướng dẫn dùng Google Sheets/Excel để quản lý dự án.

Chương 3 · Bài 4

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

Bài chỉ ra những tính năng cơ bản mà mọi công cụ quản lý dự án đều phải có — dù là Jira, Trello, Backlog, hay chỉ là một file Excel/Google Sheets. Điểm mấu chốt: một công cụ được coi là hợp lý khi nó quản lý được scope, time, cost, quality; nếu chưa làm được thì bạn cần cân nhắc thay đổi.

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

• Nắm các tính năng nền tảng mọi công cụ quản lý dự án cần có.
• Biết tiêu chí để đánh giá một công cụ có phù hợp hay không.
• Hiểu vì sao Google Sheets/Excel hoặc Redmine vẫn có thể thay thế công cụ trả phí.

─── NỘI DUNG CHÍNH

▸ 1. Những tính năng cơ bản bắt buộc

Hầu hết các công cụ quản lý dự án đều giống nhau ở những điểm nền tảng: quản lý được dự án, quản lý và chia sẻ thông tin, và phân quyền truy cập — role nào có workflow nào, truy cập ra sao. Quan trọng nhất, công cụ phải quản lý được scope (phạm vi), time (tiến độ), cost (chi phí) và quality (chất lượng) của dự án.

▸ 2. Tiêu chí đánh giá một công cụ

Khi bạn áp dụng một công cụ hay hệ thống mà nó chưa quản lý được các yếu tố scope, time, cost, quality thì chứng tỏ nó chưa hợp lý và bạn nên thay đổi. Ngược lại, ngay cả 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ý đủ 4 yếu tố này — thì cũng coi như thành công.

▸ 3. Trả phí, open source hay tự dựng bằng bảng tính

Với các công cụ như Jira, Backlog, muốn dùng đủ tính năng để quản lý 4 yếu tố trên thường phải mua bản tính phí; bản miễn phí luôn bị giới hạn và khó tính toán. Vì vậy khóa học giới thiệu thêm Redmine (open source, cấu hình khá dễ) và hướng dẫn dùng Excel / Google Sheets để quản lý dự án mà không cần hệ thống nào — đổi lại bạn phải chịu khó thiết kế và tốn công hơn một chút.

Chương 4 · Bài 1

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

Bài mở đầu chương 4, giới thiệu bộ hàm cơ bản trong Google Sheets mà một Project Manager cần biết. Điểm mấu chốt: Google Sheets có rất nhiều hàm phục vụ đủ đối tượng, nhưng khi quản lý dự án bạn chỉ cần một số hàm cốt lõi, vừa đủ và thực tế — và các hàm này sẽ được giải thích ngay trong ngữ cảnh sử dụng ở các bài sau.

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

• Hiểu vì sao chỉ cần học một nhóm hàm cơ bản thay vì toàn bộ hàm của Google Sheets.
• Biết các nhóm hàm cần dùng khi quản lý dự án (tính toán, chuỗi, tìm kiếm…).
• Biết truy cập tài liệu tổng hợp hàm kèm sample để tự tham khảo thêm.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao chỉ học hàm cơ bản

Google Sheets có rất nhiều hàm vì phục vụ đa đối tượng — kế toán, phân tích dữ liệu và nhiều mục đích khác. Trong quản lý dự án, giảng viên đúc kết chỉ cần nắm những hàm cơ bản, hay dùng nhất. Thay vì học dàn trải toàn bộ, bạn tập trung vào nhóm hàm thực sự áp dụng trong công việc.

▸ 2. Các nhóm hàm theo nhu cầu

Bộ hàm được nhóm theo mục đích sử dụng khi làm dự án:

• Nhóm hàm phục vụ tính toán (liên quan tới effort, dependency…).
• Nhóm hàm xử lý chuỗi (text).
• Nhóm hàm tìm kiếm.

Ví dụ khi quản lý tiến độ dự án sẽ dùng tới các hàm tính ngày làm việc như NETWORKDAYS hay WORKDAY. Các hàm này sẽ được giải thích ngay trong lúc dùng ở những bài sau, để bạn hiểu đúng ứng dụng thay vì học rời rạc từng hàm.

▸ 3. Tài liệu tham khảo kèm sample

Bài cung cấp đường link tới file tổng hợp các hàm cơ bản trong Google Sheets, kèm sample chi tiết cho từng hàm và ý nghĩa các tham số. Bạn có thể tham khảo nhanh các sample này để áp dụng, đồng thời chủ động search/research thêm những hàm mình cần.

Chương 4 · Bài 2

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

Bài học chia sẻ triết lý tự học công thức và ba cách để bạn tự tra cứu bất kỳ hàm nào trong Google Sheets. Điểm mấu chốt: khóa học cố tình dùng công thức đơn giản để bạn hiểu và tự làm được, thay vì đưa những công thức phức tạp mà chỉ người viết mới bảo trì nổi. Mục tiêu là "cho cần câu, không cho con cá".

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

• Biết ba nguồn tự học một hàm: tính năng Help, YouTube và nhóm hỗ trợ.
• Dùng thành thạo phần Help ngay trong Google Sheets để đọc mô tả, ví dụ và file mẫu.
• Biết đổi ngôn ngữ hiển thị sang tiếng Việt để đọc chú thích hàm dễ hơn.

─── NỘI DUNG CHÍNH

▸ 1. Ba cách tự học một hàm

• Help của Google Sheets: cách tốt nhất và thường là đủ, không cần đi đâu xa.
• YouTube: gõ tên hàm kèm "how to use it" hoặc "cách sử dụng hàm này" là ra hướng dẫn.
• Nhóm hỗ trợ khóa học: chat câu hỏi lên nhóm, giảng viên sẽ research giúp bạn.

▸ 2. Dùng Help ngay trong ô công thức

Gõ một hàm, ví dụ `SUM`, rồi mở ngoặc — Google Sheets hiện gợi ý tham số (Value 1, Value 2…) và dòng mô tả Returns the sum of a series of numbers. Nhấn Learn more để mở trang trợ giúp đầy đủ, kèm sample usage. Muốn xem công thức chạy thực tế, nhấn Make a copy để tạo ngay một file mẫu và mở trực tiếp bảng ví dụ ra xem.

▸ 3. Đổi ngôn ngữ hiển thị sang tiếng Việt

Nếu chú thích tiếng Anh gây khó, vào Settings đổi display language sang tiếng Việt rồi enter. Khi đó gõ lại `SUM` sẽ thấy mô tả "Trả về tổng một chuỗi các số" và phần Help cũng hiển thị tiếng Việt.

▸ Mẹo quan trọng: hai tiện ích nên biết

• Gõ sheet.new trên trình duyệt rồi enter để tạo ngay một file Google Sheets mới.
• Vào file chọn make available offline để dùng bảng tính ngay cả khi không có mạng; khi online lại nó tự đồng bộ. Ngoài ra Google Sheets miễn phí, chỉ cần tài khoản Gmail — khác với Excel cần bản quyền.

Chương 4 · Bài 3

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

Bài học chia sẻ những tip nền tảng để làm việc với Google Sheets chuyên nghiệp hơn khi quản lý dự án: tạo dropdown bằng Data Validation, tô màu tự động theo điều kiện bằng Conditional Formatting, và các nguyên tắc định dạng dữ liệu đúng cách. Điểm mấu chốt: bảng tính là để tính toán, nên phải tách bạch giá trị và đơn vị, đừng để dính chùm.

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

• Tạo được combo box (dropdown) cho một cột bằng Data Validation.
• Tô màu tự động theo trạng thái bằng Conditional Formatting với custom formula.
• Định dạng số/tiền, màu sắc và font chữ đúng nguyên tắc bảng tính.

─── NỘI DUNG CHÍNH

▸ 1. Data Validation — tạo dropdown và ràng buộc dữ liệu

Chọn vùng dữ liệu → Data → Data Validation → Add rule → Dropdown (from a range), trỏ tới vùng chứa các giá trị (ví dụ: mở / đang làm / đóng). Kết quả là một combo box để chọn thay vì gõ tay, có thể gán màu cho từng lựa chọn. Ngoài dropdown, Data Validation còn nhiều rule khác (text contains, is valid email, is valid url…) để ràng buộc dữ liệu nhập vào cho đúng.

▸ 2. Conditional Formatting — tô màu theo điều kiện

Muốn cả dòng đổi màu khi trạng thái là "đóng": chọn vùng → Conditional Formatting → Custom formula is, viết công thức cố định cột, thả dòng (ví dụ `$C6 = "đóng"`) rồi chọn hiệu ứng (màu nền, màu chữ, in đậm/nghiêng/gạch chân). Khi ô thỏa điều kiện, định dạng tự áp dụng.

▸ 3. Định dạng số, màu và font đúng cách

• Tách giá trị và đơn vị: gõ `150` một ô, đơn vị "Việt Nam đồng" ô khác — đừng gõ chung "150 ngàn" vì sẽ không tính tổng được. Muốn hiển thị đơn vị, dùng Format → Number → Custom currency.
• Tương phản màu: nền nhạt dùng chữ đen, nền đậm dùng chữ trắng để dễ đọc.
• Font chữ: giữ đồng nhất; nhưng chọn đúng vùng cần đổi thay vì Ctrl+A cả sheet — dễ làm hỏng định dạng người khác đã làm.

▸ Mẹo quan trọng: dùng cột số thứ tự (ID) để viết công thức

Khi dữ liệu nhiều, đặt mỗi cột một số thứ tự (ID) rồi ghi công thức theo ID (ví dụ "cột 7 = cột 4 × cột 5") thay vì theo tên tiêu đề. Tiêu đề có thể đổi khiến công thức khó theo, còn số thứ tự thì ổn định và dễ ghi chú.

Chương 4 · Bài 4

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

Bài học giới thiệu bốn kênh hỗ trợ miễn phí mà giảng viên đã lập để bạn học Google Sheets và hỏi đáp trong suốt khóa học. Điểm mấu chốt: khi gặp vướng mắc, bạn không phải tự xoay xở một mình — cứ đăng câu hỏi lên nhóm, giảng viên sẽ research và chia sẻ lại.

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

• Biết bốn kênh hỗ trợ: nhóm Zalo, forum, blog website và kênh YouTube.
• Biết cách tham gia nhóm hỗ trợ và đặt câu hỏi để được giải đáp.
• Tìm được video hướng dẫn đúng chủ đề nhờ một mẹo tìm kiếm đơn giản.

─── NỘI DUNG CHÍNH

▸ 1. Nhóm Zalo hỗ trợ khóa học

Kênh đầu tiên là nhóm Zalo hỗ trợ khóa học Google Sheets — quản lý dự án PM03. Bạn click vào link ở mục 4.1 hoặc quét QR code để xin tham gia; sau khi được duyệt, bạn có thể thảo luận bất kỳ vấn đề nào trong nhóm.

▸ 2. Forum và blog trên website

• Forum: nơi tập hợp thông báo, hướng dẫn sử dụng các khóa học và bài tips được chia sẻ dần. Đăng ký thành viên và xem đều miễn phí; có cả bài về AI, hướng dẫn ChatGPT…
• Blog trên website: vào smartitsoft.com → Blog → Google Sheets để đọc các bài viết. Cần thêm chủ đề nào, bạn có thể liên hệ để giảng viên viết bổ sung.

▸ 3. Kênh YouTube và mẹo tìm kiếm

Kênh YouTube có nhiều video theo chủ đề, ví dụ playlist Google Sheets basic gồm 16 video. Bạn có thể vào phần Video để chọn học hoặc dùng ô search.

▸ Mẹo quan trọng: thêm từ khóa "smartitsoft" khi tìm

Khi search một chủ đề trên YouTube, hãy gõ kèm chữ smartitsoft ngay sau từ khóa (ví dụ: "biểu đồ smartitsoft"). Cách này giúp lọc đúng các video hướng dẫn của kênh thay vì kết quả tràn lan. Nếu tìm trên nhóm mà chưa ra đúng ý, bạn cứ post câu hỏi lên để được hỗ trợ trực tiếp.

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

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

Bài thực hành đầu tiên trong bộ bốn demo: dựng một bảng quản lý thông tin nhân viên hoàn chỉnh từ đầu. Bạn sẽ ráp lại nhiều kỹ thuật cơ bản đã học — đánh số thứ tự bằng công thức, tạo dropdown, tô màu theo điều kiện và thống kê — trên một tình huống thật, rất đơn giản để dễ theo.

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

• Thiết kế được bảng nhân viên với các cột họ tên, email, số điện thoại, trạng thái, địa chỉ, lương, chức vụ.
• Dùng Data Validation, Conditional Formatting và Filter cho một bảng dữ liệu.
• Thống kê số lượng theo trạng thái bằng Pivot Table và bằng hàm COUNTIF.

─── NỘI DUNG CHÍNH

▸ 1. Dựng bảng và nhập dữ liệu đúng cách

Tạo cột số thứ tự bằng hàm IF kết hợp ROW để số chỉ hiện khi dòng có dữ liệu (nếu ô tên rỗng thì để trống). Với số điện thoại, đặt dấu nháy đơn ở đầu để giữ số 0 không bị mất. Định dạng header cho đậm, canh giữa và freeze dòng tiêu đề để cuộn danh sách vẫn thấy tên cột.

▸ 2. Dropdown trạng thái và tô màu theo điều kiện

Liệt kê các trạng thái (đang làm việc, nghỉ việc, nghỉ thai sản) rồi tạo combo box bằng Data → Data Validation → Add rule → Dropdown (from a range). Sau đó dùng Format → Conditional Formatting → Custom formula is với công thức cố định cột (ví dụ `$E5 = "Nghỉ việc"`) để tự tô màu xám cho nhân viên đã nghỉ. Thêm Data → Filter để lọc, sắp xếp theo cột.

▸ 3. Thống kê bằng Pivot Table và COUNTIF

Muốn biết bao nhiêu người đang làm, bao nhiêu nghỉ việc: chọn Insert → Pivot table, đưa trạng thái vào Rows và đếm ở Values. Bạn có thể bỏ dòng show total rồi Insert chart để vẽ biểu đồ theo trạng thái. Cách thứ hai đơn giản hơn là dùng COUNTIF đếm theo từng trạng thái rồi cũng vẽ chart từ bảng đếm đó.

▸ Mẹo quan trọng: mở rộng bảng khi cần

Bảng cơ bản này dễ dàng thêm cột mức lương và chức vụ (chức vụ cũng làm combo box). Khi đó phần thống kê sẽ cho biết mỗi nhân viên lương bao nhiêu, chức vụ gì — đủ dùng cho phần lớn nhu cầu quản lý cơ bản.

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

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

Demo thứ hai: dựng bảng theo dõi giờ làm việc của nhân viên theo từng ngày trong tháng. Bài tập giúp bạn quen với việc làm việc trên dữ liệu ngày tháng — nhận biết thứ trong tuần, tự tô màu ngày nghỉ và cộng tổng giờ theo nhiều chiều. Vẫn xoay quanh vài thao tác cơ bản, không có gì phức tạp.

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

• Trải các cột ngày trong tháng và định dạng ngày theo ý muốn.
• Dùng hàm WEEKDAY để xác định thứ và đánh dấu ngày cuối tuần.
• Tính tổng số giờ làm theo ngày, theo tuần, theo tháng và theo từng nhân viên.

─── NỘI DUNG CHÍNH

▸ 1. Trải ngày và định dạng cột ngày

Bắt đầu từ ngày đầu tháng (ví dụ 1/10), ngày kế tiếp bằng ngày trước cộng thêm 1 rồi kéo cho hết tháng. Để hiển thị gọn, chọn vùng ngày → Format → Number → Custom format và nhập mẫu như mm dd (hoặc mmm dd) tùy ý.

▸ 2. Xác định thứ và tô màu ngày nghỉ

Dùng hàm WEEKDAY để lấy thứ của mỗi ngày. Nếu định dạng ô kết quả bằng custom format với ba chữ D lớn (`DDD`), giá trị sẽ hiển thị thành tên thứ (Monday, Sunday…). Quy ước mỗi ngày làm 8 tiếng, thứ Bảy và Chủ nhật nghỉ. Vì Chủ nhật ứng với giá trị 1 và thứ Bảy ứng với 7, bạn dùng Conditional Formatting → Custom formula is để tô màu tự động các ngày cuối tuần khi giá trị WEEKDAY bằng 1 hoặc bằng 7.

▸ 3. Nhập giờ và cộng tổng nhiều chiều

Điền số giờ mỗi ngày (ví dụ 8, ngày nghỉ ghi 0). Sau đó dùng SUM để tính:

• Tổng theo ngày: tổng giờ tất cả nhân viên trong một ngày.
• Tổng theo tuần và theo tháng: cộng dồn số giờ của cả kỳ.
• Tổng theo từng nhân viên: sum theo hàng ngang để biết mỗi người làm bao nhiêu tiếng trong tháng.

Cuối cùng tô màu cho bảng dễ nhìn và có thể Insert chart để trực quan hóa giờ làm của từng người. Đây là cách quản lý giờ làm việc rất cơ bản mà đủ dùng.

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

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

Demo thứ ba: lập một file quản lý danh sách công việc của nhân viên. Bạn học cách thiết kế bảng task đủ thông tin (kế hoạch và thực tế), tạo dropdown cho độ ưu tiên và trạng thái, rồi tô màu theo trạng thái để nhìn phát biết ngay việc nào đang chạy, việc nào còn thiếu dữ liệu.

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

• Thiết kế bảng công việc với cột người làm, độ ưu tiên, trạng thái, kế hoạch và thực tế.
• Tạo combo box cho độ ưu tiên và trạng thái bằng Data Validation.
• Dùng Conditional Formatting để tô màu theo trạng thái và cảnh báo ô cần điền.

─── NỘI DUNG CHÍNH

▸ 1. Thiết kế bảng công việc

Các cột cần có: tên công việc, người làm, độ ưu tiên, trạng thái, phần kế hoạch (số giờ, ngày bắt đầu, ngày kết thúc), phần thực tế (số giờ, ngày bắt đầu, ngày kết thúc) và ghi chú. Điền dữ liệu mẫu như coding màn hình A/B/C, testing màn hình A/B/C để hình dung.

▸ 2. Dropdown độ ưu tiên và trạng thái

Liệt kê giá trị rồi tạo combo box bằng Data → Data Validation → Add rule → Dropdown (from a range):

• Độ ưu tiên: thấp, vừa, cao.
• Trạng thái: chưa làm, đang làm, xong, tạm hoãn, hủy.

▸ 3. Tô màu theo trạng thái và cảnh báo dữ liệu

Dùng Conditional Formatting → Custom formula is cố định cột trạng thái (ví dụ `$Y6 = "Đang làm"`) và apply cho toàn vùng để task đang làm tự đổi màu. Thêm rule khác: khi công việc đang làm mà ngày bắt đầu chưa có, tô chữ đỏ báo đây là ô cần điền.

▸ Mẹo quan trọng: merge cell và định dạng số phải có ý đồ

• Merge cell: chỉ gộp ở chỗ hợp lý, vì merge đúng chỗ giúp filter dễ hơn — đừng gộp tùy tiện.
• Định dạng số tùy biến: đưa ô về kiểu Number trước, rồi Format → Number → Custom number format để thêm ký hiệu/dấu ở trước hoặc sau con số.
• Giữ hệ màu nhất quán giữa các bảng để nhìn quen mắt.

Đây mới là danh sách công việc cơ bản; phần tính trễ của task sẽ được nói ở các demo sau.

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

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

Demo cuối trong bộ bài tập: dựng bảng tính chi phí dự án cho ngành phần mềm. Bạn sẽ thấy toàn bộ chỉ dùng các phép cộng, trừ, nhân, chia và SUM — điều quyết định không phải công thức "cao siêu" mà là cách tổ chức dữ liệu để tính toán được trên đó.

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

• Thiết lập budget dự án từ man-month và unit price.
• Tính actual cost theo tháng dựa trên resource và mức lương từng người.
• Đọc được tỷ lệ chi tiêu và lợi nhuận của dự án so với budget.

─── NỘI DUNG CHÍNH

▸ 1. Thiết lập budget dự án

Một dự án có time (ví dụ 12 tháng) và cost. Cost quy theo man-month (ví dụ 15 man-month) nhân với unit price (ví dụ 20 triệu/man-month) ra budget tổng (300 triệu). Đưa ô về kiểu Number để cộng tổng chính xác.

▸ 2. Tính actual cost theo tháng

Lập bảng các tháng và phân bổ man-month cho từng tháng (tổng đúng bằng 15). Với mỗi tháng, liệt kê resource (dev 1, dev 2…) kèm số man-month và mức lương từng người. Total cost mỗi người = số man-month × lương (cố định ô lương khi kéo công thức), rồi SUM lại ra chi phí thực tế. Thay đổi phân bổ (ví dụ chỉ 0.5 man-month) thì số tiền tự cập nhật.

▸ 3. Đọc tỷ lệ chi tiêu và lợi nhuận

• % đã chi: actual cost chia cho budget cho biết dự án đang tiêu bao nhiêu phần trăm.
• Lợi nhuận (revenue): lấy budget trừ chi phí, rồi chia cho budget ra tỷ lệ lợi nhuận.
• So sánh billable thực tế với kế hoạch để biết đang dùng ít hơn hay nhiều hơn dự kiến.

▸ Lưu ý khi tính chi phí outsource

Với dự án outsource tính ra tiền, ngay cả khi tỷ lệ chi tiêu cao thì vẫn có thể có lời. Lợi nhuận đẹp nhất là khi chi phí vừa bằng số billable và giá bán cao; giá bán thấp thì dễ lỗ. Có công ty đổ nhiều người vào dự án mà vẫn lời vì mức lương trả không cao. Thông điệp xuyên suốt: tổ chức dữ liệu tốt quan trọng hơn việc dùng công thức giỏi.

Chương 4 · Bài 6

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

Bài học bổ sung thêm một cách tự học rất hiệu quả: dùng ChatGPT để tìm hiểu các hàm cơ bản. So với Help hay YouTube, ChatGPT giải thích cặn kẽ, chi tiết và cho ví dụ ngay. Điểm mấu chốt là biết cách hỏi: hỏi từng bước, yêu cầu ví dụ dễ hiểu hơn và hỏi cả ưu/nhược điểm của hàm.

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

• Dùng ChatGPT để tra cứu và hiểu một hàm Google Sheets.
• Biết cách hỏi tiếp để nhận ví dụ cụ thể, dễ hiểu hơn.
• Hỏi được ưu, nhược điểm của một hàm và các hàm thay thế.

─── NỘI DUNG CHÍNH

▸ 1. Chuẩn bị tài khoản ChatGPT

Trước tiên bạn cần một tài khoản ChatGPT (bản 3.5 miễn phí là đủ dùng để học hàm). Nếu chưa có hoặc không tự đăng ký được, giảng viên có form hỗ trợ đăng ký AI để bạn nhờ đăng ký giúp.

▸ 2. Hỏi ChatGPT về một hàm

Đăng nhập vào trang chat, gõ câu hỏi kiểu "tôi cần tìm hiểu hàm này, dùng thế nào". ChatGPT sẽ trả về phần giải thích kèm ví dụ minh họa. Ví dụ với VLOOKUP: nó dựng sẵn bảng cột A, cột B, chỉ cách tra một sản phẩm và cho ra kết quả cụ thể để bạn đọc là hiểu ngay.

▸ 3. Hỏi sâu hơn để hiểu kỹ

• Xin ví dụ dễ hiểu hơn: gõ "cho tôi một ví dụ cụ thể, dễ hiểu hơn" thì ChatGPT đưa ví dụ đơn giản hơn nữa.
• Hỏi ưu/nhược điểm: ví dụ nhược điểm của VLOOKUP là cần biết vị trí cột và không lấy được giá trị nằm bên trái cột tra cứu.
• Hỏi hàm thay thế: khi biết hạn chế đó, bạn hỏi tiếp và ChatGPT gợi ý dùng INDEX và MATCH, kèm ví dụ.

▸ Mẹo quan trọng: hỏi theo kiểu hội thoại nhiều lượt

Sức mạnh của ChatGPT nằm ở việc hỏi nối tiếp: bắt đầu bằng câu hỏi chung, rồi liên tục yêu cầu làm rõ, cho ví dụ khác, so sánh ưu nhược điểm. Càng hỏi chi tiết, câu trả lời càng đúng nhu cầu — nhờ vậy bạn có thể tự học gần như bất kỳ hàm nào mà không cần chờ ai hướng dẫn.

Chương 5 · Bài 1

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

Bài mở đầu chương về SCOPE — phạm vi công việc của dự án. Bạn cần hiểu scope là gì và những thông tin nào phải nắm để quản lý nó, trước khi ứng dụng Google Sheets ở bài sau. Điểm mấu chốt: scope là những gì mình có trách nhiệm phải làm và bàn giao, và phải xác định rõ ai làm phần nào để tránh out of scope.

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

• Hiểu định nghĩa scope là phạm vi và trách nhiệm công việc trong dự án.
• Biết các phase và hạng mục cấu thành scope của một dự án phần mềm.
• Hiểu vai trò của WBS và ma trận phân chia trách nhiệm giữa hai bên.

─── NỘI DUNG CHÍNH

▸ 1. Scope là gì?

Scope chính là phạm vi công việc — những phần bạn cần thực hiện trong dự án và trách nhiệm cụ thể của bạn. Một dự án phần mềm thường chia thành các phase: design, coding, testing. Mỗi phase lại chia nhỏ tiếp.

▸ 2. Các hạng mục cấu thành scope

• Design: basic design, detail design.
• Coding: coding library, coding API, coding command, coding logic, coding layout.
• Testing: unit testing (gồm create test case và execute test case), integration testing.

Vẽ một diagram nhỏ liệt kê các nhánh này giúp bạn nhìn ra toàn bộ phạm vi cần làm.

▸ 3. Ma trận trách nhiệm và WBS

Lập bảng đối chiếu trách nhiệm giữa our company (công ty mình) và customer company (công ty khách hàng): ví dụ basic design do khách làm, coding và test do mình làm. Nhờ bảng này bạn biết rõ ai phụ trách hạng mục nào. Toàn bộ phạm vi được gói trong WBS (Work Breakdown Structure) — bảng liệt kê mọi hạng mục để estimate cho khách.

▸ Lưu ý khi xác định scope

Scope thường được suy ra từ báo giá tương đối, tài liệu thiết kế khách gửi, danh sách sản phẩm phải deliver và kế hoạch hoàn thành. Ví dụ dự án website gồm khoảng 15 màn hình cộng thêm multi-language (2 ngôn ngữ); mỗi màn hình lại có các chức năng nhỏ bên trong tùy độ phức tạp. Xác định đủ những thông tin này thì mới quản lý được phạm vi và xử lý chi tiết ở bước sau.

Chương 5 · Bài 2

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

Bài thực hành áp dụng những gì đã học về scope vào một file template quản lý dự án xây dần trong suốt khóa. Bạn sẽ dựng sheet quản lý phạm vi công việc và làm chủ một kỹ thuật cốt lõi: đặt mã màn hình và quản lý version tài liệu để luôn biết dự án có đang bị out of scope hay không.

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

• Dựng sheet scope liệt kê toàn bộ danh sách màn hình cần làm.
• Đặt mã màn hình/mã chức năng và nhân đôi mã cho dự án multi-language.
• Lập ma trận theo dõi version tài liệu theo ngày để quản lý thay đổi.

─── NỘI DUNG CHÍNH

▸ 1. Template dự án và sheet scope

Khóa học dùng hai file: một file template quản lý dự án (ban đầu để trống, hoàn thiện dần) và một file định nghĩa các khái niệm. Trên template, bạn tạo sheet index (tổng kết) và sheet scope. Nguồn dữ liệu là dự án demo: khách hàng, loại dự án, UAT (điều kiện chấp nhận sản phẩm), danh sách deliverable và đặc biệt là WBS.

▸ 2. Đặt mã màn hình và xử lý multi-language

Mẹo quan trọng: đặt mã màn hình / mã chức năng cho từng hạng mục (ví dụ HOME01, PROD02, ADMIN03…) thay vì chỉ ghi tên, vì báo giá thường không có mã. Với dự án multi-language, mỗi màn hình cần một mã cho từng ngôn ngữ (tiếng Anh, tiếng Việt). Dùng hàm CONCAT ghép mã ngôn ngữ với mã màn hình, cố định cột và dòng hợp lý để kéo công thức tạo ra bộ Screen ID đầy đủ.

▸ 3. Quản lý version tài liệu bằng ma trận theo ngày

Đặt baseline version là ngày nhận tài liệu lần đầu (ví dụ ngày 26). Khi tài liệu được cập nhật vào ngày khác, thêm cột theo ngày và note những màn hình bị thay đổi — đó chính là CR (change request). Ma trận theo ngày này cho biết đâu là tài liệu mới nhất và hạng mục nào vừa đổi. Cách làm tương tự áp dụng cho unit test case (thêm cột file name) và cho coding.

▸ Lưu ý khi quản lý scope

Vấn đề lớn nhất của dự án là không biết tài liệu đang ở đâu và có bị out of scope không. Nhờ ma trận version, chỉ cần cuộn sheet lên xuống là thấy hạng mục nào cần đồng bộ (ví dụ tài liệu đã update nhưng test case chưa) để đánh dấu "cần update". Kết hợp với việc theo dõi CR trên hệ thống Redmine, bạn kiểm soát được toàn bộ phạm vi dự án.

Chương 5 · Bài 3

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

Bài học chia sẻ những kinh nghiệm thực chiến khi dùng Google Sheets để quản lý scope (phạm vi) của một dự án phần mềm. Điểm mấu chốt: quản lý scope không chỉ là một cái bảng, mà là ai phụ trách, tổ chức lưu trữ ra sao, và làm sao để cả team biết đâu là trong scope, đâu là out scope.

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

• Biết ai nên phụ trách quản lý scope trong một dự án nhỏ (BA hoặc PM).
• Tổ chức được nơi lưu trữ tài liệu theo ngày để truy vết đúng phiên bản.
• Kiểm soát được change request (CR) để tránh out scope làm hỏng plan.

─── NỘI DUNG CHÍNH

▸ 1. Ai phụ trách và tổ chức lưu trữ tài liệu

Trong một dự án chừng 4 người, thường có một bạn BA phụ trách quản lý version và phạm vi; nếu không có BA thì PM làm luôn. Toàn bộ tài liệu nên bỏ lên một nơi lưu trữ chung — SVN, SharePoint, Google Drive đều được, bản chất chỉ là kho chung. Dùng phần CM Plan (Configuration Management Plan) để thống nhất cấu trúc folder. Tài liệu khách hàng cung cấp (thư mục Customer Supply) hầu như không bao giờ final ngay lần đầu, nên lưu trữ theo ngày: mỗi lần nhận là lưu một bản có ngày trong tên file. Nhờ đó, ngày ghi trong sheet khớp đúng với tài liệu trên kho, biết bản nào đang apply, bản nào không.

▸ 2. Trao quyền để cả team phân biệt in-scope / out-scope

Một mình PM không kiểm soát nổi scope vì PM không phải người trực tiếp làm. Vì vậy phải quán triệt mindset cho từng member: cái nào trong scope thì làm; cái nào out scope thì list thành CR, xin confirm từ PM, rồi PM confirm với khách hàng. Chia sẻ file cho anh em để mọi người biết tài liệu mới nhất và phạm vi có bị thay đổi hay không.

▸ 3. Daily meeting để lấy thông tin sớm

Tổ chức daily meeting mỗi ngày để anh em báo cái gì mới, cái gì cần thay đổi — nhờ đó thông tin chảy xuyên suốt. Khi phát hiện một việc đang out scope, PM chặn liền, không cho làm. Lưu ý quan trọng: người phát sinh CR nhiều nhất thường là doer (người trực tiếp làm), không phải cấp trên. Nếu không để ý, cả team làm CR mà không hay, chạy sai plan và làm chết dự án.

Chương 6 · Bài 1

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

Bài học mở đầu chương quản lý TIME, làm rõ tiến độ là gì và những thông tin cần quản lý về tiến độ trong một dự án phần mềm. Điểm mấu chốt: tiến độ luôn là một phép so sánh — so công việc thực tế với một kế hoạch đã đặt ra, để trả lời được dự án đang đạt hay không đạt tiến độ.

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

• Hiểu tiến độ nghĩa là so thực tế với kế hoạch, không phải cảm tính.
• Biết các mốc cần quản lý: phase, mốc release, và từng task nhỏ hằng ngày.
• Nắm cách xác định một công việc bị trễ start hay trễ end và trễ bao nhiêu.

─── NỘI DUNG CHÍNH

▸ 1. Tiến độ là một phép so sánh

Quản lý tiến độ nghĩa là so với một cái gì đó. Ví dụ ngày dự kiến gửi sản phẩm là thứ Sáu; đến thứ Năm bạn phải hoàn thành bao nhiêu phần trăm để kịp 100% vào thứ Sáu. Chính sự so sánh giữa thực tế và kế hoạch đó cho biết dự án có đạt tiến độ hay không.

▸ 2. Các mốc cần quản lý tiến độ

Trong dự án phần mềm, tiến độ được quản lý theo nhiều cấp:

• Theo từng phase: design, coding, testing — mỗi phase có đạt target hay không.
• Theo mốc release: có đạt được mốc target release đã cam kết hay không.
• Theo từng task nhỏ hằng ngày: mỗi ngày công việc có đạt target hay không.

▸ 3. Đo tiến độ bằng plan trên Google Sheets

Bắt đầu bằng việc định nghĩa khung thời gian dự án — ví dụ từ ngày 1 đến ngày 31, dùng hàm NETWORKDAYS để tính ra số ngày làm việc thực (loại bỏ cuối tuần). Sau đó lập danh sách công việc với start date và end date cho từng task, sao cho tất cả cuối cùng rơi đúng vào ngày hoàn thành. Khi chạy thực tế, nếu đến giữa khoảng thời gian mà tỷ lệ hoàn thành chưa tương xứng thì công việc đang bị trễ. Có hai loại trễ cơ bản: trễ ngày start (đến ngày bắt đầu vẫn chưa bắt đầu) và trễ ngày end (đến ngày kết thúc vẫn chưa xong), kèm mức trễ tính ra phần trăm. Phần công thức chi tiết sẽ được hướng dẫn ở các bài thực hành sau.

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ựng một template quản lý tiến độ (Time) bằng Google Sheets từ đầu. Bạn sẽ đi từ danh sách công việc theo mã màn hình, thêm các cột kế hoạch — thực tế, cho đến cột check tiến độ tự phân loại một task đang đúng hạn hay bị trễ. Điểm mấu chốt: chỉ cần vài công thức cơ bản và một cột trạng thái là đủ để nhìn ra ngay task nào "not good".

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

• Dựng được sheet Time với đầy đủ cột plan, actual và trạng thái công việc.
• Tạo dropdown trạng thái bằng Data Validation lấy từ sheet cấu hình.
• Hiểu ý tưởng cột check tiến độ phân biệt trễ start, trễ end và đúng tiến độ.

─── NỘI DUNG CHÍNH

▸ 1. Cấu trúc các cột của một task

Từ WBS của dự án demo (mã màn hình, ngày công), sheet Time được dựng với các cột cơ bản cho một công việc: task name, người thực hiện (person in charge), trạng thái, kế hoạch (ngày bắt đầu / ngày kết thúc), thực tế (ngày bắt đầu / ngày kết thúc), số giờ ước lượng, số giờ thực tế, phần trăm hoàn thành và ghi chú. Đây là bộ cột tối thiểu để theo dõi tiến độ.

▸ 2. Dropdown trạng thái bằng Data Validation

Tạo một sheet cấu hình liệt kê các trạng thái: Mới (New), Đang làm (In progress / Ongoing), Đã hoàn thành (Resolved), Đang review (Reviewing), Đóng (Closed), Tạm hoãn (Pending), Hủy (Cancel). Sau đó vào Data → Data Validation → Add rule → Dropdown (from a range), trỏ tới vùng trạng thái trong sheet cấu hình để cột trạng thái thành combo box. Cột phần trăm hoàn thành cũng làm dropdown tương tự với các mốc tròn (0.1, 0.2… đến 100%) cho gọn.

▸ 3. Cột check tiến độ: trễ start, trễ end, đúng tiến độ

Ý tưởng cột kiểm tra tiến độ dựa trên việc so ngày kế hoạch với ngày báo cáo (thường lấy hàm ngày hiện tại, có thể cộng trừ để lùi/tiến ngày thống kê). Một task có thể rơi vào các tình huống: trễ start (trạng thái vẫn "Mới" mà đã qua ngày bắt đầu), trễ end (đang làm mà đã qua ngày kết thúc), công việc tương lai, đang đúng tiến độ, hoặc đã xong. Hàm IF/IFS được dùng để bắt hết các trường hợp trạng thái. Cuối cùng, dùng Conditional Formatting với custom formula tô đỏ các dòng "not good" để nhìn phát hiện ngay task đang có vấn đề.

Chương 6 · Bài 3

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

Bài học chia sẻ kinh nghiệm thực tế khi dùng Google Sheets để theo dõi tiến độ và ra quyết định. Bạn sẽ học cách lọc ra các task trễ, tính đúng số giờ trễ, và quan trọng hơn là cách nhìn nhận vấn đề trước khi vội vàng overtime. Điểm mấu chốt: đo tiến độ chỉ là bước đầu — hiểu tại sao trễ mới là việc của người PM.

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

• Lọc task "not good" và sum tổng số giờ trễ bằng bộ filter.
• Tính độ trễ phần kết thúc theo phần trăm hoàn thành thay vì trừ thô.
• Biết vì sao overtime là giải pháp cuối cùng và cách phán đoán đa chiều.

─── NỘI DUNG CHÍNH

▸ 1. Lọc task trễ và tính số giờ trễ

Tạo một bộ filter trên bảng task, chọn các dòng "Not good" rồi sum cột số giờ để biết tổng thời gian đang trễ (ví dụ 15 giờ). Với task đang làm dở, số giờ trễ không nên tính bằng cách trừ thô. Cách hợp lý hơn là dựa trên phần trăm hoàn thành: nếu một task 6 giờ đã done 40%, phần còn lại 60% mới là phần trễ thực — cho ra con số sát thực tế hơn (ví dụ 3.6 giờ) so với cách trừ đơn giản (4 giờ). Bạn nên thêm một cột riêng để tính độ trễ phần kết thúc theo cách này.

▸ 2. Overtime là giải pháp cuối cùng

Khi thấy dự án trễ, đừng phản xạ là ép team overtime. Overtime bản chất làm tăng cost, kéo theo dự án over budget, và overtime liên tục khiến con người kiệt sức, tụt motivation khó phục hồi. Vì vậy overtime là phương pháp cuối cùng sau khi đã thử mọi cách khác.

▸ 3. Phán đoán đa chiều rồi họp team

Nhìn một task list phẳng thì rất khó ra quyết định. Hãy tính độ trễ theo nhiều góc nhìn: theo từng file, từng màn hình, từng người, từng trạng thái, rồi cộng lại để có bức tranh tổng thể. Sau khi thống kê xong, vẽ ra bức tranh đó cho cả team, họp lại và lắng nghe ý kiến từng thành viên xem điều gì gây ra vấn đề. Cuối cùng, PM dựa trên dữ liệu và ý kiến team để phán đoán và xử lý — đó mới là cách quản lý tiến độ đúng nghĩa.

Chương 7 · Bài 1

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

Bài học mở đầu chương quản lý COST, làm rõ chi phí dự án là gì và những thông tin PM cần quản lý để dự án có lợi nhuận. Điểm mấu chốt: doanh thu (giá tính với khách hàng) khác với chi phí; chi phí phải thấp hơn doanh thu thì mới có lợi, và PM có thể quản lý chi phí theo tiền hoặc theo ngày công / hệ số năng lực.

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

• Phân biệt được doanh thu, chi phí và lợi nhuận của một dự án.
• Biết hai cách PM thường quản lý cost: theo ngày công và theo tiền.
• Hiểu cách dùng hệ số năng lực theo level để tính chi phí mà không cần lộ lương.

─── NỘI DUNG CHÍNH

▸ 1. Chi phí, doanh thu và lợi nhuận

Chi phí là tất cả các khoản chi để hoàn thành dự án. Từ file estimation / proposal, bạn có tổng số ngày công và tổng giá tính với khách hàng — đây là doanh thu. Chi phí bỏ ra để làm dự án phải thấp hơn doanh thu thì phần còn lại mới là lợi nhuận. Thực tế, nhiều công ty ẩn giá tiền, nên PM chỉ nhận được con số tổng ngày công (ví dụ 37.5 ngày công) để quản lý.

▸ 2. Trường hợp B1 — PM quản lý theo ngày công

Nếu chỉ quản lý ngày công, plan effort chính là tổng ngày công trong estimation (ví dụ 37.5 working day). Nguyên tắc kiểm soát: số ngày công thực tế (actual) làm trong dự án phải nhỏ hơn hoặc bằng số ngày công đã báo giá. Nếu báo giá 37.5 ngày mà làm xong trong 30 ngày thì phần chênh lệch chính là lợi nhuận tính theo ngày.

▸ 3. Trường hợp B2 — PM quản lý theo tiền và hệ số năng lực

Khi quản lý theo tiền, bạn tính tổng chi phí lương của từng người (ví dụ test 1, test 2, dev…) rồi so với tổng budget để ra lợi nhuận và phần trăm lợi nhuận. Muốn tăng lợi nhuận, có hai hướng: giảm số ngày công hoặc chọn người có mức lương thấp hơn. Ở nhiều công ty, PM không được biết lương cụ thể, nên người ta thay bằng hệ số năng lực theo level (ví dụ level 1 = 0.5, level 3 = 1, level cao hơn = 1.5). Nhân ngày công với hệ số ra "ngày công quy đổi", so với tổng ngày công cần làm để biết chi phí chiếm bao nhiêu phần trăm và còn lại bao nhiêu lợi nhuận — tất cả mà không cần lộ mức lương. Cách nào cũng được, miễn phù hợp KPI công ty.

Chương 7 · Bài 2

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

Đây là bài thực hành dựng template quản lý chi phí (Cost) bằng Google Sheets. Bạn sẽ đi từ tổng thu (budget khách hàng) đến bảng chi phí kế hoạch — thực tế, rồi tính lợi nhuận và cân đối ngày công theo hệ số năng lực để dự án không bị lỗ. Điểm mấu chốt: bảng cost cho bạn nhìn ngay chi phí thực tế đang chiếm bao nhiêu phần trăm so với plan và còn bao nhiêu lợi nhuận.

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

• Dựng được sheet Cost gồm tổng thu (budget), chi phí plan và chi phí thực tế.
• Tính chi phí lương ngày từ lương tháng và số ngày công bằng NETWORKDAYS.
• Cân đối ngày công theo hệ số năng lực để kiểm soát lợi nhuận.

─── NỘI DUNG CHÍNH

▸ 1. Tổng thu và bảng chi phí

Bắt đầu bằng tổng thu (budget) — cộng giá phát triển (development) khách hàng trả với các khoản như hosting, domain, dùng hàm SUM. Sau đó lập bảng chi phí với các nhóm cột: hạng mục / danh mục, phần dự kiến (số tiền, ngày chi) và phần thực tế (số tiền, ngày chi). Ví dụ danh mục gồm hosting, domain, lương phát triển; ngày chi domain/hosting rơi vào đầu dự án, còn lương rơi vào ngày lãnh lương cuối tháng.

▸ 2. So sánh plan với actual và tính lợi nhuận

Đặt các ô tổng hợp: tổng budget, chi phí kế hoạch, chi phí thực tế. Từ đó tính chi phí thực tế đang chiếm bao nhiêu phần trăm so với plan, và lợi nhuận = budget trừ chi phí thực tế, rồi chia lại cho budget để ra phần trăm lợi nhuận. Nhờ vậy chỉ nhìn vào bảng là biết dự án đang chi tới đâu, còn lời hay lỗ.

▸ 3. Cân đối ngày công theo hệ số năng lực

Với chi phí lương, mỗi nhân viên có mã, tên, vai trò kèm hệ số năng lực, mức lương tháng và mức lương ngày. Số ngày công tính bằng hàm NETWORKDAYS (bỏ thứ Bảy, Chủ nhật). Lưu ý: nhân viên lãnh lương theo tháng, nên dùng IF để khống chế lương tối đa bằng lương tháng dù họ làm nhiều ngày. Cần phân biệt ngày công tính lương với ngày công theo effort (ngày công nhân hệ số năng lực — phản ánh giá trị thực người đó tạo ra, ví dụ sinh viên thực tập hệ số 0.25). Khi thấy dự án bị lỗ, PM cân đối lại: cho người lương thấp làm nhiều ngày hơn, người lương cao làm ít ngày hơn, hoặc bỏ bớt người, để tổng chi phí về dưới budget mà vẫn đủ effort hoàn thành.

Chương 7 · Bài 3

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

Bài học chia sẻ những tình huống thực tế về chi phí mà bảng tính không nói hết: chi phí "chờ người", sự đánh đổi giữa time và cost, và chi phí thiết bị trong ngành outsourcing. Điểm mấu chốt: khi dự án đã bắt đầu, phần lớn công ty chấp nhận huề vốn hoặc lỗ một chút để cứu dự án và cứu khách hàng, và người PM cần biết tính đúng chi phí thực để deal thêm nguồn lực.

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

• Nhận ra chi phí "chờ người" khi chuyển giao giữa hai dự án.
• Hiểu ràng buộc chặt giữa time và cost và cách chọn ưu tiên.
• Biết những chi phí thiết bị / license có thể deal cho khách hàng cung cấp.

─── NỘI DUNG CHÍNH

▸ 1. Chi phí chờ người khi chuyển giao dự án

Không thể load người vào dự án mới ngay lập tức. Một bạn đang làm dự án A, dự án B start đầu tháng, nhưng cuối tháng dự án A thường còn "lây lắc" chưa dứt điểm. Thời điểm chuyển giao đẹp nhất có thể phải đợi bạn đó nửa tháng. Khoản chi phí cho nửa tháng "chờ" đó thường công ty phải chịu; PM chỉ quan tâm đến ngày đó có người hay không, nhưng một PM thực thụ nên tính luôn cả phần chi phí người đang chờ.

▸ 2. Đánh đổi giữa time và cost

Time và cost ràng buộc rất chặt. Khi khách hàng gấp về thời gian mà chi phí đã fix, muốn giữ chi phí thì không kịp schedule, muốn kịp thì phải thêm người — tức tăng cost. Lúc đó phải deal lại với leader / công ty để xin thêm người. Nếu bạn chứng minh hợp lý bằng số liệu và kinh nghiệm, hầu hết leader đều accept, vì ở vai trò lead thì ưu tiên luôn là cứu khách hàng và cứu dự án; công ty sẵn sàng huề vốn hoặc lỗ ít để dự án không thất bại — bởi khi dự án fail thì mọi cố gắng đều mất.

▸ 3. Chi phí thiết bị trong ngành outsourcing

Ngoài lương còn có chi phí thiết bị: máy test, license, tài khoản dịch vụ. Điểm quan trọng: phần lớn thiết bị dự án có thể yêu cầu khách hàng cung cấp — ví dụ iPhone để test, tài khoản AWS — thay vì công ty tự đầu tư. Việc này cần deal, nhưng đúng rule và hoàn toàn hợp lý, giúp PM không đẩy gánh nặng chi phí lên công ty mình.

Chương 8 · Bài 1

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

Bài học mở đầu chương quản lý QUALITY, làm rõ chất lượng dự án là gì và cách đo nó một cách khách quan. Điểm mấu chốt: điều kiện nghiệm thu trong hợp đồng thường ghi rất chung chung ("sửa hết lỗi"), mà phần mềm thì không bao giờ hết lỗi — nên ngành phần mềm dùng các chuẩn (NORM) với ngưỡng trên / dưới để đo chất lượng thay cho cảm tính.

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

• Hiểu vì sao điều kiện nghiệm thu "hết lỗi" là không đo đếm được.
• Nắm khái niệm NORM và cặp ngưỡng upper / lower control limit.
• Biết đọc một chỉ số (ví dụ test case trên 1.000 LOC) là đạt hay không đạt chuẩn.

─── NỘI DUNG CHÍNH

▸ 1. Điều kiện chấp nhận sản phẩm thường rất chung chung

Trong hợp đồng hay phụ lục, phần điều kiện chấp nhận sản phẩm thường liệt kê hoàn thành các chức năng, bàn giao sản phẩm, hoặc chỉ ghi "sửa hết lỗi tồn đọng". Nhưng theo 7 nguyên tắc kiểm thử phần mềm, một phần mềm còn được dùng thì chắc chắn còn lỗi. Vì vậy yêu cầu "không còn lỗi nào" là chung chung và không có cách đo đếm cụ thể.

▸ 2. NORM — bộ khung để đo chất lượng

Để khách quan hóa, người ta đặt ra tiêu chuẩn chất lượng (NORM): một bảng hệ số theo loại dự án (ODC, fix price) cho các chỉ số như test case, bug, unit test case, integration test case, tính trên đơn vị 1.000 LOC. Mỗi chỉ số có một giá trị trung bình kèm upper control limit (cận trên) và lower control limit (cận dưới). Đo số liệu thực tế của dự án rồi so với NORM: nằm trong khung thì tạm coi là đạt chất lượng cơ bản — giống như xét nghiệm máu nằm trong ngưỡng cho phép thì coi là bình thường.

▸ 3. Đọc chỉ số: thừa, thiếu hay đạt

Ví dụ chuẩn 90 test case trên 1.000 LOC, cận trên 135, cận dưới 45. Viết vượt 135 (ví dụ 150) là viết thừa; viết dưới 45 là viết thiếu; nằm trong khoảng là đạt. Lưu ý: chỉ số này chỉ đo số lượng, chưa đánh giá nội dung test case có chất lượng hay không — muốn sâu hơn phải rã nhỏ theo tỷ lệ (layout, logic…). Kinh nghiệm: ưu tiên dùng chuẩn của khách hàng; không có thì lấy chuẩn công ty; không có nữa thì đo internal để tham chiếu.

Chương 8 · Bài 2

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

Đây là bài thực hành dựng bảng quản lý chất lượng (Quality) bằng Google Sheets, lấy phần review code làm ví dụ. Bạn sẽ đi từ NORM (chuẩn) để tính cận trên — cận dưới, đặt target theo LOC thực tế, rồi so số bug bắt được để đánh giá đạt hay không đạt chất lượng. Điểm mấu chốt: các chỉ số này là cảnh báo (warning), không phải mệnh lệnh — PM phải hiểu vấn đề, không chạy mù theo con số.

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

• Từ NORM tính được lower / upper control limit và làm tròn số bug.
• Đặt target số bug theo actual LOC của từng màn hình.
• Tô màu cảnh báo "not good" bằng Conditional Formatting để nhìn ra ngay.

─── NỘI DUNG CHÍNH

▸ 1. Dựng bảng NORM và tính cận trên / cận dưới

Copy matrix NORM (theo loại dự án như ODC) sang sheet Quality, dán dạng value để không lỗi công thức. Với mỗi chỉ số (ví dụ review code: trung bình khoảng 15 bug trên 1.000 LOC) và tỷ lệ chênh lệch cho phép (ví dụ 10%), tính cận dưới = trung bình trừ (trung bình × %), cận trên = trung bình cộng (trung bình × %). Vì bug không thể là số lẻ, dùng hàm ROUND để làm tròn.

▸ 2. Đặt target theo LOC thực tế của từng màn hình

Lấy danh sách màn hình kèm actual LOC của từng cái. Số bug cần có (target) = actual LOC × số bug chuẩn ÷ 1.000, rồi làm tròn. Từ target lại suy ra cận trên và cận dưới riêng cho từng màn hình bằng cùng công thức chênh lệch. Nhờ đó mỗi màn hình có một khoảng bug hợp lý riêng theo khối lượng code thực.

▸ 3. Đánh giá đạt / không đạt và tô màu cảnh báo

So số bug thực tế bắt được với khoảng cận: bé hơn cận dưới nghĩa là bắt thiếu, cần test thêm; lớn hơn cận trên nghĩa là chất lượng kém (quá nhiều lỗi); nằm trong khoảng là OK — đạt chất lượng. Dùng IF để xuất kết luận, thậm chí ghi rõ "cần có thêm bao nhiêu bug". Sau đó dùng Conditional Formatting → custom formula kiểm 2 ký tự đầu (ví dụ ô bằng "not good") để tô màu đỏ cảnh báo. Cùng cách này áp dụng được cho các chỉ số khác như test case, mật độ bug (bug chia LOC), hay đơn vị quy đổi man-month. Lưu ý cuối: con số chỉ mang tính warning giúp bạn thấy bức tranh tổng thể; PM phải kiểm chứng thực tế (ví dụ hỏi lại đội developer nhiều kinh nghiệm) chứ không chạy máy móc theo chỉ số.

Chương 8 · Bài 3

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

Bài học chia sẻ kinh nghiệm thực tế khi quản lý chất lượng (quality) dự án bằng Google Sheets. Thông điệp mấu chốt: những con số tổng quan trên bảng tính chỉ phản ánh bức tranh bề mặt — muốn đánh giá đúng chất lượng, bạn phải đi sâu phân loại từng bug và đọc số liệu bằng tư duy kiểm thử, chứ không chỉ nhìn tổng số lượng.

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

• Hiểu vì sao số liệu tổng chưa đủ để kết luận về chất lượng dự án.
• Biết phân loại bug theo loại (Coding Convention, Logic, nghiệp vụ…) để tìm xu hướng.
• Nắm cách kết hợp số liệu trên Sheets với các nguyên lý kiểm thử phần mềm.

─── NỘI DUNG CHÍNH

▸ 1. Số liệu tổng quan chỉ là điểm khởi đầu

Khi bảng tính cho ra một con số như "8 bug review code", đó mới chỉ là tổng quan hiện tại. Bạn phải đi sâu hơn: mỗi bug thuộc loại nào — Coding Convention, Logic, nghiệp vụ, hay lỗi khác? Phân loại toàn bộ số lượng bug rồi xem xu hướng của chúng nằm ở đâu. Trong dự án thực tế, mọi bug phát sinh đều phải được record lại trên công cụ quản lý (Redmine, Jira, Backlog…) để về sau có dữ liệu phân tích sâu.

▸ 2. Kết hợp số liệu với nguyên lý kiểm thử

Khi phân tích chất lượng, hãy kết hợp hai thứ: một là đi sâu vào loại bug, hai là áp dụng 7 nguyên tắc kiểm thử phần mềm (7 nguyên lý về bug). Từ đó bạn nhận ra các quy luật như: bug thường tập trung vào một vùng nào đó, và khi đã fix xong một nhánh test case thì phải tiếp tục test thêm các trường hợp khác. Giảng viên gợi ý tham khảo phần Quality Assurance/Control trên blog Smart IT Soft và kênh YouTube để nghe kỹ 7 nguyên tắc này.

▸ 3. Lưu ý quan trọng: số đẹp chưa chắc chất lượng cao

Đôi khi số liệu rất đẹp nhưng test case không đủ. Ví dụ bạn viết rất nhiều test case nhưng toàn kiểm layout, bắt những bug lặt vặt không quan trọng — số thì đủ mà chất lượng lại thiếu. Đó chính là lý do phải phân loại bug ra để nhìn đúng vấn đề. Muốn làm được điều này cần nhiều thời gian hoặc một cách quản lý chuyên nghiệp hơn, giúp việc đi sâu trở nên dễ dàng hơn.

Chương 9 · Bài 1

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

Mở đầu chương quản lý nguồn nhân lực (Human Resource), bài học giới thiệu các loại hợp đồng của thành viên dự án và cách quy đổi effort khi bạn không nắm được mức lương thực. Điểm mấu chốt: dùng hệ số quy đổi theo từng loại hợp đồng để biến số ngày công (working day) thành chi phí, từ đó quản lý được chi phí nhân lực so với kế hoạch.

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

• Phân biệt hợp đồng dịch vụ, hợp đồng chính thức và cộng tác viên.
• Hiểu vai trò của hệ số quy đổi khi PM không biết mức lương nhân viên.
• Tính được chi phí effort của từng thành viên từ số working day theo kế hoạch.

─── NỘI DUNG CHÍNH

▸ 1. Hai cách quản lý nguồn nhân lực

Nếu PM biết được mức lương của nhân công thì quản lý luôn theo lương. Nhưng hầu hết trường hợp PM không nắm được mức lương, khi đó phải dùng hệ số quy đổi: nhân hệ số theo level của dev với số ngày công thực tế để ra chi phí. Việc chọn cách nào tùy tình hình dự án, tổ chức và vai trò của bạn.

▸ 2. Các loại hợp đồng và hệ số tương ứng

Bài giả định tình huống PM không biết mức lương, chia thành các đề mục:

• Hợp đồng dịch vụ: nhân viên chỉ làm một dự án/phần việc, không gắn bó lâu dài (remote, freelance). Lương có thể cao hơn nhân viên chính thức vì không tính bảo hiểm, chỗ ngồi… Hệ số thường là 1.
• Hợp đồng chính thức: hệ số cũng thường là 1 — làm 10 ngày công thì tính 10.
• Cộng tác viên (sinh viên thực tập): hệ số thấp, ví dụ 0.25 — làm 10 ngày công chỉ tính khoảng 2.5 ngày, vì năng lực chưa bằng người chính thức.

▸ 3. Tính chi phí effort theo working day

Nhân hệ số với số ngày công kế hoạch để ra chi phí thực. Trong ví dụ, tổng working day theo kế hoạch là 30 ngày, nhưng sau khi áp hệ số cho từng người, chi phí thực tế chỉ còn khoảng 22.5 ngày. Hệ số này do công ty quy định (bạn cần hỏi lại để có), và mang ý nghĩa phản ánh năng lực của từng vị trí. Đây là cơ sở để PM kiểm soát chi phí có đúng kế hoạch hay không. Cách tính chi tiết hơn sẽ có ở các bài tiếp theo.

Chương 9 · Bài 2

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

Bài học giải thích khái niệm billable — giá trị đầu vào của dự án tính theo tiền hoặc theo effort, tương tự "doanh số" khi bạn bàn giao xong dự án. Điểm mấu chốt: billable là con số chốt với khách hàng dựa trên estimation, đóng vai trò như budget để bạn so sánh với chi phí thực tế mà kiểm soát lời/lỗ.

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

• Hiểu billable là gì và tính được billable theo working day lẫn theo giá tiền.
• Phân biệt billable (đầu vào) với cost actual (chi phí bỏ ra thực tế).
• Biết cách chia nhỏ billable theo giai đoạn, theo team để quản lý chi tiết hơn.

─── NỘI DUNG CHÍNH

▸ 1. Billable là gì?

Trong sheet WBS (Work Breakdown Structure), tổng giá tiền và tổng ngày công của dự án chính là billable. Ví dụ trong demo: billable theo giá tiền là 5.625.000, theo effort là 37.5 ngày công. Billable giống như doanh số của dự án — số tiền mình sẽ lấy của khách hàng khi hoàn thành. Nó dựa trên estimation và khi báo giá win thì con số này được chốt, hoạt động như budget của khách hàng.

▸ 2. Billable đối chiếu với chi phí thực tế

Billable là đầu vào; còn chi phí bỏ ra thực tế là chuyện khác. Ví dụ dự án có 3 dev, mỗi người làm một số ngày, sum lại được cost actual theo working day; nếu tính theo lương thì được cost actual theo salary. So sánh chi phí thực tế với billable sẽ biết dự án lời hay lỗ — làm ít hơn billable là lời. Tùy role, bạn được yêu cầu quản lý theo working day hay theo giá tiền, và có thể áp thêm hệ số theo level của dev/tester.

▸ 3. Chia nhỏ billable để quản lý chi tiết

Thay vì chỉ quản lý con số tổng, dự án lớn thường chia billable nhỏ hơn: chi phí phần coding riêng, phần testing riêng (dùng SUM cho từng nhóm). Có thể chia tiếp theo team (team 1, team 2), theo từng file. Nhờ đó có ba cách quản lý: theo working day, theo team, hoặc kết hợp cả hai. Dự án càng lớn thì càng chia nhỏ để vừa quản lý theo số lượng vừa theo cách phân chia của dự án.

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 khái niệm calendar effort — lượng nhân công (resource) mà bạn lên lịch trình để thực hiện dự án, tính theo đơn vị man-month. Điểm mấu chốt: calendar là số người bạn log vào dự án theo từng tháng; so sánh tổng calendar với billable sẽ cho biết cách phân bổ nguồn lực đang hướng dự án tới lời hay lỗ.

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

• Hiểu calendar effort là gì và đơn vị man-month.
• Quy đổi billable từ working day sang man-month (chia cho số ngày công/tháng).
• Biết cách phân bổ số người theo từng tháng và tính tổng calendar bằng SUM.

─── NỘI DUNG CHÍNH

▸ 1. Từ billable sang man-month

Từ dự án demo có billable 37.5 ngày công, chuyển giá tiền dạng text về số rồi dùng SUM để lấy tổng. Chia tổng ngày công cho 20 (số ngày công một tháng) để ra man-month — ví dụ được khoảng 1.8 man-month. Vì dự án demo quá nhỏ, bài giả định phóng to gấp 10 lần thành khoảng 19 man-month để minh họa dễ hơn. Khái niệm man-month được nói chi tiết ở khóa BM trước đó.

▸ 2. Calendar effort — phân bổ người theo tháng

Calendar effort là lượng resource bạn lên lịch để chạy dự án. Với đầu vào 19 man-month làm trong duration 4 tháng, bạn phân bổ số người mỗi tháng sao cho tổng khớp billable — ví dụ 5, 5, 5, 4 người, SUM lại đúng 19 man-month. Con số phân bổ từng tháng này chính là calendar.

▸ 3. So sánh calendar với billable để đọc lời/lỗ

• Nếu tổng calendar thấp hơn billable (ví dụ 4, 4, 4, 5 = 17 so với đầu vào 19) thì dự án có xu hướng lời.
• Nếu tổng calendar cao hơn billable (ví dụ 6, 6, 6, 5 = 23) thì dự án có nguy cơ lỗ.

▸ 4. Cách tính chi tiết có hệ số

Khi tính chi tiết, mỗi người được nhân hệ số theo loại/level (chính thức hệ số 1, sinh viên thực tập 0.25 nên ngày công quy đổi giảm), lấy ngày công chia cho 20 rồi SUM để ra tổng calendar. Nhờ áp hệ số, cùng số người load vào nhưng tổng man-month tiêu tốn có thể thấp hơn đầu vào — phản ánh việc phân bổ tiết kiệm resource hơn kế hoạch.

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 Effort Efficiency (EE) — chỉ số đo hiệu quả sử dụng nhân lực của dự án, tính bằng công thức EE = billable / calendar và thể hiện theo phần trăm. Điểm mấu chốt: EE cho biết bạn đang dùng nguồn lực đúng, ít hơn hay nhiều hơn so với kế hoạch (billable) — mà điều đó chính là tiền, là lời/lỗ của công ty.

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

• Nắm công thức EE = billable / calendar và đọc ý nghĩa của % EE.
• Phân biệt cách quản lý EE cho hợp đồng ODC và hợp đồng Fixed Price.
• Biết ngưỡng EE hợp lý và vì sao phải theo dõi chỉ số này chặt chẽ.

─── NỘI DUNG CHÍNH

▸ 1. Công thức và ý nghĩa của EE

EE = billable chia cho calendar, định dạng phần trăm. Nếu load resource đúng như billable (ví dụ mỗi tháng đúng 5 người theo kế hoạch 5) thì EE = 100%. Nếu load nhiều hơn (7 người) EE tụt còn 71%, load gấp đôi (10 người) chỉ còn 50% — EE càng thấp nghĩa là dùng nguồn lực nhiều hơn kế hoạch, hiệu quả kém.

▸ 2. EE với hợp đồng ODC và Fixed Price

• ODC: khách hàng chốt tiền theo từng tháng, nên phải phân bổ số người mỗi tháng rõ ràng để tính tiền. EE phản ánh sát việc mỗi tháng dùng đúng/thừa/thiếu người.
• Fixed Price: khách hàng không quan tâm cách phân bổ, chỉ cần sản phẩm đúng hạn. Việc phân bổ là chuyện nội bộ, phụ thuộc chiến lược đánh dự án; EE từng tháng có thể lên xuống thất thường (lúc 67%, lúc 80%, lúc trên 100%) nhưng nội bộ vẫn phải kiểm soát tổng.

▸ 3. Ngưỡng EE và cách theo dõi

Rất hiếm khi EE đạt đúng 100%; thực tế thường thấp hơn, và mức khoảng 85% được xem là ổn. Mỗi lần load người phải tính lại EE thật chặt để biết nguồn lực dùng có hiệu quả không — vì nếu khách hàng trả 5 người mà bạn dùng 6 người thì công ty lỗ. Bạn có thể chấp nhận EE thấp ở giai đoạn đầu rồi kéo cao về sau, miễn tổng hợp lý. Khóa BM01 trình bày chỉ số này chi tiết và đầy đủ hơn.

Chương 9 · Bài 5

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

Bài thực hành hướng dẫn dựng bảng Google Sheets để tính EE ở ba cấp độ: từng tháng, từng giai đoạn, và toàn bộ dự án. Điểm mấu chốt: dùng ngày làm việc thực (không chỉ chia cứng cho 20) để tính calendar chính xác theo từng tháng, rồi so với billable phân bổ mà đọc hiệu quả sử dụng nguồn lực.

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

• Tính working day thực tế của từng người bằng NETWORKDAYS (có trừ ngày nghỉ).
• Lấy calendar và EE cho toàn dự án, và tổng hợp EE theo từng tháng bằng SUMIF.
• Trực quan hóa billable, calendar và EE bằng combo chart.

─── NỘI DUNG CHÍNH

▸ 1. Dựng calendar từng người bằng NETWORKDAYS

Với billable 20 man-month làm trong nhiều tháng, bạn phân bổ mỗi dev/tester một khoảng start date – end date. Dùng NETWORKDAYS(start, end, holidays) để tính số ngày làm việc thực (chọn danh sách holiday và cố định dòng/cột), rồi chia cho 20 để ra calendar theo man-month. Vì mỗi tháng có số ngày làm việc khác nhau, tổng calendar thường nhỉnh hơn billable một chút — đó là lý do con số 20 (tương ứng khoảng 160 giờ/tháng theo hợp đồng) được dùng thống nhất.

▸ 2. EE toàn dự án và tạo key theo tháng

Tính EE toàn bộ = billable / tổng calendar. Để tính EE theo từng tháng, cần một cột key đánh dấu tháng: dùng EOMONTH lấy ngày cuối tháng rồi format dạng mmm-yy để làm khóa duy nhất. Việc allocate người từng tháng phụ thuộc chiến lược của bạn (ai làm tháng nào, skill ra sao), không nhất thiết ai cũng làm từ đầu đến cuối.

▸ 3. Tổng hợp EE từng tháng bằng SUMIF và vẽ chart

Tạo danh sách các tháng bằng EOMONTH, đặt billable phân bổ mỗi tháng, rồi dùng SUMIF để cộng calendar theo đúng key tháng. Lấy billable chia cho calendar mỗi tháng ra EE từng tháng; khi điều chỉnh phân bổ người ở bảng chi tiết, EE sẽ tự nhảy số. Cuối cùng dùng Insert → Chart → Combo chart: đặt billable và calendar dạng column (cùng đơn vị man-month), EE dạng line trên trục phụ (đơn vị %). Nhìn chart bạn thấy ngay tháng nào dùng hơn/kém billable và EE tương ứng.

Chương 9 · Bài 6

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

Bài học chia sẻ kinh nghiệm thực tế đọc chỉ số EE để ra quyết định quản lý, xoay quanh bốn câu hỏi: EE thấp nghĩa là gì, EE cao nghĩa là gì, EE đúng chuẩn nghĩa là gì, và EE có phản ánh hết chi phí dự án không. Điểm mấu chốt: EE chỉ đo hiệu quả sử dụng nguồn lực, không thể hiện toàn bộ chi phí — nên phải kết hợp với dữ liệu lương mới thấy đúng lời/lỗ.

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

• Diễn giải được ý nghĩa của EE thấp, EE cao và EE bằng 100%.
• Hiểu vì sao EE không phản ánh đầy đủ chi phí dự án.
• Biết dùng EE cùng tình hình tiến độ để quyết định điều chỉnh nhân sự.

─── NỘI DUNG CHÍNH

▸ 1. EE thấp và EE cao phản ánh điều gì?

• EE thấp: calendar đang dùng nhiều hơn billable — bạn xài nhiều nguồn lực hơn kế hoạch. Cần đào sâu: do quản lý kém hay do dự án thực sự khó nên phải thêm người.
• EE cao: dùng ít hơn billable. Có thể dự án dễ, hoặc PM cố tình load nhiều ở giai đoạn đầu rồi giảm dần về sau để tổng gần bằng billable.

Thực tế EE hiếm khi phẳng đều, mà nhấp nhô lúc cao lúc thấp; điều quan trọng là quản lý được tổng cho hợp lý.

▸ 2. EE không phản ánh hết chi phí dự án

EE chỉ thể hiện một phần. Chi phí thực còn phụ thuộc mức lương: một developer nhiều kinh nghiệm có lương rất cao, thậm chí cao hơn cả giá bán, khiến lợi nhuận âm ngay cả khi EE trông ổn. Ngược lại, EE nhìn như "lỗ" nhưng thực tế dự án vẫn có thể lời. Vì vậy đừng chỉ dựa vào EE để kết luận lời/lỗ — nó là chỉ số hiệu quả nguồn lực, không phải bức tranh chi phí đầy đủ.

▸ 3. Kinh nghiệm ra quyết định từ EE

Nếu EE luôn 100% (đúng billable) thì đó là quản lý rất tốt, nhưng thực tế rất hiếm. Một tình huống đáng chú ý: đã load nhiều người (EE thấp) mà dự án vẫn trễ tiến độ. Khi đó phải nhìn nhận có thể nhân sự không đủ chất lượng để làm dự án, dẫn tới càng thêm người càng không xong — lúc này phương án cần cân nhắc là đổi người. EE chính là chỉ số giúp bạn phán đoán và điều chỉnh cách load người cho hợp lý.

Chương 10 · Bài 1

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

Mở đầu chương quản lý rủi ro và vấn đề, bài học định nghĩa Risk (rủi ro) và Issue (vấn đề) cùng cách phân biệt hai khái niệm này. Điểm mấu chốt: risk là điều nghi ngờ sẽ xảy ra nhưng chưa xảy ra, còn issue là điều đã xảy ra rồi và phải xử lý ngay — nắm rõ khác biệt này giúp bạn biết cái gì cần phòng tránh, cái gì cần hành động.

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

• Phân biệt rõ risk (chưa xảy ra) với issue (đã xảy ra).
• Nắm các thông tin cần quản lý cho một risk và một issue.
• Hiểu vì sao phải ưu tiên risk theo khả năng xảy ra và độ ảnh hưởng.

─── NỘI DUNG CHÍNH

▸ 1. Risk và Issue khác nhau thế nào?

Risk là điều bạn nghi ngờ sẽ xảy ra trong dự án nhưng tại thời điểm nghi ngờ thì chưa xảy ra. Ví dụ đời thường: thấy mây đen, bạn dự đoán sắp mưa — trời mưa chưa xảy ra nên đó là risk. Issue thì ngược lại: đã xảy ra rồi. Ví dụ đang đi thì trời mưa, bạn bị ướt áo — đó là vấn đề đã thành issue.

▸ 2. Ứng xử với risk: phòng hờ hay chấp nhận

Với một risk, bạn có thể phòng hờ (mua áo mưa trước — tốn chi phí nhưng an toàn) hoặc chấp nhận rủi ro (cứ đi, mặc kệ). Nếu chấp nhận mà rủi ro xảy ra, thiệt hại có thể rất nặng — ướt áo, thậm chí hư điện thoại — còn cao hơn chi phí phòng hờ ban đầu. Với issue đã xảy ra thì bắt buộc phải có action để xử lý ngay (thay áo, sấy khô, kiểm tra thiết bị).

▸ 3. Thông tin cần quản lý cho Risk và Issue

• Risk: mô tả rủi ro; dự đoán nó xảy ra ở giai đoạn nào; độ ảnh hưởng (impact) tới chất lượng/tiến độ nhiều hay ít; khả năng xảy ra cao hay thấp. Phải chọn risk có khả năng cao để xử lý trước, risk thấp thì từ từ — vì xử lý cái gì cũng tốn chi phí.
• Issue: mô tả thông tin issue; phương pháp đứng (xử lý); chi phí bỏ ra. Ví dụ bug quá nhiều thành vấn đề thì phải action ngay: review lại test case, add team, phân người xử lý.

Chương 10 · Bài 2

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

Bài thực hành hướng dẫn dựng bảng Google Sheets để quản lý Issue và Risk của dự án — từ tạo template, gắn dropdown bằng Data Validation, cho tới cách theo dõi và cập nhật hằng ngày. Điểm mấu chốt: issue đã xảy ra thì quản lý bằng bảng phương án xử lý; risk chưa xảy ra thì bổ sung hai cột khả năng xảy ra và độ impact để ưu tiên.

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

• Dựng được bảng quản lý Issue và Risk với các cột thông tin cần thiết.
• Tạo dropdown cho danh mục, trạng thái, khả năng xảy ra, độ impact bằng Data Validation.
• Nắm ba hướng xử lý một risk và thói quen cập nhật bảng mỗi ngày.

─── NỘI DUNG CHÍNH

▸ 1. Bảng quản lý Issue

Tạo bảng Issue với các cột: mô tả vấn đề, danh mục, phương án đối ứng, người đứng/thực hiện, trạng thái, dự kiến ứng (ngày bắt đầu – kết thúc), số giờ kế hoạch và số giờ ứng. Danh mục (design, kiểm thử, unit, khách hàng, môi trường, con người…) và trạng thái (chưa làm, đang làm, pass) được đưa vào Data → Data Validation → Dropdown lấy từ sheet cấu hình. Nên thêm cột column đánh số cột để tiện trao đổi. Issue là plan phát sinh — cứ monitor danh sách, xong thì đóng, chưa xong thì theo dõi theo kế hoạch.

▸ 2. Bảng quản lý Risk

Dùng cấu trúc tương tự nhưng thêm hai cột đặc trưng: khả năng xảy ra (thấp/vừa/cao) và độ impact (nhỏ/vừa/lớn, impact tới cost, time, quality…), đều gắn dropdown qua Data Validation. Risk có khả năng cao + impact lớn thì ưu tiên xử lý; khả năng thấp và impact nhỏ thì để từ từ, vì đối ứng risk nào cũng tốn chi phí và thời gian.

▸ 3. Ba hướng xử lý risk và thói quen cập nhật

Khi đối mặt một risk có ba cách cơ bản: chủ động giải quyết, giảm nhẹ (giải quyết một phần), hoặc mặc kệ (chờ khi xảy ra mới xử lý, nếu impact và khả năng đều thấp). Bạn phải cập nhật bảng mỗi ngày để biết dự án còn issue hay risk nào; có risk tự nó biến mất thì hủy đi. Bài kết thúc bằng một tài liệu project plan mẫu liệt kê sẵn khoảng 11 common risk cùng cách action và một số issue thường gặp để bạn tham khảo.

Chương 10 · Bài 3

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

Đây là bài chia sẻ kinh nghiệm thực tế về quản lý risk (rủi ro) và issue (vấn đề) trong dự án phần mềm. Điểm mấu chốt: không có dự án nào là không có risk hay issue — nếu bạn thấy "không có vấn đề gì", thường là vì bạn chưa nhận ra, hoặc cách xử lý của bạn đã âm thầm giải quyết chúng. Vai trò của PM là nhận thức được rủi ro tồn tại và chủ động đối ứng.

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

• Nhận diện được đặc thù rủi ro theo quy mô dự án (nhỏ, lớn, khó về kỹ thuật/nghiệp vụ).
• Biết cách cập nhật và chia sẻ thông tin rủi ro liên tục cho cả team.
• Hiểu vì sao quản lý risk/issue là làm việc đội nhóm, không phải việc của riêng PM.

─── NỘI DUNG CHÍNH

▸ 1. Rủi ro theo từng loại dự án

Mỗi dự án có rủi ro riêng, nhưng có những dạng chung để lường trước:

• Dự án nhỏ (1–2 man-month): khâu design rất sơ sài, chỉ vài dòng note. Rủi ro chính nằm ở kế hoạch dễ trễ, nên phải buffer thời gian vì trao đổi với khách hàng luôn phát sinh.
• Dự án lớn (team size vài chục, cả trăm người): mỗi lần cần sửa là phải chỉnh đồng loạt, effort nhân lên theo hệ số rất cao. Estimate sai một chút, impact khi có sự cố là khủng khiếp.
• Dự án khó về kỹ thuật hoặc nghiệp vụ: nếu bỏ sót rủi ro kỹ thuật, đến lúc nó ập tới là "chết"; với nghiệp vụ liên kết phức tạp, đừng dồn tích hợp màn hình về cuối vì bug sẽ fix không kịp — phải tích hợp dần dần.

▸ 2. Cập nhật thông tin liên tục

Nhiều rủi ro chỉ là phán đoán, chưa đủ thông tin và chưa xảy ra. Vì vậy phải liên tục cập nhật để biết nó có thành hiện thực không. Là PM đi họp với khách hàng xong, bạn phải transfer thông tin đó về team ngay — đừng bao giờ giữ lại. Ví dụ khách báo "sắp gửi 50 bug", nhưng tới ngày kiểm tra hệ thống lại chưa có bug nào, bạn chia sẻ ngay để cả team nắm đúng tình hình.

▸ 3. Phát huy sức mạnh tập thể

Quản lý risk/issue là bước khởi đầu của PM, nhưng bước tiếp theo bắt buộc là chia sẻ cho các thành viên và tận dụng sức mạnh tập thể. Làm dự án là làm việc đội nhóm — mỗi người góp một góc nhìn thì việc phán đoán và đối ứng rủi ro mới hợp lý.