产品工作教会了我什么（1）

今天跟一个同事聊天，产品工作者究竟是应该理性还是感性，我们都一致同意二八原则，即产品人员最好是80%的感性加上20%的理性。产品是一项富于创造性的工作，充满感性的产品我相信更能思考到打动人的细节；在项目的落实过程中不可避免的遇到鱼与熊掌不可兼得的情况，20%的理性负责这时作出取舍。理性够用便罢，我们开玩笑说产品太理性了简直要抢开发的饭碗。

不过，抛开什么理性啊感性啊，作为一个菜鸟，创造性的工作是锦上添花，更多的也更重要的是执行。执行，执行，完成leader布置的各种任务。在我看来，不说高效优质的完成，能持续不犯错已经是足够优秀。产品工作的相当一部分是在沟通，沟通一着不慎便会导致犯错。突然想到了小王子里玫瑰花说的那句：不要说话，话语是误解的根源。（捂脸笑哭）

清晰准确的表达出你的需求。

这是我工作以来最大的收获。

需求。这大概是互联网人最熟悉的一个词了。产品提需求，开发实现需求，产品该需求，运营提需求，UI做需求。套用小王子的格式，我想很多程序员心里是这么想的：不要提需求，需求是误解的根源。

需求这个东西啊，产品其实也很烦的。从下面两个方面来看吧：

1.需求的来源决定了其注定是多变的。

以我的日常经历来看，需求来源无非是脑暴、调研和用户反馈。

头脑风暴。平均一到两周一次，会议的内容常常是下下个版本的产品功能。虽说是头脑风暴，但绝不是信口开河，所提出的功能肯定也是有所事实依据的，不然会被瞬间pass。一次高质量的脑暴会议大概会有50%的需求是可以执行的。

调研。是否要在产品里面增加或者修改功能，常常的做法是去做调研，而我们认知的界限决定了调研是肯定存在一定盲区的。随着认识程度的加深，发现已有的方法是笨拙甚至是错误的，这太常见了，这时候怎么办？改！需！求！

反馈。一个产品如果有良好的反馈机制，是可以收到很多好的建议的。还是二八原则，其中80%在产品看来都是伪需求。顺便说一句，很多开发同学常常能够在程序的角度给出很多很好的建议，这说明需求也可以是友谊的小桥嘛。

产品的每一次改需求都意味着自我否定，把自己之前辛苦相出的方案否定也是一件痛苦的事情。

不过，毋庸置疑的是，频繁改需求的产品肯定不是一个好产品。不管是初级还是高级产品，在自己的职责范围内总是有一定的权利做一些取舍，下决定前内心想清楚利弊。不犯错，就目前而言就是我下阶段工作的目标。或许是我的水平太低，但我会慢慢打怪升级的。

2.需求的沟通误差。

大家肯定见过这种游戏，几个人站一排，第一个把一句话描述给后一个，以此类推，到最后一个往往与初始大相径庭。

需求也是这样，虽然只有两到三级的传递，但是每一级造成的误差时间久了累积起来，可能足够专门发一个版本来修复。boss->leader->me->RD/QA，一层层传递，其中可能一部分是纯口头表述，更多的是文本传递，不管是哪种都有可能造成误差。

举个简单的例子，做一个输入身份证号、上传照片的实名认证功能，产品托着下巴想了一下，然后画原型、写文档、发需求一条龙完成，以为万事大吉，只待发版了。事实上呢，各种各样的情况，一个文档是远远考虑不够的。互联网谁最有创造性？当然是用户了，他们能在你事先想到的十八种错误预防外，用一百零八种姿势给你制造bug。这些问题，有时RD能想到，一部分会告诉产品，一部分产品会提出比较好的解决方案。在以后的漫长岁月里，可能突然灵光一亮，也可能自己遇到了，产品发现了一个无伤大雅的bug，于是决定改。可是这种需求本该在很早前或者半小时前就应该做了的。

不管怎样，沟通造成的后果，这个锅产品我来背。

ps:写完回头看一眼自己写的东西，简直不明所以，写的是什么鬼，逻辑乱七八糟，慢慢来吧，坚持写一些东西，坚持总结，我相信会有进步的。逆水行舟，不进则退，这句话在哪都适用。