需求管理

2021-08-19

7分钟阅读时长

研发需求，是研发行为的初始，需求不明确，理解不到位，都会直接导致研发方向的偏差，导致研发结果失败，影响项目的上线进度，浪费研发成本和项目的人力资源。所以，规范的第一步，就是研发需求的规范和管理。

由谁提出需求？

大部分的需求来自于运营和策划。来自运营的需求，主要是有关线上活动或者用户体验有关的。来自策划的需求，主要是新功能或者功能调整等。

项目组内任何成员，都可以针对产品提出优化、改进建议，从而形成需求。

来自项目组外的人员，比如：其他项目组成员、项目合作运营方人员等，也可能会针对产品提出建议或者要求，尤其是合作运营方人员，从而形成需求。

如何提出需求？

需求提出的方式，有很多种，比如各种口头（包括电话）方式提出的，QQ 等聊天工具提出的，邮件提出等。

口头需求的提出，存在需求表述不清晰、理解不准确、容易遗漏、不能跟踪、不易交流等弊端，任何口头提出的方式，都是不建议甚至是禁止的。

QQ 等聊天工具提出的需求，虽然是以文字形式提出，而且，也能附加图片等信息，但是，也存在容易遗漏、不好跟踪等问题，只适合研发内容简单、研发团队在 7 人以内、办公环境相对集中的小团队。

某些任务管理系统（比如：JIRA、BugZilla、Mantis、Redmine 等），具有简单的任务分配和跟踪功能、能追加评论、延误提醒、邮件提醒等。还可能具有里程碑和标签功能等。但是，或者过于简单，或者过于重度、过于复杂，流程复杂、应用和推广难度较大，对项目成员的要求高。

邮件系统也是需求的提出方式之一，电子邮件灵活方便、应用难度不大，但是，对项目成员的自觉性要求高。

在研发早期，团队成员（含非开发人员）不超过 7 人左右时，可以考虑使用某种简单快捷的项目管理或者任务管理系统。

团队成员超过 15 人以上时，项目管理系统（项目计划、需求管理、任务分配、错误跟踪）的应用就需要考虑了，尤其是开发周期在 6 个月以上，研发人员占整体项目人员比例超过 70% 以上时。

不管团队规模多大，也不论项目开发处于那个阶段，团队中电子邮件的应用是必不可少的，电子邮件应用门槛低、方便、快捷、灵活。综合来看，不管应用哪一种项目管理软件，主要的输出方，都是策划、运营这类需求提出者，以及 QA 这类报告人员，而作为主要的开发人员，大部分时间都只是信息的接收方。

各类项目管理、需求管理的工具和软件，都只是辅助的管理手段，能提高管理效率，但是，并不能减少管理中所需的协调和交流，相关的每日站会、周报、里程碑管理、版本管理等，都不能少。

所以，只要加强信息输出方的要求和管理，在不使用或者少量使用任务管理系统的情况下，使用电子邮件，也能很好的完成需求管理的要求。项目管理者，应该加强自身的管理和要求，借助相关辅助工具，做好项目管理、需求管理、任务分配、发布上线等工作，减少研发人员在研发管理方面的负担（不论管理系统是简单还是复杂），让其能安心工作。

需求有哪些类型？

单纯的 UI 修改
单纯的数值修改
新功能或者新活动开发
现有功能或活动调整
仅服务器端的性能优化
游戏客户端 SDK 接入
内部工具的研发
游戏管理后台的调整和修改
玩家补偿发放
玩家充值掉单处理

如何管理需求？

任何会影响线上环境的需求，都必须以书面的形式提出，以便后续的研发、测试、部署都有明确的依据；

任何需求的变动，都必须以书面的形式提出并追加更新到原有需求之后，可以废除原有需求文件，但是，不能删除；

除非有项目 PM 的明确授权，否则，任何没有经过项目 PM 审核的需求，都不能进入研发进程，更不能发布上线，擅自操作的行为，须承担全部后果；

项目 PM 或者项目 PM 明确授权的责任人（研发进度统筹人），有责任和权利及时审核所有提交的需求。审核不通过的需求，须给出理由，审核通过的需求，对其进行排期，更新和维护项目整体的研发进度表，在必要时，及时组织相关研发人员和需求方等，召开需求分析会议，商讨需求的可行性，明确责任人，确定开发进度安排。在需求发生变动时，尤其是具有较大变动时，及时协调相关人员对工作做出调整，并做出说明，更新研发进度表。

