Phụ lục C — Mẫu WBS + Timeline/Gantt + Roadmap đầy đủ (FoodNow)

Bản in từ templates/wbs/, timeline-gantt/, roadmap/. Đọc kèm Ch10–Ch13.

C.1 WBS (cây và tóm tắt)

📎 Nguồn: templates/wbs/FoodNow-WBS.md

Tên tài liệu: WBS — FoodNow MVP Dự án: FoodNow MVP Phiên bản / ngày: v1.0 — 06/02/2026 (baseline, cùng Scope Statement v1.0; điều chỉnh cho v1.1 ở Ch11/Ch12) Mục đích & khi nào dùng: Phân rã deliverable thành các work package để ước lượng, lập lịch, giao việc; dùng sau khi chốt Scope Statement.

1. Cây WBS (đến cấp 3)

flowchart LR
    R["0. FoodNow MVP<br/>1.927 ngày công"]
    R --> W1["1. Quản lý dự án<br/>186"]
    R --> W2["2. Phân tích & thiết kế<br/>227"]
    R --> W3["3. Phát triển<br/>937"]
    R --> W4["4. Kiểm thử<br/>277"]
    R --> W5["5. Hạ tầng & DevOps<br/>92"]
    R --> W6["6. Tích hợp bên thứ ba<br/>90"]
    R --> W7["7. Triển khai & đào tạo<br/>100"]
    R --> W8["8. Đóng dự án<br/>18"]
    W3 --> W31["3.1 App Khách hàng<br/>320"]
    W3 --> W32["3.2 App Nhà hàng<br/>102"]
    W3 --> W33["3.3 App Tài xế<br/>130"]
    W3 --> W34["3.4 Admin web<br/>55"]
    W3 --> W35["3.5 Backend/API<br/>330"]

2. Tóm tắt theo nhóm

3. Kiểm tra với năng lực đội

• Năng lực: 12 FTE × ~185 ngày làm việc (từ 05/01 đến 03/10/2026, trừ Tết và lễ) = 2.220 ngày.
• Ước lượng WBS = 1.927 ngày ≈ 87% năng lực; phần còn lại ≈ 293 ngày (13%) cho họp, nghỉ phép, học việc, việc phát sinh — đó chính là lý do không xếp 100%.
• Chi phí nhân sự MVP 1,67 tỷ ÷ 1.927 ngày ≈ 0,87 triệu VND/ngày công (chi phí bình quân đã gồm overhead; xem Ch14).

4. Chi tiết work package

Xem FoodNow-WBS.csv (cột: WBS_ID, Level, Name, Description, Owner, Estimate_Days, Depends_On, Status); dòng cuối là dòng tổng kiểm tra bằng công thức. Từ điển WBS cho các gói lớn ở wbs-dictionary.md.

Quy tắc:

• Level 1 = toàn dự án; Level 2 = nhóm deliverable; Level 3 = nhóm con; Level 4 = work package (lá cây).
• Work package lớn nhất 65 ngày (dịch vụ đơn hàng) — sẽ được chia nhỏ thành story khi vào backlog (Ch24).

Cách dùng cho dự án của bạn

1. Bắt đầu từ Scope Statement: mỗi epic in-scope và mỗi hạng mục project scope (quản lý, kiểm thử, triển khai) là một nhánh cấp 2.
2. Phân rã đến khi mỗi lá ước lượng được và có một người chịu trách nhiệm.
3. Kiểm tra quy tắc 100%: cộng các con phải bằng cha, không thiếu cũng không thừa.
4. So tổng ước lượng với năng lực đội; nếu > 90% thì lịch quá căng.
5. Lưu ID ổn định; khi đổi WBS sau baseline phải qua change control.

C.2 WBS chi tiết (66 work package)

📎 Nguồn: templates/wbs/FoodNow-WBS.csv (bảng dưới là bản đọc của tệp CSV; công thức Excel giữ nguyên trong tệp gốc).

C.3 WBS Dictionary

