为什么研发团队也需要重视业务贡献

在业务导向的公司，研发团队通常主要的责任是支撑主营业务，因此对业务的理解、对业务的价值判断往往成为研发团队能否发挥重大作用的瓶颈。
对业务的贡献首先是对内创造价值，需要深入到业务侧，跟业务团队共建挖掘业务上需要IT系统支撑的改进点，通过输出整体性的的解决方案、开发系统、开发工具、优化流程等方式实现内部效率提升、内部低端工作的替代、企业管理的数字化等，总体表现为人均创造的业务价值的提升。
对业务的贡献不应该仅仅局限在对公司内部团队的支撑，否则整个研发团队会成为业务的附属，缺乏话语权，资源上也会受限。而应该站在更宏观的业务上去思考整个研发团队应该如何去定位、如何去帮助主营业务、如何形成自己的独特的价值等，在支撑主营业务等同时能够创造一定的独立空间，形成自己的发展节奏。这些独特的价值包括对业务的前瞻性引导、对外部客户的直接支持、以及对企业科技形象的提升等。

跟业务团队共建实现内部价值

通常很难要求技术团队能像业务团队一样，知道业务的种种细节和问题，所以研发团队需要跟业务团队建立良好的合作，通过共建的方式进行相关系统开发。
业务团队通常在描述需求时，通常存在下面的问题：

• 业务的管理者很多时候提出的是非常宏观的需求，比如“我希望实现一个智能的自动化投放托管工具，通过数据模型，自动化出价，把ROI提升上去，同时把投放人员的成本节省下来”。这个可能代表业务管理者通过观察和自己的理解，判断这块存在业务优化的空间，但究竟能不能做、以及怎么做，都需要业务执行人员、需求分析人员、研发团队共同去落地；
• 业务的基层执行者出于自身工作范围的局限，很多时候也仅能看到自己负责的执行层面的事情，比如“我希望这个投放系统能跟我平时投放一样，碰到条件A就执行这个，碰到条件B就执行这个”，实际上可能这个业务人员只是罗列了自己认知中的某些场景，实际上还有很多隐藏的规则在下面，以及各种规则嵌套，甚至还有些决策条件无法用规则来概括，所以也需要需求分析人员通过对不同场景的调研，去获取规则和将规则抽象化，以及去发现无法用规则去判断的场景；
• 业务人员往往都会强调自己的需求很急，因为对他而言，这个的确是一个很急的事情，他并没有必要性站在整个业务角度思考自己的需求的普适性和重要性。所以往往也需要需求分析人员通过进一步了解业务，站在全局角度判断需求的重要性。

而研发团队在面对业务需求时，也可能存在一些沟通或者观念上的问题：

• 研发需求分析人员变成了业务人员的执行者，即业务说要做什么就做什么，没有判断需求的价值和优先级，也没有深思这个需求背后真实的原因是什么，最后做完的需求可能没有什么用；
• 也有些研发人员可能会带着“迷一样的优越感”俯视业务人员，认为他们不懂产品，不懂行业，提出乱七八糟的需求，但帮业务人员去挖掘、呈现和实现需求，不也是研发团队某些专业性能力的体现吗？
• 还有些研发人员会抱着一种技术只管技术的思维，只需要注意技术团队的技术氛围，以及技术能力提升等，不认为自己需要去熟悉业务，不去看产品实际落地的结果，不认为业务绩效跟研发团队有什么直接的关系等。这种情况下，通常技术人员和业务团队可能会泾渭分明，很难形成合力，甚至可能会互相拆台。

所以研发团队需要抱着好奇的态度去跟业务团队管理层、执行层都进行充分的调研沟通，形成客观的调研结论，编写场景考虑全面的业务需求和方案文档，抱着谦虚的态度给到业务人员进行评审，研发环节多跟业务人员沟通，确保用户验收是必须经历的环节，以及持续跟进业务使用效果，并通过优化功能去达成更大的业务效果。

重视研发成果在外部应用的价值

