产品经理这个岗位覆盖面很全，会和一个公司的各个层面打交道，技术（前端后端）、设计、运营等等，在这些关系链中，产品与技术关系真是剪不断理还乱，特别是彼此一番讨论过后大都是别有一番滋味在心头。每个岗位的有每个岗位的视野，从产品的的视角出发，我们看到的都是技术们形形色色地问题。前些时日偶然逛贴子发现一篇写给产品们看的讨论：“技术们都是怎么吐槽产品的”感触颇多，结合帖子的内容和自己的经历，反思了一下自己作为产品存在的一些问题
吐槽一：变更需求
整理需求是产品们吃饭的命根子，但是在提需求的问题我们总会遇到一些突发情况，特别是做ToB 的同学，需求有甲方提出，而甲方提需求的人往往都是些传话的神奇存在，说话可以不经过脑子，一会改改这一会改改那，敲代码的兄弟直接就不干了，信不信LZ鲸骨开掀开你的头盖骨？不过好在我接的几个To B的需求甲方都是ZF单位，很多需求他们提了也就提了，虽然有很认真的做，但是解决的还是公司应对职能单位的需求，而不是甲方的需求。其他时间我解得都是些To C的需求，由运营部门提出，这些需求的整理开始考验到产品的基本功，可别小瞧这些基本功，从我的角度我给出以下几种：
1、各部门提出的需求是否是伪需求？（这个不需要详细地说）
2、部门负责人提出的需求是否是全员的意见，还是个人想法？
这个需要自己去核实，举个例子：某个部门需要设计大佬给设计新的页面，负责人给了我大致样式，黄底的页面，等到我设计大佬那边跟进完页面设计进度，发给该部门时，有同学有不同意见，就过来与设计大佬沟通，第一句话问的竟是：“这个是谁想的做黄底的呀？咱们产品的色调不是应该是蓝色的吗？”设计大佬一脸蒙蔽“这不是你们自己提的吗？”听得我在旁边一个尬。虽然说统一需求意见是该部门自己的事情，可是产品还是需要做好引导工作，谁让出了问题还是自己来解决呢？可长个心吧！
3、 对于某些我们不太清楚的专业类问题（比如技术类），自己存疑的话一定要提前确认
同样是页面的例子，我们做新页面的时候，技术需要对于部门提供相应的域名，由于提需求的同学是个新人，不太懂就直接给我发了pm234.cn，我看到这个域名第一反应是有点问题，因为根据我提前做好的功课来看域名一般包括，一级域名、二级域名和三级域名，这里只是提供了个简单的二级域名，这样的想法在我脑子里稍微一转我就自己给自己找了个理由：可能技术他们那边自己知道怎么弄。于是我就傻乎乎地将需求提交给了PHP那边的负责人，结果可想而知，技术大佬在钉钉上用打字的方式给我补习了一遍域名的常识，虽然讲的我早已在事先理清楚，不专业的烙印怕是一时半会也洗不清了，从此，遇到我存疑的问题，我一定会去核实清楚，特别是对接方是个新人的时候，更要留个心眼。
吐槽二：需求文档变更不及时
主要分为以下几种情景：
1、 集体开会过需求时，虽然讨论要对需求改动，可并没有在需求文档上做及时调整。
这种情况等到技术开发完，你去问他为什么没改，他也问你为什么没改（需求文档）你问他为什么没按照会议上的调整来，技术内心估计早已问候完你亲戚。这种情况问题显然是出在产品身上，产品人平常严谨一些是个不错的习惯。
2、当然还有一种情况，产品昨天开会给技术过得需求，过完需求被其他工作找的连坐的时间都没有，第二天技术直接问为什么调整没加进需求里，因为他们要对需求进行评审，以便开展后续工作，这种情景下只能考验产品的情商了，首先要做的帮他们把评审需要的给理清楚，解不解释对我个人而言不太重要。
吐槽三：需求理解不充分
上面交给产品一个需求，我需要达到一个什么样的效果，直接转给技术，没有提前做好功课，技术那边实现不了仍然要坚持，最后需求无法完成技术背锅。
这种场景下，找到备选方案才是最重要的，毕竟产品是通过沟通来解决问题，而不是增加问题。
对于产品与技术的关系，见仁见智，我分享一下自己的想法：不同于外界的说法——产品技术就是需要吵架的，我偏向于不吵来解决问题，只要能按质按量完成需求，付出点耐心死磨硬泡都行，毕竟产品的所有出发都是为了创造或者改变，做点小小牺牲无所谓，需求无法按期交付才是产品心头的痛
网友评论