Làm sao để trở thành một Technical Architect?

“Làm việc ở công ty Product có lợi thế hơn rất nhiều để developer trở thành Technical Architect.”

– Hải Nguyễn, Chief Technical Architect của eSoftHead

Đọc bài phỏng vấn của ITviec với anh Hải để nghe anh chia sẻ về:

• Trách nhiệm của một Technical Architect là gì? Những kỹ năng nào là cần thiết?
• Career path của một Technical Architect gồm những bước đi nào?
• Lời khuyên và tips thực tế dành cho Technical Architect trẻ.

Tiểu sử: Anh Hải đi từ Software Developer → Technical Lead → Project Manager → Senior Project Manager → Chief Technical Architect. Với 14 năm kinh nghiệm về phát triển phần mềm, anh quản lý kĩ thuật cho công ty riêng là eSoftHead và một công ty outsourcing có trụ sở bên Úc. Ngoài ra, anh còn phát triển một dịch vụ đám mây về quản lý khách hàng và quản lý dự án là MyCollab, một phần sản phẩm này được dùng làm mã nguồn mở và có nhiều công ty sử dụng.

Anh có thể cho biết trách nhiệm thường ngày của 1 TA là gì?

TA chịu trách nhiệm tổng thể toàn bộ các hoạt động kỹ thuật liên quan đến project. Ví dụ như:

• Chọn lựa công cụ, tìm giải pháp trước và trong quá trình phát triển phần mềm.
• Xác định mối quan hệ giữa component trong system và trách nhiệm của từng component để thiết kế hệ thống tối ưu cho việc vận hành, bảo trì và chuyển giao cho khách hàng theo đúng yêu cầu về tính năng, tốc độ và bảo mật.
• Quản lý các hoạt động liên quan đến kĩ thuật như training, review, monitoring… để đảm bảo development team viết code, document theo đúng yêu cầu hệ thống xác định.
• Làm việc với khách hàng định kì để đảm bảo architect đáp ứng đủ yêu cầu của hệ thống, cập nhật design cho các yêu cầu mới.
• Áp dụng những best practices để cải tiến qui trình, chất lượng của phần mềm ở tất cả các khâu như development, testing, deployment, transition.

Theo anh, TA khác developer như thế nào?

Scope of work. Developer tập trung làm một công việc được giao, ví dụ như phát triển một component trong project, và phải tuân theo những quy tắc architect qui định.

Scope of work của TA lớn hơn, họ chịu trách nhiệm quản lý kỹ thuật của toàn bộ dự án. Hoạt động của TA không chỉ liên quan đến code, mà cả design, testing, quản trị phần mềm…

Anh Hải mặc sơ-mi trắng ngồi giữa

Anh nghĩ một TA bình thường có cần kỹ năng quản lý không?

Bản thân TA không cần kỹ năng quản lý như PM. Ví dụ PM phải quản lý về con người, scope project, schedule, tất cả project activities để đảm bảo delivery tốt. Còn TA thì tập trung mảng kỹ thuật nhiều hơn, cụ thể là technical activities.

Nhưng TA vẫn cần kỹ năng quản lý đối với development team. Hai vấn đề quan trọng của project là cost và schedule. TA khi đưa ra một giải pháp thì không chỉ quan tâm việc giải pháp tốt về mặt kĩ thuật mà còn phải cân bằng các yếu tố về chi phí, thời gian mà development team có thể hoàn thành.

Theo anh, những yếu tố quan trọng nhất đối với một TA là gì?

Mảng software có nhiều platform, language, operate system khác nhau. TA chắc chắn không thể biết tất cả. Nhưng những điều mà TA cần có là:

