軟件項目本來就復(fù)雜，而復(fù)雜的軟件項目若無細心的規(guī)劃就不可能成功。一個良好策劃過的項目會被有效控制著，其進度操控自如，且會照顧到參與項目進行者的福利。軟件項目本質(zhì)上也是危險的，缺乏風(fēng)險管理就不可能獲得成效。從頭保持跟項目的使用者聯(lián)系，努力將產(chǎn)品維持在滿足客戶的要求之上，并盡全力把焦點放在找出項目關(guān)鍵問題的解決方法上。

小項目可以只靠著毅力與運氣而完成，中型和大型項目則需要更多系統(tǒng)化的做法。本文將概述一些讓中型項目達到成效的技巧。

規(guī)劃

許多技術(shù)工作者寧可直接做自己的工作而不想花時間規(guī)劃一下工作方向。許多技術(shù)主管缺乏足夠的技術(shù)訓(xùn)練并且不相信自己可以規(guī)劃出改善項目的方式。由于兩邊都沒人對項目好好規(guī)劃，結(jié)果就是項目常常窘?jīng)r百出。

沒有一套規(guī)劃方式是項目中最嚴重的錯誤之一。由于上一篇中描述的上下游效應(yīng)，想在修正成本較低的上下游階段將問題解決掉，一套有效的規(guī)劃方式是必要的。一般項目約80%的時間花費在未經(jīng)規(guī)劃的重復(fù)工作上。

軟件開發(fā)的成功歸功于讓所有錯誤變成一堆細心規(guī)劃過后的小錯誤，避免出現(xiàn)未經(jīng)規(guī)劃的大錯誤。研究四種設(shè)計方式后，放棄其中三種，最多也不過是造成三個小錯誤而已?？墒菦]做好設(shè)計工作而必須把程序重寫三遍的結(jié)果，卻嚴重到可能造成三個大錯誤。由于在下游階段修正上游造成的錯誤比在上游階段就修正好問題要多花費50～200倍的代價，細心協(xié)調(diào)過的項目就有機會以1/200～1/50的代價將許多錯誤修正好。

項目中哪里找得出時間來進行規(guī)劃？很簡單，把大部分項目花在未經(jīng)規(guī)劃的重復(fù)動作上的時間中的一小段拿來用在項目初期的規(guī)劃上，避免之后將時間花費在高代價的重復(fù)動作上。盡管并非所有上游階段用去的時間都會確實省去下游階段該處理的麻煩，但是省下的麻煩還是很多。在上游階段質(zhì)量保證的經(jīng)驗法則是：用在進行技術(shù)檢閱等早期規(guī)劃工作上的一小時可以省下下游階段3～10小時的工作時數(shù)。從不同的觀點來看，一名開發(fā)人員每天花在項目要求規(guī)格或架構(gòu)上檢查的時間一般會省下后一階段中3～10天的工作時數(shù)。

軟件規(guī)劃的例子

一個項目團隊該如何規(guī)劃項目，以在一定預(yù)算內(nèi)完成軟件？底下是一些項目規(guī)劃的具體工作項目：

◆一個軟件開發(fā)的規(guī)劃反映項目進行的方式。把規(guī)劃方式記錄下來可以讓項目的資助者透過這份規(guī)劃來了解項目。

◆項目評估提供了項目規(guī)劃的基礎(chǔ)。一份仔細的評估可以確切地定出項目的規(guī)模，從而確切地定出預(yù)算上限、人員需求與時間需要。差勁的評估會低估項目在各方面的需要成本，使項目難以順利而有效地完成。

◆在每個主要階段末尾作個修正評估，可以中途修正項目成本，并讓項目的進行以穩(wěn)健的步伐前進。

◆一份包含技術(shù)審查與測試的質(zhì)量保證規(guī)劃，可確保項目不會被代價高昂而找不出錯誤的測試、除錯和修正周期壓垮。

◆一份詳細規(guī)劃出軟件構(gòu)建的方式，可確保軟件解決方案有效地在各階段以提高對客戶價值和降低風(fēng)險的方式進行。

除了以上這些明確的規(guī)劃方式，軟件項目的幾個主要活動也可以被規(guī)劃處理。

◆詳細訂出項目團隊試著要解決的問題，確定正確解決問題的方式。

◆構(gòu)架設(shè)計出解決問題方式的大體規(guī)格，建立正確的解決方案。

