Nếu có ai là người cuồng nhiệt với công nghệ với tư cách là một lĩnh vực nghề nghiệp hơn tôi, thì tôi chưa từng gặp người đó. Tôi đã lên tiếng rất nhiều lần ở đây và ngoài đời thực về các cơ hội, phần thưởng và sự thỏa mãn khi làm việc trong và với công nghệ.

Đồng thời, khi làm việc với nhiều nhà quản lý khác nhau, tôi nhận ra rằng để vượt qua sự miễn cưỡng của họ - dù đó là việc hợp tác trong một dự án, thuyết phục họ nhận một nguồn lực công nghệ dùng chung vào đội ngũ của mình, hay chỉ là sự cộng tác chung - thì cách tốt nhất là không phóng đại mọi thứ mà hãy cho họ một cái nhìn trung thực về ưu và nhược điểm. Tôi đã làm trung gian cho nhiều mối quan hệ đối tác trong những năm qua bằng cách mang lại cho các nhà quản lý khác thứ mà tôi luôn đòi hỏi: Một cái nhìn trung thực về dữ liệu.

Vì vậy, dưới đây là một số thách thức rất thực tế nếu bạn muốn làm việc trong lĩnh vực công nghệ. Hãy đón nhận nó một cách cởi mở, không điều gì trong số này nên là vật cản đường (roadblock), tất cả đều có thể vượt qua hoặc giảm nhẹ. Tôi thích làm việc trong lĩnh vực công nghệ và dự định tiếp tục gắn bó với nó hoặc các lĩnh vực gần kề ngay cả khi tôi cố gắng đạt được các mục tiêu sự nghiệp của mình.

Chúng ta không đào tạo các nhà quản lý

Khi tôi mới bước chân vào công nghệ, vẫn còn rất nhiều nhà quản lý xuất thân từ nền tảng phi kỹ thuật và thường thì khi bạn có được một người sếp, họ lại không làm cùng công việc với bạn. Tôi vẫn nhớ một trong các giám đốc của tôi, sếp của sếp tôi, thực chất là một cựu quản trị cơ sở dữ liệu Oracle (Oracle DBA) và không biết gì về phát triển phần mềm. Nhiều nhà quản lý được thăng chức vào cuối những năm 90 và đầu những năm 2000 là nhờ Hiệu ứng hào quang (Halo Effect), điều vẫn tiếp tục diễn ra cho đến ngày nay.

Lãnh đạo là một kỹ năng có thể học và cần phải được dạy dỗ. Tôi đã được đào tạo và hầu hết các nhà quản lý giỏi mà tôi biết đều đã trải qua đào tạo. Quan điểm cho rằng chúng ta chỉ cần đôn một người phù hợp lên vị trí lãnh đạo là một quan điểm sai lầm nhưng lại rất thường xuyên được áp dụng. Chúng ta tuyển dụng và thăng chức cho người khác lên các nấc thang sự nghiệp dựa trên quy mô đội ngũ của họ lớn đến đâu chứ không dựa trên khả năng lãnh đạo hay tư duy chiến lược của họ tốt đến mức nào.

Một chuyên gia công nghệ được thăng chức lên vị trí quản lý mà không có bất kỳ sự đào tạo hay hướng dẫn nào có thảm họa. Tuy nhiên, đào tạo lãnh đạo là một lĩnh vực mà tôi thấy đã suy giảm nghiêm trọng từ những năm 90 và tiếp tục bị phớt lờ, ngay cả khi chúng ta bàn về tầm quan trọng của việc tái đào tạo lực lượng lao động (reskilling the workforce).

Chúng ta không thích đào tạo nhân sự của mình

Trong số các công ty tôi đã và đang làm việc cùng, tôi có thể nói rằng khoảng 10% hoặc ít hơn có bất kỳ loại chương trình đào tạo nào, mặc dù ai cũng bàn về lực lượng lao động tương lai và các kỹ năng họ sẽ cần. Ngay cả trong lĩnh vực của tôi, phát triển phần mềm (software development), vốn không ngừng phát triển, rất ít nhà quản lý muốn cho mọi người thời gian từ một tuần đến một tháng để học các kỹ năng mới mà thích họ tự học trong quá trình làm việc hơn. Đào tạo khi đang làm việc (on the job training) rất tốt cho các thao tác cơ bản nhưng lại không quá tốt cho việc thiết kế sâu hơn và các thực hành tốt nhất (best practices).

