我们把帐号系统重构了顺便了这个经验

　　账号重构是我做PM之后，经手的第一个项目。
　　最初的需求，应该是原始简陋的账号体系无法实现更换手机号，更换微信等需求，也没法把用户的微信和手机号分别创立的账号统一起来。
　　于是，为了解决这个问题，我决定优化表结构和逻辑，将手机号，三方登录的UID都降级，统一在一个固定的账号主ID上。
　　顺便再解决一下登录页面UI太丑交互太过时的问题？
　　顺便再增加一下强制第三方绑定手机号来杜绝脏数据？
　　顺便把个人中心页面优化一下？
　　顺便（）产品要控制欲望再顺便开发要砍人了
　　这是第0条经验。
　　【Tip0】控制欲望，版本封闭
　　不成熟的小产品可以让老大帮忙规划需求，然后再旁边记小本本，学习一下如何管理需求，安排优先级。（比如要考虑前端后台的工作量啦拆分功能会受到多大影响啦用户体验和商业价值孰轻孰重啦）
　　下面是自己这一个多月来的血泪教训适用于一切【常规功能的重构需求】。
　　【Tip1】一定要先调研清楚后台逻辑
　　API的开发哥哥在需求评审的时候，非要我跟前端一起，把页面的接口都整理一遍，再跟着后台一起爬代码看逻辑。
　　在被一行行天书摧残了一下午后，我发现PRD基本不用改（）但是，如果在写PRD之前先受过摧残，那么写起来至少可以快一倍。所以，还是要谢谢开发哥哥的傲娇要求的。
　　对于一个刚刚创业的小公司，很多功能都是早期应急做出来的，又经过线上时不时优化的小补丁，可能会给现在的需求开发带来一个又一个的坑。
　　如果在最开始，没有把线上的逻辑搞清楚，在开发阶段再填坑，会付出惨痛的代价（比如熬夜加班补逻辑的同时还要被开发哥哥嫌弃）
　　【Tip2】关于逻辑
　　1。该抄就抄。2。最核心的逻辑牢牢攥在手心。
　　该抄就抄
　　账号体系这种只要是一个有用户的产品就会有的常规功能，在互联网普及这么久后，已经有了成熟的体系。
　　那么如果我们想要做这个功能或者优化这个功能，最应该做的，就是抄啊！
　　大公司几亿用户多少年验证出来解决问题的最优方案，也是中国网民多年来的操作习惯不复用是傻子么！
　　咳咳，但是借鉴也是有技巧的。
　　比如我们是不是希望用户以手机号为主要注册用的账号，该怎么样淡化强调第三方的入口；各种密码验证码的格式和校验；页面跳转中注册和忘记密码的入口放哪儿；置灰和文案的小细节历尽千帆，取百家之长，选择最符合自己产品的原型图画好了耶
　　ps。不要忘记加入符合自己公司特色的小创新（如果有且适合加进来的话没必要盲目追求新意）
　　pps。也不要忘记兼容产品以前的坑哦
　　最核心的逻辑牢牢攥在手心死也不改
　　在PRD已经定稿以后，开发过程中，需求是可以小幅度变更的。毕竟PM不是神肯定会有考虑不周的地方。
　　但是核心逻辑，是一定要明确好，并且保证每一个参与项目的人都了解清楚的。
　　如果开发中发现核心逻辑错了，宁可暂停整个项目不做，也不能朝令夕改，产品如果对于自己的逻辑都搞不清楚，那连最后的话语权也没有了。
　　【Tip3】关于交互
　　站在用户的角度出发，但别把自己当成用户。
　　PM是用户的代言人。
　　这里的用户，是所有的用户，包括各种会进行奇怪操作或是有特殊需求的非主流用户。
　　怎么样能更好更全面地写好PRD避免遗漏，我想到比较好的方法是：
　　设计页面和流程图要分三遍
　　第一遍，保证核心的常规流程是走得通的（比如用户一步一步登录或注册的过程），或者通过账号中心绑定手机号至成功的操作。
　　第二遍，保证其他分支流程不存在死循环或者死胡同（比如进行到某一步突然忘记密码，或者突然断网或手机收不到验证码等），不管什么情况，一定要给用户反馈。
　　第三遍，优化核心流程的用户体验。比如可以把一些元素放在一个页面展现不用分多个页面，比如一些按钮的特效和交互。
　　多看多琢磨其他产品这块儿的功能
　　比如连续输入多次错误的手机号，会出现图片验证码，防止爬库。
　　比如有些页面涉及表单提交和状态更新，点击返回或者右滑后的页面展示和跳转逻辑。
　　这些细节只能说多研究，多经历如果没有项目经验可以积累，那么多多观摩其他成功产品也总是有帮助的。
　　【Tip4】关于PRD
　　流程图比文字更好用。
　　这次账号重构我最大的坑就是写了一万多字的PRD，结果开发基本照着流程图来的（然后我的流程图还漏了很多元素）
　　后来在宣讲的时候，重新画了一遍流程图，把一些对应的页面跳转和提示都加上去了。感觉开发同学理解，和自己说明都快了很多。
　　以后写PRD，图文并茂，少说废话。该枚举的地方用表格，且一定记得加目录索引。
　　PRD是PM的脸，别让他变成下图所示。
　　【Tip5】关于沟通
　　当面私聊群聊
　　如果每天都随身带着手机，那我的微信步数肯定要double。
　　PM请安心当一只召唤兽虽然跑来跑去很麻烦，但是当面沟通比起打字甚至拉群里说，提高的效率不是一点半点的。
　　【Tip6】关于职责
　　保证可用100，易用50
　　衡量一个产品的好坏和能否上线，有很多因素，比如：
　　可用性是否满足业务需求
　　易用性是否有好的用户体验
　　美观性是否传递了公司品牌形象
　　安全性是否会影响线上其他功能，是否存在安全隐患
　　其中我觉得，产品最主要的是保证100的可用性，即PRD明确的功能性需求要都实现。
　　其次是50的易用性，可能我们设计的时候考虑到了80甚至100的易用性，但是由于时间或者其他原因，开发没有做。这部分涉及用户体验的需求是可以后续版本优化，或者为功能性和安全性需求让道的。
　　美观性和安全性，在设计的时候要考虑，但是决定权交给UI和RD。让专业的人，做专业的事。可以提出建议甚至异议，但是不要盲目乱做决定。
　　以上是这次版本迭代整理的几条心得。感谢包容我这只小菜鸟的产品、UI、开发、测试同学
　　希望以后再读到，会觉得说的都是废话。