本文作者 我偏笑，是我們“AI產品經理大本營”的早期成員之一，也是“AI研習小分隊”的分享嘉賓；下面是他分享的第三篇文章，以饗大家。

序言

熟悉我的人會知道，我對技術的了解相較于一般的產品經理要多一些，平時也更多的承擔技術強相關的系統設計工作，因此有一些我一直在不斷反思，嘗試給出更好答案的問題，比如：技術型產品經理的定位是什么？產品經理對技術的了解程度如何劃分？如何設計出一個架構合理的系統？

本篇文章準備就這類問題盡量展開去講，拋磚引玉。

一、技術型產品經理的定位

八個月前，我在文章《趨勢三段論》中提過這樣的觀點，技術型產品經理的定位是：以用戶需求為導向，充分利用現有技術及推動新技術的研究，為用戶提供更高質量的產品。

這句話有兩個要點，一個是充分利用現有技術，另一個是推動新技術的研究。

1、充分利用現有技術

第一點強調的是什么呢？是扛需求、是推動業務落地的能力。所謂充分利用現有技術，核心要點是保證自己能夠提出一個合理范圍內的落地方案，既不畏首畏尾，讓產品落了俗套，又不天馬行空，完全不具備可行性。這才能叫可落地。

需求的來源有很多：競品的新特性、領導的需求、自己的需求、合作方的需求等等，每個人站在自己的角度講自己的想法。能落地嗎，誰該做什么？這是技術型產品經理要問自己的第一個問題，他應該具有對全鏈路的把控能力，前端、后臺、總控、意圖、解析、對話，每個部分該承擔什么？改動量如何？任務該如何拆解？存在什么依賴關系？

技術型產品經理需要兼具從用戶和技術的角度看問題的能力。平衡技術實現與用戶需求，把最初想法轉化成真實可落地的實施方案，是技術型產品經理的一個重要的任務。

關于這點，我有一條約束自己的標準，這里分享出來，即：問題是否到我為止？換言之，我能否有能力成為所有問題的最后責任人？交付到我這的問題，要么我解決，要么我找人解決，我對最終交付負責。

2、推動新技術的研究

第二點強調的是：預見性和解決未來問題的能力。作為產品經理，應當對整個業務的發展方向有正確的理解；作為技術型產品經理，應當對業務發展所需的技術有一個明確的認知。

因為我們可做、能做、還沒做的事情太多了，都要做嗎？顯然不是。事情有個輕重緩急，作為產品經理，推動技術研究朝著未來業務最需要的地方發展就是自己的職責。

這一點要求我們根據業務的發展方向，明確什么是重要而不緊急的事，然后在條件允許的情況下，優先去處理它們。否則等到所有的事情都重要且緊急之后，那每天的工作會變成到處救火，且犯錯的概率也會由于缺乏深入思考的時間而大大提高。

舉個真實例子，我八月份提過一個需求，九月份上線之前，有個業務方的新需求明確依賴我提過的這個需求，而且還非常著急。如果等接到需求我再開始籌備，至少要將他們的上線時間推遲半個月。

關于這點，我同樣有一條約束自己的標準，雖然自己暫時還做不到，但這里也分享出來，即：別人是否有機會向我提出問題？換句話說，就是我是否能夠總是比別人先發現問題，然后推動問題在真正產生負面影響之前解決。

二、產品經理對技術的了解層級

我曾經給出過一個三層的劃分，用于描述產品經理對技術的了解層級：

第一層：知道什么能做，什么不能做。也即知道所謂的技術邊界。不論是自己提需求，還是承接別人的需求，你都能肯定的做出『支持』或『目前還不支持』的判斷。

第二層：知道什么好做，什么不好做。也即，當產品需求超出了目前系統的邊界時，或者說某需求當下『不能做』時，你有能力給出一個權衡了產品需求與系統改動量的初步技術方案。能做到這一層的人，可以說是一個稱職的技術型產品經理了，至少有能力跟技術人員進行高效的溝通。

第三層：知道什么該做，什么不該做。也即，你知道系統中的每個模塊的定位和意義，并有能力以業務需求為導向協助技術人員、甚至引導技術人員完成對系統架構的優化與改造，使其在未來能夠更好的滿足業務發展對于技術的要求。

