Files
sys-analysis-design/e-commerce/bid/30-implementation-plan.md
2026-09-08 12:35:40 +07:00

28 KiB
Raw Blame History

document, version, status, date
document version status date
bid-plan 1 draft 2026-09-06

Phần B — Kế hoạch triển khai & Tổ chức nhân sự

B7. Kế hoạch triển khai

B7.1 Tổng quan

Dự án được hoạch định với tổng thời lượng 7 tháng (timeline.durationMonths = 7), tương đương tổng nỗ lực 53,02 người-tháng (totals.grandMM = 53.02, đã gồm dự phòng rủi ro theo hạng mục), triển khai theo mô hình Agile/Scrum kết hợp (hybrid), bàn giao theo đợt (bid-config.methodology), với đội ngũ lõi tương đương 9 vị trí đồng thời (timeline.teamSize = 9, suy ra từ tổng MM và hệ số song song hoá parallelEfficiency = 0.85) và đỉnh điểm nhân sự huy động cùng lúc là 10 đầu người (staffing.peakHeadcount = 10, tương ứng staffing.peak = 9,5 FTE/tháng).

Vì bid-config.projectStartDate chưa được xác nhận và bid-config.projectDeadline/submissionDeadline đang để trống, chưa có mốc thời gian ấn định để đối chiếu tính khả thi (timeline.deadlineFit.fits = null). Kế hoạch dưới đây trình bày một lộ trình cơ sở (baseline) neo theo ngày minh hoạ, sẽ được cập nhật thành ngày thật ngay khi hai bên thống nhất ngày khởi động chính thức tại giai đoạn ký hợp đồng/kick-off — xem B7.5.

Toàn dự án được chia thành 6 giai đoạn triển khai chính (theo timeline.phases) cộng thêm 1 giai đoạn hậu dự án (Bảo hành, không tính vào 7 tháng thực hiện):

# Giai đoạn % nỗ lực Khoảng tháng Nỗ lực (MM)
1 Khởi động & Chuẩn bị 5% Tháng 0 – 0,5 2,65
2 Phân tích & Thiết kế chi tiết 15% Tháng 0,5 – 1,5 7,95
3 Phát triển (3 đợt/increment) 45% Tháng 1,5 – 4,5 23,86
4 Kiểm thử hệ thống, hiệu năng, bảo mật 15% Tháng 4,5 – 5,5 7,95
5 UAT & Đào tạo 12% Tháng 5,5 – 6,5 6,36
6 Go-live & Hỗ trợ ổn định 8% Tháng 6,5 – 7 4,24
7 Bảo hành (hậu dự án) — (12 tháng, bid-config.warrantyMonths) Sau go-live —

Trong giai đoạn Phát triển (45% nỗ lực, 3 tháng), phạm vi chức năng (mã CN-nn theo B2 và hạng mục WBS-nn theo cơ sở ước lượng) được chia thành 3 đợt bàn giao (increment) theo nguyên tắc ưu tiên các chức năng bắt buộc/MVP và các hạng mục nền tảng/rủi ro cao trước, tuân thủ mô hình bàn giao theo đợt đã mô tả tại B6.1–B6.2.

B7.2 WBS theo giai đoạn

Giai đoạn 1 — Khởi động & Chuẩn bị (2,65 MM)

  • Mục tiêu: thống nhất phạm vi chi tiết đợt 1, thiết lập nền tảng kỹ thuật và tổ chức dự án.
  • Hoạt động: họp kick-off song phương; xác nhận các số liệu nghiệệp vụ còn để ngỏ (ngưỡng hiệu năng, SLA, ngưỡng chi tiêu hạng thành viên — xem B6.6); thiết lập môi trường Dev/Staging/Production trên AWS (WBS-01); khởi tạo pipeline CI/CD (WBS-02); thiết lập công cụ quản lý dự án, kênh báo cáo.
  • Sản phẩm bàn giao: kế hoạch dự án chi tiết đã duyệt; 3 môi trường vận hành sẵn sàng; pipeline CI/CD hoạt động; biên bản kick-off có xác nhận các giả định nghiệp vụ.
  • Tiêu chí nghiệm thu mốc: Bên mời thầu xác nhận phạm vi đợt 1 bằng văn bản; môi trường Dev/Staging truy cập được; pipeline build-test-deploy chạy thành công lần đầu.
  • Vai trò tham gia: PM, SA, DEVOPS, BE (khởi tạo khung dự án).
  • Đầu vào cần từ Bên mời thầu: đầu mối liên lạc chính thức; xác nhận số liệu nghiệp vụ còn để ngỏ; quyền truy cập tài khoản hạ tầng cloud (nếu Bên mời thầu sở hữu tài khoản AWS).

