Con đường sự nghiệp của lập trình viên

2030

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
1Adopts (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
2Specializes (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
3Evangelizes (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
4Masters (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
5Creates (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
Các cấp độ về Technology

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
1Enhances (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
2Designs (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ệ
3Owns (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 (*)
4Evolves (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ó
5Leads (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
Các cấp độ về System

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
1Learn (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
2Supports (Hỗ trợ)Chủ động hỗ trợ thành viên khác để giúp họ hoàn thành công việc
3Mentors (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
4Coordinates (Đ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ả
5Manages (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
Các cấp độ về People

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
1Follows (Tuân thủ)Tuân thủ quy trình của team để phát triển sản phẩm
2Enforces (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
3Challenges (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 đó
4Adjusts (Đ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
5Defines (Đị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
Các cấp độ về Process

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
1Subsystem (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ỏ)
2TeamTầm ảnh hưởng tới toàn bộ team
3Multiple Teams (Nhiều team)Tầm ảnh hưởng tới nhiều team
4Company (Công ty, tổ chức)Tầm ảnh hưởng tới toàn bộ tổ chức
5Community (Cộng đồng)Tầm ảnh hưởng tới cộng đồng công nghệ nói chung
Các cấp độ về Influence

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ậcTrình độ tối thiểu DeveloperTech LeadTechnical Program ManagerEngineering Manager
1JuniorD1(empty)(empty)(empty)
2JuniorD2(empty)(empty)(empty)
3JuniorD3(empty)(empty)(empty)
4SeniorD4TL4TPM4(empty)
5SeniorD5TL5TPM5EM5
6SeniorD6TL6TPM6EM6
7SeniorD7TL7TPM7EM7
Cấp bậc & Lộ trình phát triển của Developer

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

1. Tôi đang là Tech lead ở công ty, nhưng tôi không đạt được các kỹ năng như tài liệu trên, vậy tôi có phải là Tech lead không?

Đ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.

2. Trong công ty tôi không có các vị trí như trên thì làm thế nào?

Đ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.

3. Làm sao để tôi đánh giá được mình (hoặc người khác) đang ở mức độ nào?

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á

4. Tại sao lại chi có 7 levels?

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.

5. Rất nhiều nơi cho rằng developer có 2 hướng phát triển là: quản lý con người, và quản lý công nghệ, nhưng sao bài viết này lại không nhắc đến?

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:

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.