作者 |   賀科學（晨末）

一、幾個看似不相干的故事

今天的話題，以幾個遇到的人和事作為開始吧。

第一個故事，是關于去年社招遇到的一個非?？上У暮蜻x人。工作 3 年，技術能力扎實，在一家小公司負責一個業務的核心系統，因為感覺日常工作沒辦法讓自己成長，所以來阿里試試。整個面試過程只能用非?？上硇稳荩驗樗募夹g方面都算過關，可是問到他自己過去做的業務時，給出的回復卻差強人意，沒辦法從宏觀視角上給出公司業務的整體形態，也沒講清楚自己負責的業務和其他業務模塊之間是如何協作的——涉及到自己模塊的問題時，有的是時間太久記不清了，而實際情況是簡歷上面相關內容僅僅是一年前的工作內容；有的則是陷入細節中無法自拔，再三提示下，都不能講清楚整個業務的形態是什么樣的；而對于那些別人做的模塊，基本都是“那些是別人負責的，我不太清楚”一句話了事，核心業務流程都不了解。

想必大家也能從旁觀者的視角看到為什么我會覺得這個候選人可惜：因為整個面試他的技術能力沒問題，而最終倒在了最基礎的業務能力考察上。我知道他在過去的三年里面付出了很多，積累了非常不錯的技術能力，但是在業務方面卻只是在被動地接需求，做了就忘，上線即再見，長久如此一步一步積累了技術，卻也在這樣的慣性下形成了自己成長的瓶頸。業務能力究竟是什么，為什么那些過去看起來影響寫代碼的事情到關鍵時候卻成了成也蕭何敗蕭何的關鍵因素？

第二個故事，是以前團隊的同事的事情。最近和他聊起今年的工作規劃，他滿肚苦水，悶悶不樂：一方面自己今年已經工作五年了，處于晉升的關鍵時期，負責著不大不小的業務模塊，今年有沒有機會就看能不能在業務上做出過硬的成績了，而另外一方面他的 leader 對他負責的內容沒有太多的“指示”，只是讓他在用戶體驗方向尋找一下突破點。

對于一個研發人員而言，在他職業生涯的這個階段遇到這樣的命題，簡直是組成了天然的焦慮放大器：拿到晉升機會需要確定的成果，而今年的命題卻看似不在他的能力范圍內，與其能力模型不匹配，其中存在著巨大的不確定性。對他而言，明確的終點和不確定的路徑，這一幕看起來仿佛是黎明前最黑暗的時刻。今年的規劃怎么做，才能讓自己在“逆風局”里步步為營，從而勇往直前？

第三個故事，發生在晉升場上。曾經帶過的一個師弟去年晉升面試結束后非常焦慮，找我聊起他的面試過程：“前面講的還好，感覺整個過程都不錯，只是最后回答未來的規劃時，沒講好。在后面評委點評環節，在場的幾位大佬也提到了需要加強對業務未來規劃方面的思考”。當時晉升面試還沒出結果，因此只能安慰他先不要把太多的精力放在結果上，而要抓住機會梳理清楚評委的建議，做針對性的思考和加強。

處于好奇，我也問了他對未來要做的事情有什么看法沒有，發現溝通過程中言語間體現的都是在跟著產品經理的功能規劃往前走，缺少了他自己作為這件事情的技術責任人在技術視角下的規劃和思考。我對他做了一些安慰，卻也無法徹底消除他當時的焦慮的情緒。好在最后結果是晉升通過皆大歡喜，但是我們都知道他還要繼續加油，努力向著面試評委們給出的建議提升自己，因為若干年后的下一次晉升，這次的建議會是未來那個場景下最基本的要求，而這個要求如果達不到，那么就可能變成整個職業生涯的天花板——是的，一個群體的天花板可能是另外一個群體的“基操”，兩個群體的能力鴻溝要比想象中離我們更近。

想要在未來能夠獨當一面？做技術的同學只接業務需求是不夠的，還要能預判業務的發展方向，能夠依靠技術側的長期投入來驅動業務朝著更好的方向發展，這個道理大家都懂，可是“紙上得來終覺淺，絕知此事要躬行”，究竟如何做才能邁過“晉升”成功后的第一道坎？

