产品经理“人身安全”指南：项目管理的理论和实践.docx

《产品经理“人身安全”指南：项目管理的理论和实践.docx》由会员分享，可在线阅读，更多相关《产品经理“人身安全”指南：项目管理的理论和实践.docx（27页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、产品经理人身安全指南：工程管理的理论和实践专家说，在一段关系中如果小心翼翼，那可能就离分开不远了。可偏偏 产品经理和程序员这一个打打杀杀”的组合，分又分不开。一个段子说，程序员开大会，产品经理还能安安稳稳地坐着，是因为外 面有安保。程序员们只看到了产品经理提需求时候的指指点点、喋喋不休，往往注 意不到产品经理面对老板每一个需求都要高优时的抓耳挠腮、面对用户 客户提出五彩斑斓的黑时的无奈但还得和蔼的人格分裂、面对用户明知 道你就是个卖肉夹馍的非让你卖给他一个热狗时的语言匮乏。对产品经理来说，如何和程序员和平共处、顺利地推动工程按时完成？ 如何在加需求、调需求、改BUG、催进度时不被“暴揍 ？如何

2、能避 免隔壁工位的程序员不在心里或者行动上给自己带来人身伤害？做好工程管理，或许能解决这些问题。管理简述谈到如何做好工程管理，先来看看什么是工程。1.概念工程是指为创造独特的产品、服务或成果而进行的临时性工作，工程是 为了组织的经营需要与战略目标服务的（PMBOK指南）。相信回答好这些问题，并且就问题的解决方法与开发同学达成一致，产 品经理就可以和开发同学建立一段平等的关系，开启安全系数高、甩锅 扯皮少的幸福工作时光。当然作为一名产品经理，你可能还会有其他的问题，包括我需要做一个 什么样的产品？产品是否有市场竞争力？是否能满足用户需求？是否 能为公司带来收益？等等的这些，并不在我们工程管理的讨

3、论范 围之内。工程管理是提供“正确地做事情”的方法，而上述这些问题, 是做正确的事情的范畴，需要在OKR / KPI制定环节去解决。下文所有的讨论，也是假设你已经知道做什么了，只是需要知道怎么做, 来展开。基于互联网工程的这些特点，哪种生命周期类型更适合产品经理去进行 工程管理呢？互联网项管理范式选择1 .预测型生命周期管理与敏捷型生命周期管理预测和敏捷是4中工程管理类型的两端，不妨就以这两种类型展开讨论。选择预测型还是敏捷型的工程生命周期管理类型，再来比照一下预测和敏捷的区别：方法需求活动交付目中预测型固定整个工程仅执行一次一次交付管理f敏捷型动态反复执行直至修正频繁小规模交付通过频繁小规模

4、交付和预测型和敏捷型的工程管理方式，在需求是否固定、执行次数、交付次 数、目标方面都有差异。如何选择需要在上述几个维度都进行考量，但 根本的还是要从需求入手。从需求的不确定性、交付的不确定性即 技术程度的不确定性两个方面去构建（敏捷实践指南）坐标，得到如下 模型：低不确定性技术程度的不确定性高不确定性自适应方法高不确定性需求的不确定性低不确定性需求和实现的技术如果不确定性较低，使用于线性的方法一比方预测型；如果两者的不确定性都较高，那可能就是一个混乱的工程，需要重新评估捋顺；如果都是一个居中的水平，可以用自适应的方法比方 敏捷型。预测和敏捷在工程管理中的区别，从敏捷宣言中就可明确知晓：我们正在

5、通过亲自开发和帮助他人开发，发现开发软件的 更好方法。通过这项工作，我们开始更重视：个体及互动而不是过程和工具可用的软件而不是完整的文档客户合作而不是合同谈判应对变更而不是遵循计划也就是说，右栏的工程固然有价值，但我们更重视左栏中 的工程。简言之，敏捷对过程和工具、文档、合同、计划的关注程度，是低于互 动、成果、合作和变化的。敏捷拥抱变化，在需求不明确的时候，在较 短的周期内开发出可用的产品，帮助明确需求和调研市场，这也就是产 品开发过程中的MVP （ Minimum Viable Product,最小可用产品） 概念。但同时，敏捷并不意味着随意和无序。在敏捷实践中，也存在着诸多的 框架，如精

