编者按：技术好奇心是 CTO 的珍贵品质，是驱动数字化和创新的源动力之一，但也可能导致与经营者背道而驰的结果。于是平衡技术好奇心和业务经营成为企业数字化顶层管理的经典议题。作者试图和企业数字化团队的技术主管们一起探索这个经典问题。
企业数字化产品团队，无论内部或独立的团队，技术负责人和经营负责人都会经历以下阶段。如果他们分别代表彩虹的两端的两种不同颜色，那么沿着这些产品发展阶段走下去，他们之间会叠加出丰富多彩的互动关系，看起来像一道靓丽的彩虹，但有时彩虹也会断裂甚至消失——项目停止或团队解散。
请跟随我体验一次。
产品从 0 到 1 阶段，团队认为再好的设计也是一种假设。这个阶段，CTO 的技术好奇心越强，团队创新源动力越大；也因为产品没投放市场，CTO 与经营负责人之间暂时没啥好争的。只要预算和工期在合理范围，CTO 和工程团队也许会反复折腾多种不同的技术架构，例如：某某服务网关怎么设计、采用什么编程语言（是否要换？）等问题。技术好奇心在这个阶段的积极作用很大，甚至是驱动产品快速往前迭代的主要动力——仅仅因为大家都很好奇「我们选的技术和设计能否产出预期的东西」。
这个阶段，技术团队也往往最容易陷进自己给自己制造的问题、并「自我满足」于解决这些「闭门问题」。毕竟，产品未发布，用户未投诉、市场未投票，一切似乎都是 CTO 说了算。而另外一面，此阶段负责经营的同事或老板较少干预工程团队，哪怕反复听到工程团队说，「您再等等，可用版本没出来呢」。
CTO 这个阶段最需要的是「自律」。0 起步的产品开发只追求制造「MVP / 最可用产品」这个行业经典就是一种自律。只要第一个投产版本能用，任何技术、设计和增加复杂度的东西，能不加就不加入产品。
随着产品投产，早期用户的导入，用户价值和市场价值被逐步验证。
大家一定都很开心。
此时，CTO 和经营负责人自然会围绕产品增长、营收（模式）的话题开始周期的回顾或辩论：三年规划、一年计划、季度指标等，特别是营收策略怎么走、工程团队人力资源如何分配（怎样算合理）等顶层问题。
此阶段，产品设计和版本功能点会逐步固定下来。产品稳定性要求越来越高，需要运营和业务操作的的任务越来越多。此时，CTO 和经营者（CEO、业务合伙人、产品总监等）对产品未来的看法很自然会有不同意见，甚至是彼此对立的意见。
那么，最经典的矛盾来了：经营决策人和 CTO 谁来决定产品策略和执行路径？
答案是：经营决策人。
除非团队/项目的 CTO 和经营决策人是同一个人的罕见例子，否则这个决策节点团队必须认可必须有且只有一位公司领导/合伙人/项目总监的唯一、最终决策权。
产品获得初步市场验证后，CTO 和经营决策人常见的协同问题如下：
一般由 CTO 把控的技术、工程管理、工程资源分配，是否偏离经营目标，这个判断是很难做到的。此时，要求 CTO 努力站在经营决策人鞋子里思考，并尽量公开及时反馈自己的思考；另外一面，经营决策人则需要利用例会主动提问 CTO 产品和技术是否对齐经营目标，一般按季度来考察这个问题。
技术好奇心驱动下，也因为产品初步获得市场青睐，只考虑满足技术好奇心的 CTO 往往会在产品和技术架构中加入更多自己认为「好玩」或「有用」的东西，例如：引进某个新的前端技术框架，或过早实施全面的微服务，从而导致产品不稳定甚至平台复杂度提前、无理由攀升，最终拖垮数字化业务或具体项目。习惯单向思考技术价值的 CTO，容易给技术平台带来和业务经营目标不般配的「技术和运营复杂度」。
此外，技术上过度保守也会导致技术偏离企业经营目标。
例如，一听到第三方「无服务器」就拒绝，技术团队认为自己把握的东西过少，不信任；而一改拒绝思考评估「无服务器」后端对简化数字化业务和运营意味着什么。「知晓云」无服务器的诞生，就是顺应「规模化标准化云计算外包」的趋势，使得业务应用团队可以更专注业务，提供更丰富更稳定更安全的整体用户价值。经营「知晓云」这些年，我们看到过太多超预算投入移动端 app 和/或小程序开发而导致项目整体资源不足、最终失败的案例。
经营目标的修改，必定意味着产品和技术的修改。
虽然经营目标和指标可以修改，但建议遵循「至少维持一个季度不变」的原则。三个月对应一个绩效和财务季度，刚好方便把某个版本的产品从起步到验证、回顾等工作走完一个小循环。任何产品迭代计划如果少于 1 个季度，都存在「瞎折腾」的危险，因为任何产品设计都是「假设」，而「假设」没有足够机会得到验证，所有下一步的决定都无从谈起。除非有更高层级的原因说：我们必须放弃/停止这个项目或产品。
没有在初创公司，跟随产品和团队完整地从 0 到 1 走过来的 CTO 或产品经理，最容易犯这个错误。毕竟你所待过的所谓「互联网大厂」，你一直是个大一些的螺丝钉，而已。他们不容易看到业务发展和产品、技术迭代之间，在每一个阶段，彼此有什么依赖关系。
这点最微妙，也最难察觉。
CTO 在好奇心趋势下积极把新技术和设计加入到产品中，一般会有业务目标或工程改进的目标，但有时候这事纯粹是 CTO 个人好奇心驱动的决定，例如加塞一些自认好玩的设计或技术到已经稳定投产的产品版本中，甚至自己都没有想明白这些新技术、新改进对应的业务、工程目标是什么。
对于已被市场初步验证的产品，复杂度是团队的最大敌人。毫无疑问，产品背后的软件工程复杂度越高，它驱动的业务所需的运营成本越高。例如：15 人不到的团队，在考虑移动端技术架构的时候，如果没有认真考察过类似「知晓云」这样的无服务器后端平台，那么产品对应的移动端/小程序的研发和运营成本一定不会低。
反之，如果决心采用「无服务器后端」支撑你们的移动端客户体验，那么连带的预期收益是：团队会节省更多的时间精力去服务用户和客户，更专注设计和迭代团队的核心服务和数据架构，而不是分心去运维和管理一堆传统的云计算资源，例如要多少 VPS，如何搭建集群等等更底层的技术复杂度。
这个例子中，采用知晓云的验证目标很显然就是：我们之前 1 个季度按资源规划只能产出 3 个功能点，采用知晓云后能否推出 5 个并获取更多新用户和客户？
当然，最没底线的事也可能发生：团队/合伙人/管理层里，根本没人提起技术和业务是否对齐的话题。CTO 只顾按计划设计开发和推出版本，业务决策人只顾造势或者所谓的「发展客户和用户」。
对此，只能说「祝你们走运」。
这个阶段，产品获得市场验证而且稳步增长。
此时，我们最容易犯的错或疏忽是：「胜利者偏差」。
高质量的产品策略和决定，可能因为市场环境等外部因素得到不好的结果，此时我们一般会努力分析因果关系。
低质量的产品策略和决策，也可能因为外部因素暂时带来好的结果，此时我们一般会忽略因果分析甚至陶醉在成功的喜悦中。
实际上，成功的产品或项目团队，是不会放过任何回顾和分析因果关系的机会的。从一起努力过的经历中，团队一起认真回顾其中的因果，对比错失的机会、现有的成果以及「应该还可以取得哪些更大的成功」，等等，我们都有必要分析一次。
分析的结果往往超越所有人的认知：即不是 CTO 最初设想的、也不完全是经营者设想的。例如：企业 SaaS 产品最经典的误区是——我们在对的时机开发好的产品投放市场，用户自然来，用户增长和收入是自然而然的事。
这和企业产品市场的现实相差很远很远。
对于 CTO 个人曾经在上一份 web2 时代互联网企业积累的 CTO「成功经验」，如果放到企业级产品市场中，往往是格格不入的。web2 时代曾出现过各种红利，例如移动社交网络，但绝大部分已被耗尽。企业市场虽然不是「存量市场」也不是「价值固定的大饼」，但企业工具的新价值必须实打实挖掘、设计和创造，其底层逻辑和「互联网思维」没有半毛钱关系。CTO 和经营决策人能重复使用的遗留资产是：工程方法论以及对商业基本逻辑的认知，产品方法论对于习惯「互联网思维」的团队在企业市场必须推倒重建。
例如：企业产品起步阶段往往走用功能单一、从企业基础个人用户的需求突破的发展道路，或者首先服务付费能力低的中小开发者群体，随着产品成熟和验证，业务营收方面需要在未来某个节点实现突破，团队资源必须整体从中小用户市场转移到中大型行业客户的业务上。从服务中小用户到中大型客户的转型（向上销售），往往决定了项目或产品团队的生死。
既然产品市场最终会超越所有旧的认知，那么 CTO 和技术团队需要有足够的谦卑，在充分发表自己（不同）意见和分析后，充分尊重最终、唯一决策人的决定。CTO 和技术主管们需要保持足够的谦卑，让业务和市场带头人带领我们往前走，即要能和业务决策人探讨技术的是什么和为什么，也要让自己的技术方案保持足够领先、足够敏捷，使得业务决策人和一线销售/服务团队能时刻明白我们在「做什么」和「为什么」。
技术好奇心本身并没有任何可耻的，相反，她是驱动技术人从小到大、从新手到老手的主要推动力，也是我们欣赏和认知更多新技术的基础。
技术人的谦卑最终能帮我们融入任何组织并理解更广阔更多元化的「非技术价值」。我们即不会因为技术暂时没发挥作用而看低它们，也不会因为极度渴望「探索技术」而罔顾公司业务的必要性而导致产品或项目发展受挫甚至失败。
（封面摄影：Jon Flobrant）
加载中,请稍侯......