不過，為了回答MaoYang的問題，我將回應分成兩篇文章：
- 關於「研發記錄簿」
- 為什麼工作還是接不起來？
這是第二篇，我將分別回答說明MaoYang文章內的多個問題，其實和「研發記錄簿」一點關係也沒有。
我自己認為
MaoYang所說的情況，可能是以下的幾件事情之一沒作好，才導致發生以下的這些問題：
- 管理機制沒有到位
- Review不落實
- 沒有相關的配套措施
管理機制沒有到位
我認為有些主管自己都不曉得寫文件的目的，甚至認為寫文件是浪費時間的事，但因為公司有這個制度，又不想要明著不作，就消極地「配合」。
以軟體開發機制來說，文件的種類從：需求、規畫、設計、實作、測試都包含在內，因此有些公司就因此寫了一堆他們認為無用處的文件：寫的人不用心寫、該看的人不去看、該檢查的人不檢查、該管理的人不去管理。
但這真的是撰寫文件的目的嗎？也許以後我可以針對這點再寫我的看法。
Review不落實
因為管理機制未落實，欠缺教育訓練的機制，使得主管根本不了解Review機制設置的目的，自然對於屬下所寫的所有文件（包含「研發記錄簿」）也不會用心的看。
但只要一發生主管不用心看文件的情況，就可能會產生以下的幾個結果：
- 文件內容浮爛
一包垃圾沒有用處，一百包的垃圾也不「研發記錄簿」會變成有用的資源可以回收。 - 內容有價值，但被輕易地放過未放入KM的經制內。
導致大家還是找不到對大家都有幫助的內容，以致於其他的員工又重覆犯了同樣的錯誤。
沒有相關的配套措施
即使主管看了，員工也寫了有用的文件了，仍然需要其他的活動配合。例如：- 設置鼓勵員工投稿的機制。
讓員工願意繼續將腦裏面有用的資訊放入公司的KM機制，讓有需要的人可以參考。 - 設置KM機制。
其實不一定真的要花大錢買KM，只要具備知識分類、儲存、評價、更新的功能或機制（例如Wiki、部落格），就可以作為管理知識的平台。
其他
會發生這個情況的原因還有很多，但我自己認為，只要前述的幾個活動沒有作好，不論是不是「研發記錄簿」都有可能會遇上MaoYang的問題，因此我認為MaoYang將這個問題，歸究於「研發記錄簿」，對它而言可說是非戰之罪。關於ISO系統
另外，MaoYang也提到「即使是已經導入ISO的公司，也會發生技術沒有承傳的問題，導致後人無法接前人的工作。」 我自己認為，只要前述的幾個活動沒有作好，即使是已經導入ISO制度的公司，仍然有可能會遇上MaoYang的問題，只是機率比較低。 為什麼我這麼說？因為ISO制度在設計時，就針對系統與現況之間的差距作了調適的機制，也就是要求文管中心定期對系統的文件作Review和檢討，以彌平系統與現況之間的差距。 如果經營者或管理者存著：只要拿到ISO認證、不是真的要作ISO系統的心態，更不想要花成本讓維護ISO系統的人員，定期執行檢視系統的工作，以避免影響線上的工作，ISO系統就作不好。 只要經營者有前述的心態，不論是不是導入ISO系統，甚至導入的是ISO 90000、CMMI都還是會遇上MaoYang的問題，因此MaoYang將問題要歸究於ISO 9000，我認為還有商確的空間。OpenSource的工具
至於MaoYang提到「OpenSource的成員雖然分散在各地，但能透過工具來協同運作完成專案。」的情況，我倒認為和這些工具並沒有直接關係，重點在於背後使用這些工具的思維。 怎麼說呢？因為OpenSource的成員必須具備：對軟體開發的成熟度到達了一定的程度，才能充份的運用協同運作的工具來開發系統，這才是他們能進行遠距溝通、開發系統的真正原因，而不是這些工具。 因為如果這些工具這麼棒，那是不是所有使用這些系統的人，都能達到相同的結果呢？ 換句話說：這些工具根本不是重點，重點是他們如何約定開發系統的流程與模式來搭配工具的「隱性知識」。 這時，MaoYang所提到導入ISO系統則是將這些「隱性知識」具體化、管理化的過程，同時用5W2H的方式，具體說明這些「隱性知識」。 因為如果ISO系統執行的夠徹底，這些「隱性知識」將無所遁形。至於CMMI的案例
文中MaoYang還提到「一家CMMI Level 3的軟體公司承接了高鐵票務系統、但是品質似乎沒有預期的水準的案例。」 對於這個情況，我一言以蔽之就是前面提過的「管理機制沒有到位」。因為如果管理機制真的到位了，後面的「Review不落實」、「沒有相關的配套措失」發生的機會就更小；如果它們不會發生，這些情況根本就不會出現。 另外，MaoYang提到「學習OpenSource的開發模式來進行公司內部的專案管理, 會比導CMMI好很多」。 我自己認為MaoYang所謂「OpenSource的開發模式」，其實就是我前面說的那類「隱性知識」，但如果真的了解CMMI Level 2(Managed)的KPA，就知道CMM2是由6個關鍵流程領域（Key Process Area, KPA）組成：- 需求管理(RM)、
- 軟體專案計畫(SPP)、
- 軟體副合約管理(SSM)、
- 軟體品質保證(SQA)、
- 軟體構型管理(SCM)。
我想特別回答
MaoYang「是不是CMMI也跟ISO 9000/9001一樣...是管不到個人的Decipline」的問題？ 我猜MaoYang說的是Discpline(紀律)，但如果MaoYang說的真是紀律，那我覺得MaoYang的觀點還必須修正。 因為，CMMI或ISO就像是由公司內所有人員來執行的「法律」，倘若CMMI或ISO變成無法要求人員執行的「法律」， 那這將不是CMMI或ISO的問題，而是經營者或執法者的問題。 就經營者而言，是否有執行這些「法律」的決心，將決定執行這些法律的效果；就執法者而言，是否有效的設計這些「法律」，將決定執行這些法律的效率。註
我這裏說的「執法者設計法律」是因為CMMI或ISO都是由企業內的QM或QA部門/人員來主導/監督執行，但現實中的制定法律/執法人員並非同一個單位，故此特別說明。
沒有留言:
張貼留言