Giai đoạn 2 — Phân tích & Thiết kế chi tiết (7,95 MM)

  • Mục tiêu: chốt thiết kế chi tiết cho toàn bộ phạm vi MVP trước khi phát triển đại trà.
  • Hoạt động: đặc tả nghiệp vụ chi tiết theo từng nhóm chức năng (Khách hàng/Seller/Admin — xem B2); thiết kế kiến trúc nền tảng dịch vụ & event backbone (WBS-03); thiết kế hệ thống bảo mật xuyên suốt (WBS-05 phần thiết kế); xây dựng design system & khung i18n/l10n (WBS-04); rà soát và chốt mô hình dữ liệu.
  • Sản phẩm bàn giao: tài liệu thiết kế chi tiết (kiến trúc, API, mô hình dữ liệu) cho phạm vi MVP; bộ design system dùng chung.
  • Tiêu chí nghiệm thu mốc: Bên mời thầu (hoặc đại diện nghiệp vụ) ký xác nhận thiết kế chi tiết (design sign-off); không còn điểm nghiệp vụ chưa rõ ảnh hưởng đến các hạng mục ưu tiên cao.
  • Vai trò tham gia: BA, SA, UIUX, PM; BE/FE tham gia rà soát tính khả thi kỹ thuật.
  • Đầu vào cần từ Bên mời thầu: phản hồi thiết kế trong thời hạn thống nhất tại kick-off; xác nhận các quy tắc nghiệp vụ đặc thù (hoa hồng, kỳ giữ tiền, hạng thành viên).

Giai đoạn 3 — Phát triển (23,86 MM, chia 3 đợt)

Mục tiêu chung: hiện thực hoá toàn bộ chức năng MVP theo B2, ưu tiên hạng mục nền tảng và bắt buộc trước, đồng thời duy trì bảo mật/hiệu năng xuyên suốt (WBS-05, WBS-06).

Đợt Nội dung chính (WBS/CN tham chiếu) Vai trò tham gia
Đợt 1 Nền tảng kiến trúc & tài khoản khách hàng: kiến trúc dịch vụ/event backbone (WBS-03), bảo mật nền tảng (WBS-05), định danh & tài khoản (WBS-18/CN-01, CN-03), danh mục & tìm kiếm đa seller (WBS-19/CN-04), giỏ hàng đa seller (WBS-20/CN-05) PM, SA, BA, BE, FE, UIUX, QA, DEVOPS
Đợt 2 Giao dịch lõi: checkout & tách đơn theo seller (WBS-21/CN-06), thanh toán (WBS-22/CN-07), tích hợp VNPay (WBS-11), Momo (WBS-12), OAuth mạng xã hội (WBS-16/CN-02), quản lý đơn hàng khách hàng (WBS-23/CN-08) PM, BA, SA, BE, FE, QA
Đợt 3 Vận hành sàn & tích hợp còn lại: đăng ký/KYC seller (WBS-32/CN-17), quản lý sản phẩm/tồn kho seller (WBS-33/CN-18), quản lý đơn hàng seller (WBS-34/CN-19), dashboard payout seller (WBS-35/CN-20), cấu hình hoa hồng (WBS-36/CN-21), commission engine & payout (WBS-37/CN-22), quản trị seller/catalog (WBS-38, WBS-39/CN-23, CN-24), xử lý tranh chấp (WBS-40/CN-25), vận chuyển & tích hợp GHN/GHTK (WBS-41, WBS-13, WBS-14/CN-26), MFA (WBS-42/CN-27), đổi trả (CN-09), wishlist/đánh giá/thông báo/khuyến mãi/loyalty/i18n/tiền tệ (WBS-25–WBS-31/CN-10–CN-16), tích hợp email/SMS (WBS-15), ngân hàng payout (WBS-17), admin dashboard (WBS-43), giám sát/logging/DR (WBS-07), hiệu năng/khả năng mở rộng (WBS-06) Toàn đội (PM, BA, SA, UIUX, BE, FE, QA, DEVOPS)
  • Sản phẩm bàn giao mỗi đợt: bản build chạy được trên môi trường Staging; demo trực tiếp với Bên mời thầu cuối mỗi đợt.
  • Tiêu chí nghiệm thu mốc: chức năng trong phạm vi đợt vượt qua kiểm thử đơn vị/tích hợp nội bộ; demo được Bên mời thầu ghi nhận không có lỗi chặn (blocker); không phát sinh yêu cầu thay đổi phạm vi ngoài quy trình Change Request (B6.3).
  • Đầu vào cần từ Bên mời thầu: tham dự demo cuối mỗi đợt và phản hồi trong thời hạn thống nhất; cung cấp tài khoản sandbox của các đối tác thanh toán/vận chuyển/ngân hàng nếu Bên mời thầu là bên đứng tên hợp đồng với đối tác đó.

