数字化转型与架构 - 规划篇｜PRD 也适用 SMART 原则？

SMART 目标定义原则

　　"SMART"原则是一个常用的目标定义原则。它由五个关键要素的英文首字母组成。

Specific（具体的）：目标应该明确要求和标准，使用具体的名词来描述行为、环境和结果，而不是使用模糊不清的形容词。

Measurable（可衡量的）：目标进展情况可以被量化和测量，以便定量地跟踪和评估达到的进度。

Achievable（可实现的）：目标应该具有挑战性，并且在给定的人员、资源和时间的限制条件下可实现目标。

Relevant（相关的）：目标与个人或组织的整体目标一致，对整体进展有益。

Time-bound（时间限定的）：确保目标有明确的时间截点，可以进行监督和管理。

　　PRD（产品需求文档 Product Requirements Document）是需求调研阶段的最终交付物，包含了所有的调研结论。PRD 是下一阶段工作的输入成果，不但为团队分享产品定义的信息，还为团队指引工作目标。因此，SMART 原则也可以用来检验 PRD 的准确性、完整性和有效性。一篇 PRD 应该由以下五大部分和八个章节组成。

第一部分：与企业战略的相关性

　　产品概述章节描述了实现的目标，可以检验此产品的开发成果是否在战略路径之上。开发成果是否有助于战略目标的实现。产品概述是对产品进行的总体描述，介绍产品的定位、核心价值、关键目标成果和相关背景信息。 产品定位和效果决定了目标用户人群；目标用户自身的特性决定了对核心价值的诉求；关键目标的实现又决定着是否能获得目标用户的认可。

产品概述示意图

第二部分：用户的具体要求

　　用户需求章节描述用户需要和期望。需求应该具体到用户遇到的问题和挑战，问题产生的背景和解决问题的条件限制。这是规划篇主要在探讨的问题。 

第三部分：可衡量的工作项

　　解决方案包含了满足用户期望的方法及实现路径。将解决方案按照四个视角进行拆解，保障细化后的每个工作任务可追踪进度。前三个视角与 MVC 开发框架的设计理念相似，第四个视角补充前三个视角未包含的所有内容。从下图我们可以看出业务模型与技术模型有很多的相似之处，所有技术解决方案都可以从现实世界中寻找到答案。

三个视角和 MVC 关系示意图

　　功能需求章节描述产品需要实现的各个具体用途。描述每个功能应该包括：用例及操作流程。用例是此功能实现的一个完整示例，示例可以描述执行的全流程。

　　结构化的用例包括以下几个部分：用例名称、参与者、目标、前置条件、主要场景及替代方案、后置条件。用例名称是管理用例的唯一标识。其它几项分别描述了，谁（参与者）在什么情况（主要场景）下，做了什么准备（前置条件）要干什么（目标），最后的结果怎么样（后置条件）？

　　数据需求章节描述产品运行过程中处理、存储的数据内容、格式和数据的要求。数据需求描述的是系统中流转的数据，所以数据应用中数据展示的形式属于功能需求，数据展示的内容和如何提供数据属于数据需求。

　　数据需求包括：数据需求名称、需求描述、数据内容、数据来源、数据使用。数据需求的描述非常简单，可以总结为四个短句：谁为什么要，都要了什么，它从哪里来，它到哪里去。这个句型非常像一个哲学问题：我是谁？我从哪里来？我要到哪里去？

　　界面需求章节描述用户和系统是如何通过界面实现沟通和交互，一个优秀的交互界面模糊了人与机器的边界。通过界面，用户可以使用系统功能并控制系统的运行。

　　界面需求描述产品的用户界面和交互设计的要求，包括：界面需求名称、需求描述、界面元素、界面布局、界面样式、界面交互。界面需求的描述就像看图说话，不仅仅是叙述画布上的“色块"，而是一个个生动的故事。

　　非功能需求章节描述系统自身运转相关的指标和要求。站在技术视角，大家总认为没有业务的牵绊可以开发一个完善的系统。现在我们看看，一个系统在满足业务需求的情况下，还要满足哪些需求。

　　硬性指标：响应性能指标、并发性能指标、容量指标、平均无故障时间、平均修复时间、平均实效间隔、数据备份周期、数据备份保存周期。

　　安全需求：用户认证、授权、鉴权、操作审计；数据传输加密、存储加密、数据脱敏等。

　　高可用需求：系统各组件有冗余方案。在部分节点故障时，系统依然可以提供服务，并自动完成故障转移。系统有完备的监控和告警机制，系统故障时可及时通知到相关人员进行干预。系统在规定的修复时间，通过人工干预可以恢复到正常状态。系统数据有备份机制，在系统宕机时可使用备份数据对系统进行数据恢复。

　　可维护性需求：系统具备统一管理设备资源、服务部署、服务运行管理、日志收集等自动化管理手段。系统自身的日志可以集中管理展示，快速定位系统线上问题。

　　以上这此指标和要求，根据不同的系统还有更细化的要求。产品需求调研过程中，应根据系统业务的重要程序酌情设置指标和要求。

第四部分：时间节点

　　优先级和时间表章节确定各个功能和特性的优先级，制定出开发进度的里程碑和对应的时间节点。虽然 WBS 粒度的工作计划表还不能被制定出来，但是项目的路线图已经可以有一个预估的时间范围。

路线图（里程碑）时间节点示意图

第五部分：可实现的条件确认

　　前面四个部分已经对所有待办任务有了一个完整的描述和分析。下面我们要考虑一下自身的能力情况和环境约束，这些也是我们即将面临的挑战。

　　限制和约束章节描述企业内外部的环境对产品开发过程中的影响。限制主要包括：团队人员、成本控制、专业技能及专业设备等。约束主要来自国家法律法规、行业标准和平台生态协议等，对企业经营业务范围的限制。

　　整个 PRD 并没有按照 S、M、A、R、T 的顺序进行检验，而是按照做事情的思考过程进行了调整。

RSMTA 顺序示意图

　　PRD 是需求调研的最终交付物。PRD 撰写完成意味着我们已经获取到充足的业务信息并完成结构化的整理。PRD 经过确认之后，我们就要进入系统建模阶段。