PM成长之路——文中的内容都能做到，你就是好PM！

lonelygo

原帖由 sambr 于 2007-8-21 19:15 发表

老兄(/老弟？)看来也做过一些项目了，呵呵，有空交流。

老D小D都可以，哈哈。
项目呢做过几个，人也管过几个
小人物。。。就是好大喜功

lonelygo

有点事情出去跑两天，不想背本子，太重了。
但愿回来的时候这个帖子没有沉到水底。[s:13]
回来后继续

lonelygo

基本要沉了，郁闷

lonelygo

这几天忙了一个项目（非EAM，谁让咱是杂家呢[s:10] ）的事情，没顾上写帖子，今天补上。
前面说到了PM在项目过程中会遇到的协调的问题，以及简单的处理方法。当然了，做为PM谁也不希望项目中天天都是需要协调的事情，都希望项目在一个正常的轨道上稳步前进。那么如何给项目一个正常的轨道呢？
     可以考虑在项目开始阶段做下面这些事情：
a、对于项目进度计划的三级管理
     三级管理是这样一个模式：长期里程碑、重点工作计划＋中期工作内容计划＋短期具体操作计划。这样的计划是一级对一级的解释与细化，这样就可以将一个漫长的项目过程通过合理的切割与组织，变成可以操作与控制的过程。通过短期计划的滚动编排，可以很容易发现项目存在的重点问题与急需解决影响进度的问题。
    通过这样一个由粗到细，再由细反馈到粗的项目计划管理过程，做为项目高层管理者可以很轻松的得到有关项目进度的真实情况和存在问题。
    对于三级计划的周期个儿建议：项目整体、月、周。
b、项目报告与项目例会制度
    EAM项目周期不算太短的，那么PM们不要指望靠脑袋将项目中所有的事情都记在脑袋里面。通过阶段的做为项目小组官方发布的文件，将项目中的进度、成果和问题进行记录、发布是很重要的。
    做为PM最重要的一个能力就是去“释放”问题，否则，所有问题都压在你身上，你再牛×你也会被压垮。那么，在项目开始阶段就和用户明确项目例会制度吧，有事情在会议中说清楚。
    建议：在正常情况下实施方项目组每周都有内部报告，发布对象就是双方项目组。整个项目官方的报告每月一个，对于特殊时期（上线过程，需求过程等）可以每周一个官方的报告。
    例会可以跟着报告走。但是为了配合顺利，最好一周一次小规模的双方项目组例会，每月的例会需要邀请双方高层项目管理者（项目管理小组的领导）参加（现实的问题就是实施方的高层管理者会每月参加吗？）。
c、需求管理策略
    谁也不希望需求变化，更不希望同样的一件事情，三个用户给了你三个“必需按我的要求来修改”的需求。对于这种你往左他往右的需求，可能是PM和顾问们最头疼的事情。很可能就是今天改过去明天该回来。
    当项目确定了项目《需求报告》或者《项目解决方案》后，双方项目经理可以坐下来明确一个可控、可追溯的需求管理方案，保证所有的需求变更都是“有人承担责任的”。
    没有规矩不成方圆，在项目开始阶段明确了计划管理、工作管理和需求管理的方法，我想PM后期需要去协调的工作会少很多的。

binxq

对于C点中解决项目需求经常变动或不通一的情况，其解决办法能不能详细说明一下，我在以前的项目中经常遇到，非常头疼。

snow.lovers

期盼看到楼主继续活跃下去呀

lonelygo