Chúng ta liên tục thúc ép các chuyên gia công nghệ phải học hỏi nhưng sau đó lại quay ngoắt lại và không cho họ cơ hội để học tập. Ngay cả nơi tôi đang làm việc hiện tại, chúng tôi có các chương trình đào tạo phong phú được cung cấp cho nhân viên, nhưng nhiều nhà quản lý lại ngần ngại cho phép nhân viên dành thời gian trong giờ làm việc bình thường để tận dụng triệt để các chương trình đó. Tôi nghe các nhà lãnh đạo cấp cao của mình nói những điều rất đúng đắn, nhưng những nhà quản lý thực chiến (in the trenches) lại tin rằng nhân viên của họ quá quan trọng đối với các dự án nên không thể để họ đi học. Tôi xin phép để câu cuối cùng đó ngấm vào tâm trí các bạn một chút.

Chúng ta biến mọi phương pháp luận mới thành một cuộc hành quân tử thần (death march)

Ngay cả phương pháp Agile cũng không giải quyết được vấn đề lớn nhất của việc phát triển phần mềm. Thời kỳ dùng mô hình thác nước (Waterfall), chúng ta nhảy từ dự án này sang dự án khác. Mọi giờ trong ngày đều được lên kế hoạch tỉ mỉ và phải được thực hiện chính xác theo đúng vạch ra của người quản lý dự án (project manager). Ngay khi chúng ta hoàn thành bản phát hành (release) và hỗ trợ, lại tiếp tục sang dự án tiếp theo! Chúng ta phàn nàn hết lần này đến lần khác về việc điều này khiến các nhà phát triển (developers) không có gì để mong đợi. Không nghỉ ngơi, không có khoảng thở, không có thời gian tự nhiên cho những kỳ nghỉ hay đào tạo mà không làm ảnh hưởng đến kế hoạch dự án tỉ mỉ đó.

Không vấn đề gì! Chúng ta sẽ chuyển sang Agile! Giờ đây, thay vì mong chờ bắt đầu dự án tiếp theo sau hai tháng nữa, chúng ta sẽ bị vùi dập theo từng khoảng thời gian hai tuần! Mọi thứ tốt hơn rất nhiều vì chúng ta dùng Agile! Kỳ nghỉ ư? Điều đó sẽ làm tổn hại đến vận tốc (velocity) của chúng ta! Chúng ta ở đây là người theo Agile! Bạn có thể đợi được không? Bạn có thể hoãn nó lại khi tồn đọng công việc (backlog) thấp hơn không? Bạn thấy đấy, chúng ta cần bạn lên kế hoạch tỉ mỉ cho thời gian nghỉ phép và đào tạo trong năm vì chúng ta theo Agile và chúng ta không có thời gian để bạn tùy hứng quyết định không có mặt.

Tôi thành thực không nghĩ rằng những người làm công việc thực tế lại quan tâm đến Waterfall, Agile, hay bất kỳ phương pháp luận đình đám nào khác nhiều bằng các nhà tư vấn tổ chức. Họ chắc chắn chẳng thấy mấy lợi ích từ cả hai mô hình này, ngoại trừ việc thay đổi cách họ báo cáo trạng thái.

Chúng ta tuyển dụng những người thông minh và lập tức phớt lờ phán đoán của họ

"Chúng tôi rất vui vì bạn có thể gia nhập đội ngũ của chúng tôi! Chúng tôi cực kỳ yêu thích hơn 10 năm kinh nghiệm trong ngành của bạn, danh sách dài các chứng chỉ và văn bằng giáo dục của bạn, cũng như kiến thức sâu rộng mà bạn thể hiện trong các cuộc phỏng vấn về công việc của mình! Chúng tôi mất nhiều tháng để tìm kiếm bạn và nhiều tuần để tuyển dụng bạn, và chúng tôi vô cùng hào hứng khi bạn đã gia nhập!

