Gặp gỡ Bánh Mộc: dự án xuyên suốt chuỗi bài

Bản đồ công trìnhTờ này lắp: Sheet & sổ tay, Kênh bán, Màn hình bếp

Bài nàyĐã họcChưa tớiĐã thay thế

Bạn sẽ học được gì

Tiêu chí nghiệm thu

Nắm bối cảnh doanh nghiệp Bánh Mộc và vai trò của từng nhân vật trong chuỗi bài.
Mô tả nỗi đau vận hành của Bánh Mộc bằng con số, không chỉ bằng cảm giác.
Hiểu năm giai đoạn phát triển sản phẩm từ khám phá tới SaaS và mỗi giai đoạn gắn với module nào.
Đọc được sơ đồ dữ liệu tổng quan (ERD) và vòng đời trạng thái đơn hàng của Mộc OMS.
Biết tech stack tham chiếu và lý do chọn ở mức tổng quan.
Lập hồ sơ dự án tương tự cho bài toán của chính bạn.

Vì sao cần một dự án xuyên suốt

Học làm phần mềm qua các ví dụ rời rạc (“ứng dụng ghi chú”, “danh sách việc cần làm”) giống như học nấu ăn bằng cách mỗi buổi luộc một quả trứng. Bạn biết từng thao tác, nhưng không bao giờ thấy một bữa tiệc được chuẩn bị từ đầu đến cuối: lên thực đơn, đi chợ, sơ chế, nấu, bày biện, dọn dẹp.

Bánh Mộc là “bữa tiệc” đó. Cùng một doanh nghiệp, cùng các nhân vật, cùng một mô hình dữ liệu xuất hiện từ bài đầu tới bài cuối. Bạn sẽ thấy một quyết định ở module 04 (ví dụ: lưu tiền bằng số nguyên) bảo vệ hệ thống ra sao ở module 08 (test tính tiền cọc) và module 13 (tích hợp kế toán). Bạn sẽ thấy một lỗi bỏ qua ở module 09 có thể gây sự cố gì ở module 11.

Bánh Mộc là doanh nghiệp hư cấu, nhưng mọi nỗi đau của nó đều lấy cảm hứng từ những gì các cửa hàng bán lẻ nhỏ ở Việt Nam thường gặp. Có thể bạn sẽ nhận ra doanh nghiệp của mình trong đó.

Doanh nghiệp và các nhân vật

Bánh Mộc là chuỗi ba tiệm bánh ngọt thủ công tại TP.HCM, ở các khu vực Phú Nhuận, Thảo Điền và Gò Vấp. Sản phẩm chính gồm bánh kem đặt theo yêu cầu (chọn size, vị, chữ viết trên bánh), bánh mì ngọt bán hằng ngày và bánh quy đóng hộp quà. Bánh kem đặt trước được làm tập trung ở bếp trung tâm rồi chuyển tới các tiệm hoặc giao tận nơi.

Khoảng 25 nhân viên phục vụ trung bình 80–150 đơn mỗi ngày. Vào các dịp lễ như Trung thu, Noel, Tết, 14/2, 8/3, 20/10, lượng đơn tăng gấp ba tới bốn lần. Khách đặt qua Facebook Page, Zalo OA, điện thoại hoặc đến trực tiếp; Bánh Mộc đang muốn có thêm website đặt hàng.

Nhân vật	Vai trò	Trong chuỗi bài
Chị Lan (Nguyễn Thị Lan), 38 tuổi	Chủ chuỗi, từng làm marketer 10 năm, không biết lập trình	“Người học” đại diện cho bạn; đội ba chiếc mũ quản lý sản phẩm, kiến trúc sư, kiểm định viên
Anh Tuấn	Quản lý bếp trung tâm, làm bánh kem đặt trước cho cả ba tiệm	Người dùng chính của màn hình bếp; kiểm định viên cho mọi thứ liên quan tới sản xuất
Hà	Nhân viên bán hàng online, trực Facebook Page, Zalo OA, điện thoại	Người dùng nhiều nhất của form tạo đơn; kiểm định viên luồng nhận đơn
Khoa	Freelancer kỹ thuật, được thuê part-time từ giai đoạn mở rộng	Xuất hiện khi Bánh Mộc cần chuyên môn sâu hơn và cộng tác người + agent
Coding agent	“Đội thi công”	Viết phần lớn code theo spec, dưới sự chỉ đạo và kiểm chứng của chị Lan

Nỗi đau hiện tại