一个组织的价值是通过组织外来体现的。同样一个研发团队创造的价值也是在研发团队外部体现，包括对本公司的价值，以及在公司外的价值。
通常在一个业务主导的公司，研发团队不需要太多关注在公司外部创造的价值，因为业务运营是这个公司的核心。然而从研发团队期望自己实现独特的价值层面，需要站在一个更高的视野看待这个问题，即从整个公司经营、团队发展角度看，研发团队能创造哪些外部价值：

• 技术的护城河：业务运营通常依赖人，好的业务运营依赖好的运营人员，所以会带来业务扩张瓶颈。通过在技术上领先竞争对手，达到更低成本的扩张能力，公司除了创造更高利润外，还可以树立更加科技化的外部形象，吸引更多的优秀资源；
• 对客户的支持和绑定：业务运营说到底，运营的是客户，包括2C或者2B客户。尤其是2B客户，能给客户提供一套完整的、开箱即用的方案，通常也能帮助客户更好的进行业务扩张，也能将客户绑定到本公司的技术方案体系内，带来更高的“离婚”成本，客户也可能会因为这个“技术溢价”，认为享受到了更好、更全面的运营服务；
• 利用外部客户完善自身的能力：从0搭建一整套行业解决方案无疑需要长期大量投入，同时也需要吸引优秀的人才。在公司本身还比较小，但是又期望发展超出行业竞争对手的技术壁垒时，有一种策略是利用外部客户去完善自己的能力，去发展优秀的团队。当公司本身就有一个优质客户池子时，这种策略是可以奏效的。电商运营公司就是这样一种典型的公司，当大量优质的品牌客户引进公司后，自然会同时寻求贴身技术解决方案供应商，通过这些客户可以获得持续的IT产品销售机会，持续的IT收入，进行完善本公司的IT行业解决方案，同时由于服务外部客户通常需要更优秀的人才，因此也能逐步进行团队的完善和升级。

内外部价值相辅相成和优先级判断

通常在业务和团队发展初期，仅能维持一个“迷你”的研发团队，依赖领头人的专业素质，去勉力响应最核心、优先级最高的业务需求，研发团队也会逐步搭建点状的产品或工具去满足业务和客户需求。
随着技术积累的增多，研发团队可能会发现自己面临更多的机会，比如公司新接入的客户需要不同类型的IT解决方案，比如公司新业务需要系统支持，比如公司内部信息化存在效率改善点等等。
此时团队可能会在资源上分化成一个着重在内部信息化的团队，帮助公司解决内部效率问题；一个着重服务客户的团队，帮助客户提供IT解决方案。此时就会涉及到内外部孰轻孰重的问题。通常需要客观评估内外部创造的价值进行理性决策：

• 并不是内部有新业务就马上需要开发IT系统支持，而是需要根据业务价值、潜力、行业是否有通用工具进行判断，通常需要让业务跑一阵，验证了业务的长期价值后再考虑动用研发资源。当然也有可能某些领域判断是将来的重点突破的增量领域，在公司进行决策后，也可能提前进行业务的布局；
• 并不是内部信息化所有的效率优化点都需要研发资源支持，毕竟每个系统除了一次性开发成本外，还有一直有维护成本在。通常也是优先使用行业通用工具进行支持，对需要新立项的产品需要进行严格的立项评估，判断必要性以及长期的价值。可以用一种产品化思维做决策，即这个事情是否值得做一个长期性的IT产品来支持；
• 并不是所有外部客户的IT需求都承接，而是需要考虑它对整个IT产品体系的完善，考虑外部客户实施场景对内部业务的反哺，考虑客户对公司的价值，考虑整个研发团队的能力是否能承接，考虑对团队能力的升级等方面。
  实际上，当一个内部信息化研发团队开始“觉醒”时，内部的需求可能无法满足这个团队对自身的进一步要求时，对外拓展就成了必经之路，IT产品会随着客户的实施而完善，更优秀的研发团队也会在对外实施过程中发展起来，这条路就停不下去了，内外解决方案的协同通常称为团队健康发展之路，即内外部应用场景共同完善产品体系，内外部客户按照一致的价值判断去实施和支撑，在公司的顶层愿景下，去构建内外部协同发展的IT愿景。甚至随着技术解决方案的发展，研发团队也有可能按照独立的业务线运行，外部客户和内部客户都可能可以按照统一的实施思维进行支撑和结算，研发团队本身也变成了业务团队。