Giai đoạn 4 — Kiểm thử hệ thống, hiệu năng, bảo mật (7,95 MM)

  • Mục tiêu: xác nhận toàn bộ phạm vi MVP đạt chất lượng đủ để đưa vào UAT.
  • Hoạt động: kiểm thử hệ thống đầu-cuối trên Staging; kiểm thử hiệu năng mô phỏng tải cao điểm (catalog/checkout); kiểm thử bảo mật (SAST/SCA đã chạy liên tục trong CI/CD, bổ sung kiểm thử xâm nhập/pentest theo B6.4); hoàn thiện giám sát/logging/DR (WBS-07).
  • Sản phẩm bàn giao: báo cáo kiểm thử hệ thống, hiệu năng, bảo mật; danh sách lỗi đã xử lý/còn tồn kèm mức độ nghiêm trọng.
  • Tiêu chí nghiệm thu mốc: không còn lỗi mức nghiêm trọng ảnh hưởng luồng giao dịch cốt lõi; ngưỡng hiệu năng/bảo mật đã xác nhận cùng Bên mời thầu tại kick-off đạt được (theo B6.8).
  • Vai trò tham gia: QA (chủ trì), BE, DEVOPS, SA.
  • Đầu vào cần từ Bên mời thầu: xác nhận ngưỡng hiệu năng/bảo mật chính thức (nếu khác giả định tại kick-off); phê duyệt kịch bản kiểm thử hệ thống.

Giai đoạn 5 — UAT & Đào tạo (6,36 MM)

  • Mục tiêu: Bên mời thầu xác nhận hệ thống đáp ứng nghiệp vụ thực tế; đội ngũ vận hành được đào tạo sử dụng.
  • Hoạt động: thực thi kịch bản UAT trên Staging với đại diện nghiệp vụ Bên mời thầu; đào tạo Platform Admin, Ops/CSR theo B9.1; hoàn thiện tài liệu bàn giao (B9.2); đào tạo & bàn giao (WBS-09).
  • Sản phẩm bàn giao: biên bản UAT (đạt/không đạt theo từng kịch bản); tài liệu hướng dẫn sử dụng theo từng nhóm người dùng; hồ sơ đào tạo.
  • Tiêu chí nghiệm thu mốc: toàn bộ kịch bản UAT bắt buộc đạt (pass), các lỗi phát sinh trong UAT ở mức không chặn go-live đã có kế hoạch xử lý; đại diện nghiệp vụ Bên mời thầu ký biên bản nghiệm thu UAT.
  • Vai trò tham gia: BA (chuẩn bị kịch bản/đào tạo), QA, PM; BE/FE hỗ trợ xử lý lỗi phát sinh trong UAT.
  • Đầu vào cần từ Bên mời thầu: bố trí đại diện nghiệp vụ tham gia UAT đúng lịch; xác nhận dữ liệu thử nghiệm (ẩn danh hoá) nếu cần dữ liệu đặc thù; sắp xếp nhân sự tham gia đào tạo.