📎 Nguồn: templates/wbs/wbs-dictionary.md

Tên tài liệu: Từ điển WBS (WBS Dictionary) — FoodNow MVP Dự án: FoodNow MVP Phiên bản / ngày: v1.0 — 06/02/2026 Mục đích & khi nào dùng: Mô tả chi tiết từng work package quan trọng để mọi người hiểu cùng một nghĩa; dùng cho các gói lớn/rủi ro cao.

Khung mô tả

Mỗi work package: ID · Tên · Mô tả phạm vi · Deliverable · Tiêu chí hoàn thành · Chịu trách nhiệm · Ước lượng · Phụ thuộc · Giả định/Rủi ro.

3.5.3 Dịch vụ đơn hàng và vòng đời

6.1.1 Tích hợp PayEasy và chứng nhận

3.1.5 Theo dõi đơn và bản đồ (app Khách hàng)

4.2.5 Hỗ trợ UAT và regression cuối

Cách dùng cho dự án của bạn

1. Chỉ viết từ điển cho gói lớn (> 30 ngày), rủi ro cao hoặc hay gây hiểu lầm.
2. Viết tiêu chí hoàn thành kiểm tra được, không dùng từ như "tốt", "ổn".
3. Ghi khoảng ước lượng (thấp–cao), không chỉ một con số.
4. Cập nhật từ điển khi WBS đổi; lưu cùng phiên bản.
5. Gửi người chịu trách nhiệm xác nhận từng dòng.

C.4 Gantt và lịch sprint

📎 Nguồn: templates/timeline-gantt/FoodNow-Gantt.md

Tên tài liệu: Gantt baseline — FoodNow MVP Dự án: FoodNow MVP Phiên bản / ngày: v1.0 — 27/02/2026 (baseline lịch sau Tết, đồng bộ Scope Statement v1.1 và WBS v1.0) Mục đích & khi nào dùng: Hiển thị lịch tổng thể, đường găng và các mốc để trình bày với Sponsor và đội; dùng sau khi có WBS, ước lượng và phụ thuộc.

1. Gantt (Mermaid)

gantt
    title FoodNow MVP - Lịch baseline (05/01/2026 - 13/11/2026)
    dateFormat YYYY-MM-DD
    axisFormat %m/%y
    excludes weekends, 2026-02-16, 2026-02-17, 2026-02-18, 2026-02-19, 2026-02-20, 2026-04-27, 2026-04-30, 2026-05-01, 2026-09-02
    section Khởi động và thiết kế
    Kickoff :milestone, m01, 2026-01-05, 0d
    Sprint 0 - chuẩn bị, chốt scope, WBS :s02, 2026-01-12, 20d
    Kiến trúc và API contract (2.3) :s03, 2026-01-12, 15d
    Hạ tầng và CI/CD nền (5.1) :s04, 2026-02-02, 15d
    UX/UI - wireframe và UI (2.2) :s05, 2026-01-19, 107d
    section Phát triển
    Sprint 1 - nền tảng (đăng nhập, khung app) :s06, 2026-02-09, 10d
    Backend lõi - tài khoản, thực đơn, đơn hàng (3.5.1–3.5.3) :s07, 2026-02-09, 67d
    App Khách hàng (3.1) :s13, 2026-02-09, 102d
    App Nhà hàng và Admin web (3.2, 3.4) :s14, 2026-02-09, 102d
    App Tài xế và bản đồ (3.3, 6.2.2) :s15, 2026-04-20, 57d
    Backend - ghép tài xế, realtime, thông báo, dữ liệu (3.5.4, 3.5.6–3.5.8) :s16, 2026-05-25, 35d
    Kiểm thử chức năng theo sprint (4.2.1–4.2.2) :s17, 2026-02-09, 105d
    section Thanh toán - đường găng
    PayEasy cấp sandbox (mốc vendor) :crit, milestone, s08, 2026-03-27, 0d
    Tích hợp PayEasy sandbox và kiểm thử chứng nhận (6.1.1) :crit, s09, 2026-03-30, 20d
    Vendor cấp chứng nhận (chờ bên ngoài) :crit, s10, 2026-04-28, 22d
    Thanh toán end-to-end và đối soát (3.5.5, 3.1.4) :crit, s11, 2026-06-01, 20d
    Kiểm thử bảo mật và tích hợp thanh toán (4.2.4) :crit, s12, 2026-06-29, 15d
    section Mốc quản lý
    Demo chạy thật cho HĐQT :milestone, s18, 2026-06-03, 0d
    Scope Freeze :milestone, s19, 2026-07-13, 0d
    section Phát hành và UAT
    Cắt release/1.0.0, tag rc.1, code freeze :crit, s20, 2026-07-20, 5d
    UAT vòng 1 (rc.1) :crit, s21, 2026-07-27, 20d
    Go/No-Go lần 1 = No-Go :crit, milestone, s22, 2026-08-21, 0d
    Sửa lỗi Critical/High, tag rc.2 :crit, s23, 2026-08-24, 9d
    UAT vòng 2 (retest, regression) :crit, s24, 2026-09-07, 8d
    Go/No-Go lần 2 = Go :crit, milestone, s25, 2026-09-16, 0d
    section Go-live và đóng
    Chuẩn bị cutover, đào tạo, tài liệu vận hành (7.1) :crit, s26, 2026-09-17, 12d
    Go-live 02 -00 thứ Bảy :crit, milestone, s27, 2026-10-03, 0d
    Hypercare 4 tuần :s28, 2026-10-03, 20d
    Đóng dự án - nghiệm thu, lessons learned :s29, 2026-11-02, 10d

