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