Giai đoạn 6 — Go-live & Hỗ trợ ổn định (4,24 MM)

  • Mục tiêu: đưa hệ thống vào vận hành chính thức an toàn, ổn định trong giai đoạn đầu (hypercare).
  • Hoạt động: phê duyệt phát hành lên Production (theo quy trình CI/CD tại B6.5); chuyển đổi dữ liệu/khởi tạo dữ liệu vận hành nếu có; go-live; hỗ trợ tăng cường (hypercare) theo WBS-10.
  • Sản phẩm bàn giao: hệ thống vận hành chính thức trên Production; biên bản nghiệm thu tổng thể dự án; báo cáo hypercare.
  • Tiêu chí nghiệm thu mốc: hệ thống vận hành ổn định trên Production không có sự cố nghiêm trọng trong giai đoạn hypercare; Bên mời thầu ký biên bản nghiệm thu tổng thể — đây là mốc bắt đầu tính thời hạn bảo hành.
  • Vai trò tham gia: PM, DEVOPS, BE, QA (trực hỗ trợ).
  • Đầu vào cần từ Bên mời thầu: phê duyệt go-live; bố trí đầu mối tiếp nhận vận hành trong giai đoạn hypercare; xác nhận biên bản nghiệm thu tổng thể.

Giai đoạn 7 — Bảo hành (hậu dự án, 12 tháng)

  • Mục tiêu: đảm bảo hệ thống vận hành ổn định lâu dài sau go-live.
  • Hoạt động: khắc phục miễn phí lỗi phát sinh từ phạm vi đã bàn giao (không gồm yêu cầu thay đổi/bổ sung chức năng — xử lý qua Change Request tại B6.3); hỗ trợ theo mức độ sự cố (B9.4).
  • Sản phẩm bàn giao: báo cáo hỗ trợ định kỳ trong thời gian bảo hành.
  • Tiêu chí nghiệm thu mốc: kết thúc 12 tháng kể từ ngày nghiệm thu tổng thể (bid-config.warrantyMonths = 12) mà không có lỗi tồn đọng mức nghiêm trọng chưa xử lý.
  • Vai trò tham gia: đội hỗ trợ vận hành (quy mô nhỏ hơn đội dự án chính, theo cam kết SLA tại B9.4).
  • Đầu vào cần từ Bên mời thầu: báo lỗi qua kênh hỗ trợ đã thống nhất; phân biệt rõ lỗi hệ thống với yêu cầu thay đổi mới.

B7.3 Gantt & mốc bàn giao

Ngày trong sơ đồ dưới đây neo theo ngày minh hoạ D0 = 2026-10-01 (chưa phải ngày khởi động chính thức — bid-config.projectStartDate là [[CẦN ĐIỀN]]). Khi có ngày khởi động chính thức, toàn bộ ngày dịch chuyển tương ứng nhưng số tháng/MM mỗi giai đoạn giữ nguyên theo timeline.phases.

