Hegel2011的博客

读书 - 工作 - 生活 - 笔记

PM培训课程小结

趁着这个集成项目经理培训的五天培训,把辅导材料基本过了一遍。结合一些自己的经验,以及看别人的一些文章,谈谈 自己的想法。

整本培训洋洋洒洒地讲了很多东西,客观的说能全面解析出这样一套体系的人相当的不简单。但是,这套体系应该说还是基于瀑布模型的,只不过 把大瀑布分拆成了n个小瀑布。实际上对软件开发并不太适用。不过因为整套体系认为光有集成是没有自己的竞争力的,要求有30%的软件开发内容, 于是又把软件开发放在里面。这也让我终于明白了工作的第一个部门成立的指导思想来源。因为我曾经相当一段时间纳闷为什么非要把系统集成 和研发凑合成一个部门。而且整个软件组还受集成一侧领导。这样能做出什么好东西来。但现在终于了解了这样组织的来源,而且以集成为主导也是因为这里面 要求软件比例不低于30%。

读了这本材料,终于明白公司是抄自国家认证考试的体系。也可能是其他人这么建议的,而也受了这个认证体系理论的影响。

软件开发有其自身的特点和重点。集成体系用其无所不包、范围够广的方式(9大范围)强行把软件包裹了进去。尽管看上去纳入了,但重点很不突出。 毕竟即使有软件工程也和系统工程是两码事情。所以,这次培训最大的结果是了解集成到底是什么思路,然后就通过这个考试,剩下的也只有自己继续摸索。

先说说集成这套体系。

首先,体系强调章程和计划。章程只有一个,而计划各个领域可以有很多。实际上,计划也是章程。只不过灵活度比章程强,可以按照需要进行 变更、更新,而章程定下了就不怎么更新了。计划或者章程规定了要做哪些事情,什么时候做,相关人员是什么,什么情况下需要变更。 随后就是一堆输入输出的交付物。

接下去的东西就好理解了,反正整个东西追求的结果都是文档。当然,文档确实有很多种,有些方法对保证系统也确实有帮助。 比如需求管理中的use case,每个case其实还是要用文字说明的,case图可以让需求方和系统分析师把东西交流清楚。但本质上就是 一个list,只是说明参与对象是什么。WBS分解,可以用于进一步细化和确认需求,分写出要做的工作。这些都是和软件开发业密切相关的, 但是在此之外,其他的东西实质上和软件的关联就不怎么大了。

最后,就是强调一切东西都要有确认,变更等都要走流程。这些东西如果乙方有能力实施,当然是很好的。

此外,还有一些东西就是骗来骗去的了。比如进度估计、成本估计,实际上即使传统的工程,能准确估算出来的都是很少的。

经典的启动、计划、执行、监控和收尾,又叫做PDCA(Plan Doing Check Action), 典型的普遍模型,自上而下。只是又可以分解成n个小瀑布。 但是,这个真的是软件开发里面最重要的事情嘛?

恐怕不是。

就我看来,软件或者互联网应用更多的强调对自身功能和模块的拆分,启动时往往很难明确细化东西。即使建筑工程本身,也就是这套体系产生的原型, 也有众多管理失败的案例,巴拿马运河等,那么软件对这套系统的适应性恐怕更难。而且这套体系显然没考虑很多项目管理工具的使用,如redmine、如版本控制系统, 而不同的工具或进步的工具是可以颠覆整个开发行为的。条条框框和优秀的软件结合起来会完全改变制造方式。与此相比,管理体系本身就显得僵化。当然,值得吸取的部分还是有的。 比如我们需要一个章程,需要需求的确认。

最最重要的,就是list要做的事情,给出最终时间。WBS后,确认细节,排好顺序,随后和用户确认。

而在这中间,系统的调整能力和团队和用户沟通的软实力才是起决定作用的东西。

Update(2012-05-15): 读了New product Introduction Model的九宗罪 进一步明确了PM这套东西不适合的原因。确实,这套东西适合的是“在有確定用戶,確定市場,確定 bussiness model 的情況下才能使用。也只有在這樣的情況下才有機會成功。” “這很大程度了解釋了為什麼:個人、大公司要『新創』一個事業很容易失敗。而一些『大公司』要『山寨』一個服務也有機會取得成功。”
那么反过来,对于不够明确的、大家都还没谱的、都需要摸索的项目就不合适。
所谓执行是针对有成熟套路的东西,考察的是系统的熟练程度和配合程度。而创新、新业务是需要试错的,其中的核心能力是学习摸索观察勇气

Included file 'twitter_sharing.html' not found in _includes directory