Technical Architect là gì? Technical Architect là người chịu trách nhiệm tổng thể toàn bộ những hoạt động sinh hoạt kỹ thuật liên quan đến project 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 project, nhưng vẫn cần kỹ năng quản lý khi đối chiếu với development team khi phải cân bằng các yếu tố về ngân sách, thời kì.
Đọ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 san sẻ về trách nhiệm của một Technical Architect là gì và những kỹ năng cấp 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ộ những hoạt động sinh hoạt kỹ thuật liên quan đến project. Ví dụ như:
- Chọn lựa dụ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 quan hệ giữa component trong system và trách nhiệm của từng component để thiết kế khối 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 như đúng yêu cầu về tính chất năng, tốc độ và bảo mật thông tin.
- Quản lý những hoạt động sinh hoạt liên quan đến kĩ thuật như training, review, monitoring… để đảm bảo development team viết code, document theo như đúng yêu cầu khối hệ thống xác định.
- Thao tác với khách hàng định kì để đảm bảo architect đáp ứng đủ yêu cầu của khối hệ thống, update design cho những yêu cầu mới.
- Ứng dụng những best practices để cải tiến qui trình, chất lượng sản phẩm của phần mềm ở tất cả những khâu như development, testing, deployment, transition.
Technical Architect khác Developer 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 to thêm, 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 cả design, testing, quản trị phần mềm…
Anh Thành Phan, Head of Rvàamp;D Atlassian Việt Nam: Sự Khác Nhau Giữa Coding và Managing
Anh nghĩ một TA thông 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ý khi đối chiếu 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ề ngân sách, thời kì mà development team có thể hoàn thành.
Kỹ năng của Technical Architect là gì?
Mảng software có nhiều platform, language, operate system khác nhau. TA kiên cố 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à xét tuyển cần để TA có thể tự mình nhìn nhận và đánh giá và quản lý chất lượng sản phẩm code, document của sản phẩm, những vấn đề khác liên quan đến performance/security của khối hệ thống.
- Có tri thức về thiết kế khối hệ thống phần mềm theo phía đối tượng người sử dụng cho những dự án vừa và lớn. Update tri thức mới về công nghệ như cloud computing, mobile, NoSQL.
- 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.
- Có tri thức về business domain mà dự án của mình đang làm. Ví dụ tổ chức em đang làm một sản phẩm về banking/finance, em phải có tri thức về những nghành nghề dịch vụ đó.
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 quyết định hành động 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 hiện.
Ví dụ tổ chức anh có những loại project nào thì anh làm như vậy. Anh không được thực hiện tất cả những kỹ năng, tri thức cấp thiết cho một người TA đúng nghĩa.
Phần lớn project của nhiều tổ chức không đủ độ phức tạp để mọi người dân 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ìn nhận và đánh giá các dụng cụ và giải pháp, qui trình phần mềm…
Nhiều tổ chức 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ự kỹ năng tay nghề hóa cao nhưng cũng song song tạo ra những người dân thợ chuyên về một nghành nghề dịch vụ nào đó.
Anh chỉ biết được công việc trong một quy trình tiế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à trái lại.
Chỉ làm một loại công việc trong thời kì dài hạn chế khả năng developer muốn phát triển sự nghiệp thành TA.
Phương pháp tuyển dụng của nhiều tổ chức là tìm ứng viên đáp ứng đúng yêu cầu về kĩ thuật ngày nay mà chưa quan tâm nhiều đến khả năng phát triển của viên chức trong tương lai.
Ví dụ tổ chức 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 tổ chức 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ìn nhận và đánh giá và quản lý kĩ thuật.
Anh Trần Vũ Tất Bình – 1 trong những Android developer trước hết ở Việt Nam: số lượng software architect ở Việt Nam còn ít.
Sai trái thường thấy của Technical Architect là gì?
Một sai trái mà anh và phần lớn TA đều phạm phải đó là muốn chứng tỏ mình là người thông minh. Tức thị nỗ lực 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 tài liệu ra máy in, chỉ có xuất tài 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 những thiết bị in ấn.
Và anh gây tuyệt vời với khách hàng là team của anh đã đoán đúng yêu cầu của họ.
Sai trái ở đâ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 kì của chính team em.
Bài học kinh nghiệm 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 dân có thể hiểu, đáp ứng yêu cầu về vận hành, sữa chữa song song đủ uyển chuyển để sở hữu thể sửa đổi mà tốn ít thời kì và sức lực nhất có thể.
Làm thế nào để 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 process và update công nghệ mới thường xuyên như 4 lời khuyên về sau:
Một là: anh khuyên các bạn nỗ lực 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ó xét tuyển phát triển kĩ năng của mình, này đã là lợi ích trước hết.
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 thời cơ hơn.
Hai là: 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 xử lý đượ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.
Ba là: chọn tổ chức 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ả tổ chức Product và Outsourcing, nhưng tổ chức Product đặc biệt quan trọng tốt hơn trong việc giúp em quan sát + hiểu toàn bộ development process.
Tham khảo: 3 điểm khác biệt giữa tổ chức product và tổ chức outsourcing
Bốn là: update thông tin công nghệ, kỹ thuật mới bằng phương pháp đọc sách, xem blog và ứng 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ìn nhận và đánh giá nó như thể 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 sản phẩm cao.
Các cuốn sách về sau có thể được ứng dụng cho hồ hết mọi tiếng nói 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 ghẽ cho nhiều vấn đề design thông thường. Quyển này viết từ thời điểm cách đó 20 năm, nhưng đến hiện tại đọc vẫn tốt vì tri thức architect thường là giữ nguyên/thay đổi rất ít theo thời kì.
- Patterns and Best Practices for Enterprise Integration. Quyển sách cung cấp 1 catalog gồm 65 patterns giá trị với những solution thực tế mô tả khả năng của messaging và giúp cho 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ụ, các 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ả quan hệ giữa các đối tượng người sử dụ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 người sử dụng cấp 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 người sử dụng với rất nhiều ví dụ. Phối 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:
- InfoQ
- DZone
- Martin Flower
Tiểu truyện:
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 tổ chức riêng là eSoftHead và một tổ chức 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 sử dụng làm mã nguồn mở và có nhiều tổ chức sử dụng.
Nếu như khách hàng nghĩ những san sẻ này còn có thể giúp ích cho bè cánh hoặc đồng nghiệp thì đừng ngại nhấn nút Share phía bên dưới nhé!
Xem thêm việc làm Technical Architect tại ITviec.
