??
Mò ?ji墨嘰第10聚
@申悅
1年開發,5年產品,歷任中興研發,網易、e代駕高級產品經理,現任某演藝服務公司產品總監。
擁有通信設備制造、云計算、移動互聯網、O2O行業經驗。寫的了代碼,做的了交互,出的了視覺,帶的了團隊。
曾獨立負責億級用戶量產品的大數據后臺設計,擅長邏輯化、系統化解決問題,業余愛好翻譯國外優秀產品設計文章。
? 該教PM們學技術了 ?
產品如何手撕技術指南---產品人的技術修養

今天分享的話題是產品人的技術修養。用這個主題是因為我個人有過開發經驗然后對開發本身很感興趣。我最開始做的事信息系統之類的產品,這一類產品需要很強的技術背景現在我主要是負責一款app的產品。不僅是有處理后臺經驗,還有做客戶端前臺的心得。

產品對技術都是在做產品過程中遇到的一種場景就是我們想讓開發區實現一款產品,在實現的過程中也會對產品提出一些意見,就會出現以下的對話。

以上的這些對話開發以及聽的很多了,最后他會有什么反應呢。

網上有一個經典的對聯:
上聯:這個其實很簡單
下聯:原理細節我不管
橫批:明天上線
開發工作的評估開發工作量是交給技術經理或者技術自己評估的,但產品經理不知道評估是否是正確的。

一般面對這個問題會有兩派的爭論,正方和反方。

如果我們懂技術就能考慮產品有哪些功能的時候就能自己確定是否可以實現,成本有多大等等,更好的情況就是我們自己上手折騰。
而缺點是容易忘記自己是不是應該思考功能本身,也就是說這個功能應不應該做,做成什么樣,應該在什么時候來完成,這些才是產品經理應該思考的東西。
同事呢,太糾結于技術本身容易忍不住說出自己的技術方案說出來,摻和到團隊成員的專業領域,其實你懂的很多東西都是皮毛,但是你輕易的去和他們討論,很容易被他們鄙視。把自己太多的東西投入技術,很容易分散自己的精力。
我個人的觀點:產品本身是需要技術的,但是不要鉆研太深,只需要有技術的意識就可以了。

我們需要知道的不是產品的技術實現,而是了解到導致整個開發和PK這個問題背后的原因是什么?那么其實很簡單,就是溝通不順暢。
我們要明白學習技術的目的,不是要去開發這些需求,也不要去碼代碼。而是明白技術能夠做什么,能夠在功能的實現可行性做取舍。理解開發說的話,站在他們的角度上思考問題。
這是我列的一個金字塔模型

從了解技術的層次來看,最基本的我們根本不需要了解代碼本身,我們只需要把自己的產品邏輯數清楚。同時把產品相關的概念進行抽象畫去處理,這樣至少能夠在邏輯實現和別人站在同一水平線。
如果我們已經有了一定的基礎知識,通過一些手段能讓開發瞬間理解。在這個基礎上我們能跟進一步去提出解決方案或者能提出開發可能會遇到的困難,發現一些開發沒有注意到的一些技術細節,這樣會更好。
如果能夠做到這一點,甚至能夠做到和開發討論具體實現細節,那你基本就是大牛級別了。
點到為止,一切從產品出發:無論理解技術有多深,都應該點到為止,不要糾結于技術本身,而是從產品出發。
底層:如何清晰的梳理業務邏輯!

希望大家能掌握兩個維度的能力。第一個就是產品自身的業務邏輯,這和開發沒有直接的關系,而是我們要清楚的自己的產品應該實現什么樣的功能以及可能需要經歷哪些步驟。
從根上來說就是根據每一個產品的不同使用場景和具體的流程來梳理產品的一個業務邏輯。
比如說電商導購的話他要處理的就是電商的購物流通;如果是內容管理系統的產品,無論是前臺和后臺要梳理的是每一步的一個狀態流,包括內容中按鈕是否開啟,你的內容是否被轉發,點贊或者評論,那么在點贊轉發過程中又會觸發系統什么樣的其他行為。
舉個例子,下面是我在設計過程中的業務流程:

