軟件項目管理與素質拓展-2.2什麼是項目

時間 2019-11-12

標籤軟件項目管理素質拓展 2.2 什麼項目简体版

原文原文鏈接

2.2.1項目的特徵算法

　　三國演義中羣英薈萃，鬥智鬥勇，最出彩的章節莫過於赤壁大戰了。周瑜全局戰略眼光不夠，加上心胸狹窄，就老想給諸葛亮下套以除掉他。「草船借箭」就是其中很經典的一齣戲。咱們看看兩我的的鬥智鬥法。數據庫

　　江面上做戰主要靠弓箭，周瑜藉口東吳軍中缺少羽箭，請諸葛亮負責督造羽箭。督造羽箭工做有明確的任務目標：十天造十萬支箭，貽誤軍機，軍法處置。沒有明確的目標，行動就沒有方向，就成了盲動，努力越多，資源耗費越多，距離目標可能越遠。執行過程當中，通常容許審時度勢，對目標作適當的調整。服務器

　　諸葛亮雖知周瑜故意刁難，但督造羽箭有助於孫劉聯合抗曹，加之胸有成竹，就立下軍令狀：何需十天，三天就足夠了。架構

　　造箭須要工匠、器材，周瑜不給人、不給物，諸葛亮只能求助於魯肅。對諸葛亮而言，最重要的資源就是魯肅。魯肅具備全局戰略眼光，認識到孫劉聯盟若是破裂，必將被曹操各個擊破。魯肅是東吳的參謀長，具備資源調配的權力：二十條船、六百名軍士、青布、稻草、鼓號，聽候調用。諸葛亮讓人用青布幔子把船蒙起來，紮了一千多個草把子，排在船兩邊，船上架起鼓號。併發

　　所謂「兵無常勢，水無常形」，每項軍事行動都有其獨特的地方，沒有兩項軍事行動會徹底同樣。爲何諸葛亮這麼有把握？首先，他事前從江中老漁翁那瞭解到三天內必有大霧；其次曹操生性多疑，諸葛亮料定曹軍大霧天不敢出擊；最後有個難能難得的魯肅，從大局出發，瞞着周瑜，爲諸葛亮配齊所需的全部人員、物資。這三方面條件缺一不可，可遇而不可求。設想一下：若是周瑜是提早十天給諸葛亮下的套，若是曹軍主帥是許褚，若是魯肅那段時間正好回南鄭見孫權不在軍營。只要其中有一個若是成立，諸葛亮就會性命不保。運維

　　每項軍事任務都有一個明確的起點和終點，不是沒完沒了或重複進行。十萬支箭點驗完畢，銷燬軍令狀，六百名軍士、20條船交還魯肅，任務即告結束。草船借箭是一錘子的買賣，打死都不會有第二次的。諸葛亮不會第二次冒險，曹操不會上第二次當。數據庫設計

　　「草船借箭」是一個典型的項目（Project），諸葛亮是對項目負全責的項目經理（Project Manager，PM）。項目做爲一種特殊的活動，具備如下特徵：性能

　　1．目的性測試

　　每一個項目都有一個明確的目標。草船借箭的目標是三天造十萬支羽箭。一個全省集中的呼叫中心項目的目標是：創建覆蓋全省的統一的電話服務平臺、短信服務平臺、互聯網服務平臺以及大客戶服務平臺，實現流程自動流轉、服務高效便捷、監管實時到位。優化

　　2．一次性

　　每一個項目都有一個明確的開始日期和完成項目的結束日期，沒完沒了或重複進行的工做不叫項目。時間方面的限定性要求是項目各方異常關注方面。由於是一次性的任務，因此又帶有臨時性的特色，項目團隊是臨時組建的，項目目標達成之日，就是團隊解散之時。

　　3．獨特性

　　每一個項目都有其獨特的地方，沒有兩個項目會徹底同樣，沒有徹底能夠照搬的先例。每一個項目的目標、工做內容、資源需求、客戶參與、實施團隊、實施環境等都不盡相同。項目不能徹底程序化，每一個項目都會面臨新的問題、新的挑戰。項目經理對各類問題的處理須要因時、因地、因人而異。

　　4．相互依賴性

　　任務有前後，資源要保證。每一個項目都是由一系列相互關聯的任務組成的，許多不重複的任務以必定的順序完成，才能達到項目目標。每一個任務的完成須要運用各類不一樣的資源，如：資金、設備、物資、人員、關係、信息等。領導、同事、客戶、下屬、夥伴是項目資源庫的重要組成部分。

