我眼中的项目经理

首先，我认为，一个项目经理，最重要的职责，就是对结果负责。也就是说，当一个项目成功的时候，你不用脸红，说你什么也没有做（如果你真的什么也没有做，就能使得项目如此成功，那么你要么运气很好，有一个杰出的助手，并且你有足够的明智、信任和恰如其分的懒惰，来让他负责具体的工作。那么你的管理才能让你可以轻松地胜任这一职务，你前途无量啊，小伙子。呵呵，不过还真的有一些管理者，恶意地偷懒，给团队带来很多不好的风气，也有类似的一种现象出现――什么也没有干，问题是看如何分辨了，最简单的一种方式就是看看结果如何？并且问问他身边的上级、下级，看看大家到底如何看待这件事情了），你就是一个胜利的Team的Leader；如果一个项目失败了，首先要做的，就是责备自己，不要责备手下人，不要说：我的团队不够优秀，我的设计人员设计出现了大问题，我的开发人员代码编写存在很大问题，我的测试人员不够优秀；归根结蒂一点，是你的错，就承担下来，如果按照这样的项目经理的逻辑，没有任何错误是管理者的错误(随便插一句，为什么我认为《都是你的错》，这本书是一本胡扯居多的书，就是因为如此，实际上，在公司层面上，很多的问题并不是执行层面上的问题，而根本是战略层面上的问题，我可以承担我层面上的错误，但是我觉得再多承担，就是有点自虐了。如果客观条件都如此好，一切都按照你的想法完成了，比如一个人在一天内，完成了整个万里长城的建设；那么也许一切都很完美了。但是，真的能够如此吗？)。一个管理者要从自身去找问题，这样他才能进一步成长，如果全部从手下人身上找责任，我觉得至少这不是一个大气的管理者，不是一个让我敬佩的管理者。举一个例子，当你是项目经理，你的项目存在了很大的问题，你的态度是什么？你正常的态度应该是很惭愧和内疚，着急想法子去解决这些问题；如果你的态度是很生气，对不起，我只能说，你没有资格生气！你还没有足够的度量和责任心来承担更多的责任。 其次，项目经理应该具有什么背景？这一点是一个无法回答的问题，因为我们不知道你的项目是一个什么样子的项目，我们不知道你的团队是一个什么样的团队等等，所以这个问题我们无法回答。对于一个典型项目，比如项目由15-20人组成，项目持续时间为1-1.5年；对于这种团队，项目经理也许不需要对某项专项技术十分精通（事实上，如果真的如此，那当然最好不过了，当然，你不能因为此而放弃管理功能，而把自己的精力放在你擅长的技术上，虽然那样做，对你来说更轻松一些）；但是项目经理对于技术大的层面应该有一个足够的认识，这些认识应该能够使得他做出一些决定，而不至于犯下很大的错误；其次，这个项目经理应该具有良好的沟通技能，因为这样规模的团队中，一个管理者在沟通中所需要花费的精力是很多的，如果你不事先在这里投资，那么也许半年以后，你将发现，再进行沟通，也许已经晚了；再次，你需要具备良好的逻辑思维能力，需要快速决定能力等等很重要的软性能力，事实上，我一直认为，一个缺乏清晰思路，和不连贯的思考能力的人，将很难走得很远；最后，你要具备相当的管理能力，你需要掌握一个团队，并且让团队按照你想要他们走的方向上进行推进；当然，其他的类似说服能力等等，都是不可或缺的。当然，做为软件项目经理，你也必须对软件的整个过程有相当的了解（这是一个Must的属性，不要因为我把他放在后面，就觉得不重要，而是说，这是一个最基本的属性。99%以上的项目经理是军队中的班长，不要把自己看成司令，认为能够完全依靠概念能力而胜任）。 做为一个项目经理，你不要仅仅把注意力放在过程上，正如我们上面所说的，你要把最主要的精力，放在人员身上：放在你的客户、你的团队成员、你项目的合作伙伴，包括你的老板身上。多和你的客户交流交流；多和你的团队成员谈谈他们的不满，多和你的合作伙伴谈谈如何更好地完成项目，谈谈你们之间的风险；多和你的老板沟通沟通项目进展，以及遇到的问题，这样也许更有效一些。这一点没有我们大家想像得那么容易。 如果说，在一个项目中，项目经理应该做什么（问出这种问题，要么这是一个超级老手，要么就是一个菜鸟，当然菜鸟居多），这一点，你不要企图去问任何人，要问的是你的公司文化是什么，要问问你的团队需要什么？正如一个管理者一样，我们并没有定义一个管理者一定要做什么，和一定不要做什么；因为我们认为一个管理者应该有足够的经验和足够的问题发现能力，去寻找自己应该做什么以及不要做什么（少和我说PM规定要干的9个管理体系，比如，至少我知道至少50%的项目经理实际上不承担成本管理的职责）。另外，很多公司对PM的职权范围都有自己的一个范围，也请关注这个范围，对于IBM这样的公司来说，他们的PM几乎不用管理技术上的特点，他们会兼2-3个项目，做非常专业的项目管理；对于很多国内的公司来说，从需求开始，到系统的架构到后期的集成和发布，以及现场安装和调试，这些都是项目经理工作中的一部分，这些都是你所需要做的。 那么我们上面提出的典型项目例子，在这个例子中，我的建议是，这个项目的项目经理应该做好如下事情： 1. 他必须明确划定系统的边界，并且通过和其他部门或者客户的沟通，做出决定，在什么时候，完成什么功能，什么功能没有必要在这个阶段完成，以及什么功能必须在某一个时间点之前完成； 2. 他必须对成本进行管理，对于这种项目，如果缺乏成本控制的概念，有时候也很难受，至少老板问起来的时候，会比较难看呢，至少你必须明白，在这个项目中，你一共消耗了多少费用，并且还需要多少费用，才能完成这个产品； 3. 他必须严格对风险进行管理，在这样的项目中，常见的风险包括需求变更的风险，包括人员风险，包括技术风险，包括合作伙伴之间的风险（当然这些风险下面，还有很多很多的子项需要分解），你即使不把这些风险告诉项目组中的每一个人（因为你需要做为一个成功的信心的象征者出现），也还是需要把这些风险记在心中，并且告诫自己，什么地方出了问题；什么地方可能出现问题，你将如何应对等等；由于风险管理，是项目中如此重要，后面我们会独立拉出一章来说，说明在什么环境下，最有可能的风险是一种什么风险； 4. 他必须时刻跟踪着项目的进度，并且随时根据实际情况，来调整自己的时间计划和任务划分以及分配；要记住：计划之所以记录下来，至少在软件行业中，就是用来进行修改的。因为不断的外界冲击，使得这些计划经常要进行调节，调节大家直接的工作节奏和步骤；这件事情最少每周做2次；不要只在分配任务的时候匆匆忙忙地做一遍。 5. 任务分配和回收，每周或者每天任务的分配和回收过程，任务下发需要协商，至少在得到项目组成员的认可以后，才能推进（这一点，要明白完成任务的是你的团队成员，而不是你，而且你应该相信你的团队成员：他们并不会无缘无故地浪费时间，原因仅仅是让自己可以有多一些的时间来休息）。任务的分配需要谨慎，我们在现实中使用了一种做法是（在这里，我非常感谢在得实中的一位同仁――刘海琳――正是他在项目组中推行这种方式，这种方式我觉得非常有效。在得实2004年一年的工作中，最让我开心的是，找到并且重用这个优秀的人才，在项目管理的严谨性和规范性上面，以及时时刻刻的思考方面，我自愧不如。顺便告诉任何一个做管理的人，发现你的属下优秀的地方，甚至是比你优秀的地方，并且重用他们，几乎没有什么事情，比这件事情更为重要的了。）在任务进行下发的时候，我们使用了一种任务单的方式，项目经理会把任务名称、任务接收人、任务的目标、目标达成的时间、其他期望等等列在一个表格中，然后通过任务下发一起发送给具体任务完成人，并且在任务目标达成的时间后，具体任务人，将这份文档发送回来；我使用过这种方法，感觉不错，主要原因是以下几点：首先，他使得项目经理必须去考虑每一个item的目标，并且明确地表达出来，而很多给很多项目组成员带来很大心理不安的一个原因就是他们得到的任务是模糊不清的，甚至是相互矛盾的，并且不断发生变化，这是一个很伤士气的做法；其次他可以使得这个任务可以回溯，将使得这些任务完成情况等等记录在案；再次，他并没有给团队成员带来太大其他的工作量，他们仅仅需要在完成任务以后，明确在任务单上标示出“完成”即可。其中最大的优点莫过于任务分配的深思熟虑方面，但是，需要明确指出的是，通过这种方法，团队一周工作，用1个小时完成分配已经不可能了，因为至少你要写10多份给予每个人的文档吧，但是，我的感受是，如果一个项目经理每周仅仅用1个小时来完成对10多个人的工作进行分配，这多少有点随意了，还是仔细考虑一下，应该如何来做比较好。我在这方面的经验是，如果是15人左右的任务分配，那么一般是3个小时左右（当然我不建议一个管理者直接面对如此多的直接管理者，这将极大分散你的精力，从而使得你没有精力来做其他事情，这对於团队来说，对于个人来说，都是一场灾难）。 6. 团队氛围的建立，团队成员的培养。如果说产品的产出是第一重要的事情，那么随着项目的成长，为公司留下一支具有战斗力的团队，也是同样重要的一环；从严格的项目管理意义上来说，项目并不承担培养人员的意义，他仅仅是使用一批适合的人，来实现项目而已；但是对于软件公司来说，我们的项目组团队相对来说比较稳定，而且行业方向相对来说比较固定（如果方向是如此不固定，一会干两天这个，一会干两天那个，这个责任，管理层需要负责，做出决策的时候，需要更谨慎一些，而不是企图手下的人都是通才和什么都能立即适应和做好），那么，培养一个具有战斗力的团队，就是很有必要的了。 7. 已经明确的流程的监控和管理，如果某一种过程我们确定要做了，这一点还是需要做好的，不管是什么理由。当然，在这一点上，我本身做得也不好。但是这不代表做得不好也是有很多理由的。对于已经明确要做的流程，一般采用的负向激励，做得不好的人，需要为此付出代价；这一点毋庸置疑。 8. 对于产品质量的持续关注，若有若无的测试，故意忽略的测试过程，导致了我们的软件，充满了低级可笑的Bugs，并且使得我们永远没有办法说明白，我们将什么时候看见可用的的软件； 这是一个项目经理所必须关注的几件事情，当然，这并不说其他的就不需要关注，比如框架设计过程等等，都是极其重要的。 再说几个大家都会在项目中处理的事情： 第一：项目例会，项目例会是否有必要？在我的经验中，我可以很明确的说，很有必要，每周花费半个小时，和项目组成员在一起对项目情况进行一次通报，还是很有必要的。当然，如果项目例会的主要作用是用来回收任务和分配任务，那么这个会议意义就不是很大了（当然，如果你的项目面临很严重的成本压力和时间压力，那么使用会议来确认时间点，并且进行回收，是可以收到一定效果的，因为大家通常不愿意，在很多人面前不断地推翻上周的承诺），因为你可以使用邮件系统，以及私下的沟通进行这些工作。一般来说，会议主要有三个作用：强调领导地位（我们的很多会议，说白了就是这个作用，比如一个空降兵空降到公司的时候，由老板主持的全部门的会议，在很大程度上就是这种会议），需要大家的短促、密集的沟通来解决问题（比如我们在设计过程中，所经常进行这种会议，如果有人认为通过MSN也能够进行，这恐怕有点过于理想化了），在一个管理原则或者类似问题，需要通过一个会议进行宣灌的时候，也就是你希望一次性把你的意见说出来，并且希望团队能够形成一个统一的观点，那么做为开始，会议也是一个好的手段。但是一般来说，会议的成本偏高，人时的成本，打搅了开发人员的思路的成本，会议室占用的成本（虽然在80%的情况，这是一个沉没成本，但是我建议你还是不要把他看成一个沉没成本比较好一些），以及你准备会议，后期会议纪要的时间等等都是需要成本的。也就是说，一般来说，我更希望在例会中，抽取一个固定的时间，来讨论大家都关心的，或者需要大家来协调解决的问题。但是，一般来说，效果并没有想像中那么好，很多团队在进入这个话题的时候，都会默不作声，于是例会慢慢变得很枯燥无味了。但是即使如此，你还是需要在一切时候，告诉大家，你开项目例会的主要原因是什么。 对于会议组织者的你来说，一般来说，我的建议是，如果一个会议你需要开半个小时，请至少花15分钟准备一个会议通知，这个会议通知会告知大家会议主题是什么，会议的例程是什么，需要大家讨论什么话题，事先需要做什么准备等等，并且安排一个会议记录者。既然一个会议那么贵，那么让这个会议发挥出最大的效用比较好一些吧。 会议完成以后，一定要有会议纪要，我不希望大家胡砍了一通，然后该如何还是如何，会议纪要中不仅要记录会议进程（一般来说，不用特别详细，我不太关心大家在过程中如何说），更重要的是要记录下来，我们在这次会议中决定要做什么时候，谁来做，什么时候Report等等，如果某些问题还存在一些疑问，没有最后落实下来，也请记录下来，好让我们知道这件事应该如何推进，比如谁来考虑预案，下次什么时候讨论等等。 第二、项目组成员的考核。一般来说，30-40%的项目经理虽然没有团队成员向他直接Report，但是还是拥有对团队成员的考核权（虽然只是一部分），这是很大的一块People Manage的工作，另外还有很多项目经理，本身不承担任何的考核职权，这一点多少是有一点麻烦的。我的意见是即使你们公司没有给你考核的权力，也请尽量给自己创造这样的机会，比如在周报中，插入一些对于团队成员的评价给他们的直接主管（当然，批评就不用做了，写谁干得好就成了）。然后，你需要明确告知团队，你认为优秀是什么，你认为的做得不好意味着什么。不要最后考核出来了，大家觉得太不公平。一般来说，一个初步做人员管理的人，会认为责任越重，那么业绩就越出色（比如设计主管比普通设计人员做得好）。这个想法是错误的，因为公司已经为这个主管支出了更高的薪水，给予了更高的Title了，我们没有理由在项目考核中，再次为这些东西买单。所以，常规的做法是，针对岗位说明书，或者项目中的承诺，完成承诺的情况如何。如果超额完成承诺，那么你就是一个优秀者，不如承诺，就是不好。很简单，不要和我讨论什么，我比某某干得好，为什么绩效比他低，很简单，你本来就应该干得比别人好，但是达到期望的程度不如别人而已。当然，采用这种方式，很重要的是两点，首先要让大家很明确，你就是按照这个方式进行考核的，其次，你需要明确和大家沟通期望何在，我们总是不希望不教而诛吧。 第三、弄明白一点，你是PM，首先是一个Project方面的牵头人，而不是技术人员，所以，不要认为对你技术方案的改进建议，是对你的能力的一种挑战，我不希望任何团队变成一个一言堂，这样的团队将变得令人很不愉快。所以，善待手下同仁们的每一个建议，只要有一点可取之处，都给予指出，如果不确定那种做法是否真的有效，那么不妨试试，不要太武断。 总体来说，我希望每一个项目经理，都能首先把自己看成一个环境营造者，营造一个适合团队成员的环境，使得团队成员能够更好地工作（比如对于过程的关注，比如系统的边界等等都是如此），即使你把自己看成一个为大家服务的人，给团队带来的效果也远远超过作为监工性质的管理者。 总之，你是一个产品的研发过程的牵头人，请善待自己的产品，请善待自己的团队，伴随着产品和团队成员一起成长，这是你的职责。

yippit 发表于 2006/12/5 20:29:00 阅读全文 | 回复(1) | 引用通告 | 编辑 | 收藏该日志

发表评论：