gantt
    dateFormat YYYY-MM-DD
    title Kế hoạch triển khai (minh hoạ theo ngày neo D0 = 2026-10-01, chờ xác nhận ngày khởi động chính thức)
    section Khởi động và Chuẩn bị
    Kick-off song phương              :milestone, m0, 2026-10-01, 0d
    Thiết lập môi trường & PMO         :p1, 2026-10-01, 15d
    section Phân tích và Thiết kế chi tiết
    Phân tích nghiệp vụ & thiết kế chi tiết :p2, after p1, 30d
    Chốt thiết kế (design sign-off)    :milestone, m1, 2026-11-15, 0d
    section Phát triển
    Đợt 1 - Nền tảng & tài khoản khách hàng :d1, after p2, 30d
    Demo đợt 1                        :milestone, m2, 2026-12-15, 0d
    Đợt 2 - Checkout, thanh toán       :d2, after d1, 31d
    Demo đợt 2                        :milestone, m3, 2027-01-15, 0d
    Đợt 3 - Seller/Admin/Tích hợp còn lại :d3, after d2, 29d
    Hoàn tất phát triển (code-complete) :milestone, m4, 2027-02-13, 0d
    section Kiểm thử hệ thống, hiệu năng, bảo mật
    Kiểm thử hệ thống/hiệu năng/bảo mật :p4, after d3, 30d
    section UAT và Đào tạo
    UAT cùng Bên mời thầu & đào tạo    :p5, after p4, 30d
    Nghiệm thu UAT                     :milestone, m6, 2027-04-14, 0d
    section Go-live và Hỗ trợ ổn định
    Go-live & hypercare                :p6, after p5, 15d
    Nghiệm thu tổng thể & go-live chính thức :milestone, m7, 2027-04-29, 0d
    section Bảo hành
    Bảo hành 12 tháng                 :warranty, 2027-04-29, 365d

Bảng mốc:

Mốc Ngày dự kiến (minh hoạ) Sản phẩm Tiêu chí nghiệm thu Gắn mốc thanh toán (C6)
M0 — Kick-off 2026-10-01 Biên bản kick-off, kế hoạch chi tiết Hai bên ký biên bản kick-off [[CẦN ĐIỀN: theo C6 — paymentMilestones chưa cấu hình]]
M1 — Design sign-off 2026-11-15 Tài liệu thiết kế chi tiết MVP Đại diện nghiệp vụ ký xác nhận thiết kế [[CẦN ĐIỀN]]
M2 — Demo đợt 1 2026-12-15 Build Staging: tài khoản, danh mục/tìm kiếm, giỏ hàng Demo không có lỗi chặn [[CẦN ĐIỀN]]
M3 — Demo đợt 2 2027-01-15 Build Staging: checkout, thanh toán, tích hợp cổng thanh toán Demo không có lỗi chặn [[CẦN ĐIỀN]]
M4 — Code-complete 2027-02-13 Toàn bộ chức năng MVP trên Staging Demo đợt 3 không có lỗi chặn [[CẦN ĐIỀN]]
M5 — Hoàn tất kiểm thử hệ thống 2027-03-15 Báo cáo kiểm thử hệ thống/hiệu năng/bảo mật Không còn lỗi mức nghiêm trọng [[CẦN ĐIỀN]]
M6 — Nghiệm thu UAT 2027-04-14 Biên bản UAT, tài liệu hướng dẫn sử dụng Toàn bộ kịch bản UAT bắt buộc đạt [[CẦN ĐIỀN]]
M7 — Go-live & nghiệm thu tổng thể 2027-04-29 Hệ thống vận hành chính thức, biên bản nghiệm thu tổng thể Vận hành ổn định qua hypercare, biên bản nghiệm thu ký [[CẦN ĐIỀN]]
M8 — Kết thúc bảo hành 2028-04-29 (M7 + 12 tháng) Báo cáo tổng kết bảo hành Hết 12 tháng, không tồn đọng lỗi nghiêm trọng [[CẦN ĐIỀN]]

Ghi chú: bid-config.paymentMilestones hiện để trống — cột "Gắn mốc thanh toán" sẽ được điền khi Phần C6 (Điều khoản thanh toán) được cấu hình cùng khách hàng/nội bộ.