因需求审核不及时导致的进度延误，或因需求理解不一致导致的返工，分工不明确导致的懈怠延期等，研发进度统筹人均承担首要责任。

研发进度统筹者，定期（每周）给出研发计划进度表、上线里程碑等计划文档，及时通知项目组内人员，协调整体的开发进度和计划。（参看《简明指南及自查手册》部分的策划篇）

在需求不明确的情况下，研发人员有权不予开发。

需求管理规范操作

前提要求

所有需要付诸实施的需求的提出，禁止采用口头传递的方式，必须采用书面文字进行描述。具体执行人有权拒绝口头下达的任何任务。
所有需求都需要经过项目统筹人的审核，再分配到前后端主程、主策、主美，由他们再进行协调分配到具体的执行人。任何未经审核的需求禁止执行，擅自执行的行为人承担全部后果。

操作流程

新需求，在项目的任务管理系统中添加一个新的任务，填写标题、需求描述，分配人统一到项目统筹人，不要填写里程碑和标签，这两项由项目统筹人来进行统筹。如果涉及到比较紧急的需求，在需求描述中向项目协调人陈述。需求描述中，还可以上传辅助说明的图片。需求涉及到的策划案等文档，需要在描述中说明文档下载地址。需求文档，建议在项目中建立专门的目录放置，组成员更新项目版本库，即可获取到。文档的更新也通过版本管理系统进行统一版本管理。
项目统筹人，查看提交到自己的需求（Assigned to me），审核并分配给对应的开发人员，根据具体情况，可能会需要创建新的任务来替换，或者分为多个子任务等。比如：

某需求提过来后，经过分析了解，发现需求重复了，则需要关闭需求，并留下说明，处理结束。原需求提出人看到后，就会了解情况；

某需求提过来后，经过分析了解，发现需求表述不正确，或者修改原需求，或者关闭原需求，创建新的需求，根据实际情况操作，并留下说明告知原需求提出人。

某需求提过来后，经过分析了解，发现需求需要前后端、策划、美术等多人，则可能需要进一步细化、分拆任务等。

项目统筹人，需要给每一个提的任务设置标签（调整不正确的标签）。标签用来对需求任务进行分类，比如：建议、文档、功能、优化、错误等。对需求任务的状态进行标注，比如：讨论中、已确认、进行中。
任务的关闭，只能由项目统筹人来进行关闭，其他成员可以添加任务，为任务添加标签、添加评论说明、把任务转回给项目统筹人，不允许进行其他操作。
以每次上线部署作为一个里程碑，项目统筹人将每个需求分配到对应的里程碑中去，不需要上线的需求，不需要分配。这样的话，每次上线部署对应到里程碑，其中所作出的变更：新功能、修正和增强等的操作，就很清晰了。每个需求任务都有一个唯一的编号，比如：#23 ，在其他计划邮件、总结邮件、公告邮件、测试邮件等所有文本描述的地方，都可以引用，用来准确定位需求任务。
项目统筹人需要及时关闭已经完成的任务，并及时审核新增加的任务，督促组员将所有需求都体现到任务里，建立起组内的工作流，让组员养成围绕任务工作的习惯和氛围。
每周一，根据现有任务以及里程碑，撰写《每周研发及上线进度统筹计划表》。
每日，根据当日工作情况，汇总撰写《每日研发及上线工作总结》邮件，当日机动产生的需求，要及时体现到任务中。

使用任务管理系统需要考虑的问题

系统是否具有发送邮件的功能，能不能使用邮件进行提醒（有新需求和任务、任务状态变动等）。
系统是否支持一个任务分配给多人，对于一些需要前后端甚至策划多人配合完成的任务，需要很好的体现。
研发团队内，需求的提交，采用文字提交的习惯如何养成？需求变动如何同步到任务（在具体执行过程中，容易遗忘，尤其在变动频繁时），不然，很容易导致成为一种形式。
系统是否支持上传除三类图片外的其他文件，比如 word 文档、PPT 文档等。可以考虑使用版本库来进行文档的保存，文档使用专门的目录规划保存。