Question

1. 前言

本文对如何通过使用阿里云云效-专有云版本的需求管理和项目管理产品，实现软件产品的需求设计、讨论、定稿和管理进行了介绍。本文以一个软件需求为例，提供了从需求设计、交互设计、需求交互讨论修改、到需求交互设计定稿的全流程演示，供包括产品经理、项目经理、敏捷教练、开发人员、测试人员在内的客户作为参考使用。

---

2. 最佳实践概述

软件需求设计是 DevOps 的重要环节之一，历经了传统瀑布、敏捷研发等多种模式的变革，是一个由来已久的话题。同时，该环节本身也是一个较为复杂的流程，涵盖用户需求的产生、产品需求的设计、交互的设计、各种设计的讨论、工作量的评估、需求的排期和版本制定、验收交付等环节。因此，如何实现整个过程中质量和速度的平衡甚为关键。我们需要清楚地知道：在软件的需求设计中，哪一步骤的质量须优先于速度，哪一步骤的速度又须优先于质量，以及具体的执行方法。此最佳实践文档的目的便在于此，希望供大家参考。

【适用场景】

• 传统的瀑布研发模式
• 基于微服务的敏捷研发模式
• 远程多地协同的研发模式

【方案架构】

• 需求生产交付流程图如下：

【方案优势】

• 减少需求不清晰带来的技术返工，节省技术资源，缩短工时。
• 减少需求阶段各方工作上因理解不一致产生的矛盾，使彼此合作更顺畅。
• 合理化版本排期，减少不必要的变动。

---

3. 前置条件

在执行本文操作前，请完成以下准备工作：

• 所在公司已购买并开通云效项目管理、需求管理产品模块。
• 已注册云效账号并完成认证，可以登录云效平台。
• 完成云效产品培训并通过相关考试。
• 加入云效的钉钉答疑群（联系本公司云效接口负责人入群）。
• 产品需求相关方（业务方、PD、UED、PM、技术架构、开发、测试、验收等）已经通过钉钉或企业微信建立实时通信群。

---

4. 工具准备

• 本方案使用 Chrome 浏览器，需提前准备。
• 安装钉钉或企业微信。

---

5. 使用流程

5.1 起草用户需求

【背景说明】：业务方（售前、运营、销售或产品经理）或 PD（产品经理）根据之前的用户反馈或产品规划，起草原始用户需求，为需求讨论提供必须的材料。

【操作步骤】：

1. 在云效中的某个项目或项目集（事先需创建好），点击名称进入该项目或项目集。

2. 点击左侧导航栏中需求。

3. 点击新建需求，进入用户需求编辑页面。

4. 在需求编辑页面编辑用户需求时，需填写：需求标题、需求背景、需求目标、用户使用场景、产品现状截图。

   「用户需求」是需求讨论会（尤其在远程多地协同研发的情况下）的主要材料，是需求整个生产交付效率和质量的关键点之一，一份好的用户需求关键在于以下两点：

   • 是否清晰阐述了用户需求背后的原始述求。
   • 是否做到了用户需求的清晰明确，无歧义。

「用户需求起草范例」见下图，范例右侧指派给 PD 并填写了期望的优先级和期望日期，让我们通过范例正文来看一下是如何做到上述两点的：

• 标题清晰：须能概括用户需求内容（比如：用户类别、涉及的产品功能、优化类/定制类/缺陷修复类等），便于后续需求生产交付流程中的查找和筛选。
• 需求背景：须清楚描述该用户需求背后的原始述求，即：若不做该需求，则用户或业务会发生什么困难、发生困难的原因等。
• 需求目标：须清楚描述该用户需求完成后能在多大程度解决客户或业务的问题。尽可能量化和明确，避免含糊。
• 用户使用场景：须清楚描述用户需求涉及的所有场景，避免遗漏，此部分内容是产品设计的基础。
• 产品现状截图：此部分是为了更好地说明用户使用场景中的内容，因此需结合用户使用场景进行逐一截图。俗话说：“百闻不如一见”，再好的文字描述也不及截图的直观清晰。用户使用场景 + 产品现状截图的形式可迅速阐明问题（尤其适用于远程多地协同研发的情况）。若截图仍不能清楚说明用户使用场景的问题，则可采用远程桌面演示的方式做进一步说明。
• 重要提醒：在用户需求撰写阶段，切记不要出现极其简短、含混不清的描述，也就是俗称的 “一句话需求”。用户需求并非自己所做的笔记，而须站在他人角度进行撰写，以使他人轻松、清楚地明白需求内容。若遇到 “一句话需求” 的情况，产品经理作为承接方可直接打回，要求用户需求撰写者进行修改。

5.2 用户需求讨论

【背景说明】：用户需求讨论环节的目的是使业务方、PD、技术经理对用户需求的理解一致，并决定是否交付以及初步确定交付优先级。在远程多地协同研发的情况下，可使用钉钉或企业微信发起远程视频会议，对照用户需求草案进行讨论。讨论会可由 PD 或 PM 召集或业务方召集，可进行多次讨论。

【操作步骤】：

1. 经过讨论，在对用户需求的理解和优先级达成一致后，若确定交付，则进入需求编辑页面，将其状态设置为已确认需求，并调整优先级。
2. 若确定不交付，则进入需求编辑页面，将状态设置为已取消。

5.3 产品需求设计 & 交互设计及讨论

