過程改進，顧名思義，即是對過程的改進工作，也或者說對過程進行改進。那麼何謂過程，本人的理解就是：過程就是為達到某個目的所要採取的方法和步驟。簡單些說，過程就是方法和步驟的集合。
任何公司做任何事情，應該都有一定的目的性。而要達到這個目的，就必須要考慮採取什麼樣的方法，通過什麼樣的步驟才可以完成。或許你不覺得你的公司做事有什麼方法，你認為你的公司可能都是領導乙個人說了算，沒有章法，那麼「沒有章法」也就是你公司所謂的做事的方法。當然，你也可能認為你公司做事沒有什麼步驟，今天這樣做，每天那樣做，可能後天的作法和前兩天做事又不一樣，但你必須承認，不論怎麼做，都一定有步驟，只是同樣的事情在不同的時間採用了不同的步驟而已。
過程改進，就是對你的公司進行做事方法上和步驟上進行改進，把不好的改進成好的，把好的改進成更好的，把不合理的改進成合理的，把合理的改進成更合理的。
本人從事的是it行業，從事軟體開發相關工作，因此這裡只涉及到軟體公司的過程改進，因此下文中的內容更多的是站在軟體公司的角度上去理解過程改進。
如何理解方法
在軟體公司，在各個過程域中都存在方法，比如怎麼獲取需求，需求應該關注那些內容，使用什麼工具開發**，怎麼做設計，設計中應該考慮那些方面，在大的方面，專案使用什麼樣的開發模型等這些都可以理解為方法。
如何理解步驟
前面講到的某個開發模型，其實就有若干不同的步驟組成，必須獲取需求階段，設計階段，開發階段，測試階段。對某個階段而言，又會拆分為不同的步驟，比如需求可能包括前期調研，需求整理，需求確認等。
軟體公司應該考慮那些過程改進
不同的軟體公司會有不同的特點，但軟體公司的共性就是專案開發。因此過程改進就需要對專案進行全盤考慮，把專案涉及到的各個方面進行分類，分成不同的過程域，對每個過程域進行細化，找出通用的實踐和過程域獨有的實踐。所幸cmmi已經對這些過程進行了細化，按照不同的成熟等級，每個等級都細化了不同的過程域。很詳細的內容可參考我另一篇文章《cmmi所關注的過程》，這裡只對這些過程域做簡要描述：
rm：需求管理，對需求進行管理並識別與專案計畫和工作產品之間的不一致之處。
pp：專案計畫，建立並維護對該專案計畫的承諾。
pmc：專案監控，對照專案計畫監督該項目的實際效能和進展。
sam：採購，建立並維護與**商的承諾。
cm：配置管理，建立並維護用於標識工作產品的基線。
ma：度量，使測量目標和測量行為與資訊需要和目標相一致。
ts：解決方案，從備選方案終選擇產品或產品元件的解決方案。
pi：產品整合，產品或產品元件要做整合的準備。
ver：產品測試，要驗證產品功能。
val：產品驗證，客戶對產品進行驗證。
ipm：按照專案以定義過程管理專案。
rskm：風險管理，在專案管理過程對風險進行管理。
dar：決策，基於既定標準對可選方案做決策。
組織級關注
opd：組織過程定義，建立並維護組織級的過程資產庫。
opf：關注組織過程，按需或週期性的識別組織級過程的強處，弱點和改進機會。
ot：組織級培訓，建立並維護支援組織管理和技術的培訓能力。
過程改進該如何實施
1， 成立過程改進小組
2， 參照成熟企業的標準，如cmmi，iso質量管理體系進行詫異分析，找出改進點。
3， 過程改進小組對改進點進行分析，找到改進方法，制定相關工作規範，並實施推廣。
過程改進持續進行，過程改進小組要定期或者根據公司需要識別改進機會，找出公司相關制定的弱點，對這些機會或弱點進行分析，找到解決方法，制定解決的措施，並實施推廣。
過程改進，還是目標改進？
公司通過了cmm2,cmm3,iso9000的評估，拿到了證書，也建立了一套質量體系，但是，現在，並沒有真正在軟體研發部門達到cmm3，只能說，是某些專案達到了。於是，我想到了乙個觀點 公司的不同階段有不同的質量目標，生存階段的目標是有市場，有業務可做，有公尺來下鍋 發展階段，有業務可做，可以保證公...
為什麼要做軟體過程改進工程師
說實話，寫東西是被領導逼出來的，在此之前，從來沒有寫東西的習慣，最多是年底的時候被領導，或者被人力部門的考核逼著，應付著做個年度考核的ppt，或者象徵性地寫寫今年的收穫啦 不足啦 明年的期望啦什麼的，這麼認真而且堅持地寫東西，長這麼大還是頭一次。好了，言歸正傳，說說我為什麼要做軟體過程改進工程師。在...
為什麼要做軟體過程改進工程師
說實話，寫東西是被領導逼出來的，在此之前，從來沒有寫東西的習慣，最多是年底的時候被領導，或者被人力部門的考核逼著，應付著做個年度考核的ppt，或者象徵性地寫寫今年的收穫啦 不足啦 明年的期望啦什麼的，這麼認真而且堅持地寫東西，長這麼大還是頭一次。好了，言歸正傳，說說我為什麼要做軟體過程改進工程師。在...