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

距离我上一篇文章，整整隔了一年，由于换了公司忙的飞起，每个月的一篇文章被加班取代了。针对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端用户只要能够保证完成自己的工作，很难去改变工作习惯，也很难去主动挖掘潜在价值。如何很好的把价值传递显性的给用户，同时改变用户的习惯。目前我做的产品是很欠缺的，这题太难了~超纲啊！比五年高考三年模拟还可怕对于我来说~

答：今年好好总结思考，再整体总结出一篇文章。

8、文案功底欠缺

文案功底欠缺，由于之前文案自己写了之后，都有专业的团队人员负责修改优化，导致我对文案无法做到字字珠玑，从各个方面来看，文案真的太重要了~

答：

（1）一个功能页面选取一个文案点，平时反复打磨，邀请同事探讨，怎样的文案达到最佳表达效果。

（2）多看书多学习，平时自己花时间和功夫利用其余时间累积。可以在生活中多去思考。

（3）每个月底的周六去看一些业内的分享讲座并出自己的心得。

9、产品深度欠缺

缺乏行业大局观。不知道行业发展趋势未来在哪里，这样也就无法把控产品的深度，和市场上哪些妖艳货没什么区别了~

答：

其实这个问题，作为一个入行不到5年的产品来说，是普遍的通病了，也是个大难题。这个没有什么捷径，除非你是才智过人天赋异禀，作为凡人的我，知道只有在这个行业沉淀下去，经历得多了，思考得多了，慢慢积累，自然也会变成一个有高度有深度的产品人。

10、时间管理

公司大，事情多又杂，时间上管理不当，导致时间花了，不知道干了什么事。而且每天加班，每天忙到连自我提升的时间都没了~

针对这种情况列了管理表，结果写着写着就遗忘了。我觉得管理表作用还是挺大的，对于自己的工作安排，时间节点都清晰明了，不会造成事情丢三落四，但是但是！！！每次都没有坚持下来。

答：

（1）一定要坚持列好管理表。将年度计划、半年度计划，细化到月度计划、周计划、天计划。

（2）按照计划事情一定要一件一件做。遇到计划有变及时更新计划表，制定新的计划。

月度计划、周计划工作表

需求点清单表

自己每天工作计划表

以上只是罗列了一些问题和如何解决问题的一些点，真正的要解决这些问题远不止我回答的那么简单，这些都是需要我们在平时的产品工作中慢慢积累，认真思考的。我们要学还很多，路很长~如：产品经理如何正确撕逼？

本文由 @李大发 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自StockSnap.io，基于 CC0 协议