Project Management cho SWE 📊

Là một Software Engineer, bạn không chỉ nhận ticket và code. Kỹ năng tự quản lý, ước lượng thời gian, giao tiếp với Product, và điều phối trong team là thứ phân biệt một developer bình thường với một senior engineer thực sự. Bài này tổng hợp kinh nghiệm thực chiến, không lý thuyết suông.

1. Estimation — Khoa học của việc đoán mò có hệ thống

Estimation không bao giờ là con số chính xác. Đó là một bài toán xác suất, và mục tiêu là thu hẹp khoảng không chắc chắn.

Tại sao chúng ta luôn estimate sai?

• Planning Fallacy (Lỗi lập kế hoạch): Não người có xu hướng nhớ kịch bản tốt nhất và bỏ qua mọi thứ có thể sai.
• Optimism Bias: "Lần này chắc không có gì phức tạp đâu" — câu nói này đã chôn vùi cả ngàn sprint.
• Unknown Unknowns: Bạn không biết mình không biết cái gì. Legacy code, missing doc, API bên thứ ba có hành vi không giống document — không thể estimate trước được.

Các kỹ thuật Estimation thực tế

Planning Poker (cho nhóm): Mỗi người estimate độc lập, sau đó reveal cùng lúc. Khi có gap lớn (1 người cho 2 points, người khác cho 13 points), không phải để tranh luận ai đúng — mà để tìm hiểu rủi ro mà người kia thấy mà bạn chưa nhìn ra.

Three-Point Estimation (cho cá nhân):

Optimistic (O): Mọi thứ suôn sẻ, không có blocker
Realistic (R):  Trường hợp bình thường, có vài issues nhỏ
Pessimistic (P): Murphy's Law — mọi thứ có thể sai đều sai

Expected = (O + 4R + P) / 6

Ví dụ thực tế:

• Tích hợp Stripe Webhook: O=3 ngày, R=5 ngày, P=9 ngày
• Expected = (3 + 4×5 + 9) / 6 = 5.3 ngày → report "5-6 ngày"

Rule of "x1.5" đơn giản: Nếu bạn không có thời gian phân tích kĩ, hãy nhân con số ban đầu của bạn với 1.5. Nếu là task liên quan đến infrastructure/migration/legacy code thì nhân 2.

Định nghĩa "Done" rõ ràng trước khi estimate

"Done Done" (hoàn chỉnh thực sự) bao gồm:

• ✅ Code chạy đúng với happy path
• ✅ Unit tests / Integration tests
• ✅ Code Review (ít nhất 1 người approve)
• ✅ Deploy lên Staging, smoke test
• ✅ Tài liệu API hoặc README update nếu cần
• ✅ PM/QA confirm trên Staging

Nếu không có Definition of Done rõ ràng, estimate của bạn sẽ chỉ tính phần "code xong" — và đó là lý do mọi người hay "thiếu" 30-40% thời gian ở cuối.

2. Task Breakdown — Nghệ thuật chia nhỏ vấn đề

Nguyên tắc INVEST cho một User Story tốt

Một task/ticket tốt phải thỏa mãn:

Vertical Slicing vs Horizontal Slicing

Horizontal Slicing (tệ hơn):

Sprint 1: Tất cả DB Schema (2 tuần)
Sprint 2: Tất cả Backend API (2 tuần)
Sprint 3: Tất cả Frontend (2 tuần)

→ Không có gì để demo, không nhận feedback sớm, risk cao.

Vertical Slicing (tốt hơn):

Sprint 1: User có thể đăng ký và login (End-to-end)
Sprint 2: User có thể xem danh sách sản phẩm (End-to-end)
Sprint 3: User có thể thêm vào giỏ hàng (End-to-end)

→ Mỗi sprint có thể demo, ship sớm, nhận feedback sớm.

Spike Tasks — Khi bạn chưa biết estimate

Nếu một task quá mơ hồ để estimate (ví dụ: "Tích hợp với hệ thống legacy của đối tác, chưa có doc"), hãy tách ra một Spike Task:

• Giới hạn thời gian cố định: 1-2 ngày
• Kết quả không phải là code, mà là knowledge — bạn sẽ biết được nên estimate bao nhiêu, và kế hoạch tích hợp là gì.

3. Agile & Scrum Mindset thực chiến

Daily Standup hiệu quả

Chỉ cần trả lời 3 câu, mỗi câu tối đa 2 dòng:

1. "Hôm qua tôi đã làm gì?"
2. "Hôm nay tôi sẽ làm gì?"
3. "Tôi có bị block bởi điều gì không?"

❌ Sai lầm phổ biến: Dùng standup để báo cáo chi tiết kỹ thuật cho manager hoặc giải quyết vấn đề ngay tại chỗ. Nếu có issue cần bàn sâu, hãy nói "After standup chúng ta có thể nói thêm không?" và tách cuộc họp riêng.

