Team Lead

Tài liệu hướng dẫn này nhằm hỗ trợ các Developer phần mềm trong vai trò Team Lead của một team, bằng cách cung cấp những thông tin chi tiết về:

Thực chất vai trò này là gì.
Điểm khác biệt của nó so với vai trò các Developer khác trong team.
Kỳ vọng từ góc độ của Quản lý, cấp trên cũng như các developer khác trong team.

Nguyên tắc cốt lõi

Một phần quan trọng để hiểu rõ hơn về vai trò của Team Lead là có một sự nắm bắt tốt về các nguyên tắc cốt lõi cơ bản sau đây.

Hỗ trợ

Thứ nhất, các team có cấu trúc phẳng, trong đó không thành viên nào đứng trên thành viên khác về mặt thứ bậc. Thứ hai, các team vốn có tính liên chức năng, và do đó vai trò lãnh đạo được chia sẻ giữa nhiều cá nhân, cụ thể là Team Lead, CTO, và Product Manager. Mỗi người trong số này đều có một lĩnh vực tập trung và một bộ trách nhiệm. Vì vậy, sự hợp tác giữa tất cả các thành viên là cần thiết để triển khai project.

Với tư cách là người dẫn dắt phát triển trong một team, Team Lead trước tiên phải giúp đỡ các Developer đồng nghiệp của mình. Các Developer được khuyến khích dựa vào Team Lead để giải quyết các trở ngại trong nhiệm vụ của họ, dù đó là các vấn đề về kỹ thuật hay sản phẩm. Ở cấp độ tiếp theo, Team Lead phải báo cáo CTO để cung cấp các cập nhật kỹ thuật và báo cáo hiệu suất của các Developer trong suốt vòng đời của project. Cuối cùng, Team Lead phải hỗ trợ các bên liên quan bên ngoài bằng cách cung cấp hỗ trợ kỹ thuật và kỹ năng khi cần thiết.

Trọng tài trong quyết định Kỹ thuật

Bên cạnh lãnh đạo là phục vụ, tinh thần sở hữu team và tinh thần sở hữu cá nhân cũng là những nguyên tắc cốt lõi mà nên đề cao trong mọi lĩnh vực.

Mỗi Developer đều được khuyến khích tham gia và đóng góp vào mọi phần của quá trình phát triển sản phẩm. Dù đó là một đề xuất cải thiện UX/UI hay là phát hiện một vấn đề bảo mật, ý kiến của Developer đều được đánh giá ở cùng mức độ với Team Lead, CTO, và Product Manager.

Đồng thời, điều này không có nghĩa là mọi quyết định đều phải được thống nhất bởi toàn bộ team. Làm như vậy sẽ dẫn đến sự đình trệ và xích mích giữa các thành viên trong team, đặc biệt là giữa CTO và Team Lead. Một người ra quyết định là cần thiết ở phía kỹ thuật để đảm bảo tiến trình phát triển. Trong các team, Team Lead có tiếng nói cuối cùng và là người ra quyết định. Các Developer phải tôn trọng và tuân theo các quyết định đã được đưa ra, dù đó là việc lựa chọn một công nghệ cụ thể cho toàn bộ project hay một quyết định triển khai cụ thể cho một tính năng hoặc sửa lỗi.

Việc có một người ra quyết định không có nghĩa là có một nhà độc tài. Để trở thành một người lãnh đạo tốt, cần có sự tin tưởng, trung thực và cung cấp ngữ cảnh. Vì vậy, việc nhận được sự đồng thuận của team là rất quan trọng. Điều này đảm bảo rằng nếu (khi 😇) có điều gì đó không như ý, toàn bộ team sẽ được huy động để đảo ngược tình thế.

Vị trí Team Lead chỉ là tạm thời

Không có Developer nào đảm nhận vai trò Team Lead mãi mãi và trong mọi project mà họ tham gia. Các Developer được phân công vào vai trò này dựa trên cấp bậc của họ trong Lộ trình Phát triển Developer, bộ kỹ năng và sự phù hợp với project tại thời điểm đó. Phù hợp với cam kết phát triển cá nhân, vai trò Team Lead thường được giao cho các Developer ít kinh nghiệm hơn để tạo cơ hội học hỏi và thể hiện kỹ năng lãnh đạo.

