前段时间，我们公司的业务部门做了一个“用户领券”活动。然后因为一些页面和文案说明的不通顺，就被老板疯狂diss，最后就是对我们产品部门领导的疯狂指责。我们领导就觉得很委屈，我们自认为已经是做得足够好了，无论是页面的打开速度还是用户的使用体验，都是符合我们预期的。但是在老板眼里，这次“业务部门”的活动，最终出现的“物料和文案”的问题，就应该是由“产品部门”来承担后果。因为，在老板看来，这个活动，是产品部门执行落地的，最终的成品也是从我们部门发出去的，那如果做得不好，当然就归咎于我们的不用心。可是，从我们部门的角度来看，这次活动的宣传资料和文案都是业务部门提供的，如果要问责，应该也是业务部门来承担才合理。你看，所处的位置不同，看问题的角度也不一样。一.先说说事情的来龙去脉先来大致说一下这个活动的来龙去脉。01.时间很赶这次的“用户领券”活动，从告知我们到最终上线，中间只有短短的2天时间，真的是时间紧任务重。他们业务部门内部有没有商量我不清楚，反正我们部门接到这个通知的时候，说是要第二天上线。当然，这是不可能的。于是在我们老大和他们老大的“友好协商”下，他们才勉强答应第三天上线。这也就意味着，留给我们开发和测试的时间，就只有2天而已。而且，他们要的功能也不是那么简单就能实现的。这个活动的整体路径是这样的：用户需要先通过微信公众号进入到活动的详情页，然后在活动的详情页进行支付购买，最后系统发放对应数量的优惠券。因为之前没有这样的业务，所以这看似没那么复杂的需求，但是对我们来说，是个全新的内容。02.现有方案改造遇到这种情况，新开发肯定是来不及的。所以，我们的思路是：找一个过去类似的案例，然后微调一下，基本上保证这个活动可以上线。当然，这个方案，也得到了业务部门的同意。他们也清楚，在这么短的时间内想要做个新的出来，肯定是不现实的。既然方案确定了，按照之前的参考，我们就要求对方提供相应的活动素材，所谓的素材其实就是活动的海报和文案，这些都是需要在页面上向用户展现的。但是就这么简单的东西，他们竟然都提供不出来，真不知道他们是着急还是不着急。为了不耽误进度，我们总不能干等着他们，于是我们就按照之前的活动做了一版上线了。与此同时，我们也邀请业务部门的对接人全程参与并测试，他们也表示这样的流程没有问题。并且他们也说老板同意了这版的方案，对流程是没有意见的，目前就是在等待最终的素材。业务部门还表示，这个素材的确认，和我们没关系了，他们会继续跟进，等老板拍板了他们就发过来给我们替换。03.上线被diss我们公司的公众号都是定点发布的，然后业务部门的素材，竟然是赶在公众号发布的最后一刻才给我们。最终，这个活动就这样着急忙慌的上线了。公众号发出去后，业务部门就开始各种朋友圈和社群的宣传。最关键的是，老板自己也会去看，这一看不要紧，直接就发飙了。发飙的对象不是业务部门，而是我们部门，老板指出了3点问题。1.海报的设计的不行，没有冲动下单的欲望；2.海报的文案不对，不明白这个活动是干什么的；3.活动的引导不对，用户买完后不知道怎么用优惠券；虽然上面说的几点和我们完全没关系，虽然我们部门领导是一肚子的委屈，但是现实却是，我们部门在那疯狂的修改海报和文案。加班加点的改，改来改去，一直改到老板满意的版本。原本和我们没有半点关系的内容，硬生生的变成了我们的工作。这其中还有个小插曲，活动发布后的1个小时内，没有任何人下单。老板竟然把这个归咎于产品部门设计的流程不合理，因为不合理，所以没人下单。因为他上面说的3点问题，导致活动没有达到预期效果。最终，这个活动总算是在反复修改中告一段落！毫无疑问，我们部门，成了这次活动成功的最大阻碍。二.为什么产生这种矛盾从我们公司的实际情况来看，我觉得之所以会有这样的结果，“责任不清”是最主要的原因。为什么这么说，因为从整件事情的链路上来看，每个人都觉得自己是对的，可结果就是没有人满意。我们慢慢的来捋一捋。01.老板是活动的发起方首先，这个活动的发起方或者叫策划方，虽然看起来是业务部门，但是按照我们公司的惯例，最初的源头肯定是老板。对老板来说，他肯定不会关心这个活动中间的沟通环节，他要的就是最终的结果，他所能看到的也只是最终的呈现效果。从他的角度来看，他所感觉到的“不通顺”，就代表着用户体验的不通顺，所以他自然而然会将问题归咎于产品没做好。当然，他这样想，好像没什么问题。02.业务部门是活动的中间人其次，想做好老板的这个活动，业务部门必然是要想方设法的满足他的要求。作为业务部门，他们自己是没有能力去实现这样的效果的，他们只能依赖于我们产品部门才能够达成目标。所以对于业务部门的人来说，他们只要满足了老板的要求，活动上线了，用户能够购买了，优惠券正常发放了，他们的工作就算完成了。他们才不会去关心所谓的流程通顺不通顺的，至于文案上的问题，他们肯定想“关我什么事？海报又不是我做的，都是设计部门出的，最终的定稿也是设计部门找老板确认的，我也说不上什么”。当然，业务部门这样想，好像也没什么问题。03.我们部门是活动的实施方最后，对我们部门来说，也就是产品技术部门来说，我们是最终的方案实施方。所谓的实施方，也就是意味着，方案设计的是否合理、流程是否通顺、文案是否合适、引导是否有吸引力，和我们其实是没有任何关系的。我们就是一个实施者，我们无法判断这个方案是否合理，我们也无法判断这个方案能带来怎样的效果。我们能做的，就是将我们已有的方案告知对方，然后让对方去做判断。如果对方都觉得我们这样的方案没有问题，那我们所要做的就是让对方提供相关素材而已。我们给对方提供的其实是填空题，我们已经给了模板，只需要按照要求填进来就可以了，至于其他的，好像还真的怪不到我们。当然，我们部门这样想，好像也没什么问题。各方都觉得自己没问题，最后必然出问题。所有的沟通，都是单线沟通。最关键的是，对于这个活动的最终效果承担部门，也没有明确的说明。没人负责，也就意味着没人积极。除了老板以外，大家的想法就是：反正这个活动和我没有任何关系，做好了我又没有任何的奖励，做不好也不会扣我半毛钱。既然如此，那自然而然就是按照常规做法来处理了。三.以后应该如何避免要解决这个问题，其实不是一朝一夕的事情，路虽远行则将至，事虽难做则必成。01.保持沟通首先，不能是单线沟通，各方应该充分沟通共享信息，这也是我们公司目前最缺少的环节。如果这次的活动，能够做到明确责任方，然后所有相关方能够坐在一起哪怕沟通那么一次，最终的结果也肯定比之前的要好。对公司来说，这个活动肯定是要上线的，最终的效果无论是哪个部门来承担，最终肯定都是要公司来买单。所以，站在公司的角度，是你部门来承担或者他的部门来，好像都没有什么区别。除非公司有什么特殊的目的，否则，是谁都一样。正式因为这样，高层是不太愿意去主动向下沟通的。当然，这不仅仅是公司高层的问题，底下执行部门的多问一句，也同样重要。沟通从来都是相互的，唯有充分交流，才能信息共享。02.各司其职，各展所长对于每个业务部门来说，公司为什么要区分不同的部门呢？如果没有差别，干嘛要区分呢？每个部门都有自己熟悉和擅长的领域，各个部门之间的协同，才能够扬长避短，形成合力，这样才能提升整体公司的运行效率。业务部门的优势是深入在一线，能够了解到前方最直接最直白的需求，也最能够了解业务面临的问题和痛点，他们是可以提供建设性意见的。但是，业务部门不管实现，他们也会以偏概全。产品部门的优势是技术实现，我们能够将业务部门所想要达成的效果快速的实现出来，并且与此同时提供比较符合正常标准的用户体验。但是，我们远离用户，我们都是办公室产品经理，用自己的感觉去衡量用户的体验。所以，各方都有各方的优势，各方也都有各方的不足。将优点发挥到极致，才能产生最大的效用。如果以后还有这样的活动，如果每个部门都能够多想一个为什么，我想，可能就会避免出现这次的情况。03.指定责任部门这次的活动，还有一点是很模糊的，那就是最终的负责部门。现在仔细想想，确实没有任何部门对这个活动应该负责。公司既然没有明确，也就意味着没有哪个部门会愿意主动跳出来的。对于业务部门来说，老板说要做个活动，要找技术部实现，那我就去找，反正最终执行也不是我。对于技术部门来说，业务部门找过来，说有个活动要上线，那我就按照他们的要求来做好了，有问题也不会找我，找他们。这其中，其实还有个设计部门，就是业务部门要提供的那些素材，其实是找设计部门进行设计的。对于设计部门来说，就更加没有责任意识了，反正我按照业务部门的要求把素材提供了，至于最终活动的效果，和我又有什么关系呢？在没有明确责任人的情况下，就算各个部门各司其职，最终的结果可能也不会让人满意。如果这次活动，公司就很明确的指定了负责的部门，最终的效果应该会比目前好很多。一些想说的话所谓的感同身受，其实是不可能的，每个人都只会从自己的观感去揣测别人。所谓的换位思考，其实是不现实的，每个人都只会站在自己的角度考虑问题。其实，很多时候，共同利益，比什么都重要。--- end ---
