決策者對軟體開發可能一知半解，他們會想當然地認為軟體開發過程比較「簡單」：從市場上找乙個技術帶頭人，然後組建乙個開發隊伍，其餘的事就是下達需求，你給我開發出軟體來。
這對於技術主管來講面臨的局面會非常尷尬，即需要向領導非常困難地解釋一些他們根本不能理解的問題。又需要承擔起巨大的壓力。「先天不足」的需求也是乙個非常大的挑戰，因為創業團隊根本沒有乙個成型的現在可操作的流程可以讓技術主管去參考。這需要技術主管有非常好的市場前瞻性，同時也要有非常好的架構延展性。
創業期，團隊知道要做什麼，也知道要怎麼做。然而一旦細化下去之後，問題會非常的多，非常的複雜。要使這些業務流程條理化，清晰化，還需要技術主管進行指導。缺少指導的技術實現會遠低於預期效果，而且軟體系統可能存在嚴重的延展性不足。
技術主管要面臨的另乙個辣手的問題是，是來自上層的非軟體開發領域的管理方式的影響。開明的老闆不會過多的關注技術主管的管理方式，但在管理一支新軍時，戰鬥力可能會比較低，在一段時間過後，上層可能表示不滿，他們可能以一種更為自信的態勢來插足軟體開發的管理。
這時，技術主管最好不要過多地去計較，我們不排斥一種新的管理方式，但需要技術主管密切觀察這種管理方式，可以吸納一些好的方法，但也要及時發現負面影響。這不是一天兩天能發覺的，但越早越好。盡早樹立起自己對管理的話語權，否則技術主管只得揹負起「能力有限」的評價。
還有一件事情是技術主管無法把控的，那就是不斷膨脹的細化的需求，老總下達的需求只是方向性和概括性的。即使你做了比較細緻的文件，他也只是掃一眼而已，因為他不懂這玩意；其次他也沒有精力和耐心；再次，他認為這是技術主管應該把好的關。對老總來講最好的方式是讓他看到軟體原形！
由於是創業階段，很多東西都沒有可借鑑性，隨著乙個個原形的出現，超出預期的時間會累加的越來越多，這會讓上層感到不安，更為可怕的是，為了實現最終目標，決策層在實現
「路徑」上爭論不休，使得需求忽左忽右，時間的浪費也是很可觀的。這樣企業不得不在指定的期限內精簡功能集，但還是有可能會造成延期的情形。
在這種緊迫感的驅動下，軟體的管理可謂是一種挑戰，因為我們可能忽視軟體的「質量」，即使臨時渡過了難關，後期也可能會有很大的維護工作去做。甚至很多設計都需要推倒重來。所以技術主管的工作將任重道遠。
需求文件對於創業階段來講是一種挑戰。不斷變化的需求及沒有細化的需求，使得你不能夠在開發階段擁有乙份完整的相對穩定的需求文件版本。如果按照規範的文件來書寫需求文件，那將是一件相當痛苦的事情。此時最好不要用正規的諸如word之類的文件格式來儲存，我們需要乙個可以靈活組織內容，變更內容的工具象uml建模工具，mindmanager等都是不借的選擇。
需求文件的整理需要開發團隊中的大多數人員同時進行，技術主管會將需求分成幾大塊，由不同的開發人員去主導。不過有一件另人沮喪的事情，這些開發人員做程式沒有問題，做設計也沒有問題，理解你要做什麼也沒有問題，幫助你規範業務流程也沒有問題。有問題的是，他們可能不善於表述！由於專業性的不足，及以時間緊迫為藉口很有可能他們寫的需求文件形同虛設。雖然如此，他們中的部分人還是希望得到這方面的鍛鍊的。此時最重要的產物不是他們文件上寫下來的，而是通過交流大家了解到實際的需求情況。
技術主管有必要對核心業務流程進行詳細的闡述，使其清晰與明確，對於其它簡單需求或相對獨立的附屬需求則可以寬容對待，不需要嚴格的文件約束，也沒有辦法和精力去使全部的需求文件內容詳盡。
在創業階段，拿iso的標準來規範現有的軟體開發流程就象在開玩笑一樣。但80-20原則還是執行的倒是非常的透徹。我們必須相信開發團隊中的每乙個人的能力，我們必須充分放權以給他們充分的發揮。團隊中的每乙個人都需要獨擋一面。我們假定每乙個人都有能力處理在開發中遇到的細小問題。因為我們分配的任務是按需求一大塊一大塊的分配的。每個人都是設計的主導者，也是**的實現者。在這樣的情況下，我們去尋找規範和自由的平衡點真的不是一件容易的事。這裡就應用一下80-20原則：
我們重點關注20%的需求的設計，這20%是業務的核心，其餘的80%是輔助或次要的。我們不是只對20%的需求進行設計，而是要對100%的需求進行設計，只是對核心業務要格外關注而已。
每個設計用20%的時間書寫文件，用80%的時間討論問題。
文件的內容為規範性文件所要求的內容的20%，其餘80%不需要。
另外需要接受下面的事實：
一、是所有這些設計中只有20%是優秀的，80%是有「缺陷」的。而這些有缺陷的設計主要是指：
1、 缺少延展性
2、 設計過於理想，有些可能根本用不到
3、 實現方法不是最優的。
二、80%的設計是可以工作的，即使那些有「缺陷」的設計也是可以工作的，他們可能直接被應用到編碼中去！只有20%的設計必須重新設計的。
三、設計文件並不能很好的指導別人進行編碼，而只能指導設計者自己去編碼。有下面的原因：
1、 設計文件不完整
2、 開必團隊中的職責劃分沒有那麼明細，沒有專門的編碼人員和專門的設計人員。
3、 不同組員之間的設計思想及設計習慣的不同，使得他很難接受別人的設計。這是新團隊缺少磨合造成的。
技術主管必須在設計環節嚴格把關，但不要拘束於形式，只要透徹的明白設計者的思想即可，否則今後苦果不斷。設計的產出其實有很多的缺陷，但這些缺陷是可以容忍的。技術主管完全可以讓架構師設計好所有東西，然後再去編寫**，這樣設計會渾然一體。職責也明確，但會有下面的問題：
一、我們有少數的特種部隊，而不是大量的正規軍。
二、架構師在設計時，其它人做什麼呢？
三、每個人都有表現慾，且他們能夠做事情，只是經歷上可能沒有你豐富。他們也希望在這種環境中成長，這也是最好的成長環境。
四、我們的時間還是少得可憐！
五、我們希望團隊中的每個人都有能力帶領一支部隊。
六、我們需要彼此了解每個人，取其精華，去其糟粕，最後形成我們的共識。
對於有缺陷的設計，技術主管可通過團隊會議來巧妙解決，但不是所有的問題都會令你滿意，只要不是本質上的問題，還是可以繼續的。這裡面有很多「缺陷」是個人的習慣、經歷、性格等形成的，對於這些「缺陷」在創業階段需要有足夠的「包容」心。
未完待續……
軟體開發管理
scrum感言 軟體流程的名稱太多，rup,v model,iso9000，cmm等等不一而足。最近接觸了scrum，收穫良多，與諸位同仁分享。自從有人類社會活動以來，就形成了各種各樣的組織和制度，上到社會體制下到家庭環境，西方到東方，社會風尚 工廠流程 等等，這些東西都具有一種共同的特點 都是為了...
軟體開發的風險管理 之二
這篇文章準備講講風險管理的一些基本原則和應對方法 首先總結一下我在我們專案中遇到的風險以及應對方法 風險名稱 風險描述 發生概率 影響應對方案 例子其他 人員風險 專案人員的能力與專案的要求之間的差距 專案人員的流動低高 1，對於重要的專案，選用能力強的開發人員 2，引入高階開發人員對設計和 的re...
初級軟體開發管理
負責團隊一線管理工作的，大多是做而優則仕，在程式設計上表現優異，被提拔成組長，是否具備管理才能，是否適合做管理，一般不會被公司特別考慮，更別說管理經驗了，新官上任三把火，剛剛被授予管理權力的開發人員，在管理上很積極，但由於缺乏經驗，也常常做出過猶不及的事情來，這麼多年工作中，遇到過下面幾種情況 老好...