这些问题阿里的技术团队也会遇到，所以我们一直在思考到底发生了什么，我们应该怎么应对。我大概从时代背景和组织形势两个方面去找一些线索。

要搞清楚这个问题，我们首先要看一下我们处于一个什么时代。

VUCA 时代已经到来，我们也不可避免的需要去面对 VUCA 的状况，这样就会发现很多情况：

这些 VUCA 的特征都会传导到技术团队，如果我们还在用以前平台化、确定性、单一性的思路去作战，会有非常多的不适应感。

1）协同的复杂性

随着公司组织规模的扩大，组织结构也变得越来越复杂，业务线，产品，技术，职能团队，各种上游和下游，一个项目运作协同的团队非常多，大家优先级可能对不齐，合作的时候各有各的目标，不可避免地存在组织内耗，相互踩脚。

2）团队内部管理的复杂性

新的 90 后、95 后逐步登上舞台，他们更加活跃，追求工作的兴趣和快乐；新人与老人的交叉，职业诉求不完全相同；公司外部信息量很多很杂，包括一些负面的诸如内卷，PUA 之类的负面消息；同时外面诱惑很多，给我们的组织成长提出了新的挑战。

在时代背景的变化和组织成长的新的形势下，我们有没有办法践行一套新的思路，来重新激活我们的团队？   

在同城零售创业的这段时间，我们一直在思考和探索如何践行创业文化，去解决面对商业愿景的构建和组织能力激活的挑战，这段时间以来，看着我们的产品一天天长大，客户规模一天天变多，团队也在一天天成长，目前看起来取得了一些初步结果。在面向创业环境文化中，我们也踩了不少大坑，也慢慢摸索出了一套粗浅的思路，给业界技术同行们做个分享。

要做成一件事情，首先是创始人得问问自己：你是不是相信这件事能做成？要是自己都不相信，那谁也救不了这个团队；唐僧师徒能够成功到达西天取经，最关键的因素是什么？是唐僧取经的信念是非常坚定的。

拥有坚定的信念之所以这么重要，是因为创业所面对的复杂性，不确定性，多变性，必须要强大的心力才能走到最后，才可以在面对失败和痛苦的时候爬出泥潭，并且在大团队面对诱惑或者方向跑偏的时候能将方向拉回。

拥有坚定的信念是和一般非创业技术团队的根本区别，没有信念的团队就是一个接需求、做项目的常规团队，只能随波逐流，成就平平。

注意一个点，坚定的信念并非个人YY，而是各方面综合判断之后形成的方向认知。比如我对于我们团队创业的方向，是结合商业&技术趋势+公司战略需要+技术团队的兴趣与成长诉求，这三项因素的综合分析得出的结论。这个逻辑推理是非常严密的；所以这里面对技术 Leader 的知识视野、技术格局、战略定力有非常高的要求。

“思考透彻，行动坚决”，是我比较相信的一种处事方式，想清楚了，就坚决地做下去。

创业要成功，不可能是创始人一个人在跳舞，面对如今商业世界的复杂度，创业项目的成功必须要有一支高度认同产品愿景的核心团队；这种高度认同是创业成功的关键力量！

为什么核心团队的核心理念必须要高度认同？因为创业项目的生死随时命悬一线，在关键时刻是需要靠大家凝成一股绳去渡过难关，所以核心团队必须要在核心愿景、核心策略和核心价值观上面达成高度一致；反之如果核心团队如果调频不一致，哪怕核心同学中有一个人不一致，会造成团队成员心态上面的动荡和内耗。

所以当核心理念对不齐的时候，一定要及时识别到，并且坐下来拉齐认知。当核心团队要引入新的伙伴，一定要把理念对齐；说得严重一点，如果核心理念完全不认可的同学，让他离开这个创业项目也是一个选择。

那什么是核心理念，就是创业项目的核心愿景和方向、核心策略和核心价值观，我可以列举我们团队的一些核心理念大家感受一下：

而其他方面诸如人的性格差异、能力模型、工作方式有差别，这是可以兼容并包的，只要不涉及核心愿景、策略和价值观，关系都不大。

跳出公司看行业，是与面向内部研发团队的视角上面的根本性差异，其核心理念是站在整个行业视角去看所处的创业方向，而非仅仅从公司自己的视角来看。