【背景说明】：在决定交付需求的情况下，业务方（非必须参加该环节，但参加更好）、PD、UED（交互设计工程师）、PM（项目经理）、技术经理、开发、测试，根据已确认的用户需求讨论（在远程多地协同研发的情况下，可远程发起钉钉或企业微信的视频会议）产品需求和交互设计。

讨论会由 PD 召集和主导、产品需求设计工作由 PD 负责、交互设计工作由 UED 负责，上述设计的工作和讨论会交替反复进行，直至所有角色对产品需求设计和交互设计的理解趋于一致，以为产品需求和交互设计的最终定稿做好准备。由于产品需求及交互设计周期（第一次需求讨论到设计定稿）会影响需求交付周期，因此，需要 PD 和架构师根据业务需要商量并达成一致。

说明：产品需求和用户需求存在本质区别。前者由 PD 起草，是技术团队进行开发的依据；后者由用户、业务方或 PD 起草，是 PD 和 UED 进行产品设计和交互设计的依据。

【操作步骤】：

1. 所有角色基于确定的用户需求进行产品需求设计和交互设计的讨论，其目的是使所有角色对用户需求理解趋于一致，并对现场可能产生的产品需求和交互的大致方案交换看法，识别出设计上的一些难点。

2. PD 和 UED 使用 axure、sketch 等常用设计软件，基于用户需求完成产品需求设计和交互设计初稿。完成后，建议把产品需求和交互设计初稿整合在一起，并将整个文本放入需求编辑页面中（用户需求后面），如下图所示。 或者在用户需求后放入产品需求和交互设计文档链接。

   产品及交互设计初稿的内容需要注意以下几点： 1）须匹配用户需求的内容，每一条用户需求都能从初稿中找到答案； 2）图文交错，文字一方面讲清楚逻辑，避免歧义，另一方面解释交互图中对现有产品的改变； 3）交互图要尽可能完整，任何交互的改变都应有图片展现。

3. PD 和 UED 在完成初稿后，PD 召集产品需求及交互设计讨论会，会上和所有角色逐一过设计内容。对不同意见进行讨论，在需求编辑页面（设计初稿的后面）做会议纪要，会后进行修改。该步骤反复进行，直至设计稿不再有不同意见。

5.4 产品需求设计 & 交互设计定稿

【背景说明】：当对产品需求及交互设计稿不再产生新意见时，业务方（非必须参加该环节，但参加更好）、PD、UED、PM、技术经理、开发、测试，验收开会（在远程多地协同研发的情况下，可远程发起钉钉或企业微信的视频会议）确定产品需求和交互设计的终稿（终稿保存在云效的需求编辑展示页面），并根据业务要求（时间、需求紧迫度）确认需求是否划分迭代以及如何划分迭代（讨论会由 PD 召集和主导）。

【说明】：若在定稿会上各方对设计仍然存在未达成一致的意见，则此次会议为讨论会，定稿会推迟到下次再开。由于此情况会影响需求交付周期，因此，PD 要尽力避免该情况出现影响需求定稿进度。不得在意见不一致的情况下仍然定稿（尤其在远程多地协同研发的情况下），以杜绝需求的反复。

【操作步骤】：设计稿各方在定稿会上确定定稿后，PM 在需求编辑页面将需求状态改为待开发，如下图。

5.5 需求技术开发工作量评估

【背景说明】：在产品需求及交互设计定稿后，PM（项目经理）、技术架构、开发、测试根据设计稿确定架构设计、开发、测试的工作量，该项工作由PM跟进。

【操作步骤】：

1. 工作量（架构设计 + 开发 + 测试）估算完毕后，PM 在需求编辑页面填入预估工时（如下图）。

5.6 需求排期及制定版本计划

【背景说明】：当需求工作量估算完成后，业务方（非必须参加该环节，但参加更好）、PD、PM、技术经理根据需求优先级、现有开发测试资源、现有开发中的需求（以看板方式展示，便于看到全局，如下图）确定需求排期进入哪个交付版本，该项工作由 PM 主导。

【操作步骤】：

1. PM 预先设置版本标签（如下图，在项目 > 设置 > 标签页面），如版本 3.14.0、必发（必须发布，代表最高优先级，轻易不能调整）。
2. 需求的排期讨论确认后，PM 在需求编辑页面选择相应的版本标签（如下图），标识该需求进入哪一版本，是否为必须发布（轻易不可调整）。
3. PM 通过标签管理版本下的需求。 具体方法见下图：在需求列表页面选择更多过滤选项，在下拉框中选择需过滤的版本标签号（如 3.14.0），点击过滤。
4. 然后，即可看到该版本标签下的所有需求。

5.7 需求验收及交付

【背景说明】：当需求开发 > 测试 > 集成完成后，业务方（非必须参加该环节，但参加更好）、PD、PM、技术经理、开发、测试、验收同学针对需求进行验收和交付，以最终确认交付的需求是否符合业务方的需要，该项工作由 PM 主导。

【操作步骤】：

1. 验收同学对测试同学提交的需求，按照设计进行验收。验收同学按照整个团队预先定义的验收标准（缺陷数量、重要性限制等）结合验收结果决定验收是否通过，并通过邮件反馈验收结果给上述相关方。
2. 验收通过后，更新产品文档。在远程多地协同研发模式的情况下，强烈建议让验收或测试同学使用钉钉或企业微信进行实操录屏直播回放给上述相关方，效果更佳。若验收未通过，开发和测试同学需快速修复不符合验收标准的缺陷，重新提交验收。验收通过率建议纳入技术团队考核，以减少同一需求验收次数。
3. 需求交付运维后，PM 在需求编辑页面设置需求状态为已完成，如下图。