Thời lượng: 25 phút
Level: Beginner
Yêu cầu: Hoàn thành Lesson 1.1
Mục tiêu bài học
Sau bài học này, bạn sẽ:
- Biết cách xác định scope MVP hợp lý
- Có checklist 5 thành phần cần có trong MVP
- Có thể lập roadmap 2 tuần cho Design System MVP
Nội dung chính
1. MVP Scope - Ít hơn bạn nghĩ
Sai lầm phổ biến: Muốn build "hoàn hảo" từ đầu → Không bao giờ ship được
Đúng cách: Ship MVP trong 2 tuần, iterate dần
Sai: "Chúng ta cần 6 tháng để build Design System hoàn chỉnh"
Đúng: "Chúng ta cần 2 tuần để có version 0.1 usable"2. MVP Checklist - 5 thành phần bắt buộc
| # | Component | Mô tả | Effort |
|---|---|---|---|
| 1 | API Guidelines | REST patterns, versioning, response format | 2-3 ngày |
| 2 | Error Format | Standard error schema | 1 ngày |
| 3 | Auth Baseline | JWT/Session strategy | 1-2 ngày |
| 4 | Logging/Tracing | Structured logs + trace propagation | 2 ngày |
| 5 | Starter Template | Boilerplate service với tất cả trên | 2-3 ngày |
Tip: Nếu component nào không thể implement trong 3 ngày, nó quá lớn cho MVP.
3. Chi tiết từng component
3.1. API Guidelines (2-3 ngày)
Deliverables:
- Document 5-10 trang (không hơn!)
- Versioning strategy:
/v1/, headers, hay tất cả? - Response envelope standard
// Standard Response Envelope
interface ApiResponse<T> {
success: boolean;
data?: T;
error?: {
code: string;
message: string;
details?: Record<string, string>;
};
meta?: {
page?: number;
limit?: number;
total?: number;
};
}3.2. Error Format (1 ngày)
Deliverables:
- Error schema definition
- 20-30 common error codes
- Mapping to HTTP status codes
// Error Codes Catalog (MVP)
const ERROR_CODES = {
// 400 Bad Request
'VALIDATION_ERROR': 400,
'INVALID_INPUT': 400,
'MISSING_FIELD': 400,
// 401 Unauthorized
'UNAUTHORIZED': 401,
'TOKEN_EXPIRED': 401,
// 403 Forbidden
'FORBIDDEN': 403,
'INSUFFICIENT_PERMISSIONS': 403,
// 404 Not Found
'RESOURCE_NOT_FOUND': 404,
'USER_NOT_FOUND': 404,
// 500 Internal
'INTERNAL_ERROR': 500,
'DATABASE_ERROR': 500,
} as const;3.3. Auth Baseline (1-2 ngày)
Deliverables:
- JWT vs Session decision (document why)
- Token format và claims
- Middleware implementation
// JWT Payload Standard
interface JwtPayload {
sub: string; // User ID
email: string;
roles: string[];
iat: number; // Issued at
exp: number; // Expires at
iss: string; // Issuer
}
// Middleware example
function authMiddleware(req, res, next) {
const token = req.headers.authorization?.replace('Bearer ', '');
if (!token) {
return res.status(401).json({
success: false,
error: { code: 'UNAUTHORIZED', message: 'Missing token' }
});
}
// Verify and attach user...
}3.4. Logging/Tracing (2 ngày)
Deliverables:
- JSON log format
- Required fields (timestamp, level, traceId, etc.)
- Logger library wrapper
// Standard Log Format
interface LogEntry {
timestamp: string; // ISO 8601
level: 'debug' | 'info' | 'warn' | 'error';
message: string;
traceId: string; // For distributed tracing
spanId?: string;
service: string;
environment: string;
data?: Record<string, any>;
}
// Usage
logger.info('User created', {
userId: user.id,
email: user.email
});
// Output
{
"timestamp": "2026-01-15T09:00:00.000Z",
"level": "info",
"message": "User created",
"traceId": "abc-123-def",
"service": "user-service",
"environment": "production",
"data": { "userId": "123", "email": "user@example.com" }
}3.5. Starter Template (2-3 ngày)
Deliverables:
- Git repository template
- Pre-configured: logging, auth middleware, error handling
- Health check endpoint
- README với quick start guide
# Cấu trúc Starter Template
my-service-template/
├── src/
│ ├── index.ts # Entry point
│ ├── config/
│ │ └── index.ts # Environment config
│ ├── middleware/
│ │ ├── auth.ts # Auth middleware
│ │ ├── error-handler.ts # Error handler
│ │ └── logger.ts # Request logging
│ ├── routes/
│ │ └── health.ts # GET /health
│ └── utils/
│ ├── logger.ts # Logger wrapper
│ └── response.ts # Response helpers
├── Dockerfile
├── docker-compose.yml
├── package.json
├── tsconfig.json
└── README.md # QUAN TRỌNG: Quick start guideNguyên tắc then chốt
"MVP success metric: Developer mới có thể clone template và có service chạy trong 15 phút."
Đây là north star của bạn. Nếu mất hơn 15 phút, MVP quá phức tạp.
Test nó:
- Cho một developer mới (hoặc giả vờ bạn là newbie)
- Đếm thời gian từ
git cloneđếncurl localhost:3000/healthtrả về 200 - Nếu > 15 phút → Simplify
Thực hành
Bài tập 1: Lập MVP Roadmap 2 tuần
Mục tiêu: Tạo realistic roadmap cho Design System MVP
Template:
# Backend Design System MVP Roadmap
## Week 1
### Day 1-2: API Guidelines
- [ ] Define response envelope schema
- [ ] Document versioning strategy
- [ ] Write 5 example endpoints
### Day 3: Error Handling
- [ ] Define error schema
- [ ] Create error codes catalog (20 codes)
- [ ] Document error → HTTP status mapping
### Day 4-5: Auth & Logging
- [ ] Decide JWT vs Session (document decision)
- [ ] Define JWT payload schema
- [ ] Define log format
- [ ] Choose logging library
## Week 2
### Day 1-3: Starter Template
- [ ] Create repo từ scratch
- [ ] Implement health endpoint
- [ ] Add auth middleware
- [ ] Add error handler middleware
- [ ] Add logging middleware
### Day 4: Documentation
- [ ] Write README with quick start
- [ ] Document folder structure
- [ ] Add code examples
### Day 5: Validation
- [ ] Time "new developer" flow (target: 15 min)
- [ ] Fix friction points
- [ ] Get feedback từ 2-3 team membersXem gợi ý
Priorities nếu hết thời gian:
- Response envelope - MUST HAVE
- Error format - MUST HAVE
- Starter template với 3 basics - MUST HAVE
- Full JWT implementation - CAN DEFER
- Advanced logging - CAN DEFER
Bài tập 2: Checklist quyết định
Với mỗi component, trả lời câu hỏi:
| Question | API Guidelines | Error Format | Auth | Logging | Template |
|---|---|---|---|---|---|
| Có thể implement < 3 ngày? | |||||
| Có lib sẵn có thể dùng? | |||||
| Team đã có convention chưa? | |||||
| Có blocker dependencies? |
Tình huống thực tế
Scenario 1: Scope creep
Bối cảnh: Bạn đang làm MVP và đến Day 3, team lead muốn thêm:
- GraphQL support
- Database migration tool
- CI/CD pipeline setup
- Kubernetes configs
Câu hỏi:
- Bạn phản hồi như thế nào?
- Làm sao để nói "không" mà vẫn giữ relationship tốt?
- Những thứ nào có thể defer sang v0.2?
Xem phân tích
Câu 1 - Phản hồi: "Những features này rất valuable, nhưng nếu thêm vào MVP, chúng ta sẽ không ship được trong 2 tuần. Có thể plan cho v0.2?"
Câu 2 - Nói "không" professionally:
- Show data: "GraphQL thêm 1 tuần, template sẽ delay"
- Offer alternative: "v0.2 trong 2 tuần tiếp theo?"
- Get alignment: "MVP goal vẫn là 15-min onboarding, đúng không?"
Câu 3 - v0.2 candidates:
- GraphQL: v0.2
- DB migrations: v0.2
- CI/CD: v0.2 (hoặc separate initiative)
- K8s configs: v0.3
Scenario 2: Team không đồng ý
Bối cảnh: Senior developer trong team nói: "REST response envelope quá rigid, mỗi endpoint nên return format riêng cho flexible."
Câu hỏi:
- Valid concern hay resistance to change?
- Bạn sẽ argue như thế nào?
- Có compromise không?
Xem phân tích
Câu 1 - Valid concern: Partially valid - flexibility quan trọng, NHƯNG consistency quan trọng hơn cho client teams.
Câu 2 - Argument:
- "Frontend team phải handle 10 different formats → bugs"
- "Debugging harder khi không biết response shape"
- "Flexibility có thể achieve bằng
datafield"
Câu 3 - Compromise:
- Envelope là standard, nhưng
datafield hoàn toàn flexible - Special cases có thể request exception với documented reason
- Review exceptions quarterly
Câu hỏi phỏng vấn
Junior Level
Q1: MVP của Backend Design System nên bao gồm những gì?
Xem đáp án
Đáp án: 5 components:
- API Guidelines (response format, versioning)
- Error handling standard
- Auth baseline (JWT/Session)
- Logging format
- Starter template
Điểm cộng: Mention "15-minute onboarding" as success metric
Q2: Làm sao biết MVP scope đủ nhỏ?
Xem đáp án
Đáp án:
- Mỗi component implementable trong < 3 ngày
- Total MVP < 2 tuần
- Success metric: 15-min đến running service
Mid Level
Q1: Describe một lần bạn phải scope down project. Bạn decide giữ gì, bỏ gì?
Xem đáp án
Framework (STAR):
- Situation: Describe project và original scope
- Task: What was the constraint (time, resources)
- Action: How you prioritized (impact vs effort matrix)
- Result: What shipped, what deferred, outcome
Good answer mentions:
- Data-driven prioritization
- Stakeholder communication
- Clear defer vs drop distinction
Senior Level
Q1: Bạn có 2 tuần và 3 engineers để build Design System MVP. Plan?
Xem đáp án
Good answer:
Week 1:
- Engineer 1: API Guidelines + Error Format (solo, owns docs)
- Engineer 2: Auth middleware + Library selection
- Engineer 3: Logging library wrapper + Format definition
- Daily sync: 15 min standup
Week 2:
- All 3: Collaborative on Starter Template
- Day 4: Internal beta với 2 "customers" (other devs)
- Day 5: Iterate based on feedback
Key points:
- Parallel work week 1, converge week 2
- Built-in feedback loop
- Internal "customers" before ship
Tóm tắt
Những điều cần nhớ
| Concept | Giải thích |
|---|---|
| MVP Scope | 5 components, 2 weeks, 15-min onboarding |
| Component sizing | Nếu > 3 ngày, quá lớn |
| Success metric | Clone → Running service trong 15 min |
| Scope creep | Nói "v0.2" thay vì "no" |
Key Takeaways
- Ship small, iterate: v0.1 trong 2 tuần tốt hơn "perfect" trong 6 tháng
- 5 components là đủ: API format, errors, auth, logging, template
- Measure success: 15-minute onboarding là north star
Checklist hoàn thành
- Hiểu 5 MVP components
- Hoàn thành roadmap 2 tuần
- Có thể identify scope creep
- Trả lời được "làm sao để scope đủ nhỏ?"
Tài liệu tham khảo
- Shape Up - Basecamp - Methodology cho fixed-time projects
- MVP Guide - Y Combinator
Bước tiếp theo
Bài tiếp theo Lesson 1.3: Definition of Done sẽ dạy bạn cách define "hoàn thành" cho mỗi standard - đảm bảo chất lượng mà không over-engineer.