1. 更豐富的產(chǎn)品設(shè)計工具

通常我們的產(chǎn)品設(shè)計工具有文檔、流程圖、交互設(shè)計。但其實還有更多更好用的工具等待我們?nèi)グl(fā)掘。對技術(shù)思維的了解，能夠為產(chǎn)品經(jīng)理提供更多更直觀的工具去進行設(shè)計。例如：

• UML類圖（不需要太精確）能夠替代名詞定義，釋清對象之間的聯(lián)系。
• 用例能夠幫忙厘清用戶需求，分解特性點，也能方便產(chǎn)品經(jīng)理體驗 DEMO 和進行 sanity 測試。
• 時序圖能夠幫助產(chǎn)品經(jīng)理整理子系統(tǒng)和外部系統(tǒng)的調(diào)用關(guān)系，估算成本、優(yōu)化策略。
• 狀態(tài)機能夠讓關(guān)鍵對象的狀態(tài)以一種無比清晰的方式表達出來，讓整個項目的人一看就懂。
• 在面對稍微復(fù)雜的特性時，偽代碼能讓產(chǎn)品更好地與研發(fā)溝通，梳理并發(fā)現(xiàn)問題。

最重要的是，以上這些工具的學習成本都不高。

2. 對運算、通信、存儲等成本更加敏感

很多產(chǎn)品決策其實是商業(yè)決策，網(wǎng)絡(luò)通信是否快速、服務(wù)器能否HOLD住產(chǎn)品需要的計算能力，這些成本因素也可能決定著產(chǎn)品能否活下去。產(chǎn)品設(shè)計的策略可能對實現(xiàn)成本產(chǎn)生巨大的影響，產(chǎn)品經(jīng)理需要懂得如何優(yōu)化資源，用最聰明的方式去解決問題。

懂技術(shù)的產(chǎn)品，會對這些成本因素更加敏感。這樣的產(chǎn)品經(jīng)理需要對網(wǎng)絡(luò)通信、數(shù)據(jù)結(jié)構(gòu)和算法有一定的知識積累，甚至會進行時間復(fù)雜度和空間復(fù)雜度方面的估算。

其實，這些因素也會影響用戶體驗，特別是外部調(diào)用較多的場景。如何優(yōu)化整個網(wǎng)絡(luò)請求的時序、如何平衡同步和異步的流程、如何通過交互設(shè)計隱藏由于技術(shù)限制而產(chǎn)生的體驗缺陷，這些決策都能大幅提高產(chǎn)品設(shè)計質(zhì)量。我在做MIUI云名片，以及短信識別機票信息（在一個界面中使用了大量外部網(wǎng)絡(luò)請求）時，對這點的感受非常強烈。

3. 了解設(shè)計模式

基礎(chǔ)的設(shè)計模式，如工廠模式、單例、代理、適配器、觀察者模式等等，我認為是產(chǎn)品經(jīng)理的必修課，非常實用。了解這些設(shè)計模式，讓我們能對產(chǎn)品的實現(xiàn)方式、難易程度和可擴展性有初步的估算。

然而設(shè)計模式這個主題更吸引我的，則是「N大設(shè)計原則」（有些地方描述為 S.O.L.I.D 五大原則，有些地方則是六大原則、七大原則、十大原則）。這些原則，甚至可以提升到哲學層面，為各種生活決策、個人管理提供指導性的意見，在產(chǎn)品設(shè)計上甚至還有豁然開朗的感覺。

DRY原則告訴我們：「Don’t Repeat Yourself.」

單一職責原則（SRP）說：「每一個類應(yīng)該專注于做一件事情?！?/p>

依賴倒置原則說：「抽象不應(yīng)該依賴細節(jié)，細節(jié)應(yīng)該依賴抽象；即針對接口編程，不要針對實現(xiàn)編程。」

又如開閉原則（OCP）：「Open for extension, Yet closed for Modification.」

而迪米特法則的那句「低耦合，高內(nèi)聚」更是經(jīng)典。

這些設(shè)計模式，都是經(jīng)典。細細品味，妙趣橫生。熟悉代碼的應(yīng)該比較好理解，不熟悉的建議找本書來研讀。初步了解可以看看這個網(wǎng)站。

4. 快速搭建原型的能力

研發(fā)資源總是緊缺的，而產(chǎn)品經(jīng)理總想做新東西。掌握初級前端技術(shù)的產(chǎn)品即可快速搭建一個可用的原型，說不定這樣就能拿到投資了呢？

而且淺嘗前端技術(shù)也并不難，HTML+CSS已經(jīng)可以搞定大部分場景了，iOS 和 Android 開發(fā)也并不難上手。而且現(xiàn)在的傻瓜式開發(fā)工具也越來越多了，入門門檻也越來越低。況且，市面上還沒有哪款原型軟件能比得上用代碼直接寫出一個來。

5. 能夠更清晰地把握系統(tǒng)的現(xiàn)狀

工程師最討厭產(chǎn)品哪點？改需求、亂評估工期，還有就是：不懂重構(gòu)等技術(shù)調(diào)整對產(chǎn)品的意義，明明很重要的事情，卻一直分配不到優(yōu)先級。

這是產(chǎn)品經(jīng)理對技術(shù)的無知導致的。

隨著業(yè)務(wù)的增長，產(chǎn)品在后臺和運維層面都要經(jīng)過一些調(diào)整才能更好地支持業(yè)務(wù)發(fā)展，這些事情包括但不限于：制造開發(fā)工具以縮短開發(fā)流程、封裝固定的業(yè)務(wù)流程以增加復(fù)用性、購買更多的帶寬和服務(wù)器、優(yōu)化性能、重構(gòu)。

懂技術(shù)的產(chǎn)品經(jīng)理能對系統(tǒng)的現(xiàn)狀有一個大致的了解，并且在產(chǎn)品需要以上技術(shù)調(diào)整時，能夠提供合理的資源和優(yōu)先級支持，更能夠幫助統(tǒng)計和表達技術(shù)調(diào)整對業(yè)務(wù)的貢獻，避免讓有價值的事一直沉寂在后方。

說了那么多，最后有一個問題：產(chǎn)品經(jīng)理懂技術(shù)，意味著需要自己會開發(fā)嗎？

不。

不是因為產(chǎn)品經(jīng)理不應(yīng)該懂，而是因為今天的軟件開發(fā)是一個巨大的工程：前端、后臺、算法、運維等等，每一個環(huán)節(jié)單獨提出來都是一整個團隊的工作。沒有哪個產(chǎn)品經(jīng)理能夠搞定這一切。我們所需要做的，是理解研發(fā)，并且?guī)椭邪l(fā)做得更好，減少溝通成本、提升業(yè)務(wù)效益。

至于有些人說的「技術(shù)思維和產(chǎn)品思維難以轉(zhuǎn)換」，這只能說是能力問題。你看人家 ponyma，既是技術(shù)大牛，同時也能一秒鐘變小白用戶呢！

本文由@Lumi Ng ?公眾號：吳亮（lumiwu）授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理?，未經(jīng)許可，禁止轉(zhuǎn)載。

原文地址：http://lumiwu.com/blog/when-a-pm-know-about-dev/