6、益、看板、水晶、极限编程、Scrum等。虽然从理念到流程上，敏捷和预测的工程生命周期类型存在诸多差异, 但既然都是工程管理，两者都符合知识、技能、工具和技术的应用 的工程管理概念。即使敏捷对流程和文档进行了诸多的裁剪，关键的控 制还是必不可少的。例如不重视文档不代表没有文档，必要的文档如产 品需求文档，还是要有的。工程管理的5大过程组和10大知识领域， 两者都会覆盖到。预测型工程与敏捷工程中的5大过程组：预测型敏捷型启动构想J推测执行探索侬结束整合管理、范围管理、进度管理、本钱管理等10大知识领域，在 预测型的工程管理中，有完整的输入、输出文档，使用的工具和技术。 敏捷工程同样离不开这10个领

7、域，但关注的重点有所不同。敏捷在10大知识领域中的应用:知识领域敏捷中的应用整合管理强调自组织的团队，具体的规划和交付授权给团队来完成；强调拥抱变化， 不强调变更的流程范围管理在工程早期缩短定义和协商范围的时间，通过发布多个版本来明确需求预测型，歹进度管理较短的工程周期，必要时调整据范围调星敏捷型，工本钱管理采用轻量级估算，出现变更时调整的，通过V质量管理频繁开展质量与审核步骤，PDCA资源管理集中和t办作的团队结构，提高生产率和促进创新问题的解决沟通管理集中办公，简化信息获取渠道，定期与相关方评审风险管理加快知识提供，充分考虑风险，随进展重新排列优先级采购管理买卖双方风险共担的采购模型，大型

8、工程主体+补充协议相关方管理直接与相关方互动，加快信息风险，提倡高度透明.范式的选择那互联网的工程管理到底是选择敏捷还是预测?前面局部也分析过互联网的工程有3大特点一节奏上的“小步快跑、 快速迭代、周期上的开发与运营兼顾、人员上的非工程制团队，基于 这些特点，适用预测或敏捷，都存在一些障碍。节奏上的特点一需求的不断变化和快速的迭代，是使用预测型工程管 理方式的障碍，敏捷比拟能适应这种节奏。而周期和人员上的特点，两 种管理方式好像都难以招架。在实践中，很多公司的工程开发会选择用看板管理故事点从需求到上线 的过程，看板、用户故事，其实都是敏捷中的工具。还有一种比拟常见 的互联网产品开发管理流程，从

9、调研到评审、设计、开发、测试、上线， 再逐一版本进行迭代，很多情况下是在对传统的预测型流程进行大幅度 裁剪的基础上，视情况混合敏捷理念的管理体系。互联网产品的工程管理，混合可能是常态，完全的预测型或者完全的敏 捷，也有一些适用场景。预测和敏捷最根本的差异，是需求是否明确， 需求能否明确的原因，是工程追求的价值。如果工程的目标是按时上线，那可以用预测型的方法，对过程进行严格 的管理。而需求存在变更可能性的工程，不应该以按时上线为目标，而 是要追求业务价值的实现，顺应变化适时调整，才能做到随价值而变。一些交付型的工程，如面向B端企业的软件系统交付，尤其是一些传统 行业的信息化、流程管理系统，工程承

10、接的是甲方的需求，产品和研发 团队作为乙方，基本适用于预测型的管理方法。业务支撑型的工程，尤其是新业务的探索，需要在激烈的市场角逐中获 得竞争优势，如开发一个元宇宙社区，那工程的推进可能就需要敏捷起 来。这个工程有着激进的时间限制一早一天有可用的产品就能早一天抢 占用户、有着较高的新颖性产品形态需要不断探索以深挖用户需求、 有一定的技术复杂度一涉及5G/通信/云计算/区块链/VR/AR等诸多快速开展中的技术的综合应用，此类工程就适用于敏捷型的工程管理方式，拥抱变化是必要且能获得最大价值的。大多数的互联网工程，不完全符合以上两种绝对的场景。毕竟，做软件 交付和探索新业务只是行业内的少数，大多数还