Một đơn bánh kem đi qua bao nhiêu tay

Để thấy nỗi đau, hãy theo dõi một đơn bánh kem sinh nhật điển hình trước khi có phần mềm.

Hình chữ ký Băng chuyền công đoạn

Hà trả lời, chép đơn vào Google Sheet
Hà nhắn anh Tuấn qua Zalo cá nhân
Anh Tuấn chép vào sổ tay bếp
Thợ bánh đọc sổ tay, viết chữ lên bánh
Nhân viên tiệm tìm đơn trong Sheet để thu nốt tiền
Cuối ngày: đối soát chuyển khoản, tiền mặt, tiền cọc

Xem sơ đồ gốc (Hình 1)

Vuốt ngang để xem hết sơ đồ

Khách nhắn Zalo OA:
bánh kem 20cm, vị chanh dây,
chữ ‘Mừng sinh nhật Bin 5 tuổi’,
nhận 17h thứ Bảy

Hà trả lời, chép đơn
vào Google Sheet

Hà báo chuyển khoản cọc,
chụp màn hình gửi nhóm Zalo nội bộ

Hà nhắn anh Tuấn
qua Zalo cá nhân

Anh Tuấn chép vào sổ tay bếp

Thợ bánh đọc sổ tay,
viết chữ lên bánh

Bánh chuyển tới tiệm Thảo Điền

Nhân viên tiệm tìm đơn
trong Sheet để thu nốt tiền

Cuối ngày: đối soát chuyển khoản,
tiền mặt, tiền cọc

Hình 1 Sơ đồ luồng

Đọc sơ đồ dạng chữ

Khách nhắn Zalo OA: bánh kem 20cm, vị chanh dây, chữ ‘Mừng sinh nhật Bin 5 tuổi’, nhận 17h thứ Bảy → Hà trả lời, chép đơn vào Google Sheet
Hà trả lời, chép đơn vào Google Sheet → Hà báo chuyển khoản cọc, chụp màn hình gửi nhóm Zalo nội bộ
Hà báo chuyển khoản cọc, chụp màn hình gửi nhóm Zalo nội bộ → Hà nhắn anh Tuấn qua Zalo cá nhân
Hà nhắn anh Tuấn qua Zalo cá nhân → Anh Tuấn chép vào sổ tay bếp
Anh Tuấn chép vào sổ tay bếp → Thợ bánh đọc sổ tay, viết chữ lên bánh
Thợ bánh đọc sổ tay, viết chữ lên bánh → Bánh chuyển tới tiệm Thảo Điền
Bánh chuyển tới tiệm Thảo Điền → Nhân viên tiệm tìm đơn trong Sheet để thu nốt tiền
Nhân viên tiệm tìm đơn trong Sheet để thu nốt tiền → Cuối ngày: đối soát chuyển khoản, tiền mặt, tiền cọc

Đơn này được chép tay ba lần (Sheet, tin nhắn, sổ tay) và đi qua năm người. Mỗi lần chép là một cơ hội sai: “Bin” thành “Bình”, 17h thành 7h, chi nhánh Thảo Điền thành Phú Nhuận. Mỗi lần chuyển tay là một cơ hội sót: tin nhắn Zalo bị trôi khi có hàng chục tin khác.

Nỗi đau được lượng hóa

Trước khi nghĩ tới phần mềm, chị Lan dành bốn tuần ghi chép lại mọi sự cố. Đây là bước quan trọng mà bạn sẽ học kỹ ở bài Bắt đầu từ vấn đề03-01: nếu không đo được nỗi đau hôm nay, bạn sẽ không bao giờ biết phần mềm có giúp được gì không. Các con số dưới đây là số liệu nội bộ chị Lan tự ghi nhận trong một tháng bình thường (không có ngày lễ lớn).

Nỗi đau	Biểu hiện	Đo trong 4 tuần	Hệ quả
Đơn rải rác, trùng, sót	Đơn nằm ở Sheet, sổ tay, Zalo cá nhân	9 đơn sót hoặc trùng	Khách đến nhận không có bánh; làm thừa bánh
Sai thông tin bánh kem	Chữ, size, vị, giờ nhận truyền miệng tới bếp	14 bánh sai chữ hoặc sai giờ	Làm lại bánh, giảm giá xin lỗi, mất khách
Không biết khách quen	Không có lịch sử mua, ngày sinh nhật	Không đo được	Không chăm sóc lại, không tri ân được khách lâu năm
Đối soát cuối ngày	Gộp chuyển khoản, tiền mặt, tiền cọc thủ công	1–2 giờ mỗi ngày mỗi chi nhánh	Quản lý về muộn; sai lệch tìm không ra nguyên nhân
Không có báo cáo	Không biết doanh thu theo chi nhánh, sản phẩm, kênh	Chị Lan mất nửa ngày cuối tháng để tổng hợp	Quyết định dựa trên cảm tính

