Tech Project Lead A -> Z: Series này dạy gì

Bạn có thể là một engineer giỏi suốt mười năm và vẫn lúng túng vào lần đầu được giao dẫn dắt một dự án. Không phải vì bạn không biết code - code mới là phần dễ - mà vì dẫn dắt là một kỹ năng hoàn toàn khác. Kỹ năng đó là quyết định ai làm gì, bảo vệ timeline, che chắn cho team khỏi hỗn loạn, và trò chuyện với những người chưa từng đọc một stack trace nào trong đời. Series này dạy đúng kỹ năng ấy qua hai mươi sáu chương, và mỗi chương đều khép lại bằng một template bạn có thể mang vào repo hoặc wiki của mình ngay ngày làm việc tiếp theo.

Vì sao engineer cần một series quản lý dự án riêng?

Có ba lý do chính.

Khoảng trống về template. Phần lớn bài viết kỹ thuật chỉ dạy code; phần lớn bài viết về quản lý dự án thì lại dạy quy trình. Khoảng giữa hai mảng đó - "kickoff doc trông cụ thể ra sao, ở dạng markdown để paste thẳng vào Confluence" - lại có rất ít tài liệu tốt. Series này lấp đúng khoảng trống đó, đi theo hướng artifact-first.

Khác biệt về từ vựng. Một engineer senior bước vào cuộc họp toàn PM sẽ nghe "RACI", "RAID log", "RAG status", "MoSCoW", "T-shirt sizing", "burndown" và cảm thấy như người ngoài cuộc. Bộ từ vựng này không khó, chỉ là chưa ai dạy gọn lại. Mỗi chương trong series sẽ định nghĩa các thuật ngữ và giải thích chúng xuất hiện từ đâu.

Niềm tin xây từ tài liệu. Một tech lead mới thường giành được niềm tin của team bằng sự rõ ràng trên giấy: status report trung thực, risk log luôn cập nhật, decision log nói được vì sao mỗi quyết định được đưa ra. Trong phần mềm, bạn dịch niềm tin thành code; trong quản lý dự án, bạn dịch niềm tin thành tài liệu. Series này dạy đúng các tài liệu đó.

Mỗi chương trả lời bảy câu hỏi nào?

Mỗi chương đều đi qua cùng bảy câu hỏi để bạn có thể đọc lướt trong vòng một phút:

1. Khi nào tình huống/artifact này thật sự xuất hiện? - trigger thực tế trong dự án, không phải định nghĩa giáo khoa.
2. Cái giá phải trả nếu bỏ qua hoặc làm sai là gì? - sự cố, deadline trễ, hay việc stakeholder nổi giận mà bạn có thể tránh được.
3. Phiên bản tối thiểu cho team 5 người trông như thế nào? - thứ nhỏ gọn nhất mà vẫn chạy được.
4. Phiên bản scale-up cho 50+ người thì khác ra sao? - những thứ thay đổi khi bạn lên quy mô nhiều team.
5. Template cụ thể là gì? - đoạn markdown, yaml, hay mermaid mà bạn có thể copy thẳng vào repo.
6. Failure mode và cách phát hiện? - những dấu hiệu cho thấy artifact đang bị bỏ rơi.
7. Khi nào không nên dùng? - cái bẫy over-engineering.

Khối code trong series này thường là template chứ không phải C#. Ở đâu mà series System Design cho bạn một đoạn đăng ký Program.cs, thì series này cho bạn một skeleton status-report.md.

Series được chia thành những nhóm chương nào?

Hai mươi sáu chương được chia thành bảy nhóm:

flowchart LR
    Start[00-introduction] --> Found[5 Foundations<br/>vai trò, ước lượng, rủi ro, comms, scope]
    Found --> Method[3 Methodology<br/>Scrum, Kanban, chọn cái nào]
    Method --> Life[6 Lifecycle<br/>kickoff -> launch -> retro]
    Life --> People[3 People<br/>1-1, tuyển dụng, feedback]
    People --> Artifact[2 Artifacts<br/>status report, ADR]
    Artifact --> Case[4 Case Studies<br/>cứu, MVP, legacy, vendor]
    Case --> End[24-checklist + 25-conclusion]

Các nhóm bổ sung cho nhau theo tầng: Foundations cung cấp bộ từ vựng; Methodology cho bạn nhịp độ làm việc; Lifecycle vẽ trọn timeline một dự án; People nói về team; Artifacts là dấu vết giấy tờ để lại; còn Case Studies cho thấy cả năm nhóm trên cùng vận hành ra sao trong một dự án thật.

