流程是个利器，可以帮我我们解决很多问题，但是流程也有其局限性，我们不能完全依赖流程，要以人为本，充分发挥人的主观能动性，才能更好地助力项目成功。 笔者所在的团队这段时间正在两个版本的交接期，前一个版本马上要上线了，但后一个版本的需求早在三周前就已经启动，却迟迟没见到交互稿。作为开发前置的视觉跳脚了：为什么交互稿还没有，回头开发时间紧了又怨视觉稿没及时给！而交互呢，双手一摊：没有人找我们要交互稿啊，需求owner产品策划都没主动来问需求的交互进度啊。于是，大家都开始面面相觑，流程上没有定这个环节啊，流程默默地背上了这个“锅”。 再有一个例子，某模块的功能需要依赖另外一个组的开发，这个问题直接沟通到开发，开发就默默地修改好了，等到临上线，大家都在催促这个依赖代码怎么还没上线，找到开发，对方说：我只知道要开发，找不到测试的人，我自己测了下没问题，还在本地库里。然后就没有然后了。于是，大家又开始说：这个流程有问题，blabla…..流程再次默默地背上了这个“锅”。 可是真的是流程的错吗？严密的流程真的可以解决问题吗？ 我们为什么要有流程 一般来说流程是为了梳理我们的工作程序，让大家遵守并有效的衔接各部门以及各环节的工作，同时知会到相应的人员。但流程不是死的，尤其在互联网公司，只要有助于我们的目标达成，那么流程只是一阵东风。 而在真实的工作场景中，往往碰到跨部门的合作需要有一定的流程规范。这个原因多半是因为跨部门之间不是特别熟悉，大家有各自的工作方式和KPI目标，或者说个体并不在意其他部门的工作，而只要保证你给我的输入按时保质即可。 于是，去制定更细致的流程去避免另外流程的环节不出问题，越来越多的流程束缚住了巨轮的前行，巨轮变得很笨重。大家的工作也开始应付各种流程中的细节。当然这是极端情况，却也反应了流程是把双刃剑。工作中并不是所有事情都可以依赖流程去保证万无一失。 其实流程约束的是人 一味地将责任推脱到流程的头上，似乎让大家都忽略了团队中人才是主体。真正地去发挥人的主观能动性。如果每一个成员都有自己强烈的ownership，那么上面我提出的两个例子是否可以避免？比如交互稿完成了，交互主动将稿件交付给产品做确认，同时在设计交互稿的时候就与视觉开始沟通视觉风格。 而视觉同学，在已知该任务的安排下能主动地去询问交互的进度，并主动地提出前期与交互沟通开始设计工作。对于产品来说，关注自己own的需求，在交互设计过程中就不断地与交互沟通确认，并关注交互视觉的进度。 三个环节环环相扣，跨越鸿沟，相互沟通之间也可以碰撞出更多的火花，更好地去打磨我们的产品，这并不是流程可以事无巨细地去定义的，而是流程以外我们作为人这个主体的发挥。 比如开发在接到需求的时候能找对应的需求再次做个确认，写完代码自测完成后能主动找到测试，并且将代码交付给需求方，那也就不会在临上线前，大家还在追究这件事到底是怎么回事？我们可以约定工作的环节和交付，但我们改变不了人的工作方式。所以，不要怪罪流程，这并不是流程的问题，而是人的问题。 培养积极主动的工作方式 激发团队成员的ownership，培养积极主动的工作方式，这似乎是个很难解决的问题。笔者从自己理解的角度粗浅地写了几点看法。希望能得到更多的探讨。 发挥Leader的影响力 Leader作为团队最有影响力的人，要有正确的引导。从工作方式及态度上做积极的引导，多和团队成员沟通，了解团队的想法，去解除大家的顾虑和疑惑。真正发挥好一个Leader的作用。 信息透明+参与感 在团队做事的时候大家一起沟通：我们为什么要做这件事？做这件事我们期望得到什么？我们以什么样的标准来衡量这件事？开发不仅仅只是写代码，他需要了解需求的背景，他也希望自己的产品受人喜爱。而产品策划也不仅仅是产品策划，他要知道这个需求的开发实现性和测试复杂性。只有信息透明，大家相互之间才能更好地 理解彼此。同时，对于产品也更有主人翁意识。每个环节大家都有意识地去主动“插一脚“，这也会使得自己做的本职工作更加出彩。 以产品目标导向而非KPI考核 大家是一个团队，我们的目标是产品成功，对于开发来说并不是代码完成才是他的目标，而对于交互视觉来说也并不是设计完成才是他的目标。大家有共同的目标。而不是划分好二亩三分地只在自己的地块耕耘好。建设美丽地球，人人有责，难道不是吗？ 流程是个好工具，我们要用好这个工具，但不能完全依赖流程。发生问题的时候多想想，怎样从自身的工作方式出发去改进。所以，请不要再“怪罪”流程啦，以人为本，才是长久之计。 |
