「研發記錄簿」的二、三事 - 2/2 為什麼工作還是接不起來? - 通達人驛站
2008/11/1

「研發記錄簿」的二、三事 - 2/2 為什麼工作還是接不起來?

這篇文章是要回應網友MaoYang的文章《您還在使用「研發記錄簿」嗎?》。
不過,為了回答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)。
換句話說,當一個開發團隊真正具有CMMI Level 2的實力時,不但早已充份滿足了OpenSource成員所使用的協同運作工具,還超過這些成員所期望的程度,我認這是MaoYang的「學習OpenSource的開發模式...比導CMMI好很多」論點會引來許多人批評的原因。

我想特別回答

MaoYang「是不是CMMI也跟ISO 9000/9001一樣...是管不到個人的Decipline」的問題? 我猜MaoYang說的是Discpline(紀律),但如果MaoYang說的真是紀律,那我覺得MaoYang的觀點還必須修正。 因為,CMMI或ISO就像是由公司內所有人員來執行的「法律」,倘若CMMI或ISO變成無法要求人員執行的「法律」, 那這將不是CMMI或ISO的問題,而是經營者或執法者的問題。 就經營者而言,是否有執行這些「法律」的決心,將決定執行這些法律的效果;就執法者而言,是否有效的設計這些「法律」,將決定執行這些法律的效率。


我這裏說的「執法者設計法律」是因為CMMI或ISO都是由企業內的QM或QA部門/人員來主導/監督執行,但現實中的制定法律/執法人員並非同一個單位,故此特別說明。
 Related Posts with Thumbnails 

0 意見 :

張貼留言