Nên đọc theo thứ tự hay đọc theo bài toán?

Cả hai cách đều hợp lệ.

Đọc theo bài toán. Mở đúng chương đang gọi tên triệu chứng bạn đang gặp. Dự án đang vượt budget? Đọc ước lượng cơ bản và scope và đánh đổi. Stakeholder cứ bất ngờ mỗi tuần? Đọc stakeholder và comms và status report. Mỗi chương đều có thể đứng độc lập.

Đọc theo thứ tự, từ 00 đến 25. Trình tự được sắp xếp có chủ đích: Foundations giải thích vì sao, Methodology nói về nhịp độ, Lifecycle dẫn bạn đi xuyên suốt một dự án từ đầu tới cuối, còn Case Studies tái dựng vòng đời đó dưới các hình dạng khác nhau. Đọc trọn series mất khoảng một tuần buổi tối; phần thưởng là bạn sẽ nhận ra cùng những artifact ấy lặp lại trong mọi dự án bạn tham gia về sau.

Series ship template kiểu gì?

Mỗi chương kết thúc bằng một template có thể copy thẳng. Bạn sẽ gặp ba định dạng chính:

# Project Kickoff: {{ Tên dự án }}

## Vì sao bây giờ
{{ Một đoạn ngắn: điều gì vừa thay đổi khiến dự án này đáng làm lúc này. }}

## In scope
- {{ Tính năng 1 }}
- {{ Tính năng 2 }}

## Out of scope
- {{ Những thứ chủ động đẩy ra ngoài }}

## Hạn quyết định
{{ Ngày phải chốt commit hoặc huỷ }}

## Stakeholder
| Vai trò     | Tên            | RACI |
|-------------|----------------|------|
| Sponsor     | {{ Tên }}      | A    |
| Tech lead   | {{ Tên }}      | R    |
| Engineer    | {{ Tên }}      | R    |
| Design      | {{ Tên }}      | C    |
| Legal       | {{ Tên }}      | I    |

## Top 3 rủi ro
1. {{ Rủi ro + cách giảm thiểu }}
2. {{ Rủi ro + cách giảm thiểu }}
3. {{ Rủi ro + cách giảm thiểu }}

Template được giữ ngắn có chủ ý. Cách nhanh nhất để một dự án chạy được là có một artifact nào đó, kể cả sơ sài, thay vì không có gì cả - một kickoff doc 50 từ vẫn tốt hơn rất nhiều so với việc bỏ qua kickoff. Khi đã có bản thô, bạn cứ việc tinh chỉnh dần.

Series giả định bạn đang dùng stack nào?

Các ví dụ kỹ thuật trong series tham chiếu .NET (ASP.NET Core, EF Core) cho đồng bộ với những series xung quanh, nhưng bản thân các ý tưởng quản lý dự án không phụ thuộc vào stack. Một team Java, team Go, hay team thuần frontend đều có thể áp dụng từng chương mà không cần dịch lại. Khi cần minh hoạ tooling cụ thể - CI pipeline, incident runbook - chương sẽ chọn ví dụ .NET nhưng vẫn có nhắc tới phương án thay thế cho các stack khác.

Các case study sẽ tái dùng bối cảnh từ series System Design để dự án trở thành một bài tập về hình dạng thay vì phải đi giải thích lại domain từ đầu.

Bạn nên bắt đầu từ đâu vào ngày mai?

Nếu bạn có mười phút, hãy đọc PM vs EM vs TPM - chương đó nói về vai trò nào hợp với công việc bạn đang thực sự làm. Nếu có một giờ, đọc thêm ước lượng cơ bản và chọn ra một artifact để giới thiệu cho team trong tuần. Nếu có cả tuần, đọc từ 00 đến 14 - đoạn này phủ trọn methodology và lifecycle, sau đó các case study sẽ đọc nhanh hơn nhiều.

Series không phải sách giáo khoa cần đọc xong rồi gấp lại; nó là tài liệu tham chiếu để mở ra mỗi khi cần. Các artifact ở đây sẽ xuất hiện trong mọi cuộc review dự án, mọi cuộc họp stakeholder, mọi buổi postmortem bạn tham gia. Khi đã biết tên chúng, bạn có thể mô tả cả một dự án chỉ bằng một đoạn văn thay vì năm tiếng update tản mạn.