　　5．不肯定性

　　項目的特殊性使得人們在項目開始之初通常很難確切劃定項目的工做範圍，準確估算完成任務所需的時間、成本，徹底預見全部可能的項目風險，由此致使初期工做計劃制定的困難。隨着項目的推動，一些原先不肯定的因素慢慢浮現並肯定，各方對項目的認識理解逐步清晰並統一，項目風險逐漸降低，項目經理須要與時俱進地對計劃進行適時調整。

2.2.2項目三角形

　　基於上節對項目特徵的總結，咱們能夠對項目作以下定義：項目是在既定資源和要求的約束下，爲實現某種目的，而相互聯繫的一次性工做任務。

　　首先，這個定義強調項目的目的性。項目目標包括4個方面：

　　（1）範圍目標：要什麼？項目要完成的內容是什麼？

　　（2）時間目標：要多快？項目必須在多長時間內完成？

　　（3）質量目標：要多好？項目交付物須要達到什麼樣的指標？

　　（4）成本目標：要多省？項目人、財、物的投入必須控制在什麼範圍內？

　　思考：這幾個目標中哪些是效果目標，哪些是效率目標？

圖 2‑ 5 項目三角形

　　作得對、作得好是效果目標，作得快、投入少是效率目標。如前所述，效果重於效率，範圍、質量優先於時間、成本。問題真的是這麼簡單嗎？軟件項目中客戶會更關注哪一個因素呢？

　　其次，這個定義強調任務和資源的相互依賴。項目的目標要素間存在某種關聯關係，一個要素的變化會引發其餘的要素變化，沒法尋求全部目標要素同時最優的結果，這就是著名的項目三角形，見圖2‑5 。項目三角形的三條邊分別是時間（Time）、成本（Cost）、質量（Quality），三條邊圍成的面積表明工做範圍（Scope）。其中質量這條邊表明的是：因爲質量低劣所付出的代價。質量越好這條邊越短，質量越差這條邊越長。三條邊與面積之間存在着頗有意思的現象。

　　假設你是一個軟件項目的負責人，原先合同約定完成100個功能，年末上線。項目是年初啓動的，五個月後因爲某種強力緣由，客戶要求提早到國慶上線，並且是做爲一項必須完成的政治任務，你該怎麼辦？

　　加班加點，加大投入，是首先想到的辦法，見圖2‑6 。

圖 2‑ 6 加大投入以壓縮工期

　　問題是：這樣作可否確保提早交付符合質量要求的100個功能，也就是在範圍（S）、質量（Q）保持不變的狀況下，增大成本（C）這條邊，以壓縮時間（T）這條邊呢？咱們知道三角形的面積等於底邊乘以高。若是過與質量相對的頂點，畫條平行線，當三角形頂點在平行線上滑動時，面積保持不變。

　　當頂點向左端滑動時，成本邊逐漸增大，時間邊逐漸減少。增長人員，加班加點，進度能夠被壓縮，任務能夠提早。

　　但時間邊的壓縮是有限度的，當時間邊與三角形的高重合時，進度的壓縮達到最小值。進一步地增長人手，加大投入，非但不能加快進度，反而會因爲人浮於事，相互觀望、效率低下等緣由而延後項目。

圖 2- 7 範圍—工期—質量—成本的妥協

　　若是因爲揹負政治性任務等因素，強行要求進一步壓縮工期怎麼辦？如圖2‑7 有兩個選擇：

　　選擇一：保持面積（範圍）不動，該完成的100個功能一個不落；加大投入的同時，加長低劣質量的代價這條邊，犧牲必定的項目質量，以確保國慶系統上線。

　　選擇二：保持質量不變，加大投入的同時，減少面積（範圍），國慶前先完成影響客戶運營的核心功能，其餘功能在年末前完成。

　　對於這兩種選擇，不能簡單地斷定對錯。

　　客戶能夠忍受按時交付的一個有80%功能的符合質量要求的系統，卻沒法接受一個包含100%功能而質量卻不好的系統。客戶能夠忍受按時交付的核心功能沒有大礙但有很多缺陷的系統，卻沒法忍受大幅延期的項目。交付延遲，意味着客戶的業務目標沒法按時達成，甚至嚴重影響客戶的業務運營、經濟效益、管理效益，這些損失每每要大大超出軟件項目自己的投資。軟件開發公司也將所以付出額外的開發成本與聲譽損失的成本。

