[M] 为什么CMM管理模式对小项目可能不适合呢？CMM在国内的实施过程中，有人提到了裁减问题。对此你是怎么看的。

[L] 其实这个问题怎么回答呢！因为我对CMM不是很了解，我觉得企业在实施CMM的过程中不能全部照搬，如果全部照搬肯定不会适合自己的企业而且也会造成浪费的。我觉得我们公司的CMM执行是，大家在一起学习一些CMM的思想，一起根据CMM的规则、流程制定一些适合公司自己的CMM的规则，公司按照制定的规则做事情。然后让CMM的评估机构来验证，看公司的事情是否是按照CMM的规则做的。这是我个人的感觉，因为我也没有参加CMM的培训、公司流程的制定，所以我也不是很清楚，只能按照个人的一些想法来回答你的问题了。

[M] 那你从一个公司普通职员的角度来看，这种“localize”的CMM制度，在公司内部的实施效果如何呢？

[L] 应该说localize的制度是符合公司的实际情况的，是根据公司的实际需要来做的。在实施的效果上应该是比照抄照搬的效果好一些的。但是CMM毕竟是一个很费精力和时间的东西，况且公司现在刚刚实施，因此大家难免会有做得不好的地方，或者抵触的情绪。不过相信随着时间的推移，随着大家意识的提高，应该会做得越来越好的。

[M] 对于一项制度，在其真正实施的过程中，总会有走样的可能。比如，你所在的公司在项目管理方面所推出的一些制度。对此，你有何看法。

[L] 我觉得制度是死的，人是活的。我们可能不需要完全按照制度执行，但是关键点应该保证。对于特定的项目可能制定的制度并不完全适合，所以我们要摘取恰当的部分，要灵活运用。比如一个很复杂的系统按照公司制定的流程可能从管理、资源、质量等都能够得到控制。但是如果系统本身很小，比如我刚刚接触的一个项目，功能很简单，如果完全按照公司的整套流程走的话，我估计效果不会很好，而且可能劳民伤财，还得不到预期的效果。所以对制度的执行要灵活，某些时候关键的内容作出来了，其他的边边角角我觉得可以不用深究，而且公司有时确实也是这么做的。有些项目不完全按照CMM做，因为太浪费资源了。

[M] 能对前面提到的 SQA，SCM做一下解释吗？

[L] SQA是CMM中的软件质量保证的意思，SCM是CMM中的软件配置管理的意思。软件配置管理，是指在CMM中，软件开发过程存在3个库：基线库、生产库、产品库。基线库是在软件开发的初期建立起来的，比如需求、项目进度、计划等等，以后的软件开发以它为基础。并不是说不允许更改，但是更改的话需要走变更流程，需要先申请，后审核，审核通过了才允许补充进入基线库。生产库是项目开发过程中存在的库，产品库是项目开发完毕后的了，库中存放的大概是一些文档、代码等等。当然你可以使用clear case来作为媒介，也可以使用source safe，这要视公司的具体情况而定。

[文档]

[M] 你对程序员进行文档的组织、编写、维护工作持什么样的态度呢？这是否会影响coding呢？尤其是在来自客户和市场的压力十分严峻的时候。这是一个很现实的问题。

[L] 其实我们大家都不止一次的提到，在做项目的过程中大部分时间都是用来组织编写文档，真正coding的时间在整个项目的生命周期中占的时间是很少的，一个真正的项目也不是以coding作为结束标志的，因为项目结束后还有维护或者二期甚至三期，所以文档的积累对于项目来说是至关重要的事情。作为项目结果之一的代码，我们不能只让写这段代码的人知道，这无异于赌博，而且经过一段时间之后谁也不可能保证自己对自己曾经写过的代码一清二楚。我们要让所有的人知道某段代码应该实现什么功能，包含什么逻辑，是一个什么样的思路，这样项目转接工作才能做得更好。客户和市场的压力十分严峻的原因是什么，不可能因为程序员写文档造成的。相反如果文档写的好反而在coding阶段会节省很多的时间，因为思路、算法在文档中已经得到很具体的体现。如果真的客户和市场的压力十分严峻至少在项目结束后应该把文档补齐。如果只是项目经理写文档，那么他的思路、设计，在程序员身上很难得到体现。因此我建议程序员要参与到概设、详设的文档编写中来。其实，摩托罗拉是很好的例子，他们不会因为某个程序员或项目经理走了，来接替他的人需要花费大量的时间来熟悉这个系统，相反他们可以从文档着手，很好的理解整个项目。我们公司有很失败的例子，在给HP做的电子商务系统中，到现在某个页面可能被5－6个人更改过，但是基本的概要设计连第一版本的内容都没有，因此现在维护相当的费劲，几乎没有人愿意接触这个项目，一点小小的改动，都要研究半天的代码。血的教训啊。

