不完全it手册（五）——设计（1）

不完全IT手册（五）――设计（1）

发信站: 水木社区 (Tue Jul 1 15:28:47 2008), 站内

http://chenleimin.blog.sohu.com/93407737.html

首先必须明确的一点，“设计”这个流程是一个统称，这里其实包括很多小的任务明确的流程，即使按照最简单的分类方式，也可以分成概要设计和详细设计这两种。其次，设计流程没有，也不应该有明确的起止日期（你做任务计划是另一回事），在做需求的时候，对于一些很明确的东西，就已经可以开始做设计了，而即使到了测试阶段，随着变更的需求或你发现的BUG，依然要进行部分设计工作。

好了，废话说完，进入正题。

第一步工作，显然是让你的团队熟悉需求，文档发给大家看，然后自然是必不可少的讲解，给大家讲目标系统要实现什么东西，对你的团队而言，他们不必像你一样对客户流程滚瓜烂熟，但也一定要清楚大概是怎么回事。

第二步工作是模块划分，每个模块大致完成什么功能，由谁来做，基本上明确下来，注意这里仅仅是粗分，对模块之间的连接不必过多讨论，这个工作应该做的很快，有条件的写个小文档，没条件的大家开个碰头会讨论一下也没啥不可以。

第三步是一个重点了，就是对各个模块进行技术层面的设计工作，这里，我强烈建议当PM的不要自己写这方面的文档，一定是你计划让谁做这部分的开发，就让谁写设计文档，不要怕他写的差，写的不好你告诉他哪里不好，让他重写（这里我们假定员工的态度都是好的，关于这个问题将在后面的文章中重点说），这样做的重要意义是你能够知道他们自己在多大程度上理解了你的想法，没理解的部分，都是哪些没理解。这个时候千万不要为了省事自己写，一般情况下，你写的东西，他们不管懂了多少，都会跟你说他们懂了。

第四步，就是让他们自己来讲自己写的技术方案，你自己一定要听，如果有条件，你组内的成员也都来听，白板是必须的（什么，你们老板这个都不给买？那你早点辞职吧），有投影仪当然更好。设计人员自己讲，能引起他本人的足够重视以及加深他的理解，组内人员都来听，对后面的相互之间的合作将有莫大的好处。有的时候，第一遍讲的效果很不好，那么你就要组织这个人第二次讲，当然了，为了避免视听疲劳，可以只讲修改过的部分。讲的时候注意时间控制，有问题当然可以随时停下来讨论，但不要一讨论就没边了，必要时刻你要中断讨论。集思广益，独断专行，IT并不是一个讲民主的地方。

本篇的后半部分，说说另一个重点，任务如何分配。一般来说，作为PM，你总是这个组中技术水平最好的人（或者之一）。我看到有些PM总是将最重的模块留给自己，在为你的奉献精神鼓掌的同时，我对你的行为则很是摇头，一定一定要记住，作为一个猪头小队长，你最大的任务不是战斗，而是监督管理你的小队去战斗，你一定要有空闲时间抬起头来，看看你的小队成员干活干的怎么样了，看看小队以外的（客户，领导，其它小队？）都在干啥，如何与他们配合呼应等等，而这些，如果你自己扎在代码堆里，那么你就几乎看不到了。

当然，也不是说你就可以什么都不干了，端茶看报纸上QQ和MM视频了。首先我估计你也没那条件，领导也不答应，其次，项目中一些重点内容我看你还是自己把握才比较好（注意是技术重点，不是工作量重点），例如整个程序的架构、数据库结构、各个模块之间的数据接口等，不同的项目有不同的重点，这个相信你自己一定知道该把握什么。

下一篇，我来讲讲设计文档中都需要写一些什么东西，哪些东西是需要写的，哪些东西是可以简写或省略的。

• 上一篇 Y_addr
• 下一篇 也来晒晒80后每月生活的开销