今天想寫寫該聽誰的這個話題。朋友說有個專案，專案是使用者希望用php基於drupal開發乙個商務**。我問使用者是搞技術的嗎？他說不是。我又問那他使用php和drupal是別人給他建議的嗎？他說不是，是使用者自己上網查的。我說使用者提的這個可能有問題，需要梳理一下。朋友說使用者提需求讓你做，你卻告訴人家需求有問題，告訴他錯了，使用者還會讓你做嗎？我說使用者不是這個行業的，也沒有專業人員參與，我覺得使用者提的不是需求。朋友有點急，他問我不是需求是什麼？我說是解決方案，應該由專業人員提出的，應該我們幫他考慮的。朋友很生氣專案最後沒有交給我做，我也有了個光說不練的名聲。
其實這樣的使用者我遇到過很多，負責專案的管理，懂些專業知識。他們經常把用什麼架構、用什麼語言、用什麼框架、做的像什麼什麼**、做得像什麼什麼功能作為需求提出來。遇到這樣的使用者千萬要注意，他們直接把需求變成了解決方案，並作為需求提出。很多開發專案組的成員都在這個行業幹了十幾年，但經常被客戶指定介面操作方式、頁面布局、開發語言、開發框架、開發元件等等。有沒有覺得不太對勁，問問使用者為什麼提出這些，如果是你會這樣設計嗎？專案都皆大歡喜的結束了，沒有人考慮這些。把自己擅長決定的事情交給了別人，不合適解決方案讓我們加更多班、投入更多的精力，被認為技術水平差。當然我們相信有高手，相信一切皆有可能，但專案投入有限、時間有限，總之鞋合適不適合只有腳知道。
還說開始的例子，商務**規模、服務物件、服務內容、業務模式、運維模式、使用者資金等都會影響方案的選擇。drupal功能很強大，要因需求而定，比如考慮維護成本、開發難度，既不要大炮打蚊子，也不要小馬拉大車。這些東西要分析使用者需求，根據專業知識和開發經驗，整體評估並認真論證，提出更加合理的解決方案。我認為作為專業的人員要主動承擔自己擅長的工作，基於自身的技術實力，為使用者提供最合理的解決方案。
我不是不聽使用者的，而是挖掘使用者真正的需求，驗證使用者解決方案，完善使用者的解決方案。這個是我想堅持的，我提醒自己搞懂使用者真正想要的，讓自己更專業，提出更合理的解決方案。其實這麼做真的很難，拿錢辦事的模式下，商務人員關心如何拿下合同，技術人員沒有話語權。
需求工程之需求基線
什麼是需求基線？需求基線就是把固定的需求都劃一根 線 說明這些需求已經確定下來，新增新的需求或修改原有的需求都必須通過需求變更流程來操作 建立需求基線的目的 防止需求的變化給程式架構造成重大影響。需求基線定義 已經通過正式評審和批准的規格說明或產品，可作為進一步開發的基礎，而且只有通過正式的變更控制...
需求工程之需求跟蹤
需求跟蹤 是需求管理的一項重要內容。指跟蹤乙個需求使用期限的全過程，需求跟蹤包括編制每個需求同系統元素之間的聯絡文件，這些元素包括 需求跟蹤的主要意義 在於獲得需求目前的實現狀態，確保使用者所有的需求都得到滿足。需求跟蹤的主要目標 維護軟體工作產品間的一致性。需求跟蹤分為 後向跟蹤 指需求在被定義到...
《需求工程》閱讀筆記之需求工程
需求工程活動分為需求獲取和需求分析 需求規格說明 需求驗證 需求管理。需求獲取是從人 文件或環境中獲取需求的過程，需求工程師必須要利用各種方法和技術來 發現 需求。需求開發的過程包含有學習和認知的過程，而學習和認知的過程是遞進的，因此需求獲取和分析是交織在一起的，需求工程師需要獲取一些資訊，隨即進行...