1）眼光的要求

为什么创业团队一定要跳出公司看行业？很简单，因为创业是要帮公司去打下江山，眼光就不能局限在公司内部；你的客户、竞对、伙伴，都可能在公司之外，如果光盯着公司内部做事情，那自然是闭门造车，要么是故步自封；正所谓高维打低维，如果视角不拉高一个维度，就无法做出高于这个维度的事情；别只是盯着老板在想什么，管理层在想什么，多走出去看看，管理者们走出去看看真正的行业在发生着什么，可能更能够理解现在公司所处的市场格局。

2）打破资源依赖性

什么是真正的创业精神？哈佛大学商学院对其的定义是：“创业精神就是一个人不以当前有限的资源为基础而追求商机的精神”。我们站在公司的肩膀上，可能很容易搞不清楚是我们自己牛，还是公司这个平台牛，如果单独把我们自己拿出去，会不会被竞对秒成渣？比如别人和你合作，是看重平台本身的资源，还是你的产品做得真的很好？所以要开创真正的格局，一定要忘记自己是谁，要有扔掉拐杖的勇气，自己就能够在市场中摸爬滚打一步步长大。

那具体来说，应该怎么做呢？有几个参考点给大家：

做客户的朋友，是对客户价值的一种更高的要求，这一点在面向创业环境的时候更加重要，而且我们有着非常深刻的体感，都是一些是实战之后的经验：

1）不要 YY 需求

搞的每一件事情都需要说清楚哪类真实的客户，什么痛点，什么诉求；这个点特别重要，客户的真实的场景，和我们的逻辑推理有很大的区别！在真正面向客户以后，你会发现我们靠推理想出来的痛点和路径，打准的概率是很低的；多去现场，涉及重要的线下交付，要去现场，去现场，去现场！现场会让你更加明白真实的现场和意向的场景有多大差别。

2）让阳光同时晒到每一寸土地

缩短每个职能角色获得痛点和需求的路径，也就是打破惯常的瀑布式路径，每个角色都应该真真切切体会到客户的一手痛点，确保大家真正搞懂了客户的问题，客户的声音一定要让每一个职能的人听见。

3）天使客户的成长

在产品初期打磨阶段，有客户愿意陪着你走，是很重要的，千万要保持良好的信任度，和客户一起成长。好的口碑和坏的口碑，都是很快会传导的！

4）客户问题的响应速度绝对是第一优先级

比如对于 toB 的产品体系，逐步摸索出来，有几个机制特别重要：block 问题日清；每周固定 review 客户问题；每个客户建立专属服务群，业务、产品、开放、测试都在里面。

5）看清楚客户真正如何在用我们的产品

不要光看上线数量，一定要看商家真正在怎么使用我们的系统，他们的数据究竟正常还是不正常；我们的产品力构建得怎么样，他们怎么在用我们的产品。

在大公司经常会有人画大图，摊大饼，但是换到创业环境，这种打法就不灵了，为什么？

面向老板汇报，写 ppt，讲多大都行，但是真正面向市场，市场会无情地拿结果说话，一切包装都会打回原形，所有粗糙都会显露无疑。这是一个思维惯性要突破，但这就是真实的世界。

所以，面向创业环境，就是要敢于做减法。清楚当下聚焦什么，不做什么。

在合适的时间引入合适的产品，尤其是不要在客户完全没有接受度，或者商业条件不具备的情况下去引入不合时宜的产品。

当然，一步一个脚印，不是说对路径和方向没有思考。我们仍然需要确保对路径的思考是清晰的，方向是坚定的，只是打法和策略上面的优先级选择方式。

当明确了当前重点攻关的重点后，是否就应该做到完美了才面对真实挑战呢？

面向商业环境下的优秀的产品、技术系统和团队组织是敲打出来的，而不是象牙塔中构建的。

为什么？这就是真实世界的逻辑的复杂性、多变性和不确定性导致的。好产品，好系统，好团队，都不可能是规划设计出来的。经历敲打，同时在敲打过程中建立免疫和防御性机制，反而会更加健壮。这就是反脆弱理论的精髓，也就是如何从“不确定性”中获益的一种方式。

领域构建思维是一种典型的构建技术平台的思想，基于一个领域把平台做大，是一种单点放大的思维，把一个领域从 0 到 1，然后逐步做深，实现从单客户到多客户，从固定逻辑到配置化，再到平台化。