第四個故事發生在我們身邊，也可能就發生在你我身上。每年新財年一到，公司內網或者朋友圈總能看到幾個這樣“有趣”的新年規劃：“今年的目標就是做完去年沒做完的那些前年規劃的事情”。一年一年又一年，似乎做了很多事情，但是回頭望去卻又似乎什么都沒做。從開始規劃的雄心勃勃，到每年年底總結時的悵然若失，再到新年規劃時的茫然，業務似乎沒有朝著期望的方向發展，365 天留下的僅僅是一次次需求一次次迭代和一次次地凌晨通宵發布。

一線業務研發同學仿佛是蒙著雙眼在迷宮中行走的困獸，想要有所突破卻找不到方向。甚至很多帶了團隊的同學、很多職場打拼多年的技術骨干也會覺得業務做的多了沒有挑戰，日子永遠在“挖下新的坑，填上舊的坑”之間來回打轉，挖坑填坑游刃有余但內心毫無波瀾，就仿佛是一只被二維次元壁壘困在莫比烏斯環上只能不斷向前爬的螞蟻一樣，“未來”是一個看不見盡頭也無法跳出的死循環，激情和理想在這個循環里面被磨得失去了原本的模樣。

作為資深業務開發人員，如何才能打破這個困境？作為帶領團隊向前奔赴的技術管理者，又如何帶著業務研發團隊跳出過去的陷阱開辟出新的成長空間？

二、問題是什么，根源在哪里？

看起來似乎非常巧，今天講的這幾個故事的主人公都處在各自職業生涯的關鍵點，想跳槽大廠的年輕程序員、處在晉升準備階段的核心技術骨干、已經晉升成功卻對接下來要怎么做一臉茫然的技術人、已經帶了團隊每年都要帶領下屬進行年度規劃的職場老鳥，不同的職業生涯階段、不同的場景下，大家看似遇到了不一樣的問題，但是從更高的層面來看，這些不一樣的問題的根源卻是同一個。

處于 1-3 年的業務開發同學，拼命積累技術能力，卻不知道自己每天做的業務需求實際上需要另外一套能力體系來支持，而這套能力體系可以通過每天做的那些“影響我寫代碼的事情”來有意識地進行培養。

業務能力就是分析業務本質，理解業務問題的能力。分析當前的需求是什么場景下的，會有哪些參與方、分析各個參與方之間的協作方式、分析每個不同的角色在這個場景下會遇到什么問題，需要技術系統怎么做來幫助他們解決這些問題。通過個人的思考分析也好，和產品經理甚至是客戶直接溝通討論也罷，這些問題都是可以比較輕松地得出相應的答案的。隨著實踐層面的經驗不斷的積累，就需要從宏觀視角回顧一下自己過去做的那些事情，有什么樣的關聯，怎樣服務了客戶，客戶為什么需要這些功能，能為他們帶來什么樣的價值（翻譯過來就是解決了客戶什么問題）。這是業務開發必須要掌握的最基本的業務能力。

那些處在晉升準備期的研發骨干，技術能力毋庸置疑，而欠缺的則是獨立負責業務的能力。自己做的事情全貌是什么樣的，目前業務發展到了什么階段，在這個階段的業務瓶頸是什么，找到瓶頸的根源之后，如何在技術側發力促成問題的解決，在問題解決之后如何配合業務上下游的同事例如客戶經理或者運營同學，把產品功能的價值最大化，是更高階的業務能力的要求。這個過程如果不自己經歷一遍，是無法在技術團隊做一個合格的業務領域的 owner 的。日常工作中做不到的事情，在晉升場上也是無法通過考驗的。

對于那些已經晉升到下一個層級的研發骨干，在獨立負責業務領域或鏈路的基礎上，解決業務遇到的問題已經算是基礎能力了，那么接下來更重要的就是看業務發展趨勢的能力。解決遇到的各種業務問題，是面向過去和面向當下的工作方式，而基于業務發展趨勢來做技術側的布局和長期投入，則是面向未來的工作方式。系統架構演進、重點技術領域的長期、持續、堅持投入都是基于未來業務發展趨勢的判斷來做出決策的，而不是脫離業務空對空做設計做演進的。

