互联网时代，提到设计狮、程序猿和产品狗之间永远有说不完的话题，如那歌中所唱：“爱恨就在一瞬间，设计对月情似天，爱恨两茫茫，问君何时改；产品开发又一月，谁知吾爱心中寒，死在代码前，梦回大唐爱”。

　　2014年的那场血案，如今还在作为程序猿的家谈。深圳某公司的五个程序员杀了两个产品经理，图文并茂，血淋淋的案发现场让我们不禁唏嘘和感到惋惜，网上一下子炸开了锅，针对产品经理，开发与设计师之间的吐槽此起彼伏。许多产品经理自嘲道：“以后入职必须要给产品经理买份人身保险，哦不，遇到不能自主的产品经理要买十份！”还有设计师调侃：“我还是安心做设计不问产品事吧！”

　　做为一个干了近6年的小设计师，从平面到网页、APP等互联网产品设计和交互，期间还做了一年多的运营兼PL，也算经历了除开发、测试以外的其他产品开发运营角色。今天就当是年终总结吧，聊聊那些年需求的“小改动”，以及上下游协作（产品经理、设计师、开发、运营等）之间的微妙关系。

　　互联网刚开始的那一会，需求直接对接开发，完成功能为最初需求。04之后网页设计师慢慢承担起不可或缺的角色，需求要先通过设计师之手再交于开发，从而产生了不少如《一像素的恩怨情仇！程序员与设计师的那些事儿》之类的爱恨情仇。设计主导产品外观，但多数心想不能事成，与开发之间为了1像素的争执只是冰山一角。两者工作性质不同，思维模式也不尽相同。设计师的作品直接呈现在用户面前，作为一个合格的设计师自然不愿意自己做的产品被人说丑，而且是因为开发没按照设计图做所造成的，更是不能接受。而开发呢，面对成千上万的代码和各种不要不要的BUG已是够头大的了，再面对设计和需求的纠结与反复修改，怎是一个“烦”字了得。程序猿本是“木讷不解风情”之人，不影响功能的哪有那么紧急需要修改的，明明还能用嘛~我默默的加班开发赶进度，用户一有什么问题就是开发这里不对那里要改，没有我们开发产品光有设计有什么用？

　　事实也的确如此，在漫长而短暂的互联网产品进化中，开发一直是占据主导地位的。很多小团队，大家都凭着某些默契在工作，需求一般是谁想到谁提，老板提得，销售提得，设计提得，客服也提得，但是最后还得看开发能否执行。

　　06年前后产品经理的角色慢慢进入人们视线，那时更多的是由从业久者担任该职位，主要协调需求、设计和开发之间的“矛盾”，并控制产品质量和运营方向。除了管理项目的能力、业务的熟练、技术的实施，高情商的沟通能力也是必不可少的。随着互联网的繁荣，产品经理越来越多，不管是设计师和程序猿，甚至是初入职场的新人，很多人都会在自己职业发展的某个时刻华丽变身为产品经理。

　　而产品经理并不像我们想的那么风光和简单，他们必然会在执行及推动整个项目的过程中跌无数个跟头。被领导、开发和设计师吐槽无数次，纵使他们情商较高不会表现出来，心中那句爆粗也是免不了的。看看产品经理苦逼在哪里：

　　1、中国大部分产品经理只是产品的执行者，很多时候他们无力改变一些固执的现状和决策，还要去推动自己都不认可的方案。

　　2、尚方一句话，刚让技术做的项目要推翻，只好厚着脸皮求改，可想而知，免不了又要被骂。

　　3、相比设计师，产品经理更像是多修的杂家，玩过游戏的都知道多修的职业在打怪升级的过程并不会那么顺利切相对漫长，他们需要了解和学习的内容包括但不限于设计、代码、用验、管理、市场行情等等等等等等，还要面对上下游的夹板气。

　　正如我在很早之前写过的一篇文章一样《自说自话：产品经理当如韦小宝》，产品经理绝对不是单单的会写文档画原型的“小”角色。

　　如今做互联网的都应该听过这样一句唬人的话“人人都是产品经理”。如果人人都是产品经理那谁来做设计做开发？如果你觉得自己是产品经理，那综上所述的技能你又是否都具备呢？换句话说大家如真能都以产品经理自律来做产品，设计和开发都尽力做到最好，自己就能给自己提出很多的优化和需求，那有没有产品经理也不再那么重要，如果大家可以零阻力的交流沟通一心只为最好产品，那做出来的东西定会是极好的，可惜这样的团队更多都出现在各大名人的创业传记里。