Vai trò này thường kéo dài — trong hầu hết các trường hợp — cho đến khi kết thúc một chu kỳ 6 tháng. Khi kết thúc chu kỳ, một Developer mới sẽ được giao trọng trách trở thành Team Lead của team. Sau khi tái phân công vai trò, Team Lead cũ có thể vẫn ở lại trong cùng team với vai trò Developer hoặc luân chuyển sang một project khác, trong vai trò Team Lead hoặc Developer.

Đối với các project có thời gian ngắn hơn một chu kỳ xoay vòng, Team Lead hiếm khi được tái phân công để đảm bảo sự ổn định và tính liên tục cần thiết cho cả team và, quan trọng hơn, cho quá trình phát triển sản phẩm.

Vai trò Thực tiễn

Team Lead được kỳ vọng sẽ thực hiện các nhiệm vụ phát triển giống như tất cả các Developer khác trong team. Vì vậy, đây không phải là một công việc chỉ tập trung vào quản lý đội ngũ mặc dù tên gọi của vai trò là như vậy.

Về cơ bản, Team Lead phải kết hợp cùng các trách nhiệm giống như các Developer với một bộ trách nhiệm bổ sung (chi tiết bên dưới).

Trong thực tế, vì Team Lead không thể tập trung hoàn toàn vào các nhiệm vụ phát triển, một tốc độ công việc thấp hơn so với các Developer khác trong team là điều được mong đợi và chấp nhận như bình thường. Đảm nhận vai trò Team Lead luôn dẫn đến việc có ít thời gian hơn để thực hiện các nhiệm vụ phát triển. Tuy nhiên, cần lưu ý rằng điều này không phải là quy tắc cố định. Một Team Lead cũng có thể là Developer có hiệu suất lớn nhất. Điều này phụ thuộc vào bộ kỹ năng của các Developer trong team và loại project đang thực hiện.

Trách nhiệm

Hỗ trợ xậy dựng Backlog

Dù Product Manager chịu trách nhiệm chính về backlog, Team Lead phải phối hợp chặt chẽ và liên tục với Product Manager của team để thực hiện các hoạt động tinh chỉnh backlog.

Trước tiên, Team Lead phải xem xét các yêu cầu của bất kỳ requirement hoặc feature mới nào được thêm vào. Phản hồi này là rất quan trọng để đảm bảo các requirement hoặc feature sẵn sàng cho các Developer tiếp nhận trong sprint. Nếu cần thay đổi, Team Lead phải hợp tác với Product Manager để cải thiện các requirement hoặc feature và/hoặc tạo thêm các requirement hoặc feature mới.

Tiếp theo, sau khi xem xét, Team Lead cũng phải ước tính ban đầu cho bất kỳ requirement hoặc feature mới nào được thêm vào để Product Manager có thể đánh giá khối lượng công việc cần thiết và lập kế hoạch cho các sprint trong tương lai dựa trên tốc độ làm việc của team. Tất cả các requirement hoặc feature phải được ước tính trước khi bắt đầu các sprint trong tương lai.

Cuối cùng, Team Lead cần đưa ra các nhiệm vụ định hướng kỹ thuật cho Product Manager để chúng được ưu tiên trong backlog. Trong các quy trình quản lý backlog, điều này bao gồm việc tạo các epic công việc và viết các nhiệm vụ công việc cho project. Giải quyết technical debt, thay đổi kiến trúc ứng dụng và cải tiến test cases phải được thực hiện liên tục để xây dựng các ứng dụng mạnh mẽ. Team Lead được giao trọng trách đảm bảo rằng chất lượng codebase không ngừng cải thiện và kiến trúc ứng dụng phát triển cùng nhịp với sản phẩm.

Buổi Sprint Planning, được lên lịch mỗi sprint, là quy trình xem xét cốt lõi trong đó Product Manager và Team Lead gặp gỡ và thảo luận về các sprint sắp tới. Ngoài phiên họp này, khi có bất kỳ thay đổi hoặc lo ngại nào trong sprint, Team Lead chịu trách nhiệm hợp tác với Product Manager để thay đổi kế hoạch phát triển nếu cần và cung cấp thông tin.

