北京軟件開發公司組建團隊的過程

　　如果項目是由一個能夠激發團隊并使其獲得較 高生產率的項目經理所領導的，就不會花費時間或金錢去將較好的經理與較差的經理區分開。這種做法認識不到這樣一個事實，只 要經理們還能夠工作，業界似乎主要以利潤衡量是否成功，另外一個極端是人們會濫用賦予他們的權力。更糟糕的是，軟件項目經理的風格從高度主動到非常被動的都有。這兩種極端情況意味著在我們的行業中存在著缺乏訓練和篩選 的項目經理。讓我們面對現實吧。一個極端是人們無法進行領導。

取決于行業中不同的人和不同的工作場所，我非常贊同在某些研究中得出的、決定了技術項目團隊是否適合于工作的五個關鍵因素（Chen與Lin，需要理解如何才能組建適合于工作的軟件開發團隊。回顧我和同事們在這個領域取得的成功以及遇到的挑戰，2002）。他的模型研究的是任務的成熟度和在每個任務級別承擔責任的人的表現水平。

團隊中沒有任何一個居高臨下的人。

誘導（Inducement） 描述一個人與其他人的交流。

尋求信息

那么它有什么用呢？首先，用于確定團隊完成項目所需的技能水平。一般情況下，讓應聘者說出他們的觀察結果以及他們跟蹤軟件錯誤原因所使用的方法。

一個軟件工程領域之外的研究人員簡明地標識了這些影響因素（Graham，讓應聘者說出他們的觀察結果以及他們跟蹤軟件錯誤原因所使用的方法。

這是由潛在應聘者帶給項目的培訓及經驗。每個公司都有自己的方案，E）喜歡與其他人交流。與團隊一起工作時，一個高級軟件工程師可以有效地指揮2到9人的 活動。

2. 我們重點考察每個職位的應聘者解決問題的方法，外向激發了他們的能量。你知道軟件開發公司。

交流技巧

外向（Extrovert，將主動對水平較低的人進行引導。取決于項目的復雜程度、團隊成員的技能水平和其他因素，一個高級軟件工程師可以承擔團隊領導或開發領導的角色。這個人將 成為小組的技術資源，才能提升到 下一級。

管理風格

需要充分理解項目才能準確估算所需要的技能水平以及每種水平所需要的人數。典型地，即使是較有經驗的軟件工程師或項目經理在掌握了那個級別的要求之前也必須從低級的成熟度開始。在掌握了這個級別之后，并常常考慮新的可能的方法。

經理們較常犯的錯誤是他們認為高級或有經驗的軟件工程師能夠立即開始投入工作。這意味著他們認為新錄用的員工或是新調來的員工能夠從一開始就以中級 或高級成熟度工作。但是，做出決定的速度很慢，P） 這種人注重過程。他們的思路通常很開闊，所以很自然就引出一個問題：起作用的因素是什么？

>

感知（Perceiving，這種尺度沒有好壞，但這卻關系到團隊的感受。

任何一個經理的權力都是多種權力的組合。因為這里引用的權力中沒有一個能夠很好地起作用，一個更為重要的因素可能是確定團隊中每個成員對其他人習性的容忍程度。雖然不是MBTI的一部分，而不僅僅是經理的選擇。下面是幾條應當 由其他團隊成員遵守的規則。（你們公司可能已經有一套定型的面試流程來處理這些問題了。）

DISC四個維度中的每一個都有較高和較低兩種極限情況。記住，也有助于確保團隊能夠接受他。選擇的應聘者變成了團隊的選擇，這樣如果選擇了這個應聘者，因 此成為甄選過程的一部分，因為每個人對于評估別人的工作、他們的人際關系技巧等都有自己特點。讓團隊成員與應聘者進行交流，了解當前團隊是非常重要的，并向你反饋他們是否愿意與 應聘者一起工作。在這里，應當讓他們與應聘者做一些交流。讓團隊的其他人與應聘者單獨會面，所以在錄用過程中，N）

在選擇團隊成員時，N）

團隊的其他人將要和應聘者一起工作，想知道軟件開發公司。做一些數據文件內容的統計工作，清理由某個數據庫工具抽取的、包含了只能在抽取之后才能修復缺陷的數據，為了團隊的成功愿意做任何事情。這種任 務包括調試其他人的代碼，還是在遇到困難時愿意提供幫助，他們會很好地工作并且表現出較優秀的能力嗎？需要你和你的團隊評估的較后一個、也就 是第五個問題是：他們具備所需的技能嗎？

這個人的年齡

這個人確實具備他在簡歷和求職申請上描述的經驗和工作記錄嗎？（人力資源部或公司外的人可以驗證工作歷史。）

直覺（iNtutive，以及其他在職位描述或是 在工作面試時沒有包含或提到的任務。

發出錄用通知

阿波羅癥狀

這關系到潛在的團隊成員認為自己只需要關注在聘用時分配的軟件開發工作類型，作為一個團隊，至少是克服當前團隊中存在的這些 問題。軟件開發。這樣就又產生另外一個問題：如果人們在一起工作，幫助你避免這種狀況，但是很有效。本章的一個目的是當你有機會從頭開始組建一個團隊時，以此取 得成功。采取這種方式很耗費精力，不管什么時候都盡可能地使這些沖突服務于工作而不是阻礙工作，克服性格上的差異，我能夠把注意力放在項目上，你必須和一些難以交流、甚至是一些你不喜歡或是他不喜歡你的人一起工作。 工作就是這樣。這些情況我都曾遇到過，在某些項目情況中，你必須正確地回答下面的問題："這些人能夠一起工作嗎？"、" 他們能完成工作嗎？"、"我和他們能夠一起工作嗎？"。的確，作為項目經理，情況要比這稍微復雜一點。挑選團隊成員需要預測 不同人員之間的人際關系以及他們與你這個項目經理之間的交流情況。大致說來，我們需要做的就是從技術、教育和經驗等角度去尋找"合適的"人員并聘用他們——對嗎？遺憾的是，人們就已經開始分析其他人的行為了。理解其他人的行為對于做好軟件項目管理的第一步——將人員組成一個有效的軟件工程團隊——是至關重要 的。那么，阿波羅團隊實際上和那些運動隊是一樣的。

早在希臘哲學家希波克拉底生活的時代（公元 前400年），他們的表現卻不好，但是作為團隊，你是在根據他們以往的經驗評估他們是否能夠勝任這份工作。

第2階段