Chị Lan quy đổi thành tiền một cách thận trọng: chi phí làm lại bánh sai, giờ công đối soát (1–2 giờ × 3 chi nhánh × khoảng 30 ngày, tức là 90–180 giờ công mỗi tháng), và giá trị những khách không quay lại. Con số tổng chị giữ trong sổ, nhưng kết luận rất rõ: chi phí của việc không có hệ thống lớn hơn nhiều so với chị tưởng, và ngày lễ còn nhân lên gấp bội.

Sản phẩm: từ “Mộc OMS” đến “MộcOS”

Tên sản phẩm có hai chặng. Mộc OMS (Order Management System, hệ thống quản lý đơn hàng) là công cụ nội bộ cho chính Bánh Mộc. MộcOS là phiên bản về sau, được đóng gói thành dịch vụ phần mềm (SaaS) bán cho các tiệm bánh khác.

Lộ trình năm giai đoạn

Giai đoạn	Module chính	Nội dung	Kết quả kỳ vọng
0 – Khám phá	M03	Phỏng vấn nhân viên, vẽ quy trình, viết PRD và spec, chọn phạm vi MVP	Biết chính xác cần xây gì và không xây gì
1 – MVP “Mộc OMS”	M04–M08	Quản lý đơn hàng, khách hàng, sản phẩm; đăng nhập theo vai trò; màn hình bếp cho bánh kem đặt trước; dashboard đơn hôm nay	Một nơi duy nhất cho mọi đơn; bếp nhận thông tin chính xác
2 – Ra mắt và vận hành	M09–M11	Deploy, tên miền `oms.banhmoc.vn`, thanh toán VietQR, thông báo Zalo ZNS và email, báo cáo doanh thu, giám sát lỗi	Cả ba chi nhánh dùng hằng ngày; đối soát nhanh
3 – Thêm AI	M12	Trợ lý AI trích xuất đơn từ tin nhắn Zalo/Facebook, tóm tắt phản hồi khách, gợi ý sản phẩm	Hà xử lý mùa lễ mà không cần thêm người
4 – Mở rộng	M13	Lên 10 chi nhánh và nhượng quyền; SaaS MộcOS đa khách hàng (multi-tenant); tích hợp hóa đơn điện tử, phần mềm kế toán	Phần mềm trở thành nguồn doanh thu mới

Vuốt ngang để xem hết sơ đồ

Phản hồi, số liệu

Bài học

Giai đoạn 0
Khám phá
(M03)

Giai đoạn 1
MVP Mộc OMS
(M04–M08)

Giai đoạn 2
Ra mắt và vận hành
(M09–M11)

Giai đoạn 3
Thêm AI
(M12)

Giai đoạn 4
Mở rộng, MộcOS
(M13)

Vuốt ngang để xem hết sơ đồ

Phản hồi, số liệu

Bài học

Giai đoạn 0
Khám phá
(M03)

Giai đoạn 1
MVP Mộc OMS
(M04–M08)

Giai đoạn 2
Ra mắt và vận hành
(M09–M11)

Giai đoạn 3
Thêm AI
(M12)

Giai đoạn 4
Mở rộng, MộcOS
(M13)

Hình 2 Sơ đồ luồng

Đọc sơ đồ dạng chữ

Giai đoạn 0 Khám phá (M03) → Giai đoạn 1 MVP Mộc OMS (M04–M08)
Giai đoạn 1 MVP Mộc OMS (M04–M08) → Giai đoạn 2 Ra mắt và vận hành (M09–M11)
Giai đoạn 2 Ra mắt và vận hành (M09–M11) → Giai đoạn 3 Thêm AI (M12)
Giai đoạn 3 Thêm AI (M12) → Giai đoạn 4 Mở rộng, MộcOS (M13)

Lưu ý giai đoạn 0 không có code. Đó là chủ ý: như bạn đã thấy ở bài Vòng đời phát triển phần mềm00-03, hiểu sai yêu cầu là loại sai lầm đắt nhất.

Tính năng MVP (giai đoạn 1)