1. Từng là developer tốt. Đây là điều kiện cần để TA có thể tự mình đánh giá và quản lý chất lượng code, document của sản phẩm, những vấn đề khác liên quan đến performance/security của hệ thống.
2. Có kiến thức về thiết kế hệ thống phần mềm theo hướng đối tượng cho các dự án vừa và lớn. Cập nhật kiến thức mới về công nghệ như cloud computing, mobile, NoSQL.
3. Có kinh nghiệm về các best practices của hoạt động phát triển phần mềm như continuous integration build, unit test, TDD.
4. Có kiến thức về business domain mà dự án của mình đang làm. Ví dụ công ty em đang làm một sản phẩm về banking/finance, em phải có kiến thức về những lĩnh vực đó.

Anh có nghĩ rằng khó để tìm được một TA đúng nghĩa tại VN? Vì sao lại khó?

Nhu cầu tuyển dụng TA khá nhiều nhưng khó tìm được ứng viên phù hợp. Nguyên nhân của vấn đề này xuất phát từ hai phía: ứng viên và nhà tuyển dụng.

1. Developer thiếu thực hành. Ví dụ công ty anh có những loại project nào, anh làm như thế, anh không được thực hành tất cả những kỹ năng, kiến thức cần thiết cho một người TA đúng nghĩa. Đa số project của các công ty không đủ độ phức tạp để mọi người có thể rèn luyện. Một TA cần rất nhiều kỹ năng khác nhau: code, design architect, viết document, đánh giá các công cụ và giải pháp, qui trình phần mềm…
2. Nhiều công ty chia nhiệm vụ của developer theo chức năng, như là back-end, front-end, server-site, networking, system administrator. Điều này tạo sự chuyên môn hóa cao nhưng cũng đồng thời tạo ra những người thợ chuyên về một lĩnh vực nào đó. Anh chỉ biết được công việc trong một công đoạn phát triển phần mềm, nếu anh là UI/UX developer, anh chỉ biết về UI/UX, anh không biết nhiều về các công nghệ bên server side và ngược lại. Chỉ làm một loại công việc trong thời gian dài hạn chế khả năng developer muốn phát triển sự nghiệp thành TA.
3. Cách thức tuyển dụng của nhiều công ty là tìm ứng viên đáp ứng đúng yêu cầu về kĩ thuật hiện tại mà chưa quan tâm nhiều đến khả năng phát triển của nhân viên trong tương lai. Ví dụ công ty có nhu cầu tuyển dụng về Java, Ruby on Rails, .NET thì thường tuyển TA đúng với kĩ năng đó. Cách tuyển này gây hạn chế cho công ty tuyển dụng vì như anh nói ở trên thì TA không chỉ liên quan tới việc viết hay đọc code mà còn design, đánh giá và quản lý kĩ thuật.

Anh từng mắc phải sai lầm nào khi còn là TA và anh vượt qua nó như thế nào?

Một sai lầm mà anh và đa số TA đều mắc phải đó là muốn chứng tỏ mình là người thông minh. Nghĩa là cố gắng đoán yêu cầu của khách hàng và hài lòng khi mình đoán đúng.

Ví dụ lúc trước khách hàng không yêu cầu in dữ liệu ra máy in, chỉ có xuất dữ liệu ra các loại file khác nhau. Nhưng anh đoán là trong tương lai họ sẽ cần nên anh thiết kế phần interface cho các thiết bị in ấn. Và anh gây ấn tượng với khách hàng là team của anh đã đoán đúng yêu cầu của họ.

Sai lầm ở đây là nếu em đoán sai yêu cầu của khách hàng, tức là em đã làm dư và nó mất thời gian của chính team em.

Bài học anh rút ra là TA, developer, project manager phải làm vừa đủ trong phạm vi công việc. Một giải pháp tốt là một giải pháp mà mọi người có thể hiểu, đáp ứng yêu cầu về vận hành, sữa chữa đồng thời đủ uyển chuyển để có thể sửa đổi mà tốn ít thời gian và công sức nhất có thể.

Anh Hải (áo trắng đứng giữa) cùng đồng nghiệp

