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

Technical Architect là gì? Technical Architect là người chịu trách nhiệm tổng thể toàn bộ các hoạt động kỹ thuật liên quan đến venture như code, design, testing v.v

Technical Architect còn được gọi là TA, là người tập trung mảng kỹ thuật của venture, nhưng vẫn cần kỹ năng quản lý đối với growth crew khi phải cân bằng các yếu tố về chi phí, thời gian.

Đọc bài phỏng vấn của ITviec với anh Hải Nguyễn – Chief Technical Architect của eSoftHead, để nghe anh chia sẻ về trách nhiệm của một Technical Architect là gì và những kỹ năng cần thiết để trở thành Technical Architect.

Xem thêm việc làm Technical Architect trên ITviec

Technical Architect là gì?

Technical Architect là người chịu trách nhiệm tổng thể toàn bộ các hoạt động kỹ thuật liên quan đến venture. 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 part trong system và trách nhiệm của từng part để 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ư coaching, overview, monitoring… để đảm bảo growth crew viết code, doc 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 finest 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ư growth, testing, deployment, transition.

Technical Architect khác Developer thế nào?

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

Scope of labor 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 Thành Phan, Head of R&D Atlassian Việt Nam: Sự Khác Nhau Giữa Coding và Managing

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 venture, schedule, tất cả venture actions để đảm bảo supply tốt. Còn TA thì tập trung mảng kỹ thuật nhiều hơn, cụ thể là technical actions.

Nhưng TA vẫn cần kỹ năng quản lý đối với growth crew. Hai vấn đề quan trọng của venture là value và schedule.

Kỹ năng của Technical Architect là gì?

Mảng software program có nhiều platform, language, function 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à:

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, doc của sản phẩm, những vấn đề khác liên quan đến efficiency/safety của hệ thống.
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, cell, NoSQL.
Có kinh nghiệm về các finest practices của hoạt động phát triển phần mềm như steady integration construct, unit take a look at, TDD.
Có kiến thức về enterprise area 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 Nguyễn Xuân Huy – Tech Architect của Cybozu Vietnam: 1 thử thách mà mọi Tech Architect đều phải trải qua là việc đưa ra quyết định chọn giải pháp phù hợp.

Tuyển dụng Technical Architect tại Việt Nam

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.

Developer thiếu thực hành.

Ví dụ công ty anh có những loại venture nào thì 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ố venture 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 doc, đánh giá các công cụ và giải pháp, qui trình phần mềm…

Nhiều công ty chia nhiệm vụ của developer theo chức năng.

Chẳng hạn: 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 facet 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.

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 Trần Vũ Tất Bình – 1 trong những Android developer đầu tiên ở Việt Nam: số lượng software program architect ở Việt Nam còn ít.

Sai lầm thường thấy của Technical Architect là gì?

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à crew 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 crew em.

Có Thể Bạn Quan Tâm : Off Beat Là Gì – Thuật Ngữ Trong Rap

Bài học anh rút ra là TA, developer, venture supervisor 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ể.

Làm sao để trở thành Technical Architech?

Để trở thành Technical Architect, các Developer cần rèn chắc kĩ năng phát triển phần mềm, hiểu course of và cập nhật công nghệ mới thường xuyên như 4 lời khuyên dưới đây:

Một là: 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. Đừ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 ở stage junior thì hãy cố thử nhận activity của stage senior. Rồi khi em làm senior developer thì em nhận trách nhiệm design architect của một part 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. Hai là: nếu em làm những venture 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 venture yêu cầu độ phức tạp kỹ thuật cao. Do đó em nên xin tham gia vào những venture khó, yêu cầu kỹ thuật cao để rèn luyện kỹ năng. Ba là: chọn công ty mà tại đó em có thể nhìn sản phẩm từ nhiều góc độ: UI/UX, entrance finish, again finish, growth course of… 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ộ growth course of.

Tham khảo: 3 điểm khác biệt giữa công ty product và công ty outsourcing

Bốn là: cập nhật thông tin công nghệ, kỹ thuật mới bằng cách đọc sách, xem weblog và áp dụng vào công việc hàng ngày. 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.

- Patterns and Greatest Practices for Enterprise Integration. Quyển sách cung cấp 1 catalog gồm 65 patterns giá trị với các resolution thực tế mô tả khả năng của messaging và giúp bạn thiết kế messaging resolution hiệu quả cho doanh nghiệp của bạn.
- Rising Object-Oriented Software program, Guided by Checks. Qua nhiều ví dụ, bạn sẽ học được cách TDD hoạt động ở nhiều mức độ, sử dụng take a look at để drive options, 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 program Improvement, Ideas, 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 program 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: Parts of Reusable Object Oriented Software program là bước đầu giúp em học cách thiết kế những phần mềm lớn.

Tham khảo: Nguyên tắc SOLID trong lập trình hướng đối tượng

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:

InfoQ
DZone
Martin Flower

Có Thể Bạn Quan Tâm : Ngôi nhà của những Biên dịch viên tự do

Tiểu sử:

Anh Hải đi từ Software program Developer → Technical Lead → Mission Supervisor → Senior Mission Supervisor → 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.

ITviec Robby

Nếu bạn nghĩ những chia sẻ này có thể giúp ích cho bạn bè hoặc đồng nghiệp thì đừng ngại nhấn nút Share bên dưới nhé!

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