◆細節(jié)設(shè)計是關(guān)于如何建立項目軟件的綜合規(guī)劃，以正確的方式建立正確的解決方案。

規(guī)劃審查

規(guī)劃方式對項目的成功是如此的重要，一些專家說項目的成敗完全決定于項目初期10%的時間內(nèi)。不管確實比例是10%還是多少，在項目的最早期，項目團隊應(yīng)該已經(jīng)訂出使用者接口雛形、細部要求跟包含成本與時間預(yù)估的細部項目規(guī)劃，而這些信息可以用來決定要不要讓項目進行下去。

兩階段出資方式

一些組織中對軟件項目經(jīng)費的問題在于項目主管在完成一些探索性的工作前就得要求上頭支出必要經(jīng)費。這樣的請款要求必然失準，因為對軟件了解不足。軟件業(yè)界的經(jīng)驗是，在項目初始階段的估計或多或少，可能會跟實際的要求差距達四倍。

一個較好的辦法是讓項目主管把經(jīng)費要求分作兩個階段。項目主管先在項目完成初期10%到20%的探索階段要求第一次經(jīng)費。到了階段結(jié)尾，項目團隊進行一次規(guī)劃審查，同時資深管理階層或是客戶決定要不要繼續(xù)推動項目，然后再撥項目剩下的部分經(jīng)費。這時項目成本仍有可能變動，不過先前已經(jīng)完成的部分會讓整個成本變動范圍從四倍縮小到50%左右。

準備規(guī)劃審查

在進行規(guī)劃審查之前，得先要有下面的準備：

◆決定好項目關(guān)鍵決策者
◆前景敘述
◆該軟件的業(yè)務(wù)狀況
◆初步努力與時程目標
◆初步努力與時程目標估計
◆十大風(fēng)險列表
◆使用者接口風(fēng)格簡介
◆使用者接口細部雛形
◆使用手冊/使用需求規(guī)格
◆軟件質(zhì)量保證計劃
◆軟件開發(fā)細節(jié)規(guī)劃

上述每一項準備在本書其他部分會更詳盡的解說。

如果這些項目都沒準備好，表示還沒有足夠信息來決定項目的質(zhì)量如何，就不用進行
規(guī)劃審查了。如果項目團隊一直都沒能夠做好這些規(guī)劃審查的準備，失敗的風(fēng)險很大。

做好這些準備所需要的時間依據(jù)軟件所需要的工作量而定。當一般使用者知道他們要的軟件是怎樣的情形下，這個準備時間可能只需要軟件總開發(fā)時間的10%。一般情況下，這段準備時間會占總開發(fā)時間的10%～20%。在一些項目中，這項工作最困難的部分是幫助一般使用者理清他們要的是什么，所以偶爾這部分的工作會占用總開發(fā)時間的25%以上。對規(guī)劃審查的經(jīng)費要求與計劃應(yīng)該將這項工作的變動考慮進去。

規(guī)劃審查的一般項目

規(guī)劃審查應(yīng)該集中在下列各項目上：
◆本來的產(chǎn)品概念仍然可行嗎？
◆發(fā)展一個滿足項目前景敘述的產(chǎn)品可能嗎？
◆該軟件的業(yè)務(wù)狀態(tài)在更新、更精確的成本與時間估計出爐后依然差距不大嗎？
◆項目的主要風(fēng)險可被克服嗎？
◆使用者與開發(fā)人員都能夠同意使用者接口的細節(jié)雛形布置嗎？
◆使用說明/使用需求規(guī)格是否完整而穩(wěn)定，足以支持更進一步的開發(fā)工作？
◆軟件開發(fā)計劃是否完整，并適合進行更進一步的開發(fā)工作？
◆完成項目所需的預(yù)估成本為多少？
◆完成項目所需的時間安排如何？

在項目開頭10%～20%的完成部分應(yīng)該足以解答這些問題，而且這些問題的答案應(yīng)該足

以讓客戶或上層主管決定是否要繼續(xù)撥款進行項目的后面階段。

規(guī)劃審查的主要好處

讓軟件組織將軟件項目經(jīng)費分成兩階段處理至少有三種好處。首先，被取消的項目常被看成失敗的案子，可是一個進行了10%～20%就取消的項目反而應(yīng)該視為徹底成功。完成80%～90%才被取消的項目所耗用的經(jīng)費足以負擔(dān)許多在探索階段進行10%～20%就取消的項目。

