Chào các bạn,
Trong bất kỳ ngành nghề nào thì cũng luôn tồn tại khái niệm career path (Con đường sự nghiệp), và ngành IT cũng không ngoại lệ. Trên thực tế, đây là chủ đề được rất nhiều bạn quan tâm, đặc biệt là các bạn đang ở level Junior và Middle.
>> Đọc thêm: Lập trình viên Fresher, Junior Senior là gì và cách phân biệt?
Chủ đề về con đường sự nghiệp của lập trình viên cũng không phải là mới, cộng đồng IT vốn dĩ đã tốn rất nhiều nước bọt cho nó từ trước đến nay. Nhưng vì có lẽ mỗi môi trường một khác, mà vẫn chưa có một kết luận chính xác nào về lộ trình phát triển sự nghiệp của một developer cả.
Nên trong bài viết này, chúng ta sẽ cùng nhau đi tìm hiểu một chút nhé.
I. Giới thiệu về nguồn tham khảo
Mình có tìm được một tài liệu rất hay là Engineering Ladders – Một framework (framework nhưng không liên quan đến code) về Engineering Managers. Đại khái là nó viết về các con đường phát triển sự nghiệp của một bạn developer, với mỗi đường sẽ chia làm nhiều cấp độ, mỗi cấp độ lại đòi hỏi các kỹ năng tương ứng.
Tài liệu này hoạt động dưới dạng open source, tức là bạn có thể đóng vào nó nếu muốn. Tính đến thời điểm mình viết bài viết này (2022), thì repository hiện đang có 1.1k star và 158 lượt fork.
II. Các khía cạnh ảnh hưởng tới một lập trình viên
Trước khi tìm hiểu chi tiết về các hướng phát triển, ta cùng xem có những khía cạnh nào mà thường ảnh hưởng tới sự phát triển của một lập trình viên đã nhé.

