導讀：“會”砍需求，并不是件容易的事情，這涉及到工程師的商業頭腦，要會判斷技術和業務的關系。技術與業務好比“兩條腿”，相互配合才能走得更遠。如何具備business sense就是我們今天的課題。

論工程師的商業頭腦
我們常常聽到這樣的話，“某某同學有很好的business sense”，這通常是評價一個非業務類型的同學，如果這個同學是一個軟件工程師，那么他一定很受產品和業務的青睞，因為對他們來講，這樣的技術同學交流起來更順暢，換句話說，就是更有共同語言。
什么是“business sense”？
Business Sense，更書面的叫法是Business Acumen，套用Wikipedia的解釋，is the keenness and quickness in understanding and dealing with a "business situation" (risks and opportunities) in a manner that is likely to lead to a good outcome。商業意識（更喜歡叫做商業頭腦，接地氣）是指對當前商業形勢的敏銳洞察力和快速響應力，通常會導致好的結果。
注意這里對商業形勢的判斷可能是機遇，但也有可能是風險，或者機遇與風險并存。能夠快速的識別出這些要素，并采取正確的行動，從而帶來好的結果，這樣的人會被稱之為具有好的商業頭腦。好的商業頭腦，加上強大的執行力，以及一點點的運氣，走上人生的巔峰便不是難事。
各行各業的商業天才，投資界的沃倫·巴菲特，科技界的史蒂夫·喬布斯，杰夫·貝索斯，拉里·佩奇，保羅·艾倫，等等，都是具有杰出商業頭腦的人。不過這些同學離我們的距離稍微遠了一點，他們的案例對大多數同學的日常工作不太具備指導意義，我們還是回過頭來聚焦在身邊的具體工作上，看看什么樣的同學會被大家認為是具備好的商業頭腦。

最有資格評價我們技術同學是否有商業頭腦的，恐怕是與我們相愛相殺的產品同學，我們來聽聽他們怎么說？
“‘會’砍需求的技術。也就是技術通過PRD評審通過和PD溝通，能夠在完整了解業務價值及解決思路的基礎上，準確判斷出哪些功能，哪些實現瓶頸，其實是nice to have, 而又有哪些是must have。在開發時間緊張的前提下和PD及時溝通砍掉nice to have的，抓緊時間保障完成must have?！?br />“有商業sense的技術同學往往具備開闊的視野、愿意接納新事物、在模糊業務背景下有自己的思維結構。
1）業務面向用戶是誰？用戶需求是什么？體量多大？2）業務增長紅利在哪里？3）業務的困難制約點在哪里？4）為什么是lazada來做，不是其他對手做？5）周邊的資本動向是什么？……

往往有商業思考的同學，大多數跟PD討論的是這些內容。他們不僅僅關心技術方案的成本以及工作時長?！?br />“討論問題、尋找方案、以及在制定方案的過程中，總是能以賦能業務的角度出發，來思考問題。關注用戶體驗、商家體驗、平臺業務健康性和可持續性?！?br />“技術方案嚴謹：基于對代碼熟悉了解+PRD理解的基礎上，能夠準確的評估近似人日。起碼不會在后期開發期間出現重大遺漏未評估環節；上下游鏈路聯動推動以達到要求的交付時間：對跨域的產品需求，能夠拉通關聯上下游進行技術評估和實現執行，有風險有問題迅速升級討論；對項目交付的時間有高度的敏感性”
“有合作精神、有開放的學習態度，以及有共贏精神?！?br />“對當下和未來的business target 和 步驟可以有清晰拆解和實現；能解決問題，靠譜，能一起擔當”
“In my view ‘business sense’ is the interest in and ability to solve ‘business problems’… So, in order for an engineer to have "business sense" s/he needs to invest the time and energy to understand (a) context, (b) stakeholders, and relative importance of factors for the company or organization when it comes to trade-offs. This would be driven by interest and - equally importantly - actual 'free' time to invest into those investigations. Of course, time is limited and engineers will decide whether to invest their precious 'free' time into developing "business sense" or their technical skills instead, i.e. into learning new frameworks, new programming languages, new technologies, etc.”

限于篇幅，這里只引用了部分同學的反饋，她們都毫無疑問的提到了以下幾點：

理解業務。具體一點講，明白當前業務的現狀，目標和方向，核心KPI是什么，為什么我們要做這個事情，以及做了以后對業務帶來的價值是什么？