11、是已经开展中的工程, 需要维护，但又没有创新那么时间紧急。如何综合敏捷型和预测型工程 管理的理念和工具，拥有一套适合产品经理进行工程管理的方法论？在 下一局部，提供一种实践。管理实践想要和写代码的同学相谈甚欢，维护其乐融融的合作气氛，每 一次迭代都功德圆满，产品经理不仅需要写得一手好文档，更需要 于润物细无声处管理好工程。产品能力和工程管理能力，两手都要 抓，两手都要硬。方案写的再好、没能按时上线，那也是纸上谈兵；方 案一塌糊涂，工程管理就注定困难重重，即便是磕磕绊绊上线了，其中 的扯皮和后续的反复不然不会少。工程管理怎么做？预测型和敏捷型的工程管理方法如何综合利用？这 里提供的这一实践，不妨

12、称其为理念敏捷、过程可控。1 .理念敏捷敏捷是为软件行业而生，在理念上也很贴合互联网的实际。再回顾一下敏捷宣言：更重视个体及互动而不是过程和工具，更重视可用的软件而不是完整的文档，更重视客户合作而不是合同谈判，更重视应对变更而 不是遵循计划。敏捷管理的目标，是通过尽早持续交付有价值的软件来 满足客户的需求。在理念上的敏捷，可以从以下几个方面入手： 态度上，拥抱变化。这个变化，包括市场的变化、需求的变化、工程过程中的变化，甚至是 人员的变化，将变化视作常态，不惧怕变化。拥抱变化不是一句口号,而是基于完善的应对方案的底气。在方案设计时，产品同学需要对所有的情况充分考虑，选择最适合当时 需求的方案，

13、但也要对后续的调整有充分的认知，在变化发生时能灵活 地应对，接受来自技术同学的“挑战他们是不喜欢变化的，需要 有足够分量的理由去说服。对变化的应对需要做好变更管理，对变更有 清晰的记录，方便回溯和应对人员变化的情形。团队建设上，透明、沟通、共建。不仅是为了提升效率，也是让团队成员获得参与感和表达价值感。除有 特殊保密需求的工程外，产品和工程所有的信息应该是团队内透明共享 的，消除权限管控的隔阂，方便实时获取，也是让各个角色的同学从前 因后果、前后左右去完成各自的工作。沟通上，因为变化无处不在，充分的、频繁的沟通非常必要，一定要鼓 励团队成员在发现问题的第一时间和相关人员沟通，所有的不清晰、不确

14、定都在第一时间澄清。共建不仅仅是共同完成工程，更是共同承当责 任，产品出现问题时，积极解决、重视复盘，不互相推诿。做到透明、沟通、共建，离不开一些工具的应用，如利用线上文档提供 信息，通过固定会议和随时的响应促进沟通，利用投票、头脑风暴等工 具进行团体决策，组织定期的团队内知识提供加强交流等。标确定上，价值为导向，通过经常的交付不断实现价值。将工程的目标定义为实现业务价值，就不仅仅是要求按时完成，而是注 重效果，必要时甚至可以牺牲时间。价值实现应该成为团队内部共同的信仰，成为何时交付、如何交付、是 否接受变更的依据。不断实现价值，在互联网的工程中可以通过不断的 版本迭代来实现，通常的迭代周期2

15、-4周，最长不超过6周，太长的周 期也会放大延期的风险。越早交付可用的版本，就能越早去验证市场需 求和业务逻辑，更灵活地应对变化，为业务获得竞争优势。2 .过程可控：基于5个过程组的流程和工作项过程可控表达在两大方面。一是对于变更，尽管我们强调灵活，但要控 制迭代周期之内的变更，尽量放到迭代之间。在规划最新的版本时，需求是否已经明确应该作为优先级排列的依据之-,还需要细化的需求可以放到后续的版本。在版本开发的过程中，尽 量不插入新的需求，防止影响现有的开发节奏，如果一定要插入，需要明确是延长上线时间、还是增加资源去完成，工程的整体节奏要相应调 整，所有变更及时和成员同步。过程可控的第二个方面，