第三層比較抽象，這里做一下解釋。當業務場景較為簡單且有限時，很容易出現一種情況，就是系統設計與業務嚴重耦合。實現一項業務功能的鏈路會很長，從頭到尾涉及到很多模塊，這塊邏輯你做也可以，他做也可以，往往人們總是傾向于選擇最符合直覺，看起來最直接的方案。但這樣通常會造成模塊間定位不清，邏輯分散的情況，當業務漸漸復雜起來，就不得不進行重構，否則就再難拓展。

所謂該做不該做，就是當你與技術人員合作設計方案的時候，應該從業務發展的角度看待問題，幫助技術人員明確各個模塊的定位，使得我們的系統能夠在盡可能長的時間保證可用性，能夠隨著業務的發展一同成長，而不是頻繁重構。

舉個形象些的例子，就像走一條路，第一層的技術型產品經理可以判斷，這條路上有沒有障礙，能不能走通；當走不通的時候，第二層的技術型產品經理可以了解，這些障礙物到底好不好處理；第三層的技術型產品經理會知道，這些障礙物究竟該怎樣處理，才能讓它們在最長的時間范圍內不會成為干擾。

三、技術型產品經理的抽象能力

抽象能力是技術型產品經理最為重要的能力之一。

抽象能力能夠幫助我們在分析時不至于陷入到繁雜的細節之中，能夠透過現象看本質，一針見血地解決問題的核心。

我舉兩個例子來說明抽象能力的作用。

1、合理的信息通路

第一個，在設計新體系時，我時常會抽象出一個概念，叫做信息。一個體系的建立需要各個模塊的配合和協作，我不可能知道每個模塊每行代碼的邏輯，那我靠什么來判斷一個方案是否可行呢？靠判斷是否存在合理的信息通路。

是，我確實不知道每個模塊的詳細邏輯，但我知道某項任務的完成，所必須的信息是什么。

先從整個任務的角度去看，將所有的模塊看做一個整體，看它的輸入輸出是否合理，如果一個系統未能獲取到它完成任務所必須的信息，這個方案必然就是不成立的，因為信息無法無中生有。

再從每個模塊的角度去看，每個模塊在系統中的作用是什么？它們的輸入和輸出是什么？它們有沒有得到完成任務所必須的信息？它們對信息做了怎樣的加工？最終模塊的輸出是否是我們想要的？

如果這些問題都有一個明確而合理的答案，那么這個方案就是可行的。剩下的只是各個模塊內部選擇自己最優的實現邏輯、模塊間選擇最優的協作方式而已。

2、邏輯上完備

第二個，通過抽象出問題的基本影響因素做到邏輯上完備。在做系統基礎架構設計時，有一個很重要的任務就是避免遺漏場景可能性。因為在系統設計初期，所謂的業務場景都只存在與設想中，而系統又需要在未來盡可能長的時間內保持對業務的可支持性，所以如何將當前還未真正遇到的問題進行全面考慮，盡可能的做到高通用性，就成了一個必須要面對的問題。

這里我們可以嘗試先想出一些基本且明顯的場景，然后據其反向抽象出問題的基本影響因素，并明確每個因素所有可能的情況，然后再利用排列組合的方式去描述一個個場景，就能有效的避免遺漏。

舉個例子，通過頭腦風暴，我想到了系統需要解決的12種場景，但是否完備了？我不清楚。但是我通過反向抽象，發現影響場景的基本因素有3個，它們的可能性個數分別為2、3、3，那么通過排列組合，我就知道，完備的場景數應當是18種，也就意味著我需要繼續驗證我當前的設計是否支持剩余的6種情況。當然有的情況在實際業務場景中是不可能存在的，不過做最初設計時多考慮一分，未來落地時就會少一分風險。

四、好的系統具備什么樣的特征

這個問題是我最近一直在思考的，很多時候，我通過直覺能夠判斷出兩個系統設計方案的優劣，但要跟別人解釋原因時，卻又不知道如何表達，所以我希望能夠提煉出一套系統設計需要遵循的方法論，至少用在我自己的工作中。

現在的我還沒能力提出一整套完備的體系，所以這里只是從幾個我有所感觸的維度進行說明。

第一個特征是模塊化。承擔同一功能的邏輯應當聚合成一個模塊，不要散落在各處，從而導致不可復用和難以維護。類似于開發過程中的函數封裝，所有需要同樣邏輯的部分都統一的調用同一個函數，而不是每次用到都重新寫一遍，還難以保持一致性。

