[M] 在小型開發(fā)團(tuán)隊中，你是否認(rèn)為，成員職則彼此都較模糊，或者說互有交叉。人員相互彌補不足，對leader來說壓力可能也會小些。在這樣的環(huán)境下，個人自由與紀(jì)律規(guī)范是一對矛盾，如何處理這個矛盾，如何把握這個度呢？

[L] 其實現(xiàn)在我所接觸到的開發(fā)團(tuán)隊中，成員的職責(zé)應(yīng)該說是比較清楚的。某個模塊由誰來做，什么時間交付定義的都十分清楚，而且功能相近的模塊也不可能交給多個人做，除非工作量很大。至于具體的職責(zé)問題我想項目成員應(yīng)該是保證自己的代碼、文檔的質(zhì)量，當(dāng)然他也要對項目有一定的責(zé)任心。在開發(fā)團(tuán)隊中人員相互彌補對于整個項目來說肯定會有很大的益處，這樣項目經(jīng)理不用幫助協(xié)調(diào)技術(shù)等問題了，會有更多的時間來管理項目。在開發(fā)團(tuán)隊中個人自由與紀(jì)律規(guī)范是非常尖銳的矛盾，對于度的把握更難以衡量了，我覺得只要不影響項目的進(jìn)度，不影響項目的質(zhì)量，遵守公司的各種規(guī)范，有些問題是可以通融的。其實團(tuán)隊開發(fā)關(guān)鍵是一個professional的問題。屬于工作范圍之內(nèi)的，要沒有任何理由的按時完成；不屬于工作范圍之內(nèi)的問題盡量少攙和。不過工作范圍的界定可能又是一個問題吧。其實也可以這么理解，如果你的編程能力很強，只用了2天的時間完成了項目經(jīng)理交給的5天的工作量的話，那么剩下的3天你會干什么？繼續(xù)寫以下的代碼？還是學(xué)習(xí)？我想應(yīng)該是學(xué)習(xí)吧。你不能接著寫以下的代碼，因為你不知道項目經(jīng)理所安排的本屬于5天工作時間之后的后續(xù)工作，可能他要一個中間階段的測試等等。但是由于你急于趕工，因此導(dǎo)致了他的中間階段的測試不能執(zhí)行。還有，項目成員要統(tǒng)一開發(fā)語言，我們公司有個EPSON的項目，除了一個人之外其他的成員都使用delphi5，只有這個程序員用delphi6，你說項目經(jīng)理能不生氣嗎？

[M] 你在前面提到的項目管理部是一個什么樣的機構(gòu)？

[L] 項目管理部是公司的一個專門討債的部門，整天追著項目經(jīng)理要文檔:)。其實怎么說呢，他們是負(fù)責(zé)監(jiān)控項目的整個流程，特別是現(xiàn)在要做CMM，更是需要項目管理部。因為SQA，SCM等都是貫穿整個項目始終的，而且還起著比較重要的作用（有關(guān)SQA，SCM的問題請見后）。因此項目管理部的工作顯得比以前更為重要。而且我們以前項目的源碼、文檔等都在項目管理部有備份，自己如果不小心丟了，還可以找項目管理部要，如果他們也丟了，責(zé)任大了。總之項目管理部是監(jiān)督項目的流程，控制項目的質(zhì)量，而且像需求變更等都需要項目管理部的參與。

[M] 是否可以認(rèn)為，項目管理部是在項目隊伍不夠成熟的前提下才產(chǎn)生的，它既起主導(dǎo)作用，也有輔佐作用，并且該部，對公司的所有項目組統(tǒng)一負(fù)責(zé)？

[L] 項目管理部的主要的工作是跟蹤，管理所有項目的整個流程。特別在CMM中，我覺得它存在的必要性更大了。其實它不應(yīng)該說成在項目隊伍不夠成熟的前提下產(chǎn)生的，或許應(yīng)該說成隨著項目隊伍的成熟，隨著公司的規(guī)范，它可能要發(fā)揮越來越重要的作用了。

