Thinking in PM–实战小结

Thinking in PM–实战小结

  Viewer discretion is advised.

  上周收到PMI的邮件:PMI Certification Granted,没有太多的惊喜,这么多年的软件项目管理
如果没有过反倒是不近情理了,而且这次还被PMI抽中资格验证,为啥抽奖就抽不到我捏?
考试和实战有很大的区别,
PMI本身是很强调项目经理的职业生涯规划的,只是国人更看重的是那张证书而已。最近两年我一直
从事互联网软件项目,一直忙忙碌碌,这里简单总结一下自己的体会,也算是作为参加这次PMP考试的
纪念。

   谈项目管理,遗憾的是首先很多公司就没有采用项目方式来管理软件产品开发,要开发某个产品时,
把产品运营、技术研发、服务支持一帮人叫到一起,开个会,老板发个言,大伙就开始干了。项目
经理是谁?是老板?怎么可能!项目经理没有得到明确的任命,产品运营、技术研发、服务支持这一帮
人只是一个Group,而不是一个Team,大家还是在自己的职能部门里面各干各的。要想成功的实施一个
软件项目,项目经理是关键,必须被明确的任命,必须被充分的授权。

   项目的三角形约束(我更喜欢锥形约束的表示方式):范围、时间、成本、质量形成锥形的4个点,
组织在中心,这是项目管理的核心。在现实世界中:时间是卡死的,往往是老板(投资人)要求在4个月内
一定要发布产品;成本当然是拼命压,越低越好;范围里面的功能特性是满满的,这个功能不能缺,那个
功能必须有;更可怕的是人手还没有完全到位,先启动吧,边干边招人呗。唯一没有被明确要求的就是
质量,往往最后牺牲最多的也是质量。这样看来,就很容易理解为什么很多软件项目的结局是心酸的。
所以说:做软件难,做软件项目经理是难上加难。然而这一些都还可以想办法争取解决,在崇尚“唯一
不变的是变化”的互联网,PM更大的挑战是变化,今天刚刚确定好功能列表,明天突然又要做一个调整,
后天忽然又有新的idea,大后天发现还是原来那个好…. 如果提交变化的那个人,有把项目的锥形约束
放在脑袋里面认真的思考一下,想清楚范围的变化对进度、对成本、对质量、对人员的影响时,Wow!
这个世界真的会和谐很多。

   项目的沟通管理:每一个项目成员都清楚下面这些问题的答案吗?
1)“这个项目是做什么?我们在做什么?”
2)“为什么要这样做?”
3)“好的做法是怎样做?”
可能你会觉得:靠!这么基本的问题还用问吗?如果是一个传统软件行业,如果在团队中每一个团队
成员都是很有经验的老手,那祝贺你,这些问题就可以省略了,而且可以预计项目成功的可能性是很大的。
但是很多公司的互联网项目团队,总有很多的新成员(甚至是应届毕业生),他们对整个行业并不熟悉,也
没有相关的经验,而且许多的互联网项目需要使用新的技术,新的知识,新的创意,因此也许项目经理
自己或者资深员工很清楚这几个问题,但是真正执行的团队成员要是不能很明确的回答:我在做什么,
为什么要这样做,业界好的做法是怎样的?结果往往是无法真正做好。

    项目的成本管理:对于互联网项目来说,不是所有的东西都要自己开发,对于某些特殊功能的组件
自己团队没有相关的技术人才或者技术实力并且不涉及到核心业务时,应该考虑外包;这样做一方面可以
争取到时间,不会影响总体进度;另一方面,从长期的投入上考虑招聘人员自己做可能成本更高而且没有
延续性。但是核心业务是无论如何不能外包的,在考虑组件外包的时候还要充分考虑外包团队和项目团队
的配合问题,当外包组件越独立,对项目的整体影响就越小。

《Thinking in PM–实战小结》有一个想法

  1. 呵呵 软件工程的管理,看上去好像问题就是这些,但是不同的人不同的角度,看得侧重点也确实不同。
    更赞同上一篇《Thinking in PM-07 互联网产品开发(1)》,我个人的感觉还是流程更重要,也就是你说的组织架构上的要素。只有确定的流程,人员才具备可替代性,降低了人的不确定因素的风险成本;只有能过有效运转的流程,才能降低整个project team的沟通成本;只有更大的有效的公司组织结构流程,才能降低project team和职能化部门间的沟通成本。这里的"成本",更重要的是时间成本。因为一般来说唯一无法撼动的就是时间。
     
    1)“这个项目是做什么?我们在做什么?”
    这个问题我觉得有必要补充一个问号:“我在做什么?”不仅要团队成员清楚团队的使命,也要每一个人明确自己的分工
     
    不知道David有没有看过《移山之道》?有一些朋友推荐给我的,我自己还没来得及看完,据说是讲敏捷开发思想的,值得一看

发表评论

电子邮件地址不会被公开。 必填项已用*标注