CTO không chịu trách nhiệm về việc lập kế hoạch phát triển hàng ngày — đó là trách nhiệm của Team Lead. Tuy nhiên, trong trường hợp có thay đổi và lo ngại, Team Lead có thể phối hợp với CTO để thảo luận và quyết định các phương án và lựa chọn triển khai kỹ thuật.

Dẫn dắt để hoàn thành Sprint

Khi một sprint đã được lên kế hoạch bắt đầu, Team Lead chịu trách nhiệm đảm bảo các mục tiêu của sprint được hoàn thành, đồng thời đáp ứng các tiêu chuẩn chất lượng cao nhất trong tất cả các lĩnh vực phát triển.

Hiệu quả của Backlog

Phân công nhiệm vụ cho các Developer là trách nhiệm duy nhất của Team Lead. Cả Product Manager và CTO đều không can thiệp vào việc này. Team Lead chịu trách nhiệm phân công nhiệm vụ một cách chiến lược cho các Developer trong team, cân nhắc giữa yêu cầu của sprint, bộ kỹ năng và kiến thức chuyên môn của từng Developer, và nhu cầu đa dạng hóa loại nhiệm vụ được giao cho từng Developer để đảm bảo tính sở hữu team. Điều này có nghĩa là một Developer không bao giờ nên chỉ được giao một loại nhiệm vụ duy nhất, ví dụ như chỉ làm frontend hoặc chỉ làm backend.

Trong quá trình phân công các mục backlog một cách hiệu quả, Team Lead cũng phải quyết định những nhiệm vụ nào phù hợp để mình thực hiện nhằm đạt được các mục tiêu của sprint nhưng vẫn đảm bảo không ảnh hưởng đến các trách nhiệm bổ sung. Nếu làm sai nhiệm vụ, Team Lead có thể trở thành điểm nghẽn, gây ra sự chậm trễ hoặc dẫn đến thực hiện kém trong các quy trình xem xét mã, tích hợp mã và phát hành.

Trong suốt sprint, Team Lead cũng chịu trách nhiệm ưu tiên các mục backlog. Product Manager thường lên kế hoạch một hỗn hợp các tính năng, lỗi và công việc, và sắp xếp thứ tự ban đầu cho tất cả các mục backlog. Tuy nhiên, Team Lead có thể thay đổi thứ tự thực hiện các mục backlog nếu điều đó hợp lý hơn về mặt kỹ thuật. Điều kiện duy nhất là thời gian của sprint và danh sách kết quả phải tuân theo định nghĩa của Product Manager.

Hoàn thành Mục tiêu Sprint

Sau khi các mục backlog đã được phân công, Team Lead phải theo dõi tiến độ của các Developer hàng ngày. Trong thực tế, các Developer nên chủ động báo cáo tiến độ và các vấn đề gặp phải, nhưng Team Lead cũng phải chủ động hỏi về trạng thái công việc của các Developer. Nếu một Developer chưa bắt đầu nhiệm vụ mới sau vài ngày vì vẫn bị mắc kẹt ở một nhiệm vụ, điều này có thể làm lệch khỏi khả năng hoàn thành cam kết của sprint của Team Lead.

Team Lead cũng phải đảm bảo rằng việc ước lượng điểm của mỗi mục backlog tương ứng với nỗ lực thực tế mà các Developer bỏ ra. Sự không chính xác liên tục sẽ ngăn cản việc sử dụng tốc độ làm việc như một chỉ số dự đoán của Product Manager. Bằng cách theo dõi tiến độ hàng ngày, Team Lead có thể nắm bắt tốc độ thực tế của team phát triển và điều chỉnh kịp thời.

Quản lý & review code

Mọi Developer trong team phải xem xét tất cả các yêu cầu kéo (pull requests) bất kể số lượng phê duyệt cần thiết để hợp nhất yêu cầu kéo. Việc xem xét mã là cần thiết để đảm bảo không chỉ chất lượng mã mà còn giúp mỗi Developer hiểu rõ mọi phần của ứng dụng. Team Lead phải đảm bảo rằng tất cả các Developer trong team đang xem xét các yêu cầu kéo một cách nhất quán và kịp thời. Bất kỳ sự thất bại nào từ một Developer có thể làm chậm sprint và làm mất cân bằng khối lượng công việc xem xét mã của các Developer khác. Trên thực tế, Team Lead phải liên tục khuyến khích các Developer ưu tiên việc xem xét mã và tập trung cả team vào các yêu cầu kéo có mức độ ưu tiên cao nhất.