而价值链构建思维更加适合面向创业环境，因为构建商业的价值链，是一种串联思想，把各个技术能力进行串联，举个形象的比方，“把一颗颗散落的珍珠用项链串起来”。

面向创业环境的时候，我们需要以更快速度去构建价值链，所以我们更应该从领域构建思维到价值链构建思维。为什么？

当局限于领域构建思路的时候，很可能从领域构建所规划的技术内容，跟整体价值的匹配可能会出现问题，比如做库存域的同学肯定希望把“库存健康”这个事情做大，但是库存健康可能当下并非商家的核心诉求；这样就会导致能力和需求错位，有点类似于拿着锤子找钉子的做法。

所以不管技术上面模块如何拆解，大家都必须要围绕价值链去规划技术，体现在两个点：

可能很大一部分同学对业务项目的认知是：业务提需求，产品出 PRD，技术照着执行写方案和代码就行了。

这就是很多技术团队被业务拖在后面跑疲于奔命的重要原因，因为他的技术逻辑是没有灵魂的，很难把握到核心的逻辑抽象脉络，看起来就是一坨坨堆砌的代码！

长期在业务线摸爬滚打以后，我越来越意识到，商业背后都有着一套精密的数学模型；商业模式的变化一定对应了这套数学模型的计算逻辑或者控制变量发生了变化！这套数学模型就是就是商业逻辑的本质，抓住这套模型，就抓住了系统的核心设计模式。

我们来举一些例子：

“电商 GMV=用户规模*品类宽度*转化率*客单价*复购率”，如果提炼出这个公式，就能够知道提升电商 GMV 有哪些方法，相对应的技术建设的要点就有了。

“经营成本=采购成本+营销费用+物流费用+商品损耗”，如果提炼出这个公式，就能够知道降本提效从哪些手段发力。

不仅仅是上面这种大的公式，微观上也是一样可以用数学模型表达，比如：一个商品可售库存=实物库存+在途库存-安全保留库存-预占库存。

Get 这个核心的数学模型以后，核心建模抽象、核心逻辑设计、扩展性设计、监控对账逻辑，全部都可以运用进去，迎刃而解。

面向创业团队，技术的选择就是一种“CTO 责任制”，这里的 CTO 责任制是打引号的，我们理解并定义为：“版块负责人要独立自主对版块进行技术选择”，而非一纸强制命令。

为什么？这里面有个基本逻辑，就是版块负责人最清楚版块所面临的挑战和未来发展，同时他也是负责技术方案落地的人，所以他必须对自己的选择负责！

那么作为一个版块的 CTO，怎么样做出更好技术决策，我们的经验：

2）要快速 get 所负责版块的“know-how”

其中最重要的是两个点：这件事情核心本质和逻辑是什么，以及这件事情有哪些不能踩的坑。怎么 get 呢？我一般是先去看公司内 ATA（阿里内网技术博客）文章，公司外行业的文章，然后进一步找到懂这行的人聊，并加上自己的分析和理解，就可以逐步掌握其中的精髓。

3）时间线理论

基于当下业务成熟度，技术发展阶段去做选择。我们来举一个例子，比如用数字化的方式提升商家的零售经营效率，可能很多同学就直接联想到通过自动化的数据算法帮助商家做分析决策。但实际上我们的经验跑下来，自动化经营决策所需要的业务成熟度、信息采集量强相关，失败概率非常高！所以我们后来总结出关键的提升经营效率的生命周期：工具化（不带大脑，靠运营）-专家经验（把运营经验推广开）-规则化（基于简单规则判断）-智能化（智能决策）。这里面，每一种打法都有适合的场景！千万要注意，技术的高大上并不是选择标准，面向创业环境大家要牢记这个观点。

大部分创业的项目都会考虑跟如何基于中台来做，跟中台如何合作？中台又应该提供什么样的合作模式，一直是被反复讨论的话题，由于我自己既做过中台，又做过业务，还是有比较多的体会。

基于 CTO 责任制和中台要不要合作，如何合作，是版块负责人考虑业务诉求、能力现状，技术成本，未来的迭代和维护成本等指标进行综合决策；也就是不存一定要用或者一定不用的逻辑；也不存在一定要用某种技术合作方式的逻辑，甚至不同模块可以采用不同的决策；但是这种决策的后果也是 CTO 需要去承担的，所以往往如何决策是一个非常复杂的课题，需要经验上面的长期摸索。

