Bài 2: Project Scoping — thu hẹp phạm vi để hoàn thành

Sau bài này, bạn sẽ:

• ✅ Nhận ra khi nào scope quá lớn hoặc quá nhỏ
• ✅ Áp dụng phương pháp MVP first để xác định scope khả thi
• ✅ Dùng kỹ thuật MoSCoW để phân loại feature
• ✅ Lên timeline với time-box cứng
• ✅ Có template planning để dùng ngay cho project tiếp theo

Ước tính thông thường: khoảng 90% hobbyist project dừng lại ở giai đoạn 30–50% hoàn thành. Lý do không phải thiếu kiến thức — mà là scope ban đầu không thực tế.

Scope quá lớn

Các ví dụ phổ biến:

• "Build self-driving car AI" — 2 năm toàn thời gian chưa xong, bỏ giữa chừng.
• "Build ChatGPT clone" — OpenAI dùng cả trăm kỹ sư và hàng tháng training. Cá nhân không khả thi.
• "Build AI for everything" — quá rộng, không có điểm kết thúc, không có gì hoàn chỉnh.

Vấn đề thực sự: các mục tiêu này không có điều kiện "done" rõ ràng. Bạn không biết khi nào mình xong.

Scope quá nhỏ

Hai thái cực đối lập cũng có vấn đề:

• "Iris classifier" — dataset mặc định của mọi tutorial. Không cho thấy bạn có thể xử lý data thực.
• "Hello World API" — không có technical challenge, không có gì để nói trong interview.

Những project này dễ hoàn thành nhưng không tạo được nội dung để trình bày với nhà tuyển dụng.

Một project có scope phù hợp cho portfolio thỏa mãn đủ 4 điều kiện:

1. Hoàn thành được trong 4–8 tuần làm part-time (~10 giờ/tuần).
2. Có ít nhất 1 thử thách technical — không chỉ ráp code từ tutorial, phải tự giải quyết ít nhất 1 vấn đề không có sẵn đáp án.
3. End-to-end — từ data/input đến output cuối cùng, có thể demo được.
4. Có kết quả đo lường được — số liệu (accuracy, latency, recall...) hoặc demo URL hoạt động.

Một project đạt đủ 4 tiêu chí này, dù đơn giản, vẫn tốt hơn project phức tạp bỏ dở ở 70%.

MVP (Minimum Viable Product) là phiên bản nhỏ nhất của project vẫn chạy được end-to-end và có thể demo. Không phải "version tệ" — mà là version tập trung vào core value.

Step 1: Vision (1 câu)

Viết đúng 1 câu mô tả project. Nếu không viết được trong 1 câu, scope chưa rõ.

App cho phép user upload PDF + đặt câu hỏi → AI trả lời
dựa trên nội dung PDF đó.

Step 2: Cắt scope đến minimum

Lấy vision, rồi loại bỏ tất cả những gì không bắt buộc cho lần chạy đầu tiên:

• Chỉ support 1 PDF (không multi-document).
• Chỉ tiếng Anh (không multilingual).
• Chỉ Q&A đơn turn (không multi-turn conversation).
• Deploy single host, không scale.
• Không cần auth, không cần rate limit.

→ MVP scope: 2–3 tuần thay vì 6 tháng.

Step 3: Iteration plan sau MVP

Sau khi ship MVP, mỗi iteration thêm 1 layer:

• V1.1: multi-PDF — 1 tuần.
• V1.2: multilingual (thêm tiếng Việt) — 2 tuần.
• V1.3: multi-turn conversation — 1 tuần.
• V2.0: production hardening — auth + rate limit + monitoring — 3 tuần.

Mỗi iteration tự nó là 1 deliverable. Nếu bỏ dở ở V1.1, bạn vẫn có V1.0 hoàn chỉnh để show.

MoSCoW là framework phân loại feature theo mức độ ưu tiên. Tên viết tắt từ 4 nhóm:

Cách áp dụng

Bước 1: List tất cả feature bạn nghĩ đến — không lọc, cứ viết hết (~15–20 items).

Bước 2: Categorize mỗi feature vào 1 trong 4 nhóm.

Bước 3: MVP = chỉ Must have + tối đa 1–2 Should have dễ làm nhất.

Bước 4: Phần còn lại → ghi vào file BACKLOG.md, không xóa.

Ví dụ: PDF Q&A app

• Must have: upload PDF, parse text, embed + store vector, query → answer, deploy URL.
• Should have: hiển thị source chunk (câu trích dẫn từ PDF), basic error handling khi PDF không đọc được.
• Could have: highlight text trên PDF, lịch sử chat.
• Won't have (MVP): multi-PDF, auth, multilingual, mobile app, Slack integration.

Điểm quan trọng: "Won't have" không có nghĩa là không bao giờ làm. Nó có nghĩa là không làm trong MVP này. Viết rõ để khi bị hỏi trong interview, bạn giải thích được quyết định.

Time-box là kỹ thuật đặt deadline cứng cho từng feature hoặc task. Khi hết deadline mà chưa xong, bạn có 2 lựa chọn: simplify hoặc bỏ — không kéo dài thêm.

