Những bài học đáng ngạc nhiên tôi đã học được với tư cách là Trưởng nhóm kỹ thuật

Xin chào mọi người! Sau một thời gian vắng bóng khỏi việc viết lách, tôi đã trở lại, cố gắng quay trở lại với guồng quay của mọi thứ. Tôi muốn nhấn mạnh rằng những trải nghiệm được chia sẻ trong không gian này dựa trên kinh nghiệm học thuật và chuyên môn của tôi. Do đó, điều quan trọng cần nhớ là những gì được mô tả ở đây chỉ có thể đại diện cho một phần nhỏ của thực tế và không nên được hiểu là công thức xác định cho các quy trình, thủ tục hoặc dịch vụ cụ thể.

Hiện tại tôi rất hào hứng với giai đoạn mới này trong sự nghiệp của mình. Tôi đã học được rất nhiều và muốn chia sẻ một phần hành trình này với cộng đồng. Tôi hy vọng rằng thông tin được trình bày ở đây sẽ có giá trị lớn đối với độc giả.

People First - Tầm quan trọng của Kỹ năng mềm

Khi tôi tham gia vào quá trình tuyển chọn đầu tiên của mình, cách đây vài năm, tôi nhớ rõ những bước gần như nhàm chán mà tôi đã trải qua: phỏng vấn với HR, bài kiểm tra thực hành, phỏng vấn với trưởng nhóm kỹ thuật và cuối cùng là phỏng vấn với người quản lý. Trong suốt sự nghiệp của mình với tư cách là một nhà phát triển, tôi đã tham gia một số cuộc phỏng vấn với các mô hình khác nhau. Vào thời điểm đó, tôi luôn cảm thấy không thoải mái khi phỏng vấn với những người của HR. Tôi không hiểu tại sao, nghĩ rằng: "Nếu tôi có thể làm những gì được yêu cầu trong bài kiểm tra kỹ thuật, thì tôi đã thể hiện đủ năng lực cho vị trí này rồi".

Khi tôi đảm nhận vai trò là trưởng nhóm phát triển kỹ thuật, một trong những trách nhiệm của tôi là hợp tác với phòng nhân sự (vâng, chính những người mà tôi không hiểu lý do tham gia vào quá trình tuyển chọn) để chuẩn bị bài kiểm tra kỹ thuật và xác định định dạng phỏng vấn cho hai ứng viên bắt đầu ở khu vực phụ trợ. Tôi nghĩ rằng mình đã biết một lập trình viên mới vào nghề ở khu vực phụ trợ cần phải cung cấp những gì và điều gì sẽ được coi là yếu tố tạo nên sự khác biệt trong bài kiểm tra. Tuy nhiên, điều tôi không ngờ là, mặc dù mã rất quan trọng, nhưng vẫn nảy sinh những yêu cầu khác ngoài việc cung cấp dự án: làm thế nào để đánh giá ứng viên về mặt giao tiếp? Họ quan tâm đến vị trí nào? Và bối cảnh họ trình bày có thể ảnh hưởng như thế nào đến sự phù hợp của họ với vị trí được đề xuất? Những câu hỏi này và những câu hỏi khác hóa ra lại có liên quan như mã mà cả hai ứng viên trình bày, một điều mà trước đây tôi chưa từng cân nhắc đến trong những năm đầu làm lập trình viên.

Tôi nhớ mình đã ngồi vào bàn họp để đưa ra quyết định cuối cùng và hơi ngạc nhiên khi nhận ra rằng có rất ít thảo luận về kỹ năng chuyên môn của từng ứng viên. Một phần là do họ là ứng viên trình độ đầu vào, nên có thể dự đoán rằng kỹ năng chuyên môn của họ sẽ không được phát triển, và đây không phải là trọng tâm chính của cuộc thảo luận.

Tuy nhiên, ngay cả đối với các vị trí tuyển dụng cao cấp hơn, đặc biệt là các vị trí cấp cao, điều quan trọng là phải xem xét các kỹ năng như giao tiếp, lập tài liệu, khả năng thích ứng, chủ động và các kỹ năng khác thường được đề cập. Những kỹ năng mềm này là cơ bản và có thể quyết định thành công trong vai trò này, ngoài các kỹ năng chuyên môn. Trên thực tế, đây là điểm tiếp theo của tôi.

Đường ranh giới giữa Junior và Senior (Không phải cấp trung).

Tôi biết có rất nhiều cuộc thảo luận về ý nghĩa và cách phân loại các thuật ngữ liên quan đến mức độ kinh nghiệm, như "senior". Một số người nói rằng "senior được định nghĩa bằng nhiều năm kinh nghiệm", những người khác lại cho rằng "ở một số công ty, bạn sẽ có được kinh nghiệm của senior sau một năm". Cũng có những người nói rằng "không có sự phân biệt rõ ràng giữa junior và senior" hoặc rằng "senior chỉ thực hiện đánh giá mã và phê duyệt PR". Một số tuyên bố này khá buồn cười, một số khác thì có một phần sự thật. Thực tế là khái niệm "senior" khá đa dạng và tôi không có thẩm quyền để định nghĩa một tiêu chuẩn chung, nhưng tôi có thể đưa ra một số hướng dẫn để hiểu cách phân loại này theo cách cá nhân hơn.