Theo tài liệu trên, thì có 5 khía cạnh ảnh hưởng tới sự phát triển của một developer, và mỗi khía cạnh lại chia ra làm 5 cấp độ khác nhau. Cụ thể:
Lưu ý
Việc hiểu hết các khía cạnh, và levels trong từng khía cạnh là điều cốt lõi để bạn nắm rõ nội dung bài viết này.
Khía cạnh thứ 1: Technology – Công nghệ
Khía cạnh này được hiểu như là các stack công nghệ, các công cụ phát triển sản phẩm.
Cấp độ | Tên cấp độ | Diễn giải |
---|---|---|
1 | Adopts (Hiểu và áp dụng) | Tích cực học và sử dụng công nghệ mà team lựa chọn |
2 | Specializes (Chuyên viên) | Đây là người tìm đến khi cần trợ giúp về một hoặc nhiều công nghệ nào đó, đồng thời cũng bắt đầu chủ động học công nghệ mới |
3 | Evangelizes (Truyền bá) | Nghiên cứu, chứng minh tính khả thi của công nghệ mới để đưa vào áp dụng trong team |
4 | Masters (Am hiểu sâu sắc) | Có hiểu biết sâu sắc về stack công nghệ của cả hệ thống |
5 | Creates (Sáng tạo) | Thiết kế, sáng tạo ra công nghệ mới để sử dụng rộng rãi trong cả team nội bộ và bên ngoài |
Khía cạnh thứ 2: System – Hệ thống
Khía cạnh này được hiểu như là các hệ thống phần mềm liên quan để vận hành sản phẩm.
Cấp độ | Tên cấp độ | Diễn giải |
---|---|---|
1 | Enhances (cải tiến) | Thực hiện thêm tính năng mới, fix bug để cải thiện và mở rộng hệ thống |
2 | Designs (Thiết kế) | Thiết kế và triển khai các tính năng từ trung bình tới lớn, nhưng đảm bảo có ít nợ công nghệ |
3 | Owns (Làm chủ | Giám sát và vận hành hệ thống, đảm bảo hệ thống tuân thủ SLA (*) |
4 | Evolves (Phát triển) | Phát triển kiến trúc hệ thống để hỗ trợ các tính năng trong tương lai và định nghĩa các SLA cho nó |
5 | Leads (Dẫn dắt) | Khám phá, tìm ra các công nghệ ưu việt hơn, sau đó đó đưa vào kế hoạch để nâng cấp hệ thống |
Khía cạnh thứ 3: People – Con người
Khía cạnh này được hiểu như là việc điều phối, dẫn dắt các developer khác.
Cấp độ | Tên cấp độ | Diễn giải |
---|---|---|
1 | Learn (Học hỏi) | Học hỏi từ người khác, tự học một cách nhanh chóng, và luôn đứng ra làm việc khi cần |
2 | Supports (Hỗ trợ) | Chủ động hỗ trợ thành viên khác để giúp họ hoàn thành công việc |
3 | Mentors (Cố vấn) | Hướng dẫn các thành viên khác phát triển sự nghiệp, khích lệ họ tham gia tích cực vào việc phát triển hệ thống |
4 | Coordinates (Điều phối) | Điều phối các thành viên trong team, tổ chức các cuộc họp, thảo luận để lấy được feedback hiệu quả |
5 | Manages (Quản lý) | Quản lý lộ trình phát triển, mong muốn, mức độ hiệu quả công việc của các thành viên trong team |
Khía cạnh thứ 4: Process – Quy trình
Khía cạnh này được hiểu như là quy trình làm việc, quy trình phát triển sản phẩm.
Cấp độ | Tên cấp độ | Diễn giải |
---|---|---|
1 | Follows (Tuân thủ) | Tuân thủ quy trình của team để phát triển sản phẩm |
2 | Enforces (Củng cố) | Đảm bảo mọi người trong team hiểu lợi ích và các điểm cần đánh đổi |
3 | Challenges (Thử thách) | Tìm ra các điểm đang là “thử thách” của team, sau đó cải thiện team bằng cách vượt qua các thử thách đó |
4 | Adjusts (Điều chỉnh, hòa giải) | Lắng nghe các góp ý, điều chỉnh cho phù hợp, hướng dẫn team thực hiện theo sự thay đổi |
5 | Defines (Định nghĩa) | Đưa ra quy trình mới để phù hợp với team, cân bằng giữa sự linh hoạt và các quy tắc |
Khía cạnh thứ 5: Influence – Tầm ảnh hưởng
Khía cạnh này được hiểu như là tầm ảnh hưởng của bạn tới người xung quanh.
Cấp độ | Tên cấp độ | Diễn giải |
---|---|---|
1 | Subsystem (Hệ thống con) | Ảnh hưởng tới một hoặc một vài hệ thống con (một vài sản phẩm nhỏ) |
2 | Team | Tầm ảnh hưởng tới toàn bộ team |
3 | Multiple Teams (Nhiều team) | Tầm ảnh hưởng tới nhiều team |
4 | Company (Công ty, tổ chức) | Tầm ảnh hưởng tới toàn bộ tổ chức |
5 | Community (Cộng đồng) | Tầm ảnh hưởng tới cộng đồng công nghệ nói chung |
III. Các con đường phát triển của lập trình viên
Chính sự khác nhau về cấp độ của các khía cạnh, mà tạo nên các con đường phát triển sự nghiệp khác nhau cho các bạn developer, cụ thể, tài liệu này chia làm 4 hướng phát triển:
- Hướng Developer (D): Bạn có xu hướng trở thành người cực kỳ am hiểu về stack công nghệ có trên sản phẩm, dùng các kiến thức đó để trực tiếp xây dựng hệ thống.
- Hướng Tech Lead (TL): Bạn có xu hướng làm chủ hệ thống, hỗ trợ team developer xây dựng sản phẩm với kiến trúc tốt, chất lượng (code) tốt.
- Hướng Technical Program Manager (TPM): Bạn có xu hướng điều phối team, thường là nhiều teams có liên quan đến nhau. Theo tác giả, vai trò này giống như “trợ lý” của EM, đảm nhiệm giúp EM một phần công việc, vì thế mà vai trò này thường chỉ tồn tại trong các dự án mà có nhiều teams cùng kết hợp làm việc.
- Hướng Engineering Manager (EM): Bạn có xu hướng đảm bảo dự án thành công, cải thiện năng suất làm việc của team, làm cho tất cả developer trong tổ chức cảm thấy hạnh phúc, và hướng dẫn họ phát triển theo lộ trình phù hợp.
Lưu ý
Các hướng trên không hoàn toàn thể hiện trình độ, hay cấp bậc thăng tiến trong tổ chức. Mà chỉ đơn giản là hướng lựa chọn, tức là một Developer cũng có thể tương đương với một Engineering Manager.
Mỗi hướng phát triển, lại có thể chia ra làm nhiều cấp độ khác nhau, chi tiết bạn có thể click vào tên các cấp độ trong bảng dưới để tìm hiểu thêm:
Cấp bậc | Trình độ tối thiểu | Developer | Tech Lead | Technical Program Manager | Engineering Manager |
---|---|---|---|---|---|
1 | Junior | D1 | (empty) | (empty) | (empty) |
2 | Junior | D2 | (empty) | (empty) | (empty) |
3 | Junior | D3 | (empty) | (empty) | (empty) |
4 | Senior | D4 | TL4 | TPM4 | (empty) |
5 | Senior | D5 | TL5 | TPM5 | EM5 |
6 | Senior | D6 | TL6 | TPM6 | EM6 |
7 | Senior | D7 | TL7 | TPM7 | EM7 |
Nhận xét
- Từ bảng trên, bạn sẽ thấy rằng, để trở thành Tech Lead, Technical Program Manager, Engineering Manager thì tối thiểu bạn phải là một Senior.
- Ở các vị trí cấp cao (từ 5 trở đi), thì Developer – Tech Lead – Technical Program Manager – Engineering Manager có thể hoán đổi vai trò cho nhau mà không gặp vấn đề gì quá khó khăn – xem chi tiết và so sánh dựa trên biểu đồ radar bằng cách click vào tên các cấp bậc.
IV. Các câu hỏi thường gặp
Điều này rất bình thường, bởi Tech lead ở mỗi tổ chức lại có thể cần các kỹ năng khác nhau. Tài liệu này không mang tính chất như một checklist để kiểm tra năng lực của bạn, mà chỉ mang tính chất như một tài liệu tham khảo, giúp bạn phát triển hơn.
Điều này cũng rất bình thường, mỗi tổ chức sẽ có các vị trí khác nhau để phù hợp với cách quản lý của tổ chức đó. Tuy nhiên, thì khả năng cao các vị trí ở tổ chức của bạn sẽ tương đồng với một levels nào đó trong tài liệu này.
Có nhiều cách đánh giá, nhưng bạn có thể tham khảo một số cách dưới đây:
– Trao đổi 1 – 1 với leader của mình
– Lấy đánh giá từ các thành viên khác trong team
– Tự xem xét bản thân đánh giá
Từ level 8 trở lên sẽ rất khác nhau ở mỗi tổ chức. Nếu bạn có ý định xây dựng, định nghĩa các vị trí từ level 8 trở lên, thì bạn phải tự làm.
Trong tài liệu này không nhắc đến, nhưng nếu bạn để ý, thì hướng Developer, Tech Lead sẽ thiên về kỹ thuật, còn hướng TPM, hoặc EM sẽ thiên về con người.
Trong thực tế, với các bạn đi lên từ Developer, thì dù theo hướng con người, hay hướng công nghệ, thì luôn có tỷ lệ nhất định giữa hai kỹ năng này – tức là 20% công nghệ, 80% con người hoặc ngược lại, chứ ít khi (hoặc không bao giờ) tập trung 100% vào một khía cạnh.
V. Tổng kết
Theo tác giả, tài liệu này được xây dựng để phù hợp với thị trường bên US, tuy nhiên, mình thấy nó có thể áp dụng được khá nhiều với các công ty tại Việt Nam, chỉ có điều khác khác tên gọi cho từng vị trí.
Ví dụ, ở Việt Nam, một vài vị trí như Software Architecture có thể tương đồng với D5 trở lên, hoặc TL6 trở lên.
Cuối cùng thì bài viết này cung cấp thêm cho bạn một cách để tìm hiểu về con đường phát triển sự nghiệp cho lập trình viên, chứ không nhằm mục đích đưa ra kết luận cuối cùng. Mặt khác con đường sự nghiệp thế nào cũng phụ thuộc rất nhiều vào tổ chức, môi trường hiện tại mà developer đang làm việc.
Tài liệu tham khảo:
- http://www.engineeringladders.com
- https://github.com/jorgef/engineeringladders/issues/5
- https://resources.base.vn/management/sla-la-gi-theo-doi-sla-cua-nhan-su-nhu-the-nao-717
Các định nghĩa mới:
- SLA: Sevice Level Agreement, tạm dịch là thỏa thuận mức độ dịch vụ, là cam kết giữa nhà cung cấp dịch vụ đối với khách hàng sử dụng dịch vụ đó. Cam kết này không chỉ dừng lại ở khía cạnh chất lượng mà còn bao gồm những yếu tố như số lượng, tính khả dụng, trách nhiệm của nhà cung cấp,… được thỏa thuận với khách hàng.