中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

產品在日常工作中，需要與開發進行溝通交流，在產品協作過程中，總會遇到一些問題與摩擦，面對這些問題，產品人員該如何應對比較合適？作者分享了一些他的看法，希望對你有所幫助。

今天重溫了一下老書，一時間入了迷。想起了當初第一次看這本書時候我的狀態，想起了我工作快兩年來遇到的一些問題。有感而發，臨時想寫一篇文章來記錄一下，記一下我對產品工作的認識以及產研之間矛盾的看法。

一、先來簡單說說我認可的產品和產品經理的定義

1. 什么是產品？

解決某類需求的商品或者服務。說白了，就是可以滿足需求的載體。

比如滿足你刷牙需求的牙刷，出行需求的共享單車，外賣需求的餓了嗎等等。這些從虛擬到實體都可以統稱為產品。

2. 什么是產品經理？

俞軍說：企業通過“產品”這個關鍵媒介，以創造“用戶價值” 的方式，有選擇地和用戶進行價值交換。

那么企業需要的這個媒介的創造者就可以稱為產品經理。

舉個不是很恰當的例子，如果現在大家洗澡洗的不爽，洗不干凈。這個需求被某個人或者某個企業發現了，那么負責解決洗澡洗不干凈的人就是產品經理。

• 也許這個企業會有個部門，一些人創造出了肥皂，用戶洗澡的時候用肥皂就能比之前洗的更干凈。那么這個部門也許會叫做產品部，這群人就叫產品經理（肥皂這個商品）。
• 也許這個企業有個部門，一些人發現搓背這個行為能有效的解決洗不干凈的問題，于是制定了一套搓背服務流程，搓完比不搓洗的更干凈。那么這群創造這個服務的人就叫產品經理（搓澡這個服務）。

其實產品經理也就是創造“肥皂”，發現“搓背”服務的人。無非是這個肥皂可能叫做滴滴，這個服務可能叫做出行?；蛘呤墙凶雒缊F/外賣，微信/社交。

二、為什么需要我們這些“產品”？

聽起來這個崗位好像也沒有很高的門檻，沒有很高的標準，那為什么有著較高專業知識門檻的研發不能順便“兼顧”一下看似輕巧的產品經理的工作呢？

個人理解，在以下的幾個方面的差異導致產品工作需要精心對待而不是隨意應付：

1. 崗位定義的不同

這個在各個求職軟件上的招聘要求都有，五花八門，總的來說產品處于信息的上游，研發處于信息的下游。一個負責設計，一個負責實施。在同一條河里，但是不在同一條船上。我簡單總結了一下。

pm：負責發現/收集/創造和定義需求，將需求通過具體的產品功能設計呈現為用戶可用的產品。

研發：從技術角度評估產品方案，設計技術方案，最終將產品設計實施落地為用戶可用的產品。

2. 崗位考核的不同

產品崗位的考核其實很清晰，與崗位最初賦予你的責任其實是對應的。能否高效準確的將各方需求轉化為產品需求，然后將需求轉化為產品方案，并確保產品方案順利落地并實施。簡單來說就是：把產品搞好。

簡單提一嘴，我覺得把產品搞好我覺得有幾個關鍵節點。

1. 需求的收集與反饋：作為需求的第一承接人，所有需求需要記錄下來。將需求的關鍵屬性諸如場景，提交人，緊急程度等等記錄。然后這些需求的狀態變更（如從需求池到產品設計階段，如進入研發階段，上線時間已定等等），及時通知關聯人員。避免出現大家會經常來問 需求怎么樣了到哪一步了上線了嗎 此類信息不對稱問題。
2. 產品方案的高質量設計：這個無需贅述，產品最需要做好的工作。
3. 版本的穩定上線：通常每個上線任務都有deadline，不要交給研發之后就不聞不問了，要常常跟一下進度，做到心中有數。如果有任何意外，需要及時調整時間和通知上級。
4. 上線后的持續跟進：上線不是終點！上線不是終點！上線不是終點！重要的話說三遍，在此我想引用一下丘吉爾的”The End of the Beginning”演講上的一句話來表達觀點：“ 這不是結束，甚至不是結束的開始，而可能只是開始的結束。”

pm：承接好各方需求，并準確高效的轉化成產品方案并推進落地。

研發：在緊迫的時間內優質的完成產品方案的落地。

3. 思維的不同

因為崗位的定義和考核不同，所以決定了思維大概率就會不同。梁寧說過，我們都活在角色里，被角色馴化。角色化的人在思維上自然也會變化，所以大家和人打交道的時候可以很明顯的看到這個人角色化的痕跡。我們來分析下產研兩個角色上的思維差別。

我們把研發的思維叫做“工程思維”，工程思維往往是理性的邏輯思維，從實現的難易程度和系統的角度去定義產品和設計產品。

