中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導讀：產品經理需要懂技術嗎？這是一個永遠有人在討論，永遠沒有答案的問題。而作為一個從技術轉做產品的人，本文作者在工作中總結了自己的一些感悟，比如技術型產品經理的定位是什么？產品經理對技術的了解程度如何劃分？如何設計出一個架構合理的系統？本文對此展開分析，與你分享。

計算機專業+一年IOS前端開發轉型產品，讓我對技術的了解相較于一般的產品經理要多一些，平時也更多的承擔技術強相關的系統方案設計工作，因此有一些我一直在不斷反思，嘗試給出更好答案的問題，比如：技術型產品經理的定位是什么？產品經理對技術的了解程度如何劃分？如何設計出一個架構合理的系統？

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

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

我對技術型產品經理的定位是：以用戶需求為導向，充分利用現有技術及新技術的研究，為用戶提供更高質量的產品。

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

1. 充分利用現有技術

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

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

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

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

2. 推動新技術的研究

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 合理的信息通路

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

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

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

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

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

2. 邏輯上完備

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

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

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

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

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

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

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

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

第四個特征是可拓展性。系統對業務的支持一定要做到可拓展性，或者講，做到規模效應。隨著工作量的累積，同一單位工作量所帶來的效果的應當是遞增的。而不是隨著業務需求的增加變得臃腫不堪后在進行重構

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

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

1. 該系統涉及到的模塊有哪些？哪些模塊是已有的，哪些模塊是新增的？
2. 每個模塊的定位，或者說定義是什么？在系統中扮演什么樣的角色，起到什么樣的作用？舊有模塊的定義是否滿足我們的要求，新模塊的定義是否清晰明確？
3. 每個模塊的輸入輸出是什么？每個模塊所獲得的輸入是否剛好滿足其能完成任務的需求，既不缺乏信息，也不存在會導致依賴的信息冗余？
4. 模塊間的上下位關系是否明確，是否與該模塊的原有定位相契合？
5. 系統整體的模塊的調用順序是什么？是否擁有合理的信息通路？是否保證了模塊上下位關系的一致性？是否存在下位模塊僭越上位模塊進行/被進行跨層級調用的情況？

做個形象點的類比，設計系統就像拼拼圖。

第一個問題，就是看我們手上有哪些拼圖；

第二個問題，就是看拼圖上的畫是什么；

第三個問題就是看拼圖的邊緣是什么樣的；

第四個問題，就是看哪些拼圖的邊緣是相互契合的；

第五個問題，就是拼好后，看整幅拼圖是否存在不一致錯誤。

本文由 @我的 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議