距离我上一篇文章，整整隔了一年，由于换了公司忙的飞起，每个月的一篇文章被加班取代了。针对 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 个月写一下竞品发展情况。
