事情是這樣的...前端
研發進度溝通會，又陷入了死通常的寂靜。後端
咱們的研發團隊已經在一個第三方集成的項目上奮鬥三個星期了。然而，三 周後提測的這一天，咱們才意識到：架構
方案設計行不通……框架
要死。學習
後端要進行重大修改，項目將延期至少兩週……測試
此刻，我默默地責備工程師們不夠勤奮慎重。但其實，他們確定也在責怪我沒有給他們足夠的時間去研究。url
最終咱們接受了現實：團隊決定再從新作方案調研。 咱們最終交付了這個項目，代價是大大落後於原來的時間表。.net
在咱們進行迭代回顧的時候，有一件事變得很清楚： 我做爲產品經理作了一些預設；這些預設被放進了方案裏；技術團隊相信這些預設是真的，而且開始工做。設計
問題：我沒有花時間去了解這個項目的複雜性。若是我在早期就讓技術團隊參與進來，咱們不會落得如此下場。3d
我獲得的教訓也很直接：做爲一個產品經理，理解技術對於項目成功來講相當重要。
接下來，我將討論新手PM可能會遇到一些問題，並給出個人回答。
爲何PM應該瞭解技術
瞭解技術能夠在如下方面幫助每個產品經理：
有助於在你的團隊中創建信任：開發者喜歡那些試圖理解他們的難點並願意協做配合解決這些問題的PM。
提升想法的質量：在瞭解技術以後。你能知道什麼是可能的，什麼是不可能的，因此你的想法是以現實爲基礎和可實施的。
在肯定項目的範圍方面變得更準確細緻：若是你瞭解什麼會增長技術的複雜性，你就能夠更好地進行權衡。做出權衡是按時交貨的一個很是重要的技能。
提升效率：你的產品需求和規範文件將會更加全面。由於與技術負責人/EM的合做良好，大部分重要的技術考慮都被提早搞定了。
識別項目相關的複雜性：你能更好地理解和項目相關的複雜性。這有助於你瞭解可能會遇到的風險並設法把風險下降。很是複雜的項目一般須要在全面開始以前先進行POC測試。
產品經理須要瞭解多少技術？
只有對技術的理解達到一個較高層次, 你纔可以回答如下問題：
構成你產品的不一樣技術棧是什麼？
這些系統中的運行邏輯是什麼？
與各系統相關的主要風險有哪些，怎麼規避？
哪一個系統是由哪一個團隊管理的？
這些系統之間是如何關聯的？ (例如: APIs)
產品經理如何瞭解一項技術？
話很少說，看圖。
在會議結束時，你應該已經有了一張簡易的流程圖或架構圖…
你可能不會理解全部的細節。那也不要緊。專一於理解所使用的術語以及它們所起的做用是什麼更爲重要。
重複以上循環，日積月累，你對技術的理解力天然會提高。
進階技巧：加深對技術的理解
其實僅僅和工程師坐一坐聊一聊並不能讓你瞭解完整的狀況，瞭解技術是很難的，須要產品經理們的不懈努力壯志雄心。
如下tips很是有用，請有志精益求精者認真食用~
把每一個新項目做爲學習機會
一旦你決定優先考慮某項功能，就請技術團隊參與進來。 從他們那裏瞭解：
- 哪些層面會受到影響？前端，後端，基礎設施等……
- 每一層會涉及多少許級的開發工做？ 理解構建該功能所涉及的技術難點。
這將使你對技術架構、所涉及的系統、複雜性的來源，都有清晰的認識。一個項目涉及的層數越多，複雜度就越大。
從技術故障中學習
生產環境中的問題和技術難點，是另外一個瞭解技術架構的絕佳機會。
若是這個問題影響了你關注的領域，請與工程師坐下來了解具體狀況：
1）哪一個系統受到影響？2)緣由是什麼？3)咱們能作什麼來防止問題復現？
重複這個循環，將幫助你創建圍繞系統自己及其薄弱的環節的分析框架。
或許一段時間後，你會發現：
提高系統魯棒性是優先級更高的事。
我還應該牢記什麼？
當你開始這段學習的過程時，還必須牢記如下幾點。
不要懼怕問問題：無論這些問題有多蠢，老是要去問。你問得越多，你獲得的信息就越清晰；
可視化有助於你更快地理解事情：在與工程師交談時，若是事情超出你的想象，請他們在紙上畫出來解釋。
工程師們喜歡那些試圖理解他們的語言和難點的PM：不要對他們的關切置之不理。與他們一塊兒工做，認識到他們預見的難點和如何解決這些問題的方法。
不要用你新發現的知識告訴開發人員 "如何實施"：這樣會被暴打，並且你會顯得很傲慢且瞎指揮。
深度學習技術方案有無數的好處，所以產品經理最好不要猶豫，在項目初始就開始瞭解它。這件事起步可能很容易，但最重要的是如何堅持這樣作。
固然也沒必要過於緊張，這將是一個很是有價值的學習過程。
關注咱們的OS帳號[ @LigaAI](https://my.oschina.net/u/5057806 " @LigaAI") ，持續接收更多幹貨分享~ 進一步瞭解咱們的產品，請訪問 LigaAI - 新一代智能研發管理平臺