Chú thích: Bài viết bên dưới được dịch từ những chia sẻ từ kinh nghiệm thực tiễn của Kỹ sư phần mềm Zain Rizvi, một kỹ sư phần mêm dày dặn kinh nghiệm, người đã giúp xây dựng AI Platform Notebooks trên Google Cloud Platform và Nền tảng ứng dụng Azure (Azure App Platform) của Microsoft. Trong bài viết, Zain chia sẻ cách tiếp cận và thực thi các dự án phát triển phần mềm khi làm việc tại vị trí Senior Engineer tại Google và Microsoft, và cũng là khuôn mẫu chung khi thực hiện dự án ở "cấp bậc senior".

__________________________________

Khi tôi bắt đầu làm việc tại Microsoft, lúc mới ra trường, lập trình là cuộc sống của tôi. Viết code là cách dễ nhất để xây dựng bất kỳ thứ gì thú vị mà não của tôi có thể tưởng tượng ra. Khi tôi nghĩ về những gì tôi muốn làm trong suốt phần đời còn lại của mình, tôi nghĩ rằng tôi chỉ muốn tiếp tục viết code.

Trong 11 năm tiếp theo, tôi trở thành senior engineer tại Microsoft và chuyển sang làm việc tại Google và sau đó là Stripe. Ở những cấp độ cao hơn này, tôi vẫn phải xây dựng, nhưng phải sử dụng một bộ công cụ rất khác. Cần có một sự thay đổi tư duy rất lớn khi bạn chuyển từ junior lên senior. Viết code dần trở thành một phần nhỏ của công việc.

Đã bao giờ bạn tạo ra một công cụ mà không ai sử dụng? Tôi thì có. Nó khá tệ. Ở cấp độ senior, hầu hết thời gian của bạn dành cho việc xác định những gì cần được xây dựng và cách xây dựng nó. Bạn phải nghiên cứu xem vấn đề trông như thế nào, bạn nói chuyện với những người khác và khiến mọi người đồng ý về những gì cần phải làm.

Đây là những “công cụ” mới của bạn:

• Nghiên cứu vấn đề

• Thiết kế giải pháp

• Xây dựng sự đồng thuận

Nghiên cứu như một thám tử

Vừa tốt nghiệp đại học, bạn nhận được các nhiệm vụ và có được câu trả lời đúng một cách dễ dàng. Không có nhiều ý kiến ​​bất đồng về việc phải làm gì ngoài phản hồi không thường xuyên trong các bài đánh giá code.

Khi bạn có nhiều kinh nghiệm hơn, bạn sẽ có nhiều hướng tiếp cận vấn đề hơn. Con đường bạn đi thật mơ hồ, có nhiều tuyến đường bạn có thể đi, nhưng mỗi con đường đều ẩn chứa những sự khó khăn riêng. Nó chỉ gói gọn trong việc viết code nữa, mà hầu hết công việc của bạn là nghiên cứu và bạn không thể tra Google để tìm câu trả lời.

Nghiên cứu có thể có nhiều hình thức. Nó thường bao gồm sự kết hợp của việc đọc code, đọc tài liệu và nói chuyện với mọi người. Vâng, là với con người thực sự. Trên thực tế, hầu hết các thông tin bạn cần đều bị khóa, và bạn đã bao giờ thấy Sherlock Holmes sử dụng công cụ tìm kiếm chưa?

Thường sẽ không có ai biết câu trả lời mà bạn cần. Năm người khác nhau có thể giữ năm mảnh ghép khác nhau mà bạn đang lắp ráp. Và bạn không biết năm người đó là ai. Và họ không biết bạn cần mảnh nào.

Bạn phải tìm họ và đặt những câu hỏi phù hợp để sàng lọc trong não của họ, khám phá ra những tinh hoa mà bạn cần.

Chắt lọc tinh hoa

Tại Google Cloud Platform, khách hàng thường liên hệ với Technical Solutions Engineer (TSE) để được trợ giúp khi gặp sự cố. Các TSE đó đã đào sâu vào các vấn đề và khắc phục chúng.

Quản lý của tôi có một ý tưởng: “Sẽ rất tuyệt nếu chúng ta có thể sử dụng AI để tự động hóa quy trình đó nhỉ?” Chúng tôi không biết phải làm thế nào, thậm chí không biết liệu nó có khả thi hay không. Rất tiếc, chúng tôi còn không chắc chắn loại vấn đề mà khách hàng yêu cầu trợ giúp, nhưng, đó là thách thức mà quản lý của tôi đưa ra.

