ARCHITECT LÀ GÌ

  -  

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

Technical Architect còn được gọi là TA, là người triệu tập mảng nghệ thuật của project, nhưng mà vẫn bắt buộc kỹ năng thống trị đối cùng với development team khi đề xuất cân bằng các yếu tố về bỏ ra phí, thời gian.

Bạn đang xem: Architect là gì

Đọc bài phỏng vấn của chamichi.com.vn cùng với anh Hải Nguyễn, Chief Technical Architect của eSoftHead để nghe anh share về trọng trách của một Technical Architect là gì và hầu như kỹ năng quan trọng để phát triển thành Technical Architect.

Technical Architect là gì?

Technical Architect là người phụ trách tổng thể toàn bộ các vận động kỹ thuật liên quan đến project. Lấy ví dụ như như:

Chọn lựa công cụ, tìm giải pháp trước cùng trong vượt trình cách tân và phát triển phần mềm.Xác định quan hệ giữa component trong system và trọng trách của từng component nhằm thiết kế khối hệ thống tối ưu cho việc vận hành, bảo trì và chuyển nhượng bàn giao cho người tiêu dùng theo đúng yêu thương cầu về tính chất năng, tốc độ và bảo mật.Quản lý các chuyển động liên quan đến kĩ thuật như training, review, monitoring… để bảo đảm an toàn development team viết code, document theo đúng yêu cầu hệ thống xác định.Làm việc với người sử dụng định kì để đảm bảo an toàn architect đáp ứng một cách đầy đủ yêu cầu của hệ thống, cập nhật design cho những yêu ước mới.Áp dụng hầu như best practices để cách tâ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.

Technical Architect khác Developer cầm nào?

Scope of work. Developer tập trung làm một quá trình được giao. Ví dụ như cải cách và phát triển một component trong project và cần tuân theo phần nhiều quy tắc architect qui định.

Scope of work của TA to hơn, họ chịu đựng trách nhiệm quản lý kỹ thuật của toàn bộ dự án. Hoạt động vui chơi của TA không chỉ có liên quan cho code, mà cả design, testing, cai 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 Hải mặc sơ-mi white ngồi giữa


Anh nghĩ về một TA thông thường có bắt buộc kỹ năng thống trị không?

Bản thân TA không đề xuất kỹ năng làm chủ như PM. Lấy một ví dụ PM phải cai quản về nhỏ người, scope project, schedule, toàn bộ project activities để bảo đảm an toàn delivery tốt. Còn TA thì tập trung mảng kỹ thuật nhiều hơn, rõ ràng là technical activities.

Nhưng TA vẫn bắt buộc kỹ năng cai quản đối cùng với development team. Nhị vấn đề đặc biệt của project là cost với schedule.

TA khi chỉ dẫn một phương án thì không chỉ quan trọng tâm việc giải pháp tốt về mặt kĩ thuật nhưng còn đề xuất cân bằng các yếu tố về chi phí, thời gian mà development team hoàn toàn có thể hoàn thành.

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

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

Từng là developer tốt. Đây là đk cần để TA hoàn toàn có thể tự mình reviews và làm chủ chất lượng code, document của sản phẩm, những sự việc khác tương quan đến performance/security của hệ thống.Có kỹ năng về thiết kế khối hệ thống phần mượt theo hướng đối tượng người sử dụng cho những dự án vừa và lớn. Cập nhật kiến thức bắt đầu về công nghệ như cloud computing, mobile, NoSQL.Có tay nghề 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ó kiến thức về business domain cơ mà dự án của mình đang làm. Ví dụ công ty em đang làm cho một sản phẩm về banking/finance, em buộc phải có kiến thức và kỹ năng 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à đông đảo Tech Architect đều đề xuất trải qua là việc đưa ra ra quyết định chọn chiến thuật phù hợp.

Tuyển dụng Technical Architect trên Việt Nam

Nhu ước tuyển dụng TA tương đối nhiều nhưng khó tìm được ứng viên phù hợp. Tại sao của sự việc này khởi đầu từ hai phía: ứng viên và nhà tuyển chọn dụng.

Developer thiếu thốn thực hành.

Ví dụ doanh nghiệp anh bao gồm loại project nào thì anh làm cho như thế. Anh ko được thực hành tất cả những kỹ năng, loài 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 được độ phức hợp để phần nhiều người có thể rèn luyện. Một TA đề xuất rất nhiều khả năng khác nhau: code, kiến thiết architect, viết document, review các luật và giải pháp, qui trình phần mềm…

Nhiều doanh nghiệp chia trách nhiệm 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 chế tạo ra sự trình độ hóa cao tuy nhiên cũng đồng thời tạo nên những fan thợ siêng về một nghành nào đó.

Anh chỉ biết được các bước trong một quy trình phát triển phần mềm. Giả dụ anh là UI/UX developer, anh chỉ biết về UI/UX, anh chần chừ nhiều về các technology bên vps side cùng ngược lại.

