我是產品經理我需不需要學技術?

1 評論 13286 瀏覽 12 收藏 9 分鐘

我是產品經理我需不需要學技術?

這個問題我已經聽過很多遍了。作為一個技術出身的產品經理,我的意見是,需要學,但很可能不是你所想的那種學法。

PM為什么要學技術?

科學技術是第一生產力,而現在這個生產力正在移動互聯網、云計算、3D打印和物聯網等領域飛速發展。這意味著誰先將它轉化為產品,誰就能突破現有的用戶體驗,在這個體驗至上的產品領域中占領頭籌??梢杂脕碓裔斪拥拇笮尚善聊蛔屖謾C用戶不用再擔心屏幕被劃傷,更可能從根源上干掉手機貼膜這個產業??梢噪S身佩戴的Google Glass即將帶來AR(增強現實)技術的全新體驗,并在游戲、社交和工具領域開辟出一個全新的產業鏈。而不懂AR只懂PR的你,肯定不可能在第一時間做出最新的產品。

再回過頭來想想PM和RD的溝通。為什么在你眼里很簡單的東西,RD就是說不能實現?他是在忽悠你嗎?為什么一個簡單的功能,RD評估出來要開發3個月?有辦法改進嗎?

所以,不管是為了能緊跟技術發展潮流帶給用戶更NB的體驗還是為了和RD溝通時不被當猴子或者外星人,PM都是需要懂技術的。

那么PM怎么學技術?

對于RD來講,學習技術是一件很簡單的事情,找到相關的技術資料,搭建好相應的開發環境,編碼、測試、改進,再編碼、再測試、再改進……

但是對于PM來講,學技術是一個很艱巨的任務。不是說PM都比RD笨,而是RD通常只需要精通一門技術即可;而只要項目要用到的技術,都屬于PM要懂的范圍。要想都精通它們,一般人很難做到。

其實當剛開始負責微盤項目的產品的時候,我曾嘗試著去學iOS開發,后來因為各種原因半途而廢(《30天精通iOS開發》什么的完全是騙人的哇!o>_<o )。但我發現雖然我只讀完了iOS開發的概要說明部分,并不清楚移動開發的細節,我也能很好的管理技術團隊、和我們RD的同學有效的溝通。后來再接觸到新技術時,我也開始用類似的方式去處理,發現效果很好。

這個學習技術的方法總結起來就是:忽視技術細節,關注技術的 原理、邊界和成本。

下邊我詳細說明下。

原理

好的產品經理需要保持對事物的好奇感,看到一個新東西,第一反應就是它是怎么做出來的。比如Nexus4采用了無線充電技術,那么你想過它的原理么?“快傳”這個手機應用可以不通過網絡傳輸文件,你去分析過它采用了什么方式么?當你在瀏覽器地址欄輸入一個網址,敲擊回車后,網站內容是如何顯示到你屏幕上的?

了解原理的成本其實比想象的低,通常認真的閱讀完一個Wiki頁面就可以。一些技術細節可以略過,因為我們的目的是建立整體概念,從而理解技術常識。當你了解了網站的工作原理后,你就會理解為什么你電腦上的圖片要放到服務器上其他人才能看見。

但是有一類技術細節是產品經理們要額外注意的,那就是“邊界”。

邊界

我把影響可實現性的技術細節稱為邊界。這些細節制約著產品的實現,無論你擁有多好的技術人員都無法逾越。 一個典型的邊界例子是早期iOS中應用本身存儲的數據只有自己能訪問(越獄的不算),這在產品層面的影響是,這導致了微盤iOS版本開發了自己的文件閱讀、視頻播放功能。邊界是把雙刃劍,一方面,邊界制約了產品;而另一方面,一旦你穿越了邊界,就能在這個領域里邊領先。

穿越邊界很常見,一種方式是通過產品設計或者其他技術方案繞過邊界;另一種更常見的方式是,觀測邊界的松動,并及時更新產品。大部分的非安全類邊界都會松動,并定期更新。比如早期Flash對3D的支持很差,這導致純3D游戲很難在瀏覽器上運行,而最新的Flash版本已經支持3D渲染,甚至可以啟動GPU處理。在我用PhoneGap做HTML5動畫效果時,發現Android系統沒有對Canvas做硬件加速,導致產品卡得沒法用,這其實也是一個邊界。而APPCAN就抓住了這個邊界,和微游戲推出了支持Canvas加速的SDK。

即使對于技術人員來講,邊界也是非常重要的東西。以前我一般都悄悄的記錄到QQ郵箱的筆記本里邊,以后我會嘗試著在方糖氣球的微信中推送最新松動的邊界信息。:)

成本

對PM來講,成本更多表現為開發時間。這本來是屬于技術經理的活,不過產品經理需要對這些有常識。你要是拿著一個Path去和RD講:“這東西這么簡單,一周時間夠了吧?” 被人家咬就不要問什么了。一般熟悉產品開發流程后,對產品開發時間的評估就能有概念了,這個是體力活,多和RD溝通,跟幾輪就清楚了。但有部分技術細節會影響開發時間,包括兩類,細節黑洞和開源黑洞。

細節黑洞

細節黑洞是指一些吞噬時間的細節。比如說拖放效果。對于大部分開發者來講,標準的拖拽效果很簡單,因為JQuery(一個開源JavaScript庫)有很多組件可以直接重用;但如果需要對這個拖放進行定制,那么只有認真讀過拖拽實現的程序員才能做好。在開發第一個可用版本的時候,PM要放棄一切可能成為黑洞的細節;即使在后期的版本迭代中,也要把可能成為黑洞的細節放到最后來做。

開源黑洞

開源是個好東西,一個好的開源項目可以幫你節省大量的開發時間。但是對包含不熟悉的開源項目的情況,一定要讓RD認真評估。我經歷過的因為開源方案不成熟、不滿足某個細節需求最后改為自行開發的例子已經不下3個了。不是說開源不好,而是不要把它想太好,就像魯迅對中國人一樣,要以最壞的情況去估算成本。

當然了,新技術也會帶來成本的降低。比如最近正在飛速成長的PhoneGap技術,它通過把HTML5直接打包到各個移動平臺,實現了一次開發多平臺運行。我個人正在開發的團隊協同工具TeamToy2就采用這種技術,雖然各種小坑不斷,整體成本上還是非常給力的。要知道這種所有東西就一個人的項目要是采用原來的方案同時開發iOS+Android客戶端+Web版+Mac客戶端根本就是不可能的任務。

小結

OK,最后我們小結下:產品經理需要懂技術,但是不可能對所有技術都精通;所以產品經理要學會忽視細節,去了解產品用到的技術的原理和本質;重點留意一些特殊的技術細節,比如影響可能性的邊界、影響開發時間的黑洞

PPT下載地址:請訪問微盤預覽和下載。

來源:http://ftqq.com

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 厲害了!

    來自廣東 回復