想必做过几年开发的小伙伴都碰到过产品经理各种需求，各种上线前需要改东西的情况。简直无语！下面我给大家盘点一下最让开发者无语的几种情况。
一. 上线前一天或者几个小时，提出新的需求
讲道理，成熟的公司，一个新版本的需求都是提前讨论制定好的，就算是改动也是小改动，但是这是成熟的公司，估计很少的公司能做到上线前不改任何需求的。
很多开发的兄弟上线前几个小时还能拿到新的需求文档，然后就是各种敲代码，但是这种情况很难保证不出一点问题。完了搞不好就被经理各种批，这么小的错误也能犯。
因为上线前，大部分情况都是在改bug，一边改着bug，还要应对随时来的“”小的改动“”。反正说多了都是泪...
二.需求反复变
不清楚大家有没有碰到过一个功能让你反复改好几次界面的情况，开始设计一个界面直接就开始做，做了一半发现逻辑对不上，然后去讨论，完了回来重头写。折腾半天，时间浪费了，最后问你怎么一个功能做了这么久？是不是效率太低了？
我当时真的想拍桌子问问产品，你能不能开始就把功能这个逻辑都设计对？锅都让开发背了...
三.产品设计无限拖延
一个产品开发新版本流程大概是：提出需求->根据需求UI做出效果图->然后产品和UI根据效果图做出小调整->定稿，UI切图->开发根据效果图开发
四.产品设计不够整体化考虑
五.简单功能复杂化
举个例子 一个选择城市的功能,可能公司产品就支持3个城市，大家在做这个程序的时候，一般有点经验的都会考虑 这个城市以后增加了怎么办，肯定不可以在程序里面写死，这个必须动态控制，不能以后增加一个城市我们就提交一次app吧。 这么想讲道理没有问题，然后获取一个城市列表（3个固定城市）加一次网络请求服务器。然后产品经理过来发现，你这么做有问题啊，就这么三条数据每次进这个界面还有正在加载数据（一般网络请求如果网络慢的时候，都有加载中提示...），然后让你改，说体验不好....然后你就要想办法了，这个不能写死，还不能每次都加载，那么只能第一次加载完存本地了，下次判断本地有就不请求服务器了...好然后高兴的写去了，写完想想有漏洞，如果服务器这个时候有增删改就麻烦了，比如 多个城市，少个城市，改了其中一个城市的名字...这个本地就和服务器对应不上了，然后还要再添加对本地数据更新的逻辑......
后来，这个app再也没有支持过别的城市...
我总觉得功能尽量越简单去实现越好，不要为了一个简单的小功能去影响整个产品的体验....
我在第一家公司的时候，老板提出这样一个概念，就是做一款可以配置的app，就一个项目...听好是一个项目，不允许拷贝多个项目然后修改，因为不好维护...
老板大概意思就是 首页的图片文字，主界面的模块功能点等都是动态的 所有的能看到的界面都可以在后台服务器配置...
说白了就是：app上所有的地方都要从后台请求字段 ，然后根据定义好的字段的值 去控制app的显示....这样就会产生出来很多app... 餐饮，医疗，交通，购物....
老板的概念是：定制化全能app...
大家想一下这个难度有多大，然后缺点有多少.
这个产品的缺点：1.app内逻辑以及请求太多，影响app的流畅度及体验
2.从产品角度考虑，配置出来的app缺乏个性化，功能界面效果很单一。
3.产品过于复杂，导致app本身过大。（基本所有第三方的sdk都会用到，jar包就几十个）
我理解的好的产品应该是： 简单、操作流畅、功能简单易用 这些都很关键。
所以一些功能从产品经理设计出来的那一刻就注定是失败的，开发多努力都毫无意义...
程序员成功的关键有很多啊，碰到一个好的产品经理设计出一款好产品，你就算做的工作很少，也一样可以成功。
但是你碰到坑人的产品经理设计出坑人的产品，你多优秀都会被埋没....想必这也是很多大神都愿意去大公司的原因...的确产品好，自己做的也没有那么累...
小公司什么奇葩都有...
说了这么多，我总觉得基本几年的开发都碰到过类似的情况，那么我们开发如果总是被产品牵着鼻子走，做的累不累？
我们开发要怎么面对这些问题呢，我提出我自己的几点看法（有问题及时提出指正）：
1.我们尽量要参与需求的制定及讨论，尽量对一些不合理的地方及时从开发的角度提出自己的意见。
2.当需求制定出来的时候，我们拿到效果图，不要着急做，要脑子里面先想想哪里有问题，不合理，整体流程能不能跑通。想通了在做。
3.当产品上线前，尽量不要做一些没有太多意义的小功能。精力都放在处理关键bug，问题上。功能能不加就不加。
4.提前制定好计划，当需求反复改的时候，要及时和上级沟通交流，调整时间计划，避免后期时间计划对应不上。
暂时就想到这些了，后面想到再补充，希望大家也可以多多提出自己的看法。都谈谈自己碰到的奇葩无语的事情。
欢迎大家加入我的开发群：454430053