资讯专栏INFORMATION COLUMN

请不要怪罪流程

MiracleWong / 2902人阅读

摘要:但流程不是死的,尤其在互联网公司,只要有助于我们的目标达成,那么流程只是一阵东风。工作中并不是所有事情都可以依赖流程去保证万无一失。所以不要怪罪流程,这并不是流程的问题,而是人的问题。所以请不要再怪罪流程啦,以人为本,才是长久之计。

本文由作者周巧芬授权网易云社区发布。

笔者所在的团队这段时间正在两个版本的交接期,前一个版本马上要上线了,但后一个版本的需求早在三周前就已经启动,却迟迟没见到交互稿。作为开发前置的视觉跳脚了:为什么交互稿还没有,回头开发时间紧了又怨视觉稿没及时给!而交互呢,双手一摊:没有人找我们要交互稿啊,需求owner产品策划都没主动来问需求的交互进度啊。于是大家都开始面面相觑,流程上没有定这个环节啊,流程默默的背上了这个“锅”。

再有一个例子,某模块的功能需要依赖另外一个组的开发,这个问题直接沟通到开发,开发就默默的修改好了,等到临上线,大家都在催促这个依赖代码怎么还没上线,找到开发,对方说:我只知道要开发,找不到测试的人,我自己测了下没问题,还在本地库里。然后就没有然后了。于是大家又开始说:这个流程有问题,blabla…..流程再次默默的背上了这个“锅”。

可是真的是流程的错吗?严密的流程真的可以解决问题吗?

回到我们为什么要有流程?

一般来说流程是为了梳理我们的工作程序,让大家遵守并有效的衔接各部门以及各环节的工作,同时知会到相应的人员。但流程不是死的,尤其在互联网公司,只要有助于我们的目标达成,那么流程只是一阵东风。而在真实的工作场景中,往往碰到跨部门的合作需要有一定的流程规范。这个原因多半是因为,跨部门之间的不是特别熟悉,大家有各自的工作方式和KPI目标,或者说个体并不在意其他部门的工作,而只要保证你给我的输入按时保质即可。

好吧,既然现实如此,于是我们制定流程来约束大家按时保质的做输入输出,公司的巨轮慢慢的启动起来。但似乎这个流程也如同巨轮的枷锁,当流程的某一环节出现问题,巨轮要么停滞,要么部门间友谊的小船说翻就翻了。于是去制定更细致的流程去避免另外流程的环节不出问题,越来越多的流程束缚住了巨轮的前行,巨轮变得很笨重。大家的工作也开始应付各种流程中的细节。当然这是极端情况,却也反应了流程是把双刃剑。工作中并不是所有事情都可以依赖流程去保证万无一失。

其实流程约束的是人。

一味的将责任推脱到流程的头上,似乎让大家都忽略了团队中人才是主体。真正的去发挥人的主观能动性。如果每一个成员都有自己强烈的ownership,那么上面我提出的两个例子是否可以避免?比如交互稿完成了,交互主动的将稿件交付给产品做确认,同时在设计交互稿的时候就与视觉开始沟通视觉风格。而视觉同学,在已知该任务的安排下能主动的去询问下交互的进度,并主动的提出前期与交互沟通开始设计工作。对于产品来说,关注自己own的需求,在交互设计过程中就不断的与交互沟通确认,并关注交互视觉的进度。三个环节环环相扣,跨越鸿沟,相互的沟通之间也可以碰撞出更多的火花,更好的去打磨我们的产品,这并不是流程可以事无巨细的去定义到,而是流程以外我们作为人这个主体的发挥。比如开发在接到需求的时候能找对应的需求再次做个确认,写完代码自测完成后能主动找到测试,并且将代码交付给需求方,那也就不会临上线了,大家还在追究这件事到底是怎么回事?我们可以约定工作的环节和交付,但我们改变不了人的工作方式。所以不要怪罪流程,这并不是流程的问题,而是人的问题。

激发团队成员的ownership,培养积极主动的工作方式?