Theo nguyên tắc trọng tài trong quyết định kỹ thuật, Team Lead có tiếng nói cuối cùng về các thay đổi phát sinh trong quá trình xem xét mã và phải được thực hiện để hợp nhất một yêu cầu kéo. Trong một team có ba Developer trở lên, có thể xảy ra các trường hợp đề xuất nhiều hướng triển khai khác nhau. Quyết định cuối cùng sẽ thuộc về Team Lead, người sẽ thông báo quyết định này. Trên thực tế, các Developer cũng được khuyến khích chia sẻ chi tiết triển khai của mình trước khi bất kỳ mã nào được triển khai để đảm bảo rằng nó phù hợp với tầm nhìn và chiến lược do Team Lead đề ra, tránh việc phải tái cấu trúc mã không hiệu quả.

Một khi số lượng phê duyệt cần thiết đã đạt được VÀ yêu cầu kéo vượt qua các yêu cầu của tích hợp liên tục (CI) tự động, Team Lead là người duy nhất trong team có quyền hợp nhất yêu cầu kéo. Không Developer nào khác được phép merge code.

Team Lead đóng vai trò điều phối các lần merge code. Việc merge code thường cần phải được sắp xếp và phù hợp với các ưu tiên của sprint để thực hiện hiệu quả. Ví dụ, hợp nhất trước một yêu cầu kéo cho một tính năng backend để mở khóa các nhiệm vụ tính năng hướng frontend có thể là quyết định đúng đắn dù có các yêu cầu kéo đã hoàn thành khác. Một yêu cầu thường xuyên khác là ưu tiên hợp nhất một yêu cầu kéo cho sửa lỗi khẩn cấp hoặc sửa lỗi chung để hỗ trợ Product Manager và/hoặc người dùng cuối.

Cuối cùng, việc có một thành viên đội kỹ thuật duy nhất chịu trách nhiệm cho tất cả các lần merge code củng cố vai trò của người bảo vệ chất lượng mã. Team Lead phải đảm bảo rằng các quy ước của team được tuân thủ và rằng chất lượng codebase đạt các tiêu chuẩn cao nhất trong khi vẫn đáp ứng các yêu cầu sản phẩm và thời gian của sprint. Bằng cách hợp nhất một yêu cầu kéo, Team Lead thực sự đảm bảo về chất lượng mã mới được thêm vào.

Đối với các project lớn (hơn 4 Developer trên cùng một nền tảng), số lượng yêu cầu kéo hàng ngày có thể rất lớn. Do đó, có thể không hiệu quả nếu tất cả Developer luôn xem xét tất cả các yêu cầu kéo nếu nó ảnh hưởng tiêu cực đến tốc độ làm việc của họ. Trong trường hợp này, các Developer được khuyến khích xem xét càng nhiều yêu cầu kéo càng tốt, trong khi Team Lead và CTO phải là những người xem xét tất cả các yêu cầu kéo.

Chịu trách nhiệm Release Product

Do vai trò dẫn dắt quy trình review code và merge code, Team Lead chịu trách nhiệm tiến hành mọi phát hành trên tất cả các môi trường. Do đó, Team Lead cần phải nắm vững các chi tiết của quy trình Release; điều này bao gồm deployment/distribution setup, những vấn đề có thể xảy ra và cách khắc phục chúng.

Khi bắt đầu một project, Team Lead phải đảm bảo rằng việc deployment/distribution đến cả môi trường staging và production được thực hiện ngay trong sprint đầu tiên để tuân thủ Quy trình Phát hành.

Trong trường hợp gặp sự cố, Team Lead cũng là người phản hồi đầu tiên để fix bugs và solve các vấn đề liên quan đến release.

Một khi release đã được xử lý, Team Lead chịu trách nhiệm thực hiện tất cả các thông báo chính thức với các bên liên quan liên quan đến release một cách kịp thời và rõ ràng, chẳng hạn như gửi tin nhắn trên Slack để thông báo cho các bên liên quan.

Nếu gặp sự cố bất ngờ làm trì hoãn release, Team Lead phải chủ động thông báo và phối hợp chặt chẽ với Product Manager về bất kỳ thay đổi nào và các phương án để giải quyết tình huống. Team Lead là trụ cột của quy trình release, không phải Product Manager.

