作為開發者，你都聽產品經理的，做的累不累？

想必做過幾年開發的小夥伴都碰到過產品經理各種需求，各種上線前需要改東西的情況。簡直無語！下面我給大家盤點一下最讓開發者無語的幾種情況。

講道理，成熟的公司，乙個新版本的需求都是提前討論制定好的，就算是改動也是小改動，但是這是成熟的公司，估計很少的公司能做到上線前不改任何需求的。

很多開發的兄弟上線前幾個小時還能拿到新的需求文件，然後就是各種敲**，但是這種情況很難保證不出一點問題。完了搞不好就被經理各種批，這麼小的錯誤也能犯。

因為上線前，大部分情況都是在改bug，一邊改著bug，還要應對隨時來的「」小的改動「」。反正說多了都是淚...

不清楚大家有沒有碰到過乙個功能讓你反覆改好幾次介面的情況，開始設計乙個介面直接就開始做，做了一半發現邏輯對不上，然後去討論，完了回來重頭寫。折騰半天，時間浪費了，最後問你怎麼乙個功能做了這麼久？是不是效率太低了？

我當時真的想拍桌子問問產品，你能不能開始就把功能這個邏輯都設計對？鍋都讓開發背了...

當然上面說的不是敏捷開發的步驟...

很多時候兩個周的開發周期，前面幾步就被用掉了一周，開發拿到效果圖已經是第二週了...開發前期很多時候能做的事情很有限...有時候根據大概描述先做也很不清晰，做出來後面看到效果圖，基本也要重新改動一遍，改動小的除外，所以有時候開發的時間非常緊迫。so 加班加班加班

我們一般開發很多功能都有乙個共用的概念,比如程式的標題欄等都是繼承乙個，如果效果不一樣，我們就要單獨處理，導致程式可維護性不高。

當然有很多時候這都是沒辦法的事情...大部分時候都是要按照需求做...

更有誇張的時候，我們做完馬上要發布了，要求重新做一版..

很多情況，我們開發的時候都會排乙個時間表，大家嚴格按照時間表執行，但是這個時間表上面羅列出來的功能和我們真正的開發時間往往相差很多。乙個支付功能問你做過沒有，你說做過，那可能只給你1天時間，第二天產品經理就過來問支付調通了沒有...

讓你負責整個專案，列出一大堆功能，問你20天能上線嗎？你這就是赤裸裸的讓我加班啊...

就算是開發時間夠，開發過程中難免出現這樣那樣的問題。總要有一些處理其他問題的時間吧，萬一開發環境突然搞亂了，或者電腦出了問題需要重灌環境。又或者大家一起合作有同事把**提交錯了，覆蓋了自己的**。各種情況都有可能耽誤開發時間。有的公司還各種開會，乙個會一上午就沒了...

有些負責人還要去面試，面試回來就被問進度怎麼樣了？要不就是帶些新人，幫助他解決問題或者講解業務這都需要時間啊！

有排計畫的時候把這些都考慮進去的嗎？產品負責人只會說，這點功能怎麼這麼久還沒跑通？

我總覺得功能盡量越簡單去實現越好，不要為了乙個簡單的小功能去影響整個產品的體驗....

老闆大概意思就是首頁的文字，主介面的模組功能點等都是動態的所有的能看到的介面都可以在後台伺服器配置...

大家想一下這個難度有多大，然後缺點有多少.

這個產品的缺點：

我理解的好的產品應該是：設計簡單、操作流暢、功能簡單易用、穩定性高、使用者體驗好，這些都很關鍵。

所以一些功能從產品經理設計出來的那一刻就注定是失敗的，開發多努力都毫無意義...

程式設計師成功的關鍵有很多因素，碰到乙個好的產品經理設計出一款好產品，你就算做的工作很少，也一樣可以成功。

但是你碰到坑人的產品經理設計出坑人的產品，你多優秀都會被埋沒....想必這也是很多大神都願意去大公司的原因...的確產品好，自己做的也沒有那麼累...

小公司什麼奇葩都有...

說了這麼多，我總覺得基本幾年的開發都碰到過類似的情況，那麼我們開發如果總是被產品牽著鼻子走，做的累不累？

我們開發要怎麼面對這些問題呢，我提出我自己的幾點看法（有問題及時提出指正）：

1.我們盡量要參與需求的制定及討論，盡量對一些不合理的地方及時從開發的角度提出自己的意見。

2.當需求制定出來的時候，我們拿到效果圖，不要著急做，要腦子裡面先想想**有問題，不合理，整體流程能不能跑通。想通了在做。

3.當產品上線前，盡量不要做一些沒有太多意義的小功能。精力都放在處理關鍵bug，問題上。功能能不加就不加。

4.提前制定好計畫，當需求反覆改的時候，要及時和上級溝通交流，調整時間計畫，避免後期時間計畫對應不上。

暫時就想到這些了，後面想到再補充，希望大家也可以多多提出自己的看法。都談談自己碰到的奇葩無語的事情。