了解技術實現的細節。當前的業務產品在系統中是怎么實現的，有哪些能力和局限，與上下游的關系是怎樣的。如何能夠快速的實現目前的產品需求。很多時候同一個問題可以有多種技術實現，每種實現都有自己的優缺點。優秀的技術同學能夠基于對當前業務問題的理解，作出最恰當的選擇。

能給到產品有效的輸入。對產品設計不合理的地方提出挑戰和有建設性的意見。對產品設計遺漏的地方給予補充，對穩定性、安全性，以及資損、輿情、PR等潛在的風險給予意見和建議。

積極的溝通和推動項目落地。幫助產品一起管理好業務的預期。能夠換位思考，理解業務面臨的壓力，管理好項目的風險，保持信息的透明，想盡辦法幫助業務實現需求。

很樸素的要求吧，不需要我們技術同學去學習理解高大上的經濟學知識，不需要你去做商業策略的判斷，只需要你了解當前負責的領域的業務，最重要的是，這些業務在系統中的實現，并給出建設性的意見，高效地推動方案落地。但是這個過程中往往有一些理解和執行的誤區：
1.非理性的挑戰
對業務價值的挑戰需要建立在客觀的數據基礎之上，而不是簡單的基于自己過去的經驗，其他人或者競爭對手的實現，甚至于技術同學自己的技術傾向。在缺乏數據支持的前提下，當我們與產品和業務對項目價值有分歧時，我建議：
1）讓專業的人做專業的事。術業有專攻，我們需要相信產品和業務的判斷?？梢砸笥忻鞔_的success metrics以及與之相匹配的運營計劃。養成項目定期復盤的習慣，避免重復犯錯。
2）用真實的數據來說話。技術同學最擅長的是用技術的手段來解決爭端。設計科學的嚴謹的實驗往往是解決問題的最佳途徑。在Amazon，幾乎所有涉及到用戶界面改變的項目都會強制要求A/B Test。強大的實驗框架允許業務和產品同時對上百種內容針對不同的人群進行測試，并根據結果自動調節分桶的大小。

2.Technical Debt and Over-Engineering
是用正確的實現還是臨時方案？在時間壓力下，大部分技術同學會選擇用臨時方案。但是所有人都知道沒有所謂的臨時方案。一旦上線，臨時方案就變成了永久方案，也就是我們的技術債。然后你會用雙倍甚至三倍的資源去還債。所以永遠不要使用臨時方案，除非你的重構計劃已經排上日程。過度設計目前看來不是太大的問題。有的時候技術同學往往會偏向選擇復雜的技術實現，比如碰到性能瓶頸大家會想到用多級緩存（JVM內存+本地緩存+TAIR），在實現時候的小小紕漏就會導致復雜的數據不一致，排查非常困難。而簡單的擴容可能就能解決當前的問題。請記住最簡單的實現往往是最有效的解決途徑。
3.脫離技術實現的細節空談業務
任何技術系統都有它的局限性。工程師們最寶貴的財富來自于他們對當前技術系統的深刻理解，這也是產品在PRD評審時最希望得到的輸入。優秀的技術同學總是能夠給出不同的技術實現方案，并清楚的分析每個方案的Pros & Cons，幫助產品做出最合適的選擇。脫離技術的細節空談業務往往無法幫助產品充分理解技術實現的局限性，無法充分評估其影響，從而不能做出最恰當的選擇。
4.Over communication is better than no communication
技術同學最受產品業務詬病的是溝通不充分，風險暴露往往太遲。理科男的特性決定了我們埋頭苦干的特質。有風險我們第一時間想的不是如何通報而是默默的去解決。這里我們必須要轉變的思路是項目的風險必須第一時間通知到對口的產品，一起想辦法去應對和解決。最關鍵的是，產品需要充分及時的信息去管理業務的預期。我們不是在孤軍奮戰，產品技術是一體的，產品代表技術對業務發聲，技術代表產品向用戶負責。
我們再來聽聽技術同學本身對技術與業務之間的關系是怎么看待的？以及對產品和業務有什么樣的訴求？
“技術與業務就好比人的兩條腿，相互配合才能走的更遠，任何一方不足就好比是瘸子走不遠走不快?！?br />“我覺得用最簡單最的技術解決復雜的業務，提高自身生產力，為客戶帶來最好的體驗和價值，是技術業務合作的最佳狀態。一個好的business sense的同學應該對于行業有足夠了解，對于問題有多種思考和解決思路，同時努力尋找最優的方向或者一些新的嘗試。個人感覺這些東西對于技術同學其實見識和思考的還是不夠多，對于產品同學來說可能了解的多一些，但是最優解法不一定有。這個是一個需要長期討論和慢慢沉淀的過程。”
“技術和業務需要相互信任，相互支持和相互理解，在業務初期或業務爆發期，技術團隊要么面臨基礎能力不完善的困難、要么面臨平臺能力不完善導致業務支持不過來的痛苦，業務團隊需要一起想辦法，做合適的業務或產品推進節奏，對業務規劃或試錯需要更加謹慎。反之對于業務遇到困難時技術需要更加主動的了解業務的本質與業務產品運營的詳細細節過程，通過細粒度的數據分析來幫助業務更好的看業務?！?br />“技術TL要懂業務（或者說理解業務），能夠和業務產品基于業務邏輯來對話，技術不能只被動的接需求，要了解業務當前的痛點，并有一些實際行動和業務一起想辦法解決痛點，如果能做到業務同學在做一個業務規劃或者有idea的時候能主動找技術同學來討論就比較好了?！?br />“業務不能只把技術作為開發資源，大家是一起為一個共同目標負責的，業務進展或結果要帶給技術同學做事情的成就感，需要技術同學理解業務的初衷和價值。”
“不喜歡：a) 特別在意業務邊界問題的PD；b) 特別喜歡挑刺且不給建議的PD；c) PRD在開發過程中經常變更的PRD，產品方案不嚴謹，也沒了解清楚業務根本需求；d) 只提需求不關注產品運行質量與問題的PD，這樣鍋全是開發的，對產品細節也不會關注，這樣的PD基本上就是滿足業務的需求,沒有產品的獨立思考；”