Gantt loại bỏ cuối tuần, Tết (16–20/02/2026), bù Giỗ Tổ 27/04, 30/04–01/05 và 02/09. Các gói màu "crit" nằm trên đường găng. Chi tiết ngày, phụ thuộc và float ở FoodNow-Schedule.csv.

2. Lịch sprint

3. Đọc-hiểu đường găng

Kết luận: đường găng đi qua tích hợp thanh toán (tổng 131 ngày làm việc từ 30/03 đến 02/10). Các nhánh phát triển (app Khách hàng, Nhà hàng, Tài xế, Backend) có float 2–5 ngày làm việc — gần găng (near-critical), cần theo dõi. Mọi trễ ở nhánh găng làm trễ go-live nếu không có biện pháp rút ngắn (crashing/fast-tracking, Ch12).

4. Ghi chú

• Baseline lịch này khớp WBS v1.0 (66 work package, 1.927 ngày công) và Scope Statement v1.1.
• Demo cho HĐQT: 03/06/2026 (tuần 22).
• Scope Freeze: 13/07/2026 (tuần 28).

Cách dùng cho dự án của bạn

1. Bắt đầu từ WBS: gom work package thành 15–30 dòng lịch (đủ để trình bày, không quá chi tiết).
2. Xác định phụ thuộc (FS/SS/FF/SF) và các mốc bên ngoài (vendor, khách).
3. Tính đường găng, ghi float; đánh dấu crit trong Mermaid.
4. Loại trừ cuối tuần và ngày nghỉ của quốc gia/công ty trong excludes.
5. Cập nhật hằng tuần (ngày thực tế, % hoàn thành) và lưu baseline để so sánh.

C.5 Schedule (bảng ngày, phụ thuộc, float)

📎 Nguồn: templates/timeline-gantt/FoodNow-Schedule.csv (bảng dưới là bản đọc của tệp CSV; công thức Excel giữ nguyên trong tệp gốc).

C.6 Phiếu đường găng

📎 Nguồn: templates/timeline-gantt/critical-path-worksheet.md

Tên tài liệu: Phiếu tính đường găng (Critical Path Worksheet) Dự án: FoodNow MVP (ví dụ) và bài luyện tập Phiên bản / ngày: v1.0 — 27/02/2026 Mục đích & khi nào dùng: Tính tay ES/EF/LS/LF và float để tìm đường găng; dùng khi lập lịch hoặc khi cần đánh giá tác động của một task trễ.