第二個特征是低耦合。承擔不同功能的模塊保有邏輯上的獨立性，邏輯上分離的兩個模塊不應該存在邏輯上的相互依賴關系，每個模塊應該明確定義好自己的輸入和輸出，并盡量保證輸入和輸出的通用，而不是和上下位模塊深度耦合，這會導致在進行邏輯優化時牽一發而動全身。

第三個特征是通用性。系統的設計是為了解決一類問題，而不是某幾個問題。系統定義好自己的輸入輸出特性，將不同的輸入轉化為對應的輸出，而不是與業務邏輯耦合。不同的模塊，必須明確好，哪些模塊處理業務邏輯，哪些模塊不處理業務邏輯，這樣作為一個整體的系統才能有足夠的通用性去做后續場景的拓展。

第四個特征是邊際成本遞減。系統對業務的支持一定要做到邊際成本遞減，或者講，做到規模效應。隨著工作量的累積，同一單位工作量所帶來的效果的應當是遞增的。借用云棲大會中阿里iDST工程師的說法，每個技術人員所能支持的業務方數量應當是遞增的，而不是說5個業務方需要1個技術人員，那10個業務方就需要2個，100個業務方就需要20個，這顯然是不合理的。

五、系統設計中需要明確的問題

在系統設計中，至少需要明確以下問題：

該系統涉及到的模塊有哪些？哪些模塊是已有的，哪些模塊是新增的？

每個模塊的定位，或者說定義是什么？在系統中扮演什么樣的角色，起到什么樣的作用？舊有模塊的定義是否滿足我們的要求，新模塊的定義是否清晰明確？

每個模塊的輸入輸出是什么？每個模塊所獲得的輸入是否剛好滿足其能完成任務的需求，既不缺乏信息，也不存在會導致依賴的信息冗余？

模塊間的上下位關系是否明確，是否與該模塊的原有定位相契合？

系統整體的模塊的調用順序是什么？是否擁有合理的信息通路？是否保證了模塊上下位關系的一致性？是否存在下位模塊僭越上位模塊進行/被進行跨層級調用的情況？

做個形象點的類比，設計系統就像拼拼圖。第一個問題，就是看我們手上有哪些拼圖；第二個問題，就是看拼圖上的畫是什么；第三個問題就是看拼圖的邊緣是什么樣的；第四個問題，就是看哪些拼圖的邊緣是相互契合的；第五個問題，就是拼好后，看整幅拼圖是否存在不一致錯誤。

結語

寫完之后，回顧整篇文章，我發現我講了三層事情：

第一層：抽象能力、產品理解、技術知識

第二層：工作定位

第三層：實踐方法

抽象能力是技術型產品經理的重要能力，是進行頂層設計的基礎。同時，技術型產品經理要兼具對產品的理解和技術的了解。這些構成了一個技術型產品經理的能力體系。

技術型產品經理要明確自己的工作定位，兼顧當下與未來，既要有能力推動當下業務落地，又要有足夠的預見性去解決未來的問題。

技術型產品經理時常要與技術人員合作進行系統/平臺的設計，保證系統及其各個模塊擁有明確的目的（定位）、合理的鏈接（信息通路）、必備的要素（模塊），是設計一個完備系統的基本要求。

注1：我偏笑 的前2篇分享文章是《填槽與多輪對話 | AI產品經理需要了解的AI技術概念》和《以 Facebook 的 wit.ai 為例講解機器人對話平臺（Bot Framework）》

注2：飯團“AI產品經理大本營” ，是黃釗hanniman建立的、行業內第一個“AI產品經理成長交流社區”，通過每天干貨分享、每月線下交流、每季職位內推等方式，幫助大家完成“AI產品經理成長的實操路徑”，詳情可見?http://fantuan.guokr.net/groups/219/?。

---------------------

作者：黃釗hanniman，圖靈機器人-人才戰略官，前騰訊產品經理，5年AI實戰經驗，8年互聯網背景，微信公眾號/知乎/在行ID“hanniman”，飯團“AI產品經理大本營”，分享人工智能相關原創干貨，200頁PPT《人工智能產品經理的新起點》被業內廣泛好評，下載量1萬+。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的技术型产品经理与系统设计的全部內容，希望文章能夠幫你解決所遇到的問題。

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