16、是有完善的流程，从启动-规划-执行-监控-收 尾的5大过程组入手，来拆解一个完善的互联网工程管理流程需要的环 节：启动全思量严论证规划远规划注细节执行少变更多关注监控重质量负责任开发 测试 产品文档评审II排期启动阶段一全思量、严论证，通过全面的考虑和严格的论证，为后续 的工作开一个好头。具体有两个环节，调研和立项。通过充分的调研，建立对市场、用户、 竞品的全面了解，说明是什么、为什么、怎么样的问题，调研的结论是 立项的依据。在通过立项评审、成功立项后，产品就可以进入规划阶段， 其实在多数情况下，启动阶段已经完成了一局部规划的工作，不过启动 独特性、临时性、渐进明细是工程的三大特点。独特性是指

17、每一个工程都是独一无二的，即使是一样的0A系统，工程 也会因为客户的不同、人员的不同而具有独特性。临时性是指工程有明 确的开始和结束的时间，持续的维护是运营的工作，已经超出了工程的 范畴。渐进明细是指工程的成果性目标是逐步完成的，工程前期只能粗 略定义或整体定义，需要随着工程的进行逐渐完善和精确。工程管理，是将知识、技能、工具和技术应用于工程活动，以满足工程 要求（PMBOK指南）的工作。2.工程管理要解决的问题工程的3个特点，说明了工程是一个有始有终、独一无二、逐渐完善和 推进的过程。尤其是工程的渐进明细也是在说工程是变化的，变化就意 味着工程具有不确定性，存在风险，这也就是之所以需要工程管

18、理的原 因。具体来说，工程执行过程中的风险会有以下：1）在工程启动和规划时.如何鼓励相关方、尤其是客户和高层参与工程的计划与决策，确 保工程结果符合他们的预期？.如何引导相关方就目标达成一致？.如何获得相关方包括客户、高层、工程组人员对工程的承诺，确保提供必要的支持?阶段的规划，多是宏观层面的预期的业务目标、大的产品发布节奏、技 术和产品架构等等。在进入规划阶段前，如果是涉及到跨部门合作的工程，建议组织一次开 工大会，拉齐所有关注工程、参与工程的人员的信息，获得后续支持项 目的承诺。规划阶段一远规划、注细节，进入规划阶段，其实工程也就正式开始 了，凡事预那么立，不预那么废，一个好的规划，应该是

19、十字型的， 既有横向的长周期内的完整规划，对工程的最终形态有设想，也包含了 纵向的近期即将开展的工作和细节。这两局部对产品同学来说，对应两个流程的工作：产品路线图的设计, 和具体版本的产品文档的输出。产品文档作为后续设计、开发、测试等环节的工作依据，需要细节完整、 描述清晰。完成了产品文档，就可以组织需求评审，需要全部相关同学 参加，在评审会上提出产品和实现层面的相关问题，探讨解决方案。文档的完善和评审可能是一个多轮循环的过程，除了产品方案评审外, 还涉及到设计图评审、技术评审、测试用例评审，由对应岗位的同学完 成，产品经理协助组织评审会议。评审会上确认后的各类文档，可以作为排期的依据。如前文

20、提到的，互 联网工程的参与人员往往是跨团队、非专职，排期时，需要考虑到各个 角色的可用时间、完成每个任务需要的工时，将突发情况充分考虑进去。例如,前端同学完成这个版本需要5个工作日，但他同时负责多个工程， 在本工程上的精力是50% ,那前端需要的开发周期就是10个工作日。 如果是涉及新技术或者有技术难度的工程，可以用三分法来预估时间: 最快时间、最可能时间、最长时间，得出最终需要的时间。最终的排期 可以绘制成甘特图，预期和实际完成的时间用不同颜色表示，清晰地显 示进度。执行阶段一少变更、多关注这6个字是送给产品同学的6字箴言。执行阶段的主要工作是设计、开发和上线，产品同学的主要工作是跟进 进度

