Cách Mình Quản Lý Dự Án

Quy trình GitHub, standup, pair development, và phối hợp team

Làm phần mềm mà không phối hợp tốt thì code hay mấy cũng vỡ. Quản lý dự án là cách mình đồng bộ công việc, phát hiện blocker sớm, và hỗ trợ nhau.

Nguyên tắc cốt lõi: Giao tiếp sớm, giao tiếp thường xuyên. Không bất ngờ.

GitHub là trung tâm dự án

GitHub không chỉ cho code -- nó là công cụ quản lý dự án của mình.

Cái gìỞ đâu
CodeRepository
TaskIssues
Thảo luậnComment trên Issue hoặc Discussions
DocumentationREADME, thư mục /docs
Bảng dự ánGitHub Projects

Issue để theo dõi task

Mọi task đáng kể nên là một GitHub Issue. Tạo issue rõ ràng:

## Title: [Loại] Mô tả ngắn

### Bối cảnh
Tại sao mình làm việc này? Link tới PRD hoặc issue cha.

### Tiêu chí chấp nhận
- [ ] Tiêu chí 1
- [ ] Tiêu chí 2

### Ghi chú kỹ thuật
Chi tiết implementation liên quan.

### Liên quan
- Blocks: #123
- Related to: #124
LabelDùng cho
featureChức năng mới
bugCái gì đó hỏng
enhancementCải thiện tính năng có sẵn
docsCập nhật documentation
choreBảo trì, dependency

Bảng GitHub Projects

┌─────────────┬─────────────┬─────────────┬─────────────┐
│   Backlog   │  Ready      │ In Progress │    Done     │
├─────────────┼─────────────┼─────────────┼─────────────┤
│ Việc tương  │ Đã ưu tiên  │ Đang được   │ Hoàn thành  │
│ lai, chưa   │ Sẵn sàng    │ làm         │ trong chu   │
│ bắt đầu     │ bắt tay vào │             │ kỳ này      │
└─────────────┴─────────────┴─────────────┴─────────────┘

Quy tắc:

  • Mỗi người chỉ một item "In Progress" -- tập trung hoàn thành, không phải bắt đầu
  • Tự di chuyển item -- giữ bảng cập nhật
  • Link PR tới issue -- dùng "Fixes #123" trong mô tả PR

Standup hàng tuần

Họp hàng tuần để đồng bộ tiến độ và blocker. Mỗi người chia sẻ:

  1. Đã xong -- thành quả từ standup trước
  2. Đang làm -- trọng tâm hiện tại
  3. Blocker -- cái gì đang cản trở

Giữ ngắn gọn: 2-3 phút mỗi người.

TốtTệ
"Xong keyword upload, PR đang chờ review""Làm mấy thứ"
"Bị block vì chưa có DataForSEO API access""Mọi thứ ổn"
"Hôm nay bắt đầu hiển thị kết quả""Tiếp tục làm"

Đừng đợi standup nếu bị block hoàn toàn, có gì khẩn cấp hỏng, hoặc cần quyết định nhanh. Nhắn team ngay.

Pair development

Hai người cùng làm trên một vấn đề. Không phải lúc nào cũng cần, nhưng cực kỳ hiệu quả cho:

Tình huốngLý do
Onboard thành viên mớiTruyền đạt kiến thức
Tính năng phức tạpHai góc nhìn bắt nhiều vấn đề hơn
Debug khóĐôi mắt mới giúp ích
Học công nghệ mớiKhám phá cùng nhau

Mô hình Driver/Navigator: một người gõ code, một người review và suy nghĩ trước. Đổi vai mỗi 20-30 phút.

Với Claude Code: một người prompt và review, người kia verify và test. Cả hai thảo luận approach trước khi prompt.

Pair từ xa: chia sẻ màn hình qua Discord/Google Meet, dùng VS Code Live Share. Nghỉ mỗi 45-60 phút.

Giao tiếp

KênhDùng cho
Slack/Team ChatCâu hỏi nhanh, cập nhật, link
GitHub IssuesThảo luận task, quyết định cần ghi lại
PR CommentsPhản hồi về code cụ thể
Video CallThảo luận phức tạp, pair

Async-first