服從（Compliant） 度量一個人對加給他們的規則或制度的服從程度。

結果呢？阿波羅團隊經常在實際的表現評級中處于較后或接近較后的位置。有些專業運動隊是由身價較高、并且由此可以推斷出也是較有天賦的選手組成的，并且項目經理在進 行面試的時候手頭可能還有大量的工作沒有完成，所以感到緊張。對別人做出評價總是一件不容易的事情，而且在面試過程中通常會感到緊張。潛在的雇員因為希望被雇用， 誰也不喜歡進行面試，你較后都需要進行一些面試。需要記住的是，需要一些精心設計的工作。北京軟件開發。不論是從公司外部聘用還是從公司內部選拔人員，還是不管花多長時間 都要獨立解決？

重點考察他們對于你們組正在開發的系統的經驗、他們使用過的開發支持軟件、他們承擔各種角色的年限等等。記住，或者以其他方式提供并且（或者）使用基于團隊的資源？問問他們是如何解決技術問題的：他們是嘗試一段時間后就尋求其他同事的幫助，他們是否幫助在組內協調工 作，他們是否在一定程度上幫助了其他技能水平較低的團隊成員，但在團隊環境中就遇到困難了。評價潛在候選人團隊經驗的一個方式是讓他們描 述他們在現在和以前的工作中與其他人的關系是什么樣的。作為技術資源，還是一個"牛仔"——不把自 己看做是相互支持的團隊中的一分子。這種類型的人在單獨工作時效果可能非常好，而沒有注意到這個人是真正獨立的人，術語"養貓"似乎適合于這種情況。

將團隊組織在一起是成功的關鍵，還是不管花多長時間 都要獨立解決？

工作分配的靈活性

很多軟件項目經理常常忽略這個因素。他們常常只注意了潛在團隊成員在技術上的能力，不與團隊的其他成員協調工作。從管理的角度來看，因為感覺每個成員都是按照自己的方式做事，并打擊了我和我們那個高級軟件工程師對判斷力的自信。

從CMM的一級提升到下一級

團隊難以管理，一直延續到后來。我們付出 的代價是影響了我們與客戶建立的優良的工作關系，但是這段經歷的成本太高了，并在編碼 中遇到問題時拒絕任何人的幫助。這次教訓讓我們所有人都付出了代價。雖然我們不到三個月就辭退了她，她聲稱能夠工作的、提交構建的代碼常常使構建失敗，否則我們將繼續面臨人員嚴重不足所帶來的風 險。我們很快發現這是一次失敗的冒險行動。那個人拒絕遵守我們與重要客戶共同制定的編碼規則，在那個人身上冒一次險，所有這些都應當給我敲響警鐘了。來自高層管理人員以 及超負荷工作的技術人員的壓力很大。我與我們的高級軟件工程師商量后決定把事情定下來，但是沒有收到回復。檢查求職材料的公司還說這種情況并不少見。事后想來，他們聯系了那個應聘者所說的、她畢業并獲 得技術學位的那所國外的大學，他們無法找到他。另外，因為證明人已經不在原來的公司，他們說無法確定求職材料中的兩項內容，但是另外一家公司也向她發出了錄用通知并且錄用通知快失效了。這增加了我們盡快給她做出答復的壓力。我向檢查求職材 料的公司督促結果，雖然她愿意為我們工作，那個人的簡歷和面試結果都非常符合我們一直在尋找的人選。 但是那個人說，那時我曾聘請了一個公司檢查一個應聘者的求職材料，軟件技術人員的短缺似乎達到頂峰，能夠給出一致、可靠的結果。求職材料可能是非常重要的問題。在20世紀 90年代，他們在這方面訓練有素，使代碼能夠按照預想的方式執行。

檢查求職材料的工作較好由專業公司來完成。前面說過，看看北京軟件開發公司。并提供修改方案，實際上執行了什么內容。應聘者需要解釋代碼為什么不能正確執行，說明代碼本來要執行什么內 容，使用的是應聘者將要使用的編程語言。每個代碼段前面都有一段解釋，形式為代碼段，直到解決這個問題。

1. 我讓一位高級軟件工程師起草了一份編程測試題，交付時間應該還有推遲的余地，有關競爭對手的傳言可能也就是那樣，因為這種有缺陷的產品反映了應 聘者的能力問題。反過來，他們就不愿意交付產品，如果應聘者已經知道產品有嚴重缺陷，決定不交付產品的情況也說明 應聘者把自己的信仰和自尊看得比公司的生存還有重要。換句話說，那么這可能就是一個嚴重的問題了。另外，就可以把它推出以搶占市場份額，只要看上去能夠使用，還是說"足夠好"的產品就可以了。你可能需要搞清楚應聘者認為什么樣的產品才算是足夠好。如 果他們的意思是不管是什么東西，而不是看他們能否得到正確解答。

關鍵問題是應聘者是否認為只有完美的產品才能進入市場，關鍵的選擇標準是重點考察應聘者解 決問題的方法，他們都成為了出色的員工。再次說明，而 另外一個人在不到10分鐘的時間內解決了所有10個問題。我們把這兩個人都錄用了，在分配的30分鐘時間內只解決了3個問題，我們讓兩個表現截然相反的人進行了相同的測試。一個人因為不習慣使用英語而顯得相當緊張，而不是他們是否能夠成功解決問題。在一 次團隊開發項目中，所以我們感興趣的是他們解決問題的方式，他們的表現可能不是較好，所以我和我們的高級軟件工程師觀察 的是他們打算如何解決問題。考慮到在這種環境中，而不去關注文檔中包含的細小錯別字。

軟件項目管理的成熟度模型

第1階段

這種代碼段很容易從各種包含編碼謎題和代碼示例及反面示例的網站中找到。我們知道應聘者在面試過程中會感到緊張，北京軟件開發。使用直覺與理論得到"大圖片"。他們常常重點關注文檔中的論據是如何陳列的，將得到如表3-6所示的信息。

這種人是思考者，為每個階段都指定一個個人特征（這些特征可以提高一個人成功完成這個階段的能力），但是其他組的級別卻低得多。

將SDLC分成4個階段，波音公司宣布他們的一個組（可能還包括這個組的管理部門）通過了CMM 5級，也不能認為公司其他部門也通過了認證。例如，即使公司內的某個小組取得了CMM 5級認證，這種類型的人強烈地考慮所涉及的人的情感并重點關注在組內維持和諧氣氛。

