会员登录
会员注册我的一位同学(Leo)目前正在一家软件公司工作。一段时间之前，在我的提议下，我以私人的身份对他进行了采访。我们以mail的方式进行了多次交流。以下是经过整理后的谈话内容，主要内容涵盖：项目管理、CMM、文档、版本控制等。希望这篇来自“一线”的文章会给大家带来启发，也欢迎大家共同讨论，并提宝贵意见。以下文章中，M代表我，L代表我同学。
声明：本文版权由Leo与Morning共同所有。
[开场]
[M] 你能对你目前的软件开发所涉及的应用领域做一个扼要的介绍吗?
[L] 首先我们公司的目标是软件外包，因为时机还不是很成熟，或者暂时还没有那么强大的市场竞争力，所以我们也要做国内的项目，作为过渡。而且我们公司是一个资源公司，所谓资源公司也就是可以短期或长期的给客户提供一定的人力资源。比如IBM的某个项目突然需要很多人，但是他们不想自己招人，因此他们就来找我们公司要人。至于我所涉及的领域主要是渠道销售网的建立以及维护，属于电子商务。大部分都是针对企业内部具体情况而定的一些项目。
[M] 你的team work规模如何?
[L] 我进入公司以后所经历的最大的项目组就是5个人。在我们公司一般的项目都是5-8人的，小项目基本就是1，2个人。
[M] 在team work中，你的职责是什么，起着什么样的作用?
[L] 既是coding人员，同时也担任着项目经理的角色。
[项目管理]
[M] 在一个team中，程序员的主要职责是什么呢?
[L] 作为程序员来讲，主要的职责就是要保质保量按时的完成项目经理分配的任务。在CMM中强调大家的整体参与，项目过程文档化。所以作为程序员来说在实施CMM的过程中，不应该只是coding的角色，还应该参与文档的编写。因为在CMM中项目过程文档化对项目经理来说是一份很大的工作量，因此必须把一部分文档交给程序员来写，因此此时程序员的工作多了文档的组织、编写、维护的工作。还有程序员还应该及时参与项目经理的整体设计，以及框架结构的设计等设计工作，要意识到如果项目经理的一步错可能的责任在他，但是工作量的直接增加是在于程序员。作为程序员还应该注意代码的规范以及注释的书写。
[M] 那么，在team中，项目经理的主要职责又是什么呢?
[L] 作为项目经理，主要的职责就是在一定的时间内使用给定的资源按时完成项目，并且达到客户、公司双满意。在项目组要起着模范带头作用，要用积极的态度来对待这个项目，要以身作则，如果加班的话，项目经理必须来，即使你来了没有什么太大的用处，要会拉拢人心。要监督项目的进展情况，这是至关重要的一点，比如在我们前一段时间做完的项目管理系统来说，我虽然名义上是项目经理但是我被代码压的喘不过气来，因此就没有时间来review程序员的代码和工作，而我的Owner也没有做这部分工作。虽然项目按时完成了，但是我感觉有极大的隐患。项目经理还要做到知人而用。要注意项目文档的准确，完整。
项目经理在项目组和公司之间起着协调资源的作用，因为项目经理要和项目管理部接触，及时的相互通融项目的进展情况，要按照公司的标准做事。如果发现项目进行过程出现时间不够、人手不够等情况，要及时的向你的领导反映要求增加人手或脱后时间等。项目经理在开发部和测试部之间也起着协调的作用，要帮助测试部搭建测试环境，要分配测试部提交的defect，要监督defect的完成情况。
最后最关键的，就是项目经理在公司和客户之间的职责了，项目经理在公司和客户之间起着桥梁的作用，要把公司最近的情况向客户阐述，还要把客户的要求及时准确的反映给公司的领导。因此遇到客户的需求变更、项目验收等问题时一定要注意自己的说话语气，做事的方法态度等，否则后果就是走人，如同我的leader。遇到客户的问题觉得扛不住时一定要及时的汇报给领导，因为万一公司和客户的关系僵了，这个责任自己是承担不起的。对待客户要不卑不亢。
[M] 你所说的Owner是一个什么角色?
[L] Owner的概念，在IT业内可能是我们公司的一个特色，因为我们公司的项目经理都很年轻，没有什么经验，因此项目来时公司会分配一个项目经理，然后分配一个Owner，在项目经理之上管理这个项目。不过Owner一般没有什么作用，绝大部分的工作都是项目经理完成，只不过当项目过程出现重大变更时Owner可能起绝对性的作用。这种Owner应该相当于公司的部门经理的作用吧。
[M] 在与客户的交流中，你或者你的同事有过不愉快的经历吗?如何处理这种情况呢?
[L] 我觉得与客户的接触中需要做到不卑不亢，对于客户提出的需求，属于范围内的，就没有任何怨言的修改，如果超出范围则需要讨价还价。不过，其中有个方式的问题。这点我承认做的不是很好，但是需要慢慢锻炼。比如：我们刚刚完成的项目中，我们安装交付之后，客户提出需要修改某些东西。我的leader直接就说这属于需求变更需要加钱，而且我的leader很自傲，说话不注意分寸，因此遭到客户投诉，搞的客户关系很僵，最后的下场就是遭到公司的开除。所以现在遇到需求变更我就先不答应也不驳斥，我说回公司找领导研究一下。当然我是真的找领导，如果领导说让我告诉客户需要付钱，则我就说属于需求变更，可能收费，如果领导说做吧，好我做。反正有什么问题有领导顶着。如果客户关系已经很僵了，则需要灵活的处理了。比如经常打电话问候一下软件运行情况，出现bug更新的速度快一点等，让客户感觉到公司很重视他们。和客户说话一定要注意，要表现出来我已经尽了200%的力量。如果动员全公司的技术高手来解决一个问题，仍然没有结果，就可能需要考虑更换另一种方式来实现。
[M] 在你的公司，似乎对项目经理在技术方面有较多的要求。而有的公司似乎项目经理更偏重于管理和资源筹划，有些对技术可能并不很了解。对此你是怎么看的呢?
[L] 应该说我们公司的情况是比较特殊的，或者说中国的模式就是这样的，项目经理一般都是从做技术开始，慢慢接触管理的。我们公司的项目一般比较小，而且有时人员编制又不足，这样就导致项目经理既负责管理和资源策划，又要参与一部分的coding、技术工作。而且项目成员遇到技术问题，项目经理就必须竭尽全力去帮助他解决，因此要求项目经理必须掌握一定的技术。不过我们公司也在慢慢的改变这种境况。首先项目经理分配工作时就要考虑到项目中可能遇到的各种问题，然后自己coding的工作会比较少，大部分精力放在管理和资源策划。而且项目经理的资源策划以及管理的权力也在逐步变大，经验也在慢慢增加。不过我倒是从来没有真正的自己带领一个团队工作过，而且自己在管理以及资源策划方面的能力也不是很足。公司Owner的作用也在慢慢的消弱，具体的与客户的交互，与公司其他部门的协调，与测试部的协作，现在的项目经理都是一人独掌。
[M] 项目经理是否必须懂技术?你是怎么看这个问题的。我曾经遇到过的一种情形，是在一个teamwork里安排一个项目经理和一个技术负责人。你觉得这样的方式是否可行呢?
[L] 个人认为项目经理还是适当懂一些技术比较好，但是如果真是如你所说安排一个项目经理和一个技术负责人的话，或许项目经理是否懂技术也就变得无所谓了。
还有一种情况就是，象我们公司现在进行工作量评估，这样的话项目经理可以不懂技术。
我认为项目经理适当懂点技术的出发点是：项目经理在做计划时需要考虑某个模块的工作量。如果模块工作量已经估计出来了，那么项目经理可以直接根据这个工作量来安排计划。好多时候是项目经理在估计模块的工作量，因此如果项目经理对于这项技术一点不懂，不知道某个模块可能遇到的技术难点以及解决这个难点需要的时间，那么在做计划时可能就会不准确。
但是我们公司现在的情况允许项目经理不懂技术，原因是工作量的评估是许多人的加权平均值。我们的流程，一般是在项目需求确认后开始工作量的估算，这个时候要求项目经理按照需求功能拆分很多不同的功能点。理论上，拆分地越细，工作量的估计就越准确。每个人对于每个功能点都存在一个乐观值、一个悲观值、一个可能值，三个数的加权平均就是某人对于某功能点的工作量。很多人对于某功能点的加权平均就是该功能点的工作量。最后给客户的报价也是按照该工作量来报的。项目经理可以按照公司评估出的工作量来制定项目计划。当然，遇到技术问题可以找项目管理部来让他们帮助找人解决。
[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] 由于需求的变更导致项目的问题我倒是不太敢确定，不过我曾经接触的项目中由于客户的不成熟，或者说双方对需求的理解不够导致项目验收拖延的事情确实存在。