什么是组织增长官

　　前段时间增长黑客很火，眼前耳边总是时不时的冒出来，当我看到它时，我脑海里一闪而过的是另一概念：组织增长官。下面我想聊聊这个话题，纯属个人见解~
　　一个组织通过产品传达他们对客户/用户的主张，这个＂产品＂是组织和客户/用户之间的媒介和载体。团队在设计用户/客户在产品上的体验旅程，我们把它称之为业务流，这是直接面向我们的用户/客户的部分。
　　而产品的背后是团队，这个背后的团队组织如何运作，各部门间有序协同的部分，我们把它称之为工作流。而我想聊的组织增长官是针对工作流而言，如何让团队紧盯目标的前提下相互协作顺起来，工作更高效。
　　简单的说也就是：方向指对，快速推进。第一层是先理顺，第二层是让其更高效。
　　现实工作中你会发现哪里像我们上面说的这几个字这么简单轻松，因为这个事一般针对已经具备一定规模和复杂度的团队组织，接下来会尝试通过举栗子来更接地气的让大家了解组织增长官的范畴和可能的维度。
　　Case1：我们有一个新的想法想去尝试和验证，我们下一步该怎么做？
　　比如：我们想在某一块做些创新和尝试，现在就我一个有想法的光杆司令怎么办？当然先确认方向是否对，或者符合我们的大目标。被认可和确定可以往下推进后，我们来分析你需要的最小作战队和MVP，然后各个角色间怎么配合，制定计划以及如何行动和验证成果等。
　　这里其实说到两个方面：
　　（1）设计模式，就是这件事情怎么跑
　　我简单的分为以下三步：
　　组建所需作战队：之所以加上‘所需’两个字，原因是有很多新的尝试和创新未必像我们想的需要重投入，实际分析后可能会发现，或许这个idea只需要投入2-3个人成立前向攻坚队（不需要把东西先做出来，先去问客户、包装方案、做探索和反馈），或者是需要做个简单原型的5-6人执行团队。
　　MVP（Minimum Viable Product最简化可实行产品）：这个产品经理都熟知的快速验证方式，我们需要分析和确认要验证这个创新和尝试，需要做的最小最简化内容是什么，以便于我们快速实现和验证它。
　　运行机制。
　　（2）制定运行机制
　　为什么又单独把它拿出来了，因为对于组织增长官来说，这是重点，如果说方向、目标是what，那么如何运转和推进就是how的部分，是组织增长官的重点。各个角色间如何协作，设计流程（一环到一环，准入、准出标准等）。
　　这个Case中当我们确定了一个目标，接下来组织增长官要推动事情的发展，就是把他分解成如何去做：设计模式就是这个创新和尝试想法目标怎么跑，谁以及最小可执行产品范围是什么，然后制定运行机制各个角色间如何配合以及如何验证和反馈。
　　Case2：总觉得慢，但说不出哪里出了问题
　　工作中这种现象经常出现，大家都很忙，而且都忙成狗了，可是为什么总觉得还是慢呢（结果、成果）？
　　其实这里有个很要命的东西就是透明和呈现，我们要在错综复杂的现实中去理，让情况呈现透明出来，而且让大家一起看见。
　　我以研发过程为例（其实这个现象发生在各个阶段，我是项目经理就以最熟悉的研发过程为例），开发和测试每天处理手头的工作已经工作12小时了，可是结果还觉得慢、不尽人意。你具体去深入了解，可能会发现一个开发一天手头有3、4个并行的项目在处理，不停的切换还不停的被打扰，为什么会这样？！
　　还有可能一些任务的等待时间已经远远超过做他的时间，等待其实就是浪费。这让我想起经典的Pizza游戏，在交付时如果有过程材料都算浪费需要扣分，现实生活中也是如此，市场瞬息万变，没有形成客户真正可用的产品，中间的过程物就是浪费。
　　换一个角度，如果迭代的周期够短你会发现有些需求永远排不上，而在现实工作中每个版本都存在着伪高优先级需求，甚至可能是半成品的状态存在着。
　　因为本文不是一个案例分析文章，是想通过举栗现象和问题，让大家了解组织增长官的范畴，所以这里不具体展开出现这些情况的原因和如何解题。
　　这个Case里想表达的是团队里会出现各种各样的现象和情况，这也是组织增长官的范畴，当遇到这些情况时组织增长官要做的提炼下是两点：
　　透明和呈现。把情况呈现出来，让团队看见问题，往往现实是大家都忙于脚下，忘记抬头。
　　发现问题，确定问题，自然而然接下来解决问题。
　　另外，组织中每一个阶段环节都会有问题，需要立体的看问题，横轴是职能线，纵轴是项目线。我们需要去看当下最重要紧急的问题在那里，然后解决它。当然组织是系统的，当出现一些问题时我们需要用系统性思维的方式去分析和思考问题。
　　这里让我想起曾上过吕毅老师的系统思考课的确收益匪浅，其实是让大家用系统思考的方式寻找里面的因素、变量，正循环负循环，然后分析和确定你要解决的问题和切入点。
　　以上是笔者理解的组织增长官，在这个过程中他会通过设计模式（这件事情怎么跑）、制定运转机制（人/团队协作流程），发现和定位问题（团队前进的绊脚石），然后去解决问题，对于组织增长官有一个前提和一个核心。
　　一个前提：针对工作流。
　　一个核心：紧盯目标，快速推进。
　　说到这，我们再回到一个本来应该在开头就问的问题：为什么会有组织增长官这个概念？
　　按理来说各部门各角色各司其职应该能够顺利完成工作，而现实很骨感。各角色在自己的边界范围内忙碌冲刺着，很少或偶尔抬起头看看对面。亦或者我们发现了问题，但还是存在屁股决定脑袋的立场问题，有个从第三视角看问题的人强有力的协助推进和解决它是企业需要的，亦或是他们是真正关心和负责快速高效达成组织目标的人。
　　除了为什么会有组织增长官这个问题外，可能还有疑问，如何确认或者量化它的效果？
　　在开头我们也提到它的第一层是先理顺然后是让其更高效，对于第一层先理顺团队一般不会有太大疑问，因为这类情况一般是目前有问题而且是有人有痛点的，帮忙推进理顺之后可能就已达到他们的初衷和效果了。
　　往往是第二层使其高效，这类情况可能不是别人的痛点，而是站在组织增长官或者负责人的角度发现并想改进的部分，或者说在一般角色中这类情况或许不会成为他们的痛点，很有可能是你发现而且想办法去改进然而团队并不买账，那么要有对比证明和量化这个前和后的效果就变成是很有需要的了。
　　所以组织增长官还需要建模，通过建模、收集和分析数据、以及通过做改进来验证效果。
　　比如：Case2中笔者举栗研发阶段出现的情况，或许就可以通过需求、质量和进度来构成这个所谓的模型进行量化对比，如果引入一些改进之后发现在固定时间、质量不变的情况下，能产出的需求量变多了等等。而不同阶段不同层次范围的模型会不同，需要结合具体情况展开分析，但组织增长官是需要聚焦目标且能量化的思路去开展工作。
　　这次笔者想先抛出这个概念，希望在此处有共鸣的朋友一起探讨交流。