IPD的理解

对IPD框架的理解，IPD流程有6个阶段：概念——计划——开发——验证——发布——生命周期，一起来看。

IPD的理解

• 本质
  • 分类——关键思想——关键要素——实践
  • 全生命周期的，集成的项目管理模型
  • 产品作为投资来管理
  • 技术和商业双轮驱动
    • 先做战略规划和市场洞察，做年度商业计划，通过市场关键需求来定义产品包
    • 做技术预研和演进
• 关键特征
  • 按阶段计划
    • 6个阶段：概念——计划——开发——验证——发布——生命周期
      • 实践：制定五层项目计划体系模板的时候，先把需求按照分阶段，然后按照里程碑计划、关键任务、相关方配合计划、原子任务逐层分解，本地员工只要把开发阶段的用户故事按照依赖关系排列关键任务，设定责任人、里程碑节点，就形成一张完整的PERT项目计划网络图，可以推测出最后准确的交付时间。过程管理可以根据时间节点的颜色来识别任务是否完成，每一个项目都据此运作。
  • 资源有限情况下的组合排序
    • 尽早交付客户价值，最大化交付客户价值，把有限资源用在收益最高的需求上
      • 实践：传统A产品的需求由于市场问题大都预算紧张，评估工作量很小，客户传递的需求不够清晰，因此系统工程师需要花大量的精力去沟通理解和设计，而M产品单一需求的工作量很高且持续性好，因此把团队80%的人力投入到M产品，并主动承揽业务，获取更高收益，对于A产品仅响应自然流入的需求，使用20%的人力。
  • 按业务适配
    • 每一种业务都是根据IPD框架去适配的
      • 实践：原A产品开发从印度团队切换到北非团队，根据团队的能力特点重新做IPD的适配，新涉足M产品，虽然和原A产品类似，但是仍然做IPD流程适配，关键任务的差异体现出两个产品受众的不同
  • 人的集成
    • 权力的逐层向下授权
      • 商业上层决策，技术下级决策
        • 实践：产品路标都是在总部机关决策，而具体的产品开发过程中的技术评审或变更控制都是在本地开发团队内部闭环
      • 每一层级的团队职责和协作方式是明确的投资决策委员会——集成组合管理团队——超级产品开发团队——产品开发团队，每个团队内的各种角色职责也是明确的
    • 跨部门重量级团队运作
      • IPD流程的每一层级，除了有产品研发，还要集成其他功能领域，如市场、财经等，他们的参与体现在规划和评审上
        • 实践：作为一个体系内海外的业务开发单元，在研发团队本地化运作时也是要集成各种角色到流程和计划体系内，比如团队内测试人员、一线解决方案方案人员、质量部门和维护团队都要参与需求的开发设计决策点的评审
    • 集成计划互锁
      • IPD提供了一个计划框架，在框架下的所有相关方角色，都有逻辑上的计划依赖关系，放在一个计划体系内，相互承诺紧密配合
        • 实践：解决方案什么时候提供高阶设计方案，开发团队什么时候完成开发，集成验证团队什么时间开始部署集成，都是由流程集成到计划体系内的
  • 事的分解
    • 把最佳实践分解到流程关键任务和配套实施方法，清晰地定义好入口和出口条件
      • 实践：业务流程根据IPD细化的时候，通用的模板包括了前置条件、流程活动定义和出口质量标准
  • 流程中构筑质量
    • 集成入口评审和集成出口验证
      • 所有相关方角色都会在上一个阶段的出口评审交付件质量并决策是否启动下一个阶段
        • 实践：本地化运作过程中，解决方案（需求方）、服务交付、系统工程师（设计人员）、测试工程师、质量运营、开发工程师、项目经理都会在设计阶段结束和验证阶段结束的关键决策评审点共同做出决策并形成书面结论
    • 跨部门多领域需求策略设计与集成
      • 除了产品的技术设计之外，营销团队需要设计可销售性并伴随产品开发同步生产营销装备等
        • 实践：平台级的新特性需求开发完，发布前评审也会评审营销资料、第三方软件选型、网络安全等产品的方方面面
    • 科学的评审点
      • 评审点设定在关键的阶段之间，同时要清晰的定义评审和检查项，过多会影响效率，过少则质量不能得到保证
        • 实践：以本地开发团队为例，生命周期之前，只在计划阶段完成进行设计、计划、验收用例的评审和验证阶段结束的交付件和网络安全评审，共2个评审点，每个评审点都有详细的检查清单，所有相关方参与投票决策
  • 流程中规范能力
    • 流程内有使能流程
      • 除了有业务流程，还有使能流程
        • 实践：根据IPD定义了需求的端到端流程，同时针对项目计划的制定，也适配了使能流程，教本地员工怎么制定项目计划
  • 覆盖全生命周期
    • 产品要管“生—养—死”
      • 实践：版本发布之后有停止服务、停止维保等里程碑，如商用版本发布之后3个月停止下载，一年后停止维保
  • 共性通用构件
    • 通用构建块，最大程度地进行模块化复用，节省开发和维护成本
      • 实践：在代码仓库存放有常用的方法定义，如日期转换，多线程任务分发等，代码是经过长期优化和筛选的，由系统工程师团队进行维护，开发人员可以直接引用
  • 战略和市场及收款的互锁
    • IPD流程向上连接战略到执行流程和市场到线索流程，向下连接线索到收款，在流程文件里有集成点的清晰定义，其本质是把其他流程的关键活动集成到IPD的框架下，形成体系的集成
      • 实践：制定年度业务目标时，需要先考虑大部门战略并做市场洞察（来自战略到执行和市场到线索），开发完成后要和客户结算收款（来自线索到现金），如果不做就很可能出现市场空间不足，收益无法覆盖团队运营成本或者客户拒不签署验收和付款等情况
  • 例行动作和触发条件来维护流程
    • 流程评审实际上是由一系列例会来完成的，例会的评审来驱动各个相关方完成他们的流程关键动作
      • 实践：每周对每个需求的关键决策评审会议放到团队的例会看板上，由项目助理组织会议
• 目的
  • 及时交付满足客户需求的高质量的新产品（持续尽早交付客户价值）
  • 全公司产品管理的一致性，将战略和计划清晰地衔接起来
  • 提供一个统一的管理流程和决策机制
• 常见问题
  • 速度和反馈慢？
    • 速度构筑于各个环节的质量控制
    • 预先达成共识，会议只做评审和形成结论，在会议开始之前就经过了充分沟通并形成了共识
    • 各个角色密切协同，减少业务流反馈和等待
    • 角色融合，一人可以身兼多种角色，减少外部沟通
  • IPD流程过于厚重？
    • IPD流程可以简化为阶段和分层授权决策的框架，再轻量化的产品也要经过现代产品开发的阶段，只要做好决策点的裁剪，尽量做到在周期内只规划一次，只评审一次，把角色整合在一起消除沟通障碍，IPD流程一样也衍生出了独立软件敏捷交付流程