这似乎是个很难解决的问题。笔者从自己理解的角度粗浅的写了几点看法。希望能得到更多的探讨。

1、 发挥leader的影响力。

Leader作为团队最有影响力的人,要有正确的引导。从工作方式及态度上做积极的引导,多和团队成员沟通,了解团队的想法,去解除大家的顾虑和疑惑。真正发挥好一个leader的作用。

2、 信息透明+参与感

在团队做事的时候大家一起沟通:我们为什么要做这件事?做这件事我们期望得到什么?我们以什么样的标准来衡量这件事?开发不仅仅只是写代码,他需要了解需求的背景,他也希望自己的产品受人喜爱。而产品策划也不仅仅是产品策划,他要知道这个需求的开发实现性和测试复杂性。只有信息透明,大家相互之间才能更好的理解彼此。同时对于产品也更有主人翁意识。每个环节大家都有意识的去主动“插一脚“,这也会使得自己做的本职工作更加出彩。

3、 以产品目标导向而非KPI考核

大家是一个团队,我们的目标是产品成功,对于开发来说并不是代码完成才是他的目标,而对于交互视觉来说也并不是设计完成才是他的目标。大家有共同的目标。而不是划分好二亩三分地只在自己的地块耕耘好。建设美丽地球,人人有责,难道不是吗?

  流程是个利器,我们要用好这个工具,但不能完全的依赖流程。发生问题的时候多想想,怎样从自身的工作方式出发去改进。所以请不要再“怪罪”流程啦,以人为本,才是长久之计。




免费领取验证码、内容安全、短信发送、直播点播体验包及云服务器等套餐

更多网易技术、产品、运营经验分享请访问网易云社区。

文章来源: 网易云社区

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/25338.html

相关文章

  • 得救之道,就在其中——关于这次的 kik,left-pad,和 npm 事件

    摘要:是的,就是这样的错很快就发布了修正。各种担忧质疑指向社区一直提倡和推动的和理念。得救之道,就在其中在的里回复说不要依赖于其他人,附了关于的链接,并且最后再次强调依然是合理的哲学。解除了用户为你的代码打包的负担。 前情提要 今天 npm 圈子鸡犬不宁,原因是一个不过 11 行的工具函数 left-pad 被作者从 npm 上撤下,所有直接和间接依赖它的包就这么齐刷刷挂了,包括 babel...

    gaara 评论0 收藏0
  • [译]你并不知道Node

    摘要:问题什么是调用栈并且它是的一部分么调用栈当然是的一部分。为什么理解是重要的因为你在每个进程中只能获取一个调用栈。它是一个从事件队列中跳去事件的循环并且将它们的回调压入到调用栈中。当调用栈为空的时候,事件循环可以决定下一步执行哪一个。 你并不知道Node 原文:You don’t know Node 译者:neal1991 welcome to star my articles-tra...

    miqt 评论0 收藏0
  • 醒来或者吃饱又是一年

    摘要:这一年,生活上过的不温不火,工作上忙忙碌碌,思想上浑浑噩噩。想想还有几个小时就要结束了,难免有点小激动,不知道是想着赶紧结束这毫无作为的一年还是想赶快迎来新的一年好大干一番手脚。 终章 距离6月26日凌晨12点半的时候写下序篇,到现在已经是2017年12月21日了,电脑上时钟刚好跳到12点30分,心情与外面阳光一样正好。 这一年,偶尔听起民谣时也会晃一晃神儿,想想以前喜欢听的歌手的歌,...

    wenshi11019 评论0 收藏0
  • 拜托!面试不要再问我Spring Cloud底层原理!

    摘要:不过大多数讲解还停留在对功能使用的层面,其底层的很多原理,很多人可能并不知晓。每个线程池里的线程就仅仅用于请求那个服务。 欢迎关注微信公众号:石杉的架构笔记(id:shishan100) 每日更新!精品技术文章准时送上! 目录 一、业务场景介绍 二、Spring Cloud核心组件:Eureka 三、Spring Cloud核心组件:Feign 四、Spring Cloud核心组件:R...

    wums 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<