基于中台的合作，一般分为五类模式，我们用表格进行说明：

具体使用哪种模式，表格中提供了选择建议。

在创业项目快速奔跑的过程中，我们是否可以牺牲架构质量？这个话题永远是一个争议不断的话题。

我们团队的经验是：技术架构的治理仍然是必须要考虑的一个因素。业务快速发展 VS 技术架构治理，不应该是 10：0，也就是绝不应该是先污染后治理！技术架构治理应该是属于长期有耐心坚持的事情，即使不占很大的比例，也不能中断，否则会带来无法挽回的后果！比如对于健壮性，对于最重要的一些逻辑和事务，在过程中就应该要有应对方案；对于扩展性，在业务需求中针对最有可能出现的扩展应该有适当预留；这样的方式可以避免系统架构腐烂到不可收拾的地步，导致重构带来巨大的工作量，反而影响了业务发展。

在系统架构治理目标上，分为健壮性、业务扩展性、支撑规模化三个层面，不同的时期治理的重点是不同的。我们团队摸索出来的一套实践分享一下。

1）健壮性

应该是首先需要进行治理的内容，因为软件的健壮性能够大幅降低出问题的成本，实际上会降低团队疲于处理问题的时间消耗，效果会很显著，所以只要有一点点余力，提升系统健壮性一定是值得投入的；健壮性的处理重点：事务与数据一致性，逻辑严密性，可监控性，系统的容灾备份等。

2）业务扩展性

或者系统的可维护性，这块是面向业务较快速度发展过程中需要应对的。在应对方式上，很重要的原则是不要把精力集中到扩展框架上面，其实解决业务扩展性最重要的是找到业务建构的核心逻辑和扩展模式，然后再选择合适的技术手段。在业务核心逻辑和范式未找准的情况下去盲目使用框架是非常危险的。解决业务扩展性有很多办法，常见的思路有：配置化（规则化）、服务化、框架与扩展点、工作流引擎、前端组件化等，可按照实际需求进行选择。

在应对软件扩展性中，两项目比较基本的武器很管用，就是大家熟知的是领域建模和设计模式，领域建模是软件模块划分的基础，将软件按职责划分为领域和模块，理清各模块边界和职责；设计模式将软件的核心逻辑按照某种风格进行组织和扩展，比如常见的模版方法，策略模式，pipeline模式，观察者模式，命令模式，都是应对软件逻辑清晰和可扩展的常见模式。

3）规模化支撑

也是架构治理的一个目标之一，常见的做法就是看性能优化，压测，做好性能应对，并提升系统的水平扩展能力，提升系统的自动化运维能力，满足系统规模化要求。

在快速奔跑过程中，架构治理要以适度为原则，不一定需要追求代码和架构绝对洁癖。软件容错性、扩张性和性能与规模应对，应该结合业务的诉求去匹配，可能有一段时间健壮性加强特别重要；业态拓展期则软件扩展性特别重要，没有固定的要求。

研发效能对创业团队来说是非常重要的，但是提升研发效率有各种高大上的手段，各种成体系的措施，我们自己摸爬滚打出来，有几个点特别关键：

创业环境下，技术文化构建依然是非常重要的一件事情，不管如何服务于商业，技术人仍然必须要找到技术人的兴趣和追求；为什么？因为创业必须要有热情，而技术文化是调动技术人热情的最原始的动力！

我们的比较有经验的体感：

1）技术 Leader 应该要是一个狂热的技术人，是一个基本原则，leader 的喜好对一个团队绝对是非常强烈的影响，要构建好的技术文化，leader 一定要亲身参与并热爱技术，维持技术理想的初心！

2）极客精神是技术人应该最应保持的技术文化，在创业过程中，我们依然可以对代码优化、系统设计、领域模型、逻辑设计精益求精。

3）从过程中去做落地，创业过程很忙，但是技术文化的构建其实不需要非常科班的流程，而是可以落实到团队的细微之处，去享受写每一段代码的时光，每一次方案脑暴和论证，每一次代码 review 的中的碰撞和探讨，这是一种发自内心的热爱；这里不论层级，应该都需要保留技术参与度。

