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