野路子的产品心经：2017这一年遇到的10点产品问题

2018-03-05 14:18:00

踩多少坑都不怕，只要你记得抽空进行问题总结，以及接下来的计划安排，下次总会做的更好。

距离我上一篇文章，整整隔了一年，由于换了公司忙的飞起，每个月的一篇文章被加班取代了。针对17年的工作，不反省自我，总结经验，对不起那些想杀我祭天祈求2018年风调雨顺国泰民安的开发啊~这周抽出了时间总结了2017这一年遇到的问题，以下总结10点：

1、需求评审粗糙或缺失

答：
（1）注意好会议前
召集好相关人员参与会议。定好时间、会议室、记录人。
（2）会议中讲解需求流程

需求背景：概述需求从哪来，为何要做这个需求。
用户与需求概述：描述解决用户什么痛点难点，将产品做成什么样。
功能模块：需求涉及相关的重点大的功能点，按照主流程重点先讲，再讲分支点。
原型与交互：讲解原型内容和交互，注意异常流程要提及。
数据指标：讲解本次需要哪些关键性的指标。
任务分配：需要其他部门、其他岗位配合的资源罗列出来，提前安排资源支持。

（3）在会议住中找个同事帮帮你做会议纪要，把争论点疑问点都记录下来。
（4）会议后，将变更点、变更范围都记录清楚，将会议纪要发给大家评估。

2、需求宣讲太草率

今年由于项目任务重，时间紧，自己没有主动发起严格的需求宣讲，有的开发需求都没有听过直接开干了。导致有些需求不太合理，且有些场景细节漏掉了，开发有些需求不理解，因为他们没有实际操作过业务，中间要废很多时间精力来给开发测试答疑沟通，一来二去开发想在年底杀我祭天了，我也很痛苦，愧疚又羞愧，还要花时间补充、修改。同时耽误了其他事情的进程。

答：从下一个新需求开始，我要按照我整理的方法进行宣讲，所谓开头开得好，产品返工少~~
（1）自己先讲需求：先介绍业务——达到什么目标存在什么价值意义——实现的思路。
（2）给出1-2天时间，给开发自己去阅读文档自己理解，再指定开发反述。
（3）在测试发问，注意前端正常流程、异常流程怎么操作，后台正常流程、异常流程处理的细小逻辑。
（4）注意事项：

确保会议时间充足：提1-2天发好通知，让开发和测试安排好工作确保不缺席，时间点最好定在离吃饭时间间隔远，反正我司程序猿吃饭是天大的事，不能耽误一丝一毫。
会议中的疑问记录好：由于对需求的理解不同岗位考虑的问题不同，在会议中会经常打断你，会问实现的问题，也会问到你没想到的异常场景，当你能马上解答的你可解答一下，若无法现场及时给出答案的需要记录下来会后再解答，不要耽误会议时间。

3、需求场景遗漏

需求分析时会漏掉场景想不全，导致需求变更的时候愧疚和害怕，所以会考虑到开发的成本，不敢对需求大动干戈。而选择折中。而这种折中会影响到用户体验。

答：
所以，我分析需求时，为了避免遗漏一些细节，逻辑不严谨。从以下几个维度去思考：
（1）用户是谁—解决什么难点—产生什么需求
（2）脑图结构化，每个功能点，思考影响节点和分支场景。
（3）每个页面从开始-发展-结束的情况（有无数据、正常异常情况），放空自己，把自己想象成用户，实在做不到，可以找到对应的朋友看他们怎么操作，会有什么让你想象不到的问题。

4、离用户不够近

需求做的没底气，做了一个地区去赶另一个场子，已做的地区后续需求不明确，也不知道自己做的需求到底能不能符合市场贴近用户，这个是时间的问题，先统一做几个地区，再做需求优化。

答：
（1）今年用户现场去的太少，需求开干前就应该去收集需求。
（2）产品设计后，再去用户现场验证，种子用户圈起来。
（3）产品上线后，持续维持和用户的互动，收集用户的意见，持续优化迭代产品。使用户画像清晰化，产品价值和产品定位明确化。
（4）竞品分析，紧盯竞品：2周浏览一下竞品。1个月写一下竞品发展情况。

5、需求文档能力待提升

需求文档写的不好。重庆第一个版本那样写太麻烦太啰嗦费时间福州第二个版本又太简单，需要寻找一个平衡点来写文档。打算山西的好好思考怎么写的需求文档易读性更好，让开发觉得我还可以再留到19年底再杀。大致罗列了一个大纲：

答：
（1）产品简介：简要的说明产品使用价值。
（2）版本管理：写好版本时间，需求变更点，变更原因。
（3）功能模块：

功能描述：写好目标用户和使用场景，在写每个功能模块的时候，简要的畅叙一下，自己能够试着去变成用户，也让开发测试有带入感。
页面原型：页面状态加图示且说明。
操作流程：正常、异常流程说明、及主要业务流程图。
业务规则：前置条件、加载机制、数据处理。
交互说明：正常交互、异常交互、页面跳转。
字段说明：字段、说明、数据来源。

6、需求验证不到位

需求验证，这点没做好，开发完成后没有去验证是否符合需求。没有很好的和开发团队配合。现在做的B端产品，测试环境准备相当复杂，自己也不会弄，每次环境配下来要花很多时间，所以每次就测试测完不管了。

答：
和测试团队制定了新的计划，需求单子增加一个要求：是否需要需求验证。如果需要，在测试结单前，测试将产品需要验证的点，把产品叫过来，演示一遍。

7、产品运营设计太薄弱

产品做了，价值点怎么传递给用户，对于B端产品，专业性较强，不像C端用户自己去探索发现，B端用户只要能够保证完成自己的工作，很难去改变工作习惯，也很难去主动挖掘潜在价值。如何很好的把价值传递显性的给用户，同时改变用户的习惯。目前我做的产品是很欠缺的，这题太难了~超纲啊！比五年高考三年模拟还可怕对于我来说~