上一篇blog可谓IPD最为核心的部分，也就是IPD的主要流程，在上篇博客中我详细介绍了IPD的各个核心阶段以及每个核心阶段的细致流程、参与人员、每个人的具体职责，那么相信大家对整体的流程以及流程对IPD理念的实践和要解决什么问题都比较清楚了，新的研发流程下和旧的相比就有很多的优势：
本篇博客介绍IPD的主要模块，也就是涉及到的一些模板：
其中比较核心的是：项目计划（管理）、PRD、技术架构和一页纸四个模板，除了这几个之外还有一些评审的模板。当然并不要求每一个都按照模板来做，但可以参考其中的理念，更多提供的是方法论。
项目管理
主要编写人是项目经理，主要包含以下几个部分：项目组成员、项目关键文档、项目计划、重要沟通、风险管理、重要变更。
- 项目组成员必须记录，因为一个项目组的成员可能来自各个资源池，所以需要有一定的标准，包括定义这个成员的：职位、姓名、投入工作量、工作内容和主管经理
- 项目关键文档需要标识这个文档的：分类、文档名称、描述、创建时间、输入方/作者、链接，这几个关键要素
- 项目计划也是必须的，并且需要详细记录任务的进度和状态：
- 重要沟通表示在项目过程中的一些重大问题的记录，包含：沟通工作、负责人、参与人、时间、计划目标、成果这几个比较重要的方面
- 风险管理在之前是比较缺失或者不透明的，现在需要加紧建设，包括：风险定义、风险类别、风险原因、风险影响范围、风险级别、处理方式、解决状态几个方面
- 需求变更标记需求的一些变化，也是必须要记录的，包含以下几个方面：类型、问题 、目的 、提出者、 提出时间、 影响、 优先级、 状态、 解决方式 、结果 、解决时间 、解决过程这几个方面。
其中项目组成员、项目计划和需求变更是比较重要的几点。当然还有一些周报的模板：
以及项目会议记录的模板可以参考：
除去以上8八部分之外，再加个封面就是一个完整的九部分的项目计划书了，项目经理可以据此hold整个项目。除此之外，建议项目经理再做一个项目计划（kick off）的PPT来增强仪式感。
产品设计PRD
产品设计模块包括：产品架构设计PRD、产品概要设计PRD、产品详细设计PRD三部分，三部分从前往后由大到小，负责度由高到低，使用频率由低到高。
- 产品架构设计PRD使用的比较少且复杂，如果不是特别大的项目简单做一下即可。一般使用和制作者都是比较高级的产品经理甚至产品专家。
- 产品需求设计PRD是我们最常用的一个模板，是一个相对整体性的设计，包含整个项目中涉及到的全部需求和场景分析，是一个比较整体性的设计。
- 产品模块设计PRD是某个单story的模板，是在产品需求设计PRD拆分出来的模块的具体设计，是针对单模块的比较细致的设计。
了解了整体的三个PRD的关系，接下来详细了解下这是三个常用PRD的结构
产品架构设计PRD
产品架构设计PRD我感觉更多的是形而上的东西，更侧重在整体的流程、配合方式、架构方式等，并不是细致的内容，所以一些简单stroy或者项目不需要这部分。
| 步骤 | 子模块 | 子模块内容 |
| 1 | 文档控制 | 包含变更记录部分内容 ,控制整体产品节奏 |
| 2 | 概述 | 产品概述及目标、产品roadmap，详细目标规划 |
| 3 | 产品架构 | 产品的整体架构设计 |
| 4 | 使用者需求 | 使用者角色、主要流程与描述 |
| 5 | 交互体验框架性需求 | 主设计基调、整体设计是怎么样的，对用户体验的目标进行描述 |
| 6 | 功能需求 | 也就是通俗意义上的功能细节需求 |
| 7 | 业务数据 | 每个模块的详细业务数据 |
| 8 | 系统架构性体系 | 系统的整体架构设计 |
| 9 | 各部分设计文档清单 | 涉及到的各个部分文档清单汇总 |
| 10 | 测试需求 | 说明是否需要BETA测试，BETA测试的要求及期望达到的目标等 |
| 11 | 非功能需求 | 产品营销需求、规则变更需求、产品服务需求、法务需求、帮助需求、安全性需求 |
| 12 | 上下线需求 | 上线时限需求、下线需求（活动类需求必须明确下线时间） |
| 13 | 效益成本分析 | 效益预测、产品技术中心成本、非产品技术中心的支持成本 |
非功能需求的一些说明：
- 产品营销需求（说明使用的推广方式、目标受众以及是否有限制或特殊要求？ (网站运营部应提供主要内容）
- 规则变更需求（本产品可能涉及到的规则的变更）
- 产品服务需求（产品上线是否需要客服协助？此产品计划的服务优先级和重要性如何？当此产品上线后，想要从客服中得到什么信息？）
- 法务需求（说明与隐私权、知识产权、专利权、商标、服务条款(TOS)、版权、合同责任、客户沟通等相关之法务议题或需求）
- 帮助需求（提供内部使用者或者客户在使用此产品时所需要的任何说明文件或帮助，比如线上帮助、CRM知识库、FAQ等）
- 安全性需求（产品需符合网络安全部的相关规定）
这几类需求比较详细，记录下说不定以后可以用到。
产品概要设计PRD
产品需求设计PRD是一个项目中整体需求的分析，总模块的介绍，需要注意里边最好设置产品的版本和版本基线。
| 步骤 | 子模块 | 子模块内容 |
| 1 | 文档控制 | 包含变更记录部分内容 ,控制整体产品节奏 |
| 2 | 概述 | 背景、目标、模块规划、产品基线、产品风险 |
| 3 | 关联文档 | 描述和产品规划、MM、需求相关（如MRD）、运营文档、产品Proposal相关的文档 |
| 4 | 使用者需求 | 从使用者的业务场景描述使用者身份，身份描述。需求场景，需求流程图，以及详细需求描述 |
| 5 | 功能需求 | 身份描述、功能总览、业务数据描述 、功能权限表、功能详情 |
| 6 | 非功能需求 | 性能需求、帮助需求、安全性需求、报表需求、数据运营需求 |
| 7 | 上线运维需求 | 上线的一些运维策略 |
其中概述部分内容的详细规划如下：
- 背景：阐述本次设计的背景和原因，包括问题
- 目标：阐述本次设计的目标，包括客户价值、特性，解决的问题等，大致场景，或者满足产品规划等
- 模块规划：阐述可能的阶段和阶段规划
- 产品基线：阐述本设计基于的产品版本基线
- 产品风险：阐述产品风险）
其中使用者需求部分内容的详细规划如下：
- 用户与组织范围：对组织范围、用户进行描述
- 业务流程与需求：对业务需求进行描述，可以包括流程图，流程描述，输入输出等
- 业务模型：使用流程图、Use Case等工具描述业务需求
如果把数据关系等做扎实，那么以后调整花费的时间就不需要那么多了。
产品详细设计PRD
这一份story级别的PRD实际上是上面 一份的PRD的子模块：
| 步骤 | 子模块 | 子模块内容 |
| 1 | 文档控制 | 包含变更记录部分内容 ,控制整体产品节奏 |
| 2 | 业务场景或问题来源 | 为什么要做这个特性？描述客户业务场景，或需求的问题来源 |
| 3 | 目标 | 支持哪些场景、哪些功能、实现的效果；以及此特性给客户带来的价值 |
| 4 | 产品解决方案 | 最核心的部分，包含产品的整体解决方案 |
| 5 | 上线准备事项 | 上线的时候需要准备的一些工作 ，需要平台协助的内容、以及实施需要对租户进行相关配置的事项 |
对于产品解决方案有必要详细阐述一下，以下几个过程比较重要，在做产品设计的时候需要通盘考虑一下：
- 业务流程及业务模型，业务流程指用户日常处理该业务的流程，一般用语言文字或流程图描述，业务模型指产品使用过程中需要完成的各种任务的流程，一般用泳道图或流程图描述
- 原型/交互：关于页面交互操作的详细描述，可以是示意图、或原型
- 数据结构：领域对象（业务视角）、字段的详细描述
- 产品规则：描述功能的详细业务处理规则、校验规则等
- 关联系统或者功能影响：与其它产品的交互和对接
- 接口相关设计：对接口的影响，包含读取、同步、回写、拉取接口
- 数据相关设计：原有业务数据的修复升级规则等需求
- 非功能需求：性能相关需求，运营、埋点相关需求
以上就是整体的需求设计和分析。比较好的使用方式是在wiki上建立好相关的目录结构，大家一起来维护一下。
技术架构设计
技术架构设计需要和产品架构设计及业务架构设计结合比较好一些，整体的目录结构如下，技术设计的时候需要考虑这些点：
| 步骤 | 子模块 | 子模块内容 |
| 1 | 引言 | 包含背景、目标、术语与缩略语、参考资料 |
| 2 | 整体范围 | 包含功能需求、需求边界是明确执行范围的边界，阶段内应做什么，不做什么 |
| 3 | 总体设计 | 包含架构设计目标、技术及设计约束、领域建模、架构设计、业务流程设计 |
| 4 | 接口设计 | 包含系统外部接口、系统内部接口 |
| 5 | 数据架构 | 包含数据模型、数据存储 |
| 6 | 非功能设计 | 包含性能、可靠性、安全性、可维护性 |
| 7 | 关键技术设计 | 包含技术选型、技术预研、风险识别与防范 |
| 8 | 部署架构 | 包含系统部署，网络拓扑，服务器要求等。 |
| 9 | 其它说明 | 补充上述未列出事项的描述。比如需要其他系统支持配合等情况说明 |
技术一页纸
技术一页纸需要考虑的很详细，我个人也非常喜欢写技术一页纸，提前可以规避很多坑，整体的目录结构如下，技术设计的时候需要考虑这些点：
| 步骤 | 子模块 | 子模块内容 |
| 1 | 业务流程图 | 实现流程、时序以及输入输出 |
| 2 | 详细设计 | 技术详细设计，包括领域模块、类间调用关系 |
| 3 | 影响点评估 | 对现有业务的影响点评估 |
| 4 | 工作量评估 | 到人天 |
另外还有对应的测试一页纸方案，这里就不详细说明了。
总结
本篇blog详细介绍了四个比较重要的模板，包括：项目规划、产品设计、技术架构、技术落地一页纸，其中产品设计又依据复杂度分为三个模板。当然除此之外还有一些我们平时用不上或者不怎么需要了解的模板，例如评审的模板（架构与概要设计评审、技术架构评审、详细设计评审、一页纸方案的评审）这里就不一一详述了。感觉整体的模板还是比较庞大的，初期接入一定会有不舒适感，觉得要填的东西太多了，但是规范化后，虽然繁杂一些，但会变得更清晰，系统的庞大必然需要流程的规范，这样系统才会稳定。不再盲目的打补丁！
