「技术人生」第8篇：如何画业务大图

作者：贺科学（晨末）

几个看似不相干的故事

今天的话题，以几个遇到的人和事作为开始吧。

第一个故事，是关于去年社招遇到的一个非常可惜的候选人。工作 3 年，技术能力扎实，在一家小公司负责一个业务的核心系统，因为感觉日常工作没办法让自己成长，所以来阿里试试。整个面试过程只能用非常可惜来形容，因为他的技术方面都算过关，可是问到他自己过去做的业务时，给出的回复却差强人意，没办法从宏观视角上给出公司业务的整体形态，也没讲清楚自己负责的业务和其他业务模块之间是如何协作的——涉及到自己模块的问题时，有的是时间太久记不清了，而实际情况是简历上面相关内容仅仅是一年前的工作内容；有的则是陷入细节中无法自拔，再三提示下，都不能讲清楚整个业务的形态是什么样的；而对于那些别人做的模块，基本都是“那些是别人负责的，我不太清楚”一句话了事，核心业务流程都不了解。

想必大家也能从旁观者的视角看到为什么我会觉得这个候选人可惜：因为整个面试他的技术能力没问题，而最终倒在了最基础的业务能力考察上。我知道他在过去的三年里面付出了很多，积累了非常不错的技术能力，但是在业务方面却只是在被动地接需求，做了就忘，上线即再见，长久如此一步一步积累了技术，却也在这样的惯性下形成了自己成长的瓶颈。业务能力究竟是什么，为什么那些过去看起来影响写代码的事情到关键时候却成了成也萧何败萧何的关键因素？

第二个故事，是以前团队的同事的事情。最近和他聊起今年的工作规划，他满肚苦水，闷闷不乐：一方面自己今年已经工作五年了，处于晋升的关键时期，负责着不大不小的业务模块，今年有没有机会就看能不能在业务上做出过硬的成绩了，而另外一方面他的 leader 对他负责的内容没有太多的“指示”，只是让他在用户体验方向寻找一下突破点。

对于一个研发人员而言，在他职业生涯的这个阶段遇到这样的命题，简直是组成了天然的焦虑放大器：拿到晋升机会需要确定的成果，而今年的命题却看似不在他的能力范围内，与其能力模型不匹配，其中存在着巨大的不确定性。对他而言，明确的终点和不确定的路径，这一幕看起来仿佛是黎明前最黑暗的时刻。今年的规划怎么做，才能让自己在“逆风局”里步步为营，从而勇往直前？

第三个故事，发生在晋升场上。曾经带过的一个师弟去年晋升面试结束后非常焦虑，找我聊起他的面试过程：“前面讲的还好，感觉整个过程都不错，只是最后回答未来的规划时，没讲好。在后面评委点评环节，在场的几位大佬也提到了需要加强对业务未来规划方面的思考”。当时晋升面试还没出结果，因此只能安慰他先不要把太多的精力放在结果上，而要抓住机会梳理清楚评委的建议，做针对性的思考和加强。

处于好奇，我也问了他对未来要做的事情有什么看法没有，发现沟通过程中言语间体现的都是在跟着产品经理的功能规划往前走，缺少了他自己作为这件事情的技术责任人在技术视角下的规划和思考。我对他做了一些安慰，却也无法彻底消除他当时的焦虑的情绪。好在最后结果是晋升通过皆大欢喜，但是我们都知道他还要继续加油，努力向着面试评委们给出的建议提升自己，因为若干年后的下一次晋升，这次的建议会是未来那个场景下最基本的要求，而这个要求如果达不到，那么就可能变成整个职业生涯的天花板——是的，一个群体的天花板可能是另外一个群体的“基操”，两个群体的能力鸿沟要比想象中离我们更近。

想要在未来能够独当一面？做技术的同学只接业务需求是不够的，还要能预判业务的发展方向，能够依靠技术侧的长期投入来驱动业务朝着更好的方向发展，这个道理大家都懂，可是“纸上得来终觉浅，绝知此事要躬行”，究竟如何做才能迈过“晋升”成功后的第一道坎？