再者，將龐大的經(jīng)費延遲到項目完成10%～20%之后再撥款的話，可以對項目所需的龐大經(jīng)費做出更可靠的要求。

最后，要求項目主管先完成項目的10%～20%才能要求撥款進行下面的部分，可以讓這些主管做好與對項目成功息息相關(guān)的上游工作。這些工作往往被省去或忽略掉，帶來的損失只有到項目下游階段必須花費昂貴的成本來修正許多錯誤時才會突顯出來。如果項目團隊被要求在下游工作之前完成最重要的上游工作，項目的整體風(fēng)險就會大大地降低。

風(fēng)險管理

風(fēng)險管理是一種特殊的規(guī)劃方式。進行過大中型軟件項目的人都親身體驗到許多事情都可能出錯。最成功的項目就是采取積極步驟以免屈服在這些問題的困擾之下。你也許是完美主義者，可是對軟件項目而言，就如人們說的，你可以有最佳期望，但是應(yīng)該要有最壞準備。

幾種最嚴重的軟件項目風(fēng)險與規(guī)劃方式息息相關(guān)：

◆沒規(guī)劃好。
◆沒照著規(guī)劃方式做好。
◆沒在項目環(huán)境變化后修正好規(guī)劃方向。

在軟件項目中不采取積極的風(fēng)險管理就是忽視軟件業(yè)界在過去幾十年中從幾千次教訓(xùn)

中總結(jié)的一個經(jīng)驗：軟件開發(fā)是高風(fēng)險的活動。如果項目采取積極風(fēng)險管理的方式，就可以避免或降低許多風(fēng)險，而這些風(fēng)險有許多如果沒處理好，就可能使項目陷入癱瘓中。

本文求生策略中包含（并在本書其他部分談到）的做法比起其他方式風(fēng)險更低，并能夠增強對其他類型的項目風(fēng)險的發(fā)現(xiàn)與控制，而被選錄。對軟件項目中要不要采取風(fēng)險管理策略，你沒什么選擇余地。如Tom Gilb在《軟件工程管理原理》（Principles of Software Engineering Management）一書中所說的，如果你不積極面對軟件項目中的風(fēng)險，你就會碰到這些問題。

項目控制

本文的一個主旨是，軟件項目可被控制，從而迎合時間、經(jīng)費跟其他目標。對一些人來說，這種項目“控制”的點子簡直慘無人道，令人想象起一名專制的項目主管以皮鞭和銅鏈展現(xiàn)威權(quán)的樣子。

--------------------------------
項目“控制”的反面就是項目失控。
--------------------------------

人們也許，會認為項目即使沒人控制方向，也會順利地進行下去而不會失控。我的想法和經(jīng)驗都告訴我那是不可能的，

有些人反對項目控制，因為他們認為這表示控制項目成員的行動。事情并不是這樣，項目控制所控制的是項目本身。下面是一些我所指的“控制”的意思：

◆選用一種軟件生命周期模型，如本文中使用的階段完成模型，給項目中技術(shù)性工作一個輪廓構(gòu)架。
◆管理需求的改變，只接受必要的改變。
◆確立設(shè)計與程序?qū)懽鳂藴剩乖O(shè)計方式與源代碼以彼此一致的方式產(chǎn)生。
◆建立項目的細節(jié)規(guī)劃，使每一名開發(fā)人員的工作朝項目目標前進而不會防礙到其他人的工作。

控制并不是良好的技術(shù)性工作的附屬品。項目控制必須透過積極的項目管理與持續(xù)漸進的控制行動來落實。項目控制的具體行動將在本文其他部分談到。

項目洞悉力

與項目控制密不可分的是“洞悉力”的概念，這是指決定項目真實狀態(tài)的能力。項目是否進行在時間、預(yù)算目標的10%范圍內(nèi)，項目是否按部就班地達到質(zhì)量目標，或是遠遠落后目標？如果項目團隊答不出這樣的問題，這支團隊就缺乏足夠的洞悉力來控制項目。

下面是一些改進洞悉力的方法：

