最近这两天,受公司委派,参加了一个项目管理方面的培训。本来以为是和自己上的研究生课程一样,老师会像填鸭一样大讲一通,结果上了之后才发现,老师讲的不错,而且人有感染力,课堂的氛围也好,两天的时间过的很快,自己带去打发时间的scrum书也没了用武之地。现在乘着眼熟,把一些讲义、笔记、感想记下来,免得忘了。
由于时间紧凑,有的东西老师并不是讲的很细,可能我也只是记了流水账,如果有人感兴趣,咱们可以再聊。首先这个讲座,并非是针对IT行业或者软件开发所作的讲座,而是面对项目管理的讲座,我们20个人也是来自不少行业,同组的5个人里,就有两个北京来的、做药品研发的管理者。
培训的开始,看了个所谓的案例,结果就是段动画,大概5分钟,形式不错,内容无非是说,项目要适应市场需要、项目团队要紧密合作、打破部门鸿沟、项目要有控制和管理等等。我觉得算是一个引子吧,起码将比较枯燥的内容用一种比较轻松的形式来展现。我觉得一个讲座、一门课,老师的感染力很重要,我同时也在读一门研究生的课程,对比一下,很多学校的老师在课堂上真的是很枯燥,咱们的大学教育,是否要反思一下……
项目任务书
在项目启动的时候编制,老师认为,项目启动书,老师认为项目启动书中包含市场+技术的内容,可能包含技术难点的分析。这点我之前做的立项报告中是没有的。不过说白了,项目任务书就是忽悠领导的,但是它也可以细化到“项目业务计划书”,继而细化到项目合同书。这里有个变化,合同书是准确且严格的。由于我们是做产品的,所以我也没和别人签过合同书,我估计这里的准确应该是说时间、资源,而不是说一些细节的系统指标。
项目团队
项目经理
什么是真正的项目经理?这个问题当时我愣住了,老师给的答案是:“满足客户、市场需求”,突然觉得和敏捷中“可工作的软件比面面俱到的文档更重要”这句话异曲同工。mpp做的好的,不见得是好的项目经理。
项目经理的培养
项目经理的需要的能力,已经有很多的总结,什么领导力、沟通能力、学习能力、导向性、监控力、影响力、灵活性等等,这里不多赘述,我们说一下项目经理的培养。除了体系的驱动与牵引外,为了保证项目不变的固执、对市场、业务缺乏了解,项目经理需要到周边部门锻炼,提高全流程意识和技能。由于我负责的项目的特点,这点很有感触,如果不了解业务部门的流程、业务员的使用习惯,我也带不好这个项目。因为项目经理握有权利,如果他的见识有偏差,其权利会使项目偏离用户、市场的真正需求。
这里老师举了其曾经去过的某品牌手机做培训的例子,说其项目经理会轮流去做业务员,有人在卖自己领导设计的手机时,被骂的狗血淋头……
项目秘书
这个词我觉得挺新鲜,但其实团队中有人做了。项目秘书的首先可以做很多“杂事”,解放项目经理和专业的技术人员,使其有精力从事项目中的专业活动。试想一个项目经理如果每天忙于写会议记录,处理日常事务,还能有多少时间做管理。而项目秘书可以在多个项目中兼任,由于其了解项目的整个过程,并在很多事情上参与,这样的人做的好,往往可以做项目经理。
在我们项目中,需求分析人员多数情况下充当了这个角色,做协调、会议组织、记录等,对其的锻炼也有不少,如果有一定的管理能力,确实可以做项目经理的后备人选。
组织模型
项目团队的组织模型有:职能结构、研发项目团队结构、跨职能团队结构、纯项目团队结构。
在这四种模型中,职能结构无法协调各个职能部门,无人关心产品成败;研发团队结构中的项目经理就像个协调人,无法做出关键决策并施加影响;纯项目团队结构中往往对技术人员的成长关心的不够。而跨职能团队结构比较理想,项目经理关注产品过程,拥有项目的领导权,影响力大;职能部门经理关注资源建设和人员培养,这种双向管理有优势,但要解决以下几个问题:
- 双向管理的难度大,公司文化是否可以跟上。
- 职能部门和项目组的权责划分是否清楚。
- 项目组成员是否可以全身心的投入到项目工作中。
沟通的重要性
谈沟通的时候,老师也举了个例子,同样的公司,同样的团队领导者,在人少的时候,项目执行时高效的;当项目成功后,人员扩充,再进行下一期项目时,执行的效率反而低下了。其原因是,当项目组人少时,往往一个人身兼数职,沟通的成本低;而人多了之后,虽然各司其职,但是沟通的成本上升,效率反而低了。如何有效沟通?这里给出的一个模型。
![](/qrcode.jpg)
需求
- 最好两人或以上去做需求,一个谈,一个记。最好不要录音,因为基本没人多数人去听,尤其在录音很长的情况下。
- 不要让客户帮你去做需求分析。这里举了一个例子,一张照片,这里说的是福田汽车的客户要求其在邮箱盖板上加了把锁,问为什么,客户说怕被偷油。这里客户的需求是“防止偷油”,而不是“加把锁”——客户帮项目组做了需求分析,冰直接给出了答案。这个例子的结果,是福田在油箱盖板上下都加了锁。
- 对于同类的客户,最多调研12-15个即可,可以获取约90%的需求——此为经验值。
- 外部需求:可获得性、功能性、易用性、生命周期成本等,不一定每一条都要做的很好。
- 需求评审的目的:找到问题、风险评估、需求跟踪、成本跟踪。
- 需求要有编号规则。
- 做“领先型”的需求:帮客户做规划。