打破流程化推动技术团队在公司的工作模式

又很长时间没有写博客了，还是得批评一下自己，任何理由都不能掩盖不写的事实。(写作能让知识更好的沉淀、思路更加的清晰。)
今天主要是写下自己最近针对技术部做的一些调整和变化，也顺带理顺自己的思路。
先说一下当前我们技术部的工作模式，技术部的主要工作就是和产品一起建设公司的产品，公司主要产品有学生和老师的上课平台（视频软件）、官网、学生的微信公众号、学生app、以及公司员工使用的管理后台，随着公司的发展，我们在持续不断优化和升级公司的产品，所有这些优化和升级我们统称为”需求迭代“，而这些需求有来自学生的、老师的和自己员工的，所有这些需求都会经过产品部门转换成产品，然后交由技术部实现。我们把实现的过程叫”需求开发“。基于这样的一种方式我们可以得出这样的一个过程：需求的产生->需求转换成产品->开发。这应该也是大部份互联网公司的工作模式。
另我们公司的部门设立有产品部、技术部、其他部门，这里我们其他部门是指除产品和技术以外的所有部门，咱们先统称为业务部门吧。以上这些的描述我们通过下面的图来体现：

可以看到上面这样的方式很像工厂里的流水线一环，我把这种工作模式称为”工厂合作模式“。
工厂流水线的核心点：

标准化：

流水线上的每一环对上一环和下一环的内部运作并不需要清楚，每一环对上一环提出要求，输送到你这一环就按照你的标准来，对下一环就是按照下一环的标准给到。

一致性：

要想把流水线的效能提高就每一环的工作产出效能都必须达到一致，任何一环的产量过多都会出现阻塞。这就要求每个部门的人员匹配和产出能达到合理的一致性。

流程化：

这是这个模型天然的要求，一个需求就是需要通过这样的流程来生产出来，你不能跳过任何一环，除非你把中间的一环干掉。
基于这样的工厂合作模式我们技术部的组织结构是这样的：

这样的结构技术部更像是一个黑盒，”对外“是不可见，不透明的。
技术部门会要求产品经理写好详细的prd，进行评审环节，需求是否能达标进入开发状态，技术内部各小组也会按照流程化和标准化的方式运转。
为了确保需求的正确产出以及有效运转流水线，技术部设定的开发流程：

另外在这样的方式下业务部门和技术部门基本上是没有”链接“的，评审prd时基本上不会有业务部门人员参加，因为这个prd已经是确定的，很难在有讨论或者商量的余地，如果真的出现重要问题，就让产品经理再和业务部门确认，确认完成后再进行评审。
到这里我们可以总结几个关键字：
沟通成本：
技术这边碰到需求问题，就需要一个传递和确认的过程，这个过程在这样的模式下是必然会出现的。很多时候可能你需要长久的等待，甚至有时会暂停开发。
周期拉长：
既然上面的问题会碰到，那周期拉长也就一定会发生了。
技术的业务感知低：
技术人员都是看着prd的各种规则进行开发，那对这个需求的理解很难深入，需求的背景、目的、目标以及未来的定位你可能只了解到了一点点表面的。
需求偏差：
传递的过程本来就会有损耗，一但某一个环节理解有些偏差，需求就差个十万八千里了。
互相抱怨、不信任：
这条才是最严重的，随着多次的需求迭代，技术人员发现需求做完好像并没人用、业务部门有些需求也没想清楚就递交过来、产品经理的prd写的不够详细根本无法开发，业务人员发现需求做的越来越慢、排队排的时间越来越长、上线后又出现各种bug，产品经理当着传话筒，受着两边的同时抱怨…

如何改变？

并非说这样的合作模式是错误的，只是在这样的模式下对每一位业务、产品和技术人员都有很高的要求，这样才能保证每一个需求的产出是有价值和连贯的。但是这很难做到，人员的流动，公司业务的变化，领导的更换有很多的因素影响着这条流水线，最最重要的是，技术团队的价值是很难提现的，只是把产品实现出来只是技术的其中一个价值，帮助业务团队，参与并帮助公司发展才是技术团队最大的价值！这也是公司每一个部门每一个员工最大的价值！

调整组织结构

要打破这也的机制先从内部做起，化整为零。

根据公司的业务重点和技术的资源进行切割分组，公司当下分为4条重要的线，每天线有对应的业务部门和产品经理负责，技术部切分为4个组对应，每个组分别有前端、后端、测试组成，人员的比例和总数按照每条线的轻重来匹配，最小单元1前端、1后端、1测试。让技术人员专注负责这条线的迭代。

创造沟通环境

分为4条线后，把每条线的技术人员整合在一起，然后整个小组搬迁至负责这条线的产品经理身边，有必要的话就把负责业务部门对接产品经理的负责人也一并坐在一起，每天晨会。让产品和业务清晰明白当下他们可用的技术人员有多少个，他们在做什么，把开发节奏交到他们手中，清晰透明。

优化开发流程

结构和人员发送变化后，接下来就是简化开发流程，而这个简化过程为3个核心关键：增加沟通、共同确认目标、并行做事。减少原有通过文档、邮件、项目工具等传递需求的方式，改变上一个流水线做完才能给到下个流水线的方式。要求技术人员必须共同参与这条线的业务讨论，要求产品经理、业务人员对需求的讨论和确认必须叫上技术。 （这里有一个很重要的点：技术人员参与业务是否有必要？我的判断就是非常有必要，我们是要做有用的和有价值的事情，而不是不停的做需求，技术人员对业务的认知越强对业务架构的能力和扩展性的把握也就越准确。如果技术人员只关注技术本身，而不关注公司的业务发展其实已经本末倒置了。）

总结

本次的调整背后更多是提升大家的专注力和战斗力快速的迭代公司业务，让大家建立起沟通和有效的链接，打破无形的部门墙，随着时间的推移合作的默契我相信会极大的推进公司的业务发展，大家形成合力，互相理解、互相帮助、互相成长。最后用一张图来表示我期望的合作模式：协作