◆用前景敘述或目標來訂出項目的概括目標。如果你不知道項目的行動方向，項目大概就推動不了了。
◆在項目完成10%后做一次規(guī)劃審查，看看項目可行與否，以決定是否該完成這個項目。
◆經(jīng)常比較實際進度跟規(guī)劃進度，以決定規(guī)劃方式是否有用，是否需要修正。
◆用二元完成點決定該做的事情是否完成。完成點只有“做好了”和“沒做好”兩種狀況，因為事實證明，從“完全做好了”讓步到“90%完成”只會讓項目狀態(tài)信息的質(zhì)量從“很好”降到“極糟”。
◆定期將產(chǎn)品做成可推出狀態(tài)，以決定產(chǎn)品的真實狀況，并控制質(zhì)量水準。
◆在每個階段末尾修訂估計數(shù)據(jù)，依據(jù)這些新信息來改善規(guī)劃方式，并更進一步了解規(guī)劃方式中的假設(shè)狀況。

許多項目團隊最后發(fā)現(xiàn)項目洞悉力并不是自動得來的。如果你想要有良好的項目洞悉力，得從一開始就把這一點放在項目規(guī)劃中，而如果你想要有個成功的項目，你就得有良好的洞悉力。

人因工程

軟件開發(fā)需要創(chuàng)意和智能、原創(chuàng)與持久再加上高度的干勁。任何對軟件開發(fā)有效率的做法是，如果項目團隊沒進入狀態(tài)，項目就不可能成功。成員們進入狀態(tài)，但是他們有可能士氣低落，或是缺乏一個可以讓麻雀變鳳凰的靈感，甚至連團隊的核心都可能在推出產(chǎn)品之前就離開工作崗位。

Tom DeMarco與Timothy Lister讓“人因工程（peopleware）”這個顯示出在軟件開發(fā)過程中人類成員才是最重要的字眼變得熱門起來。如果你不是名軟件開發(fā)者，人因工程的一些準則也許會嚇倒你。

照開發(fā)人員的興趣分派工作

一般來說，軟件開發(fā)人員的最大動力就是工作能與個人興趣相符。如果開發(fā)人員發(fā)現(xiàn)工作有趣，他們就會發(fā)揮高度干勁。如果他們覺得工作很無趣，就會趣味索然。Robert Zawacki研究了十五年后指出約60%的開發(fā)人員的生產(chǎn)力來自個人有興趣的工作上。要讓人們發(fā)揮最佳生產(chǎn)力，請依據(jù)開發(fā)人員的個別興趣來分派工作。

---------------------------------
有些人的干勁來自不可能達成的目標。
可是開發(fā)人員有時太鉆牛角尖了，如果目標達成不了，反而會讓他們失去干勁。
---------------------------------

讓開發(fā)人員知道你真的欣賞他們的成就

就像其他人一樣，開發(fā)人員也喜歡別人對他們的賞識。如果項目主持人真心贊賞開發(fā)人員，他們對項目就會更加投入。如果主管對他們的贊美虛偽而做作，他們也以虛應(yīng)對。不要用敷衍手法、離譜的目標或金錢誘惑來挑動開發(fā)人員的干勁。

提供思考導(dǎo)向的辦公室空間

軟件開發(fā)既要有發(fā)現(xiàn)也要有發(fā)明，缺一不可。整體過程中最好的環(huán)境就是既輕松又可以自在思考的場所。開發(fā)人員要如同數(shù)學(xué)家或物理學(xué)家般聚精會神。試想如果愛因斯坦坐在辦公桌前聽著他的主管責(zé)罵他說，“愛因斯坦，我們現(xiàn)在就要看你的相對論！快把它寫出來！”你想他做得到嗎？（譯注：愛因斯坦發(fā)表相對論時還只是個郵局職員）況且軟件開發(fā)人員遠不如愛因斯坦般聰明，他們需要更有助于工作的環(huán)境。

避免采用開放式工作隔間

有個老生常談的論調(diào)，說開放式的工作隔間有助于軟件項目間的溝通。問題在于這樣的隔間溝通起來反而雜亂無章，連帶影響生產(chǎn)力。有效率而良好的溝通還不如在茶水間放部汽水機來進行。開放式工作隔間有助溝通的論調(diào)乍聽起來很吸引人，可是經(jīng)不起確切考驗，而且軟件研究資料清楚顯示開發(fā)人員只有在一兩個人的辦公室內(nèi)最具生產(chǎn)力。

