我靠！太牛逼了，寶貝兒，來~~~親一個

既能從產品層面去設計產品，讓商業產品無懈可擊，

又能從技術角度與研發溝通講需求，甚至了解研發所接觸的表結構、表欄位枚舉值。

甚至有一回，處理線上緊急事故，研發mm沒有頭緒，技術leader又不了解需求的時候，

能站出來用偽代碼描述出臨時處理的腳本邏輯。

"加個判斷條件，當foo等於bar的時候..."

"把所有foo1 &< bar1 且 foo2 &> bar2的所有帖子都修改下..."

"回調的時候，加個操作..."

並且，有時候研發忙不過來沒空幫忙修複線上問題的時候，能夠鑽產品漏洞人肉修復！

好吧，我是研發，但我描述的是最近對接的一個PM。他的思路清晰不亞於研發。

思考良久決定這個問題必須匿，不然得被那幫開花的傢伙們嘲笑死總之，技術小白羞愧表示，最擅長的是賣萌耍嗲戴高帽……不過我會努力學習這塊的1.問實現性什麼的，一般都是開場白先「我提個弱智問題哦，不許鄙視我」然後問某個東西什麼原理或者怎麼實現或者能不能搞定或者傳說中的方法靠不靠譜，然後反覆問「那我這樣那樣理解對不對？「」我的需求這樣那樣的是不是也差不多，還是有啥差別」，直到徹底弄明白為止，被嫌棄就被嫌棄好了，總比稀里糊塗的好。2.問時間進度什麼，一般都是「這個大概你啥時間能給個讓我可以實際用的版本嘛」，開發給完時間「那我某時某刻準點找你驗收哦」，如果開發給的戰線太長的話……一般就會戴高帽「太久了啦，我還以為要是你的話肯定能快很多天搞定的啦」或者激將法「XX你那麼nb也跟一般開發用的時間好像也差不多啊」或者動之以情「是不是需求什麼太多了，要不你跟我說哪塊花多少時間，我列出來優先順序，你盡量先局部完成就好，要是真的來不及我就砍需求」3.交互或者什麼有爭議，如果盤算著不難修改的話讓他們自己去試試好了，如果麻煩的話就反覆拷問你這個傢伙到底想的是什麼啊，是真的覺得用戶體驗出了問題還是從技術角度覺得實現太麻煩或者不靠譜，審問出來就好解決了，體驗出問題的話如果我沒想清楚我錯我就改，但如果我已經考慮到這塊必須做出相應的設計那就把考慮過的問題告訴技術就好啦。如果是他們覺得技術上有問題，覺得成本高我就問成本到底是多少，不值得的那就算了，值得的話就告訴他們為啥值得；覺得技術上不科學就問原理是怎麼回事，不問明白不罷休，問明白了就可以給很靠譜的答覆。

4.要有保護技術同學們的決心和勇氣，下的每一個需求都要慎重仔細考慮過，修改也要慎重仔細考慮過，自己先對自己提的需求把好關，然後如果有boss摻和進來改需求要先擋住，跟boss說清楚想法和考慮，自己的需求是很慎重才下的，希望boss也能慎重後再修改。總之誰敢欺負我家的技術或者UI哪怕是我頂頭上司我也跟他拼了

懂技術，只要你懂技術，一個眼神足以~

用藍湖產品設計協作平台解決所有的溝通問題。

把技術當做真正的朋友。

另外這一點也不得意，能用上「得意」這個字眼說明題主還太年輕。

每個需求和功能，在需求評審的時候，都會和研發團隊溝通需求及功能的出發點和要達到的目標，一定程度上能讓研發團隊在研發過程中，站在用戶角度想問題。而且遇到技術問題時，對方知道我們的目標是什麼，會自己給出能達成目標的 B Plan。

當然最重要的，是在功能上線後，把真實的效果，用戶反饋及數據分析結果，也及時反饋給相關研發同事。

爸爸們真是太牛逼了！下次保證不改需求

我是純粹不太懂技術，不過也想混進他們的圈子，一些常見的術語還是要懂些，比較好
懂點技術
推薦閱讀：
相关文章