Con dao của quân đội Thụy Sĩ hay chuyên gia tổng quát

Trong bài viết “Liệu việc viết code có quan trọng?”, tôi đã đề nghị các lập trình viên dành ít thời gian hơn với các công việc kỹ thuật, vì đó là thứ mà họ đã tương đối giỏi, và dành nhiều thời gian hơn để trau dồi các kỹ năng phi kỹ thuật khác mà các lập trình viên có xu hướng thiếu hụt. Một độc giả đã đặt vấn đề với cách tiếp cận như sau:

Tôi không đồng ý với quan điểm về việc nên cải thiện những điểm yếu. Tôi thích quan điểm về việc phát triển tài năng và nhận thức được những điểm yếu của mình. “Biết rõ bản thân mình” không có nghĩa là đi học tất cả mọi thứ và trở thành một Con dao của quân đội Thụy Sĩ (Swiss Army Knife).

Rất dễ để biến đề nghị khiêm tốn của tôi trở thành một ý kiến cực kỳ ngớ ngẩn: hoặc là bạn ngồi viết code suốt ngày, hoặc bạn trở thành một người hoàn toàn không có kỹ năng về kỹ thuật và không bao giờ chạm vào một trình biên dịch nữa. Hoặc có thể bạn dành quá nhiều thời gian để theo đuổi những thú vui liên quan để bạn trở thành một người cái gì cũng biết một tí, nhưng chẳng tinh thông món nào cả. Hay nói cách khác, sẽ trở thành một Con dao của quân đội Thụy Sĩ (Swiss Army Knife).

Hãy trở thành một chuyên gia tổng quát chứ đừng là một Swiss Army Knife.

Thứ nhất, có một điều cần làm rõ. Việc nuôi dưỡng những kỹ năng phi kỹ thuật, đầu tiên và trước hết, là về việc trở thành một nhà phát triển phần mềm tốt hơn. Nếu bạn muốn giàu có, nổi tiếng, và được gái gú bu xung quanh, thì bạn đã chọn sai nghề rồi. Tôi xin lỗi vì phải nói ra sự thật này với bạn.
Thay vì một Con dao của quân đội Thụy Sĩ (Swiss Army Knife), bạn nên cố gắng để trở thành một chuyên gia tổng quát.

Một chuyên gia tổng quát là người có một hoặc nhiều chuyên môn về kỹ thuật, họ tích cực tìm kiếm để đạt được những kỹ năng mới trong cả chuyên môn hiện tại của họ cũng như trong các lĩnh vực khác, bao gồm cả lĩnh vực kỹ thuật và những thứ liên quan. Khi bạn kiếm được công việc đầu tiên với tư cách là một chuyên gia IT thì thường là trong vai trò của một lập trình viên junior hoặc DBA junior. Ban đầu bạn sẽ tập trung vào việc trở nên giỏi ở vai trò đó, và nếu bạn may mắn thì công ty sẽ cho bạn tham gia các khóa đào tạo để có được các kỹ năng nâng cao trong chuyên môn của mình. Một khi bạn đã giỏi trong công việc chuyên môn đó, hoặc ngay cả khi bạn vừa đạt đến điểm của sự thoải mái ở công việc này, thì đó là lúc để mở rộng tầm nhìn và học thêm các kỹ năng mới trong các khía cạnh khác của vòng đời phát triển phần mềm và trong phạm vi liên quan đến công việc kinh doanh của công ty. Khi bạn làm điều này bạn sẽ phát triển từ một chuyên gia để trở thành một chuyên gia tổng quát. Các chuyên gia tổng quát thường được gọi là các nghệ nhân, lập trình viên đa lĩnh vực, lập trình viên đa năng, học giả, hoặc thậm chí “các lập trình viên phục hưng”.
Một chuyên gia tổng quát là nhiều hơn so với một người biết rộng. Một người biết rộng là một người mà cái gì cũng biết một chút nhưng không tinh thông cái nào cả, trong khi một chuyên gia tổng quát là một người biết rất nhiều thứ, và tinh thông một vài thứ. Đó là một sự khác biệt lớn.

Quá nhiều chuyên môn lại là một cái bẫy của chính nó. Bạn đã bao giờ làm việc trên các dự án mà bạn vừa là “một gã chuyên về cơ sở dữ liệu”, “một gã tester”, “một gã lập trình web”, và vân vân? Wayne Allen đề cập đến điều này như một quy trình bốc mùi– chờ đợi các chuyên gia.

Một quy trình bốc mùi phổ biến trong các nhóm agile là ngày càng có nhiều stories/backlog item không được hoàn thành ở cuối mỗi vòng lặp. Có một vài lý do khác nhau về điều này, nhưng một lý do tôi quan tâm hiện nay có thể được phát hiện ra qua câu nói phổ biến của một thành viên nào đó: “Tôi đã hoàn thành tác vụ của mình”. Điều đó hàm ý rõ ràng là “Tôi đã hoàn thành phần việc của tôi, nhưng một ai đó trong nhóm vẫn chưa hoàn thành”.
Một vài nghiên cứu bổ sung cho thấy rằng người đó đang chờ đợi những người khác với một số loại chuyên môn như cơ sở dữ liệu, QA, UI, hoặc bất kỳ kỹ năng khác mà không được phân phối rộng rãi trong nhóm. Trong một nhóm agile thì sự chuyên môn hóa sẽ bị ngăn chặn. Trong một dự án truyền thống thì đơn vị để đo lường mức độ hoàn thành là tác vụ, tuy nhiên trong các dự án agile thì việc đo lường mức độ hoàn thành lại là các tính năng làm việc được. Các chuyên gia không cung cấp kết quả công việc là các tính năng làm việc được thì sẽ biết ngay là họ có vấn đề. Lưu ý là tôi không nói rằng việc chuyên môn hóa là không cần thiết, nhưng họ cần phải cân bằng với những nhu cầu khác để có thể đưa ra được các tính năng.

Làm thế nào để bạn biết liệu mình có đang trên con đường để trở thành một chuyên gia tổng quát? Vâng, cũng như trong bất kỳ chế độ tập luyện nào, bạn nên thường xuyên vượt ra khỏi vùng thoải mái của mình (comfort zone). Đôi khi bạn phải căng mình ra một chút:

Các chuyên gia tổng quát luôn sẵn sàng và có thể học các kỹ năng mới – có thể căng mình ra theo nhu cầu thay đổi của nhóm. Và kể từ khi thay đổi là tự nhiên, thì đây là một thái độ cần thiết cho các thành viên trong nhóm. Tuy nhiên, chúng ta thường được đào tạo và khuyến khích mạnh mẽ để có một trình độ chuyên môn sâu sắc. Cách tiếp cận này đưa giáo dục và đào tạo thành một hệ quả tự nhiên của mô hình tổ chức điển hình trong công việc và xã hội. Do đó, nếu một nhóm đang chuyển đổi sang phương thức làm việc agile, thì mọi người cần phải được huấn luyện để có thể căng mình ra và học hỏi những điều mới.

Tôi thấy rất nhiều các nhà phát triển phần mềm cứ đào ngày một sâu hơn vào chỉ một tập kỹ năng và chuyên môn nào đó. Rất dễ để bạn bị rơi vào lối mòn này. Có cả một vũ trụ của những kỹ năng kỹ nghệ phần mềm bên ngoài lĩnh vực hẹp của lập trình. Để trở thành một nhà phát triển phần mềm giỏi hơn, hãy phát triển từ một chuyên gia thành một chuyên gia tổng quát.