对研发团队的能力边界保持清晰的认知

随着业务的发展，研发团队也会有“思变”的烦恼，比如，该不该扩张，要不要重构，要不要加大拓展客户等，这些决策核心还是建立在对公司业务前景和团队能力边界的认知上，判断是这些变化是否可以创造更大的、持续的业务价值：

• 团队当前的人力瓶颈是什么：不同的团队负责人是否已经成长起来了，足以支持团队扩张？若不行，则需要先解决团队负责人的问题。
• 公司主营业务是否足以支持研发团队扩张：研发团队毕竟在很长一段时间内通常都无法独立养活自己，主营业务是否能维持长期快速增长来支撑研发团队的扩张？主营业务出现波动时，研发团队可能会面临哪些压力？
• 研发团队自身能覆盖多大的成本：判断研发团队中短期可能带来的收入，以及内部结算成本部分公司可能的承受范围，在可控范围内控制人力结构。
• 积累多年的产品是否需要重构：旧版本是否已经限制了业务的发展？团队资源上是否足以应对重构？是否能接受因为重构可能丧失的业务机会？也是否能接受因为不重构可能丧失更大的长远的业务机会？
• 要不要对外大范围拓展：判断产品对业务场景的完整度支持，实施成本、维护成本、团队人力等，是采用“重”的方式进行大客户IT咨询+实施，还是“轻”的方式进行小商家拓展等，还是继续维持现状，在核心种子客户上继续完善？
  在业务发展比较顺的时候，很容易得到类似的建议：“趁着现在业务顺风顺水，抓紧扩张，做成既定事实，也可能获得更大的机会。”但深思熟虑后还是倾向于保持一个满足可预期的业务发展范围内的团队，毕竟天有不测风云，因为管理人员思考不当造成的人员波动也是对团队的一种伤害，可能需要付出更大的代价去修复。

面向未来的能力储备

当公司或者团队基本摆脱了疲于奔命的阶段时，就需要思考面向未来的能力储备了：

• 存量业务的支持：存量业务主要增长方向在哪里，公司的发展方向在哪里，客户的主要需求会在哪里，IT产品在这里能提供什么价值？
• 增量业务的支持：当前行业热点在哪里？是否可以技术先行，用快速搭建DEMO的方式进行验证，实现技术解决方案引导业务发展，提前占据先机？
• 产品的升级：为了更加快速的适应将来业务的发展，当前产品是否需要进行重构升级，升级不升级的弊端判断。
• 团队的升级和梯度建设：团队负责人、团队主管和骨干是否能跟上业务的发展？是否有意识的培养一些潜力之星作为后续梯队，在业务发展发展到一定阶段刚好能接上？团队的组织架构是否从初期项目制开始向更规范的团队架构转变，相关流程也往更正规的体系靠拢，团队扩大时不至于陷入混乱和浪费？
  面向未来说起来容易，但实际上会一直受到资源的约束。毕竟未来不可预测，作为盈利组织，企业行为有时候会短视，尤其是业务导向的公司，研发部门作为“成本”存在时，可能会更难协调到资源。但研发团队一定要考虑将来的发展，毕竟研发的产出周期可能会比较长，不提前规划会导致有需要时措手不及，再次陷入“疲于奔命”，更无法思考长期的价值。
  此时通常需要研发负责人的一些智慧：
• 跟业务共建进行未来规划的落地
• 充分进行业务调研自发发起某些面向未来的项目
• 通过外部客户的需求发起某些项目
• 在团队顺风顺水的时候适当保留部分资源投入到未来能力中
  总之，建设面向未来的能力是研发团队期望发展壮大，实现其独特价值的必经之路。