项目经理手记

 

上个项目算是告一段落，进展的非常不顺利，但也算是一种经历，从中领略到了很多东西。做项目，就是要从失败中学习，对于导致项目进展不利的因素进行分析，进而使自己在下一次的项目管理过程中不会再一次的犯相同的错误。俗话说的好，人不应该被同一块石头绊倒两次。所以，失败并不都是坏事，虽然对于项目没有按时完成，项目经理承担主要责任，也被领导叫去训话，但是我觉得自己从中分析自己失败的原因，并在下一次项目的改正，这就已经足够了。

现在，又一个新的项目开始了，在对上个项目进行细致的总结以后，我也一直在思考，同时也看了一些关于项目管理的书籍以及大家的回贴后，我对发现的一些问题进行了个人的总结，并找到了一些改进的方法，希望在下一个项目中得以实施并收到良好的结果。当然，项目管理并不是从书本上的知识就能学到并灵活掌握的，但把从书本中学到的一些好的方法应用到项目管理中，从一定程度上还是很实用的。

 

１．如何进行需求的分析与挖掘？

其实这个问题不应该成为一个问题，因为一个真正意义上的的项目经理是不需要去做需求分析的，而应该是让专职的需求分析人员去做。我的理解，项目经理在工作过程中，与需求沾边的工作应该是对于项目范围的定义：确定哪些是在项目中要做的，哪些是不用去理会它的，清楚地定义项目的边界。除此之外，其它的工作都应该交由专门的人员去进行专业的信息采集与处理。但大家都知道，在实际的工作中，项目经理往往是既当爹来又当妈，一个人做Ｎ个人的活，尤其是当项目不大的时候，项目经理更是要一马当先地什么都做，几手都要抓，同时，老板对你的期望又是几手都要硬。因此，从现实的角度考虑，这个问题还是要探讨一下的。

记得我刚从学校毕业到公司的时候，曾无知地告诉老板说我对需求分析还是很有经验的，老板当时就笑着对我说，其实要想成为一个有经验的需求分析人员，起码要有十年的工作经历。当时只是觉得老板嫌我刚出道罢了，但做了一些项目之后，我对于需求分析这件工作有了更深刻的认识，也清醒地了解到需求分析真不是一件容易做的事。

首先，是我们对领域知识的缺乏。客户所在的领域并不都是我们所熟知的，这不像是在学校里做课程设计，不是图书馆管理系统，就是学生管理系统，连蒙带猜也能编出来。行业的多样性必然会导致需求领域知识的多样性，面对这样的困境，又怎么能要求我们在与客户短短的几次交谈中就获取足够的信息来完成一个复杂的软件产品呢。

 

其次，客户对需求的理解与传达不足。需求很明显是由客户传递给项目组的。客户在解释需求的时候，有时就会带有很大的含混性，而且客户对需求的说明不能做到完全的正确。如果是与外国人交流，那信息的损失就会更大。在与外国客户的交往中，英语国家的人可以用母语与你交谈还算是庆幸了，遇到了母语不是英语的国家的客户与你交谈，那两个人都要非母语进行交谈，双方都够把心里想的东西表达出７０％以上就算是非常成功的交流了。同样，分析人员在对需求进行吸收的时候也会产生误解，一些信息也会被遗漏掉。靠这样获取的需求进行开发，结果是可想而知的了。

 

要解决上述的问题，似乎没有什么比经验更好的办法了。对于某一行业领域的熟悉，需要一定时间的积累，了解了一定的知识之后，就能更容易得与客户进行有效的沟通，获取项目中需要的信息。需求对于项目的重要性不用多说，一个项目至始至终都是为了达到让客户满意的目的，满足客户的需求，其实是一种对需求含混性降低的过程。为了达到这一目的，还有一些称为方法的步骤可以让我们减少对需求的误解：

            １． 细晰地划分项目干系人（Stakeholder）：尤其是分清什么是客户，什么是使用者。在了解需求的时候，我们能从哪些人中获取信息。同时还要注意到，获取的信息是否得到负责人的确认。

            ２．需求分析会议：与客户的会议当然必不可少。从中尽可能多的找出不清楚的地方，及时的提出，如果客户允许可以进行录音，不过这一招估计很难做到，大部分时候客户可不想留下自己的话柄。与项目组成员的开会是为了在组内加深对需求的了解，集思广义，再用点头脑分暴之类的东东，可以发现更多的求知问题。

            ３．在初始的需求得到后，要对其进行细致的分析，划分功能块及其属性和约束条件。

