没有需求池的场景和问题
信息丢失的问题
最近工作的时候，发现当开发的周期拉长之后，如果开发再问我需求的相关细节，就有点遗忘，这时候再向客户和相关人员求证就不太专业了。而且比较容易出现的问题是需求模棱两可的情况，如果记错了交予开发实施，等实际上线的时候再去改，成本就比较高昂了。
当面交流的缺陷
也是最近才发生的事情，在跟进需求的过程中，和后端人员沟通了需求的相关实现，结果在测试的时候，发现功能展示和预期不符，原因是因为后端和前端沟通的时候，信息存在了遗忘和加工的现象，传达到前端这里需求就面目全非了。这样的错误是很难杜绝的，但可以建立合适的机制去减少此类问题的发生。
记录的需要
之前在完成实例筛选器功能的时候，客户提出了一些优化的建议，我整理好了之后，去找开发人员口述了相关需求，原先想的是这是一个小需求，并且开发就和我隔了几个工位，所以就随意了一些。上线客户使用的时候，发现没有更新相关的功能，回去和开发沟通，开发说不记得和我沟通过了。这中间跨度比较长，而且当时没有留下记录，只能自己背锅了。如今复盘，发现记录留存是很重要的，最起码可以在出问题的时候分清楚责任归属，以前觉得老同事就隔着几步路还要发钉钉很奇怪，现在也终于理解了。
建立需求池
根据查询的资料和实际业务场景的需要，我建立的需求池有如下字段：编号、模块、功能点、需求描述、场景描述、需求类型、优先级、提出人、提出时间、需求状态。
以下是这些字段的详解：
1）编号：需求的唯一标识，可用序号罗列，也可以用日期+当天提交需求的序号统计；作用是作为每条需求的唯一编号和快速查询需求。
2）模块：根据产品模块去划分，例如“个人中心”作用是将需求统一归类到某个模块下，在进行版本规划时，可以优先从某个模块中筛选，同时便于根据模块查询。
3）功能点：简单描述需求的功能，也就是要做什么；这样我们快速查看某个需求时，能一眼看明白这个需求是要新增或修改哪个功能。
4）需求描述：需要描述清楚需求的完整性、一致性，需要精准的描述；如果产品经理在后续想不清楚这个需求到底要做什么，可以通过需求详细描述来回想或了解。
5）场景描述：了解用户在什么场景下产生的需求，便于我们分析需求背后的价值，在给开发转述为什么要增加这个需求时，可以清晰的说明是因为哪些原因，更能说服开发愿意做这个需求。
6）需求类型：
- 新增功能：目前平台没有实现的功能；
- 功能改进：对目前平台已实现的功能进行优化；
- bug修复：系统功能使用出现问题，与正确的设计逻辑不一致；
- 用户体验：例如页面按钮摆放的问题，发送消息时发送按钮放在右侧，可以按照用户的使用习惯设计；
- UI优化：页面体现内容，如按钮颜色；
- 内部需求：公司内部产生的需求，如开发一个内部OA系统；
- 删除需求：对平台已有的功能进行简化；
- 接口需求：使用对方提供的接口，或给对方提供接口。
7）优先级：P0紧急重要 → P1紧急不重要 → P2不紧急重要 → P3不紧急不重要；可根据实际情况根据商业价值、需求类型、需求层次等信息综合判定优先级，按照四象限法则将需求分别放进这四象限中，最后按照顺序一一完成；可以帮助产品经理有条不紊的完成工作，也可基于优先级这几个分类考虑到版本规划中。
8）提出人：原需求的提出人，便于日后有疑问可追溯。
9）提出时间：需求的提出时间，方便我们了解是什么时间提出的需求，同时可以利用提出时间来规划需求的紧急程度。
10）需求状态：需求的生命周期，待讨论、暂缓（标注原因）、拒绝、需求中、开发中、已发布；主要作用是可以对需求的流转状态进行跟踪，可以了解需求在不同阶段的状态，发现问题及时调整。
11）备注：其他任何信息，如：需求期望完成时间、被拒绝原因、暂缓原因。
以下是设计的需求池模板：
小结
需求池建立完毕之后，放在公司的知识库里定期维护就可以了，也方便其他同事看具体的需求，同时注意一下开发进度表的任务状态，及时更新需求状态即可。
评论 (0)