产品经理“人身安全”指南：项目管理的理论和实践
专家说，在一段关系中如果小心翼翼，那可能就离分开不远了。可偏偏产品经理和程序员这一个“打打杀杀”的组合，分又分不开。
一个段子说，程序员开大会，产品经理还能安安稳稳地坐着，是因为外面有安保。
程序员们只看到了产品经理提需求时候的指指点点、喋喋不休，往往注意不到产品经理面对老板每一个需求都要高优时的抓耳挠腮、面对用户客户提出五彩斑斓的黑时的无奈但还得和蔼的人格分裂、面对用户明知道你就是个卖肉夹馍的非让你卖给他一个热狗时的语言匮乏。
对产品经理来说，如何和程序员和平共处、顺利地推动项目按时完成？如何在加需求、调需求、改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大特点——节奏上的“小步快跑、快速迭代”、周期上的开发与运营兼顾、人员上的非项目制团队，基于这些特点，适用预测或敏捷，都存在一些障碍。
节奏上的特点——需求的不断变化和快速的迭代，是使用预测型项目管理方式的障碍，敏捷比较能适应这种节奏。而周期和人员上的特点，两种管理方式好像都难以招架。
在实践中，很多公司的项目开发会选择用看板管理故事点从需求到上线的过程，看板、用户故事，其实都是敏捷中的工具。还有一种比较常见的互联网产品开发管理流程，从调研到评审、设计、开发、测试、上线，再逐一版本进行迭代，很多情况下是在对传统的预测型流程进行大幅度裁剪的基础上，视情况混合敏捷理念的管理体系。
互联网产品的项目管理，混合可能是常态，完全的预测型或者完全的敏捷，也有一些适用场景。预测和敏捷最根本的差别，是需求是否明确，需求能否明确的原因，是项目追求的价值。
如果项目的目标是按时上线，那可以用预测型的方法，对过程进行严格的管理。而需求存在变更可能性的项目，不应该以按时上线为目标，而是要追求业务价值的实现，顺应变化适时调整，才能做到随价值而变。
一些交付型的项目，如面向B端企业的软件系统交付，尤其是一些传统行业的信息化、流程管理系统，项目承接的是甲方的需求，产品和研发团队作为乙方，基本适用于预测型的管理方法。
业务支撑型的项目，尤其是新业务的探索，需要在激烈的市场角逐中获得竞争优势，如开发一个元宇宙社区，那项目的推进可能就需要敏捷起来。
这个项目有着激进的时间限制——早一天有可用的产品就能早一天抢占用户、有着较高的新颖性——产品形态需要不断探索以深挖用户需求、有一定的技术复杂度——涉及5G/通信/云计算/区块链/VR/AR等诸多快速发展中的技术的综合应用，此类项目就适用于敏捷型的项目管理方式，拥抱变化是必要且能获得最大价值的。
大多数的互联网项目，不完全符合以上两种绝对的场景。毕竟，做软件交付和探索新业务只是行业内的少数，大多数还是已经发展中的项目，需要维护，但又没有创新那么时间紧急。如何综合敏捷型和预测型项目管理的理念和工具，拥有一套适合产品经理进行项目管理的方法论？在下一部分，提供一种实践。
四、项目管理实践
想要和写代码的同学“相谈甚欢”，维护“其乐融融”的合作氛围，每一次迭代都“功德圆满”，产品经理不仅需要写得一手好文档，更需要于“润物细无声”处管理好项目。产品能力和项目管理能力，两手都要抓，两手都要硬。方案写的再好、没能按时上线，那也是纸上谈兵；方案一塌糊涂，项目管理就注定困难重重，即便是磕磕绊绊上线了，其中的扯皮和后续的反复不然不会少。
项目管理怎么做？预测型和敏捷型的项目管理方法如何综合利用？这里提供的这一实践，不妨称其为“理念敏捷、过程可控”。
1. 理念敏捷
敏捷是为软件行业而生，在理念上也很贴合互联网的实际。再回顾一下敏捷宣言：更重视个体及互动而不是过程和工具，更重视可用的软件而不是完整的文档，更重视客户合作而不是合同谈判，更重视应对变更而不是遵循计划。敏捷管理的目标，是通过尽早持续交付有价值的软件来满足客户的需求。在理念上的敏捷，可以从以下几个方面入手：
态度上，拥抱变化。
这个变化，包括市场的变化、需求的变化、项目过程中的变化，甚至是人员的变化，将变化视作常态，不惧怕变化。
拥抱变化不是一句口号，而是基于完善的应对方案的底气。面对变化，在方案设计时，产品同学需要对所有的情况充分考虑，选择最适合当时需求的方案，但也要对后续的调整有充分的认知，在变化发生时能灵活地应对，接受来自技术同学的“挑战”——他们是不喜欢变化的，需要有足够分量的理由去说服。对变化的应对需要做好变更管理，对变更有清晰的记录，方便回溯和应对人员变化的情形。
团队建设上，透明、沟通、共建。
不仅是为了提升效率，也是让团队成员获得参与感和体现价值感。除有特殊保密需求的项目外，产品和项目所有的信息应该是团队内透明共享的，消除权限管控的隔阂，方便实时获取，也是让各个角色的同学从前因后果、前后左右去完成各自的工作。
沟通上，因为变化无处不在，充分的、频繁的沟通非常必要，一定要鼓励团队成员在发现问题的第一时间和相关人员沟通，所有的不清晰、不确定都在第一时间澄清。共建不仅仅是共同完成项目，更是共同承担责任，产品出现问题时，积极解决、重视复盘，不互相推诿。
做到透明、沟通、共建，离不开一些工具的应用，如利用线上文档分享信息，通过固定会议和随时的响应促进沟通，利用投票、头脑风暴等工具进行团体决策，组织定期的团队内知识分享加强交流等。
目标确定上，价值为导向，通过经常的交付不断实现价值。
将项目的目标定义为实现业务价值，就不仅仅是要求按时完成，而是注重效果，必要时甚至可以牺牲时间。
价值实现应该成为团队内部共同的信仰，成为何时交付、如何交付、是否接受变更的依据。不断实现价值，在互联网的项目中可以通过不断的版本迭代来实现，通常的迭代周期2-4周，最长不超过6周，太长的周期也会放大延期的风险。越早交付可用的版本，就能越早去验证市场需求和业务逻辑，更灵活地应对变化，为业务获得竞争优势。
2. 过程可控：基于5个过程组的流程和工作项
过程可控体现在两大方面。一是对于变更，尽管我们强调灵活，但要控制迭代周期之内的变更，尽量放到迭代之间。
在规划最新的版本时，需求是否已经明确应该作为优先级排列的依据之一，还需要细化的需求可以放到后续的版本。在版本开发的过程中，尽量不插入新的需求，避免影响现有的开发节奏，如果一定要插入，需要明确是延长上线时间、还是增加资源去完成，项目的整体节奏要相应调整，所有变更及时和成员同步。
过程可控的第二个方面，是有完善的流程，从启动-规划-执行-监控-收尾的5大过程组入手，来拆解一个完善的互联网项目管理流程需要的环节：
启动阶段——全思量、严论证，通过全面的考虑和严格的论证，为后续的工作开一个好头。
具体有两个环节，调研和立项。通过充分的调研，建立对市场、用户、竞品的全面了解，阐明是什么、为什么、怎么样的问题，调研的结论是立项的依据。在通过立项评审、成功立项后，产品就可以进入规划阶段，其实在多数情况下，启动阶段已经完成了一部分规划的工作，不过启动阶段的规划，多是宏观层面的预期的业务目标、大的产品发布节奏、技术和产品架构等等。
在进入规划阶段前，如果是涉及到跨部门合作的项目，建议组织一次开工大会，拉齐所有关注项目、参与项目的人员的信息，获得后续支持项目的承诺。
规划阶段——远规划、注细节，进入规划阶段，其实项目也就正式开始了，“凡事预则立，不预则废”，一个好的规划，应该是“十”字型的，既有横向的长周期内的完整规划，对项目的最终形态有设想，也包含了纵向的近期即将开展的工作和细节。
这两部分对产品同学来说，对应两个流程的工作：产品路线图的设计，和具体版本的产品文档的输出。
产品文档作为后续设计、开发、测试等环节的工作依据，需要细节完整、描述清晰。完成了产品文档，就可以组织需求评审，需要全部相关同学参加，在评审会上提出产品和实现层面的相关问题，探讨解决方案。
文档的完善和评审可能是一个多轮循环的过程，除了产品方案评审外，还涉及到设计图评审、技术评审、测试用例评审，由对应岗位的同学完成，产品经理协助组织评审会议。
评审会上确认后的各类文档，可以作为排期的依据。如前文提到的，互联网项目的参与人员往往是跨团队、非专职，排期时，需要考虑到各个角色的可用时间、完成每个任务需要的工时，将突发情况充分考虑进去。
例如，前端同学完成这个版本需要5个工作日，但他同时负责多个项目，在本项目上的精力是50%，那前端需要的开发周期就是10个工作日。如果是涉及新技术或者有技术难度的项目，可以用三分法来预估时间：最快时间、最可能时间、最长时间，得出最终需要的时间。最终的排期可以绘制成甘特图，预期和实际完成的时间用不同颜色表示，清晰地显示进度。
执行阶段——少变更、多关注，这6个字是送给产品同学的“6字箴言”。
执行阶段的主要工作是设计、开发和上线，产品同学的主要工作是跟进进度，发挥项目管理的职责，沟通协调，同时在需要时去给各个环节的同学阐释需求。这个过程中，不建议对各岗位专业领域的内容进行过多的干涉，例如手戳设计师的屏幕，质疑程序员的代码不够完美，都是不推荐的、有损“人身安全”的高危行为，要对大家的专业能力有基本的信任。
在进度的跟进中，应该注意跟进的节奏，把控好关键节点、又不过于频繁，应该重视执行过程中的问题，要求大家在风险发生的第一时间同步，以便及时探讨解决方案、判断是否要调整原有的需求或排期。
监控阶段——重质量、担责任，重质量是对质量的重视，担责任是产品同学也要为最终结果负责，而不仅仅是测试、质量等岗位的同学的工作。
质量意识应该贯穿整个项目的始终，从规划时对质量标准的设定、测试文档的撰写，到执行中为满足质量标准进行的工作，以及监控环节的质量控制和测试。
监控阶段的工作和执行环节是交叉的，开发完成后需要提测，测试环节中发现的问题需要修复直至通过测试。整体的监控阶段的工作是需要全部角色参与的，开发先自测、再提测，测试人员通过后，产品进行验收，而且建议上线前后分别在测试和线上环境双重验收。
收尾阶段——有始终、控节奏，完成上线并不是一个版本的项目工作的结束，收尾的工作包括向业务部门交付上线的版本，更新相关的使用文档，此外还要对整个项目进行复盘，项目周期较短的可以简单总结，回顾产品和项目执行中的问题，提出后续的改进方案，不断完善产品和开发流程。
此外，按照互联网产品逐个版本迭代的节奏，这个版本的收尾意味着下一个版本的开启，控制好中间的衔接关系，适当预留时间等待业务和用户侧反馈问题、决定是否在下个版本优先处理，有时候是非常必要的。
如果此前的多个版本因为需求变更、周期紧张等原因，导致技术实现方案不够完善，可能影响后续的使用，也建议在版本规划时，在需求的节奏不那么紧张的情况下，适时考虑偿还技术债，将此纳入新的版本规划甚至安排独立的版本完成该项工作。
3. 回看互联网项目管理的5个问题
介绍完了流程，再回头看之前第二部分，产品同学可能困惑的互联网项目管理中的5个问题：
- 规划，做不做？需要做到什么程度？
- 决策，早或晚？尽早做决策、方便制定方案，还是尽可能晚做决策、应对变更？
- 文档，写不写？需要写哪些、需要多详细？
- 需求，变不变？变更对已经完成的工作和排期造成影响如何处理？
- 排期，延不延？需求不能按时完成怎么办？
上述“理念敏捷、过程可控”的流程，其实已经包含了这5个问题的答案，但我们来进一步详细说明一下。
规划，做不做——肯定是要做的，这个毋庸置疑。
上文的规划阶段的工作流程，也阐明了规划要做“十”字型的，横向的长周期内的完整规划，加纵向的近期即将开展的工作和细节。
进一步来做一些说明，规划是要解决是什么、为什么、怎么做的问题，去帮助决策，对于是什么——要提供一个什么样的产品或者服务，为什么——为什么要去做，需求未被满足？市场空间巨大？战略部署和探索？这两个问题，要尽可能全面的考虑，这样才能辅助决策者做出正确的决策，和为“怎么做”提供依据。
对于怎么做，建议有粗略的时间点即可，仅对近期要开展的工作项做细致规划，这其实也贴合了项目本身渐进明细的特点，这么做有两个好处，一是可以缩短规划周期，尽快启动项目，获得先发优势；二是需求是变化的，一开始做完所有的规划，往往很难按照规划执行，必然会经历变更，那就如不边做边规划。
决策，早或晚——要看决策的影响范围。
影响范围大、变更难度高的、变更可能性小的决策，要早做，如影响到了技术路线、顶层设计、顶层架构等技术层面的规划，早做的原因，是这依赖这些决策结论需要尽早开展技术调研，且决策周期内不会产生很大的技术突破，没有变更的空间，就可以早决定、早启动。
而影响范围小、变更相对简单、且变更可能性大的决策，可以晚做，如功能和需求点这一类的业务规划，这些对技术调研的要求不高，随时可以开始，晚做决策不影响整体进度，反而可以进行充分的需求论证。
例如在项目立项时，对用户数量、数据量级、数据更新频率等会影响存储和计算方式的决策，需要早期确定，方便技术调研和产品规划同时开展。而一些诸如功能的优先级、模块的呈现方式、交互方式等决策，可以晚做。偷偷地讲，给客户做方案，到头来对方可能觉得还是第一版好，所以不妨压缩一些决策的周期。
文档，写不写——一定要包含必要的文档。
产品同学要提供哪些必要的文档？从上述的5个过程中进一步总结一下。
启动阶段，如果是从0到1的项目启动，产品需要完成项目文件，例如《市场需求文档》、《竞品调研文档》、《产品规划文档》等，作为项目的“顶层设计”，这些文档除了是项目立项的保障，也是促进项目成员达成共识的工具，让大家对项目的重要性、规划有完整的认知。
规划阶段，产品同学需要完成整体的《产品路线图》，每一个版本的《产品需求文档》，以及评审之后的《排期表》，这几个文档用来确定各个版本的范围和进度，《产品需求文档》也是技术和测试同学产出《技术方案文档》、《测试用例文档》的范围依据，规划阶段的文档是必不可少的。
执行和监控阶段，需要的文档主要是《变更记录》，以及上述《产品需求文档》的更新，要尽可能及时、详细地对变更和调整进行记录，便于拉齐信息，团队协作。
收尾阶段，交付时通常需要提供和版本相匹配的《使用手册》，复盘的前后也提供相应的《项目总结》文档。
需求，变不变——控制需求变更，变更尽可能少影响当前的开发工作。
在“过程可控”的第一方面就强调了，对变更一定是要有控制的，无休止的变更就意味着项目永不结束。
不必要的变更是谁都不喜欢的。在项目正式开发前，也就是启动和规划阶段，是完全的“理念敏捷”——拥抱变化、团队开放、价值导向，这些阶段中的需求变更，其实是通过充分的论证形成思想的碰撞，尽可能考虑到所有的因素、得到最佳的方案，为后续的“不变更”奠定基础。
在这里需要把控的，就是时间问题，确保所有的论证在可控的时间内完成，不影响项目开始执行的时间。在项目进入执行阶段后，变更应当尽量减少，新的需求如果合理就加入待办列表，等下个版本规划和排期时一起评估。
由于一些问题，如技术难以实现等，需要修改产品或者技术方案的，也尽量第一时间提出；如果是一定要紧急上线的功能，在评估影响可控可执行的情况下，也不要忘记对现有的排期和需求范围做出相应调整。
排期，延不延——合理预估工作量，尽可能保障按时上线。
在一些情况下，项目的按时上线就是项目成功的重要标志之一，延期必然是不好的。
如何避免项目的延期，需要在排期预估的环节就进行把控，时间的预估要合理，对完成任务需要的时间、可用于开发的时间、其他影响因素等充分考虑，一旦形成排期，就是承诺，尽量不延期，在预设好的时间内完成对应的工作。
当然，合理即包括不过分压缩，也包括不过分预留，不能为了“按时上线”就预留一个“充分得过头”的时间。在项目过程中，一定会遇到需求变化、技术难度预估不足等问题可能导致延期，那就要在发现问题时尽早提出，以便尽早提供解决方案——增加人力、调整需求、还是延期，在上线的前一天通知大家项目会延期是不能接受的。
五、总结
通过对项目管理的介绍、互联网项目的特点的分析、项目管理范式的选择，本文给产品同学工作中与研发等角色进行沟通、推进项目上线提供了一套可用实践——“理念敏捷、过程可控”。
学习理论不难，在实际的工作中，最困难的部分在于，如何让项目团队内的成员都接受这一套方法，尤其如果公司和团队没有明确的研发流程、发版制度的情况下。
那没有管理职位，却要进行管理职责的产品经理，要和技术岗位的同学们“和谐共处”，保护自己的“人身安全”，就需要通过潜移默化的影响，推进产品上线的流畅，于“润物细无声“处影响团队，这考验的就是产品经理项目管理的“软实力”了。
实践的落地是循序渐进的，所有流程的前提，不要忘记理念上的敏捷——注重个体、注重沟通，方法是拿来用的，指导和优化实践，不是用来与人争论的，不能强行灌输“拥抱变化“的理念，也要说服开发同学放下”不能变更”的执念，大家共同的目标是，通过不断的迭代尽可能快速地实现业务价值。
希望本文能和产品同学在项目管理上产生一些共鸣，愿世界和平、没有延期。
本文作者 @小小晶
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