第四个故事发生在我们身边，也可能就发生在你我身上。每年新财年一到，公司内网或者朋友圈总能看到几个这样“有趣”的新年规划：“今年的目标就是做完去年没做完的那些前年规划的事情”。一年一年又一年，似乎做了很多事情，但是回头望去却又似乎什么都没做。从开始规划的雄心勃勃，到每年年底总结时的怅然若失，再到新年规划时的茫然，业务似乎没有朝着期望的方向发展，365 天留下的仅仅是一次次需求一次次迭代和一次次地凌晨通宵发布。

一线业务研发同学仿佛是蒙着双眼在迷宫中行走的困兽，想要有所突破却找不到方向。甚至很多带了团队的同学、很多职场打拼多年的技术骨干也会觉得业务做的多了没有挑战，日子永远在“挖下新的坑，填上旧的坑”之间来回打转，挖坑填坑游刃有余但内心毫无波澜，就仿佛是一只被二维次元壁垒困在莫比乌斯环上只能不断向前爬的蚂蚁一样，“未来”是一个看不见尽头也无法跳出的死循环，激情和理想在这个循环里面被磨得失去了原本的模样。

作为资深业务开发人员，如何才能打破这个困境？作为带领团队向前奔赴的技术管理者，又如何带着业务研发团队跳出过去的陷阱开辟出新的成长空间？

问题是什么，根源在哪里？

看起来似乎非常巧，今天讲的这几个故事的主人公都处在各自职业生涯的关键点，想跳槽大厂的年轻程序员、处在晋升准备阶段的核心技术骨干、已经晋升成功却对接下来要怎么做一脸茫然的技术人、已经带了团队每年都要带领下属进行年度规划的职场老鸟，不同的职业生涯阶段、不同的场景下，大家看似遇到了不一样的问题，但是从更高的层面来看，这些不一样的问题的根源却是同一个。

处于 1-3 年的业务开发同学，拼命积累技术能力，却不知道自己每天做的业务需求实际上需要另外一套能力体系来支持，而这套能力体系可以通过每天做的那些“影响我写代码的事情”来有意识地进行培养。

业务能力就是分析业务本质，理解业务问题的能力。分析当前的需求是什么场景下的，会有哪些参与方、分析各个参与方之间的协作方式、分析每个不同的角色在这个场景下会遇到什么问题，需要技术系统怎么做来帮助他们解决这些问题。通过个人的思考分析也好，和产品经理甚至是客户直接沟通讨论也罢，这些问题都是可以比较轻松地得出相应的答案的。随着实践层面的经验不断的积累，就需要从宏观视角回顾一下自己过去做的那些事情，有什么样的关联，怎样服务了客户，客户为什么需要这些功能，能为他们带来什么样的价值（翻译过来就是解决了客户什么问题）。这是业务开发必须要掌握的最基本的业务能力。

那些处在晋升准备期的研发骨干，技术能力毋庸置疑，而欠缺的则是独立负责业务的能力。自己做的事情全貌是什么样的，目前业务发展到了什么阶段，在这个阶段的业务瓶颈是什么，找到瓶颈的根源之后，如何在技术侧发力促成问题的解决，在问题解决之后如何配合业务上下游的同事例如客户经理或者运营同学，把产品功能的价值最大化，是更高阶的业务能力的要求。这个过程如果不自己经历一遍，是无法在技术团队做一个合格的业务领域的 owner 的。日常工作中做不到的事情，在晋升场上也是无法通过考验的。

对于那些已经晋升到下一个层级的研发骨干，在独立负责业务领域或链路的基础上，解决业务遇到的问题已经算是基础能力了，那么接下来更重要的就是看业务发展趋势的能力。解决遇到的各种业务问题，是面向过去和面向当下的工作方式，而基于业务发展趋势来做技术侧的布局和长期投入，则是面向未来的工作方式。系统架构演进、重点技术领域的长期、持续、坚持投入都是基于未来业务发展趋势的判断来做出决策的，而不是脱离业务空对空做设计做演进的。