一些研究發(fā)現(xiàn)開發(fā)人員在隱密、安靜、一兩個人的辦公室內(nèi)工作和在開放式隔間的辦公室內(nèi)相比，前者的生產(chǎn)力比后者要高出2.5倍。軟件開發(fā)是個需要高度思考的活動，如果電話響個不停，廣播系統(tǒng)播個沒完，人們在你四周走來走去，每隔幾分鐘就來打擾，怎么可能專心思考問題。

---------------------------------
身為主管的工作要求是每隔幾分鐘就轉(zhuǎn)移注意力以達到管理效果。
---------------------------------

一般軟件開發(fā)人員要求幾個鐘頭內(nèi)最好不要轉(zhuǎn)移注意力，才能專心。許多組織沒辦法提供開發(fā)人員安靜隱密的辦公室。他們有的是空間不足，有的是要留給副總裁之類的人用。有些組織發(fā)現(xiàn)，將他們的開發(fā)團隊安排到另一個環(huán)境去會更好些。其他組織則試著讓開發(fā)人員帶著耳機工作杜絕干擾，或者干脆讓他們在家工作。至于其他沒辦法提供開發(fā)人員安靜隱密而不受干擾的組織，只好自求多福了。

使用者參與度

軟件使用者參與的程度對軟件項目很重要。軟件成功的關(guān)鍵在于設(shè)計出一般使用者愛用的產(chǎn)品。如果沒有使用者的參與，軟件開發(fā)人員常常會考慮技術(shù)層面而忽略使用者的需要。這樣的話或許軟件產(chǎn)品中塞進過多功能，使用者實際用到的卻沒幾種。

要想開發(fā)出使用者愛用的軟件產(chǎn)品惟一方法，在于問問使用者的是什么，把開發(fā)中的產(chǎn)品先告訴使用者，并問問使用者喜不喜歡這東西，聆聽使用者的心聲并參考他們的意見。

也許項目團隊得努力好幾次才能了解使用者要的是什么。使用者們也必須了解開發(fā)人員讓他們看的雛形跟未來的成品也許相差十萬八千里。有時有分辨出哪些可能是未來的“使用者”都有困難。這些都會在以后提到。

由于使用者的參與消除了一大變量——摒除了“差不多先生”的心態(tài)，這樣一來項目所費的時間就少得多了。如果使用者沒從頭參與，以后對項目產(chǎn)品進行檢視時，一定會指出有好些地方?jīng)]照顧到他們的需要。這時開發(fā)團隊就得面對一個艱難的抉擇：依循原來的預(yù)算與時程目標而忽視使用者意見，或是在項目的下游階段接納使用者意見而讓預(yù)算跟時間超出預(yù)期限制。通常開發(fā)人員會妥協(xié)，先采用可立即修正的使用者意見，而將難以立即采用的意見留到程序的下個版本去處理。說老實話，讓使用者在產(chǎn)品還具可朔性時愈早參與愈好，而且最好是在那些不被喜歡的東西出現(xiàn)以前。

由于“做了比沒做好，早做比晚做好”的觀念，使用者對自己參與開發(fā)過程的項目反而比沒讓他們參與的期望更深。表面上，愈早讓使用者參與開發(fā)的軟件愈能滿足使用者需求與期望，而這也成了一種質(zhì)量的認定方式。實際上這樣的軟件缺陷的確更少，因為它們在開發(fā)過程中方向變動較少，而讓產(chǎn)品架構(gòu)、設(shè)計方式與實作更穩(wěn)定。如果在項目中途才加入使用者需求，被迫將沒想到的功能加進體質(zhì)不良的現(xiàn)有構(gòu)架中時，軟件質(zhì)量一定會大副下降。

除了及早參與、持續(xù)參與外，很少有軟件項目一開始就找出真正良好的解決方案，一般都必須在使用者坐下來說“是的，這就是我要的軟件”以前做出不同版本的使用者接口雛形。一個良好而成熟的使用者接口雛形可以讓項目推出后廣受歡迎，不過軟件的適用性得在開發(fā)時就調(diào)練好。參照使用者所需導(dǎo)向而做低廉、小型的修正，就不用到了項目末期再大興土木以致付出高昂的代價（本文使用的階段性完成策略提供了這樣的過程中修正方式）。