我現在是做的一款藝人經紀找工作的產品,這里面詳細的梳理出來一個人報名一個通道需要哪些業務流;發布通告在接收到藝人的報名之后應該要觸發什么動作。
在我們熟悉自身的業務邏輯之后如果能夠熟悉一些常見的技術功能的實現邏輯的話那就更好了。這里我總結出的常見的業務邏輯:
數據采集邏輯:
如果需要采集產品的基本數據,需要知道通過app的什么樣的點擊操作,把這些操作手機起來,讓服務器記住你的這個數據,并且咱后臺顯示出來。
推送邏輯:
在收到push的時候,我們的服務器端是如何進行底層的交互的。那么業內的實現方案是怎么樣的,比如常鏈接的方式是怎么樣子的以及安卓和ios在這些邏輯上的區別。
數據展示邏輯:
至少知道app在收到數據之后進一步解析出現在我們面前的。包括頁面的布局,刷新。
數據的存儲邏輯:
了解服務端和客戶端的數據存儲以及關于存儲數據的模式。
下一層:
在懂得技術術語的情況下和開發有效的溝通。
從三個方面訓練自己

1 基本術語的理解。列舉幾個開發過程中的術語;
2 除了基本屬于之外,還要了解開發人員之前所說的黑話;
3 怎么能夠幫開發躲坑。

但是無論你都了解很多東西,但是還是會和開發爭論。
當開發和質疑時你需要冷靜,心平氣和。之后就要討論問題,理清產品邏輯找到問題所在,很多時候開發會找你理論一方面開發沒有理解產品設計的思路,另一方面就是他自己針對這個產品有自己的看法。在這里推薦使用場景話的方法解釋。
場景化的方式:
讓開發從用戶的場景使用這個產品,思考這個功能。如果能讓他順著你的思路在這個場景下完成這個產品的邏輯,那你基本就贏了。
有些時候我們用什么方法解釋對方都會堅持自己的看法,建議就不要爭論下去了,無非就是先有蛋現有雞的問題,這時候就要先暫停,回去想好再進一步溝通。
這里并不是讓大家一味的妥協,對于一些原則性的問題是不能退讓的,還有一些基本產品設計邏輯。

如果以上的方法都不管用的話,終極大招就是找開發的老大,但是前提是你需要有充足的產品設計理由。
無論是用什么方法說服對方,一定要注意話術,對事不對人,避免人身攻擊。

如何培養技術感,這里給大家一些建議。

興趣:興趣是最好的老師。對于我自己而言呢,我是很享受自己寫的代碼,被運行被實現。
找幾本書籍看,這里推薦O‘Reilly深入淺出系列——Head First。最后就是實踐,自己親自敲代碼,感受開發的想法。

就是希望天下猿汪是一家

Q&A提問環節
問題一:
今天提到的這些技術細節需要體現在需求文檔里嗎?如果需要的話 應當怎樣體現?
申悅:
我可以給大家看看我平時做產品原型的方案。

這張圖是我當時做的一個社交產品。
我一般不會做需求文檔,我直接把所有的需求列在原型上,但是我會做一個比較明確的說明。
問題二:
能否分享一下對于項目時間是如何把控的?
申悅:
做一個產品功能進度表,每天都會更新,并且標注出不同團隊的開發進度;同時需要隨時溝通。

問題三:
您說入門的資料慎重選擇,您能推薦一些技術高品質的入門書籍和視頻嗎?
申悅:
入門書籍的話就是剛才提到的《O‘Reilly深入淺出系列——Head First》
視頻教學的話推薦:designcode(https://designcode.io/)【這是當初學swift和sketch看的視頻】
問題四:
請問如何對整個項目把控,web H5,移動端,是一個個開發還是同步進行呢?
申悅:
可以同步進行,對于功能點的話,有的是要有a 才能有b,只能一個個做,但是也有同步進行的。這需要具體問題具體分析。
問題五:
從技術轉產品有一些什么心得體會可以分享么?
申悅:
最大的問題從用戶體驗考慮問題,而不是從技術考慮。我認為國外的資料比較全,我花了兩個月去翻譯ui設計模式的網站,有興趣可以去看我的博客(http://s2dongman.com)。多看多理解多分析。
問題六:
剛入行的產品經理如何和程序猿溝通,需要準備哪些知識儲備嘛?從哪的地方找?
申悅:
具體要看你做哪個行業的,不同的方向做產品需要溝通的點是不一樣的。做app的就需要知道交互或者功能的實現邏輯,做后臺的就要知道數據的存儲結構等等。看一下知乎或者簡書,如果需要深入的話需要看一些書籍。