這么做有一個比較大的弊端，就是容易脫離實際。這個實際不是說的技術實際，而是需求和實際場景。研發拿到需求時，第一時間考慮技術方案和架構。這沒有什么不對，但是換個角度看，一個需求的價值不在于實現時的技術和難易程度，而在于有沒有為用戶解決問題。

產品經理的思維叫做“產品思維”，產品思維是一種結合工程思維，功能思維和商業思維的綜合思維模式，包含對商業目標，目標用戶和用戶場景的理解。

我們來舉個例子，“在這個河上建一座橋”，聽到這句話的時候，這兩個思維會如何進行思考呢？

• 工程思維：建什么橋，水泥橋還是石橋，水流湍急程度，什么時候完工….
• 產品思維：建這座橋是為了做什么？需求方是誰？預計帶來的商業價值有哪些？現在需求方是如何進行操作的（劃船？），頻率是多少…..

pm：產品思維

研發：工程思維

三、想象一下沒有產品經理的世界

首先，有產品就必然代表有需求。這個需求大概率是直接由用戶提出來的，不加思考的需求（很少有用戶能夠清晰地描述自己的需求。直接問他們使用產品的感受，大都傾向于關注產品的次要功能或者彌補缺陷的小竅門）。

這些未經思考，過濾，篩選的需求通常和用戶真正期望的需求關系不大。再簡單將這些需求轉化成產品隊列，然后期望用復雜技術編配優雅產品出來其實是不切實際的。

開發人員會直接決定構造產品的過程，也決定構造什么樣的產品。但是開發人員的任務訴求與產品最終用戶的訴求很大可能完全不同。且矛盾的地方在于優秀的開發人員關注的是解決技術難題帶來的挑戰、如期完成任務。

他們收到的信息往往不完整、缺乏遠見、有時甚至相互矛盾，還要在極為緊迫的時間內且不了解人們將如何使用產品的情況下，被迫做出事關用戶體驗的重要決定。

因此，最直接負責創造產品的人員如果很少考慮或者沒有時間和精力去考慮到真實用戶的目標、需求或動機，那么產品大概率是失敗的（你應該想象面對刺猬形或者圓形的還洗不干凈的肥皂和面對搓背體驗很差的師傅是什么樣的感受）。

歸根結底問題很簡單。人無法每次都戰勝人性，選擇那條更“艱難而準確”的道路。

一個產品的實現和設計之間必然存在沖突。研發會經常在易于編程和易于使用之間做選擇，但是考核他們的卻是編程效率和能否在緊張時間內完成編程任務，你就可以預見產品的最終模樣了。正如在法庭上我們絕不能讓原告來裁定案件一樣，產品也應該確保設計師和開發人員不是同一批人。即使程序員有足夠的設計能力和設計意愿，也無法有效地兼顧用戶、商業及技術各方利益。

四、該如何與研發相處

研發和產品不是同一批人，甚至思維方式都截然不同。但是都是為同一個目標去努力的，研發和產品是無法完全切割開來的。

舉個例子：在宣講時不能只講最終方案不講需求場景。雖然兩個崗位職責不同，但是大家是同一個團隊，都是圍繞著需求，功能，產品來進行展開工作。了解整個通路對協同有很大幫助。

在講解產品設計時講一下這個產品的 需求場景 等上游信息，其實對開展工作也是有比較多的幫助。

1. 其一：研發會有參與感和被信任感，他會覺得這個產品方案我也有提供一些建議，也有貢獻。誰都希望自己的建議能夠被采納，自己有足夠的存在感。這對研發同學“快樂”的寫代碼可能也會有幫助～。
2. 其二：研發如果用工程思維考量你的方案時候，也可以基于你表述的場景給一些建議，而這些建議往往就會產生意想不到的效果。

最后給一些正在承受“與研發針鋒相對的關系”新人產品經理幾個小tips。

• 我們雖然有著“經理頭銜”，但我們只能管理自己。
• 和研發的溝通要虛心，弱小和無知不是“被懟”的那個point，傲慢才是。
• 價值的傳遞。站在他人角度考慮。認同他們的付出，經常同步他們產品上線后的結果，包括數據結果、用戶反饋、使用感受等等都可以，讓他們覺得在做有意義的事情。

五、寫在最后

在我的產品生涯不長，但和研發battle的次數卻不少。

在爭的面紅耳赤的時候，在會議結束自己一個人坐在空無一人會議室的旋轉椅上的時候，在夜晚默默參照會議記錄修改產品方案的時候，我時常問我自己：這樣子有價值嗎，有存在的意義嗎？

這些在后來的過程里都有了答案，我既知道了“君子和而不同”，也知道了只要你期待你的產品能給公司帶來效益，能給用戶更好的使用體驗，能給世界多一份美好。那么你正在從事的，堅持的東西就是有價值的。

且不論過程是怎么樣的艱難。但行好事，莫問前程，不忘初心。堅持那顆做好產品的心吧，把自己的價值打包成產品交付給世界，那世界就會給你一個happy ending。