忙了几天，这帖子就沉睡了，呵呵，关心技术的还是比项目管理的多。[s:3]
        前面说了项目开始要注意的东西，协调过程中的一些事情，以及如何给项目一个合理、有效的轨道让用户能够配合实施方PM的工作，让项目在友好和合作的氛围中前进。随着时间的推移和实施的深入，项目自然会到了需要准备验收的时候。
    今天就说说有关项目验收的问题吧。
    项目何时验收、如何验收这可能是PM们被直接领导、老板们问的最多的问题，也是很多PM们很头疼的问题：用户平时配合的挺好，怎么一说准备验收了，什么都不好了，什么都要等等再说了……借口多的很，就是不配合你验收。诸如此类的事情，在项目验收过程都可能遇到。不验收用户不给钱，公司催死PM；要验收用户提了一堆问题，PM难死公司……面对验收工作，PM们该如何展开操作呢？
     从个人一贯对于项目验收的理解来看，PM去操作项目验收工作是没有什么标准方法的。虽然项目验收的标准程序很多，很多地方都能看到：各类验收步骤、各类功能验证、各类文档、各类测试报告、各类手册、功能清单……别的地方都能看到的东西，所以这些不是我想说的。有标准的东西都是可循的、可以量化的，这些东西只要花点时间下去，都能准备完成。真正带给我们项目验收的压力的东西是那些非量化的东西：这个那个功能不符合要求、使用不方便；承诺的某某功能没有实现；与合同、投标文件对比还有×××功能没有实现（这些功能很可能是售前、销售为了拿单子不管死活的写上去的。）；系统才上线×个月问题还没有暴露，再等×个月验收也不迟……这些东西PM们该如何应对呢？
    （没心情了，改天再写）

iceberg

我一般这样做项目验收，在项目试运行的后期，也就是准备要验收的时候，我在跟各部门领导交流的时候，一是说当前的系统应用情况，二就是吹风，跟他们谈说我们忙了几个月了，差不多该验收了，您看你这边还有什么意见没有，让相关部门的领导事先把一些问题提出来，多吹几次风，慢慢的各部门的领导从心理上就基本接受了这件事情要验收了，那么在验收会上就不会再说别的问题。
    另外是要做好主导部门领导的工作，不管这个项目做的程度是不是完备，只要主管部门的领导同意，就可以召开验收会了，在会上其他的部门领导又基本上没有意见，那么验收就不会有问题。
    私下里说一句，我做项目验收从来没有对照技术协议核对功能开发的情况，只要事先的工作做好了，验收会就是过场和签字的工作了。
    一句话说吧，功夫在诗外。
    请lonelygo指教。

lonelygo

原帖由 iceberg 于 2007-8-29 18:13 发表
我一般这样做项目验收，在项目试运行的后期，也就是准备要验收的时候，我在跟各部门领导交流的时候，一是说当前的系统应用情况，二就是吹风，跟他们谈说我们忙了几个月了，差不多该验收了，您看你这边还有什么意 ...

哈哈，也是个忽悠，不敢指教。

yf6456

等待更新，[s:2]

lonelygo

