作者 | 栢檸
來源 | 阿裡技術公衆号
本文作者：螞蟻集團資深産品專家栢檸，先後負責螞蟻AI平台、風控平台産品工作。
過去幾年，我和團隊一直在負責螞蟻集團内部相關平台産品的設計和營運工作。
這些平台産品包括人工智能部的A/B測試平台、機器學習平台、金融知識圖譜平台、NLP平台、智能文案平台、金融視覺(CV)平台、搜尋平台、機器人平台、标注平台等，以及風控團隊的相關平台産品。這些平台産品，在背後支援了螞蟻幾乎所有核心業務的運作和發展。
整個過程當中，我們在平台建設、業務支援、平台營運、AI創新以及AI整體營運等各個方面做了很多嘗試，有了不少的收獲和感悟。
最近，我花了一些時間，将其初步梳理出來，寫成了這篇文章。
文章的内容涵蓋了“需求管理、平台設計、産品驗證、平台協同、人性對抗、跨界思維、挑戰/成長”等7個方面，既有一些抽象的、方法層面的總結，也有很多真實的、有體感的案例。
篇幅比較長，約1.5萬字。感興趣的話，可以收藏下後面慢慢看。
希望本文對你有所啟發，更期待能抛磚引玉，跟大家做深入的探讨和交流。
一 需求管理：“角色錯位”與“無我境界”
1 挖掘需求，警惕“角色錯位”，杜絕“閉門造車”。
做好産品的第一步，就是把握好需求，必須搞清楚每一個産品和功能的真正使用者是誰。
對于C端産品，這個問題比較好解決，因為設計者和使用者往往是重合的。但對于技術平台類産品、B端産品，這兩者經常是錯位的，即設計者可能并不是真正的使用者。
舉個例子，支付寶的産品經理在日常生活當中天天用支付寶付款、理财，他就是個典型的支付寶使用者，是以設計者與使用者就是同一個人。而在技術平台、B端産品當中，産品的設計者可以用自己的産品，但基本上僅限于做測試、做驗證，真正的使用者卻是其他的人。
是以，設計者對于産品需求的一些推理判斷，可能會與真實情況有差别，即使他用了，那個以測試為目的的使用和真實的使用，還是有差別的。
由此可見，正是由于技術平台類産品中這種角色的錯位，就容易導緻需求把控出問題。
下面，先從我們标注平台的一個小故事開始講起。
去年12月的一天，我們标注平台的相關同學開會，進行産品設計評審。
其間，針對一個标注頁面的産品設計細節問題，在坐的産品經理、UED、前端、後端各個崗位的同學各抒己見、争論得不可開交。
突然間，我意識到一個嚴重的問題——那就是會議室的所有同學，并不是這個feature的使用者。
因為具體的标注工作，都是外包公司的數百個标注人員做的，他們才是标注頁面的真正使用者。
不是真正的使用者、沒有處在那個場景，就很難了解真實的情況。于是，大家就隻能根據自己的經驗和專業能力，進行判斷和推演。
做産品不能閉門造車。于是，我們就随即安排相關同學去了标注外包公司做現場調研。
一開始，我們與幾個标注團隊的小組長進行小範圍的初步溝通。當時，随口問了下産品使用情況，他們一緻回報“沒什麼問題，挺好用的”。
這樣的回答很正常，畢竟這麼簡單、直接的問法，是很難擷取到有價值的資訊、了解到使用者的需求。
在産品經理的行業，我們經常說的一句話是，在汽車被發明之前，如果你直接問使用者要什麼，他隻能說“我要一匹更快的馬”。
釘釘原負責人無招同學來螞蟻做“釘釘創業之路”的分享時，也談到這個問題。
他的觀點是，見到使用者不能隻是“就事論事”，隻問産品使用相關的淺層次的問題。（即使問這樣的問題，也不能問“你有什麼需求”之類很難獲得真實需求的直白的問題）。
正确的方式是，先把具體的産品抛下，多了解客戶的背景、業務、狀态等整體的、背景的、來龍去脈的資訊，要表現出對客戶“感興趣”，要想成為客戶的朋友。
隻有這樣，客戶才願意跟你多聊、深聊，隻有這樣，你才能捕獲到有價值的資訊。再加上，觀察客戶的具體行為和操作，就能捕捉到真實的需求，才能做到有所洞察。
于是，結束會議後，我們要求上樓到标注員工的辦公區，具體看看情況。
當我們站在标注人員身後，仔細觀察他們的操作、與他們深入交談後，就有了新的發現。
很多原來沒有想象到的使用方法和場景、産品設計的細節問題，在标注人員的不斷操作中，就顯現出來了。之前産品評審會上大家争論的問題，自然就有了答案。
半天下來，我們總共記錄下數十個有價值的回報和發現，并在後續工作中，一一做了處理和跟進。
可見，如果你不是真正的使用者，你沒有親眼觀察真正使用者的操作，很多問題你是無法預料到的。
大家IQ都不差，遇到問題，我們往往習慣于談方法、講邏輯，經常在會議室裡面唇槍舌戰甚至拍桌子瞪眼睛，最後誰也說服不了誰，得不到有效的結論。
在這時，不妨先問下自己“真正的使用者是誰？”，再試試“笨辦法”，走出辦公室，走到客戶那裡，去問問他們、跟他們聊聊天，看看他們怎麼用我們的産品。
那時候，很多問題便豁然開朗了。
2 滿足需求，不斷“由淺入深”，修煉“無我境界”。
接着，讓我們的思考再深入一些。
現在，假設你已經明确了使用者是誰、摸到了需求的大概脈絡，那也要考量“對需求了解是否深入”的問題，即淺層需求和深層需求的問題。
換句話，也是手段和目的的問題——“淺層需求”往往隻是手段，而“深層需求”才是目的。
舉個例子，對于我們負責的金融視覺平台，有使用者回報“我需要模型報告”，即模型訓練出來後，将一些“準确率、召回率、AUC之類”的名額，用圖表的方式展示出來。
如果你隻是将這個需求做了，那是不夠的。
為什麼呢？因為使用者要的模型報告，隻是“淺層需求”——他的确需要看各種名額，但他最想要的是，在新模型訓練出來後，他要對不同版本的模型效果進行對比——不僅要知道名額是多少，更想知道名額的具體變化，哪些升了、哪些降了以及具體數值是多少。
隻有這樣，才算是滿足了深層需求。
道理是相通的，類似問題在C端産品中也會碰到。
如果你留意的話，你會發現很多電商網站、汽車導購産品的産品經理已經摸到了深層需求。
比如，汽車網站裡面基本都有一個“車型對比”功能：不僅能将不同車型的各項配置、參數，用表格逐項列出來，而且還提供了“高亮不同配置、隐藏相同配置”等貼心功能。這就是深層次地滿足了使用者的需求。
是以，對于一個需求，多問幾個為什麼，多問自己“這是使用者的真實目的嗎？他用這個功能到底想幹什麼”等。隻有這樣，才有可能觸及到使用者深層次的需求，才有可能做出讓使用者感到很貼心的功能。
對于深入滿足使用者需求，除了做淺層、深層的分析之外，還可以采用“分而治之”的思路，将産品從子產品和功能上分層，即分出“N級火箭”，每一級“火箭”用來滿足不同類型的使用者需求，或者同一使用者在不同階段的需求。
舉個例子，盡管我們的圖譜、NLP、CV、搜尋、機器人、标注等幾個平台産品的功能各不相同，但我們還是找到了共性，即抽象出了需求分級和業務賦能的“五級火箭”，包括“功能嵌入、API調用、資料訓練、模型定制、算法開發”等五級。業務方可以根據具體情況，來選擇不同的接入方式。
- 第一級，功能嵌入：通過iframe等實作成本最低的手段，将平台的某個功能子產品嵌入到自己的系統當中。
- 第二級，API調用：直接調用平台提供的成熟API，比如調用身份證、駕駛證之類的OCR識别的API。
- 第三級，資料訓練：平台的模型符合需求，但需要提供自己的訓練資料或者字典資料等，來解決具體場景需求。
- 第四級，模型定制：平台的現場模型不太符合要求，是以要對算法參數進行配置，然後訓練出符合自己需求的新模型。
- 第五級，算法開發：最進階的情況，就是業務方懂算法、要開發新算法。平台則提供“算法開發、資料管理、模型訓練、模型測試和釋出”等一系列深層次的能力，來提升算法研發的效率。
上述“五級火箭”，由淺入深地滿足了不同類型使用者，以及同一個使用者不同階段的需求。
記得多年前，我參加了一個管理方面的進階教育訓練班。教育訓練有好幾天，内容很多，不過幾乎所有的教育訓練内容我都忘記了——除了一位老師無意中介紹的一個“萬能四步法”。
所謂四步法，就是“分類-排序-找規律-應用”這四個步驟。無論在學習新的領域知識、接手新的工作，還是來到新的環境時，都可以嘗試這個萬能四步法，相信再複雜的問題都能迎刃而解。
使用者分層、五級火箭，就是“分類-排序”的一個應用。
談完“需求/使用者分層、五級火箭”了，那是否就是對使用者需求360度、無死角地滿足了呢？
答案是否定的，因為我們還沒有做到“無我境界” 。
所謂“無我”的境界，就是滿足使用者需求的時候，不能隻考慮“我是誰、我有什麼”，而要忘掉自己，去看使用者需要什麼，什麼東西對使用者最有用。
比如，雖然你是做AI技術平台産品經理，但你眼裡不能隻有AI、算法、模型——要做到“無我”，就是要做到：如果有一種非算法、非AI的産品政策，若能切實幫到業務，那也應該去做。
在業務同學的眼裡，有沒有算法沒關系，是不是高科技不重要——而有沒有業務效果才關鍵。正所謂，不管白貓黑貓，抓到老鼠才是好貓。
比如，我們的智能文案平台，能夠智能生成千人千面的營銷文案。過去，一直在疊代産品、提升算法能力，力圖生成更加智能、精準和個性化的文案。
然而，大家知道，算法的提升不可能一蹴而就，算法效果都是慢慢地打磨和優化的。
在這個過程中，産品經理同學不能幹等。
于是，我們就在思考，不管多麼高深的算法、多麼智能的平台，我們生産的仍然是文案。而文案這個崗位，随着廣告行業的發展已經存在了數百年，那麼，一定有成熟的方法論和模式。
作為網際網路從業者，我們崇尚創新和颠覆，但我們還必須對行業保留敬畏之心。
于是，我們的産品經理同學就去把一些市場營銷、廣告文案經典書籍研讀了一番，總結出了所謂“18種優質文案句式/模闆”，這裡面既有文案從業者的經驗總結，也有廣告學、心理學等領域的科學原理。
将這些“優質句式”、“文案法則”産品化之後，配合算法和技術，就能給業務輸出更有效果的文案。
我們相信，機器不能完全代替人，機器智能和行業知識、專家經驗等人類智慧，一定會相得益彰、交相輝映。
二 平台設計：平台産品，也必須“秒懂”
講完需求，再來說說設計。
在網際網路行業，面向C端使用者的産品不僅供給充裕、極大豐富，而且普遍都免費，擷取成本基本為0。
沒有付出，就不會“珍惜”。
是以，對使用者來說，産品必須容易上手，即必須“秒懂”。如果使用者幾分鐘甚至幾十秒看不懂、不會用，那他基本就放棄了，産品就沒有機會了。
對于中台、平台産品來說，其實也是這樣的，隻不過使用者遇到不爽的體驗隻能忍忍，因為使用你的産品來解決他的業務需求，這是他的本質工作。
但是，這并不意味着産品随便搞搞就行，因為他還可以有别的選擇。你要知道，公司内部往往也有類似的産品，更不用談外部的、免費開源或者收費的解決方案了。
是以，你在平台設計上，也要下功夫，必須能快速抓住使用者，讓使用者迅速上手、接入、上線，幫助業務拿到業務結果。
如何才能做到“秒懂”呢？可以從“産品架構、術語體系、幫助指引、産品demo、統一互動”等幾個方面來考慮。
1 有清晰明了的産品架構
使用者一打開平台的頁面，就應該清晰地感覺到平台能做什麼，産品架構是什麼樣的，包含什麼功能子產品，子產品之間的關系（包含、先後等），第一步做什麼、第二步做什麼，等等。
這一點看起來沒什麼深奧的，但常見的問題是，産品經理在産品設計前期，對架構的思考不夠充分。經常是到了PRD、視覺評審階段，才發現子產品設計不合理、流程不清晰等等。這時，再返工、改動，成本就大了。
更為糟糕的是，頻繁的返工和變更，會讓産品經理個人的專業性和權威性喪失殆盡。以後，還怎麼向技術提需求、磨資源？
為了避免這樣悲慘的事情發生，産品經理要在台下多下功夫。
一個好的習慣，是先在腦中重建，再動筆繪制。很多産品經理習慣一上來就畫demo，這是不對的——大腦的認知和計算資源是有限的，顧“此”就會失“彼”，當你陷入種種細節後，就不可能從根本上、架構上思考問題了。
那怎麼辦呢？可以用充分使用腦圖這種工具。具體來說，你先不要考慮任何demo圖，而是先把整個平台産品層級結構全部理出來，包括各級導航和子產品、每個子產品包含的頁面及核心功能闆塊。畫好腦圖之後，站在使用者的角度，反複梳理和模拟，直到橫向、縱向的邏輯和流程都沒有問題了，再動手做具體的demo、PRD。
2 有顧名思義的術語體系
産品的整體架構梳理清楚之後，還要重視“術語/概念體系”，即産品中的核心概念命名以及概念之間邏輯關系的設計。
這個之是以重要，那是因為，概念和術語體系是每一個領域知識沉澱的結果，也是人們學習新事物、進行溝通交流的媒體。
概念複雜，産品必然複雜；概念簡單，産品才能簡單。
比如，同樣是人機互動的指令和方式，微信的“搖一搖”就能讓使用者“顧名思義”，并立馬有體感地照做，而我們支付寶的“咻一咻”，就比較難了解和付諸行動了。
又如，當年喬布斯釋出iPod的時候，并沒有直接抽象地說“存儲空間高達4.8G”，而是說“把1000首歌裝進口袋”。
可見，産品中的新概念命名不合理，或者将晦澀難懂的底層術語直接暴露出來，都會對使用者造成很大的困擾。
再比如，在A/B實驗平台中，最初的概念體系自頂而下分别是“業務域-業務線-産品-實驗”。
我們發現，使用者很難厘清“業務域”與“業務線”的差別，裡面的“産品”也不是大家所了解的“支付、借呗、花呗、餘額寶”這樣的産品，是以存在很多困擾。
後來，我們借助大家熟知的“實體實驗室、化學實驗室”這些事物，将概念體系改造成這樣：達爾文是一個“實驗平台”，裡面可以建立“xxxx實驗室”“yyyy實驗室”，在每一個實驗室當中，可以做各種各樣的“實驗”。這樣，就好了解多了。
除此之外，我們還對實驗室中的角色命名進行了修改。
之前實驗權限管理裡面，有“管理者”、“成員”這兩種常見的角色設定，我們同樣參照現實生活中實驗室從業人員的崗位名稱，将其改成了“實驗室主任”和“研究員”。
有趣的是，“研究員”在阿裡體系有“高P/組織部”的層級含義，這樣小小的一個文案的修改，也包含着平台設計者的“人文關懷”——對那些用A/B實驗來踐行資料驅動創新的、追求科學嚴謹做事方式的同學們，給予一點點溫情和榮耀。
而且，日後的營運活動也好做了，比如可以評比“十大研究員、十佳實驗室”等等。
總之，在設計産品的術語體系，首先是“如無必要，勿增實體”，其次，要盡量借助大家腦海中已有的概念，而不是直接照搬技術實作，或者生造新的概念。
3 有恰到好處的幫助指引
即使你在概念設計上下了功夫，也不能保證使用者不會産生任何疑問。
是以，就需要設計“幫助體系”，做進一步的解釋和闡述。
這裡，并不是說讓你寫一份冗長的産品文檔。文檔應該寫，但它不是重點，因為大部分人并不會仔細把産品文檔讀完才動手操作——他隻有遇到問題，才有可能去查查手冊。
這裡說的“幫助體系”，指的是産品化的幫助體系，即 “文檔産品化”。具體來說，就是把幫助文檔中的要點盡量嵌入到産品頁面當中，讓産品實作“自解釋”，而不是放到産品體外、僅僅存到幫助文檔中。
“文檔産品化”，具體的措施包括如下幾個方面：
頁面上有輔助說明
常見的情況，是我們的頁面太幹淨、太空了，舍不得放一句解釋的話，當使用者遇到問題，就不知所措了。是以，可以在标題下面做小字解釋、在概念上面出tip氣泡提示。對于複雜的情況，在幫助文字後面還可以加上“了解更多”連結——直接跳轉到幫助文檔的相應地方，而不是要使用者從頭查找。
新功能上線，有提示和告知
平台不斷做疊代改進，但經常發現使用者并不知道上了新功能。是以，可以對此做适度的提示和告知：大疊代可以蒙層彈窗、小的改動可以出小紅點，等等。
4 有簡單直覺的全流程demo
隻看教學視訊學不會遊泳，光學“科目一”是學不會開車的。
天花亂墜說半天，不如動手玩一遍。
現狀是，很多技術平台完全沒有demo和體驗能力。那麼，使用者就很難上手。
是以，平台一定要搭建一套“全流程、有體感、簡便易行”的demo，讓使用者親手體驗一下。
全流程，指的是你的demo要涵蓋平台的全部環節和步驟。有體感，指的是要有直覺的結果（而不是隻顯示抽象的數值、json代碼輸出之類）。簡便易行，指的是要足夠簡單、幾分鐘就能完成（是以你需要内置幾組demo的語料、圖譜、資料集等等）。
舉個例子，在NLP平台和金融視覺平台當中，使用者可以很便捷地線上體驗金融NER/文本分類、身份證/銀行卡OCR的效果。
也可以全流程地完成“項目建立、資料上傳、資料打标、模型訓練、模型測試”等環節。
值得指出的是，對于平台的demo，一定要越簡單越好，千萬不要高估了人的耐心。
記得在金融視覺平台第一版全流程demo上線後，當項目組成員在具體體驗時，才發現還是很繁瑣，甚至要放棄。
要完成demo，你仍然需要寫一堆表單，比如項目名稱/簡介、模型名稱/簡介、資料集名稱/簡介，而且，還要自己準備訓練資料，不得不去網上搜尋、下載下傳幾十/上百張圖檔……
後來，我們就對此做了大幅度的簡化，能點滑鼠的就不要讓使用者輸字，比如自動填充各種名稱和簡介。此外，平台還内置一些測試資料集供使用者使用等等。
經過一番簡化之後，使用者才能在幾分鐘之内，完成全流程、非常有體感的demo了。
5 有标準/統一的互動體驗
在做好每一個平台的設計之外，還需要考慮不同平台的體驗一緻性，即平台的統一。
做好這件事情，既能讓使用者降低學習成本、在不同平台之間平滑切換，也能減少UED、産品經理、技術同學們的重複勞動。
首先，可以将平台通用的架構和子產品，抽象出來、統一起來，包括Portal頁、項目管理、權限管理、資料管理、任務管理、釋出管理等等。
其次，将細節的體驗也統一一下，具體到元件的設計、命名、顔色、位置等等。
當我們沉澱出一套經典的産品架構和互動标準，那産品疊代速度和使用者體驗，都會大幅提升。
三 産品驗證：用不“深”，就做不好
1 要深度驗證，而不是蜻蜓點水
産品經理要真正做好一個産品，必須要自己多用。
這個道理很簡單，但這裡要談的是使用的“深度”——随便點點、看看，跟深度使用的差别是很大的。
舉個例子，如果讓你設計導航産品中的路口轉彎提示語，你可能覺得設計成類似“前方500米路口右轉”這樣就沒問題了。
你看，既包含距離，又說清了方向，感覺已經很完美了吧。然而，當你深入使用産品時、當你自己駕車的時候，才會發現情況并非如此——你很難精确地把握是否到了500米處，很可能在300米處的一個路口就錯誤地提前右轉了。
是以，現在的導航提示不僅會說“前方500米第N個路口右轉”，并且會在不該右轉的路口提示“正在經過第N-1個路口”，隻有做到這樣精細，才能保證使用者不會走錯路。
對于我們的标注平台來說，深度使用展現在做資料标注的次數——标注幾次與幾十、幾百次，你的感覺是完全不同的。
标注頁面中的一些設計的細節問題，在你做一兩次标注的時候感覺不明顯，當你做上幾十次、上百次之後，再小的問題也都會暴露出來、被放大了。
比如，有一種圖像分類任務，你隻需要标注“對”還是“錯”。
之前的設計，是每頁展示一張大圖，答完題後就切換到下一頁。當我們自己親自标注了幾十張之後，就感覺這樣的效率很低。
于是，我們就改成了一頁展示一二十張圖檔，标注人員隻需要掃一眼，把其中“對”或者“錯”的勾選出來，然後整體送出就好了（同時也減少了每一頁重新整理頁面、加載圖檔的等待時間）。這樣簡單的一個改動，其實并沒有什麼技術難度，但标注效率直接提升了好多倍。
2 自己“做業務”，結果大不同
真正要把一個平台做好，不僅要像上面說的，自己多當“标注員”，更應該做做 “業務方”。支援業務、賦能業務，跟自己做業務，還是有很大差别的。
下面，用我們做的垃圾智能分類的項目“分類寶”這個案例來說明下。
在2019年7月份，全國很多城市開始推行垃圾分類。
我們的同學基于沉澱的圖像、NLP和圖譜等AI技術能力，迅速開發出了智能垃圾分類的技術和産品，項目命名為“分類寶”。使用者可以通過“拍照片、語音搜尋”等便捷的互動方式，在支付寶小程式以及智能垃圾回收箱IoT裝置上，來體驗AI垃圾分類了。
這個項目，并不是各個業務BU給我們提需求而開始做的。這一次，我們有了雙重身份，我們自己既是平台方，也第一次做了“業務方”。
做起業務方之後，我們才發現，垃圾分類這個事情看似簡單，實際上卻包含很多複雜的環節，從“訓練資料的擷取、物品類目的整理、垃圾分類标準的維護、線上回流資料的訂正”，到“物品類目權重和優先級的調整、标注結果的确認”，再到與内部各個部門的協同、與外包ISV的對接、節假日與特殊物品的應對，等等。
經過一番手忙腳亂的折騰，總算是把項目磕磕絆絆地做了起來。
在這個過程中，我們遇到了很多之前不知道的問題，其中既有平台設計不合理的産品問題，也有訓練時間過長之類的技術問題。
更重要的是，讓我們看到了不同流程、不同系統以及不同團隊之間銜接的“真空地帶”——這正是大公司由于分工、邊界帶來的，常說的“三不管、踢皮球”的問題。而這些銜接上的問題，正是隐蔽的、極大影響效率的問題，需要被發現，通過産品和流程等機制進行解決。
“自己做業務”的這一次實踐，讓我們平台同學換了一個視角，深刻體會到了業務同學的不易，也直接推動了平台的疊代改進，以及團隊配合、流程設定的完善。
四 平台協同：連接配接，産生價值
前面講了很多，但大部分還是聚焦在某一個平台的個體上。
孤立存在的平台，就可能會降級成一個工具，其價值和能量就變得非常有限。
是以，要做好、做大平台，需要跳出平台本身，以連接配接、全局、生态的思維來看。
如果讓不同平台産生協同和連接配接，會産生“1+1>2”的效果。如果把封閉在平台内的“控制流、資料流”延伸出去，變成閉環，就會迸發出很多創新。
下面，介紹幾個方法和案例。
交叉連結，帶曝光帶流量
這是最簡單的一種平台協同的方法。每一個平台不僅要完成自己的使命，還應該考慮為兄弟平台做點什麼，比如帶帶曝光、帶帶流量什麼的。是以，我們在每個平台産品的導航欄都增加一個“AI産品矩陣”的菜單，把七八個産品的logo、名稱、連結都列了上去。資料表明，這個小小的菜單，每天都能為其他平台帶來可觀的曝光和轉化，做這個菜單的ROI非常高。
平台能力複用，杜絕浪費
平台在不斷疊代更新的過程中，對于一個新需求，不要一上來就自己做，而要先看看其他平台有沒有可以複用的現成的能力，哪怕是“曲線救國”或者“權宜之計”。
比如，知識圖譜平台的知識更新和智能文案平台的文案釋出，都需要走打标和确認流程，我們發現标注平台的标注能力就夠用了。是以，我們就沒有重新開發，而是在平台之間打通連接配接，快速解決了這個問題。
反哺和閉環，實作共同發展
如果一個平台隻是單向的輸出能力，而沒有從下遊獲得反哺，沒有形成閉環，那也不是個完善的系統和平台。
舉個例子，我們的标注平台已經累計對上億條資料進行了打标，這些标注資料使得各類模型的訓練變成了可能。正所謂，沒有人工，就沒有智能。
在這個過程中，标注平台隻是輸出價值、為智能化助力，自己并沒有從智能化中獲益。
後來，我們就考慮把這個鍊條形成閉環，即讓打标資料訓練出的模型反哺回标注平台，進而實作“智能輔助标注”。
這樣，将整個平台從“純人工标注”，轉變為了“智能輔助标注”，大大提升了标注效率、降低了标注成本。
沉澱資料資産，創造更大的價值
如果一個平台有資料的沉澱，那麼這些資料就需要深度挖掘，進而産生更多、更大的價值。
比如，每個業務最開始接入知識圖譜平台，為了解決自己的業務問題，就得從頭建Schema、導資料。但随着平台的發展，沉澱的知識越來越豐富。那麼，後續的平台就能直接受益于之前沉澱的知識，而不一定要自己重建立設了。這就是，平台資料沉澱出的價值。
再比如，标注平台裡的标注資料，在完成模型訓練之後，生命周期就終結了，躺在那裡沒有人管了，這是很可惜的。
現在我們計劃将這些資料沉澱下來、開放出去，讓資料産生更大的價值。
首先，标注資料對内開放。在業務剛接入AI平台，存在一個冷啟動的階段，最缺的是打标的資料。是以，可以将标注平台中海量标注資料梳理和開放出來，讓業務可以先到平台裡面搜尋下，看看有沒有已有的資料，有的話，就可以複用。如果沒有，再考慮重建立資料。
其次，标注資料對外開放。我們可以把一些不涉及隐私、不牽扯我們核心技術能力的部分資料開放出去，為社會創造更大的價值。
比如，在智能垃圾分類“分類寶”項目中，沉澱了數十萬打标的垃圾圖像資料。在我們開放了相關模型API之外，再把其中一部分資料開放出去，就會對整個社會的垃圾智能化處理，貢獻螞蟻的一份力量。
接入開放平台，實作強強聯合
這裡，再說說開放的具體做法。如果自己直接對外開放，做起來就比較麻煩，有很多對接和維護的事情。應該考慮将自己的能力接入到現成的、大的平台，比如支付寶小程式平台/開放平台、阿裡雲平台等等。借助這些大的平台，很多獲客、對接、運維的事情，就有兜底了。
這裡，再分享一個考慮平台協同創新的思路，那就是“圖解法和窮舉法”。
一開始，平台協同創新都是散點發生的，想到一個就做一個，很不系統和體系化。
後來，為了把所有“連接配接”和“協同”的可能性都窮盡，我們就畫了一張系統協同大圖和矩陣圖，把所有的平台都放進去，全方位地思考平台之間有什麼沒有打通的，有什麼協同創新的可能性。
這個方法，大家在做其他工作時也可以參考。
五 平台中的人性對抗
大家常說，有人的地方就有江湖。一個平台，也是一個江湖。
不同角色、訴求的人參與其中，人性就展示出來了。
是以，就需要思考人的事情，就需要對平台進行營運和治理。
1 平台的誤用
首先，要糾正平台上出現的不正确的用法。
為什麼會存在這種情況呢？
原因在于，盡管産品經理在産品設計的時候，本身就會盡力杜絕大部分錯誤的發生，在平台的玩法中也有相應的規則告知到使用者，但大家并不會像你想象的那樣“守規矩”，他們會有意無意地“妙用”、“錯用”甚至“濫用”。
比如，在我去年負責A/B實驗平台的時候，我們曾經對平台中所有實驗進行深入分析，結果就發現了很多驚人的現象。
- 數百個實驗隻有一個版本：正常來說，需要兩個或者更多的版本來進行對照實驗，但很多實驗竟然隻有一個版本，其中一個很大的“妙用”或者“誤用”，是使用者僅僅把平台當作灰階平台來使用了。
- 數百個實驗内流量為0：有的使用者并沒有使用平台的分流能力，而是自己做分流，這也是我們沒有料想到的。
- 數百個實驗運作時間小于3天或者大于30天：正常來講，實驗需要運作一周左右。但很多同學将實驗運作一兩天，一看到資料有變化就把實驗推全或者下線了，這其實是不科學的。有的實驗運作了好幾十天，原因竟然是有人忘記處理了，可能實驗場景都不存在了。
- ……
可見，大家對A/B實驗的了解還是很不夠的，導緻在平台上出現了各種“奇特”的用法。那麼，需要在平台教育訓練和産品設計等方面，做更多的工作。
除了A/B實驗這樣的平台，在我們的金融知識圖譜等平台上，也發現很多問題。
我們知道，在知識圖譜的Schema規範當中，同樣一種實體隻能有一種類型。
比如，對于“公司”這個金融領域最常見的實體類型來說，全局定義一個名為“Company”之類的類型就可以了。不同的業務域，可以有不同的業務場景，但類型應該共享一個。
然而，現實情況是，業務同學為了簡單、好把控，往往都想自己建立一個類型。于是，在平台上就出現了類似Company1、Company2這樣重複的類型。
在圖譜平台上，除了Schema重複，資料也存在重複、不一緻的情況，這些都需要一個一個進行治理。
然而，平台治理這件事，既是科學也是藝術——既不能放任自由，也不能卡的太嚴。尤其是在平台建設的初期，如果限制得太死，業務方是很難了解和配合的，甚至會丢掉客戶。
是以，要把握好力度。
2 “濫用”與“違規”
上面提到的這些平台治理的問題，其實還不算太糟糕。
接下來，給大家介紹一些需要高度重視和嚴肅處理的“濫用、違規”的行為。
分别是标注平台中的兩個真實案例：“任務釋放”和“串通磨洋工”。
先說第一個，“任務釋放”功能的濫用。
考慮到外包标注人員變更比較多，是以産品經理在标注頁面上設計了一個“任務釋放”的按鈕，用于防止任務卡在一個人手中。
然而，後來标注小組長們回報“希望取消這個按鈕”，說這個按鈕被不少标注人員用來“挑活”：當遇到難度較大的标注題目，他們就點選“任務釋放”給跳過了。
于是，我們就把這個功能從一線的标注人員那裡收回，隻給小組長開放了（這個問題也是去外包公司實地調研時發現的，之前團隊同學們都沒有料想到）。
第二個是違規行為，說的是人員串通起來“磨洋工”。
有一段時間，算法同學回報标注速度下降了。我們分析了下報表，發現個别小組的多個标注人員的标注速度都降低了，包括之前做的比較快的人員。
經過調查發現，原來是有個别害群之馬不光自己偷懶，還教唆、串通其他人，一起降低标注速度，來集體“磨洋工”。
當然，“串通磨洋工”這個問題最根本的原因，在這些标注人員的績效管理方案上——之前采用的是月薪制而非計件制，有績效獎金但微乎其微。
最近，我們在專項建立任務難度分級标準，并在完善外包人員的整體管理方案。
3 “太智能”了，也不行
最後，再說一個非常有趣的事情。
我們知道，如果一個産品不夠貼心，不夠聰明和智能，那使用者肯定不喜歡，但反過來，如果“太智能”了，那有時候也不行。
人是不安的、焦慮的，如果讓他感到“太過于神奇、不知道裡面發生了很麼”，他就不敢用。
舉個例子，在模型服務平台的産品當中，有同學設計了“模型一鍵部署”功能，即把離線模型部署到線上過程中的複雜、繁瑣的特征處理等工作自動化了。
然而，當大家花幾個月開發出來後，卻發現根本找不到一個業務方，因為大家都說不敢用。最後，這個“智能”的一鍵部署功能隻能無奈地下線了。
（要說明的是，并不是說“簡化模型部署”這個産品方向有問題，而是上述“黑盒的、讓使用者心裡沒有底”的方案，需要多斟酌，要多站在使用者的角度來思考）
六 跨界、跨界、跨界
所謂跨界，就是突破原有行業慣例和正常，通過嫁接其他行業的理念和技術，進而實作創新和突破的行為。
世界著名投資家、沃倫·巴菲特的黃金搭檔查理芒格，是一個極具智慧的人，他非常推崇跨界的思考方式，他指出：
- 你必須以跨學科的方式思考。
- 你必須經常使用所有可以從各個學科的大一課程中學到的概念。
- 如果能夠熟練地掌握這些基本概念，你解決問題的方法将不會受到限制。
要做好技術平台的設計、營運和推廣工作，你也需要跨界的思維和打法——比如，你可以把營銷思維與産品、技術跨界地結合起來。
所謂營銷思維，簡單來說，包含“認知規律、品牌體系、素材載體、傳播路徑”等幾個關鍵點：首先，要服從人們對新事物的認識規律（簡單、直覺），搭建起一套品牌識别和記憶的體系（logo、命名），不斷策劃出有創意的活動和素材，并在合适的地方進行曝光和傳播。
那麼，對于技術平台的營運和推廣，也可以跨界地使用上述營銷領域的理論和方法。
具體來說，可以從以下幾個方面着手：
平台産品需要品牌
我們對所有的平台的品牌識别體系進行了梳理，參照“阿裡動物園”的慣例，分别命名為知蛛金融知識圖譜平台、鲸語NLP平台、圖鷹金融視覺平台、千鲟搜尋平台、靈犀機器人平台，每種動物的選擇都盡量展現了該平台産品的特點（畢加索智能文案平台、AlphaQ智能标注平台的名稱已經有一定認知度，就未做修改）。
除了名稱之外，我們給力的UED同學們還設計出了非常有區隔度、記憶度，異常精美的logo。有了名稱和logo，交流、傳播和推廣的時候，就好辦多了。
産品體系需要品牌
不光要給予每一個平台以記憶度和識别度，還要考慮多個平台作為一個整體，如何記憶和傳播。同樣是考慮到阿裡的武俠文化，我們就包裝出了“AI中台天龍八部”的整體品牌概念，來傳播八大AI技術平台産品。後來發現，這個“天龍八部”的在内部的影響力很高，很多人都用“天龍八部”來整體指代AI技術平台家族。
營運活動需要品牌
做營運、做推廣，也需要有一個品牌的體系。是以，我們構造出了一個“AI特派員”的形象。對于我們對内釋出的所有文章、視訊和海報，都納入到這個體系當中。比如，所有的内網文章标題、文章的首尾都統一格式，加入“AI特派員”的名稱和形象，這樣既友善形成統一認知，也友善大家日後檢索資訊。
此外，在營運活動和物料的設計中，也有品牌營銷思維，技術和平台再高深，傳播的時候也必須考慮互動、創意和趣味。
為此，我們定制了印有平台名稱和slogan的有趣的可樂瓶，為标注産品體驗的同學頒發“聘書”等等。
由此可見，将營銷與技術、産品跨界融合，站在使用者角度進行産品品牌體系和營運活動、素材的設計，就會收到較好的效果。
七 平台産品經理的挑戰和成長
讀到這裡，你可能覺得做平台挺有趣、挺容易。
其實不然，大家都難。
對于技術平台的産品經理來說，會面臨“心、腦、體”全方位的挑戰。
在專業技能方面，除了要有産品經理崗位必須的“需求管理、産品設計、項目推動”等能力之外，還需要“懂技術”。要懂研發流程，要懂各種算法、模型的術語和原理，因為你不僅要與平台的開發團隊對話，你還要跟平台的使用者進行對話——這些使用者大部分也是技術同學。
這并不是要求你比技術同學更懂技術、代替技術同學去做技術的事情，而是要求你要了解技術點的本質，要知道這個技術能做什麼、不能做什麼，這項技術與其他技術的差別是什麼，這個技術大的發展脈絡是什麼。
當你下功夫搞清楚了這些問題之後，才不至于處于太過被動的局面。
但是，“缺乏主動權、成就感不強”，還是困擾着技術平台的産品經理同學。
要解決這個問題，可以從如下幾個方面來考慮。
深入了解業務需求，提升業務sense
平台最終是為業務服務的，平台再牛逼，對業務沒有幫助，也是不能立足的。是以，當你對業務需求有十足的把握，就能有理有據地規劃平台建設的方向，就有成就感。
考慮自己能為團隊帶來什麼獨特價值
一個項目的成功、一個平台的成功，除了專業能力之外，還需要有足夠溝通、協調、推動、BD、銷售的能力。毫不誇張地說，要做好産品，産品經理不隻是産品經理，更要有産品的“小CEO”的角色。當你通過自己的多方努力，把一件事情做成，自己就會很開心，也會赢得團隊的認可。
任何一件事情，都有創新和提升的空間
對于标注平台，你可以沿着“人工标注”的老路子去做，也可以朝着“智能輔助标注”的方向去創新。對于智能文案平台，你可以隻依賴算法提升的路徑，也可以主動創新，把領域知識和行業經驗産品化，來實作産品經理驅動。對于使用者回報的擷取和産品的疊代進化，你可以使用“當面交談、問卷調查”的傳統方式，也可以嘗試“分析使用者日志，使用大資料+AI”的新手段。要相信，隻要以終為始，從業務出發，從使用者出發，就能找到産品創新的機會。
時刻敬畏産品、敬畏使用者，認真做每一件事
我們曾經用這樣一句話，來鼓勵自己團隊的同學：我們要用做幾億DAU産品的心态，來打磨幾百、幾千DAU的技術平台。認真的人不會吃虧，你今天的每一個付出，都會産生價值，都會提高自己。人生沒有白走的路，每一個“需求”都算數。
八 結語
總算到結尾了，在這裡，再對文章的内容做一個小結：
需求管理：“角色錯位”與“無我境界”
越基本、越簡單的問題，卻越難回答，也越容易被有意、無意地忽略。做産品第一步，就是要回答這些基本問題：搞清使用者是誰，搞清楚使用者的真實需求是什麼。要深度滿足使用者需求，要多問為什麼，了解使用者真實的目的。還要忘掉自己，多從使用者角度去思考。
産品設計：平台産品，也必須“秒懂”
如果一個産品一眼看過去，都亂七八糟的，搞不清楚怎麼回事，那基本上就很失敗了。是以，要從“産品架構、概念體系、幫助體系、demo體驗、互動統一”等多個方面着手，來實作“秒懂”。
産品驗證：用不“深”，就做不好
想做好産品，就要做好産品驗證，産品經理要想方設法去高頻、深度地使用自己的産品。有機會的話，還要自己“做點小業務”，你才會驚歎“啊，原來還有這麼多問題”。在這個過程中，你自己還會有很多意想不到的收獲。
平台協同：連接配接，産生價值
單個平台的價值和能量是有限的，當你突破平台的界限，創造更多的連接配接和閉環，你就會打造出一個欣欣向榮的系統和生态。
平台中的人性對抗
有人的地方，就有人性。對于多種角色參與的平台來說，要做營運、引導和治理，這樣才能讓整個平台平穩、健康發展。
跨界、跨界、跨界
面對複雜多變的環境，需要多元化的人才、互補的技能，需要不同行業和領域進行跨界融合。跨界會産生化學反應，跨界會産生創新。
平台産品經理的挑戰和成長
成年人的字典裡，沒有容易二字。有問題有困難，平台、團隊和個體才能提升和發展。産品經理崗位是個複合體，不是單個技能就能立足，産品經理同學需要不斷迎接挑戰，不斷修煉自己。
相信平台的力量，相信産品的力量。
我們剛剛起步，我們繼續前行。