对于带团队做业务开发的团队管理人员而言，一方面要求能够在宏观上看到业务发展趋势从而进行有效的技术侧布局，在微观上看到当前业务阶段存在的问题从而给出合理的解决方案，另外还需要具备拆解复杂问题的能力，将遇到的问题进行多维度的拆解，理清业务涉及到的各方（客户、产品、技术、业务、组织等）各自的核心命题，有机地将多方的诉求结合起来，根据业务发展前景和期望综合定制合理的目标，并且带领团队做好执行实现目标。与其他故事里面提到的研发人员相比，带领团队做业务开发的主管们在宏观上面对的问题是多维的，在执行上也不再是单人执行落地的模式，而是协调统筹多个方向多个业务领域的责任人进行协同执行，发挥出团队的战斗力。

看似不同的人在不同职业生涯阶段遇到的这些问题，实际上是缺乏对应业务能力的情况下遇到的困境。

该怎么办呢？

学校里没有相应的课程来帮助业务开发人员完成最初的基础知识的积累，步入社会以后也没有一本现成的书告诉业务研发人员怎么构建自己的业务能力，这样看来，做业务似乎是一门实践的学科，只能从业务中来到业务中去。可是一旦提到实践，读过毛主席的《实践论》的读者就知道实践的经验经过思考、分析、总结就能形成一定的理论，理论再去指引实践就能少走弯路提高实践的效率，当然被实践所评判、修正的理论也会更全面、更完善。因此提升业务能力最好的方式是可以先从实践出发，同时尝试寻找合适的理论来指引自己的实践，避免缺乏理论指引的情况下实践效率和效果都不好的情况出现。

可是业务实践究竟是怎么锻炼业务能力呢？到底从哪去获取构建业务能力的理论呢？如果读者朋友现在仍然存在类似的困扰，先别急，可以先从我接下来讲的一件事情中找到提升业务能力的契机和办法。

我也曾经面对过同样的问题

2017 年的阿里云开启了创新业务的大潮，高峰期有几十个创新产品在并行推进，我有幸参并负责了其中的两个创新业务的技术工作，一个是电商相关，一个是金融相关。电商 BPaaS（业务平台即服务）产品上线后，我随即负责金融相关的产品的建设，金融 BPaaS 产品半年后上线，然后开始统管两个业务的技术工作。这个时候发现经过大半年的发展，电商 BPaaS 产品的发展和演进已经让当时的产品团队、业务运营团队、研发团队都进入了一片混乱的状态：

• 业务方面：

• • 业务有了第一个大客户，用户体量不错，业务规模比想象中更好，向上汇报也取得了公司层面的认可，团队和业务基本上明确了可以存活下来。【技术侧需要进行长期规划了】

  • 接下来就进入了寻找突破方向的阶段，需要多方向、多业务模式的试错。【研发需求量大增】

  • 业务本身非常复杂、业务领域非常多，从最开始业务上线我去做金融产品时的2个Java应用，到我回来两个产品统筹管理时，已经发展到了整个系统有7个Java应用，对应着商品、订单、交易、支付、结算、管控、开放平台等几个核心域和合同、流程、配管等支撑域，还有若干个业务无关的技术底层系统。【业务复杂度急剧上升】

• 技术方面

• • 系统架构有问题，调用依赖关系混乱，存在性能瓶颈，无法支撑更大规模的用户交易。【技术侧逐步形成瓶颈】

  • 技术系统数量增多，复杂度上升，由小型系统演变为大型分布式系统。【研发在技术侧的核心技术命题发生了变化】

  • 稳定性、研发效能、运营效能需要投入技术人员做支持，但是没有人做这些横向的事情。【业务的发展催生的技术体系的变化出现了真空地带，研发侧尚无感知和应对，所有精力都集中在业务需求的开发上】

• 团队方面

