文章背景，來自於群內周五晚上的一次頭腦風暴式的思維碰撞交流活動。活動主題由
無痕哥發起。文章版權屬於群內發過言的任何一位同學，我只是做了簡單的梳理或整理。
1. 技術人員了解產品這個崗位所需要做的事情，然後試著從產品的角度出發，考慮當前頁面功能的真實需求，挖掘更深層的可擴充套件需求，從而在另乙個方面去引導產品。
比如：乙個註冊頁面，當前產品想到的是乙個普通的使用者註冊，但是在整個的平台中，可能還有vip邀請註冊，這時候可以試著想兩個能不能合在一起，如果不能合在一起，就要分別處理。
2. 有的公司沒有專門的產品，則有專案經理兼任。但如果專案經理不懂技術，且在職權範圍內有決策權，這個就比較難溝通。
這樣可能導致的情況是：從產品看，提出的需求確實可以使使用者體驗更好，但是做起來就要很多時間，專案週期就要拉長。
這種問題，個人感覺：應該從全域性考慮，做某個模組或欄目內容是充分的給專案經理講清開發周期，所需要的人員配置，然後複雜的他就妥協了。
因為專案經理只是單純的提了乙個產品需求，他並不能充分的了解開發的週期，所需的人員，以及開發完，到測試回溯完的時間段。
一句話，他並不真正的清楚做這個需求的成本，了解這個成本之後，果斷的妥協了。
他可以選擇不信任，但要委婉的可以建議他找另外組相關人員重新評估這個時間。
這個環節最主要還是詳細的溝通，耐心的站在對方的角度來考慮問題。
當然還有一種情況，如果雙方都堅持自己的觀點，不能妥協，這需要上報更高階別的上級，進行更高階別的評審。
簡單說，需要老大來拍板，這時候問題就簡單了，把球t出去。
樂觀的估計，如果專案經理或產品覺得你說的有理他還是會接受的，首先要用自己的專業見解與產品溝通，達不成共識說明你的觀點沒有專業性。
當然這個建立在紮實的技術功底或豐富的行業經驗上面。
最後一點建議：乙個產品的立項到設計開發測試上線，其實週期是挺長的，樂觀的自以為的壓縮開發周期，
以為技術是簡單的，以為平常看到的就是乙個開發的結果，忽略了開發背後所做的種種勞動。
主觀的認為開發是不耗時間的，然後就是時間還很緊張。這樣就需要更多的技巧，更多的溝通策略來達到目標的一致。
這只是一種極端的情況，有的產品剛入行或沒有經驗，固執的以為，他代表著使用者，假想自己是使用者。
並沒有真正的站在使用者的角度，也沒有在全域性的角度來考慮問題，忽略了公司成本的重要性，以乙個一項情願達目的的想法做事，就會拖垮眾人，
這時候如果沒有乙個真正的專案把控者出現，就會讓專案走入誤區。
3. 不同公司不一樣的，技術驅動還是產品驅動甚至商業驅動的公司氛圍都不一樣
產品驅動的公司產品非常強勢，說啥就是啥，你說不行啊，按你那麼做時間會很長的，他們笑眯眯得說沒關係。然後某個週末leader問，產品現在什麼進度？他們就開始添油加醋了。
這種情況個人的建議是所有的溝通要以會議的形式正式的溝通，會後有專門的一致郵件發給相關人員，並抄送給相關leader。
避免被動情況的產生。
4. 產品上線後，後期的維護成本，新需求的產生，如何應對？
產品上線後，後續的維護同樣重要，使用者使用一段時間後，提出自己的想法。
這個時候就可以更新乙個新的版本，把一些新的建議或想法加進去。
這就完全是拼經驗的，改的多了，在寫**的時候就已經做好的預防修改的介面或**容錯性。
一般有個不成文的規定，就是寫過的東西再寫的時候時間縮減
乙個產品/專案經理需求改的太多，然後開發人員一天備份乙個，後果就是拖慢了開發周期，造到更高層的責備，然後開發悄悄的閃了。
然後在新補乙個人進來的週期是1-3個月，對整個團隊或產品造成了不可估量的損失。
5. 老是在前端這個層面來修改東西，修改完了在去讓領導抉擇，選擇。
其實這是乙個真正流程上的失誤，在產品出原型稿的時候，就需要評審一次。就算沒有原型稿，在設計出高保真效果圖的時候，再需要評審。
這樣做的目的不就是早期把一些視角上的問題消化掉。
如果出現讓前端修改效果來大面積的達到需求，這時候需要完整的設計效果圖，否則後期沒辦法收尾。
這樣也方便測試統一做回滾測試。
當然這需要靈活有一些簡單的東西，可以直接吃掉。
最後總結收尾，引用自下面**：
產品經理需要擁有很高的產品設計、使用者體驗感知能力，這裡所說的產品設計和體驗感知都必須圍繞公司戰略和產品方向進行展開，初級產品經理最容易犯的錯誤是把太多的時間摳在產品的設計細節上。說具體些，就是把產品的互動設計和ui設計看的太重，幾乎大部分的時間都花在axure原型圖的設計上了，而忽視了理解鑽研公司戰略、產品方向、以及產品本身應該重點考慮的地方。在很多產品相關的**和部落格，你會發現討論和分享的絕大多數都是圍繞體驗和互動設計相關的內容，這個怪像容易讓初級產品經理陷入泥潭，會造成產品整體感覺喪失。產品經理需要具備產品的整體嗅覺，需要具備站在高度對產品有全域性的把握能力，任何不站在整體生態、產品方向和公司戰略下討論體驗設計都是耍流氓。
本文**豪情部落格，
產品經理如何在技術人員面前更有說服力？
以我7年來做pm 產品經理 的經驗來看，說服他人，特別是研發 設計 前端這些研發部門的同事，最重要的不是口才 溝通能力和資料，而是專業。專業就是 第一，你要用內行的思維方式 表達方式和處理方式來思考 溝通和執行 第二，你要經常可以做出正確的決定。乙個人要先相信你能說出正確的話，才有可能認真去聽你說的...
技術人員如何看待新技術？
最近參加了新平台專案的技術評審，看到專案組演示iphone上的客戶端版本，看上去還很炫的樣子。做得挺好的，技術人員也是新招的乙個高手。說實話，作為技術人員出生的我，對於新興的技術，只能遠觀，而不可以褻玩焉，真是有點不是滋味。為什麼我沒有成為這方面的專家？為什麼別人可以，我卻不可以？就感覺是乙個武林人...
技術人員如何創業《一》 產品及想法
不得不說這是個浮躁的社會，人人在這個社會都想暴富或者成名。在這些引誘的驅使下很多人都脫離了原來的穩定工作創業。前幾天看了 中國合夥人 故事講到了幾個大學生從校園到工作 再到創辦了乙個偉大的企業，這個故事更加激勵了創業大軍的壯大。大家都想創業，那我們技術人員怎麼創業？也就個人的經驗分享一下 1 好的想...