產品經理懂技術的五大好處
1. 更豐富的產品設計工具
通常我們的產品設計工具有文檔、流程圖、交互設計。但其實還有更多更好用的工具等待我們去發掘。對技術思維的了解,能夠為產品經理提供更多更直觀的工具去進行設計。例如:
- UML類圖(不需要太精確)能夠替代名詞定義,釋清對象之間的聯系。
- 用例能夠幫忙厘清用戶需求,分解特性點,也能方便產品經理體驗 DEMO 和進行 sanity 測試。
- 時序圖能夠幫助產品經理整理子系統和外部系統的調用關系,估算成本、優化策略。
- 狀態機能夠讓關鍵對象的狀態以一種無比清晰的方式表達出來,讓整個項目的人一看就懂。
- 在面對稍微復雜的特性時,偽代碼能讓產品更好地與研發溝通,梳理并發現問題。
最重要的是,以上這些工具的學習成本都不高。
2. 對運算、通信、存儲等成本更加敏感
很多產品決策其實是商業決策,網絡通信是否快速、服務器能否HOLD住產品需要的計算能力,這些成本因素也可能決定著產品能否活下去。產品設計的策略可能對實現成本產生巨大的影響,產品經理需要懂得如何優化資源,用最聰明的方式去解決問題。
懂技術的產品,會對這些成本因素更加敏感。這樣的產品經理需要對網絡通信、數據結構和算法有一定的知識積累,甚至會進行時間復雜度和空間復雜度方面的估算。
其實,這些因素也會影響用戶體驗,特別是外部調用較多的場景。如何優化整個網絡請求的時序、如何平衡同步和異步的流程、如何通過交互設計隱藏由于技術限制而產生的體驗缺陷,這些決策都能大幅提高產品設計質量。我在做MIUI云名片,以及短信識別機票信息(在一個界面中使用了大量外部網絡請求)時,對這點的感受非常強烈。
3. 了解設計模式
基礎的設計模式,如工廠模式、單例、代理、適配器、觀察者模式等等,我認為是產品經理的必修課,非常實用。了解這些設計模式,讓我們能對產品的實現方式、難易程度和可擴展性有初步的估算。
然而設計模式這個主題更吸引我的,則是「N大設計原則」(有些地方描述為 S.O.L.I.D 五大原則,有些地方則是六大原則、七大原則、十大原則)。這些原則,甚至可以提升到哲學層面,為各種生活決策、個人管理提供指導性的意見,在產品設計上甚至還有豁然開朗的感覺。
DRY原則告訴我們:「Don’t Repeat Yourself.」
單一職責原則(SRP)說:「每一個類應該專注于做一件事情?!?/p>
依賴倒置原則說:「抽象不應該依賴細節,細節應該依賴抽象;即針對接口編程,不要針對實現編程。」
又如開閉原則(OCP):「Open for extension, Yet closed for Modification.」
而迪米特法則的那句「低耦合,高內聚」更是經典。
這些設計模式,都是經典。細細品味,妙趣橫生。熟悉代碼的應該比較好理解,不熟悉的建議找本書來研讀。初步了解可以看看這個網站。
4. 快速搭建原型的能力
研發資源總是緊缺的,而產品經理總想做新東西。掌握初級前端技術的產品即可快速搭建一個可用的原型,說不定這樣就能拿到投資了呢?
而且淺嘗前端技術也并不難,HTML+CSS已經可以搞定大部分場景了,iOS 和 Android 開發也并不難上手。而且現在的傻瓜式開發工具也越來越多了,入門門檻也越來越低。況且,市面上還沒有哪款原型軟件能比得上用代碼直接寫出一個來。
5. 能夠更清晰地把握系統的現狀
工程師最討厭產品哪點?改需求、亂評估工期,還有就是:不懂重構等技術調整對產品的意義,明明很重要的事情,卻一直分配不到優先級。
這是產品經理對技術的無知導致的。
隨著業務的增長,產品在后臺和運維層面都要經過一些調整才能更好地支持業務發展,這些事情包括但不限于:制造開發工具以縮短開發流程、封裝固定的業務流程以增加復用性、購買更多的帶寬和服務器、優化性能、重構。
懂技術的產品經理能對系統的現狀有一個大致的了解,并且在產品需要以上技術調整時,能夠提供合理的資源和優先級支持,更能夠幫助統計和表達技術調整對業務的貢獻,避免讓有價值的事一直沉寂在后方。
說了那么多,最后有一個問題:產品經理懂技術,意味著需要自己會開發嗎?
不。
不是因為產品經理不應該懂,而是因為今天的軟件開發是一個巨大的工程:前端、后臺、算法、運維等等,每一個環節單獨提出來都是一整個團隊的工作。沒有哪個產品經理能夠搞定這一切。我們所需要做的,是理解研發,并且幫助研發做得更好,減少溝通成本、提升業務效益。
至于有些人說的「技術思維和產品思維難以轉換」,這只能說是能力問題。你看人家 ponyma,既是技術大牛,同時也能一秒鐘變小白用戶呢!
本文由@Lumi Ng ?公眾號:吳亮(lumiwu)授權發布于人人都是產品經理?,未經許可,禁止轉載。
原文地址:http://lumiwu.com/blog/when-a-pm-know-about-dev/
- 目前還沒評論,等你發揮!