come on，被技术怼是日常了好吗，有什么可写的...
关键是被怼总是因为那些细节，是不是该长长记性了!
下文就说说开发过程中产品提需求应该注意的几个点~
应对网络环境异常的需求
记得百度有产品经理的12条军规，其中有一项是“PM首先是用户”。PM应该是疑难杂症较真强迫症用户的结合体吧，因为总有难搞定的用户会在使用产品时遇到各种各样的问题，需要PM先想到并设立预案。其中以网络环境异常为最典型的使用场景，也是入门级PM在写PRD时最容易忽视的问题，比如我，围笑🙂
网络异常以 弱网 和 无网 两种情况为主，两者都会导致无法及时拉取数据/数据返回，造成请求超时，体验中断。
弱网的常见场景为通勤时地铁内网络由4G切换成2G网络（玩儿农药的同学请举手🙋），或者封闭空间内（电梯间、地下室）网络信号弱。移动端针对这种情况通常的处理方式是做系统提示或toast类弹窗提示，提示用户当前为弱网环境，请重新刷新/下拉数据或检查网络等，且将未加载的模块使用灰度展位图代替。无网是弱网的极端情况，出现场景可能是网络中断、用户接听电话等，常见的处理方式除同上外，应增加的是重新加载网络功能，界面设置热区点击能二次连接网络。比较特殊的情况是iOS10更新后出现的APP首次启动需允许访问数据网络，iOS的这个特性处理方式同流量下断网，一定要设置可再次弹出权限，不然太坑（不懂苹果的逻辑，摊手）
在实际开发中，还要求产品经理要根据不同产品功能提出每个使用节点上的网络异常应对措施。网络环境异常是产品经理必须应对到的经典场景，特别在手游、出行导航、新闻资讯类应用中出现频率较高。曾经脑洞过一个功能觉得会有意思，是在断网时弹出浮层，提示用户进入another space ，类似于树洞的功能可以写点什么给未来的自己，存在device里，当下次遇到断网时再以图文的形式展示给用户，输出所谓的“情怀”，至少让用户感到这是个有温度的APP。
对关键数据的需求
实践证明，躲过网络异常的坑，还不能避免自己在技术前长跪不起...
PM还需要在开发过程中对提出相对完善的关键数据需求，过于简单或含糊不清都会提高沟通成本，造成技术返工，不利于项目的推进。对数据的需求主要提给后端开发，在实际开发中我发现掌握以下四点可以减少沟通成本、提高后端开发对数据需求的理解：
1.数据粒度 2.数据应用周期 3.数据需求冗余 4.数据权限
产品需要APP内所产生的数据，但你不能跟技术说：“嘿，给我有关XX的所有数据！”。PM需要先明确哪些数据是你需要的，再给出明确需求，以新闻资讯APP的评论功能为例，需要的关键数据有一级评论（父级评论）、二级评论（子集评论）、对二级评论的回复评论、对回复评论的追加评论，每级评论在时间维度上又分为升序、降序、一天内、一周内、一个月内等。在提出这些关键数据需求或提取数据时要和技术明确数据的粒度和定义，避免数据范畴宽泛和定义不明造成的需求不明确。
还以新闻APP的评论功能为例，在后端开发时常遇见的问题就是哪些数据要永久保存？其他数据的存储周期是多久？所以要求PM在明确数据粒度和定义后，将关键数据的应有周期设置好。比如为保证前端显示内容丰满度，要求一级评论的保留周期为6个月或12个月，评论通知的有效期在3个月或6个月；为保证后端存储空间可能会对最早的评论信息动态删减，这些出于技术方面要考虑的需求需要PM提前和技术对接好
在敏捷开发中设计评论功能时，通常迭代规律是：实现文字一级评论 → 实现文字二级评论及回复 → 实现评论回复的通知 → 实现图片/GIF的一级评论 → 实现图片/GIF的二级评论及回复。这其中设计到评论、通知、文本信息三个模块的开发，所以要求PM不能将需求局限于一次迭代版本中，要将最终版本的需求通盘考虑后拆分给技术，告知其每个版本开发时要考虑之后功能的冗余，也就是我们经常说的 留个口儿！
最后一点其实是PM在后台取数时最常碰到的问题，涉及到一些敏感数据时一定要提醒技术哪些数据需要哪些权限才可查看，涉及到CMS这种后端平台的更需要明确哪些ID可以增删改查；前端呢，数据隐私性其实也是PM需要注意的：用户的手机号、微信号、住址这类隐私信息一定要做马赛克处理。鹅曾经在做积分排行榜时疏漏了手机登录用户昵称默认使用手机号这一点，幸好超nice的技术大神自己做了星星，不然我会被打得满头星星的，比心❤！
改需求的正确姿势
都说改需求是PM的大忌，但其实在实际开发中，很多因素导致PM要在开发周期内改PRD。（很多因素里有老板、老板、老板、老板、客户吧）
既然胳膊扭不过大腿，那就拿出正确的该需求姿势，将技术怼你的怒火降至冰点。
其实无非就是将改动的点想清楚后再提需求，以点为轴，辐射出需要联动的功能或模块。最怕的就是还没有想好改动一点会对全局有什么影响就急忙找技术对接，不仅会造成对现有功能的推动重建，甚至会和现有的功能和架构产生矛盾，牵一发而动全身。最好的方法是自己先画roadmap，或在脑图上把和需要修改的有关功能都列出来，再找到技术master私底下讨论下修改的可行性，商量出最少代码改动的可行性方案，最后再组织需求变动评审。
纯银说过看到自己一个下午想出的idea，技术要加班加点做一两周，就明白做PM要耐操，要对自己的需求慎之又慎，对产品负责。出需求前认真复盘自己的方案、和技术/测试多一些沟通，是减少你被怼的好选择。要想不被怼，鹅有个秘籍，记得给技术买一个月的早餐和夜宵哦~😭
最近在找新坑，更新的少了，感谢大家的关注~
“好希望我的产品能和用户心智相通，成为人生追求的一部分”
---鹅哥