1. Quy ước

• ES (Early Start): bắt đầu sớm nhất = lớn nhất EF của các task tiền nhiệm (0 nếu không có).
• EF (Early Finish) = ES + Duration.
• LF (Late Finish): kết thúc muộn nhất mà không làm trễ dự án = nhỏ nhất LS của các task hậu nhiệm (= EF lớn nhất của dự án nếu là task cuối).
• LS (Late Start) = LF − Duration.
• Float (Total Float) = LS − ES = LF − EF.
• Đường găng = chuỗi task có Float = 0; độ dài = tổng Duration = thời gian ngắn nhất để xong dự án.
• Quan hệ dùng: Finish-to-Start (FS) không lag.

2. Ví dụ mẫu (6 task)

Lượt đi (forward): A 0→3; B 3→7; C 3→5; D 7→12; E 5→8; F: ES = max(12, 8) = 12 → EF = 14. Lượt về (backward): F: LF = 14, LS = 12; D: LF = 12, LS = 7; E: LF = 12, LS = 9; B: LF = 7, LS = 3; C: LF = 9, LS = 7; A: LF = min(LS(B), LS(C)) = min(3, 7) = 3, LS = 0.

Đường găng: A → B → D → F = 14 ngày. C và E có float 4: trễ tới 4 ngày không ảnh hưởng dự án.

3. Bài luyện (8 task) — tự điền

Câu hỏi: (1) Đường găng và tổng thời gian? (2) Float của C, E, F? (3) Nếu D trễ 2 ngày thì sao? (đáp án ở cuối chương 12).

4. Đường găng của FoodNow (từ FoodNow-Schedule.csv)

Tổng chuỗi: 20 + 22 + 20 + 15 + 5 + 20 + 9 + 8 + 12 = 131 ngày làm việc.

Task gần găng (float 2–5 ngày làm việc): app Khách hàng, Nhà hàng, Tài xế, Backend (float 5); kiểm thử chức năng theo sprint (float 2). Theo dõi sát vì một trễ nhỏ biến chúng thành găng.

5. Hành động khi đường găng bị trễ

1. Xác định task nào và trễ bao nhiêu ngày làm việc.
2. Trễ trên đường găng ⇒ trễ dự án; hỏi: crashing (thêm nguồn lực cho task găng) hay fast-tracking (chạy song song các task vốn tuần tự)?
3. Ghi chi phí và rủi ro của từng lựa chọn; chọn với Sponsor.
4. Cập nhật lịch, RAID và báo cáo tuần.

Cách dùng cho dự án của bạn

1. Liệt kê task, Duration, tiền nhiệm (FS); vẽ mạng nếu cần.
2. Tính ES/EF từ trái sang phải; LS/LF từ phải sang trái.
3. Float = LS − ES; tô đậm task có Float = 0.
4. Ghi task gần găng (float ≤ 20% thời lượng) để theo dõi sát.
5. Tính lại mỗi khi có thay đổi lớn hoặc task găng bị trễ.

C.7 Product Roadmap

📎 Nguồn: templates/roadmap/FoodNow-Product-Roadmap.md

Tên tài liệu: Product Roadmap — FoodNow (MVP → R1 → R2) Dự án: FoodNow Phiên bản / ngày: v1.1 — 06/07/2026 (v1.0 ngày 13/03/2026) Mục đích & khi nào dùng: Trình bày hướng đi theo mục tiêu/kết quả, không cam kết ngày chi tiết; dùng cho lãnh đạo, đội và khách; cập nhật khi thông tin lớn thay đổi.

1. Nguyên tắc đọc roadmap này

• Là định hướng, không phải lịch cam kết. Ngày chi tiết chỉ có cho Now; Next chỉ có tháng/quý; Later chỉ có mục tiêu, không có ngày.
• Mỗi release có một mục tiêu kết quả (outcome) và một vài KR đo được; tính năng chỉ là cách đạt kết quả.
• Độ tin cậy giảm dần từ Now → Later.