對于帶團隊做業務開發的團隊管理人員而言，一方面要求能夠在宏觀上看到業務發展趨勢從而進行有效的技術側布局，在微觀上看到當前業務階段存在的問題從而給出合理的解決方案，另外還需要具備拆解復雜問題的能力，將遇到的問題進行多維度的拆解，理清業務涉及到的各方（客戶、產品、技術、業務、組織等）各自的核心命題，有機地將多方的訴求結合起來，根據業務發展前景和期望綜合定制合理的目標，并且帶領團隊做好執行實現目標。與其他故事里面提到的研發人員相比，帶領團隊做業務開發的主管們在宏觀上面對的問題是多維的，在執行上也不再是單人執行落地的模式，而是協調統籌多個方向多個業務領域的責任人進行協同執行，發揮出團隊的戰斗力。

看似不同的人在不同職業生涯階段遇到的這些問題，實際上是缺乏對應業務能力的情況下遇到的困境。

三、?該怎么辦呢？

學校里沒有相應的課程來幫助業務開發人員完成最初的基礎知識的積累，步入社會以后也沒有一本現成的書告訴業務研發人員怎么構建自己的業務能力，這樣看來，做業務似乎是一門實踐的學科，只能從業務中來到業務中去?？墒且坏┨岬綄嵺`，讀過毛主席的《實踐論》的讀者就知道實踐的經驗經過思考、分析、總結就能形成一定的理論，理論再去指引實踐就能少走彎路提高實踐的效率，當然被實踐所評判、修正的理論也會更全面、更完善。因此提升業務能力最好的方式是可以先從實踐出發，同時嘗試尋找合適的理論來指引自己的實踐，避免缺乏理論指引的情況下實踐效率和效果都不好的情況出現。

可是業務實踐究竟是怎么鍛煉業務能力呢？到底從哪去獲取構建業務能力的理論呢？如果讀者朋友現在仍然存在類似的困擾，先別急，可以先從我接下來講的一件事情中找到提升業務能力的契機和辦法。

四、我也曾經面對過同樣的問題

2017 年的阿里云開啟了創新業務的大潮，高峰期有幾十個創新產品在并行推進，我有幸參并負責了其中的兩個創新業務的技術工作，一個是電商相關，一個是金融相關。電商 BPaaS（業務平臺即服務）產品上線后，我隨即負責金融相關的產品的建設，金融 BPaaS 產品半年后上線，然后開始統管兩個業務的技術工作。這個時候發現經過大半年的發展，電商 BPaaS 產品的發展和演進已經讓當時的產品團隊、業務運營團隊、研發團隊都進入了一片混亂的狀態：

• 業務方面：

業務有了第一個大客戶，用戶體量不錯，業務規模比想象中更好，向上匯報也取得了公司層面的認可，團隊和業務基本上明確了可以存活下來。【技術側需要進行長期規劃了】

接下來就進入了尋找突破方向的階段，需要多方向、多業務模式的試錯?！狙邪l需求量大增】

業務本身非常復雜、業務領域非常多，從最開始業務上線我去做金融產品時的2個Java應用，到我回來兩個產品統籌管理時，已經發展到了整個系統有7個Java應用，對應著商品、訂單、交易、支付、結算、管控、開放平臺等幾個核心域和合同、流程、配管等支撐域，還有若干個業務無關的技術底層系統?！緲I務復雜度急劇上升】

• 技術方面

系統架構有問題，調用依賴關系混亂，存在性能瓶頸，無法支撐更大規模的用戶交易?！炯夹g側逐步形成瓶頸】

技術系統數量增多，復雜度上升，由小型系統演變為大型分布式系統。【研發在技術側的核心技術命題發生了變化】

穩定性、研發效能、運營效能需要投入技術人員做支持，但是沒有人做這些橫向的事情?！緲I務的發展催生的技術體系的變化出現了真空地帶，研發側尚無感知和應對，所有精力都集中在業務需求的開發上】

• 團隊方面

上游團隊是產品團隊，沒有行業經驗，也沒有應對復雜業務系統的能力和經驗，但是商業能力極強?！旧虅諅群涂蛻魝扔袠O大優勢，有非常好的商業模式上的頂層設計;產品功能和平臺能力建設上摸索前進，產品形態和業務能力上的頂層設計有缺陷】

下游團隊是運營&客服團隊，有電商行業運營和服務經驗，但是成員大多數是外包同學，在產品發展趨勢和功能規劃方面沒有話語權但是日常工作深受影響?！井a品設計上的協同和反向促進作用降低，長期下去會造成產品能力和客戶需求脫節】

研發團隊人員分工混亂，每個人負責幾個應用，但是有的人負責的應用之間關聯性不強，需求需要多人在同一個領域內做協作?！緩碗s的系統導致了分工不清晰，從而帶來了協同上的困難，研發效能變成問題】

研發團隊成員是正式員工+外包員工，工作結果在質量和產量方面都存在無法對齊的情況?！窘M織協作模式需要重新設計】

這些看似條理清晰的內容在當時都是混雜交織在一起的，所有人都在忙碌中承受著巨大的壓力，直接體現出的現象就是產品經理想要做功能，但是不知道該找哪個研發同學溝通需求；客戶反饋問題了，也不知道應該把問題轉給哪個研發同學進行解決。而研發同學這邊已經開啟了一邊業務開發一邊救火的模式，業務需求的排期壓力疊加了客戶反饋的問題形成的壓力，造成團隊日常工作氛圍異常詭異，一邊是異常忙碌，一邊是無人交流溝通導致工位上死氣沉沉，最可怕的是，為了能夠盡快完成業務需求，已經長期加班團隊在超負荷運轉的狀態下依然頻頻無法按期交付（別問為什么，問就是需求時間倒排），也就是說，研發團隊已經無法通過自身的調整適應和努力來改變現狀了。

我分別找了每個研發同學溝通之后，發現大家疲于應對業務需求和線上問題，每個人只了解自己做的部分的事情，除此之外，既不知道自己負責的部分接下來要做什么，也不知道業務整體上的情況是怎么樣的，更不知道自己負責的內容該如何配合其他人開展工作，也自然就不知道在技術上需要做哪些投入來支持業務發展。

所有人的所有行動都是被產品經理的需求串起來驅動的，而產品經理的需求一部分從“可能賺錢”的方向而來，這些“可能賺錢的方向”本質是不斷地試錯；產品經理的需求另外一部分從“客戶反饋的問題”而來，這些問題來源于線上的 BUG，也來源于功能設計的不合理、不完善，而這部分問題也在反復地用客戶第一的價值觀在精神層面炙烤著每個團隊成員。沒錯，在生理壓力和心理壓力的疊加下，每個人的焦慮都溢于言表。

摸清整體情況以后，經過分析當前業務、團隊、技術的基本面之后，所有的問題都指向了一個根源：沒有業務大圖，參與業務的幾個團隊沒有共享視角，各自的行為都是受業務自然發展而運轉起來的，而不是經過有目的的設計的，也就是說變成了業務推著人跑，而不是人領著業務跑。這個局面長期下去是非常危險的。

我相信有的讀者會特別好奇，技術方面架構有問題和沒有業務大圖有關嗎？有關，產品經理提需求的時候沒有義務也一定不會幫助研發人員想清楚現在的技術架構怎么做、未來的技術架構如何演進；而技術人員又不知道自己做的這個需求是哪個業務領域的，要解決什么問題，只能從現有的應用里面找解法，再加上偏頗的代碼復用理念和蹩腳的代碼復用實踐，導致調用關系混亂、業務邏輯雜糅，實在覺得很多邏輯不應該放在這個應用里面的時候，就被動地趕一下微服務的潮流把應用拆分開變成兩個Java應用……架構沒有設計，沒有演進，只有在業務需求推動下的應激（受到外界刺激的情況下倉皇應對）。

也有的讀者會好奇，團隊職能、成員組織架構、協作模式、工作分工出現問題，和業務大圖有關嗎？有關，以研發團隊為例：在當時沒有業務大圖的情況下，在內部，人員分工沒有規則和依據，每個人負責多個事情，內部協同成本高，責任邊界不清晰，而且所有工作都以業務需求開發為主，這樣的研發人員所組成的團隊整體上只是一個職能單一的業務需求開發型團隊，無法完成綜合性的業務支撐挑戰；在外部，與上下游協作溝通存在工作語言的差異，而這個語言上的差異實際上是各方對業務模型理解上的差異。

技術人員說的業務概念和產品經理、運營人員的業務概念對不齊，開會各說各話信息傳遞損耗嚴重，經常需要臨時對齊內容，但是會后又各說各話，從領域驅動設計的視角來看各方描述業務模型和核心流程時充斥著各種蹩腳的比喻和類比，很難見到合理的各方一致認可的抽象模型。并且由于研發團隊職能單一，沒有有效應對非業務需求之外的事情，導致上下游協作方對研發團隊頗有微詞，比如運營同學開展商品運營過程中遇到影響效率的問題，也覺得應該是研發團隊提供系統或者工具來支撐，在客服同學服務客戶的時候遇到影響效率的問題，也覺得是研發同學支撐不夠。因此，在研發團隊缺少業務大圖的情況下，沒有全局視角的情況下，根本不知道除了做功能迭代以外還要肩負起運營效能、客戶技術服務等等的重要職責。

所以在找到了所有問題的癥結之后，就像是找到了一團亂麻的線頭一樣，先把它拎出來，把它解決掉，然后所有其他的問題開始圍繞這個癥結點做梳理、調整、治理。以下內容就是當時畫業務大圖的整體過程，覺得有用的讀者可以把這部分內容作為描繪自己業務大圖的一個操作步驟來做實踐。

1.明確組織使命和愿景

開始畫業務大圖的時候，先確定業務大圖的頂層內容，講清楚是什么團隊在做什么事情，對于這個團隊而言做這個事情的使命是什么，大家聚在一起形成這個團隊，期望在未來的幾年之內把這個事情做到什么程度，而聚在一起做這件事情的不同角色的參與者，應該如何相互看待彼此，如何相互支持彼此開展工作。所以，業務的團隊主體、使命、愿景、價值觀就是整個業務大圖的最頂層的框架，如下所示：

圖 1 業務大圖的頂層內容

使命是組織存在的前提，也是組織做的這個業務的起因。愿景是在組織的使命下，在一定時間尺度下的一個宏觀的目標。關于使命、愿景不再做深入解釋了，關心為什么畫業務大圖需要首先明確使命、愿景，可以看下整個系列文章的《技術一號位的方法論【理論篇】——解決問題的規律總結及技術、業務、組織規律的探討與應對策略分析?》一文中提到的關于組織的規律相關內容。

2.愿景的多維度拆解

明確了組織的使命愿景之后，在構建業務大圖時，我們需要從“愿景”這個宏觀的目標著手，進行多維度的拆解，講清楚需要把哪幾件事情做好，才能達成這個宏觀的目標。如下圖所示：

圖 2 支撐愿景達成的多維度的拆解

多維度拆解愿景是構建多條業務線的理論基礎。以我們都熟知的阿里的使命愿景為例，想要在數字時代，讓天下沒有難做的生意，必然要圍繞著“做生意”的各個主要維度進行投入，以支撐愿景的實現：從最經典的 “人-貨-場”再到線上支付、物流、倉儲、履約、售后，再到各種生意的細分市場，再到文娛、本地生活等不同業務線（實際上目前已經從業務線發展成為事業群甚至是不同的公司了）的配合，我們可以從這個例子里面看到針對愿景的多維度的拆解過程。目前公司這些業務板塊是否是最開始就從頂層設計好的？不一定，有些可能是在業務開展過程中發現我們需要投入人力精力去做的，但是也有些肯定是從最開始就設計好一定要做的，比如線上支付服務。

3.業務的頂層設計

在團隊愿景完成多維度拆解之后，隨之要給出的，就是第二層的內容，這一層內容，主要是承接愿景的拆解，是戰略層面的業務的頂層設計。針對要做的業務分別從 “客戶價值”維度、“組織價值”維度、“社會價值”維度（可選）、“個人價值”（可選）維度來拆分，分別講清楚做這個業務對于客戶能產生什么樣的價值，這個價值用指標衡量是什么樣的；從組織的視角來看，做這個業務對部門或公司有什么價值，這個價值用指標來衡量是什么樣的；如果做的業務是面向 C 端普通用戶的，并且經過預判可以明確產品會對一定規模的用戶產生影響，那么還需要講清楚做這個業務對社會創造了什么價值，這個價值用指標來衡量是什么樣的。

分別講清楚業務的客戶價值、組織價值、社會價值及相關的衡量方式，即完成了業務在戰略層面的頂層設計，可以拿來與團隊進行對焦溝通了。具體如下圖所示：

圖 3 業務大圖中的業務頂層設計

細心的讀者可能會發現，上面大圖里面“個人價值”這條價值線是用虛線來表示的。這里需要著重講一下的就是，個人價值是一個對外隱形的維度，一般情況下可以不對外公開對焦，只用于對于個人職業生涯規劃的指引，方便我們把自己個人的成長和業務的發展結合起來。

但是作為團隊 leader 或者業務、技術一號位，可以嘗試把個人價值向核心團隊成員公開，讓團隊成員看到管理者、一號位如何把個人利益和業務利益有機得結合在一起的。做得更好的管理者可以鼓勵團隊核心人員也結合業務戰略構建自己在做業務時的個人價值線，彼此可以看到各自在意的方向和點是什么，基于員工提供的個人價值線進行團隊成員培養，以此為契機把做業務和帶團隊結合起來。

這一點一定要重視，因為組織的戰略執行離不開個人，個人的核心利益訴求也會影響個人的決策偏好和行為，從而會反向影響業務戰略的落地，這個是組織規律，這個規律也在《技術一號位的方法論【理論篇】——解決問題的規律總結及技術、業務、組織規律的探討與應對策略分析》一文中關于組織內的員工模型相關內容有詳細論述，本文就不再展開討論了。

總之，個人價值如何與業務價值的辯證關系是需要正視并加以引導的，因此有一定信任基礎的團隊可以嘗試這樣的實踐。

4.業務的規劃與執行設計

在完成業務大圖的頂層設計之后，接下來要做的就是進行執行層面的規劃了，我們可以按照“終局——中期——近期”這樣的時間尺度來拆解各條價值線的目標，并且豐富目標支撐內容，從而形成團隊在近期要做什么，目標是什么；中期需要做什么，要達到怎樣的目標；終局是什么樣的，如何基于中期的執行結果進行持續投入，最終達到怎樣的目標才算完成了業務終局的構建。針對每條價值線都需要有這樣的規劃。如下圖所示：

圖 4 簡易版業務大圖

到此為止我們就完成了一個簡易的業務大圖。這個大圖完成之后，就可以和整個團隊進行對焦，讓大家看到我們做的業務的全貌是什么樣的，大的業務拆解成幾個子業務，而幾個子業務是如何配合的（由頂層指標驅動的），并且能夠看到整個團隊在近期要做什么，中期要做什么，終局是什么樣的。另外一點需要說明的是，簡易版的業務大圖沒有畫出技術、組織和業務各個階段的對應關系，如果想要畫出完整的業務大圖，需要把組織、技術相關的內容與業務對齊。

5.業務大圖與技術大圖融合對齊

在 2019 年完成業務大圖的對焦之后，我緊接著基于業務大圖構建了技術大圖，技術整體上劃分為“支撐業務發展”，“保障業務發展”和“驅動業務發展”三條主線，讓技術主線和業務主線進行了全維度、全周期、全階段的對齊，過去雜亂無章的技術工作按照業務領域重新劃分，基于領域劃分完成了團隊成員職責分工，每個業務領域基于業務上的客戶價值主線和業務價值主線以及技術上的三條主線開展日常工作，哪些是近期要做的，業務未來會做成什么樣，技術側需要進行怎樣的規劃和長期投入都非常清晰。

在完成技術大圖的構建之后，整個團隊之前面臨的很多揉成一團亂麻的問題都迎刃而解，團隊成員看到了變化，士氣也逐步回升。然后又根據技術大圖和業務大圖構建了新財年的戰役規劃，并行針對戰役需要的支撐做了內部組織調整，徹底理順了團隊內部陣型，填補了橫向職能的空缺，過去沒有人負責的穩定性建設、研發效能、運營效能、客戶技術服務幾個大的板塊也進入了專人專責持續投入建設的階段。從上下游團隊和客戶的反饋來看，研發團隊的這一改變切實地解決了他們工作中遇到的很多實際的問題，整個業務協同和客戶關系都發生了積極的變化。這也標志著我帶領的研發團隊從過去的單一職能的業務研發團隊轉變為支撐全業務生命周期數字化需求的綜合技術團隊，團隊內部職責和空間都擴大了，留給了每個員工足夠的成長空間。

關于業務大圖和技術大圖的融合展現，可以參考下圖內容：

圖 5 業務大圖和技術大圖融合對焦

關于基于業務大圖的戰役規劃，可以參考下圖內容：

圖 6 業務大圖中的業務戰役

我的故事就這樣講完了，我相信處于不同職業生涯的讀者看到這個例子都能多多少少有所收獲：處于職業生涯早起的業務研發同學，可以通過嘗試構建自己做的業務大圖，形成對業務整體形態的認知；要晉升的讀者，能夠依靠構建業務大圖的這個嘗試，補全做事情的重要的維度，并且從不同的維度找到業務的突破點；已經帶團隊的讀者可以依靠業務大圖完成業務頂層設計，能夠與自己的團隊成員對齊，并且利用好業務大圖把各種問題梳理清晰，做好調整，利用業務戰役實現業務目標，打出團隊成員的士氣，讓他們在開展業務的過程中獲得成長、讓他們通過業務結果和技術成果獲得成就感。

五?、業務大圖是誰都“有資格”畫的嗎

有的讀者可能會看著如何畫業務大圖的方法和步驟大皺眉頭，看著里面滿眼的“戰略”、“頂層設計”、“一號位”已經開始出現不愉快的情緒了，內心不禁想要質問作者：你是什么水平？帶幾個人？就張口戰略閉口頂層設計？當然也可能會有讀者懷疑自己：我一個寫代碼做需求的，畫這個圖有點大逆不道吧，這得是我老板的老板的老板才能做的事情吧？如果讀者朋友有以上情緒，我覺得我們可以深入聊一聊，業務大圖是誰都有資格畫的東西嗎？討論之前先亮出我的態度，我覺得“王侯將相寧有種乎”，誰都有資格畫，不僅有資格畫，還要多畫、常畫，只有一個要求，必須越畫越好，越畫越貼合實際實事求是，除此之外百無禁忌。相信我的觀點一出，可能有人已經想要拿著“別談戰略”的尚方寶劍開杠了。

眾所周知，網上有一些真假難辨的傳聞，據說有人剛入職某頂級大廠就發郵件教總裁做事，戰略打法頭頭是道，頂層設計信手拈來，當然后面就直接“被畢業”了。所以我們這些一線干活的人、一線帶團隊的人，說話辦事一定要離“戰略”遠一點，避免被人質疑是否有資格，是這樣嗎？我覺得我們這些做執行的“信息時代的農民工”，除了做好執行的本職工作以外，一定要開始嘗試畫自己所負責的業務的業務大圖，注意，是畫自己負責的業務的大圖，而不是畫總裁的業務大圖。如果擔心被人質疑資格而不去做的話，那么你現在負責的事情有誰幫你畫好了業務大圖嗎（任意形式都可以）？如果沒有人幫你畫業務大圖，你的主管跟你同步新年規劃也僅僅是幾句話帶過的話，那么請問你這一年的工作要如何高質量、有計劃地完成呢？如果已經有人幫你畫好了業務大圖，那么你負責的事情在對方的業務大圖里面占比是怎么樣的呢？涉及到你負責的事情的重點了么？未來會發展成什么樣提到了么？如果都沒有提到或者關鍵信息有缺失的話，那么缺失的這部分是不是還需要你的主管幫你補充好呢？相信這些問題在大家心里都有合適的答案。

對于研發團隊和研發人員自身而言，業務大圖是業務戰略、目標、執行策略、關鍵戰役的綜合信息載體，即使不畫業務大圖，這些內容也應該是一個管理者，一個獨立負責某個業務領域或業務鏈路的同學必須了解的。如果日常工作中沒有目標，不清楚目標實現的策略，整體業務發展趨勢和各方期望也都不知道，那么員工是無法高質量地完成工作的，只能被業務需求驅動，而不是被業務驅動。同時更重要的是，對于執行者而言，不論是處于職業生涯的什么周期，不論帶不帶團隊，畫業務大圖是打破自己能力壁壘、突破層級束縛，從單一維度做事升級到多維度、高層次做事的最好的方式和契機，它是打開你職業生涯更廣闊空間的一扇大門。用一個比喻來形容業務大圖的重要性的話，我們可以把一線做業務需求的研發人員比作我在文章開頭的第四個故事中提到的那只在莫比烏斯環上不斷爬行的螞蟻，而業務大圖就是從高緯度空間伸入低維度莫比烏斯環的一架梯子，一架可以幫助那只螞蟻突破維度壁壘的梯子，可以讓螞蟻沿著這個梯子，從無盡的二維空間進入三維空間，從而從更高維度的視角審視自己過去的環境、行為、認知。畫業務大圖的過程，讓業務研發人員不得不具備更高層次的視角（俗稱站在老板的角度看問題），為了把業務大圖畫出來而不得不去思考、解決頂層設計者們每天日常工作中會遇到的一部分問題。換言之，這實質上是利用畫業務大圖的過程，模擬、創造了頂層設計者工作環境，主動進行了頂層設計者一部分日常工作的實踐。

實踐有了，思考也會有，思考有了，認知也會逐步形成，認知形成了，行為就自然會改變，會轉變層下一個層次的工作模式，這就是業務研發人員從實踐到認知再到實踐的成長過程。所以再回頭來看，業務大圖要畫嗎？業務大圖能畫嗎？為什么放著通往下一個層次（注意不是層級）的大路不走呢？這么顯而易見的問題就不需要再回答了吧。

除了對研發人員或團隊自身的一些好處之外，在業務開展過程中對外協作方面，在進行上下協同時，業務大圖是多方對焦，下級理解上級業務戰略部署的最好的工具，能夠防止業務在落地過程中研發團隊只做機械地執行，也能防止執行方向跑偏，資源投入不當，也能防止整個業務團隊研發團隊在業務開展過程中出現短期主義，沒有長期價值的堅持，這些意義的重要性與戰略設計的正確性同樣重要。因此畫了業務大圖，可以向自己的上級主管多多請教對焦，爭取讓自己的大圖和上級的大圖在各個層面都是匹配的，不論是在戰略層面還是執行層面，都是形成了一致的認知，那么接下來就是放手去做執行了。

業務大圖在組織上的好處就不再深入展開了，大家也能從我舉的自己的示例里面看到效果。

所以，業務研發同學要多畫業務大圖，多談談自己負責的事情的戰略，多設計設計自己半年或者一年尺度上的工作計劃，多在執行過程中自我糾偏，多在執行過程中和上級對焦，針對上級簡略的任務布置能有成體系、完善的、不遺漏重點不需要領導補位的執行計劃和堅實的落地過程，請問這樣的業務研發人員或者一線主管，有誰不愛呢？

當然如果空談戰略而沒有拆解和執行，那是“嘴炮黨”，不是“業務大圖黨”，不是一回事兒，不展開討論了。

六、?業務大圖不是銀彈，通往下一個層次的路上荊棘滿地

學會了畫業務大圖，找到了通往下一個層次的路，只是解決復雜業務問題的起點，而不是復雜問題的終點。圖要一筆一筆畫，路要一步一步走，紙上談兵招人恨，實踐之中出真知。有了業務大圖不是萬事大吉了，更多的是通過業務大圖來構建個人對復雜業務的分析能力，來提升決策的正確性，是采用科學的工作方法走出的第一步，也是打開未知之門邁出的第一步。所以在學會畫業務大圖以后，還要多思考、勤實踐，真正開始以一個清醒的狀態面對自己的職業生涯。

不論你是剛入職場的新人，還是你已經處在自己職業生涯的關鍵期，還是你已經帶著團隊摸爬滾打做事，請緊緊抓住業務大圖這張船票，做好迎接更加艱巨的挑戰的準備，因為通往下一個層次的路上驚濤不減，荊棘滿地。

最后需要提示讀者朋友們的一點是，后續大家在畫業務大圖的時候會遇到一個非常非常關鍵的問題，那就是業務大圖中的戰略目標如何確定，在不同時間尺度上的業務指標如何確定。?