B7.4 Phụ thuộc & đường tới hạn

  • Đợt 1 phụ thuộc vào việc chốt thiết kế kiến trúc nền tảng/event backbone (WBS-03) và bảo mật nền tảng (WBS-05) tại Giai đoạn 2 — đây là hạng mục phức tạp/rủi ro cao nhất (complexity XL, risk high) và nằm trên đường tới hạn của toàn bộ Giai đoạn Phát triển.
  • Đợt 2 (checkout/thanh toán) phụ thuộc vào Đợt 1 hoàn tất giỏ hàng đa seller; đồng thời phụ thuộc vào việc Bên mời thầu (hoặc đối tác của Bên mời thầu) cung cấp tài khoản sandbox VNPay/Momo đúng hạn — chậm trễ ở đầu vào này ảnh hưởng trực tiếp tiến độ demo đợt 2.
  • Giai đoạn Kiểm thử hệ thống phụ thuộc vào toàn bộ 3 đợt phát triển hoàn tất (code-complete); không thể bắt đầu kiểm thử hiệu năng đầy đủ trước khi toàn bộ luồng giao dịch cốt lõi sẵn sàng trên Staging.
  • Giai đoạn UAT phụ thuộc vào việc Bên mời thầu bố trí đại diện nghiệp vụ tham gia đúng lịch; thời gian phản hồi/nghiệm thu chậm hơn dự kiến sẽ kéo dài toàn bộ đường tới hạn của dự án tương ứng.
  • Go-live phụ thuộc vào kết quả UAT đạt và phê duyệt phát hành song phương.

Giả định về thời gian phản hồi của Bên mời thầu: kế hoạch trên giả định Bên mời thầu phản hồi các nội dung cần phê duyệt (thiết kế, demo, UAT) trong thời hạn hợp lý đã thống nhất tại kick-off; thời gian phản hồi kéo dài hơn giả định sẽ làm dịch chuyển toàn bộ các mốc phía sau tương ứng, không thuộc trách nhiệm của Nhà thầu.

B7.5 Deadline dự án

bid-config.projectDeadline và submissionDeadline hiện chưa được xác định, do đó timeline.deadlineFit.fits = null — chưa có cơ sở để đánh giá tính khả thi theo một hạn chót cụ thể. Kế hoạch cơ sở tại B7.1–B7.3 (7 tháng, đội ngũ tương đương 9 vị trí đồng thời, đỉnh điểm 10 đầu người) là lộ trình đề xuất khi không có ràng buộc thời gian bên ngoài.

Nếu Bên mời thầu ấn định một hạn chót cụ thể sau khi hồ sơ này được xem xét, Nhà thầu có thể đánh giá lại tính khả thi và, nếu cần rút ngắn, sẽ trình bày phương án tăng tốc dựa trên các đòn bẩy sau (không thay đổi tổng khối lượng công việc totals.grandMM = 53,02 MM, chỉ thay đổi cách phân bổ):

  • Tăng số lượng nhân sự song song ở các vai trò đang là nút thắt của giai đoạn Phát triển (BE, FE, QA) — mức tăng cụ thể sẽ được tính lại và nêu rõ khi có hạn chót thực tế.
  • Thu hẹp phạm vi đợt đầu (MVP tối giản hơn): lùi các chức năng gắn nhãn "Tùy chọn" tại B2 (đăng nhập mạng xã hội, hiển thị đa tiền tệ tham khảo) sang giai đoạn 2 sau go-live.
  • Chạy song song có kiểm soát: bắt đầu một phần kiểm thử hệ thống/hiệu năng song song với cuối Giai đoạn Phát triển đối với các module đã code-complete sớm (đợt 1, đợt 2), thay vì chờ toàn bộ đợt 3 hoàn tất.

Rủi ro đi kèm mọi phương án tăng tốc: tăng chi phí phối hợp và rủi ro tích hợp khi nhiều đợt phát triển chạy song song; giảm thời gian ổn định trước UAT nếu rút ngắn Giai đoạn 4; cần Bên mời thầu chấp thuận rõ ràng việc lùi phạm vi tùy chọn. Nhà thầu không đề xuất rút ngắn số tháng bằng cách thay đổi số liệu MM/effort đã tính — mọi phương án tăng tốc đều dựa trên tái phân bổ nguồn lực hoặc phạm vi, được thoả thuận minh bạch với Bên mời thầu trước khi áp dụng.


B8. Tổ chức nhân sự

B8.1 Sơ đồ tổ chức