Quy trình release phải được tự động hóa hoàn toàn để giảm thiểu sự can thiệp của con người và được ghi lại để các Developer khác có thể thực hiện trách nhiệm tương tự khi cần.

Điều phối Developer

Team Lead chịu trách nhiệm lập kế hoạch cho tất cả các tài nguyên phát triển trong team của mình. Để đảm bảo các sprints được hoàn thành đúng thời hạn, Team Lead cần lập kế hoạch khi có thành viên hoặc chính họ nghỉ ốm hoặc nghỉ cá nhân vì điều này ảnh hưởng đến tốc độ làm việc chung của cả team.

Trường hợp Developer nghỉ cá nhân:

Trước khi nghỉ:
- Team Lead phải phối hợp với Developer để đảm bảo các công việc chưa hoàn thành được phân bổ lại hợp lý để đảm bảo hoàn thành.
Trong thời gian nghỉ:
- Team Lead phải đảm bảo các yêu cầu được gửi đến Developer — hiện đang trong thời gian nghỉ — từ các đối tác kỹ thuật phía khách hàng (ví dụ: những người mà Developer hợp tác hàng ngày) được xử lý một cách hợp lý. Trên thực tế, Team Lead có thể tự xử lý yêu cầu, chuyển yêu cầu cho Developer khác hoặc giải thích cho khách hàng rằng yêu cầu cần chờ Developer quay lại.
- Một thực hành tốt là Developer nên thiết lập email tự động phản hồi ngoài văn phòng (Out-Of-Office) và bật nó trong thời gian nghỉ. Team Lead nên đảm bảo rằng Developer tuân thủ thực hành này.

Trường hợp Team Lead nghỉ cá nhân:

Trước khi nghỉ:
- Team Lead phải thông báo cho Product Manager và các Developer trong team sớm nhất có thể. Tốt nhất là thông báo ít nhất 2 đến 4 tuần vì điều này tương đương với 1 đến 2 sprints Developer. Team Lead cũng nên chủ động thông báo cho các đối tác kỹ thuật phía khách hàng (ví dụ: những người mà Team Lead hợp tác hàng ngày). Thực tế tốt nhất là thông báo trước ít nhất 1 tuần cho phía khách hàng.
- Bên cạnh việc thông báo về thời gian nghỉ, Team Lead cần lập kế hoạch và thông báo về việc ủy quyền, nghĩa là Developer nào sẽ chịu trách nhiệm trong thời gian Team Lead nghỉ. Tùy thuộc vào thời gian nghỉ, phạm vi ủy quyền có thể thay đổi:
Trong thời gian nghỉ:
- Team Lead nên tận hưởng thời gian nghỉ 🙂 Họ phải chuẩn bị bàn giao đúng cách để tránh bị làm phiền khi nghỉ.
- Giống như các Developer, Team Lead nên thiết lập email tự động phản hồi ngoài văn phòng và bật nó trong thời gian nghỉ.

Trong trường hợp nghỉ ngoài kế hoạch, chẳng hạn như nghỉ ốm: Team Lead phải nhanh chóng:

Đánh giá liệu việc giảm hiệu suất làm việc có ảnh hưởng tiêu cực đến khả năng hoàn thành mục tiêu sprint của team hay không và thông báo với Product Manager.
Đánh giá và thực hiện việc phân bổ lại các nhiệm vụ còn đang chờ xử lý nếu cần thiết.
Bất kỳ sự chậm trễ nào trong việc xử lý việc nghỉ ngoài kế hoạch có thể làm lệch hướng kế hoạch sprint.

Quy tình điển hình của một Sprint

Với danh sách trách nhiệm có vẻ dài, có thể khó hình dung những gì một Team Lead cần làm hàng ngày. Vì trách nhiệm của Team Lead gắn liền với sprint phát triển, dưới đây là mô tả một sprint điển hình kéo dài hai tuần:

Tuần 1

Ngày #1:
- Tham gia buổi họp lập kế hoạch sprint do Product Manager tổ chức cùng với các Developer.
- Phân công yêu cầu nhiệm vụ cho bản thân và các thành viên trong team.
Ngày #1 → Ngày #5 (Thứ Hai → Thứ Sáu)
- Phát triển các tasks, sửa lỗi và thực hiện các tasks phụ.
- Đảm bảo việc review code được ưu tiên và thực hiện đều đặn bởi tất cả các Developer.
- Điều phối việc merge code để đảm bảo Product Manager có thể thực hiện QA trên môi trường staging liên tục.
- Thường xuyên cập nhật cho Product Manager về tiến độ và các trở ngại.