MVP (Minimum Viable Product, sản phẩm khả dụng tối thiểu) của Mộc OMS gồm bảy tính năng:

Tạo, sửa, hủy đơn hàng, với mã đơn dạng BM-YYMMDD-XXX (ví dụ BM-261012-007 là đơn thứ 7 ngày 12/10/2026).
Trạng thái đơn đi theo vòng đời rõ ràng (xem sơ đồ dưới).
Quản lý khách hàng: tìm theo số điện thoại, xem lịch sử mua.
Danh mục sản phẩm: giá, bánh kem tùy chỉnh (size, vị, chữ trên bánh).
Màn hình bếp: danh sách bánh kem cần làm theo ngày và giờ nhận.
Vai trò: owner (chị Lan), manager (quản lý chi nhánh, anh Tuấn), staff (Hà, nhân viên tiệm).
Dashboard: đơn hôm nay theo trạng thái, theo chi nhánh.

Và quan trọng không kém, danh sách không làm trong MVP: chưa có website cho khách tự đặt, chưa tích hợp thanh toán tự động, chưa có trợ lý AI, chưa quản lý tồn kho nguyên liệu, chưa có app di động riêng (dùng web trên điện thoại). Danh sách “không làm” là thứ đã thiếu hoàn toàn trong app vibe năm trước. Bạn sẽ học cách lập nó ở bài MVP và ưu tiên tính năng03-04.

Vòng đời trạng thái đơn

Vuốt ngang để xem hết sơ đồ

Tạo đơn

Xác nhận (đã chốt, đã cọc nếu cần)

Bếp bắt đầu làm

Giao đi hoặc sẵn sàng cho khách nhận

Khách đã nhận, đã thanh toán đủ

Hủy

Hủy (xử lý tiền cọc)

Hủy (chỉ quản lý)

moi

da_xac_nhan

dang_lam

dang_giao

hoan_tat

da_huy

Hình 3 Máy trạng thái

Đọc sơ đồ dạng chữ

Bắt đầu → moi: Tạo đơn
moi → da_xac_nhan: Xác nhận (đã chốt, đã cọc nếu cần)
da_xac_nhan → dang_lam: Bếp bắt đầu làm
dang_lam → dang_giao: Giao đi hoặc sẵn sàng cho khách nhận
dang_giao → hoan_tat: Khách đã nhận, đã thanh toán đủ
moi → da_huy: Hủy
da_xac_nhan → da_huy: Hủy (xử lý tiền cọc)
dang_lam → da_huy: Hủy (chỉ quản lý)
hoan_tat → Kết thúc
da_huy → Kết thúc

Trạng thái lưu trong database bằng mã không dấu (moi, da_xac_nhan, dang_lam, dang_giao, hoan_tat, da_huy) và chỉ hiển thị tiếng Việt có dấu trên giao diện. Đơn chỉ hủy được trước khi sang dang_giao. Quy tắc ai được chuyển trạng thái nào, ai được hủy đơn đang làm, tiền cọc xử lý ra sao khi hủy, là những quy tắc nghiệp vụ sẽ được chốt trong spec ở module 03 và thiết kế ở module 04. Mọi lần đổi trạng thái đều được ghi vào bảng lịch sử, để biết ai đổi, lúc nào.

Mô hình dữ liệu tổng quan

Đây là bộ khung dữ liệu cốt lõi của Mộc OMS. Bạn chưa cần hiểu hết ký hiệu; bài Mô hình hóa dữ liệu04-02 sẽ giải thích chi tiết. Hãy đọc nó như sơ đồ tổ chức: mỗi hộp là một “cuốn sổ”, mỗi đường nối là một mối quan hệ.

Vuốt ngang để xem hết sơ đồ

branchesuuididPKtextnametextaddresstextphonestaffuuididPKuuidauth_user_idtextfull_nametextroleowner, manager, staffuuidbranch_idFKordersuuididPKtextcodeUKuuidcustomer_idFKuuidbranch_idFKtextchanneltextstatustextdelivery_typetimestamptzdelivery_atbiginttotalbigintdeposittextpayment_statuscustomersuuididPKtextfull_nametextphoneUKtextzalo_idtextaddressdatebirthdaytextnotetimestamptzcreated_atorder_itemsuuididPKuuidorder_idFKuuidproduct_idFKintquantitybigintunit_pricetextcake_messagejsonboptionsproductsuuididPKtextnametextcategorybigintpricebooleanis_custom_cakebooleanis_activepaymentsuuididPKuuidorder_idFKtextmethodbigintamounttimestamptzpaid_attextreferenceorder_status_historyuuididPKuuidorder_idFKtextfrom_statustextto_statusuuidchanged_byFKtimestamptzchanged_atcó nhân viênnhận đơnđặttạogồmđược đặt trongđược thanh toán quacó lịch sử