21、，发挥工程管理的职责，沟通协调，同时在需要时去给各个环节的 同学阐释需求。这个过程中，不建议对各岗位专业领域的内容进行过多 的干涉，例如手戳设计师的屏幕，质疑程序员的代码不够完美，都是不 推荐的、有损人身安全的高危行为，要对大家的专业能力有基本的 信任。在进度的跟进中，应该注意跟进的节奏，把控好关键节点、又不过于频 繁，应该重视执行过程中的问题，要求大家在风险发生的第一时间同步, 以便及时探讨解决方案、判断是否要调整原有的需求或排期。监控阶段一重质量、担责任，重质量是对质量的重视，担责任是产品 同学也要为最终结果负责，而不仅仅是测试、质量等岗位的同学的工作。质量意识应该贯穿整个工程的始终，从规

22、划时对质量标准的设定、测试 文档的撰写，到执行中为满足质量标准进行的工作，以及监控环节的质 量控制和测试。监控阶段的工作和执行环节是交叉的，开发完成后需要提测，测试环节 中发现的问题需要修复直至通过测试。整体的监控阶段的工作是需要全 部角色参与的，开发先自测、再提测，测试人员通过后，产品进行验收, 而且建议上线前后分别在测试和线上环境双重验收。收尾阶段一有始终、控节奏，完成上线并不是一个版本的工程工作的 结束，收尾的工作包括向业务部门交付上线的版本，更新相关的使用文 档，此外还要对整个工程进行复盘，工程周期较短的可以简单总结，回 顾产品和工程执行中的问题，提出后续的改进方案，不断完善产品和开

23、发流程。此外，按照互联网产品逐个版本迭代的节奏，这个版本的收尾意味着下 一个版本的开启，控制好中间的衔接关系，适当预留时间等待业务和用 户侧反应问题、决定是否在下个版本优先处理，有时候是非常必要的。如果此前的多个版本因为需求变更、周期紧张等原因，导致技术实现方 案不够完善，可能影响后续的使用，也建议在版本规划时，在需求的节奏不那么紧张的情况下，适时考虑归还技术债，将此纳入新的版本规划甚至安排独立的版本完成该项工作。3.看互联网工程管理的5个问题介绍完了流程，再回头看之前第二局部，产品同学可能困惑的互联网项 目管理中的5个问题：1 .规划，做不做？需要做到什么程度？2 .决策，早或晚？尽早做决策

24、、方便制定方案，还是尽可能晚做决 策、应对变更？3 .文档，写不写？需要写哪些、需要多详细？4 .需求，变不变？变更对已经完成的工作和排期造成影响如何处 理？5 .排期，延不延？需求不能按时完成怎么办？上述理念敏捷、过程可控的流程，其实已经包含了这5个问题的答 案，但我们来进一步详细说明一下。规划，做不做一肯定是要做的，这个毋庸置疑。上文的规划阶段的工作流程，也说明了规划要做十字型的，横向的 长周期内的完整规划，加纵向的近期即将开展的工作和细节。进一步来做一些说明，规划是要解决是什么、为什么、怎么做的问题, 去帮助决策，对于是什么要提供一个什么样的产品或者服务，为什 么为什么要去做，需求未被满

25、足?市场空间巨大？战略部署和探索? 这两个问题，要尽可能全面的考虑，这样才能辅助决策者做出正确的决 策，和为“怎么做提供依据。对于怎么做，建议有粗略的时间点即可，仅对近期要开展的工作项做细 致规划，这其实也贴合了工程本身渐进明细的特点，这么做有两个好处， 一是可以缩短规划周期，尽快启动工程，获得先发优势；二是需求是变 化的，一开始做完所有的规划，往往很难按照规划执行，必然会经历变 更，那就如不边做边规划。决策，早或晚一要看决策的影响范围。影响范围大、变更难度高的、变更可能性小的决策，要早做，如影响到 了技术路线、顶层设计、顶层架构等技术层面的规划，早做的原因，是 这依赖这些决策结论需要尽早开展