Sprint Retrospective — Đừng bỏ qua nó

Retro không phải là "than vãn session". Cấu trúc tốt:

• What went well? (Khen ngợi, củng cố thói quen tốt)
• What didn't go well? (Khó khăn khách quan, không đổ lỗi cá nhân)
• Action items: tối đa 3 items, có người chịu trách nhiệm và deadline — không thì tuần sau lại mang ra hỏi lại.

Nợ kỹ thuật (Technical Debt) và Sprint Planning

Technical Debt cần được đưa lên backlog và estimate như feature thông thường, không phải làm âm thầm trong giờ rảnh. Cách thuyết phục PM:

• Không nói "Chúng ta cần refactor cho đẹp code" (PM không care).
• Nói "Nếu không giải quyết phần X, mỗi tính năng mới sẽ cần thêm 2 ngày để tích hợp vì codebase hiện tại gây ra bug type Y. Ước tính đến Q3 sẽ mất thêm 3 sprint nếu không fix."

4. Quản lý Dependencies & Critical Path

Nhận diện Critical Path

Trong một dự án, không phải mọi task đều quan trọng như nhau. Critical Path là chuỗi task mà nếu bất kỳ task nào bị delay, cả dự án bị delay.

Task A (2 ngày) → Task C (3 ngày) → Task E (1 ngày) → DONE
Task B (4 ngày) ↗                 Task D (2 ngày) ↗

→ B → C → E là Critical Path (tổng 8 ngày). A và D có "float" time — delay một chút không sao.

Tips thực tế: Luôn bắt đầu bằng task trên Critical Path vào đầu Sprint, không phải task dễ/thích làm trước.

Quản lý Dependency với team khác (Cross-team)

• Sync sớm: Nếu bạn cần API từ team khác, đừng đợi đến ngày cần mới hỏi. Ping họ sớm 2 tuần, thống nhất contract (API schema, error codes) trước khi cả hai bắt tay vào code.
• Dùng Consumer-Driven Contract Testing (Pact) để hai team có thể phát triển độc lập mà không lo break nhau.
• Tạo Mock/Stub sớm: Không cần đợi API thật, hãy mock trước để team mình tiến độ không bị chặn.

5. Communication với PM/Stakeholders

Nghệ thuật nói không chuyên nghiệp

Khi bị push deadline vô lý, đừng nói "Không được" hay "Được" một cách thiếu suy nghĩ. Hãy dùng Trade-off framework:

"Nếu anh/chị muốn ship trong 2 tuần thay vì 4 tuần, tôi có thể làm được, nhưng chúng ta phải bỏ các tính năng X và Y, và chấp nhận không có test coverage cho phần Z. Anh/chị muốn ưu tiên cái nào?"

Ba thứ luôn trong trạng thái cân bằng: Scope, Time, Quality. Muốn giảm Time thì phải giảm Scope hoặc giảm Quality. Không có cách nào khác.

Status Update hiệu quả

Khi cập nhật tiến độ cho PM/Manager, hãy dùng format RAG (Red/Amber/Green):

• 🟢 Green: Đúng tiến độ, không có vấn đề.
• 🟡 Amber: Có rủi ro, đang xử lý, cần theo dõi.
• 🔴 Red: Đang bị delay, cần quyết định từ phía management.

Đừng bao giờ báo cáo mãi "Green" rồi đột ngột "Red" vào cuối sprint. Ít nhất phải có "Amber" ở giữa để mọi người có thời gian phản ứng.

Ghi chép Meeting notes

Sau mỗi cuộc họp quan trọng, hãy gửi ngay một email/Slack tóm tắt:

• Những gì đã được quyết định
• Action items: ai làm gì, deadline khi nào
• Những vấn đề còn đang mở (Open Questions)

Đây không phải "việc của PM" — đây là kỹ năng tự bảo vệ bản thân để tránh "Ủa tôi tưởng mình quyết định thế này mà?"

6. Quản lý bản thân (Self Management)

Maker vs Manager Schedule

Developer cần "Maker Schedule" — các block thời gian dài liên tục (2-4 giờ) để đi vào trạng thái Deep Work. Một cuộc họp giữa buổi sáng không chỉ mất 30 phút — nó phá vỡ cả 2-3 giờ làm việc tập trung trước và sau.

Tips:

• Gom tất cả meeting vào buổi sáng hoặc chiều.
• Dùng "Do Not Disturb" block trên lịch để bảo vệ thời gian code.
• Tắt notification Slack trong giờ Deep Work, check 2-3 lần/ngày.

Tránh bẫy "Context Switching"

Mỗi lần bạn switch giữa task A và task B, não cần khoảng 15-20 phút để "warm up" lại context. Làm 5 task cùng một lúc thực ra chậm hơn làm tuần tự 5 task.

Rule của thumb: Không làm quá 2 task "active" trong cùng một ngày. Finish task trước khi pick task mới.