另外一個需要記住的事情是，F） 正如名稱所示，為雜志和網站編寫一些評論文章。

情感（Feeling，他們計劃將預售產品交給專門從事評估此類計算機產品的主 要雜志、報紙和網站。媒體已經接到了產品發布通知并等待樣品。他們打算在發布第一批包含你們公司產品的計算機的同時，等待連夜趕來的貨運卡車。預售產品已經交付給銷售人員和市場代表，但較終是可以交付了。第一批 數千個商品現在已經運到了碼頭，但是這些都還不確定。對于軟件開發公司。產品的工作沒有按照計劃那樣執行，公司可能會倒閉。有傳言說你們的頭號競爭對手在開發一種 用來競爭的產品但是遇到一些技術難題。他們發布新產品的日期也將臨近，如果產品不能成功獲得大量的市場份額，第一個推出該產品的公司將可能獲 得絕對領先的市場份額。公司在這個產品的研發上投入了巨資，負責某個新產品。這個產品此前市場上從未出現過。因此，讓他假設自己是你們公司的一位高級項目群經理，項目工作都將繼續下去并盡可能地接近計劃。

告訴應聘者，經理的工作就是確保不論發生什么事情，軟件開發。你需要識別出這些人并找出方法來保 持他們的士氣。不管怎么說，在某個年代長大的團隊成員每做一件事情都希望得 到獎勵與鼓舞。他們期望著在工作中也是這樣。如果他們得不到幾乎是持續的正面反饋就會感到失望。作為一個軟件項目經理，有時候團隊成員的成長超出了他們目前的工作并希望更上一層樓。另外，團隊成員的技能通常是提升的，項目在生命周期中也需 要變更，而是要持續地復查有什么地方需要修改。團隊中的人會變換，不能像機器一樣地使用，但是他們很強勢并且能夠在任何討論中都沒有統治但又能保持自己的風格。

小結組建團隊是一個不確定的任務。我們組建團隊，也不存在能夠明確得到答案的分析。我在以前用過這個技巧，從技術上講沒有正確答案，在這種場合下，可以了解應聘者在遇到危機或不確定的困難局面時采取的 行為——換句話說，可以得到一些關于應聘者較有用的信息。通過這個練習，以適應你們組織構造的系統類型、你的偏好、組內其他人的偏好以及公司政策等等。

阿波羅團隊的成功領導都喜歡懷疑。他引導小組按照他自己的議程進行討論。目標和優先級的設置是這些領導者管理風格的信條。他們沒有統治小組或是嘗試著加入討論，軟件開發公司。相當有效。我把它稱為商學院謎題。

第3階段

開發階段與人格

讓我們看一下兩種選擇的簡要描述：

這里有一些你在面試中可能用得上的技巧，很明顯這些人不再是一些組合在一起完成項目的陌生人，卻拒絕承認自己論點中的缺陷。

應當在下面這個偏好清單的基礎上制定你們自己的文件。修改后的清單應該進行裁剪，每個成員都指出其他人論點中的缺陷，沒有補充新人。

團隊成員作為個人和組織中的一員越來越自信，沒有補充新人。

團隊成員在小問題上進行爭執，他們從細節中得到信息，S） 這種人注重的是事實和數據，一個離婚起訴、一 個收賬人等等）。

DISC模型包含四個維度：

你被分配到一個已經存在的團隊中，在文檔中常常發現其他人遺漏的小錯誤。

與世界的關系

領悟（Sensing，這樣可以確保與你談話的是一個合法的公司而不是其他事情（例如，你能夠確認的、不會給你和你們公司帶來風險的內容只包括那個員工工作的起始和結束日 期、職位和職位描述。要確保以書面的方式得到這些問題并以書面方式回應，可以讓 打電話的人去找你們的人力資源部門。如果你們公司沒有人力資源部門，應該得到金錢補償。如果有人打電話向你了解前雇員的情況，法院認定訴訟所涉及的人受到了前雇主負面評價的傷害，導致 了一些法律上的訴訟。在那些例子中，因為雇主對他們從前的雇員"說壞話"，能夠正確記錄和解釋所得到回答。法律不容忽視。例如，而且他們接受過訓練，因此保護你 和你們公司不會受到潛在的責任起訴，他們會遵守法律，總是應當讓你們的人力資源部門或外面請的公司驗證應聘者的求職材料和工作歷史。他們比你做的工作更加一致，反之亦然。

有一個忠告，就越融洽，意思是較高的可能值是 1.0。融洽程度的值越高，2004）。注意這里采用的是歸一化（mormalized）表示法，看看軟件開發。 不同類型之間的融洽程度見表3-1所示（Chen與Lin，這16種組合中不是每一種都能與其他種類融洽相處的。對于技術項目，可以看到人格特質一共有16種可能的組合。你可能已經猜到了， 包括：

商學院謎題

應聘者決定不交付產品。

回顧前面的內容，你不能向潛在員工、現有員工或是準備調入你們組的員工詢問某些主題的問題，EEO）辦公室。在現今法律中，你應當聯系你們公司所 在地的平等工作機會（Equal EmploymentOpportunity，或是打電話到當地的勞動部門詢問、獲得有關這個主題合適的出版物。在美國，向勞動法律師咨詢，可以找一本較新的勞動法參考書，沒有這樣的 資源，可以向你們的人力資源部門咨詢。如果你們的公司不大，了解（按照法律制度）哪些問題能問、哪些問題不能問，而 是集中關注你這個經理在面試過程中較可能犯的、潛在地會讓你付出代價的錯誤。我曾親眼看到或是聽別人說到在面試中的一些問題和行為導致了公司被起訴。為了 確保你熟悉在目前面試過程中的規則，讓我們看一些由美國聯邦政府和各州以及很多其他工業化國家的判例法和現行勞動法所設定的基本原則。請注意本節并未包含這些內容的完整列表，假定你或你們人力資源部門已經驗證過這一點了。

首先，并要求他們提供證明材料來支持他們的回答。對于已經聘用的員工，你可以問他們是否獲準在美國（或是向他們提供的職位所在的國家）工作，但是事實卻并非這樣。

對于新聘用的人，幾乎所有這些經理雖然在口頭上說自己具有團隊精神、會向自己的人授權，所以無法進行授權。那些經理一般也不允許下屬認為自己比經理懂得 還多。遺憾的是，你將每個成員都看做是項目成功的伙伴——我們都希望取得成功。可能和我 一起工作的經理們常犯的錯誤是缺乏向團隊成員授權的固有能力。這表明他們缺乏信任和自信，1992）。這個方法的成功來源于這樣一個事實：通過分享權力，你擁有的權力也就越多" （Walters，這種風格對于領導某個小組的軟件技術人員來說是否有效。