4）把团队的技术能力成长放在非常重要的位置，关注同学的技术能力和思维模式的成长；一定不要把同学当成“资源”，他们都是一个个技术理想主义者，希望有一日成为大神！所以业务再忙，一定要有技术氛围。

5）看到最苦的技术同学们：TL 一定要鼓励对不在聚光灯下默默做技术底层活着技术优化的同学给予认可可尊重。

6）对于技术含量的挖掘要坚持！有个误区是业务创业环节所用到的技术没有技术含量！这个观点我不敢苟同，技术走到一定的阶段，你会发现一个很重要的观点：“技术是理解和构建这个世界的终极手段”。很多商业层面的问题分析诊断思路，商业逻辑构建思路，本质上就是技术能力的综合运用，包括：逻辑推理和演绎能力、数学建模能力、分析归纳能力，抽象表象看本质的能力，场景扩展运用的能力，这里面的技术含量很深！这里面技术思考力是非常重要的一个训练维度。

如今我们所处的商业时代，很难有一个赛道是没有竞争对手的。我们经常是面对内部研发，实际上没有过多考虑过竞对；但是现在必须要考虑；因为竞争对手是真实存在的。

反过来看，有对手，才不寂寞，当赛道中存在别的对手，也侧面验证我们的选择。所以从心态上需要去适应有对手一起赛跑。

面对竞对的态度，关键点：

创业，顾名思义，就是去创造一个之前不存在的事业；既有乐趣，也有风险，因为探索未知世界，最大的恐惧就是不确定性，不确定是否有一天项目回死掉，不确定项目未来究竟可以靠哪一条路走通。

面对未知的世界，正好就是团队的修炼的最佳时机，我们的经验是：谦卑、乐观、认知迭代。

1）保持谦卑

面对未知的世界，一定要谦卑，因为你可能没有搞懂真正的市场和客户诉求，闭门造车，尤其是大公司的人可能带着平台惯性，在快速迭代的商业模式里面，死亡随时可能发生。

2）保持乐观也非常重要

面对未知的世界，打破恐惧的方式来自于我们对于未来趋势的判断分析，对于愿景的追求，对于学习和变化的自我迭代，只有把握好这几个点，就是在不确定性中找到了确定性，恐惧就变成了往上成长的动力。

3）保持认知的迭代

虽然创业的愿景是不变的，但是市场形势，客户需求，团队能力和状态都是在不断变化，团队一定要保持持续的认知迭代，尤其是时时刻刻要做做反省，及时思考当下的状况并及时做出调整。比如当下我们团队的某个思考逻辑是不是应该调整一下？

面对创业环境，压力大，要求高，我们应该保持什么样的团队文化呢？建设团队各有各的方法，但我们创业团队有几个点特别重要：

1）务实

问题驱动，直击命脉，少绕弯，少包装，因为创业环境是面向真枪实弹的竞争和挑战，不容许有假大空，必须要踏踏实实回归业务问题，客户诉求和技术能力！

2）自主

我比较推崇“人人都是 CTO ”的思想，采取 CTO 责任制，自己对自己的板块负责；让每个人都把自己所负责的事情理解成一次创业，能够成为事情推进的发动机；这个点很重要，因为需要把团队成员的积极性充分调动起来。

3）透明

确保每个人可以大胆沟通，直面问题，管理扁平化，Leader看见一线的细节，一线看见团队的远景，上下同欲。

4）公正

这个道理很简单，能者多劳，多劳多得，让最努力的同学获得最大的回报。

5）开心

创业绝不等于单向的工作压力增加，996 甚至 007，其实并不是这样的，团队一定要注意劳逸结合，找到能够放松团队，开心团队的方法，大伙心态是开心的，才会更加高效地做事情。

技术团队在发展中会遇到很多问题，包括作战能力、兴奋感、成长性等各个方面，这是因为我们处于VUCA时代并面对更加复杂的管理挑战。我们选择了用创业团队的打法来尝试解决这个问题，初步取得了一些效果和经验。比较重要的经验是：

同时践行这套理论，一个很大的感慨：创业文化的探索，就是和一群志同道合的伙伴去不断探索未知世界，并实现个人与集体成长的过程。所以也非常渴望和志同道合的同学一起探讨交流！