更多的知识，可以参考温伯格的《探索需求——设计前的质量》。

 

２．如何进行有效的沟通

沟通的话题一直没什么争议，在项目中没有沟通简直就是死路一条。我上次做的那个项目就是在沟通上出了问题，使得项目延误。在我发了贴之后，很多朋友也回复指出存在的沟通问题。其实在项目进行中，项目经理要把大部分的时间放在沟通交流上。作用主要包括提出项目的方向（做决策、授权工作、指导各项工作、协商、报告），参加会议，整个项目的管理，公共关系，记录管理（会议记录、报告、规格说明、合同文件）等。沟通的关系主要存在于三个方面：与项目组内部、领导、客户。

 

项目组内部的沟通是开发出有质量保障的软件的基础。没有沟通，大家个个闭门造车肯定是不行的。上次的文章中我也提到了这个问题，项目成员间的沟通方式有Email，会议，电话，面对面交谈等。Email这种沟通方式方便快捷，如同QQ聊天，不需紧张，对于不善当面交流人们来说是一个福音，但是这种方式还是少用为妙。做为人与人之间的沟通，仅用文字是远远不够的，当然，对于技术上的东西可以，但对于理解性的或者感性的东西，文字的表达能力还是欠缺的。会议这种形式也是问题多多：有效的会议组织可以使得各种决策成为会议的结果，达到开会的目的；无效的会议人们就是在那边聊天叙旧，很多问题都得不到最终的确认结果。所以说会议也是一把双刃剑，如何有效的组织会议也是一门讲究。事先安排好会议日程是必须的，而且在会前要对会议有充分的准备，从而在会议中得出结论。电话交流相对好一些，但若是项目经理与组员的交流过多的通过电话，信息的传达就像上级向下级传达命令一样，组员会觉得项目经理架子太大，这样会给组员一个很不好的印象。所以，面对面的交流也是必不可少的一样形式，而且项目经理要多花时间在与组员的直接交流上来，积极的把握项目的进度，及时的得到组员的反馈信息以便做出调整。而且直接交流也在项目组内创造一个宽松的环境。

这里需要提出一点的是，我本人也屡次遇到这种情况。当项目经理传达任务给组员时，一定要注意自己的用语，务必达到清晰准确，以免造成别人完成任务以后，你才发现这并不是你当初想要的结果。最好在传达后，让组员确认他是否已经精确地了解了你的要求，这样的信息传递才是有效的。

与领导的交流是个有趣的话题。在我的上个项目中，更多的情况下是领导主动来找我问项目的进展情况，我当时没有意识到要主动的去向领导汇报项目的进展情况。结果在项目出现了问题之后再去找领导，这样就是等于把责任往领导那边推，好危险的：）所以，作为项目经理，要及时得与领导交流，把项目当前的进展情况传递给领导，正式的汇报比如每周的报告是远远不够的，建议多一些日常的非正式交谈。在交谈中，在领导的一些问询中很可能发现一些自己未预见到的问题，如果领导觉得有必要，要及时的做出调整，增加资源等。这样的话，对项目，对项目经理本人，对领导自身，都是有百益而无一害的。

客户的交流很重要，上个项目中的与客户交流不畅导致了很多问题。很多网友也在回复提到这个因素。项目经理有这个责任与客户进行交流，询问一些不清晰的需求，及时报告项目进展等。但要注意到，不能一有问题就打电话给客户，这样客户会非常反感。要利用有限次的机会，获得更多的必须的信息，这样才是有效的交流。比中可以让组员最大程度的发现未知的问题，搜集到一定量再一次性的去询问客户。这样不但不会影响客户，也要提高项目组提出问题的能力。在这里，有一点问题需要说明，介于各公司组织结构与人员安排等多方面的因素，项目经理有时未必能直接与客户取得联系，必须通过领导，这种情况下，就回到了上面所说的与领导交流问题，项目经理也要给领导一些压力，促使领导安排与客户的联系的机会。

 

３．如何进行时间管理