26、技术调研，且决策周期内不会产生很 大的技术突破，没有变更的空间，就可以早决定、早启动。而影响范围小、变更相对简单、且变更可能性大的决策，可以晚做，如 功能和需求点这一类的业务规划，这些对技术调研的要求不高，随时可 以开始，晚做决策不影响整体进度，反而可以进行充分的需求论证。例如在工程立项时，对用户数量、数据量级、数据更新频率等会影响存 储和计算方式的决策，需要早期确定，方便技术调研和产品规划同时开 展。而一些诸如功能的优先级、模块的呈现方式、交互方式等决策，可以晚做。偷偷地讲,给客户做方案，到头来对方可能觉得还是第一版好, 所以不妨压缩一些决策的周期。文档，写不写定要包含必要的文档。产品同学要

27、提供哪些必要的文档？从上述的5个过程中进一步总结一 下。启动阶段，如果是从0到1的工程启动，产品需要完成工程文件，例如 市场需求文档、竞品调研文档、产品规划文档等，作为项 目的顶层设计这些文档除了是工程立项的保障，也是促进工程成 员达成共识的工具，让大家对工程的重要性、规划有完整的认知。规划阶段，产品同学需要完成整体的产品路线图，每一个版本的产 品需求文档，以及评审之后的排期表，这几个文档用来确定各个 版本的范围和进度，产品需求文档也是技术和测试同学产出技术 方案文档、测试用例文档的范围依据，规划阶段的文档是必不可 少的。执行和监控阶段，需要的文档主要是变更记录，以及上述产品需 求文档的更新，

28、要尽可能及时、详细地对变更和调整进行记录，便于 拉齐信息，团队协作。收尾阶段，交付时通常需要提供和版本相匹配的使用手册，复盘的 前后也提供相应的工程总结文档。需求，变不变一控制需求变更，变更尽可能少影响当前的开发工作。在“过程可控的第一方面就强调了，对变更一定是要有控制的，无休 止的变更就意味着工程永不结束。不必要的变更是谁都不喜欢的。在工程正式开发前，也就是启动和规划 阶段，是完全的理念敏捷 一拥抱变化、团队开放、价值导向，这 些阶段中的需求变更，其实是通过充分的论证形成思想的碰撞，尽可能 考虑到所有的因素、得到最正确的方案，为后续的不变更奠定基础。在这里需要把控的，就是时间问题，确保所有的

29、论证在可控的时间内完 成，不影响工程开始执行的时间。在工程进入执行阶段后，变更应当尽 量减少，新的需求如果合理就加入待办列表，等下个版本规划和排期时 一起评估。由于一些问题，如技术难以实现等，需要修改产品或者技术方案的，也 尽量第一时间提出；如果是一定要紧急上线的功能，在评估影响可控可 执行的情况下，也不要忘记对现有的排期和需求范围做出相应调整。排期，延不延一合理预估工作量，尽可能保障按时上线。在一些情况下，工程的按时上线就是工程成功的重要标志之一，延期必 然是不好的。如何防止工程的延期，需要在排期预估的环节就进行把控，时间的预估 要合理，对完成任务需要的时间、可用于开发的时间、其他影响因素等

30、 充分考虑，一旦形成排期，就是承诺，尽量不延期，在预设好的时间内 完成对应的工作。当然，合理即包括不过分压缩，也包括不过分预留，不能为了 按时上 线就预留一个充分得过头”的时间。在工程过程中，一定会遇到需 求变化、技术难度预估缺乏等问题可能导致延期，那就要在发现问题时 尽早提出，以便尽早提供解决方案一增加人力、调整需求、还是延期， 在上线的前一天通知大家工程会延期是不能接受的。通过对工程管理的介绍、互联网工程的特点的分析、工程管理范式的选 择，本文给产品同学工作中与研发等角色进行沟通、推进工程上线提供 了一套可用实践理念敏捷、过程可控。学习理论不难，在实际的工作中，最困难的局部在于，如何让工程

