程序員來說是很不公平的。在國內(nèi)，只會照抄別人代碼，一點都不懂創(chuàng)新，凡事依靠別人，快下班就盯著表看的程序員是不少，這種人一般很難有什么前途。但是，優(yōu)秀的不斷進取的程序員也很多。由于國內(nèi)沒有象CMM這樣的軟件規(guī)范或者很少，所以這類優(yōu)秀的程序員不少都是干著系統(tǒng)分析員甚至PM的活，拿著程序員的工資。這類程序員雖然在起步時會吃很多虧，而且是主動找虧吃，然而幾年之后與前一種程序員的社會地位會出現(xiàn)明顯的分化。當上進的程序員們作為PM進行商務談判的時候，前者還在各個公司里頻繁跳槽，跳來跳去都不滿意。有些扯開了，回到我們的話題。
日本的軟件規(guī)范與CMM有驚人的相似，其中至少有35%以上都是幾乎一模一樣的。最近經(jīng)濟不景氣，東京倒閉了160家軟件公司，這個數(shù)字是今年6月份的，還在不斷增加。這些公司紛紛搶灘上海，招收技術(shù)人員。如果去這樣的公司應聘就要考慮清楚了，進去可以學到他們的規(guī)范和質(zhì)量控制，可是要想從程序員成為系統(tǒng)分析員或PM，比登天還難。往往一個程序員進去干了好幾年，對自己的那一塊熟的不得了，而對隔壁同事所做的東西一竅不通。拒傳華為正在嘗試CMM4（華為印度研究所已經(jīng)通過CMM4），對在華為工作的程序員們來說可謂福禍難料。當然，已經(jīng)作到PM或QA或者熱愛CODING的朋友例外。 需求分析本身也存在著時間分配的問題。第一遍需求分析花的時間會最長，分析員們在客戶的各個部門之間幾乎把腿都跑斷，把口水說干，就是為了確立一個初期的需求模型。所有的文檔將會提交給PM進行復審并簽字，不合格的打回重做。反饋表隨之將提交給客戶，第二遍第三遍等等等等接踵而來，與客戶反復討論和磋商，反復提交文檔和表格，目的只有一個，明確需求。當PM最終合并了所有文檔并確立需求之后，最終生成的需求文檔將提交給客戶的各部門負責人簽字。這些文檔將作為合同的附件添加，以便在將來項目變更或者碰到重大問題時和客戶扯皮的重要依據(jù)。
需要說明的是，客戶并非都是蠻不講理，但是說實話，頗有無奈，國內(nèi)目前的項目大多數(shù)客戶為了不讓自己的錢白花，經(jīng)常變著法子提需求。在啟動階段明確需求并簽字，無論最終情況如何，一份詳盡的書面文檔可以解決很多口頭承諾或概念模糊的文檔帶來的許多問題。
上世紀八十年代初美國搞星球大戰(zhàn)計劃，拖跨了蘇聯(lián)。大家對那段歷史有些含糊，很多人認為蘇聯(lián)人上了美國的當。其實并不完全如此，蘇聯(lián)人的情報機構(gòu)無孔不入，并非那么容易上當受騙。實際上當時美國國防部已經(jīng)開始著手NMD系統(tǒng)軟件的需求分析，前后耗資數(shù)億美圓，耗時兩年，僅僅是做需求分析，終于發(fā)現(xiàn)存在著在當時技術(shù)上無法達到的高度，隨后項目被放棄。詳盡的需求分析有一個額外的好處就是對一些雙方都很陌生或者從來無人嘗試的領域?qū)⑹且粋€決定是否進行項目的判斷標準。有時候，這種大項目在簽單時雙方都沒有絕對把握保證可以出成果，一旦在需求分析階段發(fā)現(xiàn)難以逾越的技術(shù)難關(guān)，就會放棄項目。