曾經看過cmm的一些資料，當時只是覺著這些東西有些空，而且很複雜，很沒辦法在中國的軟體公司實行。可是，這麼多年過來，經歷了很多的專案，也領導過很多專案，發現對cmm有了新的認識。
cmm的關鍵問題域是很多失敗和很多成功的例子所總結出來的，也許它很複雜，要求也很高，但是如果我們真的理解了這些關鍵問題域，那麼我們應當能從乙個又乙個的專案的失敗中走出來，以科學的精神讓專案成功，讓程式設計師不再『挨踢』，讓他們能夠像普通人那樣生活，休息，休假，驢行，不必有現在那麼大的壓力。
說個實際的吧，現在參與的乙個專案，乙個由於很多的原因做了足足三年的專案，真的可以用失敗來標記它。
從最開始公司企圖用此專案打入某行業的某使用者開始，就注定了專案的路線和失敗。由於公司希望拿這個專案作墊腳石，所以高層在對待這個專案的態度上就搖擺不定，開始是忽視，希望投入最少的人，做最少的功能點，期待後面的大專案。等到使用者不再對後面的大規劃大專案感興趣後，突然發現這個專案變成了乙個可能的潛在的產品，因此又開始重視這個專案。但是由於前期的態度，導致這個專案從一開始的功能需求就是模糊的，使用者的需求的外延在不斷的擴充套件。
同時，由於競爭的原因，使用者要求進行實際的評估。這就給這個本來已經混亂的專案增加了更多的混亂。使用者提出了400多個功能點，給我們的時間只有三個月。如果公司高層能夠認真評估風險的話，可以看出來失敗的風險是非常大的，使用者給出的需求非常的簡單，而且出於競爭的原因，沒有給我們和使用者進行需求調查的機會；結果展示平台一直都處於持續開發的過程當中；對系統所涉及的資料量和資料的複雜程度缺乏足夠的重視，導致後台處理時間幾乎不可忍受；沒有制定測試計畫；專案組與客戶之間沒有乙個穩定的、有效的溝通機制。如果認識到了這些風險，我們本來也是有機會補救的。但是高層沒有這麼做，結果就是大家持續加班將近一年，可是老闆們還是很不滿意，因為使用者不滿意。
如果高層有人拿出任何一本介紹cmm的書，那麼我們的下場可能不會這麼悲慘了。cmm2級裡的那些關鍵問題域會指出我們這個專案是多麼的危險，需求管理，沒有，風險管理，沒有，計畫，沒有，什麼都沒有，只有程式設計師拼命的編碼，編那些注定要被推翻的**，明知道要失敗，卻只能繼續走下去，多麼悲慘的結局，剁末好的程式設計師。
乙個失敗專案的總結
2013年 2014年，筆者參與了乙個大型專案，雲平台下做資源 資產 電子運維管理，由德勤負責需求整合 hp負責系統門戶和硬體整合，pccw負責實施整合。ibm 中興 亞聯 億陽等十幾家廠家做開發分包。專案合同額好幾億。當時我在pccw負責資源的實施管理，與中興 亞聯 億陽一起完成所有省份的實施，一...
乙個失敗專案的覆盤會
2018年5月份筆者參加了乙個失敗專案的覆盤會，領導開場介紹了這個專案的基本情況，2017年中標某集團十多個省的雲平台安檢專案，公司之前做了好幾年上百個類似的安檢專案，經驗較為豐富，所以在多家廠商競標過程中脫穎而出成功中標。但經過一年多的實施，最終2018年5月以客戶退單告一段落。然後讓專案團隊進行...
乙個個人小專案的失敗
最近乙個個人小專案黃了，失敗了。總結一下原因吧。先說說需求 這個專案是我自己想的，完全是處於興趣。做乙個安卓程式，要做乙個類似於rss，把校內網上的新聞抓取下來，展示到頁面上。主要是為了方便及時檢視校內新聞。因為我發現很多人不太愛關注校內網上的新聞，用手機上瀏覽器看新聞也不太方便，所以有個這個想法。...