Tuần 2

Ngày #6 → Ngày #10 (Thứ Hai → Thứ Sáu)
- Xem xét các mục trong backlog được tạo bởi Product Manager cho sprint tiếp theo và đưa ra phản hồi để đảm bảo các requirement hoặc feature sẵn sàng cho các Developer thực hiện.
- Ước lượng tất cả các requirement hoặc feature cho sprint tiếp theo.
- Phát triển các requirement hoặc feature, sửa lỗi và thực hiện các nhiệm vụ phụ.
- Đảm bảo việc review code được ưu tiên và thực hiện đều đặn bởi tất cả các Developer.
- Điều phối việc merge code để đảm bảo Product Manager có thể thực hiện QA trên môi trường staging liên tục.
- Thường xuyên cập nhật cho Product Manager về tiến độ và các trở ngại.
Ngày #10:
- Đảm bảo các Developer trong team quen thuộc với các requirement hoặc feature được lên kế hoạch cho sprint tiếp theo để chuẩn bị tốt nhất cho buổi lập kế hoạch sprint.
- Tạo nhánh release chứa tất cả công việc đã hoàn thành trong sprint.
- Chuẩn bị release lên môi trường production cùng với ghi chú phát hành để gắn thẻ branch chính. Nếu ngày cuối của sprint rơi vào Thứ Sáu, việc phát hành thường được thực hiện vào ngày làm việc tiếp theo.

Hiệu Suất

Khi đảm nhận vai trò này, ngoài việc biết các trách nhiệm, một Team Lead cũng cần biết các chỉ số quan trọng để đánh giá hiệu quả làm việc của mình.

Đội ngũ công nhận rằng các điều kiện hoàn cảnh đặc biệt có thể ảnh hưởng đến hiệu suất. Đó là lý do các chỉ số hiệu suất dưới đây không được sử dụng một cách riêng lẻ mà kết hợp để cung cấp cái nhìn đáng tin cậy cho hầu hết các tình huống. Ví dụ, dù có sự cố bất ngờ làm trì hoãn việc hoàn thành tính năng hoặc yêu cầu trong sprint, một Team Lead vẫn có thể được coi là hiệu suất cao nếu đội ngũ làm việc hiệu quả và ứng dụng phát triển có thành tích ổn định và linh hoạt.

Hoàn Thành Đều Đặn Các Mục Tiêu Sprint

Sứ mệnh chính của Team Lead là hoàn thành tất cả các story được lên kế hoạch trong mỗi sprint. Do đó, hiệu suất của họ được đo lường qua mức độ ổn định và hiệu quả trong việc đạt được các mục tiêu sprint. Team Lead cần làm việc chặt chẽ với Product Manager trong suốt sprint và đảm bảo đội ngũ luôn duy trì vận tốc cao trong mỗi sprint (số điểm story được hoàn thành).

Hiệu suất tốt trong khía cạnh này có nghĩa là:

Vận tốc càng cao càng tốt. Càng nhiều điểm story được hoàn thành trong mỗi sprint thì càng nhiều giá trị kinh doanh được cung cấp cho người dùng cuối.
Càng ít các mục backlog chưa hoàn thành được chuyển từ sprint này sang sprint khác càng tốt. Team Lead cần đảm bảo các story được ưu tiên hợp lý và theo dõi tiến độ của từng mục backlog.
Các vấn đề liên quan đến tiến độ càng sớm được báo cáo cho Product Manager càng tốt. Team Lead phải cung cấp cập nhật thường xuyên về tiến độ phát triển để Product Manager có thể điều chỉnh backlog nếu cần thiết.

Ứng Dụng Ổn Định và Linh Hoạt

Team Lead là người ra quyết định kỹ thuật và chịu trách nhiệm về chất lượng mã. Do đó, họ chịu trách nhiệm về chất lượng kết quả của quy trình phát triển: các ứng dụng. Team Lead phải đảm bảo ứng dụng hoạt động như mong đợi trong mọi điều kiện và dễ dàng phát triển theo yêu cầu mới.

