互聯網的發展有兩種非常典型的產品形態：一種是流量分發，另一種是互聯網 +。在流量分發時代，一切以技術為核心；但是現在是互聯網 +，技術純度在下降。而很多技術人都是從流量分發時代走過來，帶著深深的技術烙印。餓了么技術總監廖雪梅分享了他做互聯網 + 產品時，有哪些不適、遇到哪些挑戰。
互聯網 + 與技術逆流
我算是互聯網行業里較早的一批碼農，做過五年技術和五年管理。想和大家分享的是互聯網 + 的技術管理。
假設你是技術人員，在你的面前有兩個項目讓你選擇去做，一個是 passport 登錄系統，規模十萬級；另一個是倉庫管理系統。你會怎么去選？
為什么問大家這個問題？因為我一直覺得在碼農中是存在一條鄙視鏈：
- 第一梯隊是做 AI 和高并發的；
- 第二梯隊是做技術架構和基礎服務的；
- 第三梯隊是做業務系統的，比如積分兌換系統；最后的梯隊是做內部管理系統。
在十年前的互聯網，技術人員會削尖腦袋往第一、第二陣營去擠，而現在越來越多的人開始進入第三、第四陣營的開發，各種業務系統慢慢地都在逆襲的過程中，這是為什么？
我回顧了自己十年的工作經歷，從技術角度來看，互聯網的發展有兩種非常典型的產品形態：其中一個是流量分發。
拿百度來說，百度是一個巨無霸的流量中心，很多產品都想從上面去分一杯羹，于是產品設計都是精細化從流量中心攫取更多的流量。這種產品形態下，產品本身很輕，但每一步流量的轉化就極其重要，所以需要技術精細化去優化，那是技術為王的時代。
另一個典型的產品形態就是互聯網 +，用技術去改造一個個傳統行業，產品越做越重，越來越閉環，技術的價值反而不是最重要的了。
在流量分發時代，技術管理相對簡單，一切以技術為核心。但是現在的互聯網 +，技術純度是在下降的。而我們很多人都是從流量分發時代走過來，帶著深深的技術烙印，當我們再去做互聯網 + 產品時會有哪些不適？會遇到哪些挑戰？這些就是我想要分享的內容。
互聯網 + 的需求變化
做技術管理，所面臨的第一個挑戰一定是需求上的。
互聯網 + 的需求理解會比流量分發時代更難，因為這個行業時先于互聯網 + 存在，每個行業都有它比較固定的模式，你會覺得隔行如隔山。比如做新零售的，產品會講商品廢棄、掛單等名詞，結算產品會說我們做的是“代收代付”業務，你會一頭霧水。
每個行業有每個行業的運行規則，也會給你的項目帶來很多不一樣的地方。比如，做結算時，研發最痛苦的事就是每個月的對賬。有一次，那個月的賬怎么對都不明白，從下午查到晚上，每次算出來都差了幾塊錢。到半夜 12 點時，做對賬的小伙伴特別悲催地看著 PM 說，姐，這個錢我自己掏了行嗎……結果當然是不行，做財務的每一分錢都需要對得非常清楚。
除了需求理解成本高之外，需求 PK 難度也會增加。由于互聯網 + 的強業務導向，在研發嘗試與產品 PK 需求的時候，有時候產品也解釋不清楚就直接說，線下業務就是這么玩的，那我們就必須這樣去做。
再次，需求變化迭代速度比流量分發時代快很多了。對于這個行業，業務同事也可能是新入門，所以經常會是一邊打仗一邊調整。而且整個市場競爭非常慘烈，巨大的壓力之下，業務也會根據競爭形勢不斷去做調整。
在做外賣產品時，我們每個季度都會做需求規劃。每次總結下來后發現，面向商家的需求規劃，可能有 40% 或者 50% 會按照計劃執行。而面對內部的需求比如管理系統，規劃最多只能執行 20%—30%。
總體來說，互聯網 + 的需求迭代更快、理解成本更高，研發嘗試要做需求 PK 也會更難。
技術團隊要對傳統行業保持敬畏心
管理無非就是事和人。技術 leader 對事的管理，第一要務一定是需求管理。研發 leader，第一項硬本領也就是能理解需求，能 PK 需求。在流量分發時代，需求理解和 PK 成本相對會低很多。
拿百度地圖上做酒店來說，PM 提需求說有些地方要做改版，但是我覺得這么做不靠譜，就會其他競品的樣式給他看，甚至聊聊自己作為用戶的一些“感知”（雖然不一定專業，但你至少是用戶）。另外，很多需求都可以從數據來分析這么做是否靠譜。如果 PM 一定要上線需求，這時候就可以去預估一個轉化率，最后拿數據說話，告訴 PM 這個需求不可行，再下一次，PM 就不會固執己見了。
但在互聯網 + 這兩個法寶都不行。比如曾經產品同學要求我們把營銷工具從 PC 搬到 App 上，這個工作量巨大，當時預估將近 2 個月。你想去 PK 需求，發現曾經的法寶都行不通了——競對的內部系統拿不到，在這種場景下產品都沒上線，更沒法用數據說明轉化率了。僵持了幾天，PK 不下來，PM 說，咱們下去看一看吧。然后我就跟著 PM 去商圈去走了走，結果是我決定去做了，因為跑商圈的時候才知道 PM 提出這種需求的原因。
在外賣行業，BD 是沒有工位的，每個月只回公司一次。當 BD 和商戶洽談，達成協議后想讓商戶配置營銷活動。但是那邊可能沒有 WiFi，4G 信號也不好，BD 沒辦法只能先記下來晚上回公司再錄入。在市場競爭很激烈時，半天的時間對他們來說都很珍貴，半天就可能導致商戶流水減少，從而轉向競對。這時候我才知道，將營銷工具搬到移動端，是一件多么重要的事情。
不去線下真正看你的用戶，不知道他們到底是如何使用你的產品。
再和大家分享另一個事，做外賣有一個最基礎的功能是給商戶打印小票。那么問題來了，App 適配多少種打印機才合適？我們之前做類似產品都會先去市場調研，哪些機型覆蓋到 90% 以上的，把這些機型覆蓋全就 OK。我當時也讓 PM 去做市場調研，商戶打印機的 Top 機型是哪些？他給我找了四五種，我們就適配這主流機型。而后來發現，每天仍然有各種商戶打電話投訴，為什么小票打不出來？為什么競對可以，你們不行？很多商戶因為小票打印不出來，直接把 APP 給卸載了。
這時候我才意識到，打印小票對外賣商戶來說是核心鏈上的關鍵環節，關鍵鏈路一定是 100% 甚至 200% 的投入，因為是生命線的東西。從那以后，我們把能做的機型都兼容了，甚至還會定期去收集新的機型，看看還有哪些我們覺得可以兼容的。
這兩次經歷帶來的教訓是什么？隔行如隔山，做任何一個行業都需要保持敬畏心。在互聯網 + 時代，技術要跟產品平等對話不容易，不了解業務就不可能去平等對話。
互聯網 + 的本質究竟是什么？我覺得就是要謙卑地去看清行業，看清技術和經驗在這個行業能發揮什么樣的價值。
互聯網 + 項目如何應對“爛尾樓”
有不少碼農都應該做過爛尾樓產品，在互聯網 + 這種事情更多。比如做一個代理商績效管理系統，做了半個月，結果上線兩周，業務不用了，因為業務要進行調整。
對于這種爛尾樓產品，我們有一個 MVP 原則，假設你要做一輛車，你應該從滑板車開始做，接著做個自行車，再做個摩托車，最后才去做一輛汽車。
依舊拿代理商績效系統來說，實現代理商機制目的是什么？為了想要更快速更省錢地擴張。那為什么要給代理商制定那么多規范動作呢？他們不是員工，沒必要聽你指揮。
在互聯網 +，避免爛尾樓最重要的事情是去跟業務達成一個共識：比如想做流程優化，可以先和業務去商圈跑一圈，看這個模式是否 OK，哪些痛點是產品和技術可以解決的，再往下去推行。
爛尾樓產品要避免一定是建立在產品、業務、研發都對這個行業有更深入的理解基礎上，在業務發展初期，爛尾樓產品可能就是試驗田。
新環境下的項目管理
前面說過，互聯網 + 的需求變化多、理解成本高、迭代速度也很快，對于研發 leader 來說，你可能永遠面臨事多人少的困境。除了深入了解行業，理解需求之外，很重要的一塊就是項目管理了。
項目管理分對外和對內。對外最重要是建立信任，信任首先一定是來自不斷的溝通。互聯網 + 的項目設計的角色很多，除了產品研發之外，還有運營，甚至財務、線下的 BD，要包裝各角色對于項目理解不偏差，立體的溝通機制非常重要。立體的溝通機制，包括例會、郵件、當面溝通，將項目的中間過程通過立體溝通機制傳遞出去。
其次針對項目碎的情況，按照固定周期來迭代。這樣如果有人提需求，即使你當前沒有人力，你也可以告訴他大概能排到什么時候，哪個迭代中，給他穩定的心理預期。
再次就是需求優先級 PK。你可以借助你對公司當前重點的理解，你的 leader，甚至拉上各個需求方共同的老大來 PK 優先級。在人少事多的時候，做需求也需要有一定的策略，就是避免撒胡椒面，要不不做，要做就一次把一個方的需求解決透徹。比如當時公司有一個很緊急的項目，需要建獨立的客服體系。老板拍板說兩周之內要把體系建設起來。了解到項目的價值，帶著小伙伴認真分析項目，加班趕進度，最后順利 2 周完成交付。在業務最困難問題解決之后，大家的信任感也就慢慢建立起來了。
對內，更多就是項目流程的管理了，包括前面提到的按照固定周期發版，以及從需求、設計、開發、測試、上線整個流程中有哪些問題，這些都是經典項目管理的東西，跟傳統互聯網差異不大，不展開了。
互聯網 + 的項目管理，就是對外建立信任；對內優化流程，提升效率。
古老的話題：提升團隊戰斗力
要提升團隊的戰斗力，首先一定要解決個體的成就感問題。碼農都天然地用技術追求夢想，希望能用技術去改變世界。
技術的發展催生了互聯網 +，也降低了技術門檻。正是定位、移動支付、云服務等技術的飛速發展，傳統行業才一個接一個地在互聯網化。而對于碼農來說，互聯網 + 的技術純度在下降，有時候你做很多技術優化，還不如業務的一個決策。
技術門檻在降低，業務比重又在增加，作為技術人員你的成就感來自哪里？我認為首先互聯網 + 技術的挑戰來自技術的復合應用。現在你不需要親自做一個緩存服務，因為 redis 已經非常通用了。但你需要了解什么時候適合使用 redis，怎么才能更好發揮價值。就拿開篇說的倉庫管理系統真的沒有技術挑戰嗎？子系統就有商品、訂單、庫存等，子系統如何解耦，如何做到高可用。業務邏輯還有權限、日志、文件異步導出等，每個要做到精細化，都有非常多的講究。一個系統到底有沒有技術挑戰，跟純 PV 關系不大，主要看業務是不是足夠復雜，只要業務足夠復雜，一定會有很多技術挑戰。
其次，互聯網 + 技術的挑戰也來自用技術解放生產力。
前面提過互聯網 + 人少事多的情況經常出現，那么哪些是可以通過技術手段去提升開發效率。比如前端經常覺得業務很相似，沒有成就感，那是否可以開發日常通用組件，能看快速搭建一個頁面出來。
再次，互聯網 + 技術的成就感一定是來自業務。
前面提過，互聯網 + 的業務很重，那么技術的價值感一定是離不開業務的，做一個幾千 DAU 的銷售 APP 在辦公室可能感受不到成就感，而你跟隨 BD 走訪商圈，看到你做的產品對線下有多大幫助，一定會有很大的沖擊。這種價值感是在辦公室里 YY 不出來的。
作為技術 leader 一定要不斷通過項目、事，甚至線下的走訪讓你的小伙伴感受做這個事情的價值。
除了個體成就感之外，團隊的戰斗力一定是來自于大家一起過事。所謂過事，就是大家圍繞一個目標往前奔，經歷很多困難，面臨很多挑戰，但大家齊心協力達成目標。就像碼農，都覺得小黑屋的友誼很珍貴，從小黑屋封閉開發出來的同學，再見面都跟大學同學一樣親切，這就是過事。
再次相比流量分發時代，互聯網 + 做的是辛苦活。你的團隊文化、氛圍建設也一定是要跟務實一些。比如你可能不去夸某人學習了一個最新技術，而是夸他用技術解決了一個業務難題。你不是鼓勵大家不斷造新輪子，而是倡導從錯誤中總結，從失敗中學習。健康的團隊氛圍是大家做事情雖然很苦，但是還能苦中作樂，還能很歡快陽光地自嘲。
最后還想和大家分享一下我對事、對人的想法。對事方面要想辦法去做正確的事情，去理解這個行業，去保持一個行業敬畏心，避免一些爛尾樓產品。對人方面要把大家的價值感建設起來，讓大家更愿意做事，并且做到更快樂的做事。
