基于WBS-RBS矩陣的TC公司小程序軟件項目風險識別分析目錄TOC\o"1-2"\h\u309681.1公司和項目管理介紹 1247591.1.1項目概述 225243本項目開發背景 2147141.2項目風險識別方案 5182791)需求風險 6116322)技術風險 7137203)研發過程風險 8289974)團隊管理風險 8309781.3項目風險分類 9194381.4風險識別結果 101.1公司和項目管理介紹TC公司是中國在線旅行行業的創新者和領先者，致力于打造在線旅行一站式平臺，業務包括交通票務預訂(火車票、機票、汽車票、景點門票等)、在線酒店預訂、景點門票預訂，及多個出行場景的增值服務，用戶規模超過1.4億，是中國兩大出行平臺之一。TC公司入選2010年度江蘇省規劃布局內重點軟件企業，也是江蘇省首個“旅游信息化創新示范基地。TC公司在國內有多個研發中心，項目團隊成員來自蘇州，北京，成都等不同地區。項目人事部門采用強大的矩陣組織結構，并由專門的項目經理管理橋通，以協調來自不同地區的技術工作人員。同時，每個地區都有指定的領導者來管理他們的團隊開發人員，分配任務等。公司采用簡單的瀑布軟件開發模型，首先，業務人員確定需求，然后進行需求分析，開發人員進行進一步的技術分析和技術開發，最后發布產品。項目經理在每個項目周期中都使用Excel來宣傳周期中每個點需要完成的工作，并將其定期發送給項目團隊負責人以管理進度。為了與質量管理保持一致，該項目目前使用TFS來管理測試人員報告的技術缺陷(Bug)，但是由于模板的使用相對簡單，并且流程不是很標準化，因此通常很難有效地管理缺陷。統一項目。項目管理主要是軟件需求管理，一些需求人員通過微信為企業直接向開發人員發送書面文檔，而另一些則通常通過電子郵件，需求變更或文檔升級發送給開發人員，開發人員很難及時獲取信息。目前，尚無用于組織需求文檔的統一標準。整個項目不使用管理工具來管理項目，而是通常通過電子郵件就項目進行交流和交換。盡管TC公司為小程序軟件開發制定了完善的項目管理制度，但是項目組在軟件開發風險管理的實踐中依然遇到很多急需要解決的問題。在進一步深入研究分析后發現這些問題會直接影響著項目實施的效果。由于TC是一個小型程序項目，因此具有技術復雜性高，開發任務復雜，軟件質量要求高以及外部風險高的特點。因此，在管理項目研發風險時，不僅要考慮需求，成本，進度，技術，人才，資金，管理等相關的內部風險，還要注意項目的外部風險。過去，TC公司使用基于適當策略的軟件工程風險模型(SERIM)來管理軟件工程項目的研發風險，同時管理先前的軟件工程項目的風險。在對微信小程序風險模型的實際情況進行徹底分析之后，我們發現管理模型不適用于管理小程序開發的風險。首先，軟件工程風險模型僅識別項目風險，重點是技術風險，進度風險和成本風險對項目成本和進度的影響。小程序項目中存在多種風險來源，我們不僅需要管理項目的內部風險，還需要管理該項目的外部風險，例如微信提供的API的更改。其次，軟件工程風險模型僅在項目計劃階段和初始項目階段識別風險，而不考慮需求變化，技術開發和項目監督后硬件升級所產生的風險。簡而言之，TC以往的風險管理方法存在一些問題：沒有充分考慮軟件項目負責性，風險識別的范圍不足以及在軟件項目的實施階段對風險的了解不足。因此，項目團隊需要面對這些問題，使用適當的風險管理模型來連續管理TC公司小程序項目的研發風險，并能夠控制好項目的內部和外部風險。1.1.1項目概述TC小程序應用項目是一款無需下載安裝，只需掃描二維碼即可實現產品訂購和增值服務的應用，目前開放了火車票、飛機票、汽車票、酒店、景點等多個產品入口并已全部完成小程序應用的搭建。在不久的將來，用戶在到達火車站、機場、汽車站、景區、門店等地時，可輕松實現掃碼購票和到場服務。本項目開發背景TC公司致力于打造不同場景的差異化服務，將對旗下產品做全線智慧升級，以更豐富多元的產品依托小程序應用，領跑智慧出行。長期以來，用戶出行過程中存在著諸多不便：如景區排隊購票，入園擁擠，排隊時間長；火車站的售票窗口排隊很長，官網的購票驗證碼很難識別；機票預訂過程相當復雜，貴賓休息室的入口門檻很高、機場餐食收費高等問題，而這些情況很難在傳統方式上得到合理有效的解決。其目的就是為用戶持續打造差異化服務，提升用戶體驗。比如在汽車站，TC小程序應用項目可幫助用戶實現掃碼購票進站，無需軟件下載，告別排隊煩惱，使出行更加便捷高效；在火車站，該小程序應用項目則可以提供更加快捷高效的火車票預訂功能，更具品質的VIP候車廳服務。據了解，同程旅游還將持續探索火車站的創新體驗服務，力爭為用戶提供更多到站的特色服務和價值。同樣，在機場場景，小程序應用將對現有機票業務進行高度系統化整合和深度開發，通過貴賓廳掃碼體驗作為起點，專注打造機場服務的創新體驗，為消費者提供機場美食，掃碼訂票等其他綜合服務，在機場提供一流的、功能強大的中文旅行指南，包括餐食，購物，娛樂，交通等全面指導服務。此外，作為智慧景區解決方案供應商，TC公司深耕景區服務多年，在市場上占有絕對優勢。此次通過小程序應用項目的搭建，公司的用戶可輕松實現掃碼購票，快速入園，負責人曾經表示，TC小程序應用的使用將大大提升景區的智慧化、信息化水平，降低景區的運維成本，為游客提供更好的購票、入園、游玩等服務體驗。本項目設計概述TC公司的這款小程序應用入口在微信錢包中，可以通過微信授權獲取微信用戶信息。在覆蓋原有原生APP功能的基礎上，增加了很多新的創新功能點，重點針對用戶訪問速度、UI美化以及用戶體驗等方面進行了改進和完善。部署模式：服務器是linux服務器，部署環境是jdk1.7mysql5.6tomcat7centos6.5功能列表：①旅游攻略②酒店③景區④火車票⑤機票⑥度假⑦租車本項目整體目標該項目的開發主要為了實現以下幾個目標：1)無需繁瑣的注冊流程，及時滿足您的預訂需求；2)達到讓用戶極速預定3)為用戶提供便捷智慧服務信息以及為用戶提煉精準的信息，減少用戶查找信息的路徑，讓用戶的出行服務更加簡單、便捷和智能項目團隊組織結構該項目組建立于2016年4月，項目組的組員各自從公司各工作部門抽調每人必備開展建立。項目組建立前期現有職工39人。從公司的項目風險管理單位中挑選出一名工程項目經理。工程項目經理承擔新項目精英團隊的日常管理方法，并向公司技術主管匯報；項目組從公司開發軟件單位抽調專業技術人員26人(其中包括系統架構師2人、JAVA技術工程師10人、Android開發工程師3人，iOS開發工程師3人、WEB前端開發8人)；項目組從公司品質保障部門抽調5人(QA小組長1人、QA專員4人)；從產品經營單位抽調4人(在其中產品運營1人、產品專員3人)；項目組從公司技術部抽調UI設計師4人。項目研發流程概述TC公司微信小程序運用新項目遵照統一手機軟件開發流程實體模型(RUP模型)全部運用軟件開發生命期分成四個階段：原始階段，優化階段，搭建階段和交付階段。原始階段包含業務流程模型，可行性方案和項目實施計劃；優化階段包含考試大綱設計方案，技術性工程項目和迭代更新方案；搭建階段包含好多個迭代開發全過程，每一個迭代開發如同一個中小型項目管理。在瀑布式開發過程中，有必要進行迭代產品的需求分析和詳細設計，然后進行編碼，代碼游覽和單元測試，最后通過部署和集成集成測試完成一次迭代的開發；交付階段包括項目驗收、部署發布和項目維護。1.2本項目風險識別的過程設計該項目基于根據統一軟件開發過程模型(RUP)構建的軟件開發過程。在風險識別管理過程中，項目特征被完全整合，并且在每個項目階段都將風險識別和開發工作結合在一起。首先，使用工作分解結構方法(WBS方法)來分析項目的各種任務；然后將定性分析與定量分析相結合，以確定應用程序開發風險；最后，使用項目的WBS-RBS風險矩陣作為項目的基礎，風險因素分析和總結項目風險識別的狀態。具體的實現過程設計如下：(1)根據Rational提出的統一軟件開發過程模型(RUP)，細分了平臺開發生命周期。該模型從上至下將項目層的工作分析為相對獨立且易于管理的業務部門。在此項目實踐中，該項目首先分為四個主要階段，即啟動，改進，建設和移交；然后結合程序項目的一般特征和項目的某些特殊特征，工作分解結構方法(WBS方法)。分析項目開發過程中的各種活動，并劃分這四個主要階段的工作根據實施步驟將其分為幾個子任務，并創建一個計劃分析項目工作結構。(2)根據項目各個階段的工作內容，初步確定項目風險的范圍；再通過運用文獻分析方法，閱讀大量相關文獻資料，對初步的風險分類表進行分析和總結；然后使用定性和定量分析方法，最后將為TC公司小程序應用項目的風險分為需求風險，技術風險，過程風險，管理風險，同時，為此項目定制風險識別清單。(3)首先，使用業務風險分解結構方法(WBS-RBS方法)將項目生命周期每個階段的業務活動與風險定義列表中的四種風險進行集成，以創建項目WBS-RBS風險矩陣。接下來，是對項目風險識別列表中24個風險因素分別進行分析和說明。1.2項目風險識別方案首先從該項目的WBS開始分析，WBS是對工作任務進行分解，之后是對可能存在的風險要素進行風險識別和風險分析，最終生成一份風險識別清單。軟件研發項目，從項目工作任務和流程角度出發做分解，構建出分解結構圖即WBS，如下圖1.1所示。圖1.1軟件項目工作WBS為了能夠對風險進行全面的評估和分析，結合TC公司小程序項目開發情況，采用風險識別情況和開發任務相結合的方法，使用管理工具WBS，依據圖1.1和表1.2的風險識別清單構建WBS-RBS風險矩陣，判斷標準是1表示存在風險，0表示不存在風險或者說沒太大的影響，得出如下表1.3所示的矩陣表1.3WBS-RBS風險矩陣表WBS-RBS風險矩陣1100120013001400111011201130121012201230131013201330141014201430軟件研發項目風險需求風險RR-01111110111000RR-02111110111000RR-03111111111000RR-04111111000110RR-05111110111000技術風險TR-01000110110010TR-02000110111010TR-03001110111000TR-04000110111010過程風險PR-01111110111100PR-02111110111100PR-03111110111110管理風險MR-01111110111100MR-02111110111110MR-03111110111000MR-04111110111000MR-05111110111000下面根據項目目前的情況，結合WBS-RBS，對分析出的風險因素做出詳細說明：1)需求風險需求分析師的業務能力不強，無法以更專業的語言清楚地表達客戶需求，對系統缺乏足夠的了解，也無法提供相應的原型來幫助客戶和研發工程師了解用戶的真實需求。項目需求管理混亂，缺乏需求管理程序和規范。技術經理隨機更改需求人員設置的需求，使開發人員和需求人員不知所措。由于某些需求討論并未涉及測試人員，因此即使測試人員也不知道需求已發生重大變化，因此他們應基于原始需求文檔編寫測試用例。浪費了大量的人力資源和時間。有時，世界各地的要求并沒有明確描述。在特定的系統開發周期中，客戶渴望上網，并愿意允許客戶添加需求。相反，項目很難按時上線，程序員和測試人員必須加班，整個項目非常累。一些要求嚴格的員工標準有限，并且書面文檔含糊不清，無法有效地反映客戶的需求。該項目上沒有UI設計師，每次滿足需求時都會引起很多意見，并且對需求的理解在每個領域都各不相同，但是很難實現有效的統一。由于系統工作非常復雜，因此公司根據業務部門將其劃分為不同的開發團隊，其開發模型不同，甚至其管理風格也不同。也沒有標準化的溝通方法，因此當需要協調開發新功能時，進展總是很緩慢。世界各地不同地區的業務分析師僅了解其所在地區的業務，但他們對整個系統了解不多，因此，通常會有一些相同或相似的需求。有時，某個特定區域提出的要求已經在系統中，但是各個位置有所不同，可以通過相應的配置來實現。對于系統發布的每項新工作，一些需要它的人都不會理解和認真學習，至于系統的新功能，這對他們來說是一塊白板。2)技術風險該項目沒有架構師，技術還沒有制定統一的標準，這導致在每個領域開發出不一致的標準，從而使代碼難以理解。每個程序員根據他們的編碼習慣進行開發，最終很難維護，這使得查找特定的功能單元并修改代碼相應地浪費了時間。盡管界面樣式可以保持相對統一，但是由于設計公司必須在開始時就創建標準的界面樣式，但是隨著后續需求的增加和更改，代碼中的更改也隨之增加。每個人都可以根據需要修改原始代碼。然后一些設計規范使后期維護變得非常困難，有很多重復的代碼，這些重復的代碼不是在通用代碼庫中提取的，通常更改需求需要進行許多更改。該代碼高度依賴，并且簡單的更改將影響許多模塊，從而使開發人員不相信自己的更改。在沒有單元測試的情況下，由于工作的復雜性，程序員需要花費大量時間來模擬合適的測試工作場景，因此單元測試可以有效地解決這些問題。在編碼階段，由于早期的設計問題，代碼混合了，沒有選擇適當的技術來解決問題。編碼不符合面向對象設計的原理，最終的代碼彼此之間更加兼容，并且稍有更改就會影響很多地方。3)研發過程風險項目流程管理不規范，沒有統一的流程管理機制，系統版本仍采用手動版本模式，每個版本包含十多臺服務器，極容易出現錯誤和文件丟失。缺少代碼匹配的分發管理工具來提高工作效率。沒有統一的系統來進行項目管理和跟蹤，錯誤系統很多，有時需要在一段時間后繼續執行錯誤，并且報告錯誤的過程也在不斷變化。錯誤階段的狀態使開發人員很難與測試人員打交道，并且有時必須消除由不同區域的用戶報告的問題，并在不同的系統中消除它們，這很煩人并且不易跟蹤。為了處理不同的開發階段，開發經理創建了測試環境的不同階段，例如DQA，DQA2，PRE-PROD，PRE-PROD2，IMP和PRO。某些環境實際上不需要多個副本，這不僅加重了開發人員集成代碼的工作量，而且直接使測試人員的工作量加倍，而沒有任何重大影響。代碼分支管理很混亂，甚至需要在每個月的不同階段創建相應的代碼分支，因此每次都必須從服務器重新獲取新代碼。該代碼具有很大的容量，通常為4GB，并且必須進行更新。建立開發環境會浪費大量時間，這會使開發人員無法有效參與開發。4)團隊管理風險這主要與團隊合作問題有關。團隊的內部工作效率低下。項目經理的領導力不足，經驗不足，無法很好地領導團隊和激勵團隊。團隊角色并不清楚。關于員工的組織結構，產品團隊占主導地位，對項目有很大的看法，而研發團隊則有觀點，下屬相對較少，以便對項目，產品有更大的看法和獨立性。團隊和研發團隊是具有合作和競爭關系的團隊。有時，員工不喜歡被動地接受分配給他們的任務，尤其是在他們不擅長的領域。如果任務不是他們想要做的，那么他們就不會非常主動，容易出現問題，甚至產生負面情緒。例如，允許擅長業務和后臺數據的人員實施前端UI設計不僅無效，而且還容易出現錯誤。團隊并不熱情，基本上沒有小組活動。團隊建設(團隊建設)離開的情況要少得多。除工作外，同事很少有機會在其他場合表達自己的感受。缺乏領導能力。當現任團隊領導和管理團隊時，團隊非常和諧團結，如果遇到問題，他們愿意互相幫助。主要原因是領導者沒有準備好按自己的意愿批評和指責他人，并且他們不允許團隊成員這樣做。即使有問題，您也可以私下聯系并解決。同時，它還努力營造團隊之間的互助氛圍。當前的領導層正好相反，因此，如果系統出現問題，他們將跳槽并指責其他人。您做得越多，您犯的錯誤就越多。如果做得不好，就不會有批評。成員中的每個人都處于危險之中，沒有人愿意承擔責任。團隊成員溝通和協調問題。團隊中只有一兩個人無法有效地溝通并報告工作進度。當成品即將上線時，報告完成進度仍為99％。驗證代碼后，發現許多不完整的功能。最后，讓項目成員一起努力進行調整，很容易在工作中犯錯誤。1.3項目風險分類根據上圖列舉出來的WBS內容，我們建立了基礎的風險分類清單，具體試下：表1.1風險分類表風險分類描述需求風險主要涉及軟件需求方面的范圍、變更、分析、管理等風險技術風險主要涉及技術、架構、設計、模塊等風險過程風險主要涉及開發流程、配置工具、項目開發工具方面等風險管理風險主要涉及項目團隊管理、領導力、溝通協調、組織架構等風險在表1.1的基礎上，對風險類別進行了詳細分類，并對細化后的風險進行了編碼和識別，如下圖所示的風險分類明細表見表1.2。表1.2風險分類明細表風險類別識別代碼風險描述需求風險RR-01需求求不是很清楚或太詳細，說明也太籠統。這導致用戶，開發人員和測試人員的理解不同，從而增加了通信成本。RR-02需求變化頻繁，沒有明確的起點和終點，沒有對應的需求變化管理流程，產品可以隨意修改，并非所有的參與者都能收到穩定的文檔輸出。RR-03需求分析不足，用戶參與不度不夠，消用戶反饋的內容得不到及時響應，導致后續產品與用戶需求之間存在重大差異。RR-04需求管理不規范，以至于文檔混亂、需求設計混亂、沒有一個標準的需求管理文檔管理工具和流程。RR-05不恰當和不合理的需求，由于開發人員沒有參與需求評審，導致和當前系統的設計有很大的出入，導致技術研發成本大幅度上升。技術風險TR-01項目技術架構混亂復雜，或者說沒有架構TR-02開始沒有統一的研發規范，技術標準文檔也沒有，界面、代碼等設計編寫風格不統一TR-03有很多重復的代碼，沒有創建可重用的模塊，也沒有人負責定期的代碼更新TR-04軟件的設計沒有遵循客觀設計的原則，每個模塊的設計不統一，軟件模塊的兼容性很高，變化會影響很多地方。過程風險PR-01沒有使用適當的項目管理工具來提高工作效率，例如代碼管理工具，文檔管理工具、bug管理工具等等。沒有自動化的系統集成工具。沒有使用配置管理工具，重復性工作太多，缺乏配置管理。PR-02沒有使用配置管理工具，重復性工作太多，缺乏配置管理。PR-03沒有一套標準的開發管理流程，沒有確定項目標準，代碼管理混亂，各個階段研發狀態不明確管理風險MR-01領導力不足，項目管理經驗不足，不能使團隊離效合作。MR-02人員的組織結構，分工，架構分配不合理，角色分工不明確MR-03任務分配沒有發揮組員的特長，沒有讓正確的人做正確的工MR-04通管理有問題，溝通不暢。內部協調效率低下。MR-05管理層對團隊的支持不夠，有效的推動溝通