Hình 4 Sơ đồ thực thể

Đọc sơ đồ dạng chữ

branches — có nhân viên — staff
branches — nhận đơn — orders
customers — đặt — orders
staff — tạo — orders
orders — gồm — order_items
products — được đặt trong — order_items
orders — được thanh toán qua — payments
orders — có lịch sử — order_status_history
branches: id PK, name, address, phone
staff: id PK, auth_user_id, full_name, role, branch_id FK
customers: id PK, full_name, phone UK, zalo_id, address, birthday, note, created_at
products: id PK, name, category, price, is_custom_cake, is_active
orders: id PK, code UK, customer_id FK, branch_id FK, channel, status, delivery_type, delivery_at, total, deposit, payment_status
order_items: id PK, order_id FK, product_id FK, quantity, unit_price, cake_message, options
payments: id PK, order_id FK, method, amount, paid_at, reference
order_status_history: id PK, order_id FK, from_status, to_status, changed_by FK, changed_at

Sơ đồ trên lược bớt một số cột của bảng orders cho dễ nhìn. Danh sách đầy đủ của tám bảng:

Phiên agent

branches        (id, name, address, phone)
staff           (id, auth_user_id, full_name, role[owner|manager|staff], branch_id)
customers       (id, full_name, phone UNIQUE, zalo_id, address, birthday, note, created_at)
products        (id, name, category, price, is_custom_cake, is_active)
orders          (id, code UNIQUE, customer_id, branch_id, channel[facebook|zalo|phone|walk_in|website],
                 status, delivery_type[pickup|delivery], delivery_at, delivery_address,
                 subtotal, shipping_fee, total, deposit, payment_status[unpaid|deposit|paid],
                 note, created_by, created_at, updated_at)
order_items     (id, order_id, product_id, quantity, unit_price, cake_message, options JSONB)
payments        (id, order_id, method[cash|bank_transfer|vietqr], amount, paid_at, reference)
order_status_history (id, order_id, from_status, to_status, changed_by, changed_at)

Ba quy ước dữ liệu bạn sẽ gặp lại nhiều lần:

Tiền lưu bằng số nguyên VNĐ (kiểu bigint), không bao giờ dùng số thực. 350000 là ba trăm năm mươi nghìn đồng.
Thời gian lưu kèm múi giờ (kiểu timestamptz) và hiển thị theo giờ Việt Nam (Asia/Ho_Chi_Minh). Bạn đã thấy lỗi múi giờ trong mã đơn ở bài Lập trình đã thay đổi thế nào00-01.
order_items.unit_price lưu giá tại thời điểm đặt, không tham chiếu giá hiện tại của sản phẩm. Khi Bánh Mộc tăng giá bánh vào tháng sau, đơn cũ vẫn giữ đúng số tiền khách đã trả.

Tech stack tham chiếu

Tech stack là bộ công nghệ dùng để xây phần mềm. Chuỗi bài dùng thống nhất một bộ dưới đây trong mọi ví dụ. Lý do chọn chi tiết được phân tích ở bài Chọn tech stack04-06; ở đây chỉ là tổng quan.

Lớp	Công nghệ	Lý do chọn (tổng quan)
Ngôn ngữ	TypeScript	Một ngôn ngữ cho cả giao diện và máy chủ; kiểu dữ liệu giúp bắt lỗi sớm; AI rất quen thuộc
Framework web	Next.js (App Router), React	Phổ biến, tài liệu tốt, gộp frontend và backend trong một dự án
Giao diện	Tailwind CSS + shadcn/ui	Component nhất quán, mã nguồn nằm ngay trong repo để agent đọc và sửa
Database và đăng nhập	Supabase (PostgreSQL, Auth, Storage, Row Level Security)	PostgreSQL là database chuẩn, phổ biến; có sẵn đăng nhập và phân quyền ở tầng dữ liệu
Truy vấn và kiểm tra dữ liệu	Drizzle ORM, Zod	Định nghĩa bảng bằng TypeScript; kiểm tra dữ liệu đầu vào rõ ràng
Kiểm thử	Vitest, Playwright	Test nhanh cho logic; test trên trình duyệt thật cho luồng người dùng
Mã nguồn và CI	Git, GitHub (repo `banhmoc-oms`), GitHub Actions	Tiêu chuẩn ngành; agent làm việc tốt với Git và GitHub
Hosting	Vercel (ứng dụng), Supabase (database)	Triển khai đơn giản cho đội nhỏ, có bản xem trước cho từng thay đổi
Giám sát	Sentry (lỗi), PostHog (hành vi sử dụng)	Biết lỗi trước khi nhân viên gọi điện báo
Tích hợp	VietQR, Zalo OA/ZNS, email giao dịch (Resend hoặc tương đương)	Phù hợp thói quen thanh toán và liên lạc của khách Việt
AI coding	Coding agent dòng lệnh (ví dụ Claude Code), tương đương: Cursor, GitHub Copilot, OpenAI Codex, Gemini CLI	Nguyên tắc trong chuỗi bài áp dụng cho mọi agent

