我曾写过很多文章，试图通过 “架构演化”、“面试”、“开会”及“职业发展”等维度来进行解答，但知识和认知都比较有限，输出的内容总显得有些片面。上个月，朋友推荐了一本书，整个阅读经历让我对「架构师」有了新的认识。
有一次，笔者以架构师的角色参与某个软件产品的开发，产品经过一年多的发展，已经发布了2.0版本，并在一些企业用户中成功实施。项目后期，由于产品整体架构设计比较合理，各个功能模块的扩展性良好，架构师基本没有什么事情可做，加上一些其他因素，笔者打算辞职。
但是当跟项目组成员宣布辞职的时候，大家很吃惊，纷纷表示挽留“你怎么可以走呢，你走了，我们怎么办呢？” 我说“其实你们已经不需要我了，2.0版本新的功能架构都是你们自己设计的，最近两个月技术讨论会上，我甚至都不发言了，你们不是做的一样很好？” 但还是有人很失望地说 “你在，我们就有了主心骨，你不说话就是表示赞成我们的设计，我们才敢这样搞，你走了，我们怎么办呢？” 架构师是软件开发组织中一个比较特殊的角色，除了架构设计，软件开发等技术类工作，通常还需要承担一些管理职能：规划产品路线、估算人力资源和时间资源、安排人员职责分工，确定计划里程碑点、指导工程师工作、过程风险评估与控制等。 这些管理事务需要对产品技术架构、功能模块划分、技术风险都熟悉的架构师参与或直接负责。 在软件开发过程中，架构师除了实现技术架构，完成产品技术实现外，还需要和项目组内外各种角色沟通协调，可以说架构师相当多的时间用在和人打交道上。处理好人的关系对架构和项目的成功至关重要。架构师作为项目组最资深的专业技术人员，是项目组开发测试工程师的前辈。从架构师的身上，工程师可以看到自己的未来，因此架构师在做人做事方面需要严格要求自己，做好表率。
1、关注人而不是产品
一定要坚信： 一群优秀的人做一件他们热爱的事，一定能取得成功。不管过程多么曲折，不管外人看来多么不可思议不靠谱。
所以最好的软件项目管理不是制订计划，组织资源，跟踪修正项目进展，对成员进行激励和惩罚，而是发掘项目组每个成员的优秀潜能，让大家理解并热爱软件产品最终的蓝图和愿景。每个人都是为实现自我价值而努力，不是为了领工资而工作。
一旦做到这一点，项目组每个成员都会自我驱动，自觉合作，寻找达成目标的最优路径并坚韧不拔地持续前进。整个过程中，不需要拙劣的胡萝卜和大棒，最好的奖励就是最终要达成的目标本身，最大的惩罚就是这个美好的目标没有实现。
这也是领导的真谛：寻找一个值得共同奋斗的目标，营造一个让大家都能最大限度发挥自我价值的工作氛围。
没有懒惰的员工，只有没被激发出来的激情。所有强迫员工加班的管理者都应该为自己的无能而羞愧。2、发掘人的优秀
有些企业喜欢挖优秀的人，而不是去把自己打造成一个培养优秀人才的地方。殊不知：是事情成就了人，而不是人成就了事。 指望优秀的人来帮自己成事，不如做成一件事让自己和参与的人都变得优秀。
在前面提到的那个项目中，有一位刚毕业不久的同学，分配给他的任务是调查某个技术功能的实现。 事实上这个功能已经有开源的代码实现，只需要将这些代码加入到项目中直接调用就可以了，但是为了让他有较多的时间熟悉项目和背景技术，我没有跟他说你去使用某个开源项目实现这个功能，而是说你调查下这个功能如何实现。 后来，这个同学不但找到了这个功能的开源实现，阅读了文档和代码，还针对我们项目的需求场景对代码做了优化，然后又将这些优化的代码提交给开源项目的作者，最后被合并到开源项目中。 可以说，他的工作不只是超出了我的期望，简直就是让我吃惊，这种吃惊在我的职业生涯中曾多次出现，很多人在工作中做出的卓越成果以及表现出来的优秀让我自愧不如。 大多数人，包括我们自己，都比自己以为的更优秀，有些优秀需要在合适的环境中才会被激发出来，比如做一些有挑战的事，和更优秀的人合作，抑或拥有了超越自我的勇气。发掘人的优秀远比发掘优秀的人更有意义。
3、共享美好蓝图
架构师要和项目组全体成员共同描绘一个蓝图，这个蓝图是整个团队能够认同的，是团队共同奋斗的目标。
蓝图应该是表述 清楚的：产品要做什么、不 做什么、要达到什么业务目标，都需要描述清楚。蓝图应该是形象的：产品能为用户创造什么价值、能实现什么样的市场目标、产品最终会长什么样，都需要形象地想象出来。
蓝图应该是简单的：不管内部还是外部沟通，都能一句话说明白：我们在做什么。
蓝图应该写在软件架构设计文档的扉页、写在邮件的签名档、写在内部即时通信群的公告上。
在项目过程中，架构师要保持对目标蓝图的关注，对任何偏离蓝图的设计和决定保持警惕，错误的偏离要及时修正，必要的变更要经过大家讨论，并且需要重新获得大家的认同。
在电影《十月围城》中，一个年轻的革命党人说“我一闭上眼睛，就看到中国的明天”。这个明天就是辛亥革命的蓝图，为了这个美好的明天他愿意抛头颅、洒热血，死而无憾。创业者闭上眼睛就能看到企业的明天；软件产品的开发者闭上眼睛就能看到软件实现价值的那一刻。这就是蓝图的力量。
也许有人会说“你是在忽悠我吧，只是想让我努力工作而已”。青春总会逝去，人总是会死的，当有一天你白发苍苍回首往事，你会为无所事事而遗憾，但不会为被人忽悠而羞愧。批评马云忽悠的人，一定为马云在创建阿里巴巴的时候没有忽悠他成为创始人而遗憾。4、共同参与架构
架构师需要对系统架构负责，但并不是说一定要架构师自己完成架构设计，并要项目团队严格遵守架构决策。
把架构和架构师凌驾于项目和项目组之上，只会让架构师变成孤家寡人，让架构曲高和寡。 1、不要只有架构师一个人拥有架构架构师不要把架构当做自己的私有财产，为了维护架构的纯洁和架构师的威信而不让他人染指架构。让项目参与者对架构充分争论，大家越是觉得自己是项目架构的重要贡献者，就越是愿意对开发过程承担责任，越是愿意共同维护架构和改善软件。
2、让其他人维护框架与架构文档 框架是架构的重要组成部分，许多重要的架构设计通过框架实现来体现。但是在软件开发过程中，架构也需要根据需求不断发展演化，框架和架构文档也会随之调整。除非是重大的重构，否则架构师应该让项目组成员维护框架和架构文档，给项目组成员成长的机会也让自己有更多的时间去寻找更大的挑战。5、学会妥协
不要企图在项目中证明自己是正确的，一定要记住，你是来做软件的，不是来当老大的。所以不要企图去证明自己了不起，永远也别干这种浪费时间、伤害感情的事。
有个小故事：猎人进山里打猎，反而被一头黑熊抓住了，黑熊说“如果你给我XX我就放你走”，猎人无奈只好给黑熊XX。回去后苦练打猎本领，再次进山，结果又被黑熊抓住，再次要求给了XX。第三次他又来了，黑熊看到他就乐了“你是来打猎的还是来给我XX的？”。
每次我在做项目迷失方向，五迷三道的时候，就会想起这个故事，提醒自己是来做软件的，来实现客户价值的，不是来证明谁对谁错的，不是来给黑熊XX的。
很多时候，对架构和技术方案的反对意见，其实意味着架构和技术方案被关注、被试图理解和接受。架构师不应该对意见过于敏感，这时架构师应该做的是坦率地分享自己的设计思路，让别人理解自己的想法并努力理解别人的想法，求同存异。
对于技术细节的争论应该立即验证而不是继续讨论，当讨论深入到技术细节的时候也意味着问题已经收敛，对于整体架构设计，各方意见正趋于一致。
而当大家不再讨论架构的时候，表明架构已经融入到项目、系统和开发者中了，架构师越早被项目组遗忘，越表示架构非常成功；项目组越离不开架构师，越表示架构还有很多缺陷。6、成就他人
我们活着不是为了工作，不是为了做设计、写程序，这些不是我们生活的目的。我们活着是为了成就我们自己，而要想成就自己，就必须首先成就他人。
每个人都有自己成就的目标，而工作是达成自我成就的一种手段：通过工作的挑战，发掘自我的潜能，重新认知自我和世界。
软件开发过程是人的智力活动过程，软件开发不仅是制造软件的过程，也是开发人员完善自我、超越自我的过程。所以我们工作不只是生产产品，还要成就人，并最终成就我们自己。
做成一个项目不但要给客户创造价值，为公司盈利，还要让项目成员获得成长。要让他们觉得通过这个项目，自己的知识技能和业务水平都得到了提高。项目结束时，大家会觉得不可思议：“如此完美的产品，如此有挑战的开发居然都是我们完成的”。而且每个人都觉得自己在项目中至关重要不可或缺。
架构师作为团队的技术领导者，在项目过程中不要去试图控制什么，带着一个弹性的计划和蓝图推进，团队会管好他们自己。你越是强加禁令，队伍就越是没有纪律；你越是强制，团队就越是不能独立自主；你越是从外面寻找帮助，大家就越是没有信心。
而一旦打造出一个优秀的团队，在以后的合作中，面临更大的挑战时，架构师就可以从容应对，因为你不是一个人在战斗。同时一个优秀的团队内部也会发生化学反应，创造出超出工作本身的机会，开启更美好的明天。来源：以上内容均来自于《大型网站技术架构》第4篇
