1、盡力區分和剔除那些【雞肋需求】

     【雞肋需求】：就是那些看上去很屌但使用者並不會去使用和關注的功能需求。

      經手的專案中，曾經有個【雞肋需求】讓專案的開發成本增加了30%，投標公司減少60%（因為技術有點難），工期拖後了N天，但使用者覺得”然並卵“。那就是”在WEB頁面上動態顯示一場地內作業機械裝置的位置。“

        當時這個功能看上去很美，但上線後並沒有被使用過幾次，僅僅是向BOSS們秀了一下。

        我很一直後悔當時雖然預感到些功能需求”然並卵“，但沒有盡力找個理由把該功能需求在文件中刪除掉。

2、在需求調研階段就確定每個功能的代表使用者，驗證人員。在需求文件完成後，請代表使用者進行評審方案。請驗證人員評審測試方案。以保證功能不偏離一線使用者需求。

       公司行政想開發一套排班考勤系統來規範本公司和外包公司人員的上班考勤行為，避免代打卡和虛報出勤人數。但在需求調研階段並沒有去訪談一線使用者和外包公司，只是聽了行政人員的一面之辭。

      系統測試階段才把這些人拉來測試，結果可想而之。一線使用者提出很多修改建議，導致開發量成倍增加。外包公司以各種理由拒絕測試和使用該系統。

      後來做到一半功能，開發商就跑路了，因為需求偏離度太大了。

3、在需求階段就定義好軟體專案的生命週期和運營成本，以防止未來缺經費導致運維困難。

      曾經公司為了加強節能管理上馬了一套《機械設定油電管理系統》，用於實時監控大型設定是在用柴油動力還是在用電力，督促司機儘量用電力作業以節約成本。本來專案計劃運營一年，司機養成節能習慣了就可以不用了。所以系統設計和維保均沒為做長期使用打算，只和開發方簽訂了上線後保一年的合同。

    但後來公司為了統計需要，一直在使用該系統，超過了三年。因為軟體和硬體缺乏維護，資料採集出現了問題，導致資料準確率越來越低，目前只用成電錶的資料能採集到。最終出來的報表根本不具有使用價值。

    重點是：軟體專案的生命週期要首先和使用者確認好，到了時間就準時下線。如果還需要使用就必須重新啟動專案和申請資源。因為軟體運營需要大量人力和財力，沒有預算就很難執行下去。