Chinaunix首页 | 论坛 | 博客
  • 博客访问: 7096496
  • 博文数量: 703
  • 博客积分: 10821
  • 博客等级: 上将
  • 技术积分: 12042
  • 用 户 组: 普通用户
  • 注册时间: 2005-12-02 10:41
个人简介

中科院云平台架构师,专注于数字化、智能化,技术方向:云、Linux内核、AI、MES/ERP/CRM/OA、物联网、传感器、大数据、ML、微服务。

文章分类

全部博文(703)

分类:

2012-11-14 09:47:38

  1. 原创作品,允许转载,转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明,否则将追究法律责任。
  2. http://blog.chinaunix.net/space.php?uid=26470037&do=blog&id=3039134

几个月前,公司因为战略调整,将位于美国的系统工程(system engineering)部门的工作转到了国内。也因为这次调整,我有幸以系统架构师(system architect)的身份主导产品一新功能(feature)的开发。在此我分享自己的一些体会。
 
从开发架构师变成系统架构师所面临的第一个挑战,是所面临的技术范畴和问题复杂度变广和变大了很多。做开发架构师(development architect)时,只要关心整个系统一个子产品的内容,而系统架构师却得关心多个产品的内容。做开发架构师时,由于系统架构师已将问题进行了分解,因此所看到的复杂度也只是整个解决方案的一部分。做开发架构师时,对于不明白的问题,我们可以想当然地向系统架构师咨询,而做系统架构师时,不少情形下就要自己通过查阅规范去寻求问题的答案,并在必要时指导开发架构师的工作。
 
系统架构师引导产品开发工作的方式是提供系统架构文档(system architecture document,其中以用例描述为主),要写好这一文档也是不小的挑战。一个组织得再好的文档,新手要在2300多页的文档中找准开发新功能所需修改的各个点并不容易。找修改点的过程需要通过阅读去把握文档的编写脉络,修改点找到后又需要模仿前人的语气、角度和风格进行编写,否则写出来的内容会让人觉得突兀。在系统架构文档中描述用例时,对于假设(assumption)、前置条件(pre-condition)和后置条件(post-condition)的把握有时是个难点,这需要自己有很清晰的思路和做深入的思考。
 
做系统架构师需要与更多的人进行交互,这又会让人面临新的挑战。比如,系统架构师需要了解各运营商的网络部署情况以寻求兼容性解决方案,这就需要与客户团队(account team)进行交互;要了解第三方的产品特性就得与卖方管理者(vendor manager)进行交互;等等。为此,系统架构师需要对产品线的相关组织架构相当了解,并对各种角色(包括项目经理、产品经理、客户团队等)的职责有清晰的认识,否则会出现有问题不知向哪寻求帮助,或者做那些不在职责之内的事等问题。
 
除了以上提到的对于架构师的挑战外,一个成熟、稳定的产品研发管理团队对新系统架构师上手工作很有帮助。它有助于系统架构师快速地明确自己的工作职责和帮助建立起所需的人际关系。反之,如果没有这样一个团队,由于系统架构师的经验不足而容易出现一些扯皮现象而影响工作的开展。
 
系统架构师新手一定不能忽视团队的作用,以及在合适的时机向上司或其它富有经验的管理者寻求帮助,这是我最大的一个体会。团队的作用在于能帮助分担工作,并为技术方案的定型出谋画策。系统架构师新手由于一直身处技术领域,所以与富有经验的管理者相比,他们的技术大多不是瓶颈,但在管理方面就很有可能不如他们。他们由于阅历丰富而能很快地帮助找到管理问题的根结点,帮助我们从困境中走出。注意,系统架构师所需的不只是技术能力,更有管理能力。
 
总而言之,做系统架构师的确是很大的一个挑战。但无论如何,直面挑战是我们最好的选择!没有痛苦就没有成长!

本文出自 “李云” 博客,请务必保留此出处 http://blog.chinaunix.net/space.php?uid=26470037&do=blog&id=3039134
阅读(2330) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~