Anh có lời khuyên nào dành cho các developer trẻ muốn trở thành TA?

Anh có 4 lời khuyên.

1. Anh khuyên các bạn cố gắng nhận nhiều trách nhiệm hơn những gì mình đang làm và đừng quan tâm nhiều tới quyền lợi, vì suy cho cùng thì mình có điều kiện phát triển kĩ năng của mình, đó đã là lợi ích đầu tiên. Nếu em ở level junior thì hãy cố thử nhận task của level senior, rồi khi em làm senior developer thì em nhận trách nhiệm design architect của một component trong công việc của TA. Em nhận nhiều thử thách khó khăn thì kĩ năng của em sẽ tốt hơn + có nhiều cơ hội hơn.
2. Nếu em làm những project dễ hoặc làm những công việc dễ dàng thì em không thể trở thành developer có nhiều kinh nghiệm và phát triển lên để trở thành TA giải quyết được những project yêu cầu độ phức tạp kỹ thuật cao. Do đó em nên xin tham gia vào những project khó, yêu cầu kỹ thuật cao để rèn luyện kỹ năng.
3. Chọn công ty mà tại đó em có thể nhìn sản phẩm từ nhiều góc độ: UI/UX, front end, back end, development process… Em có thể tích lũy được phần lớn những kinh nghiệm này từ cả công ty Product và Outsourcing, nhưng công ty Product đặc biệt tốt hơn trong việc giúp em quan sát + hiểu toàn bộ development process.
4. Cập nhật thông tin công nghệ, kỹ thuật mới bằng cách đọc sách, xem blog và áp dụng vào công việc hàng ngày của mình. Có một số sách anh đã từng đọc và đánh giá nó như là bước khởi đầu cho việc học thiết kế phần mềm và viết code chất lượng cao. Các cuốn sách dưới đây có thể được áp dụng cho hầu hết mọi ngôn ngữ lập trình.
   • Design Patterns: Elements of Reusable Object-Oriented Software. Nhiều kinh nghiệm về object-oriented software của 4 designer hàng đầu được tập hợp tại đây với những giải pháp đơn giản, gọn gàng cho nhiều vấn đề design thông thường. Quyển này viết cách đây 20 năm, nhưng đến bây giờ đọc vẫn tốt vì kiến thức architect thường là giữ nguyên/thay đổi rất ít theo thời gian.
   • Patterns and Best Practices for Enterprise Integration. Quyển sách cung cấp 1 catalog gồm 65 patterns giá trị với các solution thực tế mô tả khả năng của messaging và giúp bạn thiết kế messaging solution hiệu quả cho doanh nghiệp của bạn.
   • Growing Object-Oriented Software, Guided by Tests. Qua nhiều ví dụ, bạn sẽ học được cách TDD hoạt động ở nhiều mức độ, sử dụng test để drive features, học về cấu trúc object-oriented của code, và cách sử dụng Mock Objects để miêu tả mối quan hệ giữa các đối tượng.
   • Agile Software Development, Principles, Patterns and practices: Quyển sách cơ bản và nâng cao về những nguyên tắc thiết kế phần mềm hướng đối tượng cần thiết cho software developer và architect. Tác giả diễn giải rất cụ thể các nguyên tắc lập trình hướng đối tượng với rất nhiều ví dụ. Kết hợp giữa quyển sách này và [1] Design Patterns: Elements of Reusable Object Oriented Software là bước đầu giúp em học cách thiết kế những phần mềm lớn.

Ngoài ra, anh cũng khuyên các bạn nên tìm hiểu các nguồn thông tin này hàng ngày:

1. InfoQ
2. DZone
3. Object Mentor
4. Martin Flower

Bạn có gặp phải khó khăn nào trong sự nghiệp TA của mình? Hay bạn là developer đang muốn trở thành TA? Hãy chia sẻ cùng ITviec tại phần bình luận cuối bài!

Xem thêm việc làm Technical Architect tại ITviec.