Nguyên tắc

• Mỗi feature có deadline tối đa 1 tuần làm part-time.
• Hết 1 tuần: nếu 80% done → deploy phần đó, tiếp tục. Nếu 0% done → re-scope, cắt thêm.
• "Good enough, deploy, iterate" — không phải "perfect, launch".

Tại sao cần deadline cứng

Không có deadline → Parkinson's Law: "work expands to fill the time available." Một feature lẽ ra làm 3 ngày có thể kéo dài 3 tuần nếu không có mốc cứng.

Ví dụ timeline 4 tuần

Tuần 1: Setup pipeline — PDF parse + embed + store (LangChain + ChromaDB)
         Deadline: cuối tuần 1, pipeline chạy được với 1 PDF thử nghiệm.

Tuần 2: Query + answer — gọi LLM, trả về câu trả lời có source chunk
         Deadline: cuối tuần 2, Q&A end-to-end trong terminal.

Tuần 3: UI đơn giản (Streamlit hoặc Gradio) + deploy Render/Hugging Face Spaces
         Deadline: cuối tuần 3, có public URL.

Tuần 4: Eval set (20 câu hỏi + expected answer), đo accuracy, viết README
         Deadline: cuối tuần 4, ship + ghi README.

Mỗi tuần kết thúc bằng 1 deliverable cụ thể. Nếu tuần 3 trượt deadline, tuần 4 bù không kịp — đây là signal scope vẫn còn lớn, cần cắt thêm.

So sánh 2 cách scope cùng 1 idea: RAG chatbot trên tài liệu.

Scope quá lớn (dự báo: abandon)

• Upload bất kỳ loại document: PDF, DOCX, HTML, code, video transcript.
• Hỗ trợ đa ngôn ngữ: EN, VI, ZH, JA.
• Multi-turn conversation với long-term memory.
• Production deploy với auth, rate limit, monitoring, analytics dashboard.
• Mobile app + web app + Slack bot.

Ước tính thực tế: 6 tháng+ làm full-time nếu bạn đã biết hết stack. Làm part-time: 1–2 năm. Kết quả phổ biến: bỏ dở ở tháng 2.

Scope MVP hợp lý (dự báo: ship được)

• PDF only, tiếng Anh only.
• Single-turn Q&A (hỏi một câu, nhận một trả lời).
• Deploy Render (free tier), public URL.
• Eval set cơ bản: 20 câu hỏi + expected answer, đo exact-match hoặc ROUGE-L.

Ước tính: 3–4 tuần làm part-time. Kết quả: có URL demo để show.

Roadmap iteration sau MVP

• V1.1 (+1 tuần): thêm multi-turn — lưu conversation history, truyền vào context.
• V1.2 (+2 tuần): thêm tiếng Việt — test chunking + embedding với text tiếng Việt.
• V2.0 (+3 tuần): production hardening — JWT auth đơn giản, rate limit bằng Redis, basic logging.

Điểm quan trọng cho interview: bạn có thể giải thích tại sao chọn scope này, trade-off là gì, và nếu có thêm 2 tuần bạn sẽ làm gì tiếp theo. Đây là cách tư duy của engineer, không phải hobbyist.

Scope không chỉ phụ thuộc vào idea — còn phụ thuộc vào constraints của bạn. Xác định 4 yếu tố này trước khi bắt đầu:

Ví dụ tính thực tế

Thời gian:   10h/tuần × 4 tuần = 40 giờ
Skill gap:   Chưa dùng LangChain → +20% buffer = 48 giờ ≈ 4.8 tuần
Chi phí:     Budget GPT-4o: $30 → dùng GPT-4o-mini cho dev, GPT-4o cho demo
Hardware:    MacBook M2, không GPU rời → không fine-tune, chỉ dùng API

→ Scope MVP: 4 tuần, dùng OpenAI API, không fine-tune model.

Số giờ thực tế không phải là điều bạn cần xin lỗi về. Scope phù hợp với constraints của bạn thì project mới hoàn thành được. Project 40 giờ hoàn chỉnh tốt hơn project 400 giờ dở dang.

Template dưới đây là file markdown đặt trong repo, đặt tên PLANNING.md. Điền vào trước khi viết dòng code đầu tiên.

# Project: [Tên project]

## Vision (1 câu)
[Mô tả app làm gì, cho ai, output là gì]

## Target user
[Ai sẽ dùng app này? Cụ thể 1 persona đủ rõ]

## Constraints
- Thời gian: __h/tuần × __ tuần = __ giờ tổng
- Skill gap: [liệt kê phần chưa biết]
- Budget API: $__
- Hardware: [CPU / GPU]

## MVP scope (Must have)
- [ ] Feature 1
- [ ] Feature 2
- [ ] Feature 3

## Out of scope cho MVP (Won't have)
- Feature X (lý do cắt)
- Feature Y (lý do cắt)

## Tech stack
- Model / API: ...
- Backend: ...
- Frontend / UI: ...
- Vector store: ...
- Deploy: ...

