上一篇博客详细论述了产品开发过程中遇到的问题,看来不光是我自己感受到了,其实大家都有那种很累但是又没产出的感觉,是整体的流程机制出了问题,所以才要搞流程变革,而其中和我们开发人员最密切相关的就是IPD流程,了解了IPD的目标、核心理念以及涉及人员之后,来详细聊聊IPD的流程。
- 概念与设计阶段:项目建立、组织、架构与概要设计的评审
- 开发阶段:产品的详细设计、开发测试到上线的迭代流程
- 验证阶段:产品的内部验证和客户试用
- 发布阶段:已经验证过的产品的正式发布,大面积公开发布
- 生命周期阶段:产品对外发布后进入维护、优化甚至下线的一个流程
在此之前我们只有迭代,也就是只有开发阶段,而且开发阶段还不怎么规范。需要注意的是这5个生命周期也不一定需要全部经历,当然最好是尽量都走,很多情况下如果是比较小的迭代或者敏捷迭代,就不一定需要走。
概念与设计阶段
第一个阶段主要就是定义目标和成员,并且分解任务和需求,在进行第一个阶段的时候包含以下几个步骤和涉及的人员:
步骤 | 步骤目标 | 人员 | 任务内容 |
1 | MM组下达任务书 | MM组 | 思考以下几个问题:Why:为什么要开发这个产品?What:开发什么产品,从而要满足客户的什么需求?Who:都有谁来参与产品的开发?When:每个阶段的时间安排,比如何时进入开发阶段?How:如何开发这个产品?How much:产品开发的投资收益是多少? |
2 | 组建PDT | MM组 | 组建项目组、指派一条龙的项目经理,PDT包括(产品经理、架构师、产品Marketing、服务、运维、软件、安全、测试、项目财务等) |
3 | Kick Off | PDT核心成员 | 项目启动仪式,项目的启动要有仪式感,此时是项目的核心成员参与,包括开发leader等、但此时尚未指派具体工作,具体模块到底由谁做还不确定 |
4 | 输出WBS | 项目经理和架构师 | WBS(Work Breakdown Structure)项目工作任务分解,进行具体的任务拆解,可能还需要按照模块进行大的拆解, |
5 | 需求分析与架构设计 | 项目经理和产品经理以及架构师 | 有了初步的WBS后,项目经理可以会同相关的产品经理和架构师,主要工作是进行需求分析和架构设计,对产品的需求是怎么理解的、对场景等的理解。架构师也需要做技术路线分析与方案。当然如果有需要,UE/UI需要定义主设计、运维需要定义运维策略,总之这一步就是在WBS的拆解基础上进行详细的产品设计 |
6 | 需求与概要设计评审 和技术方案评审 | MM组和技术委员会 | 第一个TR点,主要包括产品和技术两个方面的评审,是不是符合最开始的项目任务书的要求,以及为什么这么做,这么做有什么风险,评审通过后或者同期,架构师进行需求匹配与分解,产品市场定义运营策略、财务进行成本评估 |
7 | 计划决策 | MM组和技术委员会 | 评审完毕后进入第一个ChekPoint决策点,在评审和资源划分后认为可行 就将项目推入具体的开发阶段 |
开发阶段
第二个阶段就涉及到具体的开发细节了,也就是我们通常认为的迭代主流程,也是耗时最久的一个流程,在此过程中项目经理全程监控项目进度(1-10),架构师团队在正式代码开发前对过程中的需求变更、技术评审等流程提供支持(1-6)、财务在正式代码开发前跟踪成本和费用(1-6)。产品市场在测试阶段开始进行同时产品经理和产品市场可以开始进行局部培训,产品市场可以开始制定发布计划与前期售卖计划(9),除去跨流程的人员外在进行第二个阶段的时候包含以下几个步骤和涉及的人员:
步骤 | 步骤目标 | 人员 | 任务内容 |
1 | 详细设计 | 产品开发测试设计 | 产品经理为主、开发和测试参与帮助进行产品的详细设计,用户场景、用户功能以及规约等形成整体的PRD(产品原型),同步进行的是UE/UI的整体视觉设计、交互设计等出一个视觉设计稿,如有需要还可以确定前期的用户验证 |
2 | 详细设计评审 | 项目经理和产品主Owner | 第二个TR点,详细设计的评审,可以拉一些前端人员或者设计验证组等一起进行详细设计的评审,这个评审一定要特别细腻和完整,成员由项目经理灵活指定 |
3 | 任务分解 | 主副leader | 主leader负责技术开发,辅leader主要负责具体的故事的负责。主副leader要对排期进行评估,分配到人 宣讲之前!这一点非常重要,谁的任务谁参加任务宣讲反讲。 |
4 | 宣讲&反讲 | 产品开发测试设计 | 建议产品在宣讲时按照规范结构讲解,先说说背景再到story,把前因后果都讲清楚,设计部分建议设计来讲,建议听讲的开发测试再听到讲完story再统一提出一些问题,不要中途打断 |
5 | 一页纸方案 | 开发测试 | 需要开发人员提出一页纸的设计,我个人觉得这个环节特别棒,很多坑在开始前就能通过充分讨论规避掉,接下来的开发任务就是照本宣科就可以了,可以规避很多的开发风险 |
6 | 实现方案评审评审 | 技术委员会 | 第三个TR点,一页纸方案的评审,在这个环节主要对一页纸设计的方案进行评审,并进行好的差的的评比 |
7 | 开发 | 前后端开发人员 | 正常的开发流程,按照排期和一页纸设计的方案进行正常的开发流程 |
8 | Demo演示 | 开发测试 | 前后端开发人员对开发好的模块给测试进行Demo主流程演示,确认是否达到了可以测试的标准 |
9 | 测试环境流程 | 测试 | 测试要进行模块测试、集成测试、labs演示和安全测试, |
10 | 版本上线 | 开发测试产品 | 产品的迭代上线,我认为这里需要加上运维这个角色 |
验证阶段
第三个阶段比较简单,耗时比较短,涉及人员也比较少,在进行第三个阶段的时候包含以下几个步骤和涉及的人员:
步骤 | 步骤目标 | 人员 | 任务内容 |
1 | 早期客户验证 | 销售 | 进行早期的客户验证,在小部分的客户群体进行产品试用,例如推出10-20家左右的客户 |
2 | 产品优化与验证 | 项目经理组织 | 对产品进行优化,fix修改,依据客户的反馈对产品进行调整 |
3 | 可获得性分析 | 产品经理 | 产品经理依据优化和客户验证进行可获得性分析,为接下里的可获得性决策提供依据 |
4 | 可获得性决策 | MM组和技术委员会 | 第二个ChekPoint决策点,决策是否要将该产品铺开到市场上去 |
发布阶段
在可获得性决策通过后就进入发布阶段,第四个阶段比较简单,耗时比较短,涉及人员也比较少,在进行第四个阶段的时候包含以下几个步骤和涉及的人员:
步骤 | 步骤目标 | 人员 | 任务内容 |
1 | 产品发布与市场宣传 | 产品市场 | 进行产品的发布,产品的宣传和验证 |
2 | 产品发布与市场宣传流程 | 项目经理等 | 项目经理对产品进行验收和总结,是产品积累的重要阶段,设计验证组进行盈利分析 |
生命周期阶段
发布完成后进入生命流程阶段,第五个阶段比较简单,耗时比较短,涉及人员也比较少,在进行第五个阶段的时候包含以下几个步骤和涉及的人员:
步骤 | 步骤目标 | 人员 | 任务内容 |
1 | 组建LMT | MM组 | 组建LMT,也即产品生命周期管理团队 |
2 | 持续产品运营流程 | 产品市场 | 产品市场为主持续进行产品的运营,项目经理和架构师进行产品维护和管理,设计验证组进行维护与改进成本,产品经理和开发进行维护与改进支持 |
3 | 下线决策 | 产品市场 | 产品市场决定产品是否需要下线 |
4 | 下线决策流程 | 项目经理开发产品 | 下线决策后,项目经理进行产品生命周期终止计划,开发产品进行下线支持 |
5 | 退出市场决策 | MM组 | 第三个ChekPoint决策点,决策产品是否退出市场,退出后IPD流程结束 |
了解了整个流程后我觉得最为关键的两个应该就是概念与设计、开发流程,也就是我们的评审和迭代主流程,其它的虽然也重要但是和开发人员其实关系不大,了解了解也没坏处,总体而言整个流程是围绕IPD核心理念设计的。