啊哈，不出意外，技術同學對商業頭腦的判斷和產品同學的預期并沒有大的差異，技術同學的訴求集中在以下幾點：
1.參與需求的生成
讓技術同學真正理解需求的最佳方式是參與到整個需求生成的過程，了解需求是怎么產生的，有直接和業務甚至用戶對話的機會。當然在LAZADA這個環境下，很多需求來源于各個國家的一線運營同學，參與每個需求的生成不切實際，但是至少有這樣的渠道或者機制存在，讓運營和產品能夠在產品規劃或者腦爆的階段盡可能的engage技術同學。Amazon每年6月到10月有一次大的業務規劃期叫做OP1（Operational Planning Stage I）。在這個期間，產品，業務，技術會在一起腦爆下一財年的要做的事情，產出規劃。通過這個過程，技術對做的事情有很強的參與意識，也有更強的主觀能動性。
2.產品設計要有全局視野
一個線上的產品往往是跨域的，需要有全局的視野。比如Flash Sale，從招商到商品發布，導購，詳情，到購物車，下單，營銷的計算，庫存，結算，逆向等，貫穿了電商的整個核心鏈路。我們往往發現某些交易相關的產品設計只考慮了正向交易的流程，對逆向的部分缺乏設計，或者一個退貨相關的產品只考慮了物流部分，沒有結算的相應流程。這樣有缺陷的設計是導致線上問題的根源。
3.既要管生，也要管養
每一個上線的產品都是技術系統不可分割的一部分，不但有開發成本，也有長期的維護成本。我們希望每個產品上線都有周密的運營計劃，能夠真正發揮出價值。我們允許試錯，但是不能容許草率的犯錯。而產品的運營往往需要長期的，持續的投入和精細化的運營方案，不能淺嘗輒止，輕易放棄。每個產品都是我們的孩子，缺少關注的孩子注定會夭折或者發育不良。LAZADA的拼團，砍車等產品目前看來是失敗的典型。
4.用有限的資源做最有價值的事情
資源總是有限的，而需求是無限的。在阿里既要又要還要的文化氛圍下，技術常常成為甩鍋的對象。技術希望與產品是背靠背的戰友，產品能夠從紛繁復雜的業務需求中找到真正有價值的目標，技術提供最強大的炮火，一起贏得戰役。沒有原則的產品不是好產品，不能堅守承諾的技術不是好技術。
技術同學怎么去培養自己的商業頭腦呢？下面給出一些簡單的建議：
1.產品是我們最好的學習伙伴
要了解業務，最快最有效的途徑就是和我們對口的產品同學。多和她們交流，認真的參與每次PRD評審，產品規劃，總結分享，多提問，你會逐漸成長為領域的業務專家，至少可以和產品平等對話。商業頭腦更多的是一種思維方式和習慣，多與產品討論業務，業務思考的角度就會自然形成。
2.培養數據意識
阿里的土話是No Data, No BB。學會用數據來說話，首先從業務核心的KPI入手，牢記它，項目的目標是什么？與業務KPI有什么關系？如何埋點，如何追蹤，定期復盤。數據如何變化，變化背后的業務含義是什么？用戶行為的改變還是推薦算法的升級，或者是系統的故障？建立清晰的業務數據看板。
做到這兩點，對大部分一線同學來講就足夠了。要進一步的提高自己的業務能力，你可以嘗試：
3.深入了解自己的業務領域
對自己負責的業務領域，有基本的業務框架的認知，了解業務發展的前景，現狀和痛點。對業務單元的主要角色，有深入的了解。放在國際化的場景里，就需要對當地國家的業務有一定的認識，比如國家經濟發展的狀況，電商的成熟度，用戶畫像，賣家分層等等。
4.拓展自己的知識邊界
多學習，多積累。包括日常的財經新聞，評論，重要的商業事件，互聯網公司的上市財報，競爭對手的動態，朋友圈的動態等等。
5.補充專業的知識
要想真正成為業務專家，基本的經濟學常識，行業知識，商業分析的模型和框架等等，開始變得重要。跨學科的知識往往能夠幫助我們拓展思維的方式和思考的深度，帶來創新。以色列有如此多的創業公司，其中的一個觀察是他們匯聚了非常多跨學科的人才，新產品新科技在思維的撞擊中不斷誕生。
最后我想分享一些在過去一年里國際化中臺技術與LAZADA產品業務一起成長的成功案例：
1.店鋪技術與PD合作快一年，就做到了商家裝修從0到55%，uv占比17%，承接雙十一45%的流量。引導成交占比18%。店鋪技術團隊自主建立了數據小站，幫助產品數據化定位商業問題，有效的推進了店鋪的數次升級迭代。
2.剛剛上線的電子憑證系統,在Lazada業務提出要在2020財年提升Digital Goods業務后，業務中臺的技術同學和Lazada PD快速組成項目團隊，在短短2個月內，完成東南亞電子憑證業務分析和對焦，上線了一套能夠賦能東南亞賣家和市場的電子憑證系統。在上線后1周內，參加了年中大促，為馬來西亞的Burger King賣家送去了一份驚喜大禮，一天內在沒有做大力宣傳的情況下，賣出10000份 Burger King電子劵。
3.LAZADA運費業務訴求：在盡量不影響GMV的情況下，降低平臺對運費補貼。針對這個核心訴求，產品技術提出了分階段實施計劃，首先解決業務上運費優惠難以運營的局面。技術層面提供運費優惠工具，使平臺和賣家可以自主設置運費優惠，運費的成本和優惠分離；其次由于不同國家業務背景不同，技術上針對印尼（物流基礎設施較差，競爭對手大量補貼運費）的大部分賣家進行預加載運費優惠，對不同賣家設置不同的門檻進行補貼，精細化運營；第三階段針對預加載優惠規則，提供平臺工具，支持單個活動支持多個賣家同時不跨店進行優惠補貼；第四階段提供了運費券運營工具，通過運費券替換平臺補貼優惠，進行定向補貼，通過覆蓋大部分活躍買家，保證GMV的同時降低平臺運費補貼成本。最終實現了在幾乎不影響GMV的情況下，每個月節省運營成本1M USD。
技術從支撐業務，到引領業務，到創新業務，這一路走來，我們始終與業務并肩作戰，攜手奮進。

在 GitHub 更新中，歡迎關注，歡迎star。

直面Java第262期：volatile是如何解決有序性問題的？

深入并發第009期：到底什么是Java內存模型？

- MORE | 更多精彩文章 -

如果你喜歡本文,

請長按二維碼，關注?Hollis.

轉發至朋友圈，是對我最大的支持。

好文章，我在看??

總結

以上是生活随笔為你收集整理的技术人员，该如何向业务和产品“砍需求”？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。