一、方案简介
IPD（集成产品开发）是一套产品开发的模式、理念与方法，它综合了许多业界最佳实践。
飞书项目通过建立系统的研发管理体系，实现以规则的确定来应对结果的不确定。面对复杂项目，可以打破系统孤岛，建立为客户创造价值的端到端流程，轻松掌控全局进展。
二、挑战和价值
2.1 挑战
- 没有路标牵引，企业成为“快速的跟随者”
- 缺乏准确、前瞻的用户需求关注，反复做无用功，浪费资源，造成高成本
- 没有跨部门的结构化流程，各部门都有自己的流程，但部门流程之间是靠人工衔接，运作过程被割裂
- 依赖个人英雄，而且这些英雄难以复制
2.2 价值
- 通过市场管理，让企业不再跟随
- 通过需求管理，去粗取精、去伪存真、由此及彼、由表及里
- 结构化流程，通过流程工具、决策制度及运作机制来管理研发过程
- 不再依赖“英雄”，而是基于流程就可以制度化、持续推出基本满足客户要求、质量有保障的产品
三、方案亮点
3.1 项目管理
企业中主要有两种类型的活动：一类是连续不断、周而复始的活动，人们称之为“例行工作”，这些活动常常是按照既定的程序、规章制度，不断重复进行，例如，年度人力预算、每月人力核算、KPI 考核、职能部门例会等。另一类是具有特定目标的、临时性的、一次性的活动，人们称之为“项目”，每个项目都有自己的独特性，往往是不同团队采用不同过程，开发出不同产品或成果。
传统的项目管理要对项目的所有过程进行管理和风险把控，并要求在不同环节有文档输入和输出。比如 PMBOK 对项目整合管理的过程组做了文档输入和输出的整理，但是，项目管理主要是对范围、进度、成本、质量、人力资源、沟通、风险、采购和干系人进行管理，每个环节都存在启动、规划、执行、监控和收尾的过程。
3.1.1 整体管理：多视角查看进展，全方位跟踪风险
整体管理需要对项目中相互冲突的目标和方案进行平衡，统一分配资源，对齐计划，消除冲突，保证项目有序开展。在飞书项目中，支持一键切换视图模式，全局把握项目进展的资源和风险。并能够一键拉起飞书群聊，项目干系人自动入群，消除信息壁垒。
制定项目任务书：参与制定项目任务书是指了解项目的背景和目的，参与分析客户需求和期望，理解项目的制约、主要风险和总体要求（包括：总体预算、总里程碑、项目成功标准等）。项目计划书的准确制定是项目成功的关键因素，飞书项目中通过字段来承载交付物，并支持在后台预制交付物模板，添加填写信息的提示。
项目执行与监控：项目执行与监控是指执行项目计划，在过程中以项目目标为导向进行监控，根据度量、分析结果推动改进，确保按计划完成项目成果交付，实现项目的绩效目标。冲突和问题解决是项目监控中重要的活动，项目经理要倡导可视化管理。
飞书项目支持多种视图模式，表格视图可以展示项目的具体信息，列表视图展示项目-需求-任务等的拆解关系，甘特图模式能够直观的看到项目的排期计划，看板卡片便捷拖拽流转项目状态，度量视图支持自定义图表，在过程中查看项目进展和风险，最大程度的避免项目资源冲突，预防风险的发生。
集成变更控制：集成变更控制是指评审变更请求，批准变更，并管理交付件及其项目文件变更的过程。变更控制的目的并不是控制变更的发生，而是要对变更进行主动管理，提前预防不必要的变更，确保必要的变更有序进行，防止随意变更而导致混乱。
3.1.2 流程管理：让管理简单，让执行高效
流程管理：流程管理模式所强调的管理对象是业务流程，强调以流程为目标，以流程为导向来设计组织框架，同时进行业务流程的不断再造和创新，以保持企业的活动。流程可以说是企业管理模式改造中最关键的字眼，任何策略远景的实现、信息系统的导入、企业文化价值观的具体呈现，终将落实到流程。
流程持续优化：飞书项目强大的流程引擎可以帮助快速迭代升级流程，流程只有持续的优化才能更好的满足客户需求。流程驱动项目成功，将流程透明化，协同将更加容易，也更容易发现卡点和浪费的聚集地，那么改进流程，减少浪费，落地流程，持续的 PDCA。
快速落地：根据以往客户的变革数据，以前落地一个流程要 1 个月，现在就需要 1～2 天，真正的将流程变革快速落地，解决难落地的问题。
3.1.3 项目集管理：保证战略一致性，统筹全景看重点
项目集是以协调的方式管理一组相互关联的项目、子项目和项目集活动，以获取分别管理它们不可获得的收益。所以我们需要拉齐项目的关键信息，并能下钻看到项目的实际风险情况。
全景视图：通过全景视图可以实现将已授权空间中的项目，聚合到一起，实现跨空间对项目的监控，处于什么状态，是否延期，收益是多少，PMO 是谁，关注的里程碑点时间，这些信息都可以聚合展示。
全景度量：拉取项目集中的项目数据，可以形成项目集的度量看板，有效观测项目集中的数据，比如具体项目集的工时情况，缺陷密度等组织级的统一监控指标。
工作台视图：对于管理者我们可以在工作台中自定义配置自己的数据看板视图，随时关注项目集相关的进展
3.1.4 计划管理：项目多层级拆解，计划管理线上化
在项目启动阶段，需要对项目进行“预设性”的按照时间和任务进行拆解。通过飞书项目独特的流程嵌套和计划表功能可以实现项目的无限层拆分，最细颗粒度的将每个任务分配到对应责任人。
流程嵌套：和其他项目管理工具的不同点在于，飞书项目将流程的把控放在项目最重要的部分，独特的节点流工作模式帮助管理者清晰地看到每个项目的进展情况。对于多层级的项目拆分，飞书项目采用流程嵌套的方式，将节点转化为“子流程”，即可作为二级项目继续拆分工作流。这种嵌套模式解决了以往大型项目拆解限制层级的问题，可以实现无限层级的拆分，同时能够对每一层级的项目进行流程的把控，在项目的整体管理中展示所有任务之间的依赖关系，避免资源或人员的冲突。
泳道图：我们支持角色和活动之间的泳道图展示，可以很清晰的把我们要做什么描述出来，让大家正确地做事。
计划表协同编辑：除了项目经理外，PSE、PQA、各领域代表等角色也会参与计划编排且需要知晓相互依赖的信息。多人编辑时需要知道/参考别人编辑的（依赖）信息；且计划发布是严肃的动作，需要多次编辑草稿的过程再由项目经理统一发布。飞书项目计划表支持协同编辑以更好满足以上需求。
排期联动：项目的工作流程作为企业的资产可以沉淀在飞书项目中，在之后的每一次项目可以直接复用；同时，工作流可以自动生成项目计划表，项目经理可以通过编辑计划表来维护项目的节点负责人、排期、启动和完成依赖、交付物等信息。在里程碑节点上填写排期并配置和其他节点的依赖关系后，即可实现自动正排/倒排；即使在里程碑节点例如评审点时间发生变更时，其他依赖节点也可以同步更新，减少了线下使用 Excel 管理需要人工计算每个节点排期的时间成本，也避免了排期修改“牵一发而动全身”的尴尬。
依赖关系：任务依赖关系是项目活动之间存在的相互关系。这些任务依赖关系决定项目任务必须执行的顺序，项目经理可能遇到的任务依赖关系有四种，其中最常见的两种是：
- 完成到开始（Finish-to-start）：这是最常见的任务依赖类型。从完成到开始的任务依赖关系意味着 A 任务在 B 任务完成之前不能开始。这发生在大多数需要按顺序执行工作的项目中。
- 完成到完成（Finish-to-finish）：当 A 任务直到 B 任务完成后才能完成时，就会发生 Finish-to-finish 任务依赖关系。这在任务可以同时执行但必须按顺序完成的项目中很常见。
飞书项目中可以对任意节点配置依赖关系，在项目执行过程中灵活调整各节点的启动或完成依赖，帮助项目经理清晰监控项目进度以及卡点问题。
流程资源库管理：任何项目的执行过程都不是一成不变的，项目经理需要在流程中能够灵活调整，避免因非卡点任务的延期而导致整个项目进展的阻塞。飞书项目在支持管理者规范组织流程的同时，也能够在配置侧将“节点”、“任务”、“子流程”作为资源放到资源库中，允许使用者在过程中引用。例如，项目中需要对需求进行重复的迭代，那么可以将需求流程作为“子流程”资源，在使用侧多次调用，实现流程的灵活调整，快速完成项目计划的搭建。
操作指引：支持配置及展示每个活动任务的操作指引，如准入准出条件、最佳实践、注意事项等。让每个成员不仅知道要做哪些事情，也能够知道如何去做。
里程碑：支持配置里程碑，对里程碑这类关键的活动进行重点管理（里程碑节点、里程碑截止时间）。
3.1.5 时间管理：合理规划时间，高效完成活动
合理安排项目时间是项目管理中一项关键内容，它的目的是保证按时完成项目、合理分配资源、发挥最佳工作效率。合理的安排时间，保证项目按时完成。
项目甘特图：通过项目甘特图可以从单个项目的视角查看项目端到端交付过程中各里程碑节点的计划开始时间和计划完成时间；同时各角色的排期和任务完成情况，未估分节点也一目了然。操作上，在甘特图中拖拽进度条可快捷更改排期。
时间变更管理：项目执行过程中，里程碑节点的计划时间在一定进展后不允许随意变更，即使由于某些特殊变动需要修改，也需要经过变更的审批。
人力甘特图：左侧导航栏设有人员排期视图，从人员的视角查看人力资源分布情况，各角色也可以查看自己的整体排期情况。
3.1.6 变更管理：主动管理变更，防止变更混乱
项目初期制定的计划，在过程中因为某些原因需要变更计划或排期，往往存在两个极端，要么是变更自由，随意变更排期无知会，后期盘点追责为时已晚；要么变更步骤繁琐，审批邮件、信息发一堆，上下苦不堪言。
借助飞书项目变更审批插件，实现对重大变更进行审批管理，项目成员操作触发审批，项目负责人飞书卡片操作审批，让过程风险更可控。
3.1.7 质量管理：事情一次作对，降低质量成本
在正式聊质量管理前，我们先重新认识一下质量管理，这里借用一本管理学的名著《质量免费》来消除几个错误的观念：
- 第一个错误观念，认为质量意味着好、奢侈、光亮或者分量。
- 质量的定义就是“符合要求”，而不是好
- 第二个错误观念，认为质量是无形的，因此也是无法衡量的。
- 质量也有成本，一家经营良好的公司可能只需要花营业额的 2.5%在质量上面，如果没有一次把事情做对的话，可能要花掉 15%-20%甚至更多。
- 第三个错误观念，认为有一种经济质量。
- 没有所谓“经济质量”这回事，第一次就把事情做对总是比较省钱的。
- 第四个错误观念，认为质量的一切问题都是由工人，特别是那些制造厂的工人所引起的。
- 工人其实就是一面镜子，你们看到的反射影像就是你自己。
- 第五个错误观念，认为质量问题的根源在于质量部门。
- 不要说“质量问题”，而要清楚地说出它是哪一个部门的问题。
既然质量有成本，那么我要如何减少质量成本提升项目的成功率呢，来看看飞书项目是如何提升成功率的。
把事情一次作对：第一次把事情作对总是比较省钱的，那么我们可以把完成事情的约束条件，作为高亮的信息提示写在我们的流程中，并且把我们的规范放到流程中，每个人都把好自己的质量关。
质量分析：在项目的过程中，我们发现对于同一个项目，不同的角色甚至是通、同一个角色，给出的度量数据都不一致，造成这个结果的原因就是大家的口径不一致，度量的数据源不同等等，那么飞书项目可以把质量数据放在项目下做分析，那么所有人员口径统一，也能更直观进行分析。
项目度量：我们可以对项目执行的数据进行统计，并放在质量管理的页面下，让数据和项目同步，让数据驱动项目高质量交付。
3.1.8 风险管理：建立风险知识库，分析数据化管理
风险管理是对可能影响项目进度、质量等方面的不确定事件进行主动应对和管理，以降低或者消除影响的关键举措。在整个项目开展过程中，以项目经理为代表的项目团队必须积极地、持续不断地识别风险，行之有效地进行风险管理。
风险管理规划：主要在概念阶段进行，根据项目初期的需求文件等输入，由项目管理组织相关人员进行规划分析与评审，界定风险管理活动的基本范围，确定风险费用因素和所需的进度计划活动，统一纳入到项目预算和进度计划中，同时对风险指派进行分配，对风险类别、概率、影响度进行汇总；
识别风险：主要在项目立项准备阶段和概念阶段进行，采用一定的工具和技术（如 FMEA、SWOT 分析、案例库等），对风险进行有效识别，输出风险管理表，其中风险管理表主要包含以下信息供参考：
风险管理表主要包含的信息维度有：风险类别、风险描述、所属项目、风险等级、发生概率、影响程度、规避方案、应急方案、当前状态、当前负责人、当前进展等
分析风险：主要在项目概念与计划阶段进行，对已识别的风险进行概率、影响评估，评估风险等级并持续监测；
制定风险应对计划：主要在项目概念与计划阶段进行，根据风险的优先级来制定规避措施和应急措施，及时将风险对应所需的资源投入刷新至项目计划中例行监控；
控制风险：主要在项目执行阶段持续进行，按照风险应对计划对已识别风险进行跟踪，监控残余风险，定期刷新风险处理进展，同时不断识别、评估新风险，确保风险对项目的影响降到最低。
针对单项目或项目集管理中的详情页设置关联风险 Tab，将风险管理信息关联到对应项目，在关键里程碑节点（TR 和 DCP 等）设置风险状态验收规则（如研发领域中、高风险要求在 TR4A/TR5 前完成风险关闭等），并根据规则设置自动化提醒功能，提醒处理人及时完成风险释放，可以有针对性地对不同风险进行跟踪闭环。
一键入群查看历史思路：同时，风险管理工作项可以作为空间案例库对相关人员进行开放，通过查找风险管理工作项中的风险，一键入群的功能，可以查看历史的解决思路，特别是对已释放的风险/已完成项目关联风险的管理跟踪过程，可以作为公司级或领域案例进行知识分享。
3.2 市场需求管理：
据统计项目失败的原因有 45%都是由于需求的失败导致的，所以我们需要对市场需求进行重点管理，明确客户的预期，澄清需求的旅途，从而做有价值的需求将我们的资源投入到目前最重要的事情上，进一步完成做正确的事情，然后才能正确的做事。
3.2.1 需求收集：关注端到端流程，需求动态化追踪
我们把需求统一放到一个空间进行收集，这样既能从大盘视角看看需求聚合，又能避免需求过于分散而丢失，我们既支持移动端也支持 PC 端，随时随地的提需求提需求。
可见性设置：飞书项目可以创建一个空间，用来收集外部和内部的需求，对于不同需求类型，我们可以从流程上要求提供不同的需求信息，在标准化的流程下更灵活的执行，根据我们的实际业务诉求获取足够清晰的市场信息。
3.2.2 需求分析：需求结构化，避免一句话
需求分析是一个确认终点寻找路径的过程。那么终点有时候是清晰的，有时候是不明确的。
面对清晰的需求，我们常常犯的错误就是提啥需求就接，这样很容易在后续的工作中推倒重来，因为往往解决的是个方案而不是问题的本质；而面对不明确的终点，我们通常会规划 MVP，做实验局持续渐进明细，用最低的成本拿到反馈持续优化。
我们把需求分析的过程梳理为解释，过滤，分类，排序，通过这四个行为让需求分析找到终点的路径：
- 解释：通常会组织评审进行需求的澄清，进一步了解需求价值；
- 过滤：澄清需求后的，不符合价值的需要打回重新补充相关内容或者终止需求；
- 分类：根据战略，我们把需求分为 3 种类型：中长期需求，短期需求，紧急需求；
- 排序：根据战略的一致性划分优先级，方便后续分发和实现，让有限的资源投入到当前最重要的事情上去。
3.2.3 需求分发：以规则的确定来应对结果的不确定
需求分发，需要能灵活的对以上 3 种类型的需求，快速形成标准化的路径，让需求找到自己的业务流向，飞书项目可以在标准化的基础上让流程定制化，不同需求走不同流程，高效便捷，以规则的确定来应对结果的不确定。
- 中长需求：路标需求，路标需求和我们的 SP/BP 计划做对齐，与战略保持一致；
- 短期需求：Charter 立项，通过 Charter 评审后，进一步形成初始产品包需求给到研发团队；
- 紧急需求：需求变更，可以直接进入到已有的产品开发中，给到研发团队；
3.2.4 需求实现：业务与产研打通，状态自动同步
需求的实现通常需要由研发空间完成，这样经常会出现需求无法端到端管理，信息成为孤岛，业务和产研脱节，而飞书项目可以通过空间关联的概念，完成市场需求声音和产研空间状态的打通，自动同步状态，做到信息的自动化同步，保证业务和产研之间拉通对齐。
3.2.5 需求验证：端到端验证，实现价值闭环
需求的终点不是上线，而是需求的价值是否得到验证，当市场需求完成上线或者发布后，定量和定性的评估上线的需求是否满足用户预期和市场需求，这样才让一个需求真正做到闭环管理。
3.3 IPMT 决策评审：
很多企业的新产品，立项缺少决策机制，结果做出来的产品不理想或者一团糟，立项后也缺少决策的把控，比如项目是否还要继续进行，产品在质量，范围，成本上的偏差是否合理，大家都对齐认知了吗？对于这些事项，想要合理的解决，就需要建立科学的决策机制和平衡机制，比如 DCP 决策流程：
- 流程裁剪：根据项目的类型我们控制决策的评审流程，比如 EDCP 决策点如果不需要，那么可以通过流程控制快速裁剪。
- 自检：各角色按照计划时间，进行自检，自检内容为后台评审要素配置的内容，自检完成后点击完成节点。
- 预评审：我们强调事前检查，高效决策。按照正式评审的时间可以自动化配置的提醒任务，比如提前 3 天对材料预评审，提高会议决策效率，对于发现的问题，会前充分沟通。
3.3.1 评审要素：事前预防，保障质量提升效率
很多企业和公司重视评审机制，但是评审的时候却没有评审要素，不知道评什么，比如说评审一个方案，需要准备什么材料，要评审哪些点，都非常模糊。所以我们要建立科学规范的评审管理体系来提升决策能力，项目的运作效率。
- 评审要素表配置：要素表包括检测人角色，操作指导，要素分类，严重程度，关联资料等基础信息。可以在后台对评审要素进行配置，将不同阶段的评审要素导入到各个 DCP/TR 流程中。
- 评审要素表合并：我们可以通过可见性的配置，对评审点进行裁剪，裁剪后的评审要素可以合并到要合并的评审点中，比如我们将 TR4 合并到 TR4A，那么可以通过对 TR4 裁剪，做到灵活的配置。
- 评审要素裁剪：我们通过对评审要素表进行裁剪，来满足评审要素的适应性。
3.3.2 评审结论：灵活配置，充分自检高效决策
- 评审规则：我们可以支持的评审汇总结果有 2 种方式：百分比，绝对值人数。更灵活的适配各种场景。
- 评审界面：各个代表可以在各自的节点发起评审的结论，在评审结束后，我们可以通过开关进行锁死，系统会自动汇总各个代表的结论并根据后台设置的规则进行评审结论的输出。