## Success criteria
- [ ] Metric 1: target value (vd accuracy >= 0.70 trên eval set 20 câu)
- [ ] Demo URL accessible và public
- [ ] README có hướng dẫn chạy local

## Timeline
- Tuần 1: [deliverable cụ thể]
- Tuần 2: [deliverable cụ thể]
- Tuần 3: [deliverable cụ thể]
- Tuần 4: deploy + README + eval

## Risks
- Risk 1: [mô tả] → Mitigation: [cách xử lý]
- Risk 2: [mô tả] → Mitigation: [cách xử lý]

Lưu ý: "Out of scope" list quan trọng không kém "MVP scope". Nếu không viết ra, mọi feature đều tự động trở thành Must have.

Những dấu hiệu dưới đây cho thấy scope ban đầu quá lớn hoặc cần re-scope ngay:

• Sau 2 tuần vẫn chưa có bất kỳ feature nào chạy được end-to-end.
• Tốc độ progress giảm dần qua các tuần (tuần 1 nhiều hơn tuần 2, tuần 2 nhiều hơn tuần 3).
• Bạn dành nhiều thời gian học hơn build — signal là skill gap lớn hơn ước tính.
• List task không ngắn lại theo tuần — mỗi feature done lại phát sinh 3 task mới.

Action khi phát hiện scope sai

1. Dừng coding.
2. Mở lại PLANNING.md, nhìn vào "MVP scope".
3. Cắt tiếp 50% feature — di chuyển xuống "Won't have".
4. Đặt lại deadline cho phần còn lại.
5. Resume.

Re-scope không phải thất bại. Không re-scope khi cần mới dẫn đến abandon.

Yak shaving

Dành thời gian setup và tune tool thay vì làm feature core. Ví dụ: bỏ 1 tuần cấu hình Kubernetes cho MVP có 0 user, hoặc bỏ 3 ngày chọn vector database tốt nhất thay vì dùng ChromaDB local và code tiếp.

Fix: pick reasonable default, tiếp tục. Optimize sau khi có user thực.

Feature creep

Thấy idea mới giữa project → thêm vào MVP. Ví dụ: đang code PDF parser, nghĩ ra "thêm luôn support DOCX", rồi "thêm luôn OCR cho ảnh", rồi "thêm luôn summary mode".

Fix: mọi idea mới → ghi vào BACKLOG.md, không add vào MVP. Đóng file backlog lại, tiếp tục làm feature hiện tại.

Premature optimization

Lo lắng về scale cho 1 triệu user khi MVP chưa có 1 user. Ví dụ: thiết kế caching layer phức tạp, load balancer, sharding database — khi app chưa deploy lần nào.

Fix: làm cho nó chạy đúng trước, tối ưu sau khi có benchmark thực.

Tool obsession

Dành 1 tuần so sánh các LLM, vector database, hoặc framework để chọn cái "tốt nhất". Kết quả: chậm bắt đầu, và thường chọn cùng default ban đầu sau khi so sánh xong.

Fix: pick 1 reasonable default (OpenAI API + LangChain + ChromaDB là stack đủ dùng cho MVP RAG), bắt đầu code ngay. Swap component sau nếu cần.

Cho solo project AI, không cần tool phức tạp. Thứ tự ưu tiên từ đơn giản đến phức tạp hơn:

1. Markdown file trong repo (PLANNING.md, BACKLOG.md) — đơn giản nhất, không cần tài khoản mới, nằm ngay trong codebase, commit cùng code. Phù hợp solo project.
2. GitHub Issues + Projects — nếu bạn đã dùng GitHub, dùng luôn Issues để track task, Projects cho kanban. Không cần tool ngoài.
3. Notion — nếu cần visualize roadmap hoặc chia sẻ với mentor/reviewer. Có template project sẵn.
4. Linear / Trello / Jira — hợp lý khi làm nhóm 2+ người. Solo thì overhead cao.

Recommendation: bắt đầu với markdown file trong repo. Nếu sau 2 tuần cảm thấy cần track nhiều hơn, chuyển sang GitHub Projects — không mất công migrate vì issue là text.

• ✅ Scope quá lớn → abandon. Scope quá nhỏ → không có gì để show.
• ✅ Sweet spot: hoàn thành 4–8 tuần, end-to-end, có ít nhất 1 thử thách technical, có result đo được.
• ✅ MVP first: cắt scope đến minimum runnable, iteration sau mới thêm feature.
• ✅ MoSCoW: phân loại Must / Should / Could / Won't — chỉ Must + tối đa 1–2 Should cho MVP.
• ✅ Time-box: deadline cứng mỗi tuần, hết deadline → simplify hoặc bỏ feature đó.
• ✅ Scope theo constraints thực tế: thời gian, skill gap, budget API, hardware.
• ✅ Re-scope sớm khi có dấu hiệu — không để drift đến abandon.
• ✅ Tránh: yak shaving, feature creep, premature optimization, tool obsession.

Bài 3: Cấu trúc portfolio cho AI Engineer trái ngành — sau khi có project hoàn chỉnh, trình bày portfolio thế nào để phù hợp với người không có background AI chính thống.