30歲進入公司，又已經快四年，日常面臨著繁雜的業務需求，頻繁處理著需求的設計、開發、測試、變更、運營和維護，每天自己被逼的很忙。靜靜心思考，我們究竟如何能讓快速相應業務需求，並將業務需求做好做強呢？
一、首先要學會挖掘客戶需求，時刻擁有乙個產品和主人翁的心，並充滿耐心。日常除了能接受客戶的需求以外，還需學會思考客戶為什麼要提這個需求，了解這個需求的上下游背景，提的需求是否合理，是否能幫助客戶挖掘更深層的需求，並將業務需求圓滿解決。這裡有個老太太買李子的典故：
商販a: 老太太你想買什麼，我這裡有李子，蘋果，香蕉...；
老太太：給我來點李子
商販a: 好叻，我這李子可甜了。
老太太嘗了下，搖搖頭，走了。
商販b: 來看一看，我這裡有李子賣了，各種酸的甜的都有
老太太：給我來一斤酸李子
商販b: 老太太這李子可酸了，你嚐嚐
老太太嘗了下，確實很酸，但是還是買了一斤走了
商販c: 老太太，我們這裡有酸李子賣
老太太停了下來，嘗了一口：嗯，確實很酸，給我半斤
商販c: 老太太，你買這麼多酸李子做什麼？
老太太：我家兒媳婦懷孕了，想吃酸的。
商販c: 老太太，你對您兒媳婦真好，兒媳婦想吃酸的，你就過來買酸李子了。可是孕婦最重要的還是要補充維生素c,這裡有新鮮的獼猴桃，要不您來點
老太太：嗯，給我來一斤
以後老太太和商戶c建立了長期運營的關係
分析這個故事：
商戶a: 只在乎自己有什麼，不顧客戶究竟要什麼
商戶b: 知道客戶想要什麼，並能提出解決問題的措施；然而如果又來個需求，又要不斷去面對，讓自己很忙碌
商戶c:不僅知道客戶想要什麼，還能幫客戶針對需求的問題，提出其他合理的方案，並指導客戶去實施，最終達到長期合作的關係
二、細化到技術開發，我們究竟如何做好業務需求
a、如何評估好需求
整體流程評估
1、橫向評估：整體流程鏈路是什麼，跨團隊分工職責是什麼，系統邊界功能是否劃分合理，流程上是否有缺陷？
2、縱向評估：是否有歷史流程，切換到新方案後，舊版的過渡方案是如何處理？
細節功能評估
1、完整性評估：整體功能列表是什麼？功能項是否完備？那些是依賴的外部介面？那些功能項重要性和優先順序設定是否合理？
2、功能性評估：每個功能項流程邏輯是什麼，是否合理；輸入和輸出是什麼，是否有約束條件的限制和特殊考慮？相容性和可擴充套件性是否考慮？定義的需求是否容易驗證？
3、非功能性評估：每個功能項對安全、容災、效能是否有要求？異常情況下，相應的容錯處理是否合理？
4、監控與運營報表評估
b、如何做好使用者需求 參考系統性思維：wwh&dca理論
1、為什麼要做，解決了那些具體問題（使用者、架構問題）
2、全域性解決方案是什麼, 方案整體資料庫設計，類圖設計等
3、功能性設計考慮點（程式描述、功能、輸入項、輸出項、演算法（安全加密、資料結構演算法等）、流程邏輯、介面、儲存分配、限制條件、測試計畫、尚未解決的問題）
4、非功能性設計考慮點（安全、容災、效能、成本、效率、體驗指標設計）
5、異常情況設計（出錯資訊監控、補救措施等）
6、核心鏈路監控與運營報表
7、最終效果驗證，指標收集成果
8、總結，實際經歷的過程和坑，以及解決思路
評審思路：
1、一致性和完整性：功能點是否齊全，是否與設計一致
2、正確性和準確性：軟體功能、流程邏輯、演算法是否正確合理？設計能達到效能最佳，對安全、故障處理和失效的實現方案？使用者介面是否反映功能實現？
3、易理解性：模組結構是否清晰，流程邏輯是否清晰，使用者介面是否清晰
4、可測試性：設計是否可測試
5、介面開放和相容性
6、可追蹤性
7、健壯性：易修改、可擴充套件、可移植
8、復用性：是否可復用
9、可行性：是否便於編碼實現、維護和使用
如何做好需求收集
專案前期需求收集過程的效果好壞，會對軟體產品的最終質量產生直接的影響。如何收集好需求，本文作者給出了一條行之有效的實際操作途徑。什麼是需求收集？需求收集，是確定和理解不同類別使用者的需要和限制的過程，是需要高度協作的活動，是在問題及其最終解決方案之間架設橋梁的第一步，因此其重要性不言而喻。據調查顯示...
如何做好需求分析
產品的構思初期，我們會羅列盡可能多需求，也會收集到很多需求。但有些需求是偽需求，有些需求也不具備實現價值，那我們如何做判斷呢？每天有無數產品誕生，也有無數產品隕落，很多時候會談到乙個原因，沒有把握住使用者需求，吸引不了使用者。那如何把握住使用者需求呢？各種各樣的需求，如何毫無克制地載入功能去滿足使用...
如何做好專案需求分析？
專案需求分析，看了聽棠的 客戶需求何時休 深有感觸，何曾自己不是被這個問題整天困擾 客戶需求，為什麼總在變阿？做專案真辛苦阿！這樣的感嘆 整天都掛在口上。客戶需求變動確實是乙個軟體開發永遠不變的話題。為什麼小的軟體企業面對經常變動的需求是如此的狼狽？到底要怎麼做才能滿足客戶的需求？聽棠的 客戶需求何...