2. Tổng quan (timeline)

timeline
    title FoodNow - lộ trình theo release
    2026 Q4 : MVP go-live 03/10/2026
            : Kênh đặt đồ ăn riêng, 3 app + Admin, thanh toán thẻ và COD
    2027 Q1 : R1 (dự kiến)
            : Khuyến mãi, đánh giá món
    2027 Q3 : R2 (dự kiến)
            : Ví điện tử, đặt món theo nhóm

3. Now – Next – Later

4. OKR theo release

Các KR của R1, R2 là giả thuyết cần kiểm chứng bằng dữ liệu sau MVP (Ch41); sẽ chỉnh khi có số liệu thật.

5. Ba phiên bản cho ba đối tượng

6. Lịch sử thay đổi

Cách dùng cho dự án của bạn

1. Bắt đầu từ mục tiêu kinh doanh, không từ danh sách tính năng; mỗi release có Objective + 2–3 KR.
2. Chia Now / Next / Later; không ghi ngày cho Later.
3. Ghi độ chắc chắn để người đọc không hiểu nhầm là cam kết.
4. Viết 3 phiên bản (lãnh đạo, đội, khách) từ cùng một nguồn.
5. Khi cập nhật, ghi rõ cái gì đổi, cái gì không đổi, vì sao ở bảng lịch sử thay đổi.

C.8 Release Plan

📎 Nguồn: templates/roadmap/FoodNow-Release-Plan.md

Tên tài liệu: Release Plan — FoodNow MVP, R1, R2 Dự án: FoodNow Phiên bản / ngày: v1.0 — 13/03/2026 (chỉnh 06/07/2026) Mục đích & khi nào dùng: Chuyển roadmap thành kế hoạch phát hành: mục tiêu, phạm vi, tiêu chí Go/No-Go và phụ thuộc từng release; dùng sau roadmap, trước Delivery Plan (Ch30).

1. Tổng quan release

2. Phạm vi từng release

3. Tiêu chí Go/No-Go từng release

4. Phụ thuộc và rủi ro

5. Lộ trình MVP → R1 → R2

flowchart LR
    M["MVP<br/>03/10/2026<br/>v1.0.0"] -->|"3 tháng dữ liệu<br/>+ ngân sách R1"| R1["R1<br/>Q1/2027"]
    R1 -->|"kết quả R1<br/>+ tuân thủ ví"| R2["R2<br/>Q3/2027"]
    M -.hypercare 4 tuần.-> H["Ổn định vận hành"]

6. Cách cập nhật mà không "lật kèo"

• Mọi thay đổi ghi vào bảng lịch sử của roadmap: đổi gì – không đổi gì – vì sao.
• Đổi thứ tự trong cùng release thì thông báo trong SteerCo; đổi release cho một mục lớn cần Sponsor duyệt.
• Không đổi ngày đã công bố cho Now; nếu bất khả kháng, thông báo sớm kèm phương án.

Cách dùng cho dự án của bạn

1. Liệt kê 3 release (hoặc nhiều hơn) với mục tiêu và cửa sổ thời gian ở mức quý.
2. Với mỗi release, viết tiêu chí Go/No-Go đo được (chất lượng, UAT, hiệu năng, vận hành, tuân thủ, kinh doanh).
3. Liệt kê phụ thuộc và rủi ro chính; chuyển vào RAID.
4. Đặt quy tắc cập nhật release plan; ai được duyệt thay đổi.
5. Khi chuyển sang lịch phát hành chi tiết (Delivery Plan), giữ nguyên mục tiêu và tiêu chí ở đây làm nguồn.

C.9 Roadmap dạng bảng

📎 Nguồn: templates/roadmap/roadmap.csv (bảng dưới là bản đọc của tệp CSV; công thức Excel giữ nguyên trong tệp gốc).