3月1日去了聽了火龍果組織的有關需求開發與管理的講座，老師講的很精彩，也給了我很多啟發。
1.關於需求開發：不得不承認，做了幾個專案的需求分析員，其實際工作只是需求的管理，並未牽扯到需求開發，或者說深層次的需求開發。spec是企劃已經做好了的，而我的工作之一就是仔細研讀和分析，對一些細節問題，與企劃探討並明確，這只能說是需求開發的皮毛。
2.需求管理：我平時所做的工作及流程和老師講的大致相同。
1）得到最初的spec，然後經過測試人員與開發人員的共同討論分析，找到規格中不明確和不合理的地方，與企劃溝通確認並修改。這個步驟中有幾個關鍵點是要注意，一是規格一定要得到開發人員的承諾，否則spec做的再完美，開發人員無法實現，或無法按時完成，會給這個專案帶來不必要的麻煩。二是修改後的規格一定要得到客戶的最終確認才可開始進行開發。
2）將已完成spec轉化為需求追蹤表及需求說明書，並對其做評審，檢查需求項是否覆蓋完全；定義是否明確，沒有二義性；每個需求項之間的關聯是否正確及完全等。
3）檢查測試程式及開發部分是否將需求覆蓋完全
4）需求變更的問題：需求管理主要的工作就在這裡，十分重要。需求無時無刻不在變化，這就需要我們掌握乙個版本變更的時機，如果稍有變化，就要開會評審，執行變更，會耽誤我們很多的時間。我覺得老師說的就很好，應該根據專案實際的生命週期來確定時機：如果專案是瀑布式的，則必須及時的變更及評審。如果是迭代式的開發，則完全可以等到專案的結束的時候再做這些動作。
還有就是根據需求變化的大小，影響來決定評審的形式。我們在專案初期的時候，就應該將需求分成兩部分，關鍵需求（影響功能完成的），非關鍵需求（一些類似ui的部分）。如果是關鍵需求，就一定要開會進行正式評審，如果是一些非關鍵性需求，則可以累積到一定到數目後再進行正式評審。
另外還有一些在實際工作中需要注意的問題：比如正式評審的形式。在專案十分緊張的情況下，我們是否一定要開會才可以正式評審？我認為不應該拘泥於形式。需求管理員可以先以mail的形式將要變更的需求項發布出來，然後請各負責人評估，並回覆可能的影響。如果影響不大，各方面又都沒有什麼異議，那麼mail的形式就完全可以完成正式評審。這樣做既節省了時間，有保留了變更記錄，何樂而不為呢。（當然這只是個人看法，還有待大家的進一步討論）
聽講座心得
今天下午到哈工大研究生院聽了下關於網際網路與創業的講座，有些心得體會。其中一位老師講到 感到不爽的地方就是機會，感到不好的地方，如果我們能提供行之有效的方法，那麼就能夠開拓一片天地出來。歸根結底，當有不爽的地方時，就有改進這個薄弱地方的需求存在，其實就是需求 的乙個方面。實際上就是以人為本，不斷的發...
聽講座 質量管理
今天晚上,聽了關於產品質量管理講座的演講,感受很實用,很喜歡.演講圍繞什麼是質量?質量如何保證?質量執行的標準是什麼?質量管理的方 展開.總結起來,質量就是符合要求 保證質量不是測試部門的工作,更應該是研發部門的工作,不符合質量的產品嚴重影響公司利潤 要求必須細化,有操作性,要完整 保證質量要保證部...
聽講座的一點點感悟
今天聽了微軟亞洲研究院趙鋒博士的講座，感觸最深的是對新技術展示的時候，新技術所採用的技術。同樣乙個問題，不同的人思考的角度不同。有些人拿過問題來，經常無從下手 比如我 但是有人就知道怎樣去思考。有些方法其實你是知道的，但是當真正遇到問題時，卻想不到，關鍵還是沒有養成良好的思考問題的習慣。思考問題應該...