Trở thành một người cao cấp không chỉ là về kiến ​​thức chuyên môn, mặc dù điều này chắc chắn rất quan trọng. Một người cao cấp thực sự, hoặc ít nhất là một người cao cấp giỏi, là người có khả năng giải quyết các vấn đề phức tạp về cả kiến ​​trúc mã và hệ thống. Duy trì chất lượng mã, tuân thủ các thông lệ phát triển tốt và có kiến ​​thức về quản lý dự án là những khía cạnh quan trọng.

Sự khác biệt chính là một người cao cấp phải có khả năng thực hiện tất cả những điều này một cách tự chủ và quan trọng hơn là phải hợp tác với các nhóm từ các cấp độ và lĩnh vực khác nhau để cung cấp dự án tốt nhất có thể. Hơn nữa, một người cao cấp thực sự (hoặc ít nhất là những người giỏi nhất) không chỉ lãnh đạo và hướng dẫn nhóm mà còn phát triển và chuẩn bị cho các nhà phát triển khác đảm nhận các vị trí và trách nhiệm mới.

Kinh nghiệm đầu tiên của tôi khi dẫn dắt một dự án

Khi tôi đảm nhận dự án đầu tiên, sếp tôi biết rằng tôi chưa từng lãnh đạo bất kỳ dự án nào khác trước đây. Tôi chỉ tham gia vào quá trình phát triển và đưa ra một số điều sẽ tạo điều kiện thuận lợi cho quá trình phát triển về mặt giao tiếp với ban quản lý. Câu hỏi đầu tiên anh ấy hỏi tôi là: "Bao nhiêu người và loại nào sẽ đủ để bổ sung cho dự án". Tôi không biết câu trả lời ngay, đó là một câu hỏi rất phức tạp. Vì dự án chỉ nằm trong phác thảo, chúng tôi không biết về ngăn xếp, thời gian hoàn thành từng nhiệm vụ và các số liệu khác mà những người ở trên quan tâm. Tôi đã thực hiện một nghiên cứu đầy đủ để có thể giao vào ngày hôm sau về một số phương pháp quản lý dự án: Pert, Planning Poker Chúng tôi đã cùng nhau chọn phương pháp phù hợp nhất và thử thách bắt đầu. đối với từng thành viên trong nhóm, nền tảng phát triển nào là tốt nhất, ngăn xếp nào là tốt nhất để sử dụng, kiến ​​trúc hệ thống sẽ hoạt động như thế nào, nghiên cứu các giải pháp khác trên thị trường, theo dõi trình độ của từng nhà phát triển, họp, họp và họp nhiều hơn nữa với ban quản lý .

Khi tôi ít nhận ra nhất, tôi ngày càng xa rời mã. Vai trò của tôi là đề xuất cải tiến và sửa một số lỗi quan trọng để dự án có thể hoạt động hoặc ít nhất là cung cấp nền tảng vững chắc cho các nhà phát triển bắt đầu. Phần công việc còn lại bao gồm giao tiếp với các nhà phát triển, phân chia nhiệm vụ, theo dõi số liệu và về cơ bản, một mắt nhìn vào Asana (để ước tính thời gian giao dự án) và một mắt nhìn vào Meet để đảm bảo micrô của tôi không bật và không có điều gì không mong muốn "vô tình" lọt qua.

Kết luận và nhìn lại quá khứ - gửi đến bậc thầy với tình cảm

Tôi bắt đầu sự nghiệp của mình với tư cách là thực tập sinh phát triển và, điều thú vị là — và bạn có thể thấy hơi mâu thuẫn về phía tôi — tôi không có bất kỳ kinh nghiệm cụ thể nào (ít nhất là không được ghi lại chính thức trong hồ sơ việc làm của tôi) có thể phân loại tôi là một nhà phát triển cấp cơ sở, toàn thời gian hay cấp cao. Phần lớn kinh nghiệm tôi có được đến từ các dự án cá nhân và nghiên cứu tại trường đại học. Đó là một quá trình dần dần cho đến khi tôi nhận ra rằng các kỹ năng của mình đã phát triển kể từ những ngày đầu đó.

Nhưng đúng vậy, tôi đã làm việc rất chăm chỉ với tư cách là một nhà phát triển ở nhiều cấp độ khác nhau và có cơ hội gặp gỡ nhiều chuyên gia cấp cao khác nhau trong suốt sự nghiệp của mình:

1. Người cao tuổi rất có năng lực và hiệu quả, nhưng lại không giao tiếp, giải quyết vấn đề mà không giải thích về cách tiếp cận của mình.
2. Người cao tuổi này rất giỏi trong giao tiếp và giảng dạy, nhưng thường quá tải với những công việc cấp bách và không có thời gian để giảng dạy.
3. Người cao tuổi này rất nhiệt tình với việc thiết kế quá mức và tập trung công nghệ, nhưng vẫn luôn đúng thời hạn và thực hiện những gì đã hứa.

Điều quan trọng nhất là, mặc dù có những khiếm khuyết có thể biện minh được (mặc dù có thể, nhưng rất khó để cân bằng các yêu cầu), tất cả những chuyên gia này đều có điều gì đó giá trị để dạy. Những kinh nghiệm này đã giúp định hình sự nghiệp của tôi và cho tôi cái nhìn rõ ràng về những gì hiệu quả và những gì không hiệu quả trong phát triển hệ thống.