哈米尼斯的天空

在溫柏格的書中介紹了2個觀念，讓我深思許久

 ü          軟體的品質是相對的

ü          沒有一家軟體公司是一樣的；沒有一家軟體公司是不一樣的

我們很容易犯的錯就是，把品質當做是一個絕對性的指標，所以我們會用Bug的數量或是客戶有沒有唉唉叫來決定品質(其實有些公司即使客戶唉唉叫也會當做品質很好)
可是我們很容易忽略的是我們設定的立場和客戶本身的立場是不同的，所以對於同樣一套軟體的品質定義就會很不同。 

以我待過的elearning軟體公司為例吧

以平台廠商而言，能夠把許多的功能做到完整，讓客戶最好不要煩我們就可以做一些他們想做的事，這是最好的(#1)

而對客戶中的承辦人員而言，能有許多功能固然不錯，但是他們會更關心可以買許多不同的教材，讓自己推廣elearning看能來有聲有色，績效感覺起來也會比較好(#2)

可是，對於客戶中廣大使用elearning的人員，能夠方便的觀看教材、完整的記錄閱讀時間和考試記錄，最好是都不要有錯(#3)

而對於主導elearning的主管來說，elearning通常只是一種手段，他更關心的，反而是能不能和人事、績效或是目標管理系統等等異質系統的互通和漂亮的報表(#4)

從以上的例子來說，在不同的角色上，對於同樣一個平台的期望和要求就不同，因此也會產生出不同的品質要求的內容。

這就是和專案管理中講的利害關係人一樣，總是要先找到輕重緩急，設法去取得平衡點，而不幸的是，我之前的公司，對於品質的策略沒有設定得很清楚，以致於每個PM沒有所謂衡量標準，最後的結果就是工程師疲於奔命。

而這一個問題有沒有辦法改善吶，坦白說我覺得很不容易，因為這一問題會回歸到產品本身的定位，可是多數的軟體公司不見得有人能做好這一塊(絕大多數的軟體公司會以技術人員任管理職，所以容易缺乏Marketing的能力)

第二個觀念就真得很有趣了，每一家軟體公司，它們所處的產業別、開發方式等等，當然都是不一樣的，可是呢，這些軟體公司它們所面臨到的專案問題、管理的瓶頸，卻都又大同小異，差異僅在於一些環境參數的變化而已，所以，溫柏格提出軟體公司的專案成熟度的分類，和CMMI中的Level是可以相互對應的，針對這些問題的解決，他研究出一些Patten，可以用來處理這些狀況。

這裡我不免要提出一些題外話，日前，在獨孤木的Blog上，他就說了，其實很多他的讀者來信的問題都是類似的，他只是換個角度和說法而已；而在曚曚的Blog上，他利用UML的方式來簡介CMMI，這都是我推薦大家可以參考的部份。

我以我的例子來說明吧，我目前的工作是派遣到軟體公司協助他們開發系統，我透過這樣的方式，讓自己去可多歷練不同案子，多看多學多了解其他軟體公司的運作；這樣的過程中，不論這一家公司規模大小，其實同性質的問題，都一再重覆的發生，例如：專案的Scope掌握問題、人力不足和流動的問題、測試和品管的問題、客戶滿意度低的問題等等，大抵上所有的問題幾乎都是差不多的戲碼上演，以我的角色來說，我頂多是提供建言，有些採納我的建議的，也許避掉或減輕了一些狀況，有些沒有採納的，就如同我猜測，往不好的方向發展。 

我記得幾年前，一位HR的朋友告訴我，每一家公司的問題其實都差不多，只是看你能忍受的程度到那裡而已，不要太期待下一家會更好，重點反而在於你怎麼去適應它而已。

恰巧我這段日子的經驗很實在的印證了這一段話，也印證了「沒有一家軟體公司是一樣的；沒有一家軟體公司是不一樣的」