早期取得了不错的成果后，我感到公司内部对于“增长实验”的态度慢慢发生了转变，我能调配的工程师和设计师资源也明显增多。于是，我乘胜追击，又在产品内外的其他关键路径上进行了一系列测试，也取得了很好的结果。
结果就是硬道理，我一直以来倡导的独立运营的增长团队，终于得到了CEO和管理层的全力支持。
但是我没想到，组建增长团队的过程，远没有想象得顺利。招募增长团队的成员是第一关。
在招募增长工程师的过程中，我感觉到公司里的同事有不少顾虑，于是我跑去和那些做过增长实验的程序员们聊天，了解到以下想法：
“增长实验都是些很小的改动，这边换个文字，那边换个颜色，没意思……”
“做好几个版本，最终肯定有一些版本的代码是需要扔掉的，感觉自己白干了……”
“……但是我喜欢的部分是可以清晰地看到自己工作的结果，有时候做产品功能，做了很久，突然被停掉了；或者即使上线了，也不知道到底有没有用……”
了解了程序员们的顾虑之后，我明确了以下几点：
第一，应该尽量把程序员从烦琐的文本测试和小改动中解放出来，让他们去做更复杂、更有挑战性的实验。采用提前埋点的方法或者第三方测试工具里的高级功能，其实可以很有效地解决这个问题。
第二，程序员喜欢看到自己的工作有影响力，要充分调动他们的积极性，需要让他们参与到产生实验假设和实验设计的整个过程中去，并且及时地把结果反馈给他们。
第三，不是所有程序员都适合在增长团队，如果只追求技术深度，在增长团队里显然不是最合适的；但是对于那些有产品思维，喜欢看到自己的工作对用户和业务有影响的程序员来说，增长团队的工作其实是更有吸引力的。
本着这样几点原则，我终于成功地找到了几位合适的程序员。在设计师方面，我们的一位资深设计师，很顺利地加入了增长团队。他是完美的增长设计师人选，业务水平高、出活快，最关键的是他对增长指标和用户心理有深刻了解，认同“设计最终为用户服务”的理念，不歧视“简单却有效”的设计。
有了这样一个“全栈”团队，增长实验的上线基本上可以不依赖其他团队了。每天早上，我们团队会有10分钟的站立会议，汇报昨天做了什么、今天要做什么，以及有什么障碍。以两周为一个周期，一般我们能上线好几个增长实验。
得到其他团队的支持是第二关。
很多增长团队诞生初期，会面临要向全公司证明自己的局面，我们也不例外，时不时听到来自其他团队的怀疑的声音：
“为什么要有统一的增长团队？不是应该每个产品功能团队自己设计实验驱动增长吗？”(www.xing528.com)
“程序员资源这么紧张，专门去做实验那不是浪费了吗？”
“我们辛辛苦苦做的设计，凭什么增长团队说改就改？”
……
正如前文所说的，增长是一件“套路”“流程”和“文化”三位一体的工作。在组建独立增长团队的过程中，我再一次认识到增长文化的重要性。因为，“增长”对大多数人来说，是一个新鲜事物，大家对它的了解程度并不高，甚至有些人还会有种种的误解和恐惧。但增长又是一个天然需要跨团队合作的工作。因此，作为一个增长团队的负责人，你需要花足够多的时间，做好教育和宣传工作，让大家了解并认可你们团队的工作，给予支持。
我的尝试从组织一个每周实验心得分享会开始。我邀请了产品部门、市场部门、设计部门和客户服务部门的代表参加，每周分享实验的结果和从中得到的心得。开始只是增长团队分享，很快市场团队的同事也开始分享广告测试的结果。大家互相提问，提供意见，还经常一起玩“猜猜哪个版本赢”的游戏。没过多久，这个会议就被很多人称为他们在公司里“最喜欢”的会议。
除了这个每周实验心得分享会，我还在公司的企业通信工具Slack上面开通了一个“实验心得”的群组，每周定期发布实验的结果和心得，针对不同目标组织一系列面向全公司的头脑风暴讨论会，并且组织了一个“每周管理层增长讨论会议”。
经过一系列的努力，在不到一年的时间里，我从加入公司时公司没有增长团队，发展到建立了一个独立运转的增长团队，这期间，我们通过增长实验达成了好几个领域指标的大幅度提升，并且逐渐地让全公司对增长实验感兴趣，同时对增长文化有一定的认同。我给自己这一年的“增长黑客之旅”打80分。
而我所面对的挑战，也是所有增长团队负责人所面临的挑战，仍在继续：
1）在“低垂的果实”慢慢被摘掉之后，如何持续保证产生好的实验结果，驱动增长指标？
2）面对激烈的竞争和变化的环境，如何离用户更近、如何持续创新让增长实验成为产品的竞争优势？
3）如何保证增长流程高效运作、增长团队内部紧密合作、有主人翁的感觉？
4）如何确保和其他团队以及管理层的良好沟通和合作，得到大家支持，达成共赢？
5）如何让增长实验和数据驱动成为公司文化的一部分？
……
环境瞬息万变，增长永无止境，挑战层出不穷，这也是对我而言，增长最有意思的地方之一吧！
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