參予開發(fā)過程的使用者用不著很多，在Jakob Nielsen的《Usability Engineering》一書中指出，當軟件適用與否的測試人數(shù)在3～9個時，價格獲益比最好。

在1994年，Standish Group對8000件以上的軟件項目進行檢查。結(jié)論是使用者的參與是項目成功最顯著的因素。在那些失敗的項目中，缺乏使用者反應(yīng)是失敗的主要因素。計算機軟件的專家指出快速開發(fā)項目能夠成功的最重要因素在于讓一般使用者全程參與開發(fā)過程。

----------------------------------
讓使用者參與項目開發(fā)過程可說是重要的軟件項目求生技能。
----------------------------------

產(chǎn)品簡化主義

成功的軟件項目開發(fā)從需求制定到產(chǎn)品推出、繼而被接受，都需要一種“化繁為簡”的定位方針。因為軟件開發(fā)工作相當費神，若能將項目徹底簡化必然事半功倍。功能規(guī)格、設(shè)計與實作都應(yīng)該簡化。許多開發(fā)人員沉迷與復(fù)雜性，誤以為“數(shù)大便是美”，事實上只有簡化項目才是成功的唯一出路。

當開發(fā)人員致力尋求項目目標流程的簡化時，可說又向成功邁進了一大步，對一般使用者也可能造成影響。一個功能通?？煞謨尚r版、兩天版和兩周版，開發(fā)人員應(yīng)該一開始先弄出兩小時版，通常這個版本的解決方案最簡單直接，問題最少。開始實際操作后，如果解決方案還不夠，他們才應(yīng)制作兩天版甚至兩周版的解決方案，再看看這樣是否可以解決問題。解決問題的一貫態(tài)度是，先簡單后復(fù)雜，才不致于因噎廢食。

法國作家Voltaire說一篇散文不是在“增一字則太多”時完成的，而是在“減一字則太少”時完成的。軟件項目亦同，應(yīng)該是從軟件中去除不必要的東西以進行簡化，而不是不斷加上更復(fù)雜的東西。

焦點防在推出軟件

有效率的開發(fā)團隊全心全力著重產(chǎn)品的推出。微軟公司尤其重視“產(chǎn)品推出”。對產(chǎn)品推出有功的開發(fā)人員會獲得一個“產(chǎn)品推出”獎，感謝他們的努力。在微軟工作了許多年的開發(fā)人員一般都有一大堆產(chǎn)品推出獎。這樣簡單的做法強調(diào)一件事，微軟公司不是靠著開發(fā)軟件賺錢，而是靠推出產(chǎn)品賺錢，當然這也是大部分生產(chǎn)軟件的公司賺錢的方式。

對于無論是替內(nèi)部使用者開發(fā)軟件或?qū)σ话愦蟊姲l(fā)行軟件的開發(fā)人員來說，焦點是一樣重要的。一個清晰的前景描述可以讓任何軟件開發(fā)團隊對產(chǎn)品推出的目標相同。如果開發(fā)人員到了項目結(jié)尾都還對產(chǎn)品的看法有歧義，將被迫花費上許多時間、努力與金錢來讓他們的看法一致。

一個清楚的架構(gòu)也有助于讓開發(fā)團隊在目標上步伐一致。反之，就難以同心同德。如果一套良好的產(chǎn)品架構(gòu)確立了，項目的開發(fā)焦點自然集中在技術(shù)層次上。

軟件開發(fā)團隊必須確保每個技術(shù)性決定都朝著簡化系統(tǒng)功能的方向前進。如果是開發(fā)大學(xué)教育項目，也許有必要讓項目任意復(fù)雜化。不過當團隊在開發(fā)商用產(chǎn)品時，他們的任務(wù)是提供最簡單的問題解決方案，任何違反這些原則的決定都應(yīng)被否決掉。

本文所要傳達的信息是軟件開發(fā)工作本質(zhì)上主要為了滿足實際目標，這個工作有著濃厚的美學(xué)標準與科學(xué)成分。有效率的軟件開發(fā)人員了解軟件項目不是為了讓他們有個筑夢堡壘，而他們也依此排定各項條件的優(yōu)先級。微軟公司的經(jīng)驗顯示，這樣得到的行動方針能夠在項目團隊中培養(yǎng)。沒有共識的開發(fā)人員對于項目是一個累贅，對組織可說沒什么用處。

====================================================================
求生檢查