• • 上游团队是产品团队，没有行业经验，也没有应对复杂业务系统的能力和经验，但是商业能力极强。【商务侧和客户侧有极大优势，有非常好的商业模式上的顶层设计；产品功能和平台能力建设上摸索前进，产品形态和业务能力上的顶层设计有缺陷】

  • 下游团队是运营&客服团队，有电商行业运营和服务经验，但是成员大多数是外包同学，在产品发展趋势和功能规划方面没有话语权但是日常工作深受影响。【产品设计上的协同和反向促进作用降低，长期下去会造成产品能力和客户需求脱节】

  • 研发团队人员分工混乱，每个人负责几个应用，但是有的人负责的应用之间关联性不强，需求需要多人在同一个领域内做协作。【复杂的系统导致了分工不清晰，从而带来了协同上的困难，研发效能变成问题】

  • 研发团队成员是正式员工+外包员工，工作结果在质量和产量方面都存在无法对齐的情况。【组织协作模式需要重新设计】

这些看似条理清晰的内容在当时都是混杂交织在一起的，所有人都在忙碌中承受着巨大的压力，直接体现出的现象就是产品经理想要做功能，但是不知道该找哪个研发同学沟通需求；客户反馈问题了，也不知道应该把问题转给哪个研发同学进行解决。而研发同学这边已经开启了一边业务开发一边救火的模式，业务需求的排期压力叠加了客户反馈的问题形成的压力，造成团队日常工作氛围异常诡异，一边是异常忙碌，一边是无人交流沟通导致工位上死气沉沉，最可怕的是，为了能够尽快完成业务需求，已经长期加班团队在超负荷运转的状态下依然频频无法按期交付（别问为什么，问就是需求时间倒排），也就是说，研发团队已经无法通过自身的调整适应和努力来改变现状了。

我分别找了每个研发同学沟通之后，发现大家疲于应对业务需求和线上问题，每个人只了解自己做的部分的事情，除此之外，既不知道自己负责的部分接下来要做什么，也不知道业务整体上的情况是怎么样的，更不知道自己负责的内容该如何配合其他人开展工作，也自然就不知道在技术上需要做哪些投入来支持业务发展。

所有人的所有行动都是被产品经理的需求串起来驱动的，而产品经理的需求一部分从“可能赚钱”的方向而来，这些“可能赚钱的方向”本质是不断地试错；产品经理的需求另外一部分从“客户反馈的问题”而来，这些问题来源于线上的 BUG，也来源于功能设计的不合理、不完善，而这部分问题也在反复地用客户第一的价值观在精神层面炙烤着每个团队成员。没错，在生理压力和心理压力的叠加下，每个人的焦虑都溢于言表。

摸清整体情况以后，经过分析当前业务、团队、技术的基本面之后，所有的问题都指向了一个根源：没有业务大图，参与业务的几个团队没有共享视角，各自的行为都是受业务自然发展而运转起来的，而不是经过有目的的设计的，也就是说变成了业务推着人跑，而不是人领着业务跑。这个局面长期下去是非常危险的。

我相信有的读者会特别好奇，技术方面架构有问题和没有业务大图有关吗？有关，产品经理提需求的时候没有义务也一定不会帮助研发人员想清楚现在的技术架构怎么做、未来的技术架构如何演进；而技术人员又不知道自己做的这个需求是哪个业务领域的，要解决什么问题，只能从现有的应用里面找解法，再加上偏颇的代码复用理念和蹩脚的代码复用实践，导致调用关系混乱、业务逻辑杂糅，实在觉得很多逻辑不应该放在这个应用里面的时候，就被动地赶一下微服务的潮流把应用拆分开变成两个Java应用……架构没有设计，没有演进，只有在业务需求推动下的应激（受到外界刺激的情况下仓皇应对）。

也有的读者会好奇，团队职能、成员组织架构、协作模式、工作分工出现问题，和业务大图有关吗？有关，以研发团队为例：在当时没有业务大图的情况下，在内部，人员分工没有规则和依据，每个人负责多个事情，内部协同成本高，责任边界不清晰，而且所有工作都以业务需求开发为主，这样的研发人员所组成的团队整体上只是一个职能单一的业务需求开发型团队，无法完成综合性的业务支撑挑战；在外部，与上下游协作沟通存在工作语言的差异，而这个语言上的差异实际上是各方对业务模型理解上的差异。

