01 两种组织架构
通常金字塔顶是一个老板，负责统筹一切的事。其下辖几个副总裁，每个人负责一块具体的事务。
每个副总裁下辖几个总监，总监又下辖几个部门经理，每个部门经理下辖几个一线经理。
最终，每个一线经理下辖具体做事的员工，他们都是相应方面的专家。
比如，业务经理下面是业务员、产品经理下面是产品设计师、开发经理下面是程序员、测试经理下面是测试人员。
金字塔组织架构
一个典型的产品由相关的所有上述一线经理通力合作，完成一个产品的立项、调研、研发和推广，这是十分精细化的一个过程。
小公司向大公司的成长过程中，她们最容易趋向于采用这样的精细化分工，每人负责一块，因为这样职责明确，“效率最高”。
可是偏偏还有另外一种做法，这是四代以前经历过的一家规模很大的国际化公司。
这个公司的老板在参观了一些创业公司的工作方式后，十分羡慕小公司灵活的组织架构，然后着手改革。
具体的做法是，逐渐取消各大部门之间的界限，重新以业务为中心，组织一个一个的小团队，来进行产品的研发。
这种做法又似乎与大部分的公司相反，他们趋向于粗放式分工，每个团队负责产品相关的一切的事务，他们以整体业务为单元。
采用这种做法，业界最有名的恐怕就是韩都衣舍了吧。
韩都衣舍，存在一种叫“三人小组”的团队，这些小团队权力大的吓人，完全颠覆了四代印象中对“普通员工”的形象。
比如在典型的产品小组内，三个人分别是设计师、页面制作、库存管理员。
他们全权负责某一单品的页面制作、款式设计、尺码以及库存深度的预估等事务。
注意，这里是全权负责！
这意味着他们自己有权去权衡销售量和新品上架等环节，有权做任何相关经营决策。
而每个小组的考核指标则是销售额、库存量和毛利率，所以小组内的每个人都会尽力让利润最大化。
这种“海星架构”，通过利益杠杆，把人的责任心和主观能动性发挥到了最大。
海星
四代想起了谷歌的一个段子。
据说某一天搜索部门的老大使用了一下公司的搜索产品，发现了一个问题。
他没有找相关的项目经理开会，研究是哪个部门的责任，而是来到员工的休息区，把这个问题写到了黑板上。
而在这里休息的两个并非该产品的开发人员，看到这个问题后，直接找到问题的根源，然后修复了。
这就是人、活生生的人、拥有巨大潜能的人！
这些段子让四代陷入深深的思考中。
到底是什么原因导致了两种截然不同的做法？
这些对红细胞团队来说，又有些什么启示？
02 工业革命与分工
四代学习过，现代管理学起源于工业革命。
而当时正处于物品大量缺乏的时代，提高产量迫在眉睫。
所以，历次工业革命主要就是使用新技术提高行业的产能。
而分工恰恰就是提高效率以达到这个目的的主要方式。作为分工的重要产物，瀑布开发模型就是典型的代表。
分工带来高效
互联网时代则不同，这个时代物品不再匮乏，产能也不再是问题，这个时代最珍贵的是个性，是不同。
所以大量大批量、大众化的物品不再是必需品，大家希望的是多种多样定制化的东西，这种多样性，小众而密集。
就因为这样的外部环境在变化，导致在某些行业，大规模的团队分工与合作已经难以奏效。
因为巨大的投入与微小的收益往往不成正比了，收益与成本已经不匹配了，牛刀不能总用来杀鸡吧。
这两年的工作中，给四代感触最深的一件事通常就是，当一个功能发布之后，总会有一批用户跳出来，发表不同的意见。
当你按照这些客户的需求做出调整后，另一些客户又会跳出来表示反对，真是难以抉择啊。
还有就是，当客户提出一个需求时，四代不知道是不是应该做，因为他不知道其他的客户是不是也存在相同的需求。
通常大家会说，只有一个客户提嘛，小众需求，不予满足，听起来很酷，很有权威。
实际上，客户总是在慢慢流失，只不过这两年用户量的巨大增长掩盖了这一部分的流失。
还有，之所以没有形成严重的后果，只不过是因为目前还没有一家公司能提供这样定制化的产品。
流失的客户们很多只能出去逛了一圈后又回到了四代公司的怀抱。
站在公司角度，为了“完美”地解决这些分歧，大家决定提供各种设置来让用户自己可以自由调整。
于是在表面上，大家的需求都满足了，可是实现的功能带来了各种无谓的复杂性。
复杂到有时开发人员都找不到选项在哪，更别说客户了。
这种统一处理的做法确实是兼容了客户不同的需求，只不过同时也将复杂性留给了客户。
一个无比复杂的庞然大物就这样一步一步垒成了。
除此之外，还有一点，四代觉得，大规模精细化分工是以沟通的低效来达到每个分工项目上的高效。
首先，我们前面提到过，全才再难培养出来，那么分工就是必然的，分工利于资源整合。
但是分工会带来一个天生的缺陷，那就是沟通成本的增加。
这一点在模块化很成熟的工业生产中，一点问题没有！
因为生产模块和单元之间相互独立，它们各自不需要太多的沟通和交流，需要最多的就是全局统筹。
但是在乌卡（VUCA）时代，存在如此多的不确定性，导致情况变得完全不同。
不确定性充斥的时代
尤其是在软件开发这种行业中，不仅流程上无法做到严格独立的隔离，而且经常需要快速地应对各种变化，沟通的作用和成本就被逐渐放大了。
有多大？大到有人说：“管理就是沟通”！
为了减少沟通成本，于是团队之间订立各种各样的协议，比如产品只对需求负责，开发只对实现负责。
尽量大家只专注自己的事，不管别人的事，这样沟通就少了，效率就高了。
可是这样做就又会带来新的问题，那就是容易推诿，因为有些问题不能单单归结为开发的问题，或产品的问题。
此外，还容易形成责任上的淡漠感，因为开发会觉得，我只负责开发，需求我不管、也不关心，用户体验什么的，关我屁事！
对于一个严重割裂的系统，单个组成部分的最优化并不能让公司整体达到最优化。
而且精细分工会带来另一个问题，就是团队之间会形成严重的依赖关系。
分工中的某个环节出现了错误，其他的环节将无法继续工作，整个产品研发的潜在危险度增加了。
如此巨大的成本，仅仅是解决了一部分用户的需求，这个投入与产出显然是不能让人满意的。
那么如何应对这种需求的变化？
03 杀鸡用什么刀
四代觉得，可能是“小团队、快速迭代、平台定制化”。
其中，小团队是基础。
俗话说得好：麻雀虽小，五脏俱全。
所以哪怕团队再小，该有的角色和功能也都得还有。
所以，理论上，团队中的每个人是全才最好，这样覆盖角色最全。
但是这个我们前面也说过是不可能的！
既然不能是真的全才，但又存在这个需要，那就只能走大家常说的“全栈之才”了。
全栈之才，通俗地讲，就是精通一个方面，其他方面也比较熟悉，至少可以完成常规的工作。
这也就是很多人说的“一专多能”。
就像《越光宝盒》中的那个诸葛先生一样，运筹帷幄决胜千里，天文地理计谋音律乃至“接生”，无不“略懂”。
略懂略懂
全栈之才在软件开发中存在很大的作用：
一是可以统筹全局。
现代互联网项目的开发，需要应用多种能力。比如需求调研、产品设计、前端开发、后端开发、数据库、各种中间件等等。
就拿前端开发来说，你就需要用到模块化开发、自适应、MVVM、微前端，各种复杂的交互与优化。
对于一个如此复杂的构成，我们需要一个全栈之才来掌控全局，他不需要是各种技术的资深专家，但他需要熟悉各种技术。
二是可以降低沟通成本。
四代知道，一个项目越大，参与的人员就越多。
在日常协作中，不同类型角色之间的沟通很多时候是鸡同鸭讲。确实，当大家都在说着自己专业的黑话和土话时，不同专业的人怎么可能会听得懂？！
而如果有一个懂产品懂设计懂前端懂后端的全栈之才，那沟通成本显然就不同了，因为他们讲的，彼此都能听得懂。
三是综合价值高。
对于四代所在的创业公司来说，全栈之才的价值是非常大的。
创业公司不可能像大公司一样，DBA、前端、后端各种人才全都到齐了才开始工作。
所以需要一个万金油，各种活都能干。
你看，全栈的作用大不大？
全栈的价值是越来越大了，那么如何做到呢？
具体到每个团队中，比如开发团队，精通开发是必须的，但是同时也要会基本的需求调研技能、需求分析技能、产品设计技能、基本的PS技巧、基本的审美、基本的测试技能。
而对于开发过程本身，这个是本质工作，要求自然更高一点，那就是从前端开发和后端服务中任选一个精通，但是同时要熟练掌握另外一个和数据库。
有难度吧？有难度，但是绝对值得挑战。
四代进行的成长计划，就是期望通过不断的学习和方向的切换，能在一段时间内，培养出一批全栈之才。
全栈搭配上小组组合的形式，就构成了基本的战斗单元，这也是四代努力的方向。
路漫漫其修远兮，吾将上下而求索。
