[M] 在小型开发团队中，你是否认为，成员职则彼此都较模糊，或者说互有交叉。人员相互弥补不足，对leader来说压力可能也会小些。在这样的环境下，个人自由与纪律规范是一对矛盾，如何处理这个矛盾，如何把握这个度呢？

[L] 其实现在我所接触到的开发团队中，成员的职责应该说是比较清楚的。某个模块由谁来做，什么时间交付定义的都十分清楚，而且功能相近的模块也不可能交给多个人做，除非工作量很大。至于具体的职责问题我想项目成员应该是保证自己的代码、文档的质量，当然他也要对项目有一定的责任心。在开发团队中人员相互弥补对于整个项目来说肯定会有很大的益处，这样项目经理不用帮助协调技术等问题了，会有更多的时间来管理项目。在开发团队中个人自由与纪律规范是非常尖锐的矛盾，对于度的把握更难以衡量了，我觉得只要不影响项目的进度，不影响项目的质量，遵守公司的各种规范，有些问题是可以通融的。其实团队开发关键是一个professional的问题。属于工作范围之内的，要没有任何理由的按时完成；不属于工作范围之内的问题尽量少搀和。不过工作范围的界定可能又是一个问题吧。其实也可以这么理解，如果你的编程能力很强，只用了2天的时间完成了项目经理交给的5天的工作量的话，那么剩下的3天你会干什么？继续写以下的代码？还是学习？我想应该是学习吧。你不能接着写以下的代码，因为你不知道项目经理所安排的本属于5天工作时间之后的后续工作，可能他要一个中间阶段的测试等等。但是由于你急于赶工，因此导致了他的中间阶段的测试不能执行。还有，项目成员要统一开发语言，我们公司有个EPSON的项目，除了一个人之外其他的成员都使用delphi5，只有这个程序员用delphi6，你说项目经理能不生气吗？

[M] 你在前面提到的项目管理部是一个什么样的机构？

[L] 项目管理部是公司的一个专门讨债的部门，整天追着项目经理要文档:)。其实怎么说呢，他们是负责监控项目的整个流程，特别是现在要做CMM，更是需要项目管理部。因为SQA，SCM等都是贯穿整个项目始终的，而且还起着比较重要的作用（有关SQA，SCM的问题请见后）。因此项目管理部的工作显得比以前更为重要。而且我们以前项目的源码、文档等都在项目管理部有备份，自己如果不小心丢了，还可以找项目管理部要，如果他们也丢了，责任大了。总之项目管理部是监督项目的流程，控制项目的质量，而且像需求变更等都需要项目管理部的参与。

[M] 是否可以认为，项目管理部是在项目队伍不够成熟的前提下才产生的，它既起主导作用，也有辅佐作用，并且该部，对公司的所有项目组统一负责？

[L] 项目管理部的主要的工作是跟踪，管理所有项目的整个流程。特别在CMM中，我觉得它存在的必要性更大了。其实它不应该说成在项目队伍不够成熟的前提下产生的，或许应该说成随着项目队伍的成熟，随着公司的规范，它可能要发挥越来越重要的作用了。

[M] 为什么你认为项目管理部随着项目队伍的成熟，随着公司的规范，可能会发挥越来越重要的作用呢？

[L] 我感觉随着公司的规范操作，项目过程中的各种问题、流程、以及解决方案，都会得到很好的积累。积累的结果不可能局限于某个项目组，某个项目成员。也是说不可能是某个人具有这种积累，而应该是公司具有这种积累。公司需要把这种经验总结下来，保存下来，项目管理部正好可以起到这种作用。既总结项目经验，又监督项目的执行，还提供一些经验促使项目少走弯路。在CMM中，项目的各种操作有严格的定义，项目经理可能不是很成熟，或者没有足够的时间来应付各种各样的工作。此时如果派其他的项目经理来监督可能效果不是很好，因此项目管理部可以派人员进入到项目组，在项目的特定阶段监督项目的执行。

[M] 对review程序员的代码和工作，你一般是如何做的？

[L] 迄今为止，我还没有真正的单独带领一个团队工作过。在我们刚刚结束的项目中，我名义上是项目经理，但是因为还有一个owner，因此我大部分的精力是coding，然后是帮助项目组成员解决技术问题，当然某些项目经理的工作我还是稍微接触了一下。因此对于项目模块功能的review，对于代码的review，我都没有做，因为我自己的coding任务太艰巨了。不过如果真的是我，我想首先项目经理应该按照项目计划每天检查项目成员对于功能模块的完成情况，这是项目经理基本的工作。你必须检查项目成员的进度，适当的调整项目计划。然后在项目时间不是很紧的情况下要review程序员的coding，因为虽然程序员把功能实现了，但是代码可能隐藏着很大的隐患。适当的培养程序员的编码规范意识，这样对于程序员个人，还是公司都是一个很好的积累。