技术人员说的业务概念和产品经理、运营人员的业务概念对不齐，开会各说各话信息传递损耗严重，经常需要临时对齐内容，但是会后又各说各话，从领域驱动设计的视角来看各方描述业务模型和核心流程时充斥着各种蹩脚的比喻和类比，很难见到合理的各方一致认可的抽象模型。并且由于研发团队职能单一，没有有效应对非业务需求之外的事情，导致上下游协作方对研发团队颇有微词，比如运营同学开展商品运营过程中遇到影响效率的问题，也觉得应该是研发团队提供系统或者工具来支撑，在客服同学服务客户的时候遇到影响效率的问题，也觉得是研发同学支撑不够。因此，在研发团队缺少业务大图的情况下，没有全局视角的情况下，根本不知道除了做功能迭代以外还要肩负起运营效能、客户技术服务等等的重要职责。

所以在找到了所有问题的症结之后，就像是找到了一团乱麻的线头一样，先把它拎出来，把它解决掉，然后所有其他的问题开始围绕这个症结点做梳理、调整、治理。以下内容就是当时画业务大图的整体过程，觉得有用的读者可以把这部分内容作为描绘自己业务大图的一个操作步骤来做实践。

明确组织使命和愿景

开始画业务大图的时候，先确定业务大图的顶层内容，讲清楚是什么团队在做什么事情，对于这个团队而言做这个事情的使命是什么，大家聚在一起形成这个团队，期望在未来的几年之内把这个事情做到什么程度，而聚在一起做这件事情的不同角色的参与者，应该如何相互看待彼此，如何相互支持彼此开展工作。所以，业务的团队主体、使命、愿景、价值观就是整个业务大图的最顶层的框架，如下所示：

图 1 业务大图的顶层内容

使命是组织存在的前提，也是组织做的这个业务的起因。愿景是在组织的使命下，在一定时间尺度下的一个宏观的目标。关于使命、愿景不再做深入解释了，关心为什么画业务大图需要首先明确使命、愿景，可以看下整个系列文章的《技术一号位的方法论【理论篇】——解决问题的规律总结及技术、业务、组织规律的探讨与应对策略分析》一文中提到的关于组织的规律相关内容。

愿景的多维度拆解

明确了组织的使命愿景之后，在构建业务大图时，我们需要从“愿景”这个宏观的目标着手，进行多维度的拆解，讲清楚需要把哪几件事情做好，才能达成这个宏观的目标。如下图所示：

图 2 支撑愿景达成的多维度的拆解

多维度拆解愿景是构建多条业务线的理论基础。以我们都熟知的阿里的使命愿景为例，想要在数字时代，让天下没有难做的生意，必然要围绕着“做生意”的各个主要维度进行投入，以支撑愿景的实现：从最经典的 “人-货-场”再到线上支付、物流、仓储、履约、售后，再到各种生意的细分市场，再到文娱、本地生活等不同业务线（实际上目前已经从业务线发展成为事业群甚至是不同的公司了）的配合，我们可以从这个例子里面看到针对愿景的多维度的拆解过程。目前公司这些业务板块是否是最开始就从顶层设计好的？不一定，有些可能是在业务开展过程中发现我们需要投入人力精力去做的，但是也有些肯定是从最开始就设计好一定要做的，比如线上支付服务。

业务的顶层设计

在团队愿景完成多维度拆解之后，随之要给出的，就是第二层的内容，这一层内容，主要是承接愿景的拆解，是战略层面的业务的顶层设计。针对要做的业务分别从 “客户价值”维度、“组织价值”维度、“社会价值”维度（可选）、“个人价值”（可选）维度来拆分，分别讲清楚做这个业务对于客户能产生什么样的价值，这个价值用指标衡量是什么样的；从组织的视角来看，做这个业务对部门或公司有什么价值，这个价值用指标来衡量是什么样的；如果做的业务是面向 C 端普通用户的，并且经过预判可以明确产品会对一定规模的用户产生影响，那么还需要讲清楚做这个业务对社会创造了什么价值，这个价值用指标来衡量是什么样的。

