在传统软件企业工作 15 年后，转换阵地进入一家互联网企业，转眼快 3 年了，说说在这两种类型企业工作的一些感触。
先说说这家互联网企业，是做数据中心的，主要为中小企业提供互联网的基础服务，属于B2B模式。我对数据中心的理解是它主要解决数据在两个方面的问题：
- 数据在空间维度的传递「通信」；
- 数据在时间维度的传递「存储」。
围绕这两个要解决的主要问题构建一系列基于软硬件的产品，在构建产品过程中和传统软件企业的工作方式还是有很大不同的，具体体现在组织结构和产品开发方式有不小的差异。
组织结构
组织结构的不同在我看来最终会反应到对资源使用的效率与整体的协作力。
传统的软件企业对于组织结构的设定就是一棵树，从上到下逐渐扩展层级，高度取决于团队的规模，宽度取决于职能部门的规模。
这种组织结构比较好的一方面是每个组织成员对于所处的位置比较清晰，从职能内部来讲分工也比较明晰，有利于工作任务的分工，其由于职能部门的分割自带分组特性，可以把每个职能部门看成一条流水生产线。
不好的一面是跨职能部门的协作型缺乏灵活，沟通成本随着层级递增成指数增长，在多职能部门间涉及到客户时多有扯皮，就职能部门内部来讲往往资源过剩，最大的直接体现是你工作几年后发现每天都很轻松。
我所经历的工作企业大多采用这种组织结构，从搜索引擎中搜一下「组织结构」，能够看到的搜索结果中的图片也大都是这样的组织结构。
我所在的互联网企业采用矩阵式组织结构，在传统的树形组织结构上，职能部门在垂直上是由很多小团队组成的，有直接隶属于职能部门的团队，主要负责完成公用性的任务，其他的小团队则为各个产品团队人员，这种产品小团队在横向和纵向受到双重管理，具体来说，涉及到产品相关的产品经理会从横向综合调配各个职能部门中隶属于产品团队的人员，完成目标。涉及到职能部门行政管理则由职能部门统一管理，大概如下图这个样子。
这种组织结构好的一面是能够最大化利用资源，打通了横向的隔离，协作效率极高，比较灵活，会大大降低沟通成本。如果要开设新的产品线，从横向纵向组建相互隔离的团队即可，而这种纵横隔离也最大程度上降低了互相扯皮的发生。
比较不好的一面是对每个团队的领头人要求极高，针对每一个点要确立明确的目标并能正确的理解目标，执行目标。
这种组织结构也跟互联网产品的开发有很大的关系，每个组织都是独一无二的，还应当以自身的特点出发，其他的仅能借鉴不能套用。
产品开发方式
传统软件企业在产品开发方式上，比较依附软件工程的理论，无论是瀑布式还是RUP（统一软件开发过程）迭代式，都讲求产品的大而全的规划和论证，重文档，重流程，重测试，所以动不动一个软件产品开发好几年，每更新一次再来个半年一年的，不能说这样的产品开发方式不好，针对特殊领域的产品开发，这种方式还是很有优势的，比如在航空航天、金融等领域这样的产品开发方式还是挺有优势的。
互联网企业在产品的开发方式上跟传统软件企业略有不同，当要开发一款产品时，首先要围绕总体的目标找到假设的最核心的，最小化的可执行「产品」，快速实现后上线验证是否为用户带来了价值，根据验证的结果再做接下来的动作。
比如验证失败了（这是常态，所以互联网企业大多允许一定程度的试错），再寻找另一个假设的最小化可执行「产品」，直至找到或者承认失败。假如幸运的验证成功了，也就是找到用户了，那接下来用户自然会倒逼驱动产品的迭代发展，在这个过程中用户甚至还会帮助企业建立服务流程，考核体系，这也就是平常讲的「以用户为导向」。
这两种产品开发方式跟面对的用户类型也有不小的关系，如果用户是企业，一般企业用户追求大而全，这几年传统企业都在积极+互联网，但思考的出发点还是从大而全，从局域网向广域网，或许在这方面可以针对互联网的产品开发方式进行借鉴，在+互联网的时候先确立一个最小化的目标进行验证，毕竟这种产品开发方式的思路很大一部分就来自传统生产企业「丰田的精益生产」。
这里说的是软件产品开发相关的企业，其实传统企业都是可以借鉴一下，如果把每项业务看做一个产品，业务负责人看做一个产品经理，不论从组织结构上，还是在业务开展上都可以结合自己的特点进行尝试。
本文首发于我的微信公众账号「时间易逝」，欢迎订阅我的微信公众账号
在微信中搜索「doevents」或用微信扫描页面右上方二维码可订阅我的微信公众账号