Bây giờ đây là các nhiệm vụ của bạn trong 6 tháng tới. Đừng phiền tôi, tôi phải đi đảm bảo tất cả các câu chuyện (stories) của chúng ta đã được cập nhật. Nếu bạn có bất kỳ đề xuất cải tiến nào, tôi chắc chắn rằng chúng tôi đã thử chúng và thất bại rồi, và chúng tôi không hề quan tâm đến việc bạn có thể có một ý tưởng khác giúp nó thành công lần này hay không. Bạn thấy đấy, chúng tôi cũng rất thông minh và bạn chỉ nên tin tưởng chúng tôi thôi."

Thật là ngán ngẩm.

Chúng ta không thân thiện với những người chưa có kinh nghiệm

Các nghiên cứu khoa học máy tính đương đại và nhiều chương trình đào tạo hiện nay thực sự rất tốt. Họ không hẳn đang sản xuất ồ ạt các nhà phát triển (developers) nhưng họ đang cung cấp cho mọi người nền tảng vững chắc mà chúng ta luôn nói là mình cần.

Chỉ có điều là chúng ta dường như muốn có một nhà phát triển làm được việc ngay (ready made developer). Một người không chỉ biết rõ mọi ngóc ngách của ngôn ngữ lập trình mà còn hiểu rõ lĩnh vực (domain) và các ứng dụng mà họ chưa từng thấy trước đây.

"Họ mất quá nhiều thời gian để bắt nhịp!" Thật nhảm nhí, chúng ta không giao cho họ công việc mà họ có thể làm và hỗ trợ họ học hỏi. Thế hệ này sẵn sàng chứng tỏ bản thân hơn bất kỳ thế hệ nào tôi từng thấy, bất chấp mọi điều nhảm nhí chống lại thế hệ Millennials (anti-millennial) mà tôi đọc được suốt ngày.

Ngoài ra, tất cả chúng ta đều bắt đầu như những nhà phát triển cấp dưới (junior developers). Đột nhiên khi đến lượt chúng ta xây dựng tài năng mới thì chúng ta lại không hề có chút hứng thú nào trong việc bỏ công sức vào đó. Công việc khó khăn nhất mà bạn từng làm trong phát triển phần mềm và nhiều phần khác của công nghệ chính là trở thành người lao động ở cấp độ mới vào nghề (entry level worker).

Chúng ta không thân thiện với những người có nhiều kinh nghiệm

Nếu có điều gì tồi tệ hơn việc ở cấp độ mới vào nghề thì đó là việc đã trên 40 tuổi. Sao bạn dám!

Sự kỳ thị tuổi tác (ageism) hoành hành trong công nghệ thường che giấu thực tế rằng sự thiên vị vẫn luôn tồn tại và mạnh mẽ, chỉ là không phải lúc nào cũng ở những hình thức mà chúng ta mong đợi. Tôi thấy rất nhiều giả định được đưa ra về những người ở một độ tuổi nhất định và thường kinh ngạc khi thấy điều đó lại xuất phát từ chính những người cũng đang ngày một già đi (nhân sự trung niên)!

Tôi rất vui khi thấy một cựu binh trong ngành (industry veteran) ứng tuyển vào một vị trí, và mặc dù không phải ai cũng có một buổi phỏng vấn tuyệt vời như bất kỳ vị trí nào khác, bạn phải trải qua vài người để tìm ra người mình muốn. Tôi chỉ không hiểu làm thế nào mà lại hợp lý khi kỳ vọng tất cả các đội ngũ của bạn đều ở độ tuổi từ 28 đến 37. Hoàn toàn sai lầm khi đưa ra giả định về một ai đó dựa trên độ tuổi của họ. Chúng ta nên dành thời gian phỏng vấn, tìm hiểu kỹ năng và kinh nghiệm thực tế của họ, và đưa ra quyết định tuyển dụng dựa trên năng lực (merit) giống như đối với bất kỳ ai khác.

Chúng ta thường hành xử như một hội nghề nghiệp (guild)