从项目经理的角度来看，时间管理应该分两个方面，一方面是项目经理对项目的时间资源管理，另一方面是自身工作时间的安排管理。时间资源对于项目来说是十分宝贵的，虽然人月只是神话，但是每一天，这个神话都在不停的被人期待着，尤其是老板们（可能他们也知道这只是个神话）。

完美的时间分配是每个人每天八小时都被安排的满满的。这显然是不可能的。项目的开发有点像进程的并发，有时要有等待。这时项目经理要及时的调整组员的工作安排，一种办法是把任务已经的组员安排到被瓶颈阻塞的任务上来，帮助别的组员一起进行解决问题（又见神话），另一种是看下阶段的工作是不是可以划分出一些在这个阶段就完成。让组员空闲着就说明项目经理的安排没有做好。上个项目中，有一段时间组员都说没有事情可以做，当时没有很好的做出调整，才导致后面的时间资源紧张。

对于自身的时间管理，项目经理要把握的一点就是永远都要把重要的事情放在第一位。每天早上到公司就要安排自已一天的工作，并按优先级排一个序，接下来就要做优先级第一的事情。从长远看，要按照重要与紧急的安排划分，相信大家在很多地方也都看到过。

 

重要又紧急的事情是当前要执行的，让人忙得不可开交。

不重要又紧急的事情就是浪费时间。

重要但不紧急的事情才是项目经理能把握先机的关键。之所以出现很多的紧急的事情，把项目经理整天忙得团团转，很多情况下就是因为事先没有把握好这些重要但不紧急的事情，如果能够事先做准备，后面的安排就是按步就班，很少出现忙不过来的情况了。

不重要又不紧急的事情，就随它去吧。

特别的，对于一些项目经理要写的文档，最好规范出一些模板。一般公司都会有相应的文档模板，但那远远不够，每次项目都要写一些类似的信息，所以最好自己整理一份模板。以后每次做新的项目，只要输入一些新项目的信息即可，这样大大地减轻项目经理日常的工作，把花在文档上的时间降到最小，何乐而不为呢。

４．如何进行开发方法的讨论

关于开发方法的讨论一直是个热门的话题。不论是学者还是实践家都在不断地寻找一种好的方法，从经典的瀑布模型到现在流行的敏捷开发，都给软件开发带来了一次次的进步。虽然方法如此之多，但老实说，虽然瀑布模型很难应对当前快速变化的软件需求，但大部分情况下，软件开发还是按照它来进行开发的，最多有一些迭代的变化。至少我在参与了不少项目后发现基本上都是按照它来进行的。

瀑布模型明确指出了软件开发过程所要经历的每一步流程，每个阶段都是以上一个阶段的完成而开始的。同时，在每个阶段的结束时，要有一个里程碑的检查，来决定是否可以进入下一个阶段。这种方式比较适合需求基本稳定或者大型的项目。迭代的开发模式阶段与瀑布模型一致，不同的是当一个阶段的工作出现问题时允许回溯到上一个阶段进行改进，这种方法其实更加实用。因为，在现实中，很少有项目在编码与需求或设计文档要求的完全一样。现在热论中的敏捷开发好像在国内实施的并不是很多，这种方法讲究的是轻量级的入手与实施，简单灵活的设计以备随时应对需求的变化。国外似乎应用的更多，我觉得可能这种方法看似简单，但对开发人员的要求极高，光是灵活的设计以及对面向对象思想的深入理解，我们又有多少人都够胜任呢？

我个人觉得方法的使用还是要与项目的特征相结合。比如说我的上个项目是个Web的项目，那就应该用快速原型开发的方法：在接到客户需求后，第一时间内就是进行UI的设计，把所有页面全都按已知需求做出来，以及页面间的链接做出来，然后拿给客户看，这种方法对需求的定位比较准备，能够在早期就与客户进行有效的沟通，启发客户提供进一步详细的需求描述，对后期的开发有着极大的帮助。再比如我现在正在做的一个类似MIS的系统，所有的需求都已明确，客户提供了详尽的需求资料，而且是在先前系统上做的一个增加功能的版本。这种情况下，我们就应该选择走标准的流程。

项目类型的不同，决定的开发方法选择结果的不同。项目经理应该熟悉各种开发方法，才可以在对项目分析之后决定用什么样的开发方法来应对它。

 