Chỉ có tác dụng một loại quá trình trong thời hạn dài hạn chế kĩ năng developer muốn trở nên tân tiến sự nghiệp thành TA.

Cách thức tuyển dụng của đa số công ty là search ứng viên đáp ứng đúng yêu mong về kĩ thuật lúc này mà chưa thân mật nhiều đến khả năng phát triển của nhân viên cấp dưới 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 xuyên tuyển TA đúng với năng lực đó. Phương pháp tuyển này gây tinh giảm cho doanh nghiệp tuyển dụng.

Xem thêm: Online Là Gì ? Định Nghĩa Và Giải Thích Ý Nghĩa Học Trực Tuyến (Online) Là Gì

Vì như anh nhắc đến ở trên thì TA không những liên quan tới việc viết hay đọc code mà còn design, đánh giá và làm chủ kĩ thuật.

Anh trằn Vũ tất Bình – 1 trong những game android developer thứ nhất ở Việt Nam: số lượng software architect ở vn còn ít.

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

Một sai lầm mà anh và phần lớn TA đều phạm phải đó là muốn chứng minh mình là tín đồ thông minh. Nghĩa là cố gắng đoán yêu thương cầu của người tiêu dùng và ăn nhập khi bản thân đoán đúng.

Ví dụ dịp trước người tiêu dùng không yêu cầu in tài liệu ra đồ vật in, chỉ bao gồm xuất dữ liệu ra các loại file khác nhau. Cơ mà anh đoán là sau này họ sẽ bắt buộc nên anh xây dựng phần interface cho các thiết bị in ấn.

Và anh gây tuyệt hảo với khách hàng là team của anh đã đoán đúng yêu mong của họ.

Sai lầm ở đó là nếu em đoán không đúng yêu ước của khách hàng hàng, có nghĩa là em đã có tác dụng dư với nó mất thời gian của thiết yếu team em.

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


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


Làm sao để trở nên Technical Architech?

Để phát triển thành Technical Architect, những Developer nên rèn chắc khả năng phát triển phần mềm, gọi process và cập nhật công nghệ mới thường xuyên như 4 lời khuyên bên dưới đây:

Một là: anh khuyên chúng ta cố nuốm nhận nhiều trọng trách hơn những gì mình đã làm. Đừng ân cần nhiều cho tới quyền lợi. Vì suy cho cùng thì bản thân 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ử thừa nhận task của level senior. Rồi lúc em làm senior developer thì em nhận nhiệm vụ design architect của một component trong công việc của TA. Em thừa nhận nhiều thử thách khó khăn thì tài năng của em sẽ xuất sắc hơn + bao gồm nhiều thời cơ hơn.

Hai là: nếu em làm đầy đủ project dễ hoặc có tác dụng những các bước dễ dàng thì em không thể biến chuyển developer có khá nhiều kinh nghiệm và trở nên tân tiến lên để phát triển thành TA giải quyết và xử lý được đầy đủ project yêu cầu độ tinh vi kỹ thuật cao. Cho nên vì vậy em yêu cầu xin tham gia vào đầy đủ project khó, yêu cầu kỹ thuật cao nhằm rèn luyện kỹ năng.

Ba là: chọn công ty mà tại kia em rất có thể nhìn sản phẩm từ những góc độ: UI/UX, front end, back end, development process… Em có thể tích lũy được phần nhiều những kinh nghiệm này từ bỏ cả doanh nghiệp Product cùng Outsourcing, nhưng lại công ty Product quan trọng tốt rộng trong việc giúp em quan gần kề + hiểu toàn thể development process.

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

Bốn là: update thông tin công nghệ, chuyên môn mới bằng cách đọc sách, xem blog và áp dụng vào các bước hàng ngày của mình.

Có một vài sách anh đã có lần đọc và review nó như là bước bắt đầu cho việc học xây dựng phần mềm với viết code unique cao.

Các cuốn sách dưới đây có thể được vận dụng cho phần lớn mọi ngữ điệu lập trình.

Ngoài ra, anh cũng khuyên những bạn nên mày mò các nguồn tin tức này mặt hàng ngày:

Tiểu sử anh Hải Nguyễ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 tay nghề về phát triển phần mềm, anh cai quản kĩ thuật cho công ty riêng là eSoftHead và một công ty outsourcing gồm trụ sở mặt Úc.

Xem thêm: Nhổ Răng Sữa Cho Bé Ở Đâu? Top 10 Địa Chỉ Uy Tín Nhất Game Bác Sĩ Khám Răng

Ngoài ra, anh còn cách tân và phát triển một dịch vụ thương mại đám mây về làm chủ khách sản phẩm và cai quản dự án là MyCollab, 1 phần sản phẩm này được sử dụng làm mã nguồn mở và có nhiều công ty sử dụng.

*

Nếu chúng ta nghĩ những share này có thể giúp ích cho bằng hữu hoặc đồng nghiệp thì đừng ngại thừa nhận nút Share bên dưới nhé!