說說最近發生的一些事情
近日 某網際網路公司就因為 '主題顏色隨手機殼顏色變化'而發生了一次吵架事件，後來都被開除了！
作為一名程式設計師，大家都知道，產品經理是需要經常與研發人員打交道的一個職業，他們也有一定的技術常識，有相當一部分產品經理都曾經是程式設計師，他們也開發過很多優秀的產品，後來由於自己的職業規劃就轉產品經理了，因此這部分人與程式設計師溝通起來也是相當輕鬆的，當然也有一部分產品經理直接就是從產品經理做起，沒有一定的技術基礎，他們設計出的產品更多從使用者角度出發，不會過多的去考慮技術實現的問題，最近就有這麼一個網際網路公司的產品經理提出了一個牛逼的需求，把程式設計師們難倒了！
後來看谷歌最近也出了這麼一個設計，如圖6所示，我估計產品經理應該要的是這種效果，另外查資料得知堅果手機，一加手機，還有三星s8都有這個功能，雖然並沒什麼卵用！
發生這種情況，也是我們不希望看到的。作為一個程式設計師，我知道，根據我之前開發過的相似的功能特徵，我可以估計出現在的這些功能特徵各自要多少開發時間。然後，我把總時間加起來，這就得到了完成整個專案需要的大致時間。然而，事實情況中，每個專案在開發過程中都遇到二、三個瓶頸。這些瓶頸會肆意的消耗程式設計師的大量時間，你在遇到它們之前根本不會有所預見。它們會拖住整個專案，致使工期延後數週甚至數月。
這些是沒有經驗的人在評估複雜度時不會理解的。他們不明白在其他事情上都很靈的方法，為什麼放到軟體開發上就不靈了。所以，下一次當你聽到有人說“我想你幾天時間就能把它開發出來”時，不管是誰說的，都不要懊惱。深呼吸一下，告訴他這篇文章的地址，《不懂技術的人不要對懂技術的人說這很容易實現》自己該幹什麼還幹什麼。
對於產品來說
產品提出的需求，一定要是經過需求評審會的，符合實際的一些場景的。 往往一些看似很簡單的需求，實際上會遇到很多坑。
提需求要有節奏感。不要誤會，這個節奏感不是啪啪啪的節奏感，而是說你提的需求，要跟著專案的版本週期和實際應用場景走。
需求的來源
老闆提出的戰略方向的需求：老闆會站在戰略層的事務，在確定了產品的方向之後，他會對產品的樣子有個大致的想象，有些功能是必須要有的，這時候，他會和大家討論哪些需求建議加上去。
一、談需求前，先明確問題是什麼
問題”不是“我要一個…功能”，而是“我在做…時，為了達到…的目的，需要通過產品完成”。
二、說需求時，先別討論解決方案
三、聊需求後，明確邊界和優先順序
學會拒絕不合理需求，學會正確溝通需求，這是作為一個產品經理最基本的責任；
就像阿偉大佬說的那樣，一定要開需求評審會，拿出原型圖，設計圖，或者一些參考資料，讓大家討論一下，儘量提讓大家接受範圍之內的合理的需求。不要盲目給開發者開一些腦洞大開的自以為是的“神創意”！也許你無意中的一句話就被打了還不知道怎麼回事。
對於程式開發者來說
1、開發人員有質疑這個需求不合理不合理的建議
（這裡切記不要說這是xxx的需求，我也認為不合理，但是沒有辦法，這樣只會讓開發人員鄙視你，造成你後續的被動，工作越來越難開展）
2、開發人員在實現需求的過程要考慮其複雜程度，如果實現起來比較麻煩，也可以和產品經理進行商討
（產品經理和開發人員是承上啟下的關係，也是完成一個需求功能不可缺少的一部分，正確的溝通和理解會讓你在以後的工作中得心應手）
在工作中我也會跟開發、UI等相關人員進行激烈的溝通和爭吵，但是都是基於工作需求；任何一個需求的確認如果只是平平淡淡，沒有一點問題和摩擦肯定會出現問題，只有大家一起溝通確認才能讓需求正確的執行。
最後
最後忍不住吐個槽。有些產品經理動不動就拉老大來給程式設計師施壓，我覺得這種是最low的。
總之我個人認為需求的確認需要大家一起來確認，不是老闆的責任，不是某一個部門的責任，不是某一個角色的責任；要適當的學會拒絕，學會溝通，才能讓需求更正確的執行。
開發者很辛苦，希望可以諒解一下。
###閱讀更多
相信自己，沒有做不到的，只有想不到的
在這裡獲得的不僅僅是技術！