Tôi chấp nhận thách thức.

Giờ đây, bất kỳ giải pháp AI nào cho loại vấn đề này đều cần rất nhiều dữ liệu. AI cần nhìn thấy nhiều môi trường rời rạc để hiểu chúng trông như thế nào. Và khi đi sâu vào tìm kiếm, tôi nhận ra rằng chúng tôi không có dữ liệu đó, tất cả đều nằm trong bộ não của những TSE. Bạn không thể đào tạo AI để thực hiện điều đó được.

Tôi đã phải tìm ra các mẫu (pattern). Có thể trò chuyện với TSE sẽ giúp tôi hiểu thêm điều gì đó…

Tôi: "Vậy, bạn thường gặp phải vấn đề gì?"

TSE: "Các vấn đề không lần nào giống lần nào"

Khỉ thật, Tương lai của AI trông thật ảm đạm.

Tôi: "Vậy bạn làm gì để giải quyết nó?"

TSE: “Cũng tùy, dựa trên sự cố đó, chúng tôi sẽ truy vấn cơ sở dữ liệu này hoặc cơ sở dữ liệu khác. Sau đó, điều đó sẽ dẫn chúng tôi tới một nơi khác và chúng tôi lại tiếp tục tìm hiểu cho đến khi chúng tôi phát hiện ra điều gì bất ổn. Và rồi, chúng tôi sửa chữa nó ”.

Không có dữ liệu chắc chắn về những vấn đề họ giải quyết. Không có cách lặp lại để sửa chữa chúng. Tôi đã sẵn sàng từ bỏ.

Nhưng khoan.

“Hãy cho tôi biết thêm về những truy vấn mà bạn chạy được không?”

Nếu tôi thay đổi vấn đề thì sao? Có lẽ tôi không cần phải khắc phục những vấn đề của khách hàng ngay lập tức. Điều gì sẽ xảy ra nếu tôi giúp các TSE sửa lỗi nhanh hơn? Tôi sẽ chạy tự động hàng trăm truy vấn mà họ có thể chạy và đề xuất rằng: “Này, câu hỏi này có một kết quả đáng ngờ. Có thể đào sâu hơn một chút tại đây nhỉ? ” Đó là hàng loạt những việc sửa lỗi, mà các TSE có thể bỏ qua.

Tôi thậm chí có thể mở rộng ý tưởng này để thu thập dữ liệu cần thiết cho một hệ thống AI thực tế. Chuyện này thực sự có tiềm năng! Và họ - các TSE - rất vui mừng. Đội của tôi rất phấn khích. Người quản lý của tôi rất phấn khích. Chúng tôi bắt đầu viết mã.

Thiết kế: Nghệ thuật của sự cân bằng

Với những vấn đề mơ hồ không có câu trả lời đúng duy nhất. Có thể không có bất kỳ câu trả lời nào. Những gì bạn đang đối mặt có thể là một vấn đề đau đầu của khách hàng, của nhóm bạn hoặc thậm chí là của chính bạn. Công việc của bạn là xóa bỏ vấn đề đó mà không gây ra những khó khăn lớn hơn.

Có một điều thú vị về các vấn đề không rõ ràng: chúng không có câu trả lời thỏa đáng. Mọi giải pháp đều mang lại những lợi ích và mặt trái nhất định. Bạn càng khám phá được nhiều điều trong số đó, bạn càng có khả năng cân bằng tốt hơn những đánh đổi mà bạn phải thực hiện. Một số đánh đổi phổ biến cần xem xét:

• Sẽ mất bao lâu để phát triển giải pháp?

• Chi phí cơ hội là gì?

• Nó có rủi ro như thế nào? Điều gì xảy ra nếu điều đó không thành công?

• Sẽ có bao nhiêu công việc để duy trì điều này về sau?

• Nó sẽ mở rộng bao xa? Và cần bao lâu?

Với những vấn đề không rõ ràng này, đôi khi câu trả lời tốt nhất có thể là tiếp tục làm công việc mà chúng ta đã và đang làm. Đó là một bài học khó.

Trẻ và ngây thơ

