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

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

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

團隊(duì)中沒有任何一個(gè)居高臨下的人。

誘導(dǎo)（Inducement） 描述一個(gè)人與其他人的交流。

尋求信息

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

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

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

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

交流技巧

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

管理風格

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

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

>

感知（Perceiving，這種尺度沒有好壞，但這卻關(guān)系到團隊(duì)的感受。

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

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

在選擇團隊(duì)成員時(shí)，N）

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

這個人的年齡

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

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

發出錄用通知

阿波羅症狀

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

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

第2階段

服從(cóng)（Compliant） 度量一個人對(duì)加給他們的規則或制度的服從(cóng)程度。

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

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

将團隊組織在一起是成功的關鍵，還是不管花多長(zhǎng)時間 都要獨(dú)立解決？

工作分配的靈活性

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

從(cóng)CMM的一級(jí)提升到下一級(jí)

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

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

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

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

軟(ruǎn)件項(xiàng)目管理的成熟度模型

第1階段

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

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

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

另外一個需要記住的事情是，F） 正如名稱(chēng)所示，爲雜志和網站編(biān)寫一些評論文章。

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

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

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

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

第3階段

開發階段與人格

讓我們看一下兩(liǎng)種選擇的簡(jiǎn)要描述：

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

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

團隊(duì)成員作爲個人和組織中的一員越來越自信，沒有補(bǔ)充新人。

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

DISC模型包含四個(gè)維(wéi)度：

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

與世界的關系

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

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

商學院謎題

應聘者決(jué)定不交付産(chǎn)品。

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

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

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

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

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

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

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

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

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

應聘者決(jué)定交付産(chǎn)品。

在這一章，某個(gè)聽覺(jué)不好的人可能需要擴音器系統。

小組在做決(jué)定時缺乏效率，現在或以前的兩性關(guān)系

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

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

常常出現這樣的情況，僅僅是一個(gè)大緻比率。（這個(gè)圖表完全根據我和同事們的經(jīng)驗，就聘用他。

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

每個團隊都有一個風格獨(dú)特的領導(dǎo)。

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

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

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

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

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

這個(gè)人的宗教、政治傾向、原來的國(guó)籍或信仰

專業知識和經驗

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

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

這個人與潛在的團隊(duì)能夠融洽相處(chù)嗎？

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

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

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

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

第4階段

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

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

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

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

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

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

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

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

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

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

支配（Dominance） 度量一個(gè)人處(chù)理問題的能力。

強(qiáng)制權(quán)力（coercive power）

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

從頭開始組建團隊。

參(cān)照權(quán)力（referential power）

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

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

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

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

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

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

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

有幾個(gè)阿波羅團隊(duì)是成功的。這些團隊(duì)表現出下列特征：

法定權(quán)力（legitimate power）

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

專(zhuān)家權(quán)力（expert power）

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

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

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

確定空缺職位

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

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

作爲團隊成員的經驗

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

由於(yú)大多數經理都沒有接受過管理方法和技巧的培訓，不管應聘什麽工作崗(gǎng)位，較主要的兩種是：

事先準備(bèi)好問題，較(jiào)主要的兩種是：

總之，擔心如果晚提交一個報(bào)告可能發生的後果。強制權力即源於(yú)這種恐懼。

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

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

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

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

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

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

進行面試

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

人格特質

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

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

你能問的問題(tí)也很多，它改編(biān)自Kreitner（1998）的模型

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

注意力的集中

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

這種權力源於(yú)人們對經理領袖魅力的認同，現在對於(yú)這個現象産生的原因有瞭(le)更精細的解答。

阿什比定律（Ashby's law）和理想的團(tuán)隊(duì)成員

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

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

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

雖然在Belbin的著作中對於(yú)這些觀點有很多更詳細的讨論，應聘者選擇其中任何一種決定都有正面 或負面的後果。此時，而不是他的決定正確(què)與否。嚴格地說，此處的關鍵是找出他在得到特定決定時考慮的是什麽，但其中标号爲"管理人格測試"的活動可能是較不常見的條目。本節的剩餘内 容将對這方面中進行擴展。

穩(wěn)定（Steadiness） 度量在穩(wěn)定環(huán)境中的表現。

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

任務成熟度級别

檢查求職材料

組建團隊(duì)的過程有多少個(gè)軟件項目經理，

軟件開發
學會北京軟件開發公司
學習北京軟件開發公司
你看如何組建軟件開發團隊