　　美國一個未公開的評估報告顯示，17個主要的軍方軟件合同，沒有一個項目按時完成，平均28個月的進度計劃推遲了20個月才完成，一個4年應該完成的任務，7年還未提交。因此有負責人說：「我寧願軟件有錯也不肯被延遲，咱們能夠在之後糾正錯誤。」[SEI01]

　　這又使得不少項目經理陷入「前期重進度，後期重質量」或者「前期過於細緻，後期草草收尾」的誤區。這種先後不一致的狀況主要是因爲對項目工做量及難度估計不許，對自身研發能力與實施能力認識不足，項目資源規劃不科學。前期質量缺陷遺留到後期解決，時間越拖後，代價越大。若是出現大範圍返工，將得不償失。

　　項目推動的過程，就是項目三角形的四個要素動態調整、動態平衡的過程。軟件項目中，時間這一效率目標通常是比較剛性的目標，範圍、質量這兩個效果目標是與時間相關的彈性目標，成本這一效率目標主要取決於軟件開發公司的經營決策。在客戶能夠忍受的範圍與質量前提下，在公司能夠承受的代價下，確保按時交付基本可用的系統。系統交付以後，再逐漸補齊應該作的內容，提升軟件的質量。

　　沒有固定的標準，沒有固定的程式，只有指導性的原則。各方的博弈，火候的拿捏，都是每一個項目經理成長路上的必修課。

　　項目三角形還有其餘一些值得探討的話題，你們能夠本身作些思考。如：零缺陷軟件的代價有多大？項目的最佳投入是多少？時間越充裕質量必定越好嗎？

2.2.3項目與運營活動

　　人類有組織的活動可分爲兩種類型：一類是接二連三、周而復始的活動，稱爲「運營」(Operation)，如公交車的運營、平常教學管理活動；一類就是前面講述的「項目」，如阿波羅登月計劃、三峽工程、奧運售票系統等。兩者的主要區別見表2‑2。

表 2‑ 2 項目與運營活動的區別

	項目	運營
負責人	項目經理	職能主管
組織體系	臨時項目團隊	職能式固定組織
時限性	一次性	周而復始
工做性質	獨特性	不斷重複
運做目標	關注效果	關注效率
運做環境	相對開放和不肯定	相對封閉和肯定
管理模式	按項目的過程和活動進行管理	按部門職能和直線指揮系統進行管理

特定客戶＋特定目標＋必定期限＋必定資源，這才構成項目。

　　思考：如下活動，上課、迎新晚會、集體婚禮、申辦奧運、系統運行維護、教室衛生保潔、神州飛船計劃及我的健身鍛鍊，哪些是項目，哪些是運營？

項目活動的一次性、獨特性，決定了必須首先關注實現效果，在達成能夠接受的效果目標的前提下，再考慮效率，絕對不能由於追求效率而影響了效果。

運營活動是重複性活動，其運營環境相對封閉肯定，經過以往屢次的重複已經驗證其效果達標，所以大多更關注效率，更關注在不斷重複時下降實現的代價。

2.2.4軟件項目

1 ．軟件及軟件的特色

　　IEEE這樣定義軟件：軟件是計算機程序、規程以及運行計算機系統可能須要的相關文檔和數據。軟件能夠形象化表示爲：軟件＝程序＋數據＋規程＋文檔。其中的「規程」是所求解問題的領域知識和經驗，反映了軟件要實現的功能，要支持的業務流程。

　　軟件區別於硬件及傳統工業產品具備明顯不一樣的特性：

　　（1）軟件是抽象的邏輯產品，由0、1集合表示的交互界面、處理邏輯及數據集合。軟件在最終投運以前，誰都沒有徹底的把握下結論 ——「鞋子合不合客戶的腳」。軟件產品的無形性，使得知識及知識產權的管理比較困難，在某種程度上制約了軟件業的發展。

　　（2）複雜性是軟件的本質特性，軟件在規模上可能比任何其餘人工製品都要複雜。它的複雜性源於應用領域實際問題的複雜性和應用軟件技術的複雜性。