Hiệu suất tốt trong khía cạnh này có nghĩa là:

Số lượng lỗi và lỗi tái phát càng ít càng tốt. Team Lead cần kiểm tra kỹ các vấn đề tiềm ẩn trước khi merge code và liên tục thực hiện QA để phát hiện vấn đề trước khi người dùng cuối gặp phải.
Yêu cầu mới càng dễ thực hiện càng tốt. Cơ sở mã cần dễ phát triển để tối đa hóa lợi ích cho chủ sở hữu.
Thời gian khắc phục lỗi và sự cố càng nhanh càng tốt (MTTR thấp). Team Lead phải đảm bảo thời gian trung bình để khôi phục hệ thống luôn ở mức thấp.

Môi Trường Làm Việc Hiệu Quả Cho Đội Ngũ

Xây dựng project xoay quanh những cá nhân có động lực. Cung cấp cho họ môi trường và sự hỗ trợ cần thiết, và tin tưởng rằng họ sẽ hoàn thành công việc. – Tuyên Ngôn Agile

Team Lead trực tiếp ảnh hưởng đến công việc hàng ngày của mỗi Developer vì họ phân công các story và điều phối nỗ lực review mã. Như một huấn luyện viên thể thao, Team Lead cần biết điểm mạnh, điểm yếu và nguyện vọng của mỗi thành viên trong đội (ví dụ, một Developer muốn làm việc với các nhiệm vụ cụ thể) và cung cấp hướng dẫn, động viên để đảm bảo họ làm việc tốt nhất có thể. Team Lead cần tạo môi trường mà mọi người đều cảm thấy được đánh giá cao và có động lực (không ai bị tụt lại phía sau).

Hiệu suất tốt trong khía cạnh này có nghĩa là:

Càng có nhiều nỗ lực giao tiếp và cộng tác tích cực càng tốt. Trong một đội ngũ hoạt động tốt, mỗi thành viên tích cực tham gia vào tất cả các cuộc thảo luận team và cộng tác với nhau để đạt được mục tiêu sprint.
Đội ngũ càng đồng thuận với các mục tiêu sprint càng tốt. Team Lead phải đảm bảo rằng mỗi thành viên trong đội hiểu rõ bối cảnh và lý do cho việc ưu tiên các story trong mỗi sprint. Mỗi thành viên cần có bức tranh tổng thể của project.

Nên làm và Không nên làm

Để tránh những sai sót phổ biến, cần tuân thủ các nguyên tắc sau đây:

DO làm việc trên các story về tính năng.

Do NOT chỉ làm việc trên các nhiệm vụ lặt vặt và sửa lỗi.

👉 Một Team Lead đóng vai trò quan trọng trong việc giải quyết các trở ngại kỹ thuật cho các Developer và dành một phần lớn thời gian cho việc review và merge code. Tuy nhiên, năng suất của Team Lead cũng đóng góp vào vận tốc của đội ngũ. Vì vậy, Team Lead phải hoàn thành các story về tính năng để hỗ trợ đạt được các mục tiêu sprint. Với kinh nghiệm và kỹ năng vững vàng, Team Lead nên hiệu quả ngang bằng hoặc hơn so với các Developer khác trong đội ngũ. Ngoài ra, vì họ có quyền quyết định kỹ thuật, họ không chỉ có khả năng thực hiện mã một cách kỹ lưỡng mà còn giúp mở đường cho các Developer khác, ví dụ: triển khai mã mà cả đội có thể học hỏi và làm theo.

DO lập kế hoạch liên tục để hoàn thành tất cả trách nhiệm một cách hiệu quả.

Do NOT trở thành nút thắt cổ chai của đội ngũ.

👉 Vai trò lãnh đạo đi kèm với các trách nhiệm bổ sung. Thành công trong vai trò này không chỉ dựa vào nỗ lực của một cá nhân mà còn của cả đội ngũ. Do đó, Team Lead cần có kỹ năng tổ chức cá nhân mạnh mẽ để biết phân bổ thời gian hiệu quả nhất trong mỗi sprint. Từ các story họ tự giao cho mình đến việc giải quyết backlog của các pull request để review và hợp nhất, họ phải tránh mọi tình huống mà mình trở thành nút thắt cổ chai của đội ngũ. Phần lớn hiệu quả của đội ngũ phụ thuộc vào sự hiệu quả của Team Lead.