31、团队 内的成员都接受这一套方法，尤其如果公司和团队没有明确的研发流程、 发版制度的情况下。那没有管理职位，却要进行管理职责的产品经理，要和技术岗位的同学 们和谐共处，保护自己的人身安全就需要通过潜移默化的影 响，推进产品上线的流畅，于“润物细无声处影响团队，这考验的就 是产品经理工程管理的软实力 了。实践的落地是循序渐进的，所有流程的前提，不要忘记理念上的敏捷一 注重个体、注重沟通，方法是拿来用的，指导和优化实践，不是用来 与人争论的，不能强行灌输拥抱变化”的理念，也要说服开发同学放 下不能变更的执念，大家共同的目标是，通过不断的迭代尽可能快 速地实现业务价值。希望本文能和产品同学在工程管理上

32、产生一些共鸣，愿世界和平、没有 延期。2）在工程执行过程中.如何及时掌握工程的进度和状态、确保工程按时交付，而非在即 将结束时才发现工程要延期？如何对需求的优先级进行排序，协调好不同相关方、不同需求之 间的冲突？如何应对来自客户、高层变更要求，以及工程团队改变方案和进 度等的诉求？.如何解决工程人手缺乏、资源匮乏的问题，或者资源可使用情况 发生变化的情形？如何在问题和风险产生式，推动相关的调整和整改落地？3）在团队建设中.如何提升团队的沟通、协作与配合？如何建立互信、尊重、有责任感的工程团队文化？如何去解决这些问题，工程管理的相关理论划分了十大知识领域，涵盖 了工程管理的方方面面：整合管理、范

33、围管理、进度管理、本钱管理、 质量管理、沟通管理、风险管理、相关方管理、沟通管理、采购管理。3.工程管理4种类型如何把工程管理的十大领域组织起来，建立恰当的管理流程和体系？工程管理理论也提供了 4种工程管理生命周期的类型（PMBOK指南）：型I&二提敏交付频率预测型迭代型变更程度方法需求活动交付目预测型固定整个工程仅执行一次一次交付管理迭代型动态反复执行直至修止一次交付解决方案增量型动态对给定的增量执行一次频繁更小规模交付速动态反复执行直至修正频繁小规模交付通过频繁小规模交付,以一个布置和完成暑假作业的例子来具体来体会一下这几种类型:1）放暑假了，数学老师一口气布置完了所有的暑假作业，开学的第

34、一天按时交，过程中老师不会检查这个是预测型，也叫瀑布型，最终开学你交了作业就可以。2）放暑假了，语文老师留了一篇作文，要求你先选题，交给她看了、 确认了之后，再列提纲，提纲她也得检查和修改，然后你再写成作文， 并且修改到她认为符合标准这个是迭代型，中间需要反复检查修正, 但只有最后一次她确认了的作文才能算你的作业。3）放暑假了，英语老师说作业她每天早上8点发在群里，晚上8点得 完成一这个是增量型，每天布置的作业就是给定增量，每天交作业就 是交付。4）放暑假了，科学老师说，每人做一个有新意的科学小创造，他每两 周周检查一次，你决定做一个遥控汽车；于是第一个两周你的汽车成型 了，老师看了还行但是建

35、议你把车身做大一点以便放进更大容量的电池。第二个两周你的车身放大了车也能遥控跑起来了，老师说现在你的车只 能往前走，需要包含倒车的功能，现在别的做遥控汽车的同学是水陆两 栖的方案，你可以加上飞行的功能，有新意又不雷同如此不断调整，到开学你交的作业，是一辆超长续航、能直走转弯后退、车门不仅长得像翅膀还能像翅膀一样带着车飞、具备了摄像功能、自带GPS定位的遥控汽车这个是敏捷型，原始需求是粗略的，每次给老师看的都是成型的作品，不断朝着有新意的目标在调整交付。选择哪种类型的工程管理方法，取决于工程的特点和目标。就像上边暑假作业的工程：数学老师希望你在暑假期间进行了练习就可以，要求的是总量；语文老师希望

36、你完成一篇优秀的作文，会通过过程的监管要求质 里，英语老师希望你每天练习一点，确保英语的语感和保持持续学习 的习惯；科学老师希望你不断突破创新，提升创造力。从上述4种类型的比照中也可以看到，预测型和敏捷型是4类中的两个 极端。在实际的应用中，预测型的工程管理方式适用于需求明确、产品清晰、 不需要变更、需要整体交付的行业，如建筑、制造、通信、能源等等。 敏捷型的工程管理方式适用于速度变化快、复杂性高和风险高的行业,敏捷的诞生，就是基于软件行业的管理需求，去满足组织能够快速产生满足市场需求的产品，通过灵敏的调整保持竞争力和占有市场份额的需 求。既然敏捷是随着软件行业的兴起而诞生的，早在2006年左

