请不要怪罪流程

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

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

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

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

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

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

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

其实流程约束的是人。

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

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

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

1、        发挥leader的影响力。

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

2、        信息透明+参与感

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

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

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

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

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

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

相关文章：
【推荐】 selenium下拉框踩坑埋坑
【推荐】 std::shared_ptr之deleter的巧妙应用
【推荐】 HashMap在并发场景下踩过的坑