DO thực thi các quyết định kỹ thuật một cách nghiêm ngặt để thúc đẩy project.

Do NOT cho tất cả các Developer tham gia vào mọi quyết định kỹ thuật.

👉 Là người quyết định kỹ thuật trong đội ngũ, Team Lead cần biết cách sử dụng quyền quyết định của mình một cách khéo léo. Team Lead phải cân bằng giữa việc tìm kiếm sự đồng thuận của đội ngũ và tiến hành project. Không phải mọi quyết định kỹ thuật đều quan trọng như nhau. Một số quyết định kỹ thuật yêu cầu sự tham gia của mọi Developer (ví dụ: quyết định ảnh hưởng đến toàn bộ cơ sở mã), nhưng phần lớn có thể và nên được thực hiện theo ý kiến của Team Lead và Developer chịu trách nhiệm triển khai. Các Developer trong đội ngũ ủy quyền quyền quyết định cho Team Lead và mong đợi Team Lead sẽ dùng quyền này để đưa ra quyết định có lợi cho project.

DO điều phối việc làm quen cho các Developer mới tham gia vào đội ngũ.

Do NOT để các Developer mới tự tìm hiểu mọi thứ.

👉 Team Lead có lợi ích trong việc đảm bảo các Developer mới tham gia vào đội ngũ có mọi thứ cần thiết để làm việc hiệu quả. Càng sớm các Developer này hiểu rõ project và cơ sở mã, họ càng sớm có thể đóng góp ý nghĩa cho đội ngũ. Team Lead thường chịu trách nhiệm về quá trình làm quen, nhưng cũng có thể ủy quyền cho một thành viên khác, như Developer hoặc CTO, tùy theo nhu cầu của project.

DO theo dõi sát sao lỗi/sự cố ứng dụng.

Do NOT để lỗi không được xử lý và điều tra.

👉 Hiệu suất của Team Lead một phần được đánh giá dựa trên tính ổn định của ứng dụng mà họ dẫn dắt. Vì vậy, họ phải là người đầu tiên phản ứng khi gặp phải các lỗi nghiêm trọng, chẳng hạn như sự cố máy chủ hoặc sự cố ứng dụng. Họ cũng nên thường xuyên kiểm tra các lỗi không nghiêm trọng, ngay cả khi không đều đặn, để đảm bảo điều tra và giải quyết. Team Lead cần ưu tiên xử lý các lỗi trong môi trường sản xuất dựa trên mức độ nghiêm trọng và tần suất xuất hiện của chúng, và đảm bảo rằng các lỗi này được giải quyết để giảm thiểu tác động tiêu cực đến người dùng.

Tham khảo thêm

1. Ở vị trí senior thì phải đánh đổi những gì?

Chịu trách nhiệm nhiều hơn với sản phẩm, đứng mũi chịu sào trước manager.
Đi trước những người khác, đánh hơi rủi ro, phải phân tích được mọi thứ, trở thành contact point khi người khác cần gì thì họ sẽ hỏi mình.
Khó work-life balance trong giai đoạn 6 tháng đầu.
Phải chấp nhận họp hành nhiều.

2. Làm sao mà từ mid-level lên được senior?

Bổ sung kiến thức và thể hiện kiến thức.
Chuẩn bị những dự án khó, những dự án có ảnh hưởng lớn, giúp tăng uy tín.
Có quan hệ tốt với engineering manager, người sẽ hỗ trợ trực tiếp.

3. Tại sao mình làm mãi như một senior nhưng mãi không lên?

Chuyển công ty thôi.
Hoặc giao tiếp với manager để tìm sự giúp đỡ.
Cần sự niềm tin từ manager.
Chủ động hỗ trợ, sẵn sàng chia sẻ kiến thức.
Sát sao với công việc, tránh xử lý hơi cảm tính.

4. Lời khuyên cho những bạn đang muốn lên senior?

Nói chuyện với manager để biết mình cần làm những gì.
Luôn tăng kiến thức, làm side projects để nâng cao kỹ năng, cố gắng đạt trình độ của một senior.

Làm mãi mà không lên SENIOR Software Engineer? Lời khuyên từ Senior tại Big Tech & FAANG