在继续开始之前，要说明一个问题。
    关于项目，我们可以去追求完美，但是考虑到给我们发工资的老板的心情，所以，在研究项目验收这个问题的时候，让我们先把做个完美的项目这个念头扔到别的地方，重点去关心如何让一个项目在大家都能接受的底线之上去验收。
    事实上，项目验收应该从PM接到项目的第一天，从看招标文件、投标文件、技术协议那天就开始准备。道理很简单：PM之后做的所有工作就是要完成这个项目，所以从这天开始PM就要为项目验收而准备。
    看招标文件、投标文件、技术协议不是去弄明白要做什么事情，而是要“清楚的知道那些用户要求的东西、公司承诺的东西、合同里写清楚的东西，在事实上是无法实现或者在成本分析中实现这些东西是不划算的”。这些东西PM要明确的把他们从这三份合同相关的文件中识别出来，然后去和销售经理、售前顾问聊聊，看看这些东西都是怎么跑到合同或者标书里面去的，那些是可以去考虑回避的，那些是用户很关心，需要去考虑实现的。
    行了，弄清楚这些事情之后，组织好你的小组成员和顾问，把这些东西说清楚，考虑好需求调研的时候对这些问题采用何种方式去调研之后，可以着手准备项目启动会（第一次设计联络会）了。
     其实，做项目的过程，就是去将那三个文件（再罗嗦一次：招标文件、投标文件、技术协议）逐渐衰减的过程，当PM所担心的问题都“合理”的衰减了（合理是很重要的，有时候老板们会用一些“粗鲁”的方法解决问题，表面看暂时解决问题，事实上后遗症很厉害。），那么项目也可以验收了。但愿这个表述，大家能理解。
    PM如果能抓清楚影响项目未来发展和验收的主要问题，那么就需要在前面讲的协调、沟通过程（就是我说的吹牛过程，鉴于大家的理解有误，我改正为协调、沟通）中一点一点去把握用户对这些问题的心态和想法，然后加以诱导和说服。感觉条件具备的时候去选择一个合理的方式去将这些心中的石头释放掉。
    有那些合理的方式呢？
    会议显然是首选了。需要考虑清楚的就是会议的主题是什么，不要傻傻的去开有关功能、需求变更为主题的会哦，这会吓到用户的。关于开会的问题前面也说了很多，就不多说了。需要注意的就是选好主题，然后把你想实现的事情合理的安排进去，并讨论通过。
    第二选择就是个别沟通了。每个功能点总有核心用户部门的，那么就去和这些部门的领导去沟通、协调吧。
    还有第三种好办法吗？那就是希望用户不要提这些问题了。但是谁能保证他现在不提，你准备验收的时候不提呢？装傻，不是好办法。还是主动去排雷比较好，免的炸的时候你很惨。
    把那些麻烦的需求都合理的处理了，那么面对验收我们还要做什么？
    分布验收，分模块验收是个比较好的策略。古话说一口吃不成胖子嘛，那就慢慢吃吧。分步、分模块验收从用户心理来说压力相对较小，就是一个模块，验收了你也跑不了，给你签字的可能性很大。当然了，事情都是两面的。分模块验收是容易，那么需要考虑以下问题：
    a、模块验收了，用户来新的需求，做还是不做？
    b、模块验收的功能显然不会是三个文件规定的全部东西，如何保证在总体验收的时候用户不和你回头算旧帐？
    说个一家之言：做电力项目，只要钱没拿到手之前，所有的签字都是假的，千万不要以为签字了就万事大吉了。曾经有PM向我说：怎么能这样，原来都签字了，现在怎么又变了，怎么签了字都不算？我说：你怎么办？去他办公室哭能解决问题不？
    c、签字验收的人，对于项目的最终验收是否具备绝对的发言权？人家弄个副主任给你签模块验收，等最后发飙的时候主任去，一句：模块验收的事情我不知道，我今天提的问题你们必需做到，要不我不签字验收，谁要验收谁去签字。能气的你想把你的IBM扔过去。
    不管怎样，事情做的差不多了，项目也超期了，总是要验收的。
    上面那个兄弟说了，提前吹风是很重要的。这小风慢慢的吹，一个人一个人的吹，争取在吹风的时候把问题都提前了解清楚，然后找合理的理由去说服吧。
    现在能不能验收了？估计还是比较悬吧？总有不好摆平的用户的，跟你叫上劲了也不是什么奇怪的事情。那么就上下活动，团结可以团结的力量，判断清楚问题和形势后开个验收预备会吧。
    你不给我验收，那么我要求开个预备会“诚恳”并且“认真”的听用户的意见和问题，并给出一个解决问题的时间表，在这个时间表内，谁不配合、谁不能完成任务都要有相应的处理办法。我曾经利用中午吃饭的时间和电厂一把手聊天，除了没说项目的事情，聊了很多话题，还记得有：应用数学是什么专业，能做什么；拉普拉斯方程；电网潮流计算；电厂主辅分离好不好；他们电厂有没有必要成立检修公司……。一直聊到下午上班，然后跟到办公室跟他谈预备会的事情，最后要了他一句话：开会的时候我肯定最后发言，你说什么我强调什么，怎样？
