《架构师二.docxVIP

开篇之前我想先说说当年开发的那点事儿：大约10年前吧，我还是一个程序员的时候经常都是遇到这样的项目开发流程：?解决方案：满足客户目的和投标用的一堆文档（不少还是互联网上抄的），是以Word为主的纯文字。投标完成和客户付订金后项目组成立，通常为（0至1）个项目经理或者叫项目负责人+（1至N）个程序员的项目组模式设计：由项目的头或者经验最足的成员参与编写设计。倒霉的时候我们会得到一份按照软件工程学的纯中文形式的设计想法(抱歉我只能这样来形容)，而更糟的情况是得到一份完全看不懂的Rose文档（那个年代可是UML大放异彩的时代，而当时我对UML完全就是个瞎子）开发：到这里才有我参与的份，前面的内容通常作为项目组中低层的人员是不透明的。得到“设计”后，我们只能靠自己的“猜想”来实现，最后拿着界面给经理看是否符合他的“设计要求”。?测试？这项目是没有的，只要程序能跑通直接就交付了。?项目的结果不言而喻，最多的沟通就是吵架与被训斥还有就是被客户抱怨。在这种例子很可笑，但更可笑的是至今我还听到不少的朋友跟我说起这种类似的苦B经历。他们不是没有设计，不是没有沟通也不是没有管理，只是每个人都在用自己方式在表达，没有共同的语言和沟通方式。那么换个沟通能力很强大的项目经理会改变这种境况吗？可能可以，但遇到最多的只能是改善，只是苦B这个角色换成项目经理而已，因为本质上没有多大的变化。?我很感恩能有这么让人难受的开发经历，因为太难过了所以才促成当时的我去想办法，去学习最后努力去改变。接下来的部分会是我将这10多年来的经历进行的一些总结，因为我学的东东很杂当时在大学里根本没有这些知识只能靠在项目实践中摸索前行，我受MSF与敏捷开发的影响很大，并且我是一个反UML人士，但我并没有完全去采用某一种标准化的开发方法与开发流程，长年来只是以我对这些方法论的理解应用到我的项目里，而在这里我不想过多地讨论关于开发方法论与项目管理的内容，而只是将其中与架构和设计相关的内容抽取出来论述。表达思维架构师的职责世界上最难的两件事是：将别人口袋的钱放到自己的口袋里面；将自己脑子的想法完整放到别人的脑子里面。在大家的印象中，项目经理是项目中沟通得最多的角色，其实架构师的沟通量也不逊于项目经理。在国内更多的情况是架构师与项目经理就是同一个人。作为系统/项目的总设计师，并不是单纯只为客户想出技术解决方案然后做出一份设计扔给项目组就完事了，而需要向每个位参与项目的成员或角色从不同的层面介绍或解释设计原意与理念。?有效沟通本文的主要内容说得简单一点就是架构师销售自己的设计的一些方式与方法。除了开发能力与设计能力以外“有效沟通”也是架构师的很重要一项技能。架构师与项目经理不同主要工作时间与精力不是全放在沟通上，但如果沟通不当就会出现因为反复沟通而大量消耗架构师的设计时间，甚至设计出让人难以理解的架构，就算设计本身的含金量再高，在没有找到伯乐之前也只能处于“曲高和寡”的尴尬局面。我之所以将沟通看作一项修炼的另一个原因是这些内容都是从书看不到的，只能从实战中摸趴滚打慢慢积累而成，不同的经历可能也会有不一样的看法与心得，而接下来就是我积累多年的一点经验的总结：如果说开发流程是大的迭代那么设计就是经历一次次的小迭代以至于完善，项目的每个参与者的想法与建议都是架构师修正设计，积累迭代的参考来源,。所以，架构师的沟通是需要双向激荡的。我按照项目中与架构师沟通频率最高的角色、掌握的技能、信息的需求进行了归类，这样将更便于了解怎么样的沟通方式最为有效：?销售??沟通的需求：从设计中寻找卖点与特色，丰富销售方案和定制预售计划。知识技能：对开发或深入的技术内容可能只存在于概念性的理解、掌握市场的第一手信息并且对客户的需求最为了解。推荐工具：特色列表 (Full Feature List)，字段：特色功能(Feature)+说明(Summary)以产品开发（做项目会省事，没有这一步）为例，我与销售讨论整个产品的最具有特色的10项目功能（实际上3项就够了，实践告诉我只有前3项是别人记得最深刻的），这10项特色我们又称之为“购买理由”，然后是整个系统全部特色功能（Full Features）。我经常会与销售因为某个特色功能而经常激烈地碰撞，但最后销售所提出的意见与建议往往发挥着最重要的作用，有时甚至直接影响到项目的可行性。?修练的法门：抛弃一切技术实现细节，写/说出产品最重要的三个特色抛弃一切技术实现细节，用心聆听“非专业”的意见这项修炼看起很简单，重于练心，做起来对于专业技术人员并不是容易的事，细节决定成败，往往最简单最不引起注意的人或事可能是一个关键点。??项目经理?沟通需求：根据设计进行时间估算、准备项目资源与工作分解。知识技能：大多是熟悉体系架构类的知识（需要了解他/她是偏向于技术还是管理），热衷于沟通与跟