我们采访了Pinterest和FanDuel等发展最快的公司的20位高管，以帮助您回答这个关键问题。经过30多个小时的采访，我们想通了一件事：选择合适的团队发展模式，不仅有利于公司的发展，也能强化企业文化。团队开发模式从我们的访谈中，我们可以总结出两种比较流行的团队开发模式：一种是独立模式，另一种是职能模式。如果您想组建自己的开发团队，两者都是不错的起点。“当游戏开始时，以正确的布局进行游戏”（ZackOnisko，CreativeMarket首席开发官）。每个模型都专注于“更深入地了解您团队的开发模型”（MikeDuboe，Tilt开发官），然后全力以赴解锁货币化。单机模式总结Uber和Facebook都在使用单机模式。在我们的采访中，我们偶然发现了该模型的两个主要版本：在这两个版本中，开发副总裁领导团队。例如，在Uber，EdBaker是开发副总裁，直接向CEOTravisKalanick汇报。Ed领导着一个100多人的团队，与产品、营销、工程、设计和数据方面的专家合作，共同开发供应和需求。根据受访者提供的信息，Uber通过这种模式来提高团队生产和迭代的速度，建立强大的团队DNA。Uber非常重视速度和迭代，他们的开发团队为此建立了强大的反馈机制，这反过来又体现在Uber的产品中。反馈机制可以帮助老用户群体发展新用户群体，这通常是由老用户的搜索、支付和推荐机制触发的。例如，新用户在听了老用户的推荐后开始使用Uber，这就是推荐反馈的结果。司机加入优步是因为他们看到了“成为优步司机”的广告，这是为广告付费的结果。在这两种情况下，无论是供给侧驱动还是需求侧乘客，都是老用户利用反馈机制创造新用户的过程。Uber开发团队的工作就是让这些反馈机制尽可能强大，以增加公司的乘数效应。比如Uber的推荐反馈机制的乘数效应中的乘数是“10”。这意味着优步通过线性方式（例如付费广告）获取的用户将创造十倍以上的新用户。如果团队通过付费广告获取了1000个用户，那么这1000个用户也会通过推荐反馈机制创造10000个新用户。乘数效应越好，Uber的增长速度就会越快。独立模式的冲突与解决方案PinterestDevelopment的产品经理CaseyWinters认为，独立模式的冲突是不可避免的。当Pinterest独立时，开发团队的人数一直在增加。事实上，Pinterest的用户数量增长如此之快，以至于其他团队开始担心这种快速增长是否以牺牲一般用户体验为代价。例如，当开发团队推出新的注册界面时，用户活跃度急剧增加，但焦虑感也随之增加。其他团队认为这个过程让用户体验变差了。然而，这些数字最终将抵消其他球队令人痛心的言论。这需要在保证用户体验的同时保持增长指标的稳健性，是在采用独立模式的过程中需要面对的最大挑战。关于这种增长是否必须以牺牲用户体验为代价的争论很多，如果不采取任何措施，“这将导致对该平台缺乏信任，”温特斯说，并补充说“人们应该理解（并相信))开发团队会尽最大努力为用户带来最好的体验。”建立信任你如何在不同团队之间建立起最基本的信任？Casey对上述问题有一个很好的建议：让开发团队书面承诺他们不会为了增长指标而做损害用户体验的事情。我们的一位受访者建议遵守与文化创造者CEO的承诺，并让开发和产品副总裁也签署该承诺，以减少独立模型中的冲突。据Invoice2Go开发主管NaomiIonita（前印象笔记开发主管）介绍，开发部门的工作不可避免地会与产品部门发生重叠。根据她自己领导两个团队的经验，她解释说，如果产品开发领导层有明确的分工和良好的沟通技巧，这种冲突问题是可以避免的。问题又回到“信任、透明和客观”。职能模型总结受访者表示，当开发员工需要向职能领导（例如产品、工程等）汇报时，其他人认为开发指标将以正确的方式实现。Pinterest、Twitter、LinkedIn、Dropbox和BitTorrent使用功能模型。这种模式的流行得益于以下三个优势。1.职能主管（如产品、工程等）决定开发计划。2.由职能领导平衡增长和非增长举措。3.产品副总裁通常担任职能领导的角色，因此负责开发。让我们看看第三个条款在实践中是如何运作的。PramodSokke是BitTorrent的产品主管，能够与平台上的所有客户进行交流。他负责BitTorrent的增长和非增长指标，这意味着Pramod的产品规划必须围绕增长和非增长绩效展开，因为他负责这两个团队的绩效。BitTorrent开发团队以外的员工也信任Pramod，因为他以平衡的方式处理该计划，确保了所有人的成功。功能模式的冲突与解决方案尽管如此，用户体验与用户增长的矛盾仍然存在于功能模式中。由于上述几个优点，冲突不像在独立模式下那么明显。冲突持续存在是因为确保用户增长的措施往往与用户对产品的期望背道而驰。这就是我们的受访者提倡纵向分析的原因。通过对用户行为的分析，我们可以知道用户增长是否会以牺牲用户参与热情为代价。同时，你也会了解哪种开发方案可以保证用户增长，提高用户参与度。我们还了解到，当增长指数的负责人是数据驱动的，并且认识到产品需要迭代和学习机制时，功能模型将是最有效的。这样，产品开发蓝图就不会凭直觉规划出来了。例如，Pramod对其产品采用了非常典型的数据驱动迭代方法。这使得团队中唯一的开发项目经理AnnabellSatterfield更有效率。因为这种方法很好地结合了数据分析和迭代过程。Annabell解释说，她使用的增长过程是数据驱动和迭代的。跟直觉无关，全在过程本身：观察数据（定性和定量分析），提出假设，推出测试计划和Minimumviableproduct，观察测试结果，判断是否要带这个实验产品市场或从头开始吸取教训。现在让我们以假设的方式说明功能模式中的另一个潜在冲突，假设数据驱动和产品迭代这两个过程不能很好地结合在一起。例如，Pramod使用非迭代方法进行产品管理，而Annabell仍然使用迭代开发模型。Pramod可能会要求Annabell在产品路线图上大放异彩，这个过程需要6-12个月。Annabell可能会同意Pramod，但她也可能在几周（或几天）内证明数据驱动的产品迭代都是不好的。Annabell说，从收入和用户的角度来看，这样做会增加产品的计划成本。我们的一些受访者会通过更改产品蓝图来解决冲突。在上面的假设示例中，Pramod可能希望两者都做，而不是将所有产品工作都固定在一个模型上。一个轨道用于练习Pramod的非迭代方法，而另一个轨道使用Annabell的迭代模式。每个赛道都有自己独立的产品、工程和设计资源，以确保所有功能在计划的时间和预算内完成。高层企业必读（两种模式必读）。不管怎样，为了促进发展，顶级公司必须引入数据驱动和迭代的思维模式。否则，无论你如何规划你的开发团队，都难免会失败。结论在我们生活的软件世界中，开发和产品交织在一起，这意味着很难知道产品在哪里结束，开发从哪里开始。这仍然是一个相对较新的现象，同时也使得选择最佳团队开发模式具有挑战性。我们的受访者，二十名开发主管，无一例外地提到了两种最流行的模式：独立模式和功能模式。当您希望随着业务规模的扩大而建立自己的开发团队时，这两种模型都是很好的起点。单机模式可以在运行增长实验的同时加速产品生产和迭代。但是，这种模式也导致了团队工作透明度的降低，导致企业内部不信任的滋生，而职能模式则因为更平衡的发展模式而增加了工作的透明度。但是，无论如何，用户体验和用户增长之间的矛盾依然存在。有趣的是，我们没有发现两个模型的结果有太大差异，这意味着在实现产品更大的指数增长方面，两个模型都不比另一个更好。这是一个非常重要的发现。因此，在为团队选择发展模式时，综合考虑企业文化、组织结构和战略适应性，可能会获得更好的结果。企业发展不要只选择一种模式，要选择适合自己的模式。两个模型都有自己的冲突，选择冲突在你团队范围内的模型来解决，然后选择一个气质能与之相适应的人作为团队领导。开发负责人与产品团队的关系，将对你选择的模式乃至整个企业的成功起到决定性的作用。作者Andrew(Drew)McInnes目前在Tradecraft工作。在此之前，Drew是社交移动游戏业务（特别是在Zynga）的开发产品经理，并希望继续致力于帮助构建开发引擎。