flowchart TB
    SC["Ban chỉ đạo dự án\n(đại diện Nhà thầu + đại diện Bên mời thầu)"]
    PM["Quản lý dự án (PM)\nphía Nhà thầu"]
    POC["Đầu mối nghiệp vụ\nBên mời thầu"]

    SC --> PM
    SC -.-> POC

    PM --> BA["Nhóm Phân tích nghiệp vụ (BA)"]
    PM --> SA["Kiến trúc sư giải pháp (SA)"]
    PM --> UIUX["Nhóm Thiết kế UI/UX"]
    PM --> BE["Nhóm Phát triển Backend (BE)"]
    PM --> FE["Nhóm Phát triển Frontend (FE)"]
    PM --> QA["Nhóm Kiểm thử (QA)"]
    PM --> DEVOPS["Nhóm Hạ tầng & DevOps"]

    BA <--> POC
    QA <--> POC
    PM <--> POC

Chú giải: Ban chỉ đạo (đường chấm) họp định kỳ để ra quyết định cấp cao (phạm vi, tiến độ, ngân sách); PM là đầu mối vận hành hằng ngày phía Nhà thầu, làm việc trực tiếp với đầu mối nghiệp vụ của Bên mời thầu; BA và QA có tương tác trực tiếp với đầu mối nghiệp vụ khi cần xác nhận yêu cầu/UAT.

B8.2 Bảng vai trò & trách nhiệm

Vai trò Trách nhiệm chính Yêu cầu năng lực Nhân sự đề xuất
PM (Quản lý dự án) Điều phối tiến độ/phạm vi/rủi ro, đầu mối báo cáo, chủ trì demo và ceremonies [[CẦN ĐIỀN: số năm kinh nghiệm quản lý dự án CNTT tương tự, chứng chỉ PMP/PSM nếu HSMT yêu cầu]] [[CẦN ĐIỀN]]
BA (Phân tích nghiệp vụ) Đặc tả yêu cầu chi tiết, chuẩn bị kịch bản UAT, đào tạo nghiệp vụ [[CẦN ĐIỀN: kinh nghiệm phân tích nghiệp vụ thương mại điện tử/marketplace]] [[CẦN ĐIỀN]]
SA (Kiến trúc sư giải pháp) Thiết kế kiến trúc tổng thể, đảm bảo NFR (hiệu năng/bảo mật/khả năng mở rộng) [[CẦN ĐIỀN: kinh nghiệm kiến trúc microservices/event-driven quy mô lớn]] [[CẦN ĐIỀN]]
UIUX (Thiết kế UI/UX) Design system, trải nghiệm người dùng đa ngôn ngữ [[CẦN ĐIỀN]] [[CẦN ĐIỀN]]
BE (Phát triển Backend) Hiện thực hoá dịch vụ nghiệp vụ, tích hợp bên thứ ba, logic tính toán phức tạp (tách đơn, hoa hồng, payout) [[CẦN ĐIỀN: kinh nghiệm hệ thống thanh toán/PII]] [[CẦN ĐIỀN]]
FE (Phát triển Frontend) Giao diện web đáp ứng cho Khách hàng/Seller/Admin [[CẦN ĐIỀN]] [[CẦN ĐIỀN]]
QA (Kiểm thử) Kiểm thử đa lớp (đơn vị/tích hợp/hệ thống/hiệu năng/bảo mật/UAT hỗ trợ) [[CẦN ĐIỀN: chứng chỉ ISTQB nếu HSMT yêu cầu]] [[CẦN ĐIỀN]]
DEVOPS (Hạ tầng & vận hành) Môi trường AWS, CI/CD, giám sát/logging, DR/backup [[CẦN ĐIỀN: chứng chỉ AWS nếu HSMT yêu cầu]] [[CẦN ĐIỀN]]

Nhân sự chủ chốt đề xuất (PM, SA và các vai trò khác nếu Bên mời thầu yêu cầu nêu tên) cần đối chiếu CV/cam kết tham gia tại mục A6 — hiện bid-config.keyPersonnel để trống nên toàn bộ tên nhân sự trong bảng trên là [[CẦN ĐIỀN]].

B8.3 Staffing plan theo tháng