Tiêu chí chung đằng sau bộ công nghệ này là “nhàm chán” một cách có chủ đích: phổ biến, tài liệu tốt, dễ tuyển người, và AI đã “đọc” rất nhiều code viết bằng chúng. Bạn hoàn toàn có thể dùng bộ công nghệ khác cho dự án của mình; các nguyên tắc vẫn giữ nguyên.

Cấu trúc repo tham chiếu

Mã nguồn Mộc OMS nằm trong repo banhmoc-oms trên GitHub, với cấu trúc dưới đây. Mỗi thư mục sẽ được giải thích khi bạn tới module tương ứng; tạm thời chỉ cần để ý thư mục docs/, nơi chứa PRD, spec và quyết định kiến trúc, tức là “bộ nhớ dài hạn” mà cả người và agent cùng đọc.

Phiên agent

banhmoc-oms/
├── AGENTS.md              # hướng dẫn cho coding agent (có thể kèm CLAUDE.md trỏ tới)
├── README.md
├── docs/
│   ├── PRD.md
│   ├── specs/             # spec từng tính năng, ví dụ specs/tao-don-hang.md
│   └── adr/               # quyết định kiến trúc
├── src/
│   ├── app/               # Next.js routes (app router)
│   ├── components/        # component giao diện
│   ├── lib/               # tiện ích, kết nối db, auth
│   ├── db/                # schema Drizzle, migrations, seed
│   └── features/          # orders/, customers/, products/ ...
├── tests/
│   ├── unit/
│   └── e2e/
├── .env.example
└── .github/workflows/ci.yml

Áp dụng vào dự án Bánh Mộc

Nhật ký công trình · Bánh Mộc

BM-261013-005

13.10.2026

Chị LanChủ chuỗi
Anh TuấnBếp trung tâm
HàBán hàng online

Chị Lan đưa hồ sơ dự án một trang cho Hà, Hà giơ tay hỏi ngay về đơn qua điện thoại

Trước khi bước vào module 01, chị Lan viết “hồ sơ dự án một trang” để dán đầu thư mục docs/ và đọc lại mỗi khi bị cuốn vào chi tiết:

MARKDOWN

# Mộc OMS – Hồ sơ dự án (bản 0.1)

## Vấn đề
Đơn hàng rải rác ở Sheet, sổ tay, Zalo cá nhân → sót đơn, sai chữ trên bánh,
mất 1–2 giờ/ngày/chi nhánh để đối soát, không biết khách quen.

## Mục tiêu 6 tháng (đo được)
- Bánh kem sai chữ/sai giờ: từ 14 xuống dưới 3 trong 4 tuần
- Đơn sót/trùng: về 0
- Thời gian đối soát cuối ngày: dưới 20 phút/chi nhánh

## Người dùng
Hà (nhận đơn online), nhân viên 3 tiệm, anh Tuấn (bếp), chị Lan (quản lý)

## MVP gồm
Đơn hàng, khách hàng, sản phẩm, màn hình bếp, phân quyền 3 vai trò, dashboard hôm nay

## Không làm trong MVP
Website khách tự đặt, thanh toán tự động, AI, tồn kho, app di động riêng

## Nguyên tắc
Dữ liệu khách là trách nhiệm của Bánh Mộc. Tiền là số nguyên. Giờ là giờ Việt Nam.
Không phát hành trong 3 ngày trước ngày lễ.