开会的时候，厂长还多说了一句话：“人家D经理在这边很久了，也很辛苦，我认为他们的工作很有成绩，今天人家也拿出最后的验收计划了，态度非常好。今天我还要说的就是，那个部门不配合××公司技术人员，导致计划不能完成，到了时间你们那个主任不签字，我来签字验收，验收完了我再找你算帐。”听了这话，心里那个爽啊。当天没有加班，晚上喊小组兄弟们出去喝酒。
    个人认为，预备会是个比较好的处理方法。行了，预备会也开了，问题都说清楚了，能不能验收了？
    答案是还有可能出什么鬼问题导致用户提出来不验收，对于老PM，遇到这样的问题不奇怪吧。怎么办呢？相信通过前期的沟通什么的，PM对用户的心里底线应该都能把握了，而且前面你也做了这么多工作了。就差最后一点了，不解决不急死人啊？
    备忘吧！我都做了这么多事情了，最后这一点你还担心我不做？但是，说好的要验收啊！总要让我给公司一个交代啊？而且，没按时验收，你（用户PM）这不也算没完成工作啊？要不咱各退一步，你给我验收了，我验收报告后面给你附个备忘录，我答应你做的都写里面去。
    事情做到这份了，PM们项目验收了没有？

BobWang

D总啊[s:5] [s:5] [s:5]

lonelygo

通过一个项目从头到尾整个过程的简单解释，希望新的PM及技术转型的PM们能够从中间得到点自己需要的东西。也算我没有白花这么多时间去打字。
    写了不少，回头再来提炼下：
    项目开始阶段，分析清楚合同相关文件很重要，从中间发现以后需要注意的“特殊”功能要求；
    在项目开始阶段和用户明确项目的管理体系：报告、例会、需求变更等；
    排一个比你觉得能实现的计划周期压缩20％的总体计划；
    根据自己的能力和优势选择一个理想的介入项目的方法：或者高调（这个不是太好玩）、或者认真、或者技术很好、或者理解行业需求……
    开始阶段，多和用户沟通，不一定要有问题才去找用户，电厂的主管们大多时间还是教多的，多接触接触是好事；
    刚开始的项目报告一定要言之有物，能客观反应问题（是用户的就指出来，是自己的错误也老实写上去），让用户领导觉得可以通过这样的形式了解项目情况，并愿意参加例会；
    滚动计划一定要准确，不要滚来滚去，事情总完成不了，会导致用户对于你计划能力和做事能力的怀疑；
    排雷工作早点做，不要等验收前3个月才想起来；
    PM就是PM，不要再去做技术高手，对小组兄弟多些指导，少做点具体事情，多花点时间去考虑项目整体的事情；
    对于验收，不要一根筋的去考虑，做多种方案准备，然后考虑清楚后再和用户去谈；
    最后，关心项目组兄弟们的生活，人性化点；

BobWang

很有启发意义啊,
再次崇拜一下

lonelygo

原帖由 BobWang 于 2007-8-29 23:48 发表
很有启发意义啊,
再次崇拜一下

哈哈，你就拍吧。

binxq

好帖顶就得起来，希望继续发好帖。

qizinb

好帖顶就得起来，希望继续发好帖。

sambr

看起来各个行业虽然有些差别,不过好像也没有太大差别.电力的我接触不多,我是作石油.石化和制造的,遇到的各种情形以及解决措施看起来似乎很有雷同啊.

lonelygo

原帖由 sambr 于 2007-8-30 13:26 发表
看起来各个行业虽然有些差别,不过好像也没有太大差别.电力的我接触不多,我是作石油.石化和制造的,遇到的各种情形以及解决措施看起来似乎很有雷同啊.

没错。
从顾问的角度来说，适当的了解行业很重要；
但是从项目来说，项目管理应该还是有很多共性的东西的。

iceberg

lonelygo做的报告在于把项目管理过程中可能存在的问题及相关的解决方式都作了必要的阐释，受益匪浅呀。多谢了。
    另外多说一句，取法乎上，仅得其中。我们每个PM 还是要结合自身的特点及项目的特点，全方位提高个人项目管理水平和用户沟通水平，才能成长为一个较为理想的PM。