通常，我会如下记录一个新需求。
1. 标题：需求是什么
2. 内容：用户原文（必要时会补充自己的理解）
3. 用户账户情况：账号注册时间和消费历史
4. 反馈来源：工单／QQ／微信／电话等，用于进一步沟通和上线后的通知
再收到类似反馈，叠加上去，由产品经理评估。如果产品经理出于各种理由暂不考虑此需求，那就进行汇总，形成简单的报表，直观呈现给他们。
我一直以为自己做得不错，比较细致和耐心，直到 3 月的某个周末，大 BOSS 突然将过去一年提交的用户需求翻了个底儿掉，并对未考虑开发的需求追问了原因或做了评论。举个栗子。
一位做报名的用户希望我们像某友商那样，将底部「提交」按钮固定悬浮于当前页面某个位置，以便告知报名者「嘿，这里可以报名哦」，并方便填写人随时点击。我看了下友商的提交样式，心下了然。这个需求记录后不久就被产品经理挪到了「不考虑」之列，未说明原因，我也没有追问。BOSS 是同意「不考虑」的处理结果的，但他补充了原因：在我们的场景里，不需要刺激用户点击保存。相对而言，数据的质量比较重要。
我紧张地关注着不时弹出的更新通知，越看越觉羞愧，原来我已经对日常工作变得十分麻木，没了之前追根溯源的热情；看到他对某些需求一针见血的分析评论，更让我深刻感受到对于同一件事情的看法，我的显得如此浅薄。我只是在「记录」，缺乏对用户使用场景的深入了解，也极少思考我们目前的业务范围和产品属性。
醍醐灌顶之后，我开始留意产品经理们是如何分析用户需求的，并尝试着自己总结成以下几点：
一、了解用户的使用场景
有个不断被提及的需求，地址信息可以转化成经纬度保存到本地。这是个比我入职时间还长的需求，一直是「不考虑」的状态，所以我收到后未做他想，直接追加到以前的记录里。直到这次被 BOSS 重新找出来，产品经理再次进行评估时，问了我一句：你知道用户的使用场景是什么吗？我当时就愣住了，赶紧找回用户，重新询问。
使用场景通常包含用户所处行业和业务流程。我们不试图针对某一行业，解决其 100% 的问题，能解决其中某个环节并在其他大多数行业中具备普适性即可。
二、使用场景的细分
「打印时可以调整页面样式」也是反馈频繁的建议，我大概清楚用户是要打印员工证、订单之类的，但是简单的追加用户信息后，我没有想过对场景加以细分，这部分工作是后来产品经理与用户直接沟通，补充了足够的信息后完成的。场景的细分可能涉及到功能实现的不同。
三、需求的归纳总结
同一个页面，有的需要超链接，有的想自定义文案，这其实就是一个「富文本编辑」的需求；有的人希望记录填写人的手机设备识别码，有的希望电脑名称，其实都是想判断填写人的唯一身份；有些人打印时不想要分割线，不想要为填写的信息，其实就是这个功能的一系列小优化。
四、发散思考
用户希望知道某页面的浏览次数，BOSS 看到这个需求后，考虑得更多更广：其他页面的浏览器次数呢？除了浏览次数，访客 IP、国家、城市，操作系统，停留时间呢？如果这些数据按小时、按天、按周、按月的统计数量形成曲线和对比，是非常打动需要此类数据的用户的。
最后说件有意思的事情。
产品经理小冰最近收到一个用户需求，希望在填写页面展示该页面的浏览量和填写量，让填写者感受到这个页面的热度。市场部小野同学直言：我们没有设计展示给「用户的用户」的数字，这跟很多投票软件一样，太烟火味了，不工具。客户成功妹子问「烟火味」是指什么？小冰的解读很得我心：「性冷淡、高冷」。归根结底，就是我们的产品属性，这是我在需求管理中，不能忽视的。
网友评论