[M] 对于项目文档的准确，完整，应该如何去把握呢？

[L] 项目文档的准确，完整的定义可能很模糊，而且判断起来也很困难，但是我想基本的应该是：项目初期应该把项目涉及到的内容全部写入文档，项目进行中可能某个思路不能得到实现需要更改，代码更改了但是文档一定要跟着更改，否则失去了文档本来的意义。所以我想项目经理在做计划时是否每周要留出半天甚至的时间来修改文档？

[M] 项目文档化过程中，文档撰写者需要将思路精确无误的表达出来，并且阶段性地保持文档和代码的一致性。这对文档撰写者提出了一定要求。在你的公司里，当客户和市场的压力十分严峻时，又是如何保证这些的。对此你有什么看法或心得，你认为程序员需要具备什么额外素质吗？

[L] 其实写文档是一个整理思路的途径，所谓的完整或许不需要面面俱到，但是重点的流程，关键的思路等都需要描述出来啊。其实对于文档的撰写，不要觉得是个很复杂的事情，文档的意义在于它记录了项目的完成过程，在于便于以后项目的维护。当客户和市场的压力十分严峻时，我们的精力可能集中于项目的真正coding，专注于项目的按期完工。但是在项目结束之后项目文档一定要补全。现在国内的情况是程序员大部分是本科出身，因此程序员本身的素质决定了他不止可以承担coding的任务，因此项目经理要适当的给予他们一些其他的额外工作。

[M] 文档具体包含哪些类型？每种文档针对何种阅读者？

[L] 文档包括：需求分析说明书，概要设计说明书，详细设计说明书（许多数据流图都作为文档的附件的），等等吧，现在我手上也没有很全的文档列表。

[M] 在你的公司，有没有类似程序设计说明这样的文档，若有，对于这类文档，撰写者若表述不清则会使阅读者难于理解。实际中是否存在这样的问题？

[L] 其实我觉得象概要设计说明书，详细设计说明书不知是否属于程序设计的文档，不过我觉得应该是吧。其实象这种文档如果撰写者表述不清对于阅读者的理解程度会有很大的差别的。我们公司也一直在讨论如何制定一个切实可行的规范，以利于大家把文档写的详细、清楚，我们现在的模板有时对于某些项目来说真的不适合。但是很长时间以来仍然找不到一个可以避免的方式。在现实的工作中，我认为是存在表达不清的，只不过我暂时没有遇到过，或许我从需求阶段一直跟到验收，所以对系统很了解，所以可能没有遇到不好理解的地方吧。而且现在公司的形式是每个人负责写一块的概要设计和详细设计，因此这份文档对于这个人来说很明白，但是没有人对整体文档的把握，虽然我们要做概要设计和详细设计的评审，但是由于大多数情况下时间不允许，因此项目成员写完以后，项目经理组织到一起也完事了。

[M] 文档的意义或作用除了记录项目完成过程外，还有其他吗？

[L] 或许文档的意义重要的在于项目的"repeatable"，"repeatable"前几天刚刚从项目管理部经理哪里听来的新词，具体的含义我想大家可以讨论。或许文档可以帮助我们总结经验教训，记录我们突然间的思想的火花，遇到同样的项目可以提供经验。