　　（3）軟件開發最關鍵的因素是人，生產過程以創造性思惟爲主，研發成本遠遠大於生產成本。軟件產品基本上是「定製」的，軟件開發至今沒有擺脫手工模式。人手不夠、人員流失、能力欠缺、沒有動力、不負責任、單打獨鬥都是項目失敗的一些常見緣由。

　　（4）軟件沒有統一的質量標準，軟件缺陷檢測比較困難。所謂充分完備的測試也只是相對意義上的，沒法作到全面完全。即便通過嚴格的測試試用，也沒法保證軟件沒有潛在的缺陷，幾乎全部的軟件系統都是「帶病上線」。

　　（5）計劃、監督、控制、管理比較困難。軟件涉及的技術更新迅速、需求變化快、時間緊迫，研發工做每每多任務併發、依賴關係複雜、流程繁多且環環相扣，加之個體生產率差別巨大，以至軟件項目的進度、成本、質量每每難以準確估計與控制。

　　（6）軟件維護比硬件複雜許多，管理調整、技術進步、應用水平提升都會對軟件提出更高的要求。軟件維護包括修復缺陷的糾錯性維護，加強軟件功能、性能的完善性維護，以及因應軟硬件環境變化的適應性維護。維護的過程當中又可能產生新的缺陷。

　　（7）受制於不少社會因素，如組織的政治、文化、決策體系、管理方式。

2．軟件行業的現狀

　　上個世紀末曾經有這樣一個傳聞，比爾•蓋茨和通用汽車CEO韋爾奇間有個爭論。

蓋茨在一次計算機博覽會上說：「若是通用汽車像計算機行業那樣跟得上技術發展，咱們都將駕駛每加侖行駛1000英里的25美圓的汽車。」

韋爾奇作出迴應：若是通用開發了像微軟那樣的技術，咱們今天將駕駛有如下特徵的汽車：

不管怎樣，你的汽車都會毫無理由的一天碰撞兩次。
每次重劃公路交通線時，你都不得不買輛新車。
偶爾地，你的車會毫無理由地「Down」在高速上，你不得不「再發動」，而後繼續駕駛。
偶爾地，實施一個控制命令如向左轉，會致使你的汽車莫名其妙地熄火，並拒絕再發動，在這種狀況下你不得不重裝汽車發動機。
每次只能有一我的使用這輛汽車，除非買輛「汽車95」或「汽車NT」，但那樣你將不得不買更多座位。
油、水溫和交流發電機的報警燈將被單一的「通常汽車故障」報警燈代替。
新座位將迫使每一個人有一樣大小的臀部。
汽囊系統在中止運行前將不斷詢問「你肯定要關閉嗎？」
偶爾地，你會被汽車拒之門外，除非你在轉動鑰匙時，同時打開門把手。
要求全部買主同時購買一套道路交通圖，即便他們不須要也不想要，嘗試刪除這個選擇將當即致使汽車的功能減小50%或更多。通用也將變成司法部的調查對象。
每購買一款新車，用戶將都要從頭學駕駛，由於「汽車2000」控制方式與「汽車98」截然不同。
你將按開始鍵，而後關掉髮動機。

　　美國著名的諮詢機構Standish Group自1995年發佈第一份CHAOS報告以來，近二十年的時間裏，對超過9萬個IT項目進行了深刻的追蹤調查，如圖2‑8 。他們發現，雖然在過去的20年裏，IT項目的成功率整體上有所提高，但2012年的報告顯示狀況依舊不容樂觀。能在預算內按時交付規定功能的項目僅佔39%，43%的項目存在延期、超預算或功能縮水等問題，完工前取消或交付後沒有投入使用的項目仍然高達18%。

圖 2‑8 Standish Group的CHAOS報告

　　國內軟件項目情況的數字只會比這更糟糕。很多軟件的開發，僅僅是爲了驗收會上那一個小時的系統演示。驗收會後，服務器直接關機，軟件系統沒有真正投入運行一天。由於在項目立項之初，可能就僅僅是爲了把有限的科技項目資金找個名目開支掉，固然談不上關注軟件的可用性、實用性了。

　　2014年，GAO（美國政府問責署）審計指出，美國國防部信息技術項目頻頻出現預算超支、表現不佳和延期的問題。15個美國軍方主要的自動化信息系統中（MAIS），7個項目的總成本增加範圍從4%到2233%不等，12個項目的時間進度延期從數月到6年不等，有8個項目的性能數據未能達到預期目標。其緣由主要有兩點：