幾年前的某個時候,公司大夥都等著下班我卻等著晚上加班,因為產品經理對產品的某個功能進行了調整和修改,我必須加班將其修改完善。對於這種事情我已經數不清了,產品經理的每一次變動都得讓我們技術部門的同學們加班到深夜甚至到天明,如今回憶起來歷歷在目!今天這個文章我們不談論是誰的責任,也不去抨擊產品經理的無能,說說技術人員為什麼總是在抱怨需求在變動這些事， 希望大家踴躍討論。
一. 抱怨現象
最近我做了實施人員,經常到各個客戶工廠去給他們實施專案,在這個過程中我瞭解到了軟體的真實使用者,在這之間我就成為了客戶和公司技術人員的傳話筒,因為我本身也是做技術出身所以這樣對訊息的轉化也就有了一定的優勢。最近幾次我在回來的路上一直再想同樣一個問題,為什麼技術人員總在抱怨需求的變動,之前我做開發的時候也是在抱怨,現在換了新人我給他們傳話他們同樣在抱怨，這是為什麼？
案例一:
前面的文字中說道過給客戶做的一個倉庫電子看板,這個裡面經歷了幾次較大的改動,每一次我回來給公司的技術人員反饋問題他們總是那麼的不耐煩甚至牴觸。
第一次給客戶做的效果原型示例圖如下：
分為兩個部分，兩個都是一樣的只是顯示內容不一樣而已，一個是進料資訊一個是出料資訊。
第二次客戶要求在下面新增一行文字:
這次新增的是下面的滾動文字，介面展示效果堪稱不錯，現場螢幕測試也完全OK。
第三次 客戶要求下面的滾動文字可以替換,也可以不顯示或者不滾動
第四次 客戶要求欄位顯示的行數可以自定義
第五次 客戶要求欄位滾動的速度可以自定義
第七次 客戶要求介面資料重新整理資料的頻率可以自定義
............
到了這個時候技術人員火了,MD天天改，天天這樣改，有完沒完？
案例二:
客戶之前做統計報表都是Excel自己統計的,而且統計的還有模有樣，在Excel中製作的非常漂亮而且顯得非常專業，後來公司上系統了需要在系統中能夠自動生成這樣的報表,這裡貼一個示例圖看看客戶的要求。
以上表格式Excel中的,客戶要求在系統頁面上顯示一個這樣的報表格式。因為使用者非技術人員之前就是一直用Excel這樣做的，要求就是給他們做成如圖的樣子就可以了並且資料正確。
公司技術人員拿來之後一看這個報表也不怎麼難嘛，很簡單，資料在系統中都可以統計得到。
(1) 課題年份和獲獎年份有啥關係
(2) 課題年份和課題數有啥關係,課題研究如果當年沒有完成直到第二年才完成算哪一年的？
(3) 客戶研究是以小組的形式來展開的，他們和小組是否有關係，表格中並沒有體現小組的資訊
(4) 課題和成果之間的關係是啥,怎麼好像數量關係沒有直接聯絡啊
(5) 課題和獲獎是否有直接關係啊？
(6) 有了成果是不是就一定能夠獲獎啊？
..............
後來開發人員懵了，這是啥子需求哦，改一個不是這樣的，該另外一個又不是這樣的，客戶又表述不清楚你想知道的東西，你確認一直認為客戶所要的東西變了和第一次說的不一樣啊！一個這麼簡單的表格到了最後花了時間，花了人力，最後結果還是一團糟.
二. 客戶不清楚最終想要什麼
以上兩個案例都是最近我實施過程中的真實案例，我們用事實說話不做虛假假設。在最近的工作中類似的經歷非常之多，這裡只是舉兩個例子【我們這裡說的是問題，如果哪位高人想說這表現出你們團隊協作能力較差，或者公司整體能力不行等麻煩不要看此文了，這個問題不在此文章討論，後續再說這些問題】。
案例一分析：
(1) 客戶頻繁的要求修改這些那些，說明客戶自己本身也不知道需要做什麼怎樣的介面，介面需要展示什麼資料。這是一個很正常的現象，如果客戶這些都全部清除你也就只有碼程式碼的份了，處理碼程式碼的體力勞動你沒有價值了。
(2) 很多要求是在現場展示的時候提出來的，說明客戶很多時候就是隨心所欲，甚至拿著手機看到了一個非常漂亮的東西也想往上面貼。
(3) 軟體是否適用要在真正環境下才能校驗"真偽",比如其中遇到的字型問題，在電腦上顯示非常好，但是在大螢幕上顯得非常小，遠距離觀看和近距離觀看還是有差別的。
(4) 開發人員只是一味的跟著客戶的節奏在走,客戶說什麼就是什麼,說那裡有問題就改哪裡，最終程式碼沒有結構性，滿是補丁的可以勉強執行，只要再修改裡面千瘡百孔。
以上總結幾點基本可以歸納出來在開發的過程中為什麼會一直出現不停的修改，於是這也苦了開發人員，沒辦法那個誰說的"客戶就是上帝"。
三. 開發人員未能真正理解需求
案例二分析:
(1) 技術人員太小瞧了一個簡單功能的開發.這裡我一定要將這個排到第一點,個人覺得這是態度的問題，對於問題處理的態度問題。
(2) 技術人員對給出的淺顯得需求未能去深入挖掘，不然不會到了開發過程才發現年份之間關係有問題。
(3) 非專業人士的表達不能夠理解是因為技術人員沒有站在使用者的角度去想這個問題並且表達出來(我承認這個有點難度,但是作為有價值的的技術人員必須學會這麼做)。
(4) 發現問題沒有去歸納總結，而且沒有及時去反饋問題，也沒有去溝通問題。
四. 案例分析總結
以上單獨分析了兩個案例，一個案例問題出現在客戶這邊，一個案例問題出現在開發人員這邊，我這裡暫且這樣劃分。
總結一下導致需求變動的原因:
(1) 客戶本身不清楚自己具體要做成什麼樣子,而且客戶的想法較多
(2) 客戶現場的真實環境導致你某些程式不能滿足(適應環境,有機會影響環境,生物的適應性)
(3) 客戶不能正確表述他所要的東西,雖然他心裡非常清楚想要這個,和程式設計師一樣語音組織表達能力較差(實際上需求沒有變,表述不一樣理解不一樣)
(4) 開發人員小瞧了簡單的業務需求,沒有深入去挖掘潛在的問題和需求,問題最終逐步暴露出來
當然需求的變動還有很多其他的原因，比如市場的需求變動，客戶操作習慣的變動,業務的發展變動這些都會直接導致程式需求的變動,以上的原因導致的需求變動就足以讓技術人員叫苦不迭了。
五. 技術員能不抱怨麼
說來很奇怪,我一直認為技術人員就是”很奇怪的動物”，從開始工作的那個時候開始走到哪裡都能夠看到抱怨的程式設計師，沒有一個公司的程式設計師對需求變動不抱怨的，但是最終抱怨之後還是默默的修改變動的需求，說明程式設計師都是善良的！偶爾會抓狂但是他們還是會默默付出。
對於後來我介入了這兩個功能的開發,並且做了一些工作來調整這樣的狀況:
案例一中我自己在紙上羅列一些環境和硬體清單:
1. 客戶螢幕解析度使用的是1280*768,最大解析度支援1990*1280,剛好公司有這樣一個屏可以模擬測試。
2. 客戶使用xp系統(使用的工控機,沒得辦法),那我們也安裝一個xp系統，虛擬機器就好[建議儘快拋棄xp系統,這個系統現在的確非常頭疼]
3. 遠距離看螢幕字型大小,不要在電腦螢幕上看
4. 需要自定義動態設定的引數全部羅列,顯示資料行數,欄位數,重新整理頻率,翻轉時間,滾動文字等等，每一個都具體在紙上羅列，然後對著去實現
5. 問題分析主次,畫好資料傳輸的邏輯圖,問題優先順序分等級，哪些問題是有關聯的，程式層次關係等等
6. 交給另外的人員來測試,沒有參與過開發的(很是慚愧我公司沒有測試人員)
案例二中我給開發人員指出一下幾個問題:
1. 課題年份和獲獎年份的關係， 我先假設幾種關係，使用窮舉法：
(1) 課題研究是否獲獎要到第二年才確認，甚至是第三年
(2) 課題研究是否獲獎一定是在第二年確認
(3) 課題研究是否獲獎一定是在當年確認
(4) 課題研究和是否獲獎本身沒有任何關係
2. 課題成果和獲獎之間的關係，同樣先假設幾種關係,使用窮舉法:
(1) 課題研究有成果就一定能夠獲獎
(2) 課題研究有成果可能能夠獲獎
(3) 課題研究成果和獲獎沒有關係
.........
上面是簡單羅列的問題,我相信如果你能夠將這些問題羅列出來，說明你解決問題的思路已經非常清晰了，這個思路和技術無關，也就是你已經明白你要做的東西了。同樣你清楚這些東西那麼你就很容易去有的放矢，針對具體的問題解決問題，而不是盲目的去修改程式碼然後編譯一次交給實施人員去給客戶看行不行。對應客戶自己本身不能表訴那麼你就從他表達出來的內容拆分幾種假設，然後你可以以你的專業語言去描述給他聽，他自己要明白你描述的是否是他想要的東西問題就解決了。
我當然知道技術人員的抱怨是必比不可少的，我工作也有些年了，到現在還避免不了偶爾去抱怨一下，就跟家庭生活一樣偶爾也會有煩心和不愉快的時候，如果你坦然去接受面對這些問題我相信你會從容很多。
六. 總結
(1) 永遠不要奢望客戶清楚的告訴你他們想要什麼東西，更加別異想天開的他們會給我們整理一份非常完美的需求文件(如果有客戶為你做了很好的一份需求文件，那是因為你的善良感動了上帝)。
(2) 客戶的問題是你發揮自己能力和體現價值的時候
(3) 好的程式層次結構，程式碼的健壯效能夠很好的應付客戶需求的變動
(4) 你和你的程式一定要比客戶想的多，而不讓客戶為你想更多的問題
(5) 深入挖掘客戶的需求，這個不會讓你吃虧的，挖掘需求也有很多辦法，只要你真的再為客戶想問題那麼解決問題的方式一定很多
(6) 沒有一層不變的需求，也沒有完美的客戶，更加沒有完美的個人，要坦然面對工作中的問題
(7) 溝通是解決問題的最好最直接的方式,直接打電話不要使用QQ發訊息留言(最反感QQ留言了,開發人員最喜歡QQ留言了,因為不敢給客戶打電話)
本文到此結束，文中所寫只是個人經歷和感受，不存在任何的偏見，可能和一些人的意見和想法有出入，但是不影響各位對此話題的見解！