[M] 為什么你認(rèn)為項目管理部隨著項目隊伍的成熟，隨著公司的規(guī)范，可能會發(fā)揮越來越重要的作用呢？

[L] 我感覺隨著公司的規(guī)范操作，項目過程中的各種問題、流程、以及解決方案，都會得到很好的積累。積累的結(jié)果不可能局限于某個項目組，某個項目成員。也是說不可能是某個人具有這種積累，而應(yīng)該是公司具有這種積累。公司需要把這種經(jīng)驗總結(jié)下來，保存下來，項目管理部正好可以起到這種作用。既總結(jié)項目經(jīng)驗，又監(jiān)督項目的執(zhí)行，還提供一些經(jīng)驗促使項目少走彎路。在CMM中，項目的各種操作有嚴(yán)格的定義，項目經(jīng)理可能不是很成熟，或者沒有足夠的時間來應(yīng)付各種各樣的工作。此時如果派其他的項目經(jīng)理來監(jiān)督可能效果不是很好，因此項目管理部可以派人員進(jìn)入到項目組，在項目的特定階段監(jiān)督項目的執(zhí)行。

[M] 對review程序員的代碼和工作，你一般是如何做的？

[L] 迄今為止，我還沒有真正的單獨帶領(lǐng)一個團(tuán)隊工作過。在我們剛剛結(jié)束的項目中，我名義上是項目經(jīng)理，但是因為還有一個owner，因此我大部分的精力是coding，然后是幫助項目組成員解決技術(shù)問題，當(dāng)然某些項目經(jīng)理的工作我還是稍微接觸了一下。因此對于項目模塊功能的review，對于代碼的review，我都沒有做，因為我自己的coding任務(wù)太艱巨了。不過如果真的是我，我想首先項目經(jīng)理應(yīng)該按照項目計劃每天檢查項目成員對于功能模塊的完成情況，這是項目經(jīng)理基本的工作。你必須檢查項目成員的進(jìn)度，適當(dāng)?shù)恼{(diào)整項目計劃。然后在項目時間不是很緊的情況下要review程序員的coding，因為雖然程序員把功能實現(xiàn)了，但是代碼可能隱藏著很大的隱患。適當(dāng)?shù)呐囵B(yǎng)程序員的編碼規(guī)范意識，這樣對于程序員個人，還是公司都是一個很好的積累。

在我們公司曾經(jīng)有一個項目經(jīng)理每天要兩次調(diào)整項目計劃，他帶項目真的是很認(rèn)真，很有一套經(jīng)驗的。我們公司還有一個team，當(dāng)項目經(jīng)理review某個程序員的代碼時發(fā)現(xiàn)一個頁面中竟然使用了10個以上的recordset(記錄集)，這種代碼的質(zhì)量太讓人難以接受，雖然功能實現(xiàn)了，但是隱患呢？很危險。因此項目經(jīng)理很生氣的把該程序員訓(xùn)斥了一通。

[M] 你是否認(rèn)為，對需求的正確理解將直接影響項目開發(fā)的后續(xù)工作。實際情況，往往是用戶自身對需求的認(rèn)識也并非總是清楚的和一塵不變的，對此，你怎么看呢？

[L] 對需求的理解肯定會影響項目開發(fā)的后續(xù)工作。因此在市場前期對銷售人員，以及對參與需求調(diào)研的人員的能力，有比較高的要求。他們要準(zhǔn)確把握用戶的需求而且要挖掘用戶的隱含需求，特別是對于用戶自身對需求也認(rèn)識不清的情況，更需要前期的人員有很高的能力。用戶需求不確定是一個不可避免的問題。在任何項目中，這種問題都會出現(xiàn)，所以我們公司對于需求變更，一定比例之內(nèi)是無條件更改的，對于超過比例的需要收費了。在需求調(diào)研階段，我們往往是做demo，要求用戶確認(rèn)。通過demo，用戶的要求和我們的理解能比較好的達(dá)成一致。

[M] 需求變更超過比例的需要收費，則公司無形中承諾了這種變更將不會使項目出現(xiàn)問題，這一點團(tuán)隊成員上下都需要保證的，那么，如何保證呢？有沒有反例呢？