分别讲清楚业务的客户价值、组织价值、社会价值及相关的衡量方式，即完成了业务在战略层面的顶层设计，可以拿来与团队进行对焦沟通了。具体如下图所示：

图 3 业务大图中的业务顶层设计

细心的读者可能会发现，上面大图里面“个人价值”这条价值线是用虚线来表示的。这里需要着重讲一下的就是，个人价值是一个对外隐形的维度，一般情况下可以不对外公开对焦，只用于对于个人职业生涯规划的指引，方便我们把自己个人的成长和业务的发展结合起来。

但是作为团队 leader 或者业务、技术一号位，可以尝试把个人价值向核心团队成员公开，让团队成员看到管理者、一号位如何把个人利益和业务利益有机得结合在一起的。做得更好的管理者可以鼓励团队核心人员也结合业务战略构建自己在做业务时的个人价值线，彼此可以看到各自在意的方向和点是什么，基于员工提供的个人价值线进行团队成员培养，以此为契机把做业务和带团队结合起来。

这一点一定要重视，因为组织的战略执行离不开个人，个人的核心利益诉求也会影响个人的决策偏好和行为，从而会反向影响业务战略的落地，这个是组织规律，这个规律也在《技术一号位的方法论【理论篇】——解决问题的规律总结及技术、业务、组织规律的探讨与应对策略分析》一文中关于组织内的员工模型相关内容有详细论述，本文就不再展开讨论了。

总之，个人价值如何与业务价值的辩证关系是需要正视并加以引导的，因此有一定信任基础的团队可以尝试这样的实践。

业务的规划与执行设计

在完成业务大图的顶层设计之后，接下来要做的就是进行执行层面的规划了，我们可以按照“终局——中期——近期”这样的时间尺度来拆解各条价值线的目标，并且丰富目标支撑内容，从而形成团队在近期要做什么，目标是什么；中期需要做什么，要达到怎样的目标；终局是什么样的，如何基于中期的执行结果进行持续投入，最终达到怎样的目标才算完成了业务终局的构建。针对每条价值线都需要有这样的规划。如下图所示：

图 4 简易版业务大图

到此为止我们就完成了一个简易的业务大图。这个大图完成之后，就可以和整个团队进行对焦，让大家看到我们做的业务的全貌是什么样的，大的业务拆解成几个子业务，而几个子业务是如何配合的（由顶层指标驱动的），并且能够看到整个团队在近期要做什么，中期要做什么，终局是什么样的。另外一点需要说明的是，简易版的业务大图没有画出技术、组织和业务各个阶段的对应关系，如果想要画出完整的业务大图，需要把组织、技术相关的内容与业务对齐。

业务大图与技术大图融合对齐

在 2019 年完成业务大图的对焦之后，我紧接着基于业务大图构建了技术大图，技术整体上划分为“支撑业务发展”，“保障业务发展”和“驱动业务发展”三条主线，让技术主线和业务主线进行了全维度、全周期、全阶段的对齐，过去杂乱无章的技术工作按照业务领域重新划分，基于领域划分完成了团队成员职责分工，每个业务领域基于业务上的客户价值主线和业务价值主线以及技术上的三条主线开展日常工作，哪些是近期要做的，业务未来会做成什么样，技术侧需要进行怎样的规划和长期投入都非常清晰。

在完成技术大图的构建之后，整个团队之前面临的很多揉成一团乱麻的问题都迎刃而解，团队成员看到了变化，士气也逐步回升。然后又根据技术大图和业务大图构建了新财年的战役规划，并行针对战役需要的支撑做了内部组织调整，彻底理顺了团队内部阵型，填补了横向职能的空缺，过去没有人负责的稳定性建设、研发效能、运营效能、客户技术服务几个大的板块也进入了专人专责持续投入建设的阶段。从上下游团队和客户的反馈来看，研发团队的这一改变切实地解决了他们工作中遇到的很多实际的问题，整个业务协同和客户关系都发生了积极的变化。这也标志着我带领的研发团队从过去的单一职能的业务研发团队转变为支撑全业务生命周期数字化需求的综合技术团队，团队内部职责和空间都扩大了，留给了每个员工足够的成长空间。

