关于跨部门推动

2017-06-17  本文已影响0人  FancyZZ

产品从立项到交付给用户/客户规模化购买、试用,不光由产品部门决定,但是产品经理作为产品的第一负责人,虽然大多情况公司没有赋予你广义上产品成败的职责。如果将产品拟人化,那么产品就是孩子的母亲或是奶妈,对孩子学习、工作、婚恋等重要关节不闻不问几乎是不可能的,那么与孩子的老师、同事、儿媳等其他环节人员打交道成为不可避免的一部分。

背景

最近刚刚接手一个属于学前班阶段的开发工具型产品S,该工具由部门I(所在组)、部门R共用研发,被部门J使用,产出的工程运行于部门E的产品上,由部门S进行销售,也有外部客户使用,然后由部门R提供技术支持。

由于现在产品稳定性、易用性方面存在不小的问题,急需在各个环境收集问题来提升稳定性,就这样一场跨部门攻坚战就此开展。

原则

自上而下

之前尝试过在公司内部自下而上的去驱动提高生产效率的使用,在使用者都认可的情况下由于不同人员KPI的差异、人性中的惰性都导致事情很难坚持。自上而下的推动可以让不同人员的KPI得到统一,在督促推进时手中的尚方宝剑也让话语更加有力。

成会为主,邮件为辅

邮件作为办公场景最高频的“沟通”工具,因为高频与形式所限,更多时候充当的通知和留存的角色。一封发送多人的沟通邮件(尤其是发送给高层,谁知道他们一天会收到多少内容),几乎等于没有发。

当你真的想推动一件准备充分且对于各方利益相关或是对公司整体有帮助的事情,那么请你先发一封会议邀请函给少数几位(5人以内)能够拍板做事的负责人,然后邀请的你leader来通过私人方式再向他们发送邀请和确认时间。

当你能够将几位负责人窜在一起的时候,恭喜你已经成功了一半(当然,前提是你的提议是有价值的并且对大家有益的或是站在公司利益制高点的)。

靠谱并被认可的方案

那么在这个会议前,你需要准备好了一份或多份可以马上落地执行的方案,这个方案应该是你经过反复考量的,不会被全盘推翻的。在准备好方案后,还有两个事情是一定要做的。

会议形成可以落地的内容

如果上面几项内容都进行的很顺利,那么正式的会议你不会遇到太多困难,但是有一点是需要注意的。

私下leader没有提出的问题,可能在这个会议中提及(因为各种原因,遗漏、表达欲、参会人员关系等等),对于这些问题一定避免出现以下内容:“回去再研究下”、“A和B都可以,回头再定”等等。会议输出的结论一定要是可以马上落地的。

会议讨论出可以落地的、大家都认可方案,请马上输出会议报告给利益相关部门所有人,请各部门负责人回复确认并给出执行时间等。

方案的持续推动

最后

这次跨部门推动期间走了不少弯路,希望之后可以避免。另外希望S产品能够朝着自己预期的方向、节奏顺利迭代。

上一篇 下一篇

猜你喜欢

热点阅读