需求重要嗎？重要。你做了需求分析嗎，有需求規格說明書嗎？ 沒有。很多人、企業在重複這樣的老路，我就走在這樣的路上。至於為什麼---這塊不在我的許可權範圍內，建議過無效。這裡只當是從一線開發人員的角度說下自己對需求重要性的體會吧。
一路走來，對需求的重要性的認識也是逐漸加深的。即使你一畢業就進入一牛逼，一大公司，一很正規的單位，一上班就讓你參與到需求相關的工作中，也不會有多深刻的體會，甚至是懵懂的，無感覺的。更何況，我還在乙個小城市的小公司裡了。需求的溝通就是，qq，**，面談，溝通完了也不會有完整的文件留下來，最多乙個草稿上畫的示意圖。接下來就是碼**了，中途發現有遺忘，遺漏，不解的，再qq，面談，再回去碼**。好不容易碼完了，自己也測試了，執行通過。準備給甲方試用了。內部測試？省了。
結果是甲方一用，問題就來了：
資料沒顯示（檢查發現甲方用的sql server2000，開發用的sql server 2005），「靠，不早說」；
需求都知道重要，因為她是後續工作的基礎。卻由於過度自信（做過類似的專案）或者自身業務、技術能力有限，草草了事，急著進入開發階段。到了開發階段，甚至後續的測試，上線階段發現重大問題，才想起問誰做的需求，去確認需求。這時就開始暗生隱患（什麼隱患？很多，後面會提到）
需求做得不到位，帶來的直接影響就是，返工，專案範圍擴大。當然如果有經驗的，敏感的開發員在碼之前發現需求問題了，會找經理或甲方確認下，再開始，避免了一次返工；至於說專案範圍擴大，這是大概率事件，很少說需求變了，專案範圍縮小的。接著就是開發周期延長可能性增加，交付上線時間推後，成本增加，合同額會有扣款。
我就遇到乙個專案，20w的專案計畫1年完成，光開發人員平均3-4人，結果做了5年，明擺著是虧錢做。技術不行嗎？都不是第一天做程式，也不是公司的第乙個專案，最大最根本的問題還是在需求。可能會好奇，這是把需求做成什麼樣了，才能搞成這樣。絕大部分模組都改版3次以上，很多達到5次，能不延期嗎。沒有需求管理，變更控制嗎？像樣的需求說明書都沒有，這些又怎麼會有。再者是客大店小，主動權在人家那。這裡也就不去討論什麼管理，規範問題了。只為說明需求的重要性。
上面說到需求出現問題時，會暗生隱患。到這裡隱患都開始浮現出來了。上面也只說到一點，延期、成本上公升。還有其他隱患：影響人員鬥志士氣，影響團隊穩定。雖不是打仗但也講究這個。
開始做新專案了，多少有些興奮的。慢慢的就是煩躁，抓狂，離職。團隊不穩定，水平也就不穩定了。聽到過甲方說「你們怎麼又有人離職啊，我這個專案還有多少人在做」。真有些專案是能把人做跑的。
作為小負責人你就要不斷的給新加入的人培訓，還得解決他的各種瑣事，什麼找不到依賴檔案，什麼開發環境配置不好；偶爾來次什麼誤刪除啊，你就頭大了。最後整個團隊都沒鬥志了。想不延期都難了
需求不明還有乙個隱患就是，技術選型受阻，都可能要重簽合同。在正式開發前都會進行架構設計，技術選型，選元件，選框架。本以為滿足專案要求的，後面卻發現不行，要重新設計，要用到高深的，複雜的，不熟悉的技術時，開發起來都覺得心是顫抖的，萬一開發到一半進行不下去了，是自己去造輪子，改造輪子，還是另找輪子。自己造時間不好把握，另選輪子，之前的工作可能要推倒重來，騎虎難下，兩難選擇，能把人愁死。
需求的重要性不言而喻，卻是在多少人填了多少坑，抓了多少狂才意識到的。只希望以後少些坑，少些抓狂。沒有是不現實的，因為唯一不變的就是：需求變更。
領悟能力在需求階段的重要性
搞it的人都知道 軟體開發需要跟客戶做需求 同時也很清楚地知道一點 當你問對方 你每天是如何工作 所有客戶都會迷茫 至少相當一部分客戶是這樣的 因為他們每天都是如此地工作 當你再問 你想要什麼東西時 估計客戶就會開始變得不耐煩甚至狂躁起來 會詫異地看著你，說 剛才已經說了！正應了一句話 魚對於自己終...
專案需求的重要性
最近看到網上瘋傳的幾張，著實道出大家內心的想法呀！沒有經歷過的人恐怕真的無法體會到其中的 精髓 只有真正經歷的人，才能產生更多的共鳴吧。哈哈 最近跟乙個專案，從前期需求分析階段開始，由於整個 及其需求都不了解，討論需求的時候很難跟客戶產生共鳴，只好聽專案經理跟客戶一同討論。旁聽不懂的東西其實也挺煎熬...
需求的重要性續集
這裡是it修真院產品分享課，今天要分享的是 需求的重要性續集 很多時候需求的提出方可能並不是我們自己，是由他人提出的。記錄需求的提出方是誰有助於我們重新梳理當時的決策過程，如果提出的是失敗需求，就算不是我們自己。那麼也應當思考 為什麼自己沒有阻攔這次需求，反而是讓失敗的需求順利的上了線？當時如果提出...