　　大型成熟的公司项目，大部分需求均有产品经理提出，因为其知晓整个产品的进度和成员能力，更能从大局出发，使整个产品在现有团队基础上按着最合适的节奏逐步完善，而非一个个紧急的零时方案。当然，职权的划分会使得设计师和开发落入流程的最下游，逐步失去话语权，更造成了三者之间剪不断理还乱的矛盾：

　　产品需求与产品经理可以探（si）讨（bi）确定方案，定好的原型到设计师那里就没有太大发挥余地了。设计师做好的设计稿，到前端开发那里，除了一些特效与交互实现细节，基本上就是照做而已。而前端开发如果区分重构和 JS，那么 JS 基本也只能拿着重构写好的结构继续开发。前端跟后台的关系倒不像是真正的上下游，应该说是并行的，甚至大部分时候前端要按照后台的规矩来做，自己还轻易改不得动不了。而测试同学，在这个流程的最后端，却要从产品文档开始介入整个流程，设计测试用例，从产品逻辑，设计还原，兼容性问题，接口自动化测试，安全问题，性能问题等都要关注。更别提还有运维哥哥要跟着改定时任务，优化 DB 等等了。那么可想而知上游的一些看似微小的变化，会给下游的人员造成多大的蝴蝶效应。

　　接下来说说看那些需求口中的“小改动”：只是改下文字颜色，马上就能搞定吗？这里要对齐，不难吧？我这个功能很简单的，明天给我行不行？

　　再看看设计眼中的“小改动”：只是改下文字颜色，秒改！对齐，这个得调整一会，很多页面都要改！这个功能先规划一下，不能设计出来再改！

　　最后看看开发眼中的“小改动”：改颜色重要吗？等下次吧，发布很烦的！这里也要改？一改全站都要改啊！只改个样式？布局都变了啊！有没有想过以后怎么运营这块功能？费时费力别只用一次啊！

　　多少射鸡师与程序猿的屏幕被多少指点江山的大神戳碎过？是不是很想摔桌子来一句：you can you up！

　　人与人之间的信任都哪去了？说好定下来不改的呢？但是目前国内互联网产品的开发流程就是这样，改改改！改改改！原因就是缺少真正能把控产品精确需求的这样一个人。在产品的开发流程中，如果让没有经验的管产品，不懂设计的管设计、不写代码的管开发、不善运营的管运营，一、不能服众；二、那我们就接受改改改的命运吧！无奈的一次次把排好的时间又插上新需求，那么开发人员也会产生相应的不信任：反正你是要插需求的，进度慢也是没办法的！

　　设计师思维更奔放自由一些，同样的页面设计为了更好看或者更好的体验，不管三七二十一改版出不同的样式。当然，从业多年的资深设计师了解基本的布局实现，能够让开发在尽量少改动的情况下完成更好的设计改版。不过与程序员眼里的结构与逻辑还是两个世界。所以往往设计师感觉我没怎么动，只是这里加了个小东西，或者各个元素都调了些位置颜色，因为要符合现在的设计风格嘛。结果到程序员那里就悲剧了：这相当于重做啊！

　　运营的同学心中都住着一个罗永浩和抠脚大汉，要有情怀，要博眼球。可是有着罗永浩这样的市场媒体运营兼相声演员也阻止不了锤子走向失败，一意孤行的自嗨产品得不到市场的认可，再多的创新也只留下了人们谈笑中的“情怀”二字。所有需求和反馈不能以偏盖面的直接影响产品流程和发展方向。

　　需求改变的提出可以感性的大刀阔斧，但也需要理性的布阵，让粮草先行。

　　身边的同事是与你一起同甘共苦并让产品迈向成功的好伙伴，不要冷落他们，善待尊重你们身边的产品经理、设计师、程序猿和运营，尊重他们的工作成果。

　　所以，除了我们嘴上说说“理解万岁”之外，其实上游的角色应该更多的去了解下游的工作，才能更好的推进下去。比如产品运营同如果你懂点代码，懂点用户体验，懂点审美，你会发现，沟通会如此顺畅，竟能和程序员与设计师聊到一起了。设计师多想想，我这个改动到底会对页面结构有多大影响，这个设计到底是如何变成页面的？前端同学多想想，我做的模板 JS/开发能不能用？我是否有考虑到各种状态的变化，各种扩展的能力？开发的同学多考虑一下我这个接口真的好用吗？有没有哪些参数可以省略？有没有那些信息不该暴露？是否接口过于臃肿？是否字段表意不清晰或各处不一致？

　　但是这个时候测试同学说了：我TM怎么那么苦逼？运维同学又道：我TM还没说话呢，你们也好意思吐槽？

　　千言万语化作一句话，一个团队齐心做好产品，理解万岁吧！