Khi tôi còn là một cậu chàng vừa mới ra trường được bốn năm, tôi được yêu cầu nghĩ cách để làm cho việc nâng cấp cơ sở dữ liệu của chúng tôi ít rủi ro hơn. Nhóm sẽ xem xét một cách thủ công tất cả các thay đổi đã được lên kế hoạch, để đảm bảo chúng được an toàn, nhưng thỉnh thoảng lại xảy ra lỗi và mọi người phải cuống cuồng để sửa nó, trong căn phòng ngập tràn tiếng máy nhắn tin (pager).

"Chúng ta có thể xây dựng một công cụ để bắt kịp những thay đổi rủi ro đó không?" quản lý của tôi hỏi tôi. Woah, đây là một vấn đề kết thúc siêu mở. Tuyệt vời! Tôi quyết tâm không để anh thất vọng. Điều này đòi hỏi phải đào sâu vào các phương pháp hay nhất về nâng cấp cơ sở dữ liệu (tôi thậm chí đã đọc hết thảy cả một cuốn sách về nó). Tôi đã dành những ngày nghỉ đông vất vả cốt chỉ để phát triển một mẫu thử nghiệm (prototype) nhằm giúp việc nâng cấp diễn ra một cách an toàn. Và tôi đã thành công! Có vẻ vậy.

Khi tôi cho người quản lý xem tác phẩm của mình, anh ấy đã lo lắng: “Bạn biết không, hãy cứ tiếp tục làm những việc theo cách chúng ta làm hiện tại.”

Ôi!

Đó là một bài học khó nhằn về quản lý rủi ro, nhưng anh ấy đã đúng. Một lỗi trong công cụ của tôi có thể khiến toàn bộ dịch vụ của chúng tôi đi tong. Thật không đáng để mạo hiểm.

Tôi đã học được nhiều bài học trong ngày hôm đó:

• Xem xét mức độ rủi ro của bất kỳ dự án mới nào có thể thêm vào hệ thống

• Không sao cả. Nếu bạn không bao giờ thất bại thì bạn đang không vươn mình

• Nhận phản hồi sớm!

Để có được thông tin phản hồi là việc tối quan trọng. Hãy cho mọi người biết bạn định làm những gì trước khi xây dựng nó và để họ cảnh báo bạn về các cạm bẫy có thể có khi bạn bước vào. Nếu như tôi chia sẻ thiết kế đó với người quản lý của mình trước khi xây dựng nó thì dự án đó đã được hủy vài tuần trước đó rồi, điều đó sẽ giúp tôi có một kỳ nghỉ đông thư giãn.

Nhưng việc thu thập thông tin phản hồi đòi hỏi một kỹ năng mềm: sự đồng cảm. Bạn có thể hiểu tại sao mọi người không đồng ý với bạn? Họ xem trọng điểm khác nhau nào?

Không phải lúc nào bạn cũng đồng ý với phản hồi, nhưng bạn phải hiểu nó. Chỉ khi đó, bạn mới có thể tiến về phía trước với một tầm nhìn mới mà mọi người đều có thể theo sau.

Xây dựng sự đồng thuận

Độ quan trọng của việc nhận được các phản hồi và đồng ý về kế hoạch sẽ tăng dần, khi dự án của bạn trở nên lớn hơn.

Bạn có thể bắt đầu bằng việc đồng ý từ người quản lý của mình (là người đã giao cho bạn nhiệm vụ mơ hồ đó). Nhưng bạn sẽ cần phải xây dựng sự đồng thuận với các thành viên còn lại trong nhóm và thậm chí cả những người bên ngoài nhóm có liên quan tới công việc của bạn.

Điều này đòi hỏi kỹ năng giao tiếp, cả việc hiểu và được hiểu.

Một khi tôi được giao nhiệm vụ tạo ra thế hệ tiếp theo của hệ thống quản lý cơ sở dữ liệu nội bộ của chúng tôi. Đây là điều mà nhiều đội phụ thuộc vào và giải pháp hiện tại của chúng tôi sẽ ngừng mở rộng quy mô xuyên suốt một hoặc hai năm. Nhóm của tôi có bảy người, với tám ý kiến ​​khác nhau về việc nên có một hệ thống thế nào (bao gồm người quản lý của tôi và sếp cấp trên của anh ấy).