Chị chia sẻ hồ sơ với anh Tuấn và Hà. Hà đọc xong hỏi ngay: “Chị ơi, khách đặt qua điện thoại thì em nhập ở đâu?” Câu hỏi đó trở thành mục đầu tiên trong danh sách câu hỏi cho buổi phỏng vấn ở giai đoạn 0. Chị Lan mỉm cười: hồ sơ dự án đã làm đúng việc của nó, là khơi ra câu hỏi trước khi viết dòng code nào.

Prompt mẫu

Dùng prompt dưới đây để lập hồ sơ dự án tương tự cho bài toán của bạn. Bạn sẽ dùng hồ sơ này làm dự án song song suốt chuỗi bài.

Giao việc cho agent

Tôi muốn lập "hồ sơ dự án một trang" cho một phần mềm nội bộ của doanh nghiệp tôi.
Bối cảnh: [ngành, quy mô, số chi nhánh/nhân viên, kênh bán, số giao dịch mỗi ngày].
Những gì tôi đang dùng: [Excel, Sheet, sổ tay, Zalo...].
Những gì tôi thấy đang có vấn đề: [mô tả tự do, chưa cần gọn].

Hãy PHỎNG VẤN tôi trước, mỗi lần một câu, tối đa 10 câu, để làm rõ:
nỗi đau cụ thể, ai chịu ảnh hưởng, đo được bằng con số nào, điều gì KHÔNG cần làm.

Sau đó viết hồ sơ theo các mục: Vấn đề, Mục tiêu 6 tháng (đo được), Người dùng,
MVP gồm, Không làm trong MVP, Nguyên tắc. Tối đa một trang.
Chỗ nào tôi chưa có số liệu, ghi rõ "CẦN ĐO" thay vì tự đặt con số.

Prompt thứ hai giúp bạn kiểm tra nhanh mô hình dữ liệu ban đầu cho dự án của mình:

Giao việc cho agent

Đây là danh sách các "cuốn sổ" (bảng dữ liệu) tôi nghĩ phần mềm của mình cần:
[liệt kê, ví dụ: khách hàng, đơn hàng, sản phẩm...].
Hãy vẽ sơ đồ ERD bằng Mermaid cho các bảng này, đề xuất các cột chính, và chỉ ra:
1. Quan hệ nào tôi có thể đã bỏ sót.
2. Dữ liệu nào nên lưu "tại thời điểm giao dịch" thay vì tham chiếu (ví dụ giá bán).
3. Cột nào chứa dữ liệu cá nhân cần bảo vệ.
Giải thích bằng ngôn ngữ cho người không chuyên.

Sai lầm thường gặp

Sự cố 01

Bắt đầu từ tính năng thay vì từ nỗi đau.

Triệu chứng

“Tôi muốn có dashboard đẹp” là tính năng; “tôi mất nửa ngày cuối tháng để tổng hợp doanh thu” là nỗi đau.

Cách tránh

viết nỗi đau và con số trước, tính năng sau, như bảng nỗi đau ở trên.
Sự cố 02

Không đo trước khi xây.

Triệu chứng

Không có số liệu “trước”, bạn không bao giờ chứng minh được phần mềm có ích.

Cách tránh

dành hai tới bốn tuần ghi chép sự cố bằng một Sheet đơn giản trước khi làm phần mềm.
Sự cố 03

Nhồi mọi thứ vào MVP.

Triệu chứng

Website, AI, tồn kho, thanh toán tự động, tất cả trong phiên bản đầu.

Cách tránh

chọn những tính năng giải quyết nỗi đau lớn nhất, viết danh sách “không làm” rõ ràng và dám giữ nó.
Sự cố 04

Thiết kế dữ liệu tùy hứng.

Triệu chứng

Trạng thái tự do, tiền lưu bằng chữ, giá không lưu tại thời điểm bán.

Cách tránh

thiết kế mô hình dữ liệu trước khi để agent viết code, dùng ba quy ước ở trên làm điểm khởi đầu.
Sự cố 05

Chọn công nghệ theo trào lưu.

Triệu chứng

Chọn công nghệ mới nhất vì nghe hấp dẫn, rồi không tìm được người hỗ trợ và AI viết code kém vì ít ví dụ.

Cách tránh

ưu tiên công nghệ phổ biến, ổn định; xem Chọn tech stack04-06.

Checklist