关于业务大图和技术大图的融合展现，可以参考下图内容：

图 5 业务大图和技术大图融合对焦

关于基于业务大图的战役规划，可以参考下图内容：

图 6 业务大图中的业务战役

我的故事就这样讲完了，我相信处于不同职业生涯的读者看到这个例子都能多多少少有所收获：处于职业生涯早起的业务研发同学，可以通过尝试构建自己做的业务大图，形成对业务整体形态的认知；要晋升的读者，能够依靠构建业务大图的这个尝试，补全做事情的重要的维度，并且从不同的维度找到业务的突破点；已经带团队的读者可以依靠业务大图完成业务顶层设计，能够与自己的团队成员对齐，并且利用好业务大图把各种问题梳理清晰，做好调整，利用业务战役实现业务目标，打出团队成员的士气，让他们在开展业务的过程中获得成长、让他们通过业务结果和技术成果获得成就感。

业务大图是谁都“有资格”画的吗？

有的读者可能会看着如何画业务大图的方法和步骤大皱眉头，看着里面满眼的“战略”、“顶层设计”、“一号位”已经开始出现不愉快的情绪了，内心不禁想要质问作者：你是什么水平？带几个人？就张口战略闭口顶层设计？当然也可能会有读者怀疑自己：我一个写代码做需求的，画这个图有点大逆不道吧，这得是我老板的老板的老板才能做的事情吧？如果读者朋友有以上情绪，我觉得我们可以深入聊一聊，业务大图是谁都有资格画的东西吗？讨论之前先亮出我的态度，我觉得“王侯将相宁有种乎”，谁都有资格画，不仅有资格画，还要多画、常画，只有一个要求，必须越画越好，越画越贴合实际实事求是，除此之外百无禁忌。相信我的观点一出，可能有人已经想要拿着“别谈战略”的尚方宝剑开杠了。

众所周知，网上有一些真假难辨的传闻，据说有人刚入职某顶级大厂就发邮件教总裁做事，战略打法头头是道，顶层设计信手拈来，当然后面就直接“被毕业”了。所以我们这些一线干活的人、一线带团队的人，说话办事一定要离“战略”远一点，避免被人质疑是否有资格，是这样吗？我觉得我们这些做执行的“信息时代的农民工”，除了做好执行的本职工作以外，一定要开始尝试画自己所负责的业务的业务大图，注意，是画自己负责的业务的大图，而不是画总裁的业务大图。如果担心被人质疑资格而不去做的话，那么你现在负责的事情有谁帮你画好了业务大图吗（任意形式都可以）？如果没有人帮你画业务大图，你的主管跟你同步新年规划也仅仅是几句话带过的话，那么请问你这一年的工作要如何高质量、有计划地完成呢？如果已经有人帮你画好了业务大图，那么你负责的事情在对方的业务大图里面占比是怎么样的呢？涉及到你负责的事情的重点了么？未来会发展成什么样提到了么？如果都没有提到或者关键信息有缺失的话，那么缺失的这部分是不是还需要你的主管帮你补充好呢？相信这些问题在大家心里都有合适的答案。