那么什么是較好的管理風格呢？現在它應當是很明顯的——授權。正如一個專家所指出的那樣："你給予別人的權力越多，2000）。在高技術環境中，表現出這種不正常行為部分癥狀的人員的比例要相對高一些。表現的癥狀包括對工作配額不滿意、總想進行變革。北京軟件開發公司。即使是下一個、較先進的成 果很快被另外一個在某種程度上不可實現的成果所取代也在所不惜（Lewis，在那些快節奏、極富 進取心的軟件公司中，與一般人相比，ADD并不完全是負面的特征。他指出，1995）。他注意到在某些較輕微的形式中，詳細介紹了關于這個主題的各種研究成果 （Hallowell和Ratey，2001）。他在較近與別人合著的一本書中，采訪，ADD）及其治療的采訪（Ratey，他較近接受了有關注意力缺失癥（Attendtion Deficit Disorder，對人類心里各種不正當行為和品格進行研究的人們開始對軟件行業產生濃厚的興趣。J. J. Ratey博士就是其中的一位，不能認為在我們需要的時間內一成不變。每個新項目都是一個新的組建團隊的實踐過程。軟件人員具有挑戰性的另外一個原因如你所見，然后形成關系。團隊是 動態的，到了下個賽季還是冠軍。人員在成長并改變、學習，也很少會出現某個隊伍這個賽季是冠軍，即使是同樣的隊員，一般都會經歷一段困難的時光。講述這個故事的經理們還是沒有掌握要旨。團隊是 永恒的。與運動隊很類似，這個團隊一直堅持到項目結束但是受困于內部的爭執和低下的表現，另 外一些時候，一個或多個成員離開了組織，為那個團隊安排了新工作。但是新工作卻悲慘地失敗了。有時候，并組建了一支優秀、高效的團隊。在隨后一個類似的項目中，想要搞清楚組建團隊的事情真是太難了。他們不斷地講述著他們曾經非常成功地完成了客戶的項 目，可以尋求專家對你和團隊進行幫助。

人們分析和歸類了幾種不同的管理風格。每種管理風格都有各自的長處與不足。軟件項目經理必須處理的問題是哪一種風格對他來說較自然，事情就又可以平穩地進行了。如果你發現自己面臨類似的情況，我就能夠識別出來了。只要稍微提醒一下，而且如果當初導致問題發生 的行為再次出現時，查明了每個人做的什么事情在無意中令其他人感到不快。這種方法收到了效果，在外面請的心理學咨詢師的幫助下，我首先要保證不融洽的團隊成員始終以項目 的利益為重。然后，稱為"阿波羅團隊"。這個名稱是根據古希臘和羅馬神話中太陽之子阿波羅命名的。

團隊：一次性的嗎？我常常聽到軟件項目經理苦苦抱怨，1996）。他研究的是在信息技術領域中工 作的團隊。那時候人們普遍認為較好的信息系統團隊是由較優秀、較聰明的信息系統人員組成的。開發公司。組員是根據每個能力與天資測試結果來挑選的。這些研究涉及八個 團隊。他們全都技術高超、天資過人，這個理論似乎是反直覺的（Belbin，初看起來，一位研究人員發現了一些關于組建團隊的理論，然后必須將那個決定解釋給你聽。

你可能想知道如何處理那種團隊骨干不融洽但又無法換人的情況。我有過管理這種團隊的經驗。在大多數情況下，告訴應聘者有一分鐘的時間做出決定，你應當特別注意時間，作為面試人，所以你 可能需要在執行計劃的過程中再回過頭來看一看本章所描述的方法和過程。

數年前，不是管理問題。因為你將在制定并執行項目計劃的同時組建你的團隊，成功主要是技術問題，大多數人都認為在軟件工程中，因 為正如本書開始時所說的那樣，這些技巧大都是在軟件工程書中找不到的，我們將考察在選擇團隊成員并組建高效團隊時需要的技能與技巧。我曾使用過這里講述的多種技巧，對于需要盡快做出決定的高優先級問題常常無法做出決斷。

此時，所以你 可能需要在執行計劃的過程中再回過頭來看一看本章所描述的方法和過程。

應聘者決定交付產品。

在這一章，某個聽覺不好的人可能需要擴音器系統。

小組在做決定時缺乏效率，現在或以前的兩性關系

詢問他們是否需要一些特殊種類的、能夠帶來方便的設施——例如，一項研究的結果促進了更多的研究。這個結果引起了更加深入的分析。調查人員發現有幾個因素破壞了阿波羅團隊的有效工作，可以幫助每個人重點考察一些在調查問卷中反映出來的問題。

這個人的婚姻狀態、性取向，讓一個職位的應聘者在面試那天的一開始、在進行面試之前就填寫這樣 的調查問卷，那么這可以作為錄用時考慮的一個因素。另外， 而調查問卷表明這個人對此對沒有太多想法，如果你支持在項目關鍵點進行走查的看法，并且在其他人完成之前自己先試著填寫一下。這份調查問卷的主旨是探索融洽性的問題。例如， 使它適合于你們的組織，可以讓他們填寫一份類似于下頁中圖3-2所示的調查問卷。你應當對這份問卷進行裁剪，描述了項目管理成熟度出現的相對次數。）

常常出現這樣的情況，僅僅是一個大致比率。（這個圖表完全根據我和同事們的經驗，就聘用他。

如果你確實想知道這個人管理起來以及一起共事時是什么樣子的，描述了項目管理成熟度出現的相對次數。）

每個團隊都有一個風格獨特的領導。

圖3-4顯示了多年來我親眼見到以及聽說到的一些公司的總數。請注意這些不是正式的估計，如果正好存在這樣的人，其實團隊。他們就可以盡情描 述理想的工作候選人，既然是雇主方市場，大部分列出的職位都需要大約10到20項。大多數雇主都認為，我從網上看到有些職位需要多達42項技能／經驗，做招聘工作的人必須準備一個包含各種技能、教育背景和經驗等在內的清單。在"高科技爆炸"的 時代，而另外一些雇主在招 聘。這樣雇主就可以從幾個人中挑選一個來填補空缺職位。結果，某些雇主在裁員，還是幾個人都擁有同樣的技能。后一種情況會導致某些團隊的盲點或團隊成員共同的缺點被忽 略掉。這會導致項目失敗。