37、右，敏捷就 被引入中国，且有大量企业进行了敏捷实践。那在互联网行业的工程管 理中，是否可以直接选择敏捷的工程管理方式？这可能需求打个问号。产品经理如果对着开发同学说，我们要敏捷，要应对变化，所以这个需求得改一下这句话说完，你可能就把自己置于了一个十分危险的境地。知己知彼，百战不殆，想要管理互联网工程，还是先看看互联网项 目的特点。二、浅谈互联网项1.特点与传统行业相比，互联网是轻资产的行业，投入的主要是人力资源，试 错本钱更低，鼓励创新，走了弯路只是消耗了一些人力和时间；同时, 互联网产品开发本钱低，不存在物料的消耗，产品的迭代更新速度快、 市场竞争激烈；在用户层面，互联网和用户拥有更高的互动

38、性，可以根 据反应实时调整产品。互联网的工程管理，由于行业、产品和用户特征，具备以下3个方面的 特点：1）节奏上，小步快跑、快速迭代是大多数互联网工程的共识。风口的瞬息万变、市场的迅速抢占、竞争的分秒必争都要求互联网的项 目需要快速推进、实时反应和迅速调整，要勇于拥抱变化。那在工程的节奏上，就需要尽快上线可用的产品，不断在适应和接收的 反应中迭代，以最小的本钱和有效的方式验证产品是否符合用户需求, 灵活调整方向。例如小米的MIUI系统，操作系统每周更新，根据米粉的使用意见快速 调整，第二个周五再推送一个新的版本，如此往复，几乎从不间断。这 也是此前很热门的概念互联网思维的内涵之一。2）周期上，

39、互联网的工程往往和运营分不开，这里的运营不是指用户 运营、内容运营、活动运营等，是指产品本身的运营。工程是临时性、独特性的工作，而运营是持续的、重复性的工作，而在 互联网团队中，工程往往是不断迭代的，交付一个版本后，产研团队不 仅要专注于后续版本的开发，也需要解决之前的版本中遗留的问题，甚 至是进行使用答疑，在执行时间上，工程时间和运营时间也没有方法完 全割裂而往往是并行，甚至解决线上问题（运营）的优先级是高于开发 新的版本（工程）的。3）人员上，首先是工程经理这个角色，很大情况下由产品经理充当。 在互联网行业，往往是针对跨部门的大工程、或者是面向企业用户（TO B ）的业务，才会有工程经理的

40、岗位，而众多的面向C端的业务、面向 企业内部的产品和服务、部门或者小组之内的工程，是不会有专门的项 目经理的，产品经理需要同时承当起工程经理的角色，推动流程和进度。其次是工程的成员，尤其是开发人员，同时参与多个工程、或者如上一 点所说的那样，即负责开发又负责运营，也是常态。同时，不同角色的开发人员，前端、后端、算法、测试、运维、质量等， 分属不同的组或者部门，是再正常不过的现象。虽然工程管理本身就需 要协调工程人员所属的职能部门与工程之间的关系，但互联网行业这种 产品经理要承当工程管理的工作但往往没有明确授权、工程参与人员所 属职能部门繁杂的情况，也是独具特色。2.互联网工程管理要解决的问题传统的工程管理要解决的问题，互联网的工程管理中也会遇到，那个性 化的问题会有哪些呢？用互联网的语言，来转化一下互联网工程管 理中、产品经理需要聚焦的问题： 文档，写不写？需要写哪些、需要多详细？.需求，变不变？变更对已经完成的工作和排期造成影响如何处 理？ 排期，延不延？需求不能按时完成怎么办？.规划，做不做？需要做到什么程度？ 决策，早或晚？尽早做决策、方便制定方案，还是尽可能晚做决策、应对变更？