Bước đầu tiên là nói chuyện với tất cả họ để thực sự hiểu mối quan tâm và ưu tiên của họ. Nhưng có một tiếng nói khác mà tôi muốn nghe: từ khách hàng của chúng tôi! Đây được coi là một hệ thống dành cho các nhóm kỹ sư khác, làm thế nào tôi có thể xây dựng giải pháp cho họ mà không hiểu các vấn đề của họ? Phải mất một chút thời gian để tìm ra những người dùng đó là ai. Điều này đòi hỏi một kỹ năng mềm khác: Nghệ thuật tìm kiếm người bạn cần trò chuyện.

Cuối cùng thì tôi đưa họ vào phòng để nói chuyện. Tại đó, họ tung tin giật gân rằng: “Chúng tôi thực sự không thể chứng minh cho việc chuyển sang bất kỳ hệ thống mới nào. Hệ thống hiện tại hoạt động đủ tốt và chúng tôi có nhiều vấn đề cấp bách hơn cần khắc phục.” Tôi đã nói chuyện với ba đội khác nhau và lần nào cũng nhận được câu trả lời y hệt nhau. Khổ thật, vậy xây dựng một giải pháp thì có ích gì nếu không có ai sử dụng nó?

Một sự dịch chuyển đã xảy ra, hệ thống hiện tại sẽ sớm ngừng đáp ứng các tiêu chuẩn về độ tin cậy của chúng tôi. Có một số lựa chọn trước mắt như:

• Chính trị: nói quản lý chuỗi của tôi thuyết phục quản lý chuỗi của họ để buộc họ phải thay đổi. Điều này thật kinh khủng.

• Thuyết phục: Dạy cho các nhóm đó biết lý do tại sao khó khăn họ đang đối mặt hiện tại chả hề hấn gì nếu so với khó khăn sẽ gặp phải trong vài năm sắp tới. Đây là một điều khó chứng minh và chúng tôi phải làm cho ra lẽ với rất, rất nhiều nhóm. Điều này không thể mở rộng ra được.

Và có một lựa chọn thứ ba: thay đổi các ràng buộc. Điều gì sẽ xảy ra nếu tôi nói "không" với một số tính năng mà tôi được yêu cầu sẽ thêm vào? Việc loại bỏ điều đó sẽ giúp tôi thiết kế hệ thống theo cách mà chúng tôi có thể chuyển dịch tất cả khách hàng của mình theo một cách tự động. Sẽ không cần bất cứ nỗ lực nào từ họ. Chúng tôi sẽ hoán đổi động cơ với chiếc xe đang phóng xuống đường cao tốc.

Hướng này dễ chịu hơn nhiều. Và bằng cách làm nổi bật sự đẩy lùi (pushback) của người dùng, tôi đã thuyết phục các bên liên quan khác thay đổi và bỏ những ràng buộc đó.

Tạm kết

Đó là quy trình chung của bất kỳ dự án nào bạn thực hiện ở cấp senior: Bạn nghiên cứu vấn đề, thu thập các mảnh ghép, hiểu thế giới tốt hơn. Bạn thiết kế một giải pháp, thu thập phản hồi và điều chỉnh hành động khi cần thiết. Sau đó, việc thực hiện bắt đầu.

Vậy làm thế nào để bạn học được tất cả những kỹ năng này? Kinh nghiệm. Hãy rời khỏi tổ và vỗ đôi cánh của mình đi. Nếu cơ hội xuất hiện, hãy chớp lấy nó. Bạn sẽ không thấy sẵn sàng, không một ai thấy sẵn sàng, nhưng điều đó chắc chắn khiến bạn trải nghiệm và học nhiều hơn từ kinh nghiệm của mình.

Yêu cầu giúp đỡ. Lắng nghe câu trả lời bạn nhận được. Tiếp tục cố gắng. Vào cuối dự án, hãy yêu cầu nhận phản hồi và dựa vào nó để cải thiện bản thân nhanh hơn. Bạn chỉ có thể học những kỹ năng này bằng cách luyện tập.

Đó là một thế giới mới tại mức độ senior. Bạn vẫn sẽ tiếp tục xây dựng những sản phẩm của mình, nhưng với các công cụ mới, bạn sẽ xây dựng được quy mô lớn hơn và tốt hơn trước đây.

VietnamWorks inTECH
Theo Zain Rizvi