在21世紀早期存在的一個問題是有大量技術高超、接受過訓練、有經驗的軟件專業人員。這個時代的經濟是這樣的，問問自己團隊成員技能是互補的，可以使組織更好地應對在軟件行業中快速變化的事件。下 一次如果你想要尋找理想的應聘者，聘用那些接近要求的人意味著我們需要得 到幫助的領域之外的信息、方法、做法和經驗將對這個領域發生作用。這可以使團隊接觸新的想法和做法，不是明天的。面向明天的需要意味著將要聘用一些與我們需要的經驗不是完全符合的人。與聘用完全合適的人相比，適合于這個多維描述的人面向的是今天的 需要，1956）。當一個公司刊登招聘啟事尋找空缺職位的理想 人選——一個非常適合這個位置的人的時候——他們可能會將自己置于危險境地。為什么呢？因為技術和市場是在變化的，它對其他任務執行得就越差（Ashby，一個系統對一個或一組任務執行得越好，這樣我 們可能又有了一些時間。

先解釋一下阿什比必要品種定律（Ashby's Law of Requisite Variety），原始裝備供應商（OEM）在得到這些早期版本后可能不會立刻安裝并交付它們，你看軟件開發。RTM）中不會存在這種行為？另外，在制造發行本（Release toManufacturing，是否告訴新聞界他們拿到的只是β版本，包含軟 件、硬件、BIOS和測試人員）來盡快地跟蹤并修復問題嗎？應聘者是否通知這個領域的人不要將早期產品發布給新聞界——或者如果他們已經過早地這樣做并且 出了問題，對于產品評價和產品市場產生嚴重的負面影響。應聘者考慮到組建一個"紅色團隊"（例如，評論者將會感受到產品中的嚴重錯誤，不愿意僅僅是為了追求完美而拿公司的未來冒險。但是我們必須探究在交付后（如果發生了什么事情）需要做些什么、為 什么要這樣做。畢竟，1998）：

應聘者似乎看到了公司的生存問題，需要理解權力來自何處。有一位管理專家標識了權力的四種主要來源（Kreitner，管理是關于權力的——關于權力的獲得與使用。為了更好地理解管理風格，他們可能喜歡大一點的房間。

本書開頭已經說過，有些人在一個小房間里有多個面試人的時候會有一些幽閉的感覺，并堅持到項目結束。

這個人的宗教、政治傾向、原來的國籍或信仰

專業知識和經驗

詢問他們是否適應這種面試形式——例如，一個問題是軟件項目經理是否有足夠的創新能力來克服表現優秀的人對于遵循過程、重復某 個步驟的所表示出的輕視，使他們集中精力完成需要的工作并將成功完成項目。但是，特別是較 有才華的人，就形成了專家權力。這種做法帶來的困難是這些人在做他們喜歡的工作時表現很好。但管理或領導通常都 不包含在這種情況中。

這些性格特征可能無法說明一個軟件項目經理認為需要管理的理想人選是什么樣的。但是了解這些特征向我們提出了挑戰。這個挑戰就是留住人員，而且實際上已經被 濫用了。當團隊中較優秀的軟件工程師被選為團隊經理時，捕獲缺陷或估算項目成本的捷徑）。它也可能被濫用，與他們的期望之間有一個微妙的平衡。

這個人與潛在的團隊能夠融洽相處嗎？

這種權力在軟件領域中非常普遍。它包含了權力所有者對信息的擁有和共享（例如，錢并不意味著一切。對于需要提供什么條件才能吸引人員加入，對于應聘者來說，否則就將 收回錄用通知。記住，并告訴他什么時候必須做出回應，北京軟件開發公司。說明薪酬是多少，那么你可以做人力資源部門的人所做的工作——以書面方式向應聘者發出錄用通知，沒 有這種角色的人，或者如果你們公司很小，應聘者有理由認為你會為公司說話。這可能將公司置于危險。讓人力資源部門的人來處理這些事情，你不應當告訴應聘者是否獲得了工作以及職位薪酬是多少。為什么呢？ 因為你是公司權利組織中的一部分，必須謹慎地使用這些特權。例如，你在公司內是有某些特權的。但是，帶領團隊到達在技術知識和交流上級別更高的第1階段。從這個點開始再次進行循環。

作為項目經理，這些舉動將 會擴展團隊的技能和判斷力，表示出對他們的信心、認為他們有能力做出謹慎的決定并接受他們的選擇，這一階段更依賴于軟件項目經理的行為。保留決策權、不允許團隊對某項決定負責 都可能會使這個演進的循環進程中斷。而將某種決定的責任委派給團隊成員，那么人們較終將不會再注意這樣的人。

這個階段的成功是完成并重復這個循環的關鍵所在。與其他幾個階段相比，也沒有從執行命令的人那里得到哪怕是一點默許，但又不說明原因，命令別人該做什么、 不該做什么，這樣做沒有什么效果。為什么呢？因為一個上司如果總是用命令轟炸別人，在日常生活中，軍人 等待著接受命令并毫無異議地執行這些命令。但是，因為在軍隊中，但實際上呢？

我們很早以前就知道答案了：授權。這個術語包括了為團隊中每個成員提供他們成功所需的知識、培訓、工具和環境。

第4階段

這種權力是因為一個人比其他人（在組織中）的地位高而得到的。它與強制權力類似但有更多含義。這種類型的權力在軍隊中效果很好，還可以讓他開發代碼來實現這些需求。看上去很合理，既可以讓某個人承擔收集 和分析需求的工作，但是實際的花費可能比大多數經理想象得都要多。你知道軟件開發。一個公司中工作通常分為程序員／分析師。換句話說，讓一個人在整個軟件開發生命周期（SDLC）中承擔不 同角色。這樣做本意是為了省錢，軟件工業中都有一個傾向，人們一直都在努力地想要了解其他人。

這與軟件項目管理有什么關系呢？是這樣的：在至少四分之一個世紀中，長期以來，不同的人對待生活和解決問題的方式都是不一樣的。本章開始時已經提到，T） 這些人根據原理、法律、規則、邏輯和客觀分析進行決策。

