产品经理“人身安全”指南：项目管理理论和实践
下面是小编为大家整理的产品经理“人身安全”指南：项目管理理论和实践,供大家参考。
产品经理“人身安全”指南：项目管理的理论和实践
专家说，在一段关系中如果小心翼翼，那可能就离分开不远了。可偏偏产品经理和程序员这一个“打打杀杀”的组合，分又分不开。
一个段子说，程序员开大会，产品经理还能安安稳稳地坐着，是因为外面有安保。
程序员们只看到了产品经理提需求时候的指指点点、喋喋不休，往往注意不到产品经理面对老板每一个需求都要高优时的抓耳挠腮、面对用户客户提出五彩斑斓的黑时的无奈但还得和蔼的人格分裂、面对用户明知道你就是个卖肉夹馍的非让你卖给他一个热狗时的语言匮乏。
对产品经理来说，如何和程序员和平共处、顺利地推动项目按时完成？如何在加需求、调需求、改 BUG、催进度时不被“暴揍”？如何能避免隔壁工位的程序员不在心里或者行动上给自己带来“人身伤害”？ 做好项目管理，或许能解决这些问题。
一、项目管理简述 谈到如何做好项目管理，先来看看什么是项目。
1. 概念 项目是指为创造独特的产品、服务或成果而进行的临时性工作，项目是为了组织的经营需要与战略目标服务的（PMBOK 指南）。
独特性、临时性、渐进明细是项目的三大特点。
独特性是指每一个项目都是独一无二的，即使是一样的 OA 系统，项目也会因为客户的不同、人员的不同而具有独特性。临时性是指项目有明确的开始和结束的时间，持续的维护是运营的工作，已经超出了项目的范畴。渐进明细是指项目的成果性目标是逐步完成的，项目前期只能粗略定义或整体定义，需要随着项目的进行逐渐完善和精确。
项目管理，是将知识、技能、工具和技术应用于项目活动，以满足项目要求（PMBOK 指南）的工作。
2. 项目管理要解决的问题 项目的 3 个特点，阐明了项目是一个有始有终、独一无二、逐渐完善和推进的过程。尤其是项目的渐进明细也是在说项目是变化的，变化就意味着项目具有不确定性，存在风险，这也就是之所以需要项目管理的原因。具体来说，项目执行过程中的风险会有以下：
1）在项目启动和规划时 如何鼓励相关方、尤其是客户和高层参与项目的计划与决策，确保项目结果符合他们的预期？
如何引导相关方就目标达成一致？
如何获得相关方包括客户、高层、项目组人员对项目的承诺，确保提供必要的支持？
2）在项目执行过程中 如何及时掌握项目的进度和状态、确保项目按时交付，而非在即将结束时才发现项目要延期？
如何对需求的优先级进行排序，协调好不同相关方、不同需求之间的冲突？
如何应对来自客户、高层变更要求，以及项目团队改变方案和进度等的诉求？
如何解决项目人手不足、资源匮乏的问题，或者资源可使用情况发生变化的情形？
如何在问题和风险产生式，推动相关的调整和整改落地？
3）在团队建设中 如何提升团队的沟通、协作与配合？
如何建立互信、尊重、有责任感的项目团队文化？
…… 如何去解决这些问题，项目管理的相关理论划分了十大知识领域，涵盖了项目管理的方方面面：整合管理、范围管理、进度管理、成本管理、质量管理、沟通管理、风险管理、相关方管理、沟通管理、采购管理。
3. 项目管理 4 种类型
如何把项目管理的十大领域组织起来，建立恰当的管理流程和体系？项目管理理论也提供了 4 种项目管理生命周期的类型（PMBOK 指南）：
以一个布置和完成暑假作业的例子来具体来体会一下这几种类型：
1）放暑假了，数学老师一口气布置完了所有的暑假作业，开学的第一天按时交，过程中老师不会检查——这个是预测型，也叫瀑布型，最终开学你交了作业就可以。
2）放暑假了，语文老师留了一篇作文，要求你先选题，交给她看了、确认了之后，再列提纲，提纲她也得检查和修改，然后你再写成作文，并且修改到她认为符合标准——这个是迭代型，中间需要反复检查修正，但只有最后一次她确认了的作文才能算你的作业。
3）放暑假了，英语老师说作业她每天早上 8 点发在群里，晚上 8 点得完成——这个是增量型，每天布置的作业就是给定增量，每天交作业就是交付。
4）放暑假了，科学老师说，每人做一个有新意的科学小发明，他每两周周检查一次，你决定做一个遥控汽车；于是第一个两周你的汽车成型了，老师看了还行但是建议你把车身做大一点以便放进更大容量的电池。
第二个两周你的车身放大了车也能遥控跑起来了，老师说现在你的车只能往前走，需要包含倒车的功能，现在别的做遥控汽车的同学是水陆两栖的方案，你可以加上飞行的功能，有新意又不雷同…… 如此不断调整，到开学你交的作业，是一辆超长续航、能直走转弯后退、车门不仅长得像翅膀还能像翅膀一样带着车飞、具备了摄像功能、自带GPS 定位的遥控汽车——这个是敏捷型，原始需求是粗略的，每次给老师看的都是成型的作品，不断朝着有新意的目标在调整交付。
选择哪种类型的项目管理方法，取决于项目的特点和目标。就像上边暑假作业的项目：
数学老师希望你在暑假期间进行了练习就可以，要求的是总量；
语文老师希望你完成一篇优秀的作文，会通过过程的监管要求质量；
英语老师希望你每天练习一点，确保英语的语感和保持持续学习的习惯；
科学老师希望你不断突破创新，提升创造力。
从上述 4 种类型的对比中也可以看到，预测型和敏捷型是 4 类中的两个极端。
在实际的应用中，预测型的项目管理方式适用于需求明确、产品清晰、不需要变更、需要整体交付的行业，如建筑、制造、通信、能源等等。敏捷型的项目管理方式适用于速度变化快、复杂性高和风险高的行业，敏捷的诞生，就是基于软件行业的管理需求，去满足组织能够快速产生满足市场需求的产品，通过灵敏的调整保持竞争力和占有市场份额的需求。
既然敏捷是随着软件行业的兴起而诞生的，早在 2006 年左右，敏捷就被引入中国，且有大量企业进行了敏捷实践。那在互联网行业的项目管理中，是否可以直接选择敏捷的项目管理方式？
这可能需求打个问号。产品经理如果对着开发同学说，我们要敏捷，要应对变化，所以这个需求得改一下——这句话说完，你可能就把自己置于了一个十分危险的境地。
“知己知彼，百战不殆”，想要管理互联网项目，还是先看看互联网项目的特点。
二、浅谈互联网项目 1. 特点 与传统行业相比，互联网是轻资产的行业，投入的主要是人力资源，试错成本更低，鼓励创新，走了弯路只是消耗了一些人力和时间；同时，互联网产品开发成本低，不存在物料的消耗，产品的迭代更新速度快、市场竞争激烈；在用户层面，互联网和用户拥有更高的互动性，可以根据反馈实时调整产品。
互联网的项目管理，由于行业、产品和用户特征，具备以下 3 个方面的特点：
1）节奏上，“小步快跑、快速迭代”是大多数互联网项目的共识。
风口的瞬息万变、市场的迅速抢占、竞争的分秒必争都要求互联网的项目需要快速推进、实时反馈和迅速调整，要勇于“拥抱变化”。
那在项目的节奏上，就需要尽快上线可用的产品，不断在适应和接收的反馈中迭代，以最小的成本和有效的方式验证产品是否符合用户需求，灵活调整方向。
例如小米的 MIUI 系统，操作系统每周更新，根据米粉的使用意见快速调整，第二个周五再推送一个新的版本，如此往复，几乎从不间断。这也是此前很热门的概念“互联网思维”的内涵之一。
2）周期上，互联网的项目往往和运营分不开，这里的运营不是指用户运营、内容运营、活动运营等，是指产品本身的运营。
项目是临时性、独特性的工作，而运营是持续的、重复性的工作，而在互联网团队中，项目往往是不断迭代的，交付一个版本后，产研团队不仅要专注于后续版本的开发，也需要解决之前的版本中遗留的问题，甚至是进行使用答疑，在执行时间上，项目时间和运营时间也没有办法完全割裂而往往是并行，甚至解决线上问题（运营）的优先级是高于开发新的版本（项目）的。
3）人员上，首先是项目经理这个角色，很大情况下由产品经理充当。在互联网行业，往往是针对跨部门的大项目、或者是面向企业用户（TO B）的业务，才会有项目经理的岗位，而众多的面向 C 端的业务、面向企业内部的产品和服务、部门或者小组之内的项目，是不会有专门的项目经理的，产品经理需要同时承担起项目经理的角色，推动流程和进度。
其次是项目的成员，尤其是开发人员，同时参与多个项目、或者如上一点所说的那样，即负责开发又负责运营，也是常态。
同时，不同角色的开发人员，前端、后端、算法、测试、运维、质量等，分属不同的组或者部门，是再正常不过的现象。虽然项目管理本身就需要协调项目人员所属的职能部门与项目之间的关系，但互联网行业这种产品经理要承担项目管理的工作但往往没有明确授权、项目参与人员所属职能部门繁杂的情况，也是独具特色。
2. 互联网项目管理要解决的问题 传统的项目管理要解决的问题，互联网的项目管理中也会遇到，那个性化的问题会有哪些呢？用“互联网”的语言，来转化一下互联网项目管理中、产品经理需要聚焦的问题：
文档，写不写？需要写哪些、需要多详细？
需求，变不变？变更对已经完成的工作和排期造成影响如何处理？
排期，延不延？需求不能按时完成怎么办？
规划，做不做？需要做到什么程度？
决策，早或晚？尽早做决策、方便制定方案，还是尽可能晚做决策、应对变更？
相信回答好这些问题，并且就问题的解决办法与开发同学达成一致，产品经理就可以和开发同学建立一段平等的关系，开启安全系数高、甩锅扯皮少的幸福工作时光。
当然作为一名产品经理，你可能还会有其他的问题，包括我需要做一个什么样的产品？产品是否有市场竞争力？是否能满足用户需求？是否能为公司带来收益？… … 等等的这些，并不在我们项目管理的讨论范围之内。项目管理是提供“正确地做事情”的方法，而上述这些问题，是“做正确的事情”的范畴，需要在 OKR / KPI 制定环节去解决。
下文所有的讨论，也是假设你已经知道做什么了，只是需要知道怎么做，来展开。
基于互联网项目的这些特点，哪种生命周期类型更适合产品经理去进行项目管理呢？ 三、互联网项目管理范式选择 1. 预测型生命周期管理与敏捷型生命周期管理 预测和敏捷是 4 中项目管理类型的两端，不妨就以这两种类型展开讨论。选择预测型还是敏捷型的项目生命周期管理类型，再来对比一下预测和敏捷的区别：
预测型和敏捷型的项目管理方式，在需求是否固定、执行次数、交付次数、目标方面都有差异。如何选择需要在上述几个维度都进行考量，但根本的还是要从需求入手。从需求的不确定性、交付的不确定性——即技术程度的不确定性两个方面去构建（敏捷实践指南）坐标，得到如下模型：
需求和实现的技术如果不确定性较低，使用于线性的方法——比如预测型；如果两者的不确定性都较高，那可能就是一个混乱的项目，需要重
新评估捋顺；如果都是一个居中的水平，可以用自适应的方法——比如敏捷型。
预测和敏捷在项目管理中的区别，从《敏捷宣言》中就可明确知晓：
我们正在通过亲自开发和帮助他人开发，发现开发软件的更好方法。通过这项工作，我们开始更重视：
个体及互动而不是过程和工具
可用的软件而不是完整的文档
客户合作而不是合同谈判
应对变更而不是遵循计划
也就是说，右栏的项目固然有价值，但我们更重视左栏中的项目。
简言之，敏捷对过程和工具、文档、合同、计划的关注程度，是低于互动、成果、合作和变化的。敏捷拥抱变化，在需求不明确的时候，在较短的周期内开发出可用的产品，帮助明确需求和调研市场，这也就是产品开发过程中的 MVP（Minimum Viable Product，最小可用产品）概念。
但同时，敏捷并不意味着随意和无序。在敏捷实践中，也存在着诸多的框架，如精益、看板、水晶、极限编程、Scrum 等。
虽然从理念到流程上，敏捷和预测的项目生命周期类型存在诸多差异，但既然都是项目管理，两者都符合“知识、技能、工具和技术的应用”的项目管理概念。即使敏捷对流程和文档进行了诸多的裁剪，关键的控制还是必不可少的。例如不重视文档不代表没有文档，必要的文档如产品需求文档，还是要有的。项目管理的 5 大过程组和 10 大知识领域，两者都会覆盖到。
预测型项目与敏捷项目中的 5 大过程组：
整合管理、范围管理、进度管理、成本管理……等 10 大知识领域，在预测型的项目管理中，有完整的输入、输出文档，使用的工具和技术。敏捷项目同样离不开这 10 个领域，但关注的重点有所不同。
敏捷在 10 大知识领域中的应用：
2. 范式的选择 那互联网的项目管理到底是选择敏捷还是预测？ 前面部分也分析过，互联网的项目有 3 大特点——节奏上的“小步快跑、快速迭代”、周期上的开发与运营兼顾、人员上的非项目制团队，基于这些特点，适用预测或敏捷，都存在一些障碍。
节奏上的特点——需求的不断变化和快速的迭代，是使用预测型项目管理方式的障碍，敏捷比较能适应这种节奏。而周期和人员上的特点，两种管理方式好像都难以招架。
在实践中，很多公司的项目开发会选择用看板管理故事点从需求到上线的过程，看板、用户故事，其实都是敏捷中的工具。还有一种比较常见的互联网产品开发管理流程，从调研到评审、设计、开发、测试、上线，再逐一版本进行迭代，很多情况下是在对传统的预测型流程进行大幅度裁剪的基础上，视情况混合敏捷理念的管理体系。
互联网产品的项目管理，混合可能是常态，完全的预测型或者完全的敏捷，也有一些适用场景。预测和敏捷最根本的差别，是需求是否明确，需求能否明确的原因，是项目追求的价值。
如果项目的目标是按时上线，那可以用预测型的方法，对过程进行严格的管理。而需求存在变更可能性的项目，不应该以按时上线为目标，而是要追求业务价值的实现，顺应变化适时调整，才能做到随价...