Nếu không vì điểm tiếp theo của tôi, thì đây sẽ là điều phàn nàn lớn nhất của tôi về lĩnh vực công nghệ. Mọi người tự hỏi tại sao tôi lại phản đối chứng chỉ (anti-certification), đó là bởi vì chúng ta đã cố gắng làm cho mọi thứ có vẻ như có một rào cản rất lớn cần phải vượt qua.

Nhìn xem, tôi thích các chương trình khoa học máy tính đương đại nhưng bạn không cần bằng đại học bốn năm để học cách phát triển phần mềm. Tất cả kiến thức đều ở đó, hầu hết là miễn phí. Mọi thứ từ học các ngôn ngữ khác nhau cho đến các nguyên

lý cơ bản cốt lõi. Giá trị duy nhất thực sự của các trường đại học là môi trường lớp học có cấu trúc giúp ép buộc một mức độ kỷ luật nhất định. Nếu không, tôi có thể tìm thấy theo đúng nghĩa đen tất cả các tài liệu giống như bạn nhận được từ một trường đại học ở trên Internet.

Phát triển phần mềm có cảm giác giống như Phù thủy xứ Oz (Wizard of Oz). "Đừng bận tâm đến người đàn ông đằng sau tấm rèm kia!" Tôi hiểu thế giới phát triển phần mềm rõ nhất, nhưng điều này áp dụng cho bất kỳ công việc nào trong lĩnh vực của chúng ta. Bạn có thực sự cần bằng đại học để trở thành một người quản lý dự án (project manager) hay một Huấn luyện viên Agile (Agile Coach) không? Có thực sự cần không?

Chúng ta có một hệ thống giai cấp (caste system)

Agile đã thất bại trong việc xóa bỏ ranh giới giữa nhà phát triển (developer), kiểm thử chất lượng (QA), quản trị hệ thống (sysadmins), và các vai trò khác. Thành thật mà nói, điều đó không thực tế vì đó là những vai trò thực sự có các kỹ năng và tư duy rất khác biệt nhau. Dù sao đi nữa, ý tưởng chuẩn hóa các chức năng công nghệ nghe có vẻ rất tuyệt đối với tôi.

Thực tế phũ phàng là có một hệ thống giai cấp và các nhà phát triển nằm ở trên cùng. Tôi nói điều này với tư cách là một cựu nhà phát triển. Tôi thừa nhận rằng họ thường là những người có nhu cầu cao nhất và đôi khi khó tìm nhất. Chúng ta không thể làm phát triển phần mềm nếu không có các nhà phát triển. Dù vậy, chúng ta thường đối xử với họ như những người đặc biệt, trong khi ngành công nghiệp này thường nhanh chóng cắt giảm kiểm thử chất lượng (QA) hoặc quản lý dự án (project managers) bất chấp những đóng góp hoặc giá trị thực tế của cá nhân đó đối với tổ chức.

Bây giờ là một góc nhìn tổng quan (perspective)

Tất cả những điều này nghe có vẻ rất tiêu cực nhưng tôi tưởng tượng bạn cũng có thể tạo ra một danh sách tương tự cho các nghề nghiệp tài chính, luật pháp, y tế, hoặc bất kỳ ngành nghề nào khác. Công nghệ không có gì độc quyền cả. Bất chấp tất cả các điểm tôi đã liệt kê ở trên và việc phải vượt qua phần lớn trong số đó, tôi vẫn là một người ủng hộ sự nghiệp công nghệ dưới nhiều hình thức của nó.

Bất chấp những cuộc vật lộn của chúng ta với việc đào tạo, đây vẫn là một trong những lĩnh vực tốt nhất để liên tục chịu thử thách về mặt trí tuệ, trả lương cao, và nó có một con đường sự nghiệp rõ ràng bất chấp nhiều tuyên bố ngược lại. Tôi thực sự yêu thích nó, với tất cả những điểm tốt và xấu, nhưng khi bạn gặp phải một số khía cạnh này, đừng ngạc nhiên và hãy biết rằng luôn có cách lách qua hoặc vượt qua tất cả chúng khi bạn tiến bước trên con đường sự nghiệp của mình.