Tech Project Lead — Tổng kết: 5 bài học còn lại
Tổng kết series Tech Project Lead A -> Z: năm bài học sống lâu hơn từng dự án cụ thể, danh sách đọc đề xuất, và việc nên làm ngày mai.
Mục lục
- Bài 1 — vì sao artifact thắng anh hùng mỗi lần?
- Bài 2 — "viết trước khi nói" thật sự nghĩa là gì?
- Bài 3 — vì sao scope là đòn bẩy trung thực duy nhất?
- Bài 4 — tin cậy được xây theo tuần ra sao, không phải lúc launch?
- Bài 5 — vai trò thật sự là gì, dưới các artifact?
- Các bài học gộp lại thành một vai trò ra sao?
- Checklist tech PM production?
- Đọc gì sau series?
- Bạn nên làm gì ngày mai?
- Nếu dự án của tôi không khớp case study nào?
- Đi tiếp từ đây như thế nào?
Bạn bắt đầu series này vì muốn có những artifact thực dụng để dẫn dắt một dự án phần mềm. Bạn kết thúc, hy vọng, với những template thật sự dùng được và một cây quyết định để biết artifact nào sẵn sàng dùng vào lúc nào. Chương cuối ngắn theo thiết kế - năm bài học, một checklist, một danh sách đọc. Series ở lại; còn cuộc trò chuyện về dự án của bạn thì bắt đầu.
Bài 1 — vì sao artifact thắng anh hùng mỗi lần?
Mọi chương trong series đều theo dõi một failure mode kiểu anh hùng và một artifact giảm thiểu tương ứng. Pattern lặp đi lặp lại: team cố nhớ mọi thứ, engineer senior giữ ngữ cảnh trong đầu, manager bỏ 1-on-1 vì bận. Mỗi cái là một giải pháp anh hùng; và mỗi cái đều fail vào lúc người anh hùng rời đi.
Artifact - kickoff doc, RAID log, status report, ADR - là ký ức của team. Chúng sống sót qua việc người anh hùng rời. Chương checklist là index của các artifact mà team nên có và chương nào dạy từng cái.
Bài 2 — "viết trước khi nói" thật sự nghĩa là gì?
Một buổi họp bắt đầu bằng việc đọc một tài liệu một trang luôn thắng buổi họp khởi động lạnh. Tài liệu buộc người viết phải suy nghĩ rõ ràng; buổi họp khi đó trở thành biên tập, không phải khám phá. Văn hoá "six-pager" của Amazon và "writing first" của Stripe đều là những biểu đạt khác nhau của bài học này.
Trong series, mọi artifact đều là tài liệu. Status report, kickoff doc, ADR, và note 1-on-1 đều chia sẻ chung kỷ luật: viết khiến bạn chậm lại đủ để nghĩ; team nào viết thì ship nhanh hơn.
Bài 3 — vì sao scope là đòn bẩy trung thực duy nhất?
Thời gian bị cố định bởi lịch. Chất lượng bị cố định bởi chuẩn của bạn. Chi phí bị cố định bởi headcount. Đòn bẩy duy nhất bạn có thể kéo một cách trung thực trên dự án phần mềm là scope - cái bạn chọn ship và cái bạn chọn hoãn.
Mọi dự án trễ ngày đều trễ vì scope lớn hơn thời gian, và team không cắt. Chương scope cho khung tư duy (MoSCoW, iron triangle); case study cho thấy nó trong hành động. Kỹ năng tech lead senior là gọi tên trade-off ra to, không phải bảo toàn cảm xúc của mọi người về scope.
Bài 4 — tin cậy được xây theo tuần ra sao, không phải lúc launch?
Stakeholder tin một dự án ship status tuần tẻ nhạt hơn là một dự án có buổi launch xuất sắc. Nhịp tuần - status report, demo, retro - là cái xây dựng dần dần thành tin cậy. Một team kịp các cam kết nhỏ sẽ kiếm được tin cậy để cam kết những thứ lớn hơn.
Hệ quả: một status update bị lỡ tốn nhiều tin cậy hơn vài sprint goal lỡ nhưng được báo trung thực. Đáng tin ở việc nhỏ để được tin với việc lớn.
Bài 5 — vai trò thật sự là gì, dưới các artifact?
Artifact không phải là việc. Việc là giao tiếp: làm cho quyết định nhìn thấy được, làm cho trade-off rõ ra, làm cho con người được nghe. Artifact là phương tiện; còn việc là kết nối.
Đó là vì sao các chương người không phải tuỳ chọn dù không trực tiếp ship code. 1-on-1, các cuộc trò chuyện feedback, loop tuyển - đây là phương tiện qua đó capacity team được phát triển hoặc bị phí phạm.
Các bài học gộp lại thành một vai trò ra sao?
Các bài học xếp tầng thành một thực hành mà mọi tech lead senior cuối cùng đều phát triển:
flowchart LR
Comm[5. Giao tiếp] --> Trust[4. Tin cậy theo tuần]
Trust --> Scope[3. Scope là đòn bẩy]
Scope --> Write[2. Viết trước khi nói]
Write --> Artifact[1. Artifact thắng anh hùng]
Artifact --> Iterate[Lặp mỗi quý]
Iterate --> Comm
Vai trò là một vòng phản hồi: giao tiếp sinh ra tin cậy, tin cậy kiếm được quyền bảo vệ scope, kỷ luật scope tạo ra tài liệu, tài liệu thay anh hùng, và team cải thiện mỗi quý. Tech lead chạy được vòng này trong vài năm sẽ trở thành lãnh đạo senior mà không ai có thể hình dung tổ chức thiếu được - không phải nhờ một dự án xuất sắc, mà nhờ kỷ luật đều đặn.
Checklist tech PM production?
Cắt ra dán lên tường:
Trước kickoff, verify:
[ ] Bạn biết sponsor là ai và thành công trông như thế nào.
[ ] Bạn đã viết kickoff doc với out-of-scope rõ ràng.
[ ] Bạn đã nêu một Accountable cho mỗi quyết định lớn (RACI).
[ ] Bạn có ước lượng three-point, không phải số đơn.
[ ] Bạn dựng RAID log và review hàng tuần.
[ ] Bạn chọn phương pháp phù hợp với hình dạng việc.
[ ] Bạn viết roadmap dạng Now / Next / Later.
[ ] Bạn lên lịch 1-on-1 hàng tuần với mọi người báo cáo.
[ ] Bạn dựng nhịp status report tuần.
[ ] Bạn viết ADR cho các lựa chọn kiến trúc khó.
[ ] Bạn có checklist launch kèm plan rollback.
[ ] Bạn sẽ chạy retro không đổ lỗi vào cuối mỗi sprint.
Mười hai item, copy vào README của dự án bất kỳ. Danh sách là phần tẻ nhạt của quản lý dự án; làm chủ được danh sách tẻ nhạt chính là cái phân biệt tech project lead với engineer ước mình là một tech project lead.
Đọc gì sau series?
- Camille Fournier, The Manager's Path — hướng dẫn kinh điển cho engineer chuyển sang manager. Đọc một lần ở mỗi lần promote.
- Will Larson, An Elegant Puzzle — engineering management ở scale, gồm cả migration và reorg mà chương legacy chỉ phác qua.
- Lara Hogan, Resilient Management — phần con người của vai trò khi làm tốt.
- Michael Nygard, Release It! — đã được trích từ series System Design; là anh em vận hành về độ tin cậy của series này.
- Frederick Brooks, The Mythical Man-Month — viết năm 1975, vẫn còn liên quan đến mức đau đớn. "Thêm người vào một dự án trễ làm nó trễ hơn" là bài học mà chương cứu theo đuổi.
Bạn nên làm gì ngày mai?
Năm thói quen nhỏ biến series thành kỹ năng vĩnh viễn:
- Viết trước khi nói. Trước bất kỳ cuộc trò chuyện dự án nào, viết một đoạn tóm tắt; chia sẻ; rồi họp để tinh chỉnh, không phải để đọc.
- Refresh RAID log sáng thứ Hai. Năm phút mỗi tuần là đủ; kỷ luật quan trọng hơn format.
- Gửi status mỗi thứ Sáu. Cùng giờ, cùng format, ngay cả khi không có gì mới. Tính đáng tin xây dựng niềm tin.
- Giữ 1-on-1 cả khi bận. Đặc biệt là khi bận. Bỏ 1-on-1 là tín hiệu rằng ưu tiên đang ở chỗ khác.
- Đọc lại một chương mỗi tuần trong sáu tuần. Nhận biết quan trọng hơn nhớ thuộc; đọc lại có giãn cách thắng đọc một mạch.
Nếu dự án của tôi không khớp case study nào?
Bốn case study (cứu, MVP, legacy, vendor) phủ những hình phổ biến nhất. Khi dự án của bạn là một thứ khác - platform nghiên cứu, tool data nội bộ, dự án quy định - các chương foundation và lifecycle vẫn áp được. Case study là cái bạn lắp; còn artifact là gạch.
Pattern sống sót vì vấn đề bên dưới luôn lặp lại. Stakeholder bất ngờ bạn, scope creep, ngày trượt, người cần feedback. Các artifact giải những vấn đề này chạy được ở mọi hình. Khi có hình mới, cần case study mới; series chào đón pull request.
Đi tiếp từ đây như thế nào?
- Bắt đầu series: giới thiệu.
- Hub: checklist chạy dự án.
- Chọn case phù hợp tình huống hiện tại của bạn: cứu, MVP, legacy, vendor.
Cảm ơn bạn đã đọc series. Artifact là của bạn để giữ; dự án là của bạn để remix. Cuộc trò chuyện về cách bạn lead giờ đã trong tay bạn.