需求背后程序员的辛酸—(由APP主题颜色随手机壳颜色变化需求带来的思考)
说说最近发生的一些事情
近日 某互联网公司就因为 '主题颜色随手机壳颜色变化'而发生了一次吵架事件，后来都被开除了！
作为一名程序员，大家都知道，产品经理是需要经常与研发人员打交道的一个职业，他们也有一定的技术常识，有相当一部分产品经理都曾经是程序员，他们也开发过很多优秀的产品，后来由于自己的职业规划就转产品经理了，因此这部分人与程序员沟通起来也是相当轻松的，当然也有一部分产品经理直接就是从产品经理做起，没有一定的技术基础，他们设计出的产品更多从用户角度出发，不会过多的去考虑技术实现的问题，最近就有这么一个互联网公司的产品经理提出了一个牛逼的需求，把程序员们难倒了！
后来看谷歌最近也出了这么一个设计，如图6所示，我估计产品经理应该要的是这种效果，另外查资料得知坚果手机，一加手机，还有三星s8都有这个功能，虽然并没什么卵用！
发生这种情况，也是我们不希望看到的。作为一个程序员，我知道，根据我之前开发过的相似的功能特征，我可以估计出现在的这些功能特征各自要多少开发时间。然后，我把总时间加起来，这就得到了完成整个项目需要的大致时间。然而，事实情况中，每个项目在开发过程中都遇到二、三个瓶颈。这些瓶颈会肆意的消耗程序员的大量时间，你在遇到它们之前根本不会有所预见。它们会拖住整个项目，致使工期延后数周甚至数月。
这些是没有经验的人在评估复杂度时不会理解的。他们不明白在其他事情上都很灵的方法，为什么放到软件开发上就不灵了。所以，下一次当你听到有人说“我想你几天时间就能把它开发出来”时，不管是谁说的，都不要懊恼。深呼吸一下，告诉他这篇文章的地址，《不懂技术的人不要对懂技术的人说这很容易实现》自己该干什么还干什么。
对于产品来说
产品提出的需求，一定要是经过需求评审会的，符合实际的一些场景的。 往往一些看似很简单的需求，实际上会遇到很多坑。
提需求要有节奏感。不要误会，这个节奏感不是啪啪啪的节奏感，而是说你提的需求，要跟着项目的版本周期和实际应用场景走。
需求的来源
老板提出的战略方向的需求：老板会站在战略层的事务，在确定了产品的方向之后，他会对产品的样子有个大致的想象，有些功能是必须要有的，这时候，他会和大家讨论哪些需求建议加上去。
一、谈需求前，先明确问题是什么
问题”不是“我要一个…功能”，而是“我在做…时，为了达到…的目的，需要通过产品完成”。
二、说需求时，先别讨论解决方案
三、聊需求后，明确边界和优先级
学会拒绝不合理需求，学会正确沟通需求，这是作为一个产品经理最基本的责任；
就像阿伟大佬说的那样，一定要开需求评审会，拿出原型图，设计图，或者一些参考资料，让大家讨论一下，尽量提让大家接受范围之内的合理的需求。不要盲目给开发者开一些脑洞大开的自以为是的“神创意”！也许你无意中的一句话就被打了还不知道怎么回事。
对于程序开发者来说
1、开发人员有质疑这个需求不合理不合理的建议
（这里切记不要说这是xxx的需求，我也认为不合理，但是没有办法，这样只会让开发人员鄙视你，造成你后续的被动，工作越来越难开展）
2、开发人员在实现需求的过程要考虑其复杂程度，如果实现起来比较麻烦，也可以和产品经理进行商讨
（产品经理和开发人员是承上启下的关系，也是完成一个需求功能不可缺少的一部分，正确的沟通和理解会让你在以后的工作中得心应手）
在工作中我也会跟开发、UI等相关人员进行激烈的沟通和争吵，但是都是基于工作需求；任何一个需求的确认如果只是平平淡淡，没有一点问题和摩擦肯定会出现问题，只有大家一起沟通确认才能让需求正确的执行。
最后
最后忍不住吐个槽。有些产品经理动不动就拉老大来给程序员施压，我觉得这种是最low的。
总之我个人认为需求的确认需要大家一起来确认，不是老板的责任，不是某一个部门的责任，不是某一个角色的责任；要适当的学会拒绝，学会沟通，才能让需求更正确的执行。
开发者很辛苦，希望可以谅解一下。
阅读更多
相信自己，没有做不到的，只有想不到的
在这里获得的不仅仅是技术！
