前言1：
我本是一个创业失败者，放下曾经所有的不切实际。告别深圳，来到惠州从最底层的程序员开始，效仿自己10多年前从头来过，
入职在这一个八千人的制造业公司中，发现这里的同事关系都是清淡的，甚至直接领导和下属也是清淡的。
回想刚入职那会我就默默在那写代码，哪怕这只是一个三十人规模的技术部，我入职2个月了总监都没跟我单聊过一次，这就是大公司吧。
记得有一次，晚上9点了。由于项目第二天要上线，我还在那加班，总监刚开完会出来，看到我一个人在那。我以为他回过来体面的问候我一下，比如说一句：“怎么还在加班，遇到什么困难了？”
然后只是瞅了一眼，就回自己办公室了。背上包从办公室出来，直接走了。那一刻我怒了！
我觉得领导看不见我，心里默想：“你不是看不见我吗？我就让你看见一下”。
虽然说从头开始，可是打心里还是有那一股子傲气。工作十年，五年开发，四年管理，一年创业。十年工作经验的我哪怕是从头来过，再爬上去我也不可能又要花10年。
后来就有了《手把手撸套框架》这个系列的博客。在部门内部组织了一次非常成功的培训，Victory框架被部门称“开发框架1.0”。
这也是制造业不像互联网那样重视技术部门，导致技术部门同样不重视开发。让我抓住机会好好秀了一把，在培训会上我直接说我觉得我可以担任架构师。
后来，领导经常叫我去办公室，谈各种话题。有技术的，有管理的，也有指导我很多。 最后他没让我当架构师，却让我当了“项目经理”。
确实，比起开发技能，部门的项目管理几乎是一塌糊涂。毕竟七分业务，三分技术。随后我从项目经理，一直往项目集经理的路线发展。这就是我想写《项目经理指导手册》的原因，等同于制定一份项目经理的“开发框架”。
前言2：PMP只是一本字典
我是2015年考的PMP，在我刚做管理的时候，那会没人教我技术部应该怎么管，我经常逛博客园看文章，有看到一个作者写的《从程序员到项目经理》的系列文章（这哥们还出了书），其实这个系列对我帮助没多大，只是让我知道了有PMP
这个东西，去培训了，也考证了。PMP似乎是所有项目经理，必考一个证，在很长一段时间里 我觉得PMP 没什么卵用。 PMP是把所有的活动都去理解成一个项目进行管理。也就是说无论你造桥，修路，盖房子。读可以去套用PMP。都是启动，规划，
执行，监控，收尾，这个五个基础过程。 都是“范围管理、整合管理、进度管理、成本管理、资源管理、风险管理、质量管理、沟通管理、采购管理、相关方管理。” 这就活脱脱的一本字典，没人照着字典写作文吧。 真按PMP去做项目一会完蛋。。
很可悲的事情是，软件行业很长一段时间的管理模式都是平移自建筑业、制造业。软件行业有他的特殊性，就拿需求变更来说，造桥，修路不可能造到一半突然改方案，软件行业就会，而且很频繁。造桥修路来不得一点质量问题，否则就是一场人祸，
但软件行业可以不断升级，甚至重构。
所以，一次成型，资源无限很多情况只存在理论当中。当然我的理解也会有一定的片面，这个我必须承认。因此，我也认为认为 自研项目的话，采用“瀑布模式” 的适用场景同样非常少。
前言3：瀑布与敏捷
瀑布与敏捷，本身没有孰优孰略。 也不想网上说的敏捷比瀑布快， 这个本身不存在的。只是两者在理念上有所不同，瀑布要求的是 “全量交付”。而敏捷是“增量交付"。 而且，敏捷占用资源更多，还要求是优质资源。
对于人员的管理要求也不一样，瀑布的管理模式 项目经理指导，而敏捷是要求员工有自驱力，能自管理。 这个难度上其实比瀑布难多了。
为此，我特地去考了一下《Scrum敏捷项目管理》 也拿到了 “Scrum Master” 的证书。 总体感觉就比实行PMP 或者 瀑布，自在多了。
===============================华丽的分割线==============================================
以下内容是我 在这现在任职公司 做项目经理之后，对部门软件项目管理改善后的指导内容。90%的思想是基于“Scrum” 的基础，结合了一点 “OKR” 的理念 演化而来。。
所以，不具备 “通用性”，在这里写成博客除了把自己的 想法做一个记录以外，也是为了将规范化，后期在新人培训上能减少一些沟通成本。
另外，也是一种经验积累，持续维护这份文档的话，这能成为我行走江湖的一招半式。
===============================华丽的分割线==============================================
《项目经理指导手册》
开篇
《项目经理指导手册》是我根据入职公司以来阅读的《OKR工作法》、《Scrum实战指南》两本书的思想总结，经过多个项目实战的检验和不断完善，自我感觉可以将其固化下来成为一个
项目经理工作的通用方法。现代软件行业的高速发展对项目经理的要求越来越高，不仅仅是需要掌握瀑布模型，PMP、敏捷 等等项目管理手段，更需要项目经理以此为基础结合工作场景做出灵活性管理。
因此，手册中对针对，调研、工具、角色、会议、需求、任务、测试 等多个维度进行规范。
手册的愿景是，降低项目经理门槛，提高项目交付能力。无规矩不成方圆，无规范难以协同。对于项目经理来说适当的规范和标准不是要去消灭项目经理的创造性，而是要将项目经理的行为标准化，降低
沟通与管理成本。以一种普遍的方式形成共识。 基于共识一起工作，提升协作效率，尽可能的少踩坑，杜绝重复踩坑，切实提升项目管理能力，做出好项目。
一、成员篇
（1）规模，美国CHAOS协会，做过一个调查。得出一个结论。敏捷团队人员规模，10人范围内人数和效率是正比上升的，12人以上的效率曲线是下降的。所以在Scrum提出合理人员规模应该在： 7±2 人。
即最小团队位5 人。 最多为9人。 （敏捷也有大规模支撑方案：SAFe，但是不适用我们这种场景。）
（2）角色，我们在软件项目中会听到各种角色：项目经理、需求分析师、产品经理、程序员、架构师、测试、UI设计师等等。在Scrum中只有三种角色：
1，Scrum Master 敏捷教练，保障敏捷正常进行。
2，Product Owner 产品经理，驱动产品成功。
3，Developers 开发者，开发软件，负责交付成果。
这种模式，下没有项目经理，Scrum Master 职责是保证项目按敏捷模式不偏离方向的进行下去。Scrum Master 没有权力，更像是一个保姆。
我们在实际项目中，很难在客户那里解释自己是Scrum Master。
所以，在角色分工上，我所处的制造业信息化项目，角色上进行了一些结合。如下：
1，项目经理：项目中拥有权力，把握项目方向，负责项目中的管理事务，结合PMP五大过程组，十大领域，对项目进行管理。
2，产品经理：设计产品，规划产品交付优先级。担任业务方和团队之间的桥梁。结合
3，实施工程师：推进产品落地，负责培训，指导用户使用系统。项目一线作战员，解答用户问题，收集并反馈用户需求和问题。
4，测试工程师：保障项目质量，编写测试用例，执行软件测试工作，包括不限于，功能、流程、性能、安全测试。 项目质量的守门员。
5，开发工程师：软件开发，根据设计文档编写代码；根据设计文档编写单元测试代码，按需求交付软件。
这里，有一定的局限性，一般还有UI设计师，但是工业互联网，都是各种系统类型的项目，所以，几乎没有美工方面的设计。
前面说标准团队的成员是7人正负2人， 这里就占了5个角色了。我定义的比例是： 1:1:1:1:3 （开发3人）
在我们公司，由于设定了一个经营管理部的独立部门，由这个部门负责信息化战略规划。所以，关于企业上线什么产品，要做什么功能，其实是他们部门决定了。当然，他们不是业务方，也不能把他们理解成客户。
这里，经营管理部，理解为产品经理的职能部门。
（3）复合。敏捷中讲究T型人才，一专多能。我们也之为复合型人才。项目中，我们不一定能真的把 项目，产品，实施，测试，开发，按比例给配齐了。往往是“缺胳膊少腿”的, 但是工作和流程却不会因此减少。
因此，往往我们需要变通，我觉得几个角色中，是岗位缺失的情况下，是可以切换或短时间兼任的。
1,项目经理 <=双向=> 产品经理
2.测试工程师 <=双向=> 实施工程师
3.开发工程师 =单向=> 测试工程师
4.开发工程师 =单向=> 实施工程师
直接切换或兼任的情况，一定只能短时间应急，规划的五种角色是项目中必须的角色，没有哪个角色是可要可不要的，兼任一时可以，长期就会造成两头 都做不好。职责分离是团队协作的基础。再次强调，不是万不得已
不要用这种方式去执行项目工作。