对于研发团队和研发人员自身而言，业务大图是业务战略、目标、执行策略、关键战役的综合信息载体，即使不画业务大图，这些内容也应该是一个管理者，一个独立负责某个业务领域或业务链路的同学必须了解的。如果日常工作中没有目标，不清楚目标实现的策略，整体业务发展趋势和各方期望也都不知道，那么员工是无法高质量地完成工作的，只能被业务需求驱动，而不是被业务驱动。同时更重要的是，对于执行者而言，不论是处于职业生涯的什么周期，不论带不带团队，画业务大图是打破自己能力壁垒、突破层级束缚，从单一维度做事升级到多维度、高层次做事的最好的方式和契机，它是打开你职业生涯更广阔空间的一扇大门。用一个比喻来形容业务大图的重要性的话，我们可以把一线做业务需求的研发人员比作我在文章开头的第四个故事中提到的那只在莫比乌斯环上不断爬行的蚂蚁，而业务大图就是从高纬度空间伸入低维度莫比乌斯环的一架梯子，一架可以帮助那只蚂蚁突破维度壁垒的梯子，可以让蚂蚁沿着这个梯子，从无尽的二维空间进入三维空间，从而从更高维度的视角审视自己过去的环境、行为、认知。画业务大图的过程，让业务研发人员不得不具备更高层次的视角（俗称站在老板的角度看问题），为了把业务大图画出来而不得不去思考、解决顶层设计者们每天日常工作中会遇到的一部分问题。换言之，这实质上是利用画业务大图的过程，模拟、创造了顶层设计者工作环境，主动进行了顶层设计者一部分日常工作的实践。

实践有了，思考也会有，思考有了，认知也会逐步形成，认知形成了，行为就自然会改变，会转变层下一个层次的工作模式，这就是业务研发人员从实践到认知再到实践的成长过程。所以再回头来看，业务大图要画吗？业务大图能画吗？为什么放着通往下一个层次（注意不是层级）的大路不走呢？这么显而易见的问题就不需要再回答了吧。

除了对研发人员或团队自身的一些好处之外，在业务开展过程中对外协作方面，在进行上下协同时，业务大图是多方对焦，下级理解上级业务战略部署的最好的工具，能够防止业务在落地过程中研发团队只做机械地执行，也能防止执行方向跑偏，资源投入不当，也能防止整个业务团队研发团队在业务开展过程中出现短期主义，没有长期价值的坚持，这些意义的重要性与战略设计的正确性同样重要。因此画了业务大图，可以向自己的上级主管多多请教对焦，争取让自己的大图和上级的大图在各个层面都是匹配的，不论是在战略层面还是执行层面，都是形成了一致的认知，那么接下来就是放手去做执行了。

业务大图在组织上的好处就不再深入展开了，大家也能从我举的自己的示例里面看到效果。

所以，业务研发同学要多画业务大图，多谈谈自己负责的事情的战略，多设计设计自己半年或者一年尺度上的工作计划，多在执行过程中自我纠偏，多在执行过程中和上级对焦，针对上级简略的任务布置能有成体系、完善的、不遗漏重点不需要领导补位的执行计划和坚实的落地过程，请问这样的业务研发人员或者一线主管，有谁不爱呢？

当然如果空谈战略而没有拆解和执行，那是“嘴炮党”，不是“业务大图党”，不是一回事儿，不展开讨论了。

业务大图不是银弹，通往下一个层次的路上荆棘满地

学会了画业务大图，找到了通往下一个层次的路，只是解决复杂业务问题的起点，而不是复杂问题的终点。图要一笔一笔画，路要一步一步走，纸上谈兵招人恨，实践之中出真知。有了业务大图不是万事大吉了，更多的是通过业务大图来构建个人对复杂业务的分析能力，来提升决策的正确性，是采用科学的工作方法走出的第一步，也是打开未知之门迈出的第一步。所以在学会画业务大图以后，还要多思考、勤实践，真正开始以一个清醒的状态面对自己的职业生涯。

不论你是刚入职场的新人，还是你已经处在自己职业生涯的关键期，还是你已经带着团队摸爬滚打做事，请紧紧抓住业务大图这张船票，做好迎接更加艰巨的挑战的准备，因为通往下一个层次的路上惊涛不减，荆棘满地。

最后需要提示读者朋友们的一点是，后续大家在画业务大图的时候会遇到一个非常非常关键的问题，那就是业务大图中的战略目标如何确定，在不同时间尺度上的业务指标如何确定。这部分内容，我会在下篇文章中给出详细的说明，让大家区分清楚目标和指标，让大家知道指标的本质是什么，从而帮助大家能够针对自己负责的业务构建起来一整套完整的指标体系，请大家关注下一篇文章《「技术人生」第9篇：什么是指标，如何定制业务指标》。