想必做過幾年開發的小伙伴都碰到過產品經理各種需求。各種上線前須要改東西的情況。

簡直無語。以下我給大家盤點一下最讓開發人員無語的幾種情況。

一. 上線前一天或者幾個小時，提出新的需求

講道理，成熟的公司。一個新版本號的需求都是提前討論制定好的，就算是修改也是小修改。可是這是成熟的公司，預計非常少的公司能做到上線前不改不論什么需求的。

非常多開發的兄弟上線前幾個小時還能拿到新的需求文檔。然后就是各種寫程序。可是這樣的情況非常難保證不出一點問題。完了搞不好就被經理各種批，這么小的錯誤也能犯。

由于上線前。大部分情況都是在改bug，一邊改著bug，還要應對隨時來的“”小的修改“”。反正說多了都是淚...

二.需求重復變?

不清楚大家有沒有碰到過一個功能讓你重復改好幾次界面的情況，開始設計一個界面直接就開始做，做了一半發現邏輯對不上。然后去討論，完了回來重頭寫。

折騰半天，時間浪費了，最后問你怎么一個功能做了這么久？是不是效率太低了？

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

三.產品設計無限遲延

一個產品開發新版本號流程大概是：提出需求->依據需求UI做出效果圖->然后產品和UI依據效果圖做出小調整->定稿，UI切圖->開發依據效果圖開發

當然上面說的不是敏捷開發的步驟... 非常多時候兩個周的開發周期，前面幾步就被用掉了一周，開發拿到效果圖已經是第二周了...開發前期非常多時候能做的事情非常有限...有時候依據大概描寫敘述先做也非常不清晰，做出來后面看到效果圖。基本也要又一次修改一遍。修改小的除外，所以有時候開發的時間非常緊迫。so ?加班 加班 加班

四.產品設計不夠總體化考慮

好多時候產品經理提出新的功能或者需求都會去參考其他的app。假設是一個經驗不太夠的產品，他每次設計出來的東西和整個產品都不一定能相應上，比方 ：好幾種顏色的標題欄。首頁風格常常會變 一會九宮格布局 ，一會兒tab標簽欄布局（一種是activity跳轉，一種是fragment碎片），好幾種風格的篩選數據的效果。

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

當然有非常多時候這都是沒辦法的事情...大部分時候都是要依照需求做... 更有夸張的時候。我們做完立即要公布了。要求又一次做一版..

五.產品開發時間卡的很死

非常多情況，我們開發的時候都會排一個時間表，大家嚴格依照時間表運行，可是這個時間表上面羅列出來的功能和我們真正的開發時間往往相差非常多。一個支付功能問你做過沒有，你說做過。那可能僅僅給你1天時間，第二天產品經理就過來問 支付調通了沒有... 讓你負責整個項目。列出一大堆功能，問你20天能上線嗎？你這就是赤裸裸的讓我加班啊... 就算是開發時間夠，開發過程中難免出現這樣那樣的問題。總要有一些處理其它問題的時間吧。萬一開發環境突然搞亂了，或者電腦出了問題須要重裝環境。

又或者大家一起合作有同事把代碼提交錯了，覆蓋了自己的代碼。各種情況都有可能耽誤開發時間。有的公司還各種開會，一個會一上午就沒了...

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

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

六.簡單功能復雜化

舉個樣例 ?一個選擇城市的功能,可能公司產品就支持3個城市，大家在做這個程序的時候，一般有點經驗的都會考慮 這個城市以后添加了怎么辦，肯定不能夠在程序里面寫死。這個必須動態控制，不能以后添加一個城市我們就提交一次app吧。 這么想講道理沒有問題。然后獲取一個城市列表（3個固定城市）加一次網絡請求server。然后產品經理過來發現，你這么做有問題啊，就這么三條數據每次進這個界面還有正在載入數據（一般網絡請求假設網絡慢的時候，都有載入中提示...），然后讓你改，說體驗不好....然后你就要想辦法了。這個不能寫死。還不能每次都載入，那么僅僅能第一次載入完存本地了，下次推斷本地有就不請求server了...好然后高興的寫去了，寫完想想有漏洞，假設server這個時候有增刪改就麻煩了。比方 多個城市。少個城市，改了當中一個城市的名字...這個本地就和server相應不上了，然后還要再加入對本地數據更新的邏輯......

后來，這個app再也沒有支持過別的城市,白白加了這么多復雜的邏輯...

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

我在第一家公司的時候。老板提出這樣一個概念。就是做一款能夠配置的app。就一個項目...聽好是一個項目，不同意拷貝多個項目然后改動，由于不好維護...

老板大概意思就是 ? 首頁的圖片文字，主界面的模塊功能點等都是動態的 全部的能看到的界面都能夠在后臺server配置...

說白了就是：app上全部的地方都要從后臺請求字段 ，然后依據定義好的字段的值 去控制app的顯示....這樣就會產生出來非常多app... 餐飲，醫療。交通，購物....

老板的概念是：定制化全能app...

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

這個產品的缺點：

? 1.app內邏輯以及請求太多，影響app的流暢度及體驗

? 2.從產品角度考慮，配置出來的app缺乏個性化，功能界面效果非常單一。

? 3.產品過于復雜。導致app本身過大。（基本全部第三方的sdk都會用到，jar包就幾十個）?

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

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

程序猿成功的關鍵有非常多因素，碰到一個好的產品經理設計出一款好產品，你就算做的工作非常少。也一樣能夠成功。

可是你碰到坑人的產品經理設計出坑人的產品。你多優秀都會被埋沒....想必這也是非常多大神都愿意去大公司的原因...的確產品好。自己做的也沒有那么累...

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

說了這么多，我總認為基本幾年的開發都碰到過類似的情況。那么我們開發假設總是被產品牽著鼻子走，做的累不累？

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

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

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

想通了在做。

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

4.提前制定好計劃。當需求重復改的時候，要及時和上級溝通交流，調整時間計劃，避免后期時間計劃相應不上。

臨時就想到這些了。后面想到再補充，希望大家也能夠多多提出自己的看法。

都談談自己碰到的奇葩無語的事情。

歡迎大家增加我的開發群：454430053

轉載于:https://www.cnblogs.com/wzzkaifa/p/7376047.html

總結

以上是生活随笔為你收集整理的作为开发人员，你都听产品经理的，做的累不累？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。