Mục lục

Lesson 1.2: Xác định phạm vi MVP

Học cách scope Backend Design System MVP đúng cách để ship được version đầu tiên trong 2 tuần

MVP
Scoping
Planning

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

Code:
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

#ComponentMô tảEffort
1API GuidelinesREST patterns, versioning, response format2-3 ngày
2Error FormatStandard error schema1 ngày
3Auth BaselineJWT/Session strategy1-2 ngày
4Logging/TracingStructured logs + trace propagation2 ngày
5Starter TemplateBoilerplate service với tất cả trên2-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
typescript:
// 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
typescript:
// 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
typescript:
// 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
typescript:
// 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
bash:
# 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 guide

Nguyê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ó:

  1. Cho một developer mới (hoặc giả vờ bạn là newbie)
  2. Đếm thời gian từ git clone đến curl localhost:3000/health trả về 200
  3. 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:

markdown:
# 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 members
Xem gợi ý

Priorities nếu hết thời gian:

  1. Response envelope - MUST HAVE
  2. Error format - MUST HAVE
  3. Starter template với 3 basics - MUST HAVE
  4. Full JWT implementation - CAN DEFER
  5. 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:

QuestionAPI GuidelinesError FormatAuthLoggingTemplate
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:

  1. Bạn phản hồi như thế nào?
  2. Làm sao để nói "không" mà vẫn giữ relationship tốt?
  3. 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:

  1. Valid concern hay resistance to change?
  2. Bạn sẽ argue như thế nào?
  3. 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 data field"

Câu 3 - Compromise:

  • Envelope là standard, nhưng data field 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:

  1. API Guidelines (response format, versioning)
  2. Error handling standard
  3. Auth baseline (JWT/Session)
  4. Logging format
  5. 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ớ

ConceptGiải thích
MVP Scope5 components, 2 weeks, 15-min onboarding
Component sizingNếu > 3 ngày, quá lớn
Success metricClone → Running service trong 15 min
Scope creepNói "v0.2" thay vì "no"

Key Takeaways

  1. Ship small, iterate: v0.1 trong 2 tuần tốt hơn "perfect" trong 6 tháng
  2. 5 components là đủ: API format, errors, auth, logging, template
  3. 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


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.

Tiếp tục Lesson 1.3 →

Quảng cáo
mdhorizontal