一般軟體開發組織，在軟體專案結束時會進行專案總結會，利用專案中的統計資料對專案中發生的成敗得失進行總結分析，然後制定出改進計畫，以希望在下次專案可以做的更好。然而，多年過去之後，對比一下現在的資料和當初的資料，基本上可以得出乙個結論：這麼多年沒有絲毫改進，甚至還有退步的跡象。
這是發生在很多地方的現象。為什麼會發生這種現象呢？本人就那些無用的專案總結會以及無用的過程改進建議進行原因分析以及提出解決對策。
專案總結會的原意是遵照戴明環(p-d-c-a)進行改進的一種方式。它通過對專案發生的成敗得失進行總結，並且制定詳細具體的行動方案，以達到團隊能力成熟度提公升的目的。
專案總結會要由以下要素構成：
時間、地點、人物、資料、分析過程、分析結果、改進建議、行動方案計畫、改進過程監督、改進效果評估、結論。
有些組織甚至連上述的必要要素都不全面，比如：專案總結之後沒有改進計畫。
對於要素全面的組織來說，他們還有下列問題：
時間不對
大部分組織的專案總結會時間不對，他們選擇在專案結束後，資料統計完畢再開始召集相關成員召開會議。這是乙個錯誤的時間。基本上軟體專案都要半年以上，而人們無法記住海量的事情，並且將細節能夠完全還原，尤其是經過了這麼長時間。所以，專案總結會，往往變成了專案追思會。
當表達方式中像下面這樣的詞彙出現比較頻繁的時候，基本上就說明了這個問題。
「當時好像是」「我記得當時」「大概情形是這樣的」
基於這樣的資訊如何能夠做出準確的判定呢？
所以專案的總結會應該短週期頻繁的召開，建議週期為4-6周一次。
總結，前一段時間發生的事情，這時候記憶猶新，可以相對正確指出其中的問題，並且得出合理的改進建議。
但是，反對者認為，對詳細設計的總結無助於**書寫的改進。關於這一點，我將在《荒謬過程》裡逐步闡述其觀點中的基本錯誤。
參加人選有誤
有的組織有sqa，基於組織整體改進的要求，專案總結會的時候會叫上sqa，有助於對資料進行分析，例如：整體組織的生產率為300行/人月，但是某團隊的生產率為1000行/人月，那麼sqa會提出這個資料嚴重超出平均水平，從而得出：過程不夠規範的結論，從而要求乙個高效的團隊降低其開發速度。這樣的荒謬結論就是因為參照了荒謬的標準造成的，而sqa的作用基本上是獎惡罰善，所以，叫sqa來參加專案總結會是大錯特錯。具體為什麼說sqa是獎惡罰善，我將會在《攪混水的sqa》裡詳細說明。
對於動輒上百人的團隊，也考慮到不會讓所有人參加會議，於是只叫了幾個「管理人員」參會，於是大家開始一場望風撲影的討論，結果就形成了一套風馬牛不相及的結論。
資料意義不大
現在團隊統計的資料往往都不具備參考價值，即使那個資料是真實而準確的，因為統計的資料意義本身是錯誤的。具體請參照拙作《你的專案統計這些資料嗎？》
基於無意義的資料做出的結論也是無意義的，得出的改進方案也是隔靴搔癢的。
分析過程淺嘗輒止
分析原因要分析根源原因。很多原因分析過程往往停留在表面，不願意深入分析，例如，把bug產生的原因歸為**書寫錯誤，這無助於改進**書寫，**書寫錯誤的原因是設計有誤，還是理解有誤，還是技術力不足，還是別的什麼原因。分析原因的時候應該不斷地問為什麼，直到找到真正的原因，並可以制定出改進措施為止。否則，停留在表面的分析是無法得出正確的改進措施的。
知識不足，無法分析出真正原因
雖然有些組織，可以通過不斷地問為什麼，然後制定改進措施，但是由於其知識的不足，其分析原因的路線產生了錯誤，只能得到錯誤的結論。
有乙個非常生動的例子，是乙個關於缺少了某判定條件產生的處理錯誤的分析過程。
為了後續說明方便，我把每個分析步驟增加了字母標號。
bug產生的原因是**書寫錯誤
**書寫錯誤的是因為設計有誤
設計有誤的原因是條件分析不足
條件分析不足的原因是考慮不周
考慮不周的原因是因為缺少輔助分析的檢查單
改進措施就是建立分析輔助工具——條件分歧檢查單
這個過程看似無懈可擊。但是這個分析過程的根本問題在於知識體系不足。我們讓另外乙個專家來分析這個問題的產生原因，他是這樣分析的，為了區分上述過程，我在字母後面加上了數字1.
a1. bug產生的原因是**書寫錯誤
b1.**書寫錯誤的原因是因為違背了單一職責原則
c1.違背單一職責原則的原因是開發者缺少相關知識
d1.改進措施是進行物件導向技術培訓。
為什麼兩個分析過程的起點相同，卻達到了不同的路徑。因為前者缺少相關的知識，他認為對於設計過程增加了相關的檢查單就可以解決問題，但是，每種情況的複雜度都不同。如何通過乙個檢查單來覆蓋所有的分支處理呢？
其實，原來**的if-else巢狀可以通過物件導向的一次呼叫以及若干過載來代替，這樣就可以從根本上來規避條件缺少的問題，因為這規避了問題產生的直接原因：影響邏輯的變數太多。但是，第乙個分析者並不了解物件導向技術可以很好地解決問題，所以沿著自己的思路得到了錯誤的結論。
改進措施無法實施
有些組織的改進計畫都是些籠統的如：提公升設計能力，加強溝通。
有的略具體一點，但是卻仍然無法指導行動，比如：增加**複查時間。
有的很具體，但是無法實施；
有的可以實施但是卻沒有負責人；
有的有負責人，卻沒有設定完成時間；
有的有完成時間，卻沒有檢驗改進效果的方式；
改進措施要具體可行，並且要跟蹤改進效果。
首先要具體。
避免使用：加強、提高、提公升等模糊的詞語，改用增加、減少、替換、交叉、建立等明確可以執行的動作。
其次要可行。
如果設定的改進方案無法執行，那麼分析了也無法進行改進。
再次要有時間限制。
改進措施不可能無限期延長。需要有明確的執行時間限制，並且如果有必要還要設定里程碑，分階段的改進。有些事情不是一蹴而就的。
然後要有負責人。
改進措施如果沒有安排負責人，往往會束之高閣，置之不理。最後，也沒有進入真正的改進行動。
最後要有檢查效果的方式。
如果改進措施實施了，但是卻沒有檢查改進效果，那麼到底改進措施是否有效就無從可知了。
改進措施無效
改進措施無效往往是由於前面幾個原因中的乙個或多個產生的。比如：針對「需求變更導致了後期工時的增加，從而引起了專案的延期。」提出的改進措施是及早凍結專案需求。然而，客戶根本無法凍結專案需求，因為制定需求是乙個guess work。這個改進措施根本無法執行，也就沒有效果。
管理人員誤導
a． 絕對表達的謬誤
常見的管理人員的一句質疑是：「如果***是問題的原因，那麼解決了這個就能夠解決問題嗎？」這句話是一種絕對表達的反問句。沒有人會回答yes。因為導致問題發生的原因往往是多方面因素造成的。而並非單方面。因此誰也不能說解決了這個就解決了所有問題。於是一條可以改進的措施就被否決了。
b． 不願意對固有的但是根本上的東西進行變革
對於很多專案來說，其根本的原因是流程錯誤，但是很少有分析的時候能夠得出這個結論。一方面固然有知識不足的原因，另一方面，即使有人提出是過程的問題，管理人員為了維護自己的尊嚴，不願意承認這方面的問題，往往會提出反對意見，顧左右而言他，推卸責任。有時還進行人身攻擊。
c． 不願意承認工具落後
管理人員喜歡用一句話來掩蓋工具落後的問題：「明白原理比使用工具更重要」。這句話是正確的廢話。
以上是對於無用專案總結會的分析和改進措施。你有什麼見解？
Python庫總結會
scikit surprise是易於使用的python scikit，適用於推薦系統 gensim scikit learn是簡單有效的資料探勘和資料分析工具 whoosh是快速，純粹的python搜尋引擎庫 recsys是提供了構建和評估許多推薦系統 演算法效能的工具 lenskit是一組用於試驗...
部門總結會（0428）
今天參加了部門組織的專案總結會。受益匪淺，特此記錄。總體上，這次分享會是比較成功的，因為實現了 業務 與 政治 的雙重目的。業務上，大家一起回顧了專案，分享了自己的心得。通過一些討論，加深了對一些問題的認識。政治上，總結會從一開始的拘謹逐漸走向歡聲笑語，大家加深了對彼此的了解，也拉近了彼此的關係。這...
里程碑作用的總結會 2010 03 （20 21）
週六日整整開了兩天會，如此強度還真是有點不適應，不過收穫頗多。這次開會主要圍繞著我們近一年半以來所有學習知識的巨集觀把控和細節彙總，拿公尺老師講的 農民收莊稼 的例子來說，我們這是在對我們過去一年半以來耕耘的土地進行收穫，對收穫的 莊稼 還需要進行分類 彙總 消化吸收。如是，公尺老師講的 農民收莊稼...