[L] 其實任何公司都不會允許客戶無休止的更改需求，因此需要采取某種手段來制約客戶的需求更改，我想收費的目的也在于此吧。至于目的是否能夠達(dá)到，效果如何，終是否把需求變更的錢收回來是具體另一回事了。

[M] 我想知道在你所在的公司，在項目開發(fā)過程中，是否存在由于需求變更的程度很大，而導(dǎo)致項目形勢很糟糕這樣的現(xiàn)象，或者由于采取適當(dāng)措施而“化險為夷”的事例？

[L] 由于需求的變更導(dǎo)致項目的問題我倒是不太敢確定，不過我曾經(jīng)接觸的項目中由于客戶的不成熟，或者說雙方對需求的理解不夠?qū)е马椖框炇胀涎拥氖虑榇_實存在。

[CMM]

[M] 你在項目中采用CMM管理有多長時間了？對CMM的印象如何？從開始接觸到目前為止對其認(rèn)識是否有變化呢？

[L] 對于CMM整套體系我還不是很熟悉，而且我們公司在做CMM的規(guī)范時我的項目正緊，因此也沒有時間參與其中�？偟膩碚f，我們公司是在近剛剛啟動的幾個項目中采用CMM管理的，我手頭的這個項目還沒有正式開始，我估計正式開始后也會采用CMM管理。所以我從未使用CMM管理過項目。對CMM總的印象是項目過程文檔化，一個項目結(jié)束可能需要產(chǎn)生40、50個文檔，而且這種管理模式對于比較大的項目應(yīng)該是很有用的，但是對于小項目好像用不上，但是我想或許應(yīng)該從小項目來實踐吧。

[M] 在前面的談話中，你曾提到“CMM中強調(diào)大家的整體參與”，從實際角度出發(fā)，你是如何理解這一點的？在公司規(guī)模不同的情況下，這種“強調(diào)”又是如何具體體現(xiàn)的？

[L] 或許在CMM中沒有涉及到“CMM中強調(diào)大家的整體參與”這句話，這只是我個人的一點意見而已。因為在CMM中追求項目結(jié)果文檔化，因此項目文檔是一個比較大的工作量。我們公司一個項目結(jié)束后可能要產(chǎn)生50多個文件，如此大的文檔工作量，如果讓一人完成可能不太現(xiàn)實，而且文檔的維護(hù)也是很大的工作量。因此需要把概要設(shè)計，詳細(xì)設(shè)計等工作的一部分交給各程序員做，因此也做到了大家參與。而且對于系統(tǒng)采用的技術(shù)，某個模塊的具體流程等每個人肯定有每個人的想法，因此需要集思廣益，大家參與討論。無論公司規(guī)模的大小，比如微軟，可能整體的大架構(gòu)程序員不能參與，但是具體到小模塊時，程序員會參與其中。對這一點我的體會在于概要設(shè)計和詳細(xì)設(shè)計上，前提是大家都深入了解了需求，然后每人負(fù)責(zé)一部分模塊的設(shè)計以及coding、文檔的工作。

[M] 是否可以這樣認(rèn)為，在小規(guī)模的team中，程序員該主動參與框架結(jié)構(gòu)的設(shè)計等整體設(shè)計工作。而對于大型的軟件開發(fā)公司（比如微軟）而言，這種方式是否不適合呢？在CMM中是否對此有所提及。

[L] 我的一點想法，在CMM或者公司中都沒有具體談到這個問題。確實象我們公司做的一般都是針對性很強的項目，所以在項目過程中大家都有自己的看法、自己的設(shè)想，而且項目經(jīng)理或者所謂的系統(tǒng)分析員也未必是考慮得十全十美。所以我的想法是大家一起開會討論研究整體的系統(tǒng)框架等問題，這樣能夠集思廣益。對于項目中的難點，關(guān)鍵的地方，大家都有個比較清醒的認(rèn)識，也利于大家團(tuán)結(jié)一心。我覺得即使在微軟，他們也會或多或少地參與，他們也會提出他們的建議。好，這個問題留待討論，實踐。