Tôi nhớ các nhân vật chính và vai trò của họ trong chuỗi bài.
Tôi kể được ít nhất bốn nỗi đau của Bánh Mộc kèm con số.
Tôi giải thích được năm giai đoạn phát triển từ khám phá tới MộcOS.
Tôi đọc được ERD tổng quan và biết tám bảng dữ liệu chính.
Tôi hiểu ba quy ước dữ liệu: tiền số nguyên, giờ có múi giờ, giá lưu tại thời điểm đặt.
Tôi biết tech stack tham chiếu và tiêu chí “nhàm chán có chủ đích”.
Tôi đã lập hồ sơ dự án một trang cho bài toán của mình.

Bài tập thực hành

Bài 1

Cơ bản

Theo dõi một giao dịch

Chọn một giao dịch điển hình trong doanh nghiệp của bạn (một đơn hàng, một lịch hẹn, một yêu cầu hỗ trợ). Vẽ sơ đồ nó đi qua bao nhiêu người, bao nhiêu công cụ, bị chép lại bao nhiêu lần, như sơ đồ đơn bánh kem ở trên.

Kết quả mong đợi

một sơ đồ (vẽ tay hoặc Mermaid) và danh sách các điểm có thể sai hoặc sót.
Bài 2

Cơ bản

Bảng nỗi đau

Lập bảng nỗi đau năm cột (nỗi đau, biểu hiện, cách đo, số liệu hiện có, hệ quả). Với cột số liệu, ghi “CẦN ĐO” nếu chưa có và bắt đầu một Sheet ghi chép trong hai tuần tới.

Kết quả mong đợi

ít nhất bốn nỗi đau, mỗi cái có cách đo cụ thể.
Bài 3

Nâng cao

Hồ sơ dự án và ERD đầu tiên

Dùng hai prompt mẫu để lập hồ sơ dự án một trang và ERD sơ bộ cho dự án của bạn. So sánh ERD với của Bánh Mộc: có bảng nào tương đương với order_status_history (lịch sử thay đổi) không?

Kết quả mong đợi

hồ sơ một trang có mục “không làm”; ERD có ít nhất bốn bảng và bạn chỉ ra được cột nào chứa dữ liệu cá nhân.

Thuật ngữ trong bài

OMS: Order Management System: hệ thống quản lý đơn hàng
SaaS: Software as a Service: phần mềm cho thuê qua internet, khách trả phí định kỳ
Multi-tenant (đa khách hàng): Một hệ thống phục vụ nhiều doanh nghiệp, dữ liệu mỗi bên tách biệt
MVP: Minimum Viable Product: phiên bản nhỏ nhất đủ để kiểm chứng giá trị
ERD: Sơ đồ thực thể và quan hệ: các bảng dữ liệu và cách chúng liên kết
Tech stack: Bộ công nghệ dùng để xây phần mềm
Repo (repository): Kho chứa mã nguồn và lịch sử thay đổi, ví dụ banhmoc-oms
Row Level Security (RLS): Cơ chế database tự kiểm soát ai được đọc/sửa từng dòng dữ liệu
VietQR: Chuẩn mã QR chuyển khoản liên ngân hàng tại Việt Nam
Zalo ZNS: Dịch vụ gửi thông báo theo mẫu đã duyệt qua Zalo

Đọc thêm

Supabase Docs và Next.js Docs: tài liệu chính thức của hai công nghệ nền tảng.
PostgreSQL Documentation: tài liệu database dùng trong Mộc OMS.
Bắt đầu từ vấn đề, không phải từ giải pháp03-01: giai đoạn 0 của Bánh Mộc.
Các giai đoạn trưởng thành của phần mềm13-01: hành trình Bánh Mộc từ Sheet tới MộcOS.

Nghiệm thu tờ 00-05

Đọc xong và tự kiểm theo phiếu nghiệm thu, rồi đánh dấu tờ này.

Tác giả

Phú Digital

Đội ngũ PDL Digital — triển khai website, giải pháp AI và digital marketing cho doanh nghiệp.

Một đơn bánh kem đi qua bao nhiêu tay

Nỗi đau được lượng hóa

Lộ trình năm giai đoạn

Tính năng MVP (giai đoạn 1)

Vòng đời trạng thái đơn

Bắt đầu từ tính năng thay vì từ nỗi đau.

Không đo trước khi xây.

Nhồi mọi thứ vào MVP.

Thiết kế dữ liệu tùy hứng.

Chọn công nghệ theo trào lưu.

Theo dõi một giao dịch

Bảng nỗi đau

Hồ sơ dự án và ERD đầu tiên

Muốn dựng phần mềm riêng cho doanh nghiệp của bạn?

Nhận tư vấn miễn phí

Nhận tư vấn
miễn phí