Đơn vị: FTE (người-tháng/tháng) — lấy nguyên văn từ staffing.byMonth trong bid/estimate.computed.json.

Vai trò M1 M2 M3 M4 M5 M6 M7 Tổng MM/vai trò (totals.mmByRole)
PM 0,61 0,49 0,46 0,46 0,49 0,47 0,49 3,48
BA 1,15 0,79 0,20 0,20 0,18 0,31 0,23 3,05
SA 1,16 0,72 0,23 0,23 0,25 0,14 — 2,73
UIUX 1,03 0,90 0,26 0,26 0,13 — — 2,58
BE 0,92 3,21 4,58 4,58 3,21 1,19 0,64 18,31
FE 0,47 1,65 2,37 2,37 1,65 0,61 0,33 9,47
QA 0,42 0,92 0,99 0,99 2,20 2,34 0,64 8,49
DEVOPS 1,73 0,45 0,41 0,41 0,58 0,49 0,86 4,92
Tổng FTE/tháng 7,49 9,13 9,50 9,50 8,69 5,55 3,19 53,02 (grandMM)

Đỉnh điểm huy động (staffing.peak) là 9,5 FTE/tháng vào M3–M4 (giai đoạn Phát triển cao điểm), tương đương 10 đầu người (staffing.peakHeadcount) khi quy đổi sang số lượng nhân sự vật lý cần huy động đồng thời (một số vai trò có FTE lẻ có thể do một người đảm nhiệm không trọn thời gian hoặc chia sẻ giữa các hạng mục). Từ M6 trở đi, nhân sự phát triển (BE/FE/SA/UIUX) giảm dần khi chuyển trọng tâm sang kiểm thử/UAT (QA tăng lên 2,20–2,34 FTE ở M5–M6), phù hợp với việc chuyển pha từ Phát triển sang Kiểm thử & UAT.

B8.4 RACI cho các hoạt động chính

Hoạt động PM BA SA BE/FE QA DEVOPS Đầu mối nghiệp vụ Bên mời thầu Ban chỉ đạo
Xác nhận phạm vi & thiết kế chi tiết A R R C C C C I
Phát triển từng đợt A C C R C I I I
Kiểm thử hệ thống/hiệu năng/bảo mật A I C C R R I I
UAT A R I C R I A I
Đào tạo & chuyển giao tài liệu R R I C C I C I
Go-live & phê duyệt phát hành A I C C C R A C
Yêu cầu thay đổi phạm vi (Change Request) R C C C I I R A
Báo cáo tiến độ định kỳ R I I I I I I A

(R = Thực hiện, A = Phê duyệt/chịu trách nhiệm cuối, C = Tham vấn, I = Được thông báo.)

B8.5 Cơ chế họp/báo cáo/escalation

  • Đồng bộ nội bộ đội dự án: họp ngắn theo chu kỳ ngắn (đồng bộ tiến độ hằng ngày/hằng tuần trong đội phát triển) — tần suất cụ thể thống nhất tại kick-off (xem B6.7).
  • Báo cáo tiến độ với Bên mời thầu: định kỳ (tuần/hai tuần — thống nhất tại kick-off), gồm tình trạng hạng mục, rủi ro, vấn đề cần quyết định.
  • Demo cuối mỗi đợt bàn giao: theo lịch tại B7.3 (M2, M3, M4).
  • Họp Ban chỉ đạo: định kỳ (ví dụ hằng tháng — [[CẦN ĐIỀN: tần suất chính thức]]) để ra quyết định vượt thẩm quyền PM (thay đổi phạm vi lớn, rủi ro nghiêm trọng, điều chỉnh tiến độ/ngân sách).
  • Escalation sự cố nghiêm trọng: theo kênh khẩn cấp mô tả tại B9.4 (mức độ Nghiêm trọng/Cao), áp dụng cả trong giai đoạn triển khai và giai đoạn bảo hành.

Nguồn: computed (timeline, staffing) + bid-config.methodology, bid-config.warrantyMonths; B2/B6 của bid/10-technical-proposal.md.