项目的起源：
一个平常的工作日里面，我们负责开发的工程师羊羊羊（以下简称羊）找到了我，和我说Wap发布不能用了，当时我震惊了一下以为出了什么大Bug呢，坐下来详细了解之后原来羊想表达的意思是我们现在Wap发布的页面交互与视觉都太老套了，用户填写错误的时候也没有明确告知用户错在哪里了，所以羊说不能用了；聊完之后我把自己变成小白用户实际使用了一下Wap发布发了条信息，发现确实存在许多的可用性问题，当时身背数个项目的我决定和羊把这个项目做下去
项目的思考与设计：
与做其他项目一样，把现有的基本数据与竞品看了一遍，出了Blog（百姓网内部的产品文档的形式）与交互；也确定了本次优化的范围，发布分为前中后的环节，我们这次会优化最重要的发布中的环节，就是发布表单页，如下二张图就是输出需求的部分截图
需求输出就很正常的进入开发阶段了，这时候我们信心满满，因为我们知道目前的发布确实不好用，改完了之后很大可能会好于目前的情况
此处有波折：
在2016年2月份的时候羊开发完毕了，于是做了AB测试，第二天我们看数据惊人的发现发布成功率下降了10%！这是一个非常大的下降，如果真的全量上线了发布量会减少许多，这会是直接的经济损失，为何会这样？询问了客服部门也没有用户反馈发布有问题，陷入了自我怀疑，咱们这次运用了许多JS，是不是JS影响了加载速度或者控件的使用？是不是新的设计与交互用户使用不习惯？
因为这次是代码性能层面与交互设计一起优化上线的，我们无法锁定是哪个部分出了问题，我们对于设计比较有信心，那就先将问题锁定在代码性能层面；我们在加载页面的环节打了许多的数据监测点，之后我们得到了数据，老版本的平均加载时间为2.6秒，新版平均加载时间为4秒+，于是我们对于新版本的加载时间优化到3.6秒，再进行数据监测，发现发布成功率毫无变化！事实证明想要发布的用户多等上1秒多是不在乎的，但是我们还是要做的越短越好
既然性能没有问题难道是设计问题？？我们不敢相信，老的设计用户更加喜欢？在接下来的几天时间里面我们没有找到任何解决方案。有一次我找到羊聊天，羊已经没有什么信心了，当时是周一，羊说如果周五我们还没有起色我们只能回滚到老版本了然后去做其他的项目，我和羊表达了我的意思：不能把这个项目做成烂尾的项目！目前主要的责任在我，作为产品经理没有找到解决方案的源头，我相信我们很快就能找到问题的根源，咱们肯定行！
虽然口头上很有信心，作为产品经理在数日时间里面没有找到问题的根源，内心是有挫败感的；于是把自己当成小白用户不断的发布信息，发现了一个重大问题：用户在没有登录情况下填写发布表单之后跳转到登录页面，用户登录好了之后并没有发布，而是重新回到发布页面，用户下拉之后再次点击发布按钮才能发布，而老版本中登录好了就直接发布了，我赶紧找到羊让他把这个问题修复，晚上加班到家10点多了，我就拿我爸爸的手机中的UC浏览器尝试发布流程，没想到这时候就发现的了一个重大问题，在安卓4.4以下的系统里面不支持Flaxbox的css属性，界面错乱导致不可使用；当时我心理就一阵暗喜，这二个问题修复之后发布成功率很大可能会提升，事实证明就是这样！
顺利上线：
经过二个重大Bug的修复，发布成功率提升上来了并且比老版本的略高，于是我们全面放量，放量之后也没有出现报错或者用户反馈，数据表现也很正常；并且成功的挡住了机器人来Wap发帖，不过机器人的因素在一开始没有考虑到，上线期间才意识到的
做的好的地方：
- 这是自发的项目，没有人要求我们做这个项目，我和羊都是身兼数个项目，在整个过程中遇到了许多困难，都没有退缩或者放弃，在项目推进过程中拥有十足的热情
- 没有测试与BI；测试和BI的工作是我们自己担起来的，特别是羊，在页面上打了N多的点并看数据分析
做的不好的地方：
- 发布是一个大项目，本次改版涉及到了代码性能与交互界面，我们的做法是开发好一起上线的；刚开始上线AB测试的时候发布成功率是下降的，我们无法锁定到底是代码性能层面还是交互界面层面的问题；应该先调整交互界面，等确定没有问题之后再上线性能
- 对于发布的用户了解不够深入，项目最初没有拉取用户手机，分辨率，浏览器等数据；导致后面我们自己测试的环节中忽视了UC这样的“恼人”浏览器
- 对不发布产品本身考虑不够周全，忽视了“机器人”的这样的因素
总结：
- 这是一个经过等于才见到彩虹的项目，给我们自身带来了许多价值与思考，让我们对于Wap和发布流程越来越了解
- 项目中上线了N多个优化case，让我们对于判断上线case对于数据的影响越来越准确
- 项目中看了许多笔数据，让我们对于看数据更加敏感