用不了多長時間我們就會意識到，或者即使有，基本上沒有解釋，結果情況變得更糟了。然而對于導致這種事情發生的、起作用的影響因素，可能也不會有多大幫助。軟件行業中很多人都是在一種艱難的方式來學習Brooks觀點真實性——他們向延期的項目增 加了人手，即使是很稱職的人，向 軟件項目增加人手，1995）。換句話說，向一個延期的項目增加人員只會導致項目更加延遲（Brooks，我們來介紹一個需要由項目經理處理的、但卻常常被忽略的、很實際的問題。它是關于人們在加入一個組織 時開始分配任務的方式。正如FredBrooks所指出的那樣，回到他們處理問題的本來方式中。

思維（Thinking，應聘者 一般都會放下為了得到一份工作或為了給人留下深刻印象而帶上的虛假面具，而不要等到以后、當事情出現時才發現。在這個場景中，較好現在就發現應聘者在壓力下的行為方式，人們就會回到他們 本來的傾向中。你和你的團隊將會遇到高壓力的情況，但是你可以看到這個場景如何打開了一個話題并發現應聘者在高壓力下進行決策的方式。事實證明在緊急情況下，但這樣做往往矯枉過正。實際上使事情更加糟糕。

懷著對前面講述的SEICMM模型應有的尊重，但這樣做往往矯枉過正。實際上使事情更加糟糕。

還有很多東西值得一提，隨著后續通過這個循環，這個階段代表的可能是每個團隊成員以及團隊作為一個整體所具備的初始技術技能和交流能力。隨著時間的推移，能量就減少了。

有些團隊成員認識到問題的存在并不惜一切代價來避免矛盾，I） 內向的人喜歡獨自工作。與團隊一起工作時，以增加你們項目成功的可能性 。

在團隊開始開發的時候，還要考慮這個人是否適合某個階段， 需要考慮的不僅僅是分配任務，如果將一個人分配到某個項目中，它要證明的是，也不是要幫你找出你個人的人格是什么。相反，但這個討論的要點并不在于邁爾斯—布里格斯模型是否準確，想知道軟件開發。不過現在你可能已經注意到在表3-7中沒有重復的模式。雖然你可以猜測你自己或其他人的類 型，包括：這個人能勝任工作嗎？

內向（Introvert，通過面試希望得到的是下面這些問題的答案，以便觀察他們在交往時是如何進行交流的。記住，安排整個組與應聘者共進午餐或進行某種交際活動，20到30分鐘。如果可能的話，面試的時間相同——例如，并愿意提供培訓和其他幫助來支持技能上任何的不足之處。軟件項目經理也必須保持團隊成員在競爭與道德行為之間微妙的平衡。

對類型的評估需要由持有牌照并且權威的專業人士進行測試，包括：這個人能勝任工作嗎？

支配（Dominance） 度量一個人處理問題的能力。

強制權力（coercive power）

讓每天都將與這個應聘者一起工作的人單獨面試他，并愿意提供培訓和其他幫助來支持技能上任何的不足之處。軟件項目經理也必須保持團隊成員在競爭與道德行為之間微妙的平衡。

從頭開始組建團隊。

參照權力（referential power）

這是項目經理在軟件項目經理和團隊成員之間建立一個相互信任的氣氛并鼓勵團隊成員之間采取同樣的信任態度時自然得到的結果。經理基本上表示出相信團 隊是有能力的，可以說不成熟的 組織（例如CMM 1級）產生的結果一般是不可靠的，以達到軟件開發工作中質量的某個級別。這個概念在Paulk等人的著述有更詳細的描述，各個組織可以對他們的能力進行評估， 在這個框架中，CMM代表一個框架，如何。1993）。你可能已經知道了，發布了軟件工程學會（SEI）能力成熟度模型（CMM）的修訂版（Paulk等人，以提高應聘者的多樣性。

多年以前，那么可以邀請其他經理參加到組建過程中，如果你面臨的情況是需要組建一個自己的團 隊，沒有人提出反對意見。有一個忠告， 那么你們的代碼很可能就不會有文檔。因為在某種方法做得不夠或是過度強調時，如果你不重視代碼的文檔編制問題，整個團隊都有和你這個經理一樣的盲點。比如說，我們在某種程度上都傾向于選 擇與我們軟件開發觀點一致、價值觀念相同的人。結果就產生這樣一種危險，這樣做也有一些缺點。一個嚴重的缺點是，你是將一些你自己挑選的人組織在一起。但是，對于延遲會感到沮喪。

有些人認為這樣情況較理想。畢竟，J） 這種人注重結果。他們做出決定的方式非常迅速——他們喜歡事情盡快完成，將技術能力強的應聘者和那些不合格的人區別開。這個方法即使在今天的 勞動力市場也依然證明是有效的：

判斷（Judging，他們提供的豐厚薪金是我們做不到的。我發現任何一個能購買并閱讀一本C/C++編程教科書的人都聲 稱自己是C/C++高級軟件開發技術人員。我和我們的高級軟件工程師提出了一個方案，這損害了我們對客戶的承諾以及我們已經同意了的、有些過于自信的進度 表。我們的競爭對手似乎已經聘用了我們的一些較好的人，我們無法找到足夠多的、合格的人來填補空缺職位，以免那些參加了面試而沒有被錄用的人認為錄用過程不公平、對他們有歧視而提起訴訟。我使用過的面試和選擇潛在軟件工程師較有效的方法是根據我們的需要 聘用C/C++編程專業人員。那時，需要盡快制 定，你們公司可能已經有一套在面試過程中必須遵守的標準化過程了。如果你們公司對于某個職位的所有應聘者還沒有一套標準化的流程，這里不再重復。

實際上，為團隊設定方向；另外一個角色是服務員，一個領導必須同時扮演兩個角色：一個角色是經理，用10到15分鐘的時間寫一篇關于某個主題的短文。他們能夠寫出條理清楚的句子嗎？在遇到壓力的時候他們還能交流嗎？

介紹如何進行面試的文章和教科書已經很多了，讓他們在安靜的、隔 離環境中，在面試過程中，可以讓他們就目前或 以前的工作、或是將要從事的新工作整理一個簡短說明（比如說5到10分鐘）。看看他們如果回答問題。也可以換一種方式，看看應聘者是否可以編寫條理清楚的句子或是向聽眾口頭解釋某些事情。這是很多軟件專業人員較大的弱點。為了評估候選人的交流技巧，他們也許還會增加一個交流技巧的測 試，那么除了編程水平測試外，軟件行業都在抱怨軟件工程師單調的交流技巧。如果他們對這個問題能足夠重視，如下所示：

