目錄
產品研發過程常見問題1：缺乏統一的管理平臺
產品研發過程常見問題2：難以量化的需求開發與管理
產品研發過程常見問題3：跨部門協作困難
產品研發過程常見問題4：多項目管理挑戰多
產品研發過程常見問題1：缺乏統一的管理平臺
隨著軟件開發實踐的不斷深入，應用生命周期管理越來越被業界接受為一種經過實踐檢驗的，可以創造高品質的應用程序的，可靠的軟件開發模式。但是，要實施整個應用程序生命周期管理是非常復雜的，我們必須借助一些工具來幫助我們完成整個生命周期的管理。
讓我們先來回顧一下絕大多數軟件研發團隊的典型工作情景：
【場景1】：工具滿天飛
很多研發企業的管理平臺非常分散，不同團隊和個人使用工具不同，我們常常可以看到，產品部門收集需求使用Word、Excel，項目經理制定項目計劃、進行任務劃分和分配使用Project，開發部門管理任務和缺陷使用Jira、URTracker，測試部門管理測試任務使用TestDirector、TestLink，配置管理使用VSS、SVN、CVS、CC等等，這些平臺相互是獨立的，不僅不可以信息共享，部門之間還產生了有明顯的信息壁壘，完全靠手工操作實現信息傳遞。
【場景2】：研發過程銜接不暢
公司的需求管理、計劃管理、缺陷跟蹤、測試管理等等各種研發活動，使用不同公司開發的無法整合的工具，這些不同來源的工具，既無法共享項目信息，給使用上帶來很多不便，又無法在各種不同類型的數據之間建立關聯，導致一些高級管理功能無法實現，比如要實現需求跟蹤，需要整合需求管理、任務管理、測試管理三個系統。
【場景3】：一個BUG引發的血案？！
軟件開發人員1： 通過代碼走查發現一個BUG，需要將這個BUG記入缺陷跟蹤系統；
軟件開發人員2（代碼的作者）：需要根據這個缺陷判斷需要如何修改，并評估修改的工作量。如果是普通的BUG，只需要開發人員進行修改即可；一旦發現是深層次的BUG，涉及到數據結構的調整、界面的調整甚至軟件架構的調整，這將牽動研發團隊的項目經理、系統架構師、數據庫管理員、界面設計人員、產品經理；
項目經理：收到開發人員的匯報，很不幸的發現這個問題需要在缺陷跟蹤系統中將相關的人員統統拉到一起才可以解決問題；
產品經理：需要根據缺陷評估即將投入的人力成本和由此引發的后果；
系統架構師：評估架構調整的成本并拿出可行性方案；
數據庫管理員：調整數據結構，并為由此帶來的數據結構升級準備方案；
界面設計人員：重新調整界面，并為原來統一的風格如何調整傷透腦經；
軟件開發人員3（終確定FIX BUG的人員）：根據終收到的修改方案，制定修改計劃并進行BUG的修改，而且該軟件開發人員制訂的開發計劃需要讓相關人員能準確的掌握BUG修改的進度，因為他的計劃制約了后續的每一步工作；
版本經理：根據修改結果發布一個測試版本，并知道版本中已包含了此次修改；
測試人員：在拿到該版本后需要對這個BUG導致的代碼修改設計針對性的測試用例，這個測試用例可能是自動測試用例，也可能是人工測試用例，總之測試人員需要在測試管理系統來記錄這個BUG修改的驗證過程；
版本經理（又出現了! ）：一切緒后，向客戶發布版本時還需要提供release notes以指明該版本中的這個改動（假設該BUG對用戶可見）；
技術支持：收到版本經理發布的版本、操作手冊以及相關的FAQ，做好給客戶提供支持的準備；
QA：仔細分析代碼走查發現的所有BUG原因，如果是典型問題，還需要將該問題寫入開發經驗庫，并通過知識共享的形式分享給所有團隊成員；
項目經理（?！）：一切卻還沒有結束！項目經理的職責還需要從組織級的角度把控項目過程和研發全進程。一個開發人員的代碼如果被統計出問題較多，應該對該開發人員開發的代碼采取補救和預防措施，要么加強測試，要么給他一些培訓，要么他根本不適合這個職位應該走人；對于這個開發人員的上司，他應該如何評價這個犯錯的下屬，因為幾個BUG認為他的工作不稱職顯然是不正確的，還有他如何衡量這個開發人員的工作量，是否是該員工工作量太多導致了該員工的代碼質量不高？他還想知道該員工在引入這個BUG時當時的工作任務是否過于緊迫？當然，他也可能想分析一下這個典型的BUG引入會導致多少額外的工作量產生？
…………………….
這，也太麻煩了吧！
一切只是因為一個開發人員的某行代碼的BUG引發的血案？！
拜托！這是研發工作的特點！好嗎？!
理由很簡單：沒有一個集中管理、統一、高度整合的管理平臺！