在我们公司曾经有一个项目经理每天要两次调整项目计划，他带项目真的是很认真，很有一套经验的。我们公司还有一个team，当项目经理review某个程序员的代码时发现一个页面中竟然使用了10个以上的recordset(记录集)，这种代码的质量太让人难以接受，虽然功能实现了，但是隐患呢？很危险。因此项目经理很生气的把该程序员训斥了一通。

[M] 你是否认为，对需求的正确理解将直接影响项目开发的后续工作。实际情况，往往是用户自身对需求的认识也并非总是清楚的和一尘不变的，对此，你怎么看呢？

[L] 对需求的理解肯定会影响项目开发的后续工作。因此在市场前期对销售人员，以及对参与需求调研的人员的能力，有比较高的要求。他们要准确把握用户的需求而且要挖掘用户的隐含需求，特别是对于用户自身对需求也认识不清的情况，更需要前期的人员有很高的能力。用户需求不确定是一个不可避免的问题。在任何项目中，这种问题都会出现，所以我们公司对于需求变更，一定比例之内是无条件更改的，对于超过比例的需要收费了。在需求调研阶段，我们往往是做demo，要求用户确认。通过demo，用户的要求和我们的理解能比较好的达成一致。

[M] 需求变更超过比例的需要收费，则公司无形中承诺了这种变更将不会使项目出现问题，这一点团队成员上下都需要保证的，那么，如何保证呢？有没有反例呢？

[L] 其实任何公司都不会允许客户无休止的更改需求，因此需要采取某种手段来制约客户的需求更改，我想收费的目的也在于此吧。至于目的是否能够达到，效果如何，终是否把需求变更的钱收回来是具体另一回事了。

[M] 我想知道在你所在的公司，在项目开发过程中，是否存在由于需求变更的程度很大，而导致项目形势很糟糕这样的现象，或者由于采取适当措施而“化险为夷”的事例？

[L] 由于需求的变更导致项目的问题我倒是不太敢确定，不过我曾经接触的项目中由于客户的不成熟，或者说双方对需求的理解不够导致项目验收拖延的事情确实存在。

[CMM]

[M] 你在项目中采用CMM管理有多长时间了？对CMM的印象如何？从开始接触到目前为止对其认识是否有变化呢？

[L] 对于CMM整套体系我还不是很熟悉，而且我们公司在做CMM的规范时我的项目正紧，因此也没有时间参与其中。总的来说，我们公司是在近刚刚启动的几个项目中采用CMM管理的，我手头的这个项目还没有正式开始，我估计正式开始后也会采用CMM管理。所以我从未使用CMM管理过项目。对CMM总的印象是项目过程文档化，一个项目结束可能需要产生40、50个文档，而且这种管理模式对于比较大的项目应该是很有用的，但是对于小项目好像用不上，但是我想或许应该从小项目来实践吧。

[M] 在前面的谈话中，你曾提到“CMM中强调大家的整体参与”，从实际角度出发，你是如何理解这一点的？在公司规模不同的情况下，这种“强调”又是如何具体体现的？

[L] 或许在CMM中没有涉及到“CMM中强调大家的整体参与”这句话，这只是我个人的一点意见而已。因为在CMM中追求项目结果文档化，因此项目文档是一个比较大的工作量。我们公司一个项目结束后可能要产生50多个文件，如此大的文档工作量，如果让一人完成可能不太现实，而且文档的维护也是很大的工作量。因此需要把概要设计，详细设计等工作的一部分交给各程序员做，因此也做到了大家参与。而且对于系统采用的技术，某个模块的具体流程等每个人肯定有每个人的想法，因此需要集思广益，大家参与讨论。无论公司规模的大小，比如微软，可能整体的大架构程序员不能参与，但是具体到小模块时，程序员会参与其中。对这一点我的体会在于概要设计和详细设计上，前提是大家都深入了解了需求，然后每人负责一部分模块的设计以及coding、文档的工作。

[M] 是否可以这样认为，在小规模的team中，程序员该主动参与框架结构的设计等整体设计工作。而对于大型的软件开发公司（比如微软）而言，这种方式是否不适合呢？在CMM中是否对此有所提及。

[L] 我的一点想法，在CMM或者公司中都没有具体谈到这个问题。确实象我们公司做的一般都是针对性很强的项目，所以在项目过程中大家都有自己的看法、自己的设想，而且项目经理或者所谓的系统分析员也未必是考虑得十全十美。所以我的想法是大家一起开会讨论研究整体的系统框架等问题，这样能够集思广益。对于项目中的难点，关键的地方，大家都有个比较清醒的认识，也利于大家团结一心。我觉得即使在微软，他们也会或多或少地参与，他们也会提出他们的建议。好，这个问题留待讨论，实践。