Mình ưu tiên giao tiếp async -- tôn trọng thời gian tập trung, tạo bản ghi bằng văn bản, hoạt động xuyên múi giờ.

Tốt: "Khi nào rảnh, review PR #42 giúp mình nhé? Không gấp, cuối ngày cũng được."

Tệ: "Ê, bạn có ở đó không?" → đợi → "Hay mình call nhé?"

Hỏi đúng cách khi stuck

## Đang cố làm gì
Upload CSV và parse keywords

## Mong đợi
Keywords hiển thị trong bảng

## Thực tế
Error: "Cannot read property 'map' of undefined"

## Đã thử
1. Kiểm tra format CSV — đúng
2. Console log response — data là null
3. Check API endpoint — trả về 200

## Code liên quan
[link hoặc snippet]

Quản lý blocker

BlockerCách giải quyết
Đợi thông tinHỏi trực tiếp, đặt deadline
Bối rối kỹ thuậtNhờ giúp, pair với ai đó
Phụ thuộc bên ngoàiEscalate, tìm workaround
Cần quyết địnhMang các phương án đến người quyết định
1. Tự giải quyết (tối đa 30 phút)
2. Hỏi đồng đội
3. Hỏi team lead
4. Escalate lên stakeholder

Đừng loay hoay với một vấn đề hàng giờ. Nhờ giúp sớm tốt hơn stuck muộn.

Code review

Mọi PR nên được review trước khi merge.

Với tư cách tác giả: giữ PR nhỏ (dễ review hơn), viết mô tả rõ (cái gì và tại sao), tự review trước, phản hồi feedback nhanh.

Với tư cách reviewer: review trong 24 giờ (đừng block đồng đội), gợi ý cải thiện chứ không chỉ nêu vấn đề, approve hoặc request changes rõ ràng, tập trung vấn đề quan trọng chứ không chỉ style.

Review check:

  • Code làm đúng cái PR nói?
  • Bug hoặc edge case rõ ràng?
  • Code dễ hiểu?
  • Vấn đề bảo mật?
  • Theo pattern của mình?

Bàn giao

Khi chuyển công việc cho người khác, cần: trạng thái hiện tại, cách chạy, vấn đề đã biết, bước tiếp theo, file liên quan.

## Bàn giao: [Tên dự án]

### Trạng thái
MVP hoạt động. User upload keywords và thấy cluster.

### Đã xong
- [x] Luồng upload
- [x] Logic clustering
- [x] Hiển thị kết quả cơ bản

### Chưa xong
- [ ] Export CSV
- [ ] Progress indicator
- [ ] Xử lý lỗi cho file lớn

### Cách chạy
1. Clone repo
2. Copy .env.example → .env.local
3. Thêm API key (hỏi mình lấy DataForSEO creds)
4. bun install && bun run dev

### Vấn đề đã biết
- Clustering fail khi >5000 keywords (cần batching)
- Chưa có loading state

### File quan trọng
- src/app/api/cluster/route.ts — logic chính
- src/components/results-table.tsx — component hiển thị

### Thắc mắc?
Ping mình trên Slack.

Những lỗi hay gặp

Làm việc cô lập -- PR khổng lồ bất ngờ sau nhiều ngày im lặng. Push WIP, chia sẻ sớm, hỏi feedback thường xuyên.

Không cập nhật bảng -- bảng hiển thị sai, không ai biết đang làm gì. Cập nhật trạng thái issue khi bắt đầu và kết thúc.

Ngồi trên blocker -- "Mình stuck 2 ngày mới hỏi." Quy tắc 30 phút: stuck 30 phút thì nhờ giúp.

Giao tiếp mơ hồ -- "Mình đang làm cái kia" (cái kia là cái gì?). Cụ thể: nêu tên issue, file, vấn đề.

Checklist

Ổn nếu:

  • Ai cũng biết người khác đang làm gì
  • Blocker phát hiện nhanh
  • PR review trong 24 giờ
  • Bảng phản ánh thực tế
  • Standup ngắn gọn và hữu ích
  • Context được chia sẻ khi bàn giao

Cần sửa nếu:

  • Bất ngờ xảy ra thường xuyên
  • Hai người vô tình làm cùng một thứ
  • PR nằm chờ review nhiều ngày
  • Không ai biết cái gì đang bị block
  • Bàn giao bị mất thông tin