项目管理实例—— 点评[转]

查看( 579 ) / 评论( 0 ) / 评分( 0 / 0 )

项目管理 实例—— 点评

在MSN项目管理群里，一位很资深的IT工作人员推荐她的博客，我粗看了一下确实不错，准备每篇阅读一下，当然也希望通过点评一下来提高一下自己。该文章是作者对项目管理实例进行的相关思考。

项目管理实例（1） － 不一样的PMO
http://blog.c s a i.cn/user2/50754/archives/2009/39793.html

项目管理实例（2） － 选拔项目经理
http://blog.c s a i.cn/user2/50754/archives/2009/40050.html

项目管理实例（3）－换将
http://blog.c s a i.cn/user2/50754/archives/2009/40116.html

项目管理实例（4） － 加人一定管用吗?　
http://blog.c s a i.cn/user2/50754/archives/2009/40345.html

项目管理实例（5）－2009年终盘点　
http://blog.c s a i.cn/user2/50754/archives/2010/42082.html

首先是PMO的产生
所在公司是一家软件 公司，主要为电子行业、航空航天等军工企业 提供信息化 产品和服务。
1、老板受他本人在制造业 工作经历的影响，把一个软件公司的组织结构设置得如同工厂，几乎每项工作都是一个部门只承担一部分，不允许参与其他工作。
2、 比如售前阶段，工作说明书是咨询部负责完成，合同签订后，转到实施部，实施部的项目经理和业务顾问到客户那里进行业务调研工作，编写出业务调研报告和业务 需求说明书，通过评审后才能继续传递文档至下游，下游是设计部，负责需求分析和概要设计，再下面是开发部，负责详细设计和编码.。。。。。。
老板 想得挺好，可是最大的问题很快就来了，软件过程中的文档很难标准化，评审难有标准。而各个环节都希望上游的产出物一定要满足下游的输入要求才行，否则下游 的部门就不接！，因此，设计部埋怨项目经理和业务顾问写的业务需求不够详细，不够准确，没法做需求分析，评审一次次通过不了，同样道理，开发部门死活不认 可设计部的架构师写的需求规格和概设，认为不能指导详细设计和编码工作，而架构师又认为他们只负责需求分析和概要设计，开发部要求的那些事都应当开发人员 自己完成。。。。。。
项目经理除了自己要写业务需求外，整天都在协调、协调，下游环节的部门不接受上游部门的产出物，项目经理也难以判断该不该传到到下一棒，需要协调的事情特别多。何况他们的文档也常常被别人狂批，似乎自己也没协调的资格。
——点评
这个是分工过于职能化的恶果，需求和文档在内部过程中已经失真了，且由于职能化的原因，内部无法达成一致，除了问题只能相互推诿扯皮，缺乏一个整体协调机关
如果采用项目组型会怎么样呢？人员无法得到充分利用，项目内部的各个环节质量取决于项目经理的素质，也会造成一定的问题
想必这也是各个公司PMO产生的主要原因之一吧。

一 个项目组由各个部门的人组成，无论是产品经理，还是项目经理每推动一步都很费劲，各个部门扯皮的现象层出不穷。就是在这种情况下，老板设想成立一个公司级 的综合管理部门，将公司主要的骨干，如项目经理和产品经理集中到1个部门，进行总协调和总负责。这个部门被赋予了相当大的权利，因为老板希望找一个“强 势”的人能好好替他“管一管”。本人就是在这样的背景下走马上任的。我的部门被设置为PMO，与一般公司的 PMO不同，我直接领导项目经理，而且无论何人，不管是哪一个部门，什么职位，只要担任项目经理，就都归我领导。项目经理管理和考核着不属于同一个部门的 的组员，即使组员是其他部门经理，甚至是技术副总监，也仍然归项目经理领导和考核。因此，本人是一个名副其实的PMO (Officer的O,不是office的O) ，管理和掌控公司所有的项目和产品，
——点评
这是一个比较强势的PMO，直接划为一个部门，项目经理比较强势，而PMO更加强势。

我预想的PMO会比较温和一些，由资深的PM和各职能部门经理组成。
制定公司软件工程和项目管理流程、制定公司文档管理制度。
对项目的软件生命周期、项目风险等进行指导
对项目经理进行考核
对软件过程进行监控和度量
对项目中遇到的问题进行评估，协作提供解决方案和再分配

关于选拔项目经理
1、没有调研到明确的客户需求，只是将以前已调研到的做了确认；
2、现场调研活动主要以老H为主要提问人，小Z为主要补充提问人。G君在现场基本插不上话；
3、现场工作过程中没有阶段性的详细计划，对于双方的工作安排以及相互配合没有很好的统一规划协调；
4、每天的调研情况没有及时讨论汇总；
5、没有对第二天工作的安排和预期；
作者认为该PM业务不熟悉、对公司项目流程不适应、项目准备不够充分等等。
其实我的想法是
该PM业务不熟悉是正常的，刚工作的项目经理显然无法同有此经验的技术人员相比，项目经理也是需要通过项目不断去熟悉的，也有个熟悉的过程
该PM对公司项目流程不适应，这也很正常，一般而言从大公司出来的PM与从小公司出来的PM相比，适应性要差一点，为何，在大公司项目流程已经很规范了，他只需要follow即可，而小公司往往缺乏流程，或者需要自己去慢慢摸索和了解；最好的办法是培训。
项目准备不够充分和多方都有关系，但是自信是必须的。
作为PM也需要在不断的学习和摸索中成长，无论大公司还是小公司出来的PM到了一个新环境都会面临这个问题。

关于换将
这个在缺乏流程的小公司和人员流动频繁的公司比较普遍，本人深有同感。
一个项目换了3茬需求调研的售前，换了3茬项目经理，每次去调研又都是在重复同样的问题，别说客户会反感，就连项目总监也会感觉很失望。
尤其是在解决方案中给出的10几个核心名单，在实施过程中几乎一个也没有，换成谁，都受不了这个打击。

关于加人一定管用吗?
我的看法是在某些时候是管用的，在某些时候是添乱的，很多时候是上司强行安排的，处于无奈必须接受的，这样的加人只能让PM感受很差。
为什么要加人，在什么阶段加人，需要进行评估的，在需求阶段加了很多开发人员确实没有太大作用，可如果为了做demo，在需求阶段增加开发人员则是有用的
什么样的工作是并行的什么样的工作是串行的，什么工作是最关键的，需要甄别清楚再下结论是否需要加人

关于2009年终盘点

1、同时做两个项目的项目经理比只做一个的要做的好；
个人感觉可能问题出在工作较多的项目经理认为自己受到了重视，其次忙的项目经理更加需要思考，因此更能提升自己。
2、“自称”不懂技术的项目经理比熟悉技术的项目经理做的好；
不懂技术的项目经理能够把关注力集中在业务、管理和沟通上，如果太懂技术的话，不知不觉人就会沉溺其中，反而忘了主要工作。
3、研发（非现场）投入最大、现场投入也最大的项目，缺陷最多；
个人理解，现场的压力会大些，其次具备相应的软硬件环境，而且客户随时可能来抽查，所以保持高度的戒备，缺陷会少些
4、所有项目都是进入内部研发阶段，进度控制不错，而只要有客户参与，进度就无法保证，但平时几乎所有项目经理都叫嚷“和客户打交道容易，内部协调最烦”；
在现场客户会有一定的干扰作用，但却又是合情合理的，和与公司的协调，处于自身的尴尬位置是无法去挑明。
5、提前一个月给客户安装 上线，最后验收仍然拖后3个月！
这个似乎是通论了，越到上线客户越会找一堆需求。