抑制越俎代庖的冲动

2019-04-03    来源:xuexiao.me

容器云强势上线!快速搭建集群,上万Linux镜像随意使用

曾以为,诸如朝三暮四、邯郸学步、削足适履之类的成语都只适合用来描述动物的智商。凭着理性的大脑,人类绝不会犯这些低级错误。但离开学校真正接触现实的社会后,各种经历时常让我感慨,这些老祖宗凝练出的精华之所以能够历久弥新,正是因为它们源于你我身边真实的生活。

最近常浮现在脑中的词是“越俎代庖”,意思是主持祭祀的人跨过礼器去替厨师操办酒席,常用来比喻超出自己的职责范围去干涉别人管辖的事。在现代社会,一个人不可能掌握所有技术。所以最好的方法是进行社会分工,每个人只需要精通一种技术,再与其他人协作即可。然而这种分工配合的模式过于理想化。因为现实生活中,团队成员往往会不满足于份内的事儿,还想对他人施加影响力。于是乎,内耗重重。

个体在团队中虽然只承担部分职责,但或多或少会对合作者的工作成果有所预期。当别人做出来的活儿与自己的预期有偏差时,便会心存不满,不吐不快。产品设计师觉得交互画的线框图与梦想中的产品差太多;交互觉得产品提供的需求不靠谱,只考虑商业需求和KPI;开发觉得视觉提供的效果完全是异想天开,在渲染时极其消耗资源。

互不信任的情绪在升级,各位的手也越伸越长。产品提需求的时候直接带上了线框图,只期望交互把控件对整齐;交互奋力抵制不靠谱的需求,只磨嘴皮子就是不配合;开发磨磨蹭蹭不想写太费脑子的算法。每个人都想让产品变成自己期望的那样,去影响并不属于自己专长的领域,挤压别人的决策。合作的美梦为什么会变成内耗的噩梦呢?

原因在于合作的方式不靠谱。公司里常见的合作方式是瀑布式的。各个职位的人组成了一条流水线,一个环节的任务完成了,就输出交付物,给下一个环节的人继续加工。

理想情况下,每个环节的人应先向下游交付一份“效果”描述文档,下游的合作者再施展自己的才华,为这些“效果”提供“解决方案”。然而实际情况则是下游抱怨“效果”不靠谱,上游抱怨“解决方案”不达标。信心在一次次失望中崩溃,于是下一次再描述“效果”时就想夹带私活,把自己偏爱的“解决方案”直接灌输给合作方。然而,这种头痛医头的方法是非常低效、破坏分工机制且打击合作伙伴积极性的,只治标不治本。

要想消除这些内耗,抑制越俎代庖的冲动,需要优化流水线式的配合方式:

1、下游应当提前参与上游的决策:

上游应该在对效果有初步想法时就邀请下游参与讨论,看是否存在极其不靠谱的点,以免自己一个人闷头走得太远 。当然下游也应明白此时自己只是参谋,只有建议权,不要表现得过于强势。通过这种方式,上游可以了解合作方的能力范围和工作习惯,下游也能参与决策,对最终产品有了熟悉感,更像是一起孕育的孩子,而非仅仅是个乙方。

2、向下游提供“效果”图时,也要交代一下它的背景

在交付“效果”文档时,可以也附带说明一下为什么要这么做。知其所以然,可以让下游对“效果图”有更深刻的了解,也能在思考“解决方案”时有更灵活的发挥空间。

3、交付文档要翔实地定义“效果”的所有细节,表述方式要利于下游理解

个体对自己脑袋里的想法是很清楚的,所以当文档中的细节存在纰漏时不太在意。比如,“这个图标是临时用用的”、“点这里时是要判断一下再跳转的”。但对于阅读这份文档的合作者来说,则像是到了初到陌生地的游客,会把地图上每一个像素都奉为真理。与其在合作者做好活儿之后大呼“这完全不是我要的效果”,不如自己认真一点,保证每一个传递给下游的细节都是正确的。连自己都懒得说清楚的点,又怎么要求别人来猜你到底想要什么效果呢?

越俎代庖的冲动源于对他人能力的不信任。与其专制地把别人控制得死死的,不如尽早倾听别人的意见,并尽责地管好自己的摊子。你对别人要求得越多,给别人的喘息空间就越少,收获的惊喜也越少。

文章来源:xuexiao.me 转载请注明出处链接。

标签: 团队经验 产品经验 团队管理 

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点!
本站所提供的图片等素材,版权归原作者所有,如需使用,请与原作者联系。

上一篇:Web信息架构笔记(2):何谓信息架构

下一篇:地图微博