Tôi là một kiến trúc sư front - end, nhưng tôi cũng được biết đến như một nhà lãnh đạo về kỹ thuật, một chuyên gia về một số lĩnh vực liên quan. Tôi gia nhập công ty hiện tại với 5 năm kinh nghiệm về thiết kế và kinh nghiệm quản lý phát triển, tuy nhiên đến lúc phải lựa chọn con đường riêng cho sự nghiệp của mình giữa các công ty, tôi đã đi theo hướng kỹ thuật.
Tôi phải thú nhận rằng tôi không có bất kỳ một ý tưởng nào về việc một nhà lãnh đạo kỹ thuật thực sự cần làm gì. Chuyên gia về kỹ thuật không cần thiết phải là các nhà lãnh đạo kỹ thuật. Cả hai đều có những kỹ năng kỹ thuật vượt trội, sự khác nhau ở đây là những người khác liên quan như thế nào đến bạn. Bạn có phải là một người khiến người khác muốn đi theo? Đó là một câu hỏi thực sự quan trọng. Bài viết dưới đây sẽ đưa ra một số kỹ năng mềm nhằm tạo nên một nhà lãnh đạo kỹ thuật từ một chuyên gia kỹ thuật.
Thẩm quyền của bạn trong vị trí lãnh đạo kỹ thuật - hay bất kỳ một vị trí lãnh đạo nào - là sẽ đi từ việc bạn có thể làm gì cho những người khác. Quyền... ở đây bắt nguồn từ việc bạn đang được biết đến như một người cố gắng và giải quyết đúng vấn đề cho mọi người. Mục đích là làm cho người khác tìm kiếm bạn, không phải để bạn đuổi theo người khác để cho nhận xét về code của họ. Để điều này xảy ra, trí tuệ và kỹ năng là không đủ - bạn cần phải trở nên có ích.
Đối với các nhà lãnh đạo kỹ thuật, nếu bạn bận đến nỗi không thể trợ giúp người khác được, bạn không làm là việc của bạn - và tôi nói ở đây không chỉ giúp một vài người khi họ đến và yêu cầu sự giúp đỡ. Bạn có thể phải thiết lập một một kỳ vọng đối với cấp trên của mình rằng việc giúp đỡ người khác là một phần quan trọng trong công việc của một nhà lãnh đạo kỹ thuật. Nhưng bạn có biết không? Nó có thể tốn khá nhiều thời gian - hãy trao đổi lại với sếp của bạn. Thậm chí nếu không tốn thời chi phí thời gian cho việc đó, cố gắng ước tính thời gian nó tiết kiệm được cho đồng nghiệp của bạn. Những con số nói lên rất nhiều điều.
Việc đo lường chính xác rằng bạn hữu ích như thế nào là bí quyết kỹ thuật của cả nhóm. Nếu bạn tuyệt vời nhưng nhóm của bạn không thể tạo ra một công việc xuất sắc, thì bạn không phải là một nhà lãnh đạo kỹ thuật - bạn chỉ là một dev cấp cao. Có một sự khác biệt giữa hai điều đó. Mỗi bit của đoạn code mà bạn viết, mỗi bit của tài liệu mà bạn kết hợp với nhau nên phù hợp để sử dụng làm tài liệu sử dụng cho việc đào tạo cho người khác trong nhóm của bạn. Khi đưa ra quyết định về cách để giải quyết một vấn đề hay là nghĩ nên sử dụng công nghệ gì, hãy nghĩ về những gì sẽ trợ giúp cho những nhà phát triển tương lai.
Công việc của tôi như một kiến trúc sư front - end thường xuyên liên quan đến không chỉ là việc viết những đoạn code, mà còn là “dọn dẹp” những đoạn code của người khác để hỗ trợ trong khả năng tái sử dụng và sự hiểu biết đối với những dev khác. Đó là một tập hợp lớn các chức năng có thể hoạt động tốt hơn như là một đối tượng, và nó có lẽ sẽ phụ thuộc vào việc bạn khiến cho nó xảy ra, cho dù thông qua việc đào tạo hay chỉ là làm điều đó.
Nói vê việc đào tạo, nó cần phải là một niềm đam mê. Kinh nghiệm và năng khiếu cho việc đào tạo có lẽ là yếu tố quan trọng nhất trong tôi quyết định gắn bó với vị trí một kiến trúc sư front - end. Nói chuyện trước công chúng hay diễn thuyết là một điều bắt buộc. Việc viết tư liệu sẽ có thể là của bạn. Mỗi một vấn đề kỹ thuật đi theo cách của bạn sẽ được xem như một cơ hội để rèn luyện người mang vấn đề đó đến cho bạn.
Giúp đỡ người khác, cho dù họ có là những dev khác, những nhà quản lý dự án khác, hay những khách hàng, đều cần trở thành một niềm đam mê của bạn nếu bạn là một nhà lãnh đạo kỹ thuật tham vọng. Điều này có thể có nhiều hình thức khác nhau, nhưng nó nên thấm nhuần tư tưởng vào mọi thứ bạn làm. Đó là lý do vì sao đây là nguyên tắc số 1.
Nó có thể đang cố gắng để bảo vệ chuyên môn của chúng tôi bằng cách làm những thứ xuất hiện phức tạp hơn bản thân chúng hiện có. Nhưng trong thực tế, không mất nhiều trí tuệ để làm một cái gì đó phức tạp hơn nó cần. Nó, tuy nhiên, cần rất nhiều trí tuệ để có một cái gì đó phức tạp mà cũng dễ hiểu.
Nếu những dev khác, và những người không phải dân kỹ thuật, không thể hiểu giải pháp của bạn khi bạn giải thích nó trong điều kiện cơ bản, bạn đã gặp một vấn đề. Xin đừng nghe những điều như: "Tất cả các giải pháp tốt nên đơn giản," bởi vì nó không đúng trong mọi trường hợp - nhưng lời giải thích của bạn thì nên như vậy. Hãy tập suy nghĩ như một người không biết về kỹ thuật để bạn có thể giải thích mọi thứ theo cách của họ. Điều này sẽ làm bạn có nhiều giá trị hơn là chỉ đơn thuần là một nhà lãnh đạo kỹ thuật.
Và đừng xem đó là những điều hiển nhiên rằng bạn sẽ phải vòng vo để giải thích các giải pháp của bạn. Đôi khi, bạn sẽ không bao giờ nhìn thấy những người thực hiện giải pháp của bạn, nhưng còn cái email bạn đã gửi ba tuần trước sẽ biết. Trau dồi những kỹ năng viết lách của bạn. Hãy chọn lấy cuốn sách “ The Sense of Style” của Steven Pinker và đọc trên các văn bản có tính thuyết phục. Bắt đầu một blog và viết một vài bài viết về những gì triết lý về việc code của bạn.
Nguyên tắc đó mở rộng sang cả code của bạn. Nếu đoạn code của bạn thực sự khó để đọc, nó thường không phải là một dấu hiệu cho thấy một người thực sự thông minh đã viết nó; trong thực tế, nó thường có nghĩa là ngược lại. Diễn giả và kỹ sư phần mềm Martin Fowler đã từng nói, "Bất cứ kẻ ngốc có thể viết code mà máy tính có thể hiểu được. Lập trình viên giỏi viết code mà con người có thể hiểu được."
Hãy nhớ rằng: rõ ràng là mấu chốt của vấn đề. Việc nhận thức về trí tuệ của bạn sẽ xác định thực trạng của kinh nghiệm làm việc của bạn, cho dù bạn có thích hay không.
1. Trợ giúp như thể đó là công việc của chính bạn
Thẩm quyền của bạn trong vị trí lãnh đạo kỹ thuật - hay bất kỳ một vị trí lãnh đạo nào - là sẽ đi từ việc bạn có thể làm gì cho những người khác. Quyền... ở đây bắt nguồn từ việc bạn đang được biết đến như một người cố gắng và giải quyết đúng vấn đề cho mọi người. Mục đích là làm cho người khác tìm kiếm bạn, không phải để bạn đuổi theo người khác để cho nhận xét về code của họ. Để điều này xảy ra, trí tuệ và kỹ năng là không đủ - bạn cần phải trở nên có ích.
Đối với các nhà lãnh đạo kỹ thuật, nếu bạn bận đến nỗi không thể trợ giúp người khác được, bạn không làm là việc của bạn - và tôi nói ở đây không chỉ giúp một vài người khi họ đến và yêu cầu sự giúp đỡ. Bạn có thể phải thiết lập một một kỳ vọng đối với cấp trên của mình rằng việc giúp đỡ người khác là một phần quan trọng trong công việc của một nhà lãnh đạo kỹ thuật. Nhưng bạn có biết không? Nó có thể tốn khá nhiều thời gian - hãy trao đổi lại với sếp của bạn. Thậm chí nếu không tốn thời chi phí thời gian cho việc đó, cố gắng ước tính thời gian nó tiết kiệm được cho đồng nghiệp của bạn. Những con số nói lên rất nhiều điều.
Việc đo lường chính xác rằng bạn hữu ích như thế nào là bí quyết kỹ thuật của cả nhóm. Nếu bạn tuyệt vời nhưng nhóm của bạn không thể tạo ra một công việc xuất sắc, thì bạn không phải là một nhà lãnh đạo kỹ thuật - bạn chỉ là một dev cấp cao. Có một sự khác biệt giữa hai điều đó. Mỗi bit của đoạn code mà bạn viết, mỗi bit của tài liệu mà bạn kết hợp với nhau nên phù hợp để sử dụng làm tài liệu sử dụng cho việc đào tạo cho người khác trong nhóm của bạn. Khi đưa ra quyết định về cách để giải quyết một vấn đề hay là nghĩ nên sử dụng công nghệ gì, hãy nghĩ về những gì sẽ trợ giúp cho những nhà phát triển tương lai.
Công việc của tôi như một kiến trúc sư front - end thường xuyên liên quan đến không chỉ là việc viết những đoạn code, mà còn là “dọn dẹp” những đoạn code của người khác để hỗ trợ trong khả năng tái sử dụng và sự hiểu biết đối với những dev khác. Đó là một tập hợp lớn các chức năng có thể hoạt động tốt hơn như là một đối tượng, và nó có lẽ sẽ phụ thuộc vào việc bạn khiến cho nó xảy ra, cho dù thông qua việc đào tạo hay chỉ là làm điều đó.
Nói vê việc đào tạo, nó cần phải là một niềm đam mê. Kinh nghiệm và năng khiếu cho việc đào tạo có lẽ là yếu tố quan trọng nhất trong tôi quyết định gắn bó với vị trí một kiến trúc sư front - end. Nói chuyện trước công chúng hay diễn thuyết là một điều bắt buộc. Việc viết tư liệu sẽ có thể là của bạn. Mỗi một vấn đề kỹ thuật đi theo cách của bạn sẽ được xem như một cơ hội để rèn luyện người mang vấn đề đó đến cho bạn.
Giúp đỡ người khác, cho dù họ có là những dev khác, những nhà quản lý dự án khác, hay những khách hàng, đều cần trở thành một niềm đam mê của bạn nếu bạn là một nhà lãnh đạo kỹ thuật tham vọng. Điều này có thể có nhiều hình thức khác nhau, nhưng nó nên thấm nhuần tư tưởng vào mọi thứ bạn làm. Đó là lý do vì sao đây là nguyên tắc số 1.
2. Đừng ném một tấm nệm vào bể bơi
Một trò đùa tinh quái có thể dạy chúng ta một điều gì đó về việc trở thanh nhà lãnh đạo kỹ thuật. Những chiếc nệm dễ dàng rơi vào bể bơi, nhưng một khi chúng ở trong đó, chúng trở nên gần như không thể mang ra ngoài. Thực vậy , tôi đã tính toán trên: một chiếc nệm cỡ lớn, một khi ngập nước, sẽ nặng hơn 2000 pounds. Có rất nhiều thứ dễ dàng để làm việc trên một codebase: những mô hình, những triết lý code cơ bản, thậm chí những lựa chọn dựa trên công nghệ sử dụng. Nhưng một khi một codebase được xây dựng trên một nền tảng, gần như không thể đưa nền tảng ra khỏi đó mà không xây dựng lại toàn bộ codebase. Khung mẫu mới có vẻ như là một ý tưởng tốt? Bạn nên hy vọng mọi người trong nhóm của bạn biết cách sử dụng khung mẫu như thế nào, và những thứ xung quanh nó trong 6 tháng. Không có thời gian để quay lại và dọn dẹp những đối tượng phức tạp mà bạn viết để xử lý tất cả các chức năng của AJAX? Đừng ngạc nhiên khi mọi người bắt đầu viết những cách giải quyết không cần thiết bởi vì họ không hiểu code của bạn. Bạn có từng bỏ lại đoạn code của mình trong trạng thái nó rất khó đọc và chỉnh sửa? Tôi muốn bạn tưởng tượng đến một tấm nệm bị ném vào trong bể bơi. Không để ý đến lệnh này thường dẫn đến kết quả bạn là người duy nhất có thể làm việc trong một dự án cụ thể. Điều đó không bao giờ là một tình huống hoàn hảo để tham gia. Đây là một trong những sự khác biệt lớn giữa chuyên gia kỹ thuật và một nhà lãnh đạo kỹ thuật: một chuyên gia kỹ thuật có thể dễ dàng giám sát để đưa ra nhận xét. Một nhà lãnh đạo kỹ thuật sẽ có những biện pháp đảm bảo điều đó không bao giờ xảy ra. Là một chuyên gia kỹ thuật, bạn là một người chơi A, và chuyên môn cần thiết ở bất cứ đâu; và khi là một nhà lãnh đạo kỹ thuật, nhiệm vụ của bạn là đảm bảo bạn có thể đáp ứng được những kiến thức chuyên môn đó, dù điều đó có nghĩa là đào tạo những dev khác, việc viết và biên soạn đoạn code giúp những dev khác theo kịp xu hướng, hay là cố ý chọn những mô hình và những phương pháp mà nhóm bạn đã quen thuộc. Jerry Weinberg, trong cuốn “Tâm lý học về lập trình máy tính” có nói: " Nếu một lập trình viên là yếu tố then chốt, dứt bỏ anh ấy càng nhanh càng tốt!" Nếu bạn đang ở một vị trí mà bạn là một phần không thể thiếu được cho một dự án lâu dài, việc khắc phục điều đó cần được đặt lên làm ưu tiên hàng đầu. Bạn sẽ không bao giờ bị ràng buộc bởi một dự án, bởi vì chuyên môn của bạn được cần thông qua cả nhóm. Trước khi xây dựng một codebase trên bất cứ thứ gì, hãy tự hỏi bản thân điều gì xảy ra khi bạn không còn làm dự án. Nếu câu trả lời là họ phải thuê một ai đó thông minh hơn bạn hoặc là dự án đó sụp đổ, đừng tham gia vào dự án đó nữa. Và khi là một nhà lãnh đạo, bạn nên quan sát những người khác để chắc chắn rằng họ không mắc cùng một lỗi. Hãy nhớ rằng, những quyết định về kỹ thuật thường thuộc về những nhà lãnh đạo về kỹ thuật, dù bất kể là ai người làm ra nó.3. Bạn không phải là chuyên gia duy nhất trong lĩnh vực này
“Bởi vì một chương trình mới được viết cho OS8 và có thể chức năng hoạt động nhanh gấp hai lần. Lý do đó đã đủ chưa, Nancy Drew?” Đó là câu mở đầu của Nick Burns, một gã làm IT ở công ty, từ bản phác thảo Saturday Night Live cùng tên. Anh ta là một chuyên gia kỹ thuật thích thể hiện, tra tấn bạn bằng lời nói, sửa máy tính cho bạn, và rồi sau đó xúc phạm bạn trước khi hét lên: “Không có gì đâu!”. Đó là một trong những điều hài hước bởi vì điều đó là đúng. Những hình mẫu của một chuyên gia về công nghệ là những người đối xử với mọi người như cấp dưới phổ biến đến nỗi nó được đưa vào làm thành một vở hài kịch, chương trình truyền hình và những cuộc trò chuyện chia sẻ trong kinh doanh trên khắp cả nước. Tôi đã từng phải đối phó với những chàng trai (hay các cô gái). Chúng ta đều đã từng như vậy. Bạn biết đến những chàng trai sẽ không thừa nhận lỗi lầm của mình, những người trở nên vô cùng cảnh giác bất cứ khi nào có người khác đưa ra ý tưởng của riêng họ, những người xem trí tuệ của mình hơn người khác và để cho những người khác biết điều đó. Trên thực tế, mỗi người làm việc với những dev đều phải đối mặt với những người này ở một số khía cạnh. Phải mất rất nhiều can đảm và tự nhận thức để thừa nhận rằng tôi đã gặp anh chàng trên nhiều hơn một lần. Là một chàng trai thông minh, tôi đã xây dựng lòng tự trọng của tôi về trí tuệ. Vì vậy, khi ý tưởng của tôi bị thử thách, khi trí tuệ của tôi bị nghi ngờ, điều đó như một sự tấn công trực diện vào lòng tự trọng của tôi. Và nó thậm chí còn tồi tệ hơn khi đó là một người ít hiểu biết hơn tôi. Làm thế nào mà họ dám nghi ngờ kiến thức của tôi! Chẳng lễ họ không biết rằng tôi là một chuyên gia kỹ thuật? Thay vì coi đồng đội là những người hiểu biết ít hơn bạn, hãy cố gắng xem họ như là những người biết nhiều hơn bạn trong các lĩnh vực khác nhau. Hãy đối xử với người khác như các chuyên gia trong các lĩnh vực khác mà bạn có thể học hỏi. Quản lý dự án có thể không biết nhiều về cách tiếp cận đối tượng của bạn với các giải pháp, nhưng cô ấy có thể là một chuyên gia trong cách dự án đang vận hành và các khách hàng có cảm giác như thế nào về dự án đó. Một lần nữa, trong cuốn “Tâm lý của lập trình máy tính”, Weinberg nói, "Hãy đối xử với những người biết ít hơn bạn với sự tôn trọng, tôn kính, và kiên nhẫn." Hãy tiến một bước xa hơn. Không chỉ đối xử với họ theo cách này - hãy nghĩ về họ như vậy. Bạn sẽ phải ngạc nhiên trước sự làm việc dễ dàng hơn với họ một cách ngang hàng chứ không phải là những người cấp dưới với trí tuệ kém cỏi - và một sự thay đổi trong suy nghĩ có thể là tất cả những gì cần thiết để tạo nên sự khác biệt đó.4. Trí tuệ đòi hỏi sự rõ ràng
Nó có thể đang cố gắng để bảo vệ chuyên môn của chúng tôi bằng cách làm những thứ xuất hiện phức tạp hơn bản thân chúng hiện có. Nhưng trong thực tế, không mất nhiều trí tuệ để làm một cái gì đó phức tạp hơn nó cần. Nó, tuy nhiên, cần rất nhiều trí tuệ để có một cái gì đó phức tạp mà cũng dễ hiểu.
Nếu những dev khác, và những người không phải dân kỹ thuật, không thể hiểu giải pháp của bạn khi bạn giải thích nó trong điều kiện cơ bản, bạn đã gặp một vấn đề. Xin đừng nghe những điều như: "Tất cả các giải pháp tốt nên đơn giản," bởi vì nó không đúng trong mọi trường hợp - nhưng lời giải thích của bạn thì nên như vậy. Hãy tập suy nghĩ như một người không biết về kỹ thuật để bạn có thể giải thích mọi thứ theo cách của họ. Điều này sẽ làm bạn có nhiều giá trị hơn là chỉ đơn thuần là một nhà lãnh đạo kỹ thuật.
Và đừng xem đó là những điều hiển nhiên rằng bạn sẽ phải vòng vo để giải thích các giải pháp của bạn. Đôi khi, bạn sẽ không bao giờ nhìn thấy những người thực hiện giải pháp của bạn, nhưng còn cái email bạn đã gửi ba tuần trước sẽ biết. Trau dồi những kỹ năng viết lách của bạn. Hãy chọn lấy cuốn sách “ The Sense of Style” của Steven Pinker và đọc trên các văn bản có tính thuyết phục. Bắt đầu một blog và viết một vài bài viết về những gì triết lý về việc code của bạn.
Nguyên tắc đó mở rộng sang cả code của bạn. Nếu đoạn code của bạn thực sự khó để đọc, nó thường không phải là một dấu hiệu cho thấy một người thực sự thông minh đã viết nó; trong thực tế, nó thường có nghĩa là ngược lại. Diễn giả và kỹ sư phần mềm Martin Fowler đã từng nói, "Bất cứ kẻ ngốc có thể viết code mà máy tính có thể hiểu được. Lập trình viên giỏi viết code mà con người có thể hiểu được."
Hãy nhớ rằng: rõ ràng là mấu chốt của vấn đề. Việc nhận thức về trí tuệ của bạn sẽ xác định thực trạng của kinh nghiệm làm việc của bạn, cho dù bạn có thích hay không.
5. Bạn là người tạo nên sự hòa hợp
Hãy tưởng tượng bạn đi đến bác sĩ để giải thích một số triệu chứng lạ bạn đang gặp phải. Bạn ngồi xuống trên giường khám bệnh, một chút lo lắng, một chút bối rối với những gì đang thực sự diễn ra. Khi bạn giải thích tình trạng của bạn, bác sĩ sẽ lắng nghe với đôi mắt mở to và bắt tay vào nhau. Và bạn càng giải thích, nó càng tệ hơn. Bác sĩ thật sự bị shock. Khi bạn cuối cùng cũng hoàn thành, bác sĩ lắp bắp nói, "Tôi không biết làm thế nào để xử lý nó!" Bạn sẽ cảm thấy thế nào? Bạn sẽ làm gì? Nếu là tôi, tôi muốn bắt đầu nói lời tạm biệt với những người thân yêu, vì đó là một điều xấu, dấu hiệu xấu. Tôi đã bị hoảng loạn hoàn toàn dựa trên những phản ứng của bác sĩ. Bây giờ tưởng tượng một người quản lý dự án đến gặp bạn và bắt đầu giải thích các chức năng kỳ lạ cần thiết cho một dự án đặc biệt phức tạp. Khi bạn lắng nghe, nó trở nên rõ ràng rằng điều này là hoàn toàn là một lĩnh vực mới với bạn, cũng như với công ty. Bạn thậm chí không chắc chắn nếu những gì họ đang yêu cầu là khả thi. Làm thế nào để bạn trả lời? Bạn có định sẽ giống như ông bác sĩ điên bên trên? Nếu là bạn như vậy, tôi có thể đảm bảo với bạn rằng quản lý dự án sẽ sợ hãi như bạn, thậm chí là hơn thế. Tôi không nói rằng bạn nên nói dối và bịa ra một điều gì đó, vì nó thậm chí còn tồi tệ hơn. Nhưng học để nói "tôi không biết" mà không có một chút sợ hãi trong giọng nói của bạn là một nghệ thuật mà điều đó sẽ giúp bình tĩnh lại những người trong nhóm, các khách hàng, những người giám sát, và bất cứ ai khác tham gia vào một dự án. (Gợi ý: nó thường liên quan đến ngay sau với, "nhưng tôi sẽ kiểm tra xem nó ra.") Là một nhà lãnh đạo kỹ thuật, mọi người sẽ làm theo cảm xúc của bạn cũng như sự lãnh đạo kỹ thuật của bạn. Họ sẽ nhìn vào bạn không chỉ đối với các câu trả lời, nhưng đối với các mức độ thích hợp của mối quan tâm. Nếu mọi người rời khỏi cuộc họp với bạn mà lo lắng nhiều hơn trước đó, nó có thể là thời gian để có một cái nhìn về cách phản ứng của bạn đang ảnh hưởng đến họ.6. Lãnh đạo kỹ thuật thực sự
Lãnh đạo kỹ thuật lấy con người làm trung tâm cũng giống như lãnh đạo các lĩnh vực khác, và biết cách làm như thế nào để hành động của bạn ảnh hưởng đến những người khác, điều đó có thể làm nên tất cả sự khác biệt trong thế giới trong việc chuyển từ một chuyên gia kỹ thuật sang một nhà lãnh đạo kỹ thuật. Hãy nhớ rằng: việc khiến cho mọi người làm theo chỉ đạo của bạn có thể còn quan trọng hơn biết làm thế nào để giải quyết các vấn đề kỹ thuật. Bỏ qua mọi người có thể quyên sinh vì sự nghiệp cho một nhà lãnh đạo, ảnh hưởng đến họ là nơi điều kỳ diệu thực sự xảy ra.Người dịch: Hà Chi.
Nguồn: alistapart.com.