實在是不想寫開篇語了...
算了，還是寫吧，要不顯得文章沒頭沒尾很敷衍...
思考中：怎么寫能吸引引起大家的興趣，是大家讀下去呢...
算了，不玩套路了，直接來：產品和開發的日常撕逼，看似正常，其實可以避免，之前老K一直強調溝通能力的重要性，其實，最最根本的，是產品經理要有基本的自我修養。
下面，論產品經理的自我修養：
別YY需求
產品經理提出任何需求，原因一定不是，不是，不是：老板想要、運營需求、競品已有等等這類**的理由（老K曾在產品經理7神器——說服程序猿一文提出過說服程序猿的法寶，這明顯是用來搞笑的，聰明如你們，一定懂得吧）。任何需求，都要從產品目標&用戶需求兩個層面去考慮，首先找到充足的理由說服自己，然后再去說服技術。
舉個例子：比如理財產品都涉及綁定銀行卡這樣的功能，一般需要手動去輸入銀行卡號，體驗很差。所以PM提出優化方案：用拍照識別銀行卡來代替手動輸入。這個需求，從產品目標上講：符合產品科技金融的定位&簡化操作可以提高轉化和留存；從用戶需求上講，極大的優化了體驗，用的爽！
做好信息共享
很多PM在需求評審時只告知要做什么，而不說明為什么要做。是啊，程序猿負責實現功能就好了，說其他的有什么用？然，這種想法是絕對錯誤的，大家同屬一個Team，一定要讓每一個人都明確目標，同時也明確自己的努力可以向目標邁進一步。
而且，經驗豐富的程序猿會想到功能可能的延伸方向，提前做好可擴展性。
不要強行評估工作量
即使是技術出身的PM，也不要強行去評估工作量并確定工期。切記，專業的事兒交給專業的人去做。
盡量別改需求
對產品來說，改需求是一句話的事兒；對技術來說，改需求可能意味著代碼廢棄、框架重構...簡單說來就是通宵兩天寫的幾千行代碼沒用。。
所以，承接第1條，別YY需求，所有的需求都從產品目標&用戶需求的兩個層面去考慮周全，避免在開發的過程中改需求。
及時反饋結果
功能上線后，達成的效果要及時反饋給程序猿（挑好的說），雖然大部分程序猿并不關心運營指標，但自己的努力取得了很好的效果，他們還是很高興的。同時，也會建立程序猿對PM的信心，信任PM的眼光，由此形成良性循環，溝通上會更加順暢。
把握好"度"
前段時間看《我的前半生》，其中賀函對唐晶的一句話讓我印象很深刻：你學會了我的所有技能，唯獨欠缺的是把握一個"度"（具體臺詞忘了，大概這個意思...）。
其實很多同學都缺乏這個，怎么講呢，舉個簡單的例子：需求會后定好了上線時間，但是在測試過程中發現一個BUG影響很大，難以解決，怎么辦？逼開發通宵加班解決BUG？講道理你沒錯，確定好了時間就一定按照時間節點走，但這類難以預見的問題影響開發進度，該怎么辦呢？
所謂的把握好"度"，所謂的人情世故，大概這樣吧...
文章轉自產品經理日記微信公眾號，轉載文章僅供學習，感謝產品經理日記的分享。