５．如何面对技术细节

技术细节的问题我相信是困扰着项目经理的一个头疼的问题。理论上说，项目经理的职责就是进行管理，对于技术是没有什么苛刻的要求，顶多是了解即可。但实际上，在我们所处的环境中，项目经理一般技术出身，有着一股对于技术狂热的酷爱，仿佛不进行技术的学习就是没有意义的工作。针对这人问题，我想谈谈自己对于这个问题的看法：

         1.项目经理不能没有技术背景

很难想像一个对技术毫不了解的人来做项目经理，对项目来说是个多么大的悲哀。组员肯定会经常把气撒在项目经理身上，“一个什么都不懂的人怎么能够带领我们这帮聪明的程序员？”，这样一来，气士低沉，项目何来的曙光呢？当然，大部分的情况下，项目经理还都是技术出身的，从程序员的岗位上提升上来，即所谓的编而优则管。一个具有技术经验的项目经理，无论是在计划安排，还是在做决策的时候，都会因其具有丰富的经验而更加有效的执行。同时，在对需求的理解上也会更加深刻，可以更准确的把握项目的进展方向。

         2.项目经理不能陷入技术细节

拥有技术对项目经理来说是必备的，过多的专注技术就是项目经理的大忌了。项目经理应把工作的主要任务放在管理上，即计划安排，资源调配，进度控制，交流等等，把这些工作都做到位，需要大量的时间与精力的。而如果项目经理专注于技术而不能自拔，那就势必影响到他应做的工作。而且，过分专注技术的人往往有个特点就是爱追求完美，我个人有时也是这样。觉得事情总会一个完美的解决方案，就在其中深入的研究，这种精神对于科研的学者来说是一件好事，但是对于在企业中的人员来说，就另当别论了。尤其是项目经理，在管理一个项目时，不要去追求完美。典型的问题就是关于软件产品的三要素的关系，即时间、成本、质量，如果项目经理想要对这三方面都追求完美，那么这个项目基本上就不用做了。因此，在开始一个项目时就要衡量到底这三个因素要重点放在哪两点上，另一点可以做一些舍弃。不要因为没有找到一个完美的办法而灰心丧气，这个世界本来就不是完美的。

         3.项目经理应该把握技术的发展方向

不专注技术，不代表不去理会技术，特别是当前这个技术日新月异的时代，项目经理应该主动地比别人更快的去接收新信息。对于技术的发展，作为一个项目经理是应当很好的把握的。做Web的项目就应该了解现在Web 2.0的方向，在微软平台上做产品，就应该了解.Net 2.0, 3.0的新特性。这时并不要求项目经理要去学习具体的知识点，只是说要求项目经理每天能够利用少许的时间从互联网上获取最新的资讯，更新自己的知识结构，对项目的技术方向有个明确的认识，才能更从容地应对未来的技术变化。

         4.项目经理应与职能经理一起为促进团队的技术提高而努力

当项目接近尾声的时候，项目经理需要准备一个总结的报告，对项目进行一番评述。而组员的工作基本就已经结束，其实这时需要做的工作非常重要，就是对软件开发过程中的一些技术点进行总结，比如生成能够重用的控件、某一问题的通用解决办法等。这些工作，对于技术人员来说是一种积累，同时，对于公司来说也是一笔潜在的收益。因此，项目经理应该安排技术人员进行这方面的工作，多数情况下，职能经理可能考虑到现实的情况，会安排他们直接进入下一个项目。但项目经理应该与职能经理进行很好的交流，争取到一部分的时间来进行上述的工作。所谓磨刀不费砍柴工，大量的知识积累，可以更高地提高开发人员的工作效率与开发的产品的质量，到头来，还是解除了项目经理的一大头疼问题。

 

总结

啰嗦了那么多东西，只是想谈谈自己对项目管理中遇到问题的想法。其实上面的每一点都可以展开成一本书的容量，只是自己还没有那个能力去分析的那么彻底。毕竟自己也是一个刚刚步入项目经理队伍的新手，更多的时候，还是需要去从项目中学习经验，总结成败。也希望自己能够及时将自己的经验总结拿出来与大家分享与交流，从大家的意见中，吸取更多的精华。