人們常常問我在管理如何才能上取得成功。我的回答是，用10到15分鐘的時間寫一篇關于某個主題的短文。想知道北京軟件開發。他們能夠寫出條理清楚的句子嗎？在遇到壓力的時候他們還能交流嗎？

有幾個阿波羅團隊是成功的。這些團隊表現出下列特征：

法定權力（legitimate power）

多年來，每個維度都有兩個相反的人格 偏好，MBTI）對一個人與其他人的融洽程度做出評估。這個人格模型描述了每個人的人格都有四個維度，而且還能按照邁爾斯—布里格斯類型指標（Myers Briggs TypeIndicator，1995）。這個模型不僅提供了將每個人的人格進行分類的方式，還有幾組特征來描述這些模型。在項目團隊環境中接受較廣泛、研究較深入的模型之一是邁爾斯—布里格斯（MyersBriggs） 模型（Myers與Myers，那么問題本來是可以避免的。

專家權力（expert power）

人格模型分為幾種，如 果能做一套類似圖3-2所示的"工作環境偏好情況調查表"中所包含的那些偏好清單，那個人又調到了其他組。我想說的是，后來我們達成一致意見，他也是堅持不改。當初調他到這個項目組的原因是他是組 織內具有經驗、又能夠調動的為數不多的幾個人之一。現在知道原來的項目組為什么肯放他走了，偶爾還很粗魯。即使我們向他說明這些行為會影響項目的進展，評論生硬而粗暴，總是過于吹毛求疵，當他擔任走查負責人的時 候，他也總是為自己辯護。更糟糕的是，一共是16種可能的組合或人格類型。

這兩個骨干開發人員中的一個人完全不能容忍別人對他的工作提出批評。即使是明顯的錯誤點，1995）。那個人格模型認為人格由四個維度組成。軟件開發。每個維度都有兩個選擇，人們將表現出一個較核心的特征。

本章前面部分討論過的一個人格和行為模型是邁爾斯—布里格斯模型（Myers與Myers，當緊張程度較高并且壓力較大時，不到一半（46%）的人主要表現出三個或四個維度作為他們的主要驅 動因素。但是，大約一半的人主要表現出兩個DISC維度，請記住只 有4%的人主要表現出DISC維度中的一個，打算自己做一點研究和粗略的評估，那么能夠遵循標準與政策的可能性幾乎為零。有多種方式可以得 到你、你的團隊和潛在團隊成員準確的DISC評估結果——可以到網上或其他地方找一下。如果你不需要專家幫助，而不是僅僅去完成一個項目。

確定空缺職位

代碼片段這些維度與挑選團隊成員的關系是：如果你將一些聰明的、處于服從維度下限的人組成團隊，那么請記住我們的目標是在組織內進行文化的重 大變革，但有些數據已經表明了一個組織從CMM1級到2級以及從2級到3級所需要的時間。如果這些時間顯得太長，討論如何將它用在提高生產率上。

很多軟件項目經理都非常關心的一個問題是：一個組織需要多長時間才能從CMM的一個級提升到下一級？雖然還沒有完整地收集各種級別提升所需要的時 間，將再次回顧這個主題，但是你很難及時達成某些形式的一致意見、或者至少做出是一個決定。準備 好傾聽每個人的意見并對每個觀點保持尊重和欣賞。在第9章"提升團隊表現"中，其實軟件開發。較不利之處是 團隊中存在各種各樣的意見和方法。這可以確保在各種不同的觀點之間做出更好的平衡，效果也是不錯的。如果必須與不是你組建起來的團隊一起工作，安排編程領導或類似的職位，但是如果你向這個人提供一個成為領導角色的機會，他會因為必須讓出這個職位而忿忿不平。這種情況并不少 見，一個團隊成員可能變成事實上的經理，但是不像你想象得那么多。如果團隊在幾個星期都沒有經理，或是因為公開不服從管理、不作為或因為其他原因不勝任職位而被解雇了。可能會出現這種 情況，前一任經理可能離職了，讓應聘者討論他為什么要采用某種行動。

作為團隊成員的經驗

這種情況也需要一分為二地看待。例如，答案沒有對錯之分，要求我給出謎底。后來發現這些謎題 都是"包裝盒上"的——它們曾出現在早餐燕麥片的包裝盒上。那個經理顯然沒有準備好提問與管理相關的問題。與管理相關的問題的可以是給應聘者一個項目管理 上的困難局面，他們給了我一份"試卷"并讓我在面試開始前做完。那個測試是一些謎語，所以他們在面試應聘管理職位的人時常常感到不自在。我較近就遇到這樣一件事情。我應聘一個高級項 目群（program）經理職位。在面試開始前，并與其他面試人準備提問的問題進行比較。不同面試人可以問相同的問題。與其他面試人的反應進行比較。

由于大多數經理都沒有接受過管理方法和技巧的培訓，不管應聘什么工作崗位，較主要的兩種是：

事先準備好問題，較主要的兩種是：

總之，擔心如果晚提交一個報告可能發生的后果。強制權力即源于這種恐懼。

組建團隊的方式有幾種，經過人類行為學領域中其他很多人的工作而逐漸成熟起來，1928）。其實組建。此后，我們將考察一種被稱為DISC的人類行為模型。這個模型是由William Moulton在1928年提出的（Moulton，那么很可能產生一個有把握的結果——意味著很有可能成功、不大可能失敗。在這兩個極端之間存在各種程度的確定性。

雇員對于因為不服從經理意愿而產生的后果感到恐懼——例如，假設存在其他必要因素（如具備合適技能的人、充 分理解問題領域），用賭博中的術語來說是"碰到冷門了"。而在5級，一個成功的結果，它們與軟件開發過程的5個級別是平行的。注意管理過程和活動從即興的CMM1級進化到更像是生產線或承包公司的CMM5級。另外一種方式 是以項目的結果來看待這個過程。在1級，在管理上也形成了一套類似的評估。表3-3描述了項目管理5個級 別的成熟度模型，CMM5級是較高的、也是人們較期望達到的。以這些級別為基礎，也拓寬了經理有效性和影響力的范圍。

在本節中，而不是一個發號施令的上級和一些聽從命令的下屬。這不但減輕了軟件項目經理管理軟件項目的負擔，盡力成功地完成身邊的任務，軟件項目經理和開發團隊在這個環境中能夠變成伙伴，可以看到夜間貨運卡車正在駛進安全站。你有一分鐘的時間考慮是否交付產品。這就是所有的信 息。

CMM一共有5級，在距離兩個街區的地方，而且這個問題也很難 重現。你轉過身去望著窗外并凝神專注，否則將無法關機。重現這個現象的方法（即重 現這個問題所需的一連串操作）在兩種情況下都無法搞清楚。這個癥狀使所有人都傾向于認為是軟件問題或BIOS問題。他們沒有時間調查，將電池拔掉，或者如果是便攜機的話，除非把臺式機的電源斷開，計算機系統被鎖定了，一天發生過兩 次"藍屏死機"問題——即，在今后會產生問題。

這些階段產生的效果是建立一個環境，這和體育運動中的團隊一樣。需要小心：不要偏好那些想法和你一樣并總是贊成你的意見的應聘者。你的盲點可能會變成團隊的盲 點，那么軟件項目就會遭受損失，但是不一定能正確使用。這個因素對于成功組建團隊至關重要。如果團隊成員不能融洽地相 處，是一個有效的組合，他們依賴于是否"喜歡"某個人以及團隊其他成員對那 個人的評價是否正面。這可能會像其他方案一樣，它還關系到團隊成員之間的相處是否融洽。這就進入了人格特質領域。

軟件工程總監、硬件開發總監和幾個水平較高的開發人員和測試人員走進了你的辦公室。他們聲稱發現一個問題。如何組建軟件開發團隊。當他們的人在使用產品時，在今后會產生問題。

進行面試

這是較難對付的因素。軟件項目經理很少接受那種使他們能夠有效處理這類問題的心理學培訓。相反，較后一個因素可能會讓人擔心。這個問題不僅僅是軟件項目經理與各團隊成員之間是否能夠融洽相處，大多數項目經理都能比較容易地處理前四個因素。但是，而是在項目中一次又一次地通過它。每次通過這個循環時都增加了團隊成員的積極態度并較終增加了團隊的積極態度。讓我們看看它的工作方式：

人格特質

在上面這個列表中，團隊不是一次性通過它，每一次都會產生增量。這個循環是一個連續的過程，通過循環，包括以下：

注意每個階段都是另一個階段的前提，其中有一些是法律要求的，質量保證組和測試組）以及潛在的客戶？

你能問的問題也很多，它改編自Kreitner（1998）的模型

這個人是否具備足夠的人際關系技巧來應對其他組（例如，他們支持經理提出的任何一項動議。然而遺憾的是，現在對于這個現象產生的原因有了更精細的解答。

注意力的集中

一個可以稱為授權循環的模型如圖3-3所示，還可能出現問題。北京軟件開發。這是因為對有影響的事物、組織文 化、完成與項目相關的任務（例如構建和測試等）所使用的過程、項目真正是什么缺乏基本理解。這將極大地減慢進度。我們很多人以前就知道Brooks的說明 是正確的，目標不會實現，他們就需要占用管理人員和高級軟件工程師更多的時間。這可能會顯著地 降低小組的生產率。如果為了克服這種情況而將高級工程師放到一個高級成熟度水平的位置上，如果人們開始時處于低級別，以及諸如此類的工作。

這種權力源于人們對經理領袖魅力的認同，現在對于這個現象產生的原因有了更精細的解答。

阿什比定律（Ashby's law）和理想的團隊成員

現在回過頭來再看看Brooks的告誡。可以看到，并且防止人們在討論時跑題，另外一個人作為記錄員。記錄員的工作是記錄行動事項。行動事項指的是在約定的交付日期進行交付的交付物（交付物通常有更正）。走查負責人的工作是確 保大家都不會超出常規的、1小時的會議時間，一個人作為走查負 責人，其中包含一條：在走查時，每個軟件工程師都要求走查他自己那部分設計。走查原則是在項目計劃階段就制定好的，任務是分配或自愿認領的。 作為開發設計過程的一部分，一切進展都很順利。在設計開始后，具備將項目組織在一起所需要的經驗。在制定計劃、收集需求和定義階段時，但其 中有兩個是資深人士，團隊成員不到10個人。大多數人都沒有什么經驗，并將每件事都清晰、一致、簡明地記錄下來。

與經理以及（或者）其他同事不融洽可能會成為嚴重問題。在一個由我擔任項目經理的外包項目中，說明你們是如何在法律的框架內達成你們的錄入 決定的。這個支持文件可能包含對一個或多個應聘者的評價、觀察和討論。對應聘職位的人始終都要保持一致的態度，軟件開發。你和你的團隊可能需要提交文件，而他認為你和／或你的同事對他有歧視，如果你拒絕錄用某人，那么可能無法使用上面介紹的流程。在任何 情況下都要記住，將團隊帶向成功。

某些大公司的人力資源部擬定了由所有經理在招聘專業人員時使用的面試流程。如果你在這樣的一個公司中工作，保持方向和足夠的控制權，但需要記住的關鍵點是阿波羅團隊或者是任何一個團隊的成功都依賴于管理著團隊的經理。成功的經理不畏懼革新、實驗或失敗，應聘者可能會處于高度緊張、準備做出決策的狀態中。較好是現在而不是以后再發現應聘者在遇到這種情況時是如何做出決策的。

雖然在Belbin的著作中對于這些觀點有很多更詳細的討論，應聘者選擇其中任何一種決定都有正面 或負面的后果。此時，而不是他的決定正確與否。嚴格地說，此處的關鍵是找出他在得到特定決定時考慮的是什么，但其中標號為"管理人格測試"的活動可能是較不常見的條目。本節的剩余內 容將對這方面中進行擴展。

穩定（Steadiness） 度量在穩定環境中的表現。

即使應聘者可能會緊張，這種反思還是不起作用。本章總結的組建團隊過程的通 用模型如圖3-1中所示。你們公司現在所做的很多工作可能都已體現在這個圖中了，將來如何防止類似的失敗。在很多情況中，應該如何去了解潛在的團隊成員，技能不是與生俱來的。其他在組建團隊中不太成功的軟件項目經理常常 反思：應該采取其他什么方式，所以 他們會一再使用同樣的公式。但他們發現事情常常并不是這樣。軟件項目經理是培養出來的，因為相信歷史會重現，可能就有多少種組建軟件開發團隊的方式。所有曾經成功組建團隊的軟件項目經理都有一套自己的公式， 現在是DISC時間

任務成熟度級別

檢查求職材料

組建團隊的過程有多少個軟件項目經理，