所以说，系统设计应该根据规模，业务，开发团队人员素质，项目要求时间来科学的执行设计过程，设计的目标是通过有效的沟通，达到按时按质的完成开发任务的目标。

14.文档使用策略
上次说到文档是用来沟通的，这里就会引出沟通成本的问题。团队很小，例如就3个人，开发组长把关键点记录一下，然后通过开会、面对面讲解等手段将问题沟通好，如果是3个人团队写大量文档，等文档写好，基本上时间就到期了。

团队大了就不一样了。假如团队有几十人，指望着给每一个人讲解是不可能的，所以就得靠文档沟通(当然开会也少不了的)。文档也是分级写的，当项目很大时，可能项目经理就写愿景文档(目标)，而设计文档则由承担相应模块的开发组长来写。项目经理通过文档跟开发组长沟通明白，开发组长通过文档与程序员沟通明白。

说到文档的格式，个人认为能沟通清楚就行了，没必要照本宣科(当然验收有特殊要求另说，一般那样的也是后来补的)。我个人不喜欢用什么UML图那种东西。

十年前，参与了RUP过程的项目后，觉得UML太拉风了，需求分析和设计不用太落伍了。结果，后来负责一个系统开发后，写了个大几十页的用例分析文档去和业务部门领导沟通。人家看两眼，说这个东西我可看不懂，其实用例分析文档很简单了，业务部门稍学肯定能明白，但人家不想学，也不习惯而已。因为人家甲方，你也不能要求人家必须学。

后来，在项目开发管理中，发现文字描述是最不好用的，例如数据库设计文档，少则几十个表，多则几百个表。表名及描述，字段名及描述，几百页，实在不知道谁看这东西，有什么用，花时间写一顿起不到什么作用。

当时，我个人也不写数据库文档，喜欢让团队人员装上PowerDesigner直接看数据设计模型，把字段的注释写明白，而且表与表外键关系图上就有，十分清晰，比看Word文档更好用。

甚于用于沟通的文档，我就拿PPT画，主要是图形+少量文字描述，用户适应怎么看，我就怎么画，再也不想用什么UML了，当然UML在某些场合也很有用，最起码买本书，好多书的知识点都用UML，最起码能看懂书吧。甚于PPT怎么画才有效沟通，学问也不小，到时发专题写。当年我画的两个图，给印到开会材料上，给上级和各省的参会人员。

所以兵无常势，水无常形，项目经理要灵活运用文档，不要拘泥形势，达到沟通的目标就行。

14.项目风险的防控
我个人碰到的最大项目风险，主要是项目进度的风险，项目没有工期不紧的，关键是质量也不能太差，投入倒是可以大点(单位特点)。但是熟知项目管理三角的都知道，时间、成本、质量三个角。在时间紧，质量还有要求，投入成本再大也没有，因为到极限了。类似，一个人300天可以盖一个房子，但300人一天盖一个房子的原理一样。

其实项目三角里还有一个不太为人了解的一个角，好多有经验的项目经理习惯性的用，确没看到这个理论。在《迭代软件开发项目管理》一书中，除了进度、质量、成本中，还增加了范围，形成了个四方形，而这个范围用好则是解决项目进度的主要武器，而且是项目经理的核武器

大部分提需求的用户并不知道系统应该有多大规模，有多少功能模块，否则他们也不会提三个月五个月完成了，也就是用户不知道要实现的需求范围多少。这时项目经理，就需要辨识哪儿些是核心需求，必须实现，不实现用户无法使用。哪儿些是扩展需，只是为了提升用户的易用性可以放一下以后实现。我搞项目，三个月工期业务部门领导一说，就变一个月二十天，我就是采用这办法，原计划的好多功能砍掉，只保留核心基础功能，系统先转起来，后面再完善。

再一个就是降低沟通成本，减少沟通时间。最耗时间的不是开发团队人员之间的沟通，而是与业务人员之间的沟通，天天又写文档又开会的，太费劲了，最主要是双方没有沟通的有效工具，这个工具是什么呢?这个工具就是原型法，用户只能给提供各种文件、单据、报表等，而技术人员心里虽大概怎么处理，确也很难与用户说清。所以需要给用户画原型，窗口上的按钮、下拉框、表格都有，哪儿该增哪儿该减，简洁明白。如果用lDE和常用的项目模板画出可操作的界面原型(数据绑死到控件，不读写数据库)，会更有效，原型法的效果太好了，缩短沟通时间同时，会大大降低业务人员的反反复复。

所以只有肯动脑筋，项目无论遇到技术、时间等各种风险，都能应对，前题是出现风险时不要慌乱，影响大脑运转。

15.见识和气场
当项目经理，最主要的是具备很好的综合素质。所以个人的见识很重要，除了读书学习外、在工作中吸取、与高素质人员沟通交流很重要，不一定是讨论技术业务问题，扯天谈地都有可熊提高自己见识。技术上要有见识，一个合格的项目经理不一定要写代码，去了解每个实现细节。但是要了解项目技术架构及开发过程，最起码知道应用该架构能达到什么效果。并要了解技术上的发展趋势，及流行的技术内容。