撰写详细设计是一个逐步细化、深入的过程。没有人能一次就设计出完美的东西，需要及时的沟通，包括与客户的反馈，与其他项目组成员的讨论，这样有助于降低开发时偏离需求的风险。也就是说，在开发之前题，是建立在设计者的想法有客户的确认和开发人员的理解的基础之上设计撰写人必须与系统分析员反复讨论，以透彻理解用户需求；

一项需求可能有多种方式实现，设计者必须与系统分析员确定该需求将采用何种方式实现，将达到何种效果，以消除将需求映射为设计的歧义；讨论过程中还可能会发现需求有不完备甚至错误的地方，在需求重新确定后设计者需修正设计。设计文档必须写清楚各个模块/接口/公共对象的定义，列明程序的各种执行条件与期望的运行效果，还要正确处理各种可能的异常。此外设计文档应该遵循一定的写作模式与版面风格，使用统一的术语或惯用语，使得小组成员很容易理解。以上这些活动综合起来将是一个很细致、很耗时的工作过程。就个人所知，一些公司的详细设计通常是由程序主管或少数核心的程序员撰写的，他们通常也是系统架构的主要作者或维护者。因为他们在开发团队中技术最为精湛，对架构最为熟悉，他们最有资格评价现有架构是否能适应新的用户需求，采用何种方式实现需求对架构的冲击最小。但是由少数人来负责所有的详细设计可能造成开发过程中的瓶颈甚至是设计的错误。当任务比较集中的时候，设计者可能忙得透不过气，而负责实现的同事反而在等米下锅，比较清闲。于是为了让自己不成为拖累进度的“罪人”，某些设计者就会采用一种快捷方式来交付设计：他们会与系统分析员进行初步的讨论，然后撰写一份粗糙的但仍然叫做详细设计的文档，把它交付给负责实现的同事，再通过讨论、即时通工具、电子邮件等方式解答对方提出的疑问。但由于详细设计本身不完备，他们不得不花费更多的时间和精力与负责实现的同事沟通；而且他们却很可能忘了把这些交流的成果更新到详细设计中去！（或许是他们太忙，没有足够的时间，又或许是他们认为既然产品已经实现，那么详细设计也就不必维护了。）其结果很可能是当产品开发出来后，我们才发现它跟用户要求的完全两样！原本在详细设计阶段就应该发现的需求漏洞与在那时应该确定的技术方案在实现阶段甚至测试阶段才暴露出来，而这时大家往往有木已成舟的感觉，改动的难度比设计阶段高数倍甚至十倍以上，毕竟任何再牛的人都有自己的局限。

对于以上问题我提出全员设计，全员设计的含义就是把详细设计的工作进行适当地分解，把它们分摊到小组内其它同事身上，让大家都参与设计。这可以说明如下：

当一组用户需求基本确定下来后，程序主管需要估计需求的相关性、需求的优先级、设计的难易程度、设计的工作量等，将该组需求分解为一或多项设计任务，并指定给适当的同事。参与设计的每个人必须负责至少一项设计的撰写任务。设计者从系统分析员处获得详细的用户需求，并与系统分析员反复沟通以透彻理解用户需求。他还要分析系统架构及产品的已实现与/或已规划部分，理解架构的设计理念，理解产品不同模块之间的协作关系，理解架构与产品之间的约束和依赖。当然对系统架构和产品的分析不可能穷尽每一个细节，只要分析与即将开发的模块相关的内容即可。

一项设计任务，它可能需要多个程序员完成。比如用户界面或网页由某位或某组同事负责，而业务逻辑组件则由另一位或另一组负责，数据库部分则又由其它同事负责。设计者必须考虑他们的立场，以各方面都相对容易理解的方式写清楚主要的模块/接口/对象定义，明确相应的调用规则与主要逻辑处理。如果某项设计任务所涉及的内容太专业化，设计者并不熟悉相关的内容（比如某位C#程序员并不熟悉如何编写一个存储过程），他可以用描述性的文字说明该部分的设计要求，并知会相关的同事补充。其它同事在补充时可以对这些描述性的文字重新整理，以更加确切地表达设计内容，更符合文档的书写惯例。在设计文档完成后，设计者必须把他提交给程序主管或由程序主管指定的程序员审阅。个人推荐由其它程序员而不仅仅是程序主管来审阅。不用担心等待多个人的审阅意见是否可能导致一份设计滞留很久。大家可以并行地工作，不必是A审阅后才能B审阅。可以交叉审阅，即A的设计由B、C审阅，B的设计由A、C审阅等。审阅意见可以用多种方式（如讨论、即时通工具、电子邮件）反馈给设计者，设计者负责汇总这些意见并修正设计。以个人的经验而言，通常设计交付审阅后半天内就可以收到反馈意见了。设计经过反复地修正直至没有人再提出修正意见，这时就可以由程序员实现了。以个人的经验而言，一份设计通常两、三轮反馈后就可以定稿了。如果多次反馈后仍不能定稿，极有可能是：

a)需求尚未明确，各个方面（包括客户、系统分析员或设计者）对需求的看法不统一

b)技术或系统架构存在严重的限制，无法用较方便的方式实现

全员参与设计好处、风险与不适用的团队如下：

1.2.1 全员设计可以带来以下明显的好处

1.有助于平衡工作量，加快开发进度。详细设计的任务分解后，程序主管或核心程序员可以有更多的时间处理其它的事务，比如关注软件的开发质量或改善系统架构。详细设计的撰写任务分解后它们可以并行地撰写，这将极大地提高设计撰写的进度，节约时间。

2.有助于培养程序员的大局观。每位撰写设计的程序员不再仅仅只关心自己负责实现的模块，他必须从更高的层次考虑和理解设计。

3.有助于加强同事之间的交流与协作。设计者需要与系统分析员、其它程序员、审阅者进行反复的交流和沟通，实际上每份设计都是多人协作的成果。更多的沟通有助于集思广益，有助于避免一、两个人的倾向性意见导致错误的设计。每位设计者都需要对自己撰写的设计负责，他还要向其它同事的设计提供审阅意见或技术建议，彼此的工作是互相支持和依赖的，这有助于减少“只扫自家门前雪，不管他人瓦上霜”的想法。

1.2.2 推行全员设计的潜在风险

1.在某种意义上，全员设计可能增加交流的成本。两个人之间有一条交流途径，三个人之间最多有三条，四个人之间最多有六条。途径越多，信息量就越大，而这些信息不见得都是有用的信息。详细设计的任务分解后，不可避免地有更多的人参与交流和沟通，大家要花更多的时间来理解他人的想法，也可能要花更多的时间向他人阐述自己的观点。特别是在并行撰写详细设计的过程中，系统分析员反而可能成为另一个瓶颈了。但从总体上来看，在设计阶段花费适当的代价发现更多的问题，比在实现阶段或测试阶段再发现问题，仍然是划算的。

2.分解后的详细设计可能引入冲突的设计内容。由于设计由不同的程序员撰写，他们考虑问题的角度和思维的方式不可能完全一致，这增大了不同的设计内容之间的计算口径或交互方式不一致的可能性。这需要设计者们尽可能遵循一致的设计原则，也需要审阅者们尽可能找到这些不一致的地方。

3.并不是所有的程序员都适合参与设计。很明显，例如刚入职的同事就不适合参与设计，他们对系统架构还缺乏足够的认识。另外兼职的同事也不适合参与设计，他们的工作方式可能无法保证及时提交设计文档与参与讨论等。