2010年12月9日 星期四

第十二講 期末總整理 和 成立一個思考俱樂部


()思考為一種人人都能培養的技能

(1)我們必須將負面思考放在該有的位置上,作為整體思考的一部分,但將創造性、建設性和計畫性思考擺在負面思考之前。

(2)我們必須理解知覺如何以自我組織模式系統的方式運作,以及後續種種,譬如,水平思考就理所當然緊接而來。

(3)我們必須將情緒、情感和價值觀放在適合它們的位置上。最終它們會是思考中最重要的部分-只不過它們是在結尾時才派上用場,而不是一開始就發揮影響力。

(4)讓習慣、態度和策略成為我們的第二天性;對自己的思考技能少點自滿,也不那麼依賴那些使用陳舊說法的人來思考,我們的進展會更快速。

(5)本書中倡導的概念:

(i)PO」:直接肇因於模式系統的邏輯。

(ii)「一個概念」的行動價值。

(iii)Exlectics:有別於辨證法。

(iv)「邏輯泡泡」:以直接方式陳述知覺總合及使他人在其間能邏輯行事的結構。

(v)「運作力」:有別於敘述形式的思考。

()思考練習場-思考據俱樂部

思考俱樂部是練習和享受思考技能的一個場所,是為那些要享受思考、想鍛鍊思考技能的人而成立的。

(1)宗旨:提供一段時間與一個場地讓人享受和練習思考。場合及例行程序是其主要優勢。

(2)思考類型:關切的是智慧。思考俱樂部不是一個用來爭論、偏袒和辯護你觀點的場合,而是一個可以公開探索議題和誠實評估的所在。重點在於知覺,清晰又簡單很重要。

(i)思索某個議題這樣的思考本身。

(ii)思考我們如何考量議題(價值觀、偏好、膠著、想不出意見等等)

(3)活動:三階段-1.學習基本的思考技能2.練習這些技能3.應用這些技能

(4)形式和紀律:沒有正確的答案也沒有固定的見解,就必須有十分嚴格的流程紀律;紀律和儀式、程序是取代熱忱的理想替代物。

(5)組織:

(i)人員

(a)籌辦者和主席:籌辦者要擔負起聚會的全部責任,並且表現得像主席一樣。籌辦者應該從一而終

(b)計時員:計時員必須精準又堅決。會議必須準時開始準時結束。

(c)記錄員:記錄員的任務是要為每次會議做摘要報告,列入會議日誌中。整個摘要應該控制在三百到五百字。

(d)聯絡員:提醒會員下次聚會的時間,確認若有人不能參加會提早通知。

(ii)聚會地點

理想的聚會地點是家裡,場所應該都選在同一個地點,聚會時間也最好固定。

(iii)頻率

最佳頻率是兩周一次。

(iv)持續時間

前四次以一小時為限,而後可以慢慢增長至一個半小時,再到兩小時。

(6)會議日誌:應該做會議日誌,記錄每一次的會議(包含時間、地點和出席的人,以及議程和思考內容的摘要-300500字。)

(7)內容:會員都必須閱讀過本書。

(i)在一開始就應該直截了當強調重點只在練習和發展基本的思考技能。

(ii)有必要維持一個嚴肅議題和有趣議題之間的平衡。(從一開始的1:3漸增到1:1)

(8)議程

(i)試辦會議一:

(a)議題-籌辦者設定議題焦點為PMI技巧,提醒會員PMI的性質。

時間:二~三分鐘。

(b)第一個練習-六個人為一組,二分鐘討論正面,二分鐘討論負面,二分鐘討論有趣面。

時間:六分鐘。

(c)第二個練習-三人一組,隔開各自進行PMI討論,六分鐘後,兩組集合報告各自的結果(回饋)

時間:活動六分鐘;回饋四分鐘。

(d)第三個練習-每個人都只作PMI一部分,個別想兩分鐘,兩分鐘後再次集合輪流報告心得。

時間:活動二分鐘;回饋四分鐘。

(e)第四個練習-三人一組,隔開各自進行PMI討論,六分鐘後,兩組集合報告各自的結果並進行比較。

時間:活動六分鐘;回饋五分鐘。

(f)討論時段-全體一起討論以下議題:

PMI練習的價值。

.什麼時候做PMI練習最有用?

.做PMI練習的危險。

.剛開始時,PMI的形式會不會讓人覺得奇怪?

.剛開始時,嚴格、短暫、時限會不會讓人覺得困難?

.在PMI練習中「有趣面」部分所遇上的困難。

時間:十分鐘。

(g)第五個練習-全體會員一起討論。

「選舉投票時,每個人有兩票,其中一張是負面選票,用來抵銷你不喜歡候選人的票數、」

時間:六分鐘。

(h)練習項目-每個人寫下「練習項目」(包括嚴肅和有趣的議題),經過討論後,作為日後議題的儲備。

時間:活動三分鐘;回饋四分鐘。

(i)會議尾聲-提醒下次會議的注意事項,下次討論議題為APC技巧,會員要記得先閱讀本書相關內容。

時間:一分鐘。

(i)試辦會議二:

(a)議題-籌辦者設定議題焦點為APC技巧,提醒會員PMI的性質。

時間:二~三分鐘。

(b)第一個練習-全體針對「一天清晨有人看見一位婦女在花園裡掩埋三隻紅色短襪,每隻襪子都埋在不同的洞裡。對此可能有什麼不同的解釋?」單獨進行API練習。兩分鐘後全體集合,比較他們的解釋。

時間:活動二分鐘;回饋四分鐘。

(c)第二個練習-三人一組,針對「尋找各種方法以測量一個人二十四小時中所喝下的液體總量。」設想最多方法,時間到後比較兩組的記錄。

時間:活動三分鐘;回饋四分鐘。

(d)第三個練習-籌辦者輪流詢問「尋求各種節省需付費能源的方法,不管是在家庭裡或是整個大環境的。」會員想不出就跳過,當到連續三個會員都想不出跳過時,改採自由發言。

時間:最多八分鐘。

(e)第四個練習-三人一組,各自討論「有個父親發現他十八歲的兒子為了償債,私自開走家裡的汽車變賣。兒子說出買車的人,父親能採取哪些行動。」三分鐘後集合比較他們的方案。

時間:活動三分鐘;回饋四分鐘。

(f)討論時段-全體一起討論以下議題:

.我們什麼時候要尋找替代選項,什麼時候不用?

.不斷尋找替代選項的危險性在哪?

.為什麼有時候很難找到替代選項?

.所有的替代選項都應該列出來嗎?即使是那些很不可行的?

.替代選項的搜索範圍要有多廣?都在同個方向找,或在不同方向各找一個?

時間:十分鐘。

(g)第五個練習-每個人花兩分鐘思考「有什麼能發揮跟梯子、杯子、狗、鑰匙、窗戶相同的功能?」再全部一起討論,輪流要每個會員對每個項目提出一個替代物。

時間:活動二分鐘;回饋四分鐘。

(h)第六個練習-全部會員一起討論「因應街頭犯罪增加的各種可能方法。要注意的是,因應方法不代表就是尋求解決問題的辦法,還包括著手處理或仔細考慮問題的方法。」的各種因應方法,稍後並將這些因應方法分類。

時間:七分鐘。

(i)練習項目-每個人寫下「練習項目」(包括嚴肅和有趣的議題),經過討論後,作為日後議題的儲備。

時間:活動二分鐘;回饋二分鐘。

(j)會議尾聲-提醒下次聚會的時間和議題。

(9)必須避免事項

(a)缺少時間紀律,某項討論變得「有趣」後就放任其延長。

(b)練習某個思考技能的當下失去焦點,結果是泛泛的討論和空談。

(c)自我形態的爭論、想證明一個論點、證明自己是對的、證明對方是錯的。

(d)處理太多嚴肅或「沉重」的議題,陷入陳規的泥淖中和炫耀事實。

(e)看不出練習「有趣」項目這樣的簡單程序可累積出堅實的技能。

(f)野心太大、太急於將養成中的思考技能應用到「真實事件」或解決會員的個人問題上。這終將會成為思考俱樂部的目標,不過是在一段時間之後。

(g)籠統馬虎,覺得流程儀式不需斤斤計較。

(h)深陷議題之中,無法視為練習。

(i)不願思索涉及其中的「思考」,也不願只考慮議題。

(j)軟弱的籌辦者,或者試圖輪換職責、導致出現軟弱的籌辦者。

(k)缺乏幽默感。

(l)政治或宗教成見。

※以上這些事情,都可以藉由將注意力確實專注於焦點、流程和時間紀律上而避免,空談、自我和驕傲都是會議大敵、

感想

首先,終於把這本書唸過並做了相關的心得分享,實在得大舒一口氣(當然,也得謝謝各位看倌看了那麼久!),一時之間覺得自己有如釋重負之感,但也覺得自己是如此的不堪與脆弱。肥蝦常常逼迫自己要能比別人多想一點,也要求自己要有比別人多想一點的能力。這個想法正就落入Edward de Bono所說的負面思考的心態。自己也許稍具思考的能力,也自以為是能先思考再付諸感覺行動的人,但要將這知覺與思考變為自己的第二天性實在還有一大段的距離。

這本書所要闡述的重點不像溫伯格「問題真得是問題嗎-你想通了嗎?」所要求解決問題的程序(定義問題問題定義問題溝通問題共同化自我反省回應到目的);與齋藤嘉則的「發現問題的思考術」所提倡的發現構思分析過程也不太一樣;與岸良裕司依據TOC理論所寫解決問題的步驟!擬聚共識界定核心問題、化解衝突確認目標、防範可能風險建立中繼目標,確立執行順序。但是也都有一些關係。

本書對肥蝦來說是一本內省,修練內功的法門。首先,要讓自已有一個遇事、凡事都能先多想、多思考(比較性)的作法;不要囿於自己或他人的想法,就是不要有經濟上的【從眾行為】,也就是要有如去年修讀吳統雄老師課程所要求學生的「獨立人格,多元學習」的作為;但思考過程不是如吳老師說的(1)理論建構。(2)資料收集。(3)資料分析。(4)理論辨難。-這是學者研究問題的態度。

本書的作法是切合每人的生活與工作與日常處事的方法。第一步,要能先破除自己的【執見】(PMI),然後想想除了你預定的作法外,還有什麼方法(APC)。破除了【執見】之後再重新定下來思考(抽取歸類與分化分析覺察)重點就是要讓自己的處事模式增多(柏瑞圖八二法則-80%可以套用既有的模式;20%需要思考創造新模式),但要切記不可為模式所困(利用錯誤、意外、幽默;用踏腳石、隨機刺激法;用水平思考,用「PO)。思考的方式要(1)先收集所能夠搜集的資訊(CAFC&S;用射擊式或釣魚式問問題)(2)知道別人的思維與感受(用邏輯泡泡、用Exlectics思維、用EBD/ADI、用OPV、要明瞭變異價值、要能有效溝通)。思考作到知己知彼後能從價值承載言詞中辨別真正的價值,才用自身的價值觀真正判斷何為HV/LV。在這一連串的過程中還必須思索這思索過程,瞭解決策前後思考之不同,考量現實與推測未來,排定優先順序,再秉持著這感覺以毅力付諸行動。這種種的一切切切不可或忘你的目標與目的(利用AGO),知道風險與限制,明白相關資源,設定一個有彈性、思考面向廣的計畫。這種種的修為就是要讓知覺與思考成為個人的第二天性,成為一個「思考者」,可以專注思考,敏感性的思考;而達成這目標除了思考的標的外,也要注意思考的思考,可以斟酌使用TEC + PISCO的綜合方法。

最後一個感想:「肥蝦也想參加這種思考俱樂部!!!

2010年12月8日 星期三

軟體專案管理第十一週課程心得_Organizational Structure and Project


Organizational Structure and Project

第八組三位同學分別報告了【軟體專案管理】的第十章 專案組織與團隊運作與第十一章 軟體人力資源管理,雖然負責的範圍遠大於其他的分組,但是報告的書本與期刊內容卻是一樣完整與精彩。說實在的,肥蝦對於專案管理中的人力資源管理與溝通管理向來較為weakness,當然一方面因為自己對於人資管理較為缺乏興趣;另一方面也是肥蝦的主觀意識過於強烈,對於傾聽他人的發言與意見,會因為自我的主觀意見與認知,直接給予對方相當直接的反應,也是肥蝦一直被批評為太機車的原因之一。(另一個重要原因是肥蝦對於文件的要求較坊間的陋俗多一些!)

這一篇肥蝦主要是針對課堂上佳欣同學報告第十章中述及的專案組織架構以及授權的內容。以下將分成兩部份討論進行討論:第一部份 公司組織、專案組織、專案類型架構-就肥蝦已有的認知與想法,對三者與專案執行之間作一個簡要的說明與臆想;第二部份 專案組織、專案工作分派與專案授權-則延續第一部份的專案組織,進一步與第四章專案規劃的RCAI+圖形、第六章時程規劃中的專案組織與工作分派,對應到PMBOK9.1 中的team member roles and responsibilities,談到專案團隊內的授權

()第一部份 公司組織、專案組織、專案類型架構

在第十章中提及的專案組織結構的段落裏,將專案組織區別為:

(1)功能式組織

(2)矩陣式組織(依專案經理的職責區分)

(i)功能矩陣式

(ii)平衡矩陣式

(iii)專案矩陣式

(3)混合式組織

對於以上的定義,PMBOK 20082.4.2 Organizational Structure也有對應提到Functional OrganizationMatrix Organization(Weak, Balanced, String)Projectized OrganizationComposite Organization。但是,在【軟體專案管理】第十章所述及的,是為專案的組織架構; PMBOK所稱的組織架構卻是為Enterprise Environmental Factors中的要素之一,其會影響資源的取得與利用,以及專案的建構(Organizational structure is an enterprise environmental factor which can affect the availability of resources and influence how projects are conducted.)。所以在PMBOK 2008中說明的是Enterprise Organization,是描述公司的組織架構,並非本書中所說的Project OrganizationPMBOK是另外在9.1發展人力資源計畫提到Project Organization ChartProject中的Roles and responsibilities,這比較類同【軟體專案管理】第十章的課文內容。不管是PMBOK或【軟體專案管理】,兩書都未進一步說明企業組織型態(Enterprise Organization)與專案組織型態(Project Organization)間的相關性!

此外,佳欣同學所報告的"Risk Implications of Software Project Organization Structures"的文獻,該篇文章中將專案組織的類型─Project FormMatrix FormFunctional FormAdhocracy ─與專案類型-Pure Project Form (純專案型態)Hybrid Form(混合型態)Operational Activity(作業活動)Breakthrough Event(突發事件)進行交叉分析,就有限的資料進行實證研究,探討不同專案組織在面對不同類型專案下可能存在的風險因素。姑且不論該篇文章的實證結果,就肥蝦所體認該文作者的想法,伊應該是認為專案類型與專案組織架構型態之間也應該存在著相當的交互影響!

專案所屬公司的組織架構、專案組織架構與專案類型其間,三者是否會有一定的相關性與必然性?是否會進一步影響專案的結果?專案執行的結果轉變為Lesson Learned之後是否會進一步回饋予企業,作為企業組織架構調整的依據?一般人的直覺與觀感,我們會直論式的推斷功能性的企業組織結構,專案組織應該以功能性為主,專案經理所扮演的角色可能僅是一個聯絡者或促進者(expediter)的角色;專案性的企業組織結構,其專案組織就應該是專案性組織,專案相關的權責由專案經理掌控主導權。而對於突發性的臨時重要事件,公司也許會組成一個臨時編組;對於預定經營計劃中的專案型態,公司或許會組成相對應的專案組織。但三者之間的互動性,以及與專案執行的結果之間,是否就如直覺般的認知,三者之間是否存在有一定的相關性呢?肥蝦覺得這是一個非常有趣的議題!

就肥蝦有限的瞭解與閱讀,雖然有不少的著作探討專案組織型態對專案成敗或風險的影響;也有很多的報告研究企業環境要素對專案管理的影響。但是,截至目前為止,大腹便便卻腹笥甚窘的我還尚未閱讀過有人就公司組織架構、專案組織型態、專案的特質與屬性、專案的執行結果四者之間,探究其中的關聯性。

首先,肥蝦先行假設四者間的關聯性如【圖一】

進一步,應該則需要推定四者間兩兩之間的相關性,以及檢測其間的關係是否存在的假設!這當然只是肥蝦的臆測。但是試想,如果把當初第四組的彥宇誌源同學所舉出的課堂討論案例-【CIO的困境:誘騙加入 未必持久】(請參考:軟體專案管理第七週課程心得之一_Case study of the CIO's straits),把劇情往下延伸到:「馬修斯公司執行長在聽過科技長報告後,決定將自己的構想-提高衣櫃佔有率-變成一個公司層級的大型專案,組織一個專案團隊,直接隸屬於執行長辦公室。該團隊的專案經理由科技長擔任,專案團隊中包含郵購與網路部門營業部門、行銷部門、財務部門組成的專案功能小組,每個功能小組則由該部門中的第二把交椅擔任。」這後續將會有怎樣的情況產生?馬修斯公司內部員工與外部媒體是否會開始揣測科技長巴利高汀是否已被執行長設定為下任執行長的第一備位人選?各部門的副總們如何看待這一個專案團隊?是否會抵抗這專案團隊?針對科技長目前所遭遇到的資源壓力與各部門的壓力,是否可有效緩解?等等原有議題與可能引發的新議題,肥蝦想應該會有不同的思維與作法,對專案的成敗與效果也會有不一樣的結果。

其實看看你、我週遭的環境!很多公司一旦少主進入公司,就會給少主掛一個總經理特助,或者特定部門的主管,然後成立一個可以跨越各部門的專案團隊,執行公司一個中、短期的重大專案,這不就像是上述的案例嗎?回思"Risk Implications of Software Project Organization Structures"該篇文獻,作者所研究的實案中,一般以功能性架構為主的公部門,是否已經為了專案的類型與屬性進行了不同的安排?記得肥蝦參加2010年台北國際專案管理論壇時,大陸參加世博規劃作業的專案管理人員報告世博的專案,以及台北市公園處介紹花博的專案,兩者之間因為政府的組織架構差異即大,以及世博與花博的大小與展覽屬性有別,因此對應的專案組織架構型態與資源的取得與利用,兩者間有者極大的差距。

第二部份 專案組織、專案工作分派與專案授權

書本10.3討論授權乙節,主要在講述在不同的專案組織與專案生命週期間,對於專案經理的授權程度,以及專案經理與功能經理間的可能衝突。但是,肥蝦此處要進一步說明肥蝦關於專案團隊中授權類型的看法。

如同第一部份所述,公司的組織與專案的類型,當然會影響到專案的組織架構,專案組織型態也當然會影響到專案團隊內的授權與作業。此處,暫且假設公司組織與專案類型對專案團隊內授權與作業影響為一個已存在的要素,除此之外,一個團隊的專案經理還應考量那些要素,以進行對團隊成員進行授權與要求呢?

就如書本所說的:「管理者不可能獨自完成專案大大小小所有的事務,有些工作必須授權由他人來完成。」在專案經理肥蝦有限的時間與能力下,不可能自己完成專案的所有事務,也不可能親身參與各個活動,一定必須將專案工作進行適當的分派與授權。肥蝦以為專案經理應就專案的工作內容與屬性,專案的組織架構、專案工作項目的優先性與重要性、專案成員的人格特質與專案工作的分派等因素,進一步進行專案團隊內部的授權。因此,肥蝦依憑自我的主觀認知,整合至目前為止同學們的報告資料,繪成【圖二】


一個良好的RAM圖示,不但可讓專案團隊彼此清楚瞭解專案工作職權的分派與責任、權力,有效的凝聚專案成員對專案的向心力,更可讓專案經理著重於專案的管理性工作,瞭解、界定與解決專案的問題,在達成專案的目標的過程中RAM將可有效的發揮它的助益。

2010年11月29日 星期一

軟體專案管理第十週課程心得_QP, QA, QC and SV&V


QP, QA, QC and SV&V

品質規劃(Quality Planning)品質保證(Quality Assurance)與品質控制(Quality Control)在台灣的工作環境中,除非有一定規模或一定制度的公司,遵循一定的品質作業規則,不然很難體會軟體專案中品質管理的程序與作業。最最簡單的一個問句:「您們工作團隊,是否有程式撰寫作業準則或者變數編碼規則?」這也是國珍與東豪同學對於軟體專案品質管理的疑問?我們是否真正的重視與落實品質管理?還是它只是一個空頭的名詞,以讓公司可向客戶多爭取點專案的經費?


【軟體專案管理】書本上將軟體品質定義為:軟體產品整體的功能和特性滿足既定需求的能力。更白話一點的說,就像日本的Mint(經營情報研究會)所著,周明憲所譯的【軟體工程實務】所寫的:「(1)正確的運作。(2)不會當機。(3)容易使用。(4)回應快速。(5)易於維護。(6)易於移轉。」這些要求可概括的區分為功能性與非功能性的要求;就過程而言,就如DeutachWillis(1988)所分別的程序品質(Process Quality)與產品品質(Product Quality)


目前,對於專案一般認知的”triple constraint” - scope, schedule, cost,目前很多的討論與研究中已經把”quality””performance”抽離出來成為第四個constraint。就肥蝦的觀點,原本的專案管理三角形(Project Management Triangle),可以畫成【圖一】


那何為QualityPerformance?」因為品質不能空口說白話,品質需要有一定的定義與Metric可以供測量。記得九十三年六月至十二月被賣到資策會資訊工程所作「電子化政府共通作業平台規劃專案」,每一篇徵求建議書(RFP)都會提到作業需求、功能需求、界面需求、環境需求(內含非功能需求)。這些需求有時會定義出下限,如非功能需求中列示了:「可利用率達99.95%,一般作業時間:2秒,尖峰作業時間: 3秒線上,同時維持200使用者之滿載,負荷10分鐘以上。」這些要求,不管是對於uservendor說,都是要達到的水準。為了達到此要求,vendor必須於建議書中定義出一些方法、規範、公式、標準、容忍誤差,以及必要的作業方法與管理流程。整體系統的架構規劃與設計,當然就需要以這些要求為Base,這也是肥蝦會把Quality畫在下方直線的原因。因為品質水準是要花錢的,就是PMBOK中所說的”Cost of Quality”


品質的規劃與管控學說與理論相對於其它的專案管理知識領域,算是相對的成熟與穩定,PMBOK 2008年的改版相較於2004年版是修正不多,下表為PMBOK 2008對於Quality規劃、保證與控制的ITTO

8.1Plan Quality

The process of identifying quality requirements and/or standards for the project and product, and documenting how the project will demonstrate compliance.

8.1.1.1Scope Baseline

8.1.2.1Cost-Benefit Analysis

8.1.3.1Quality Management Plan

8.1.1.2Stakeholder Register

8.1.2.2Cost of Quality(COQ)

8.1.3.2Quality Metrics

8.1.1.3Cost Performance Baseline

8.1.2.3Control Charts

8.1.3.3Quality Checklists

8.1.1.4Schedule Baseline

8.1.2.4Benchmarking

8.1.3.4Process Improvement Plan

8.1.1.5Risk Register

8.1.2.5Design of Experiments

8.1.3.5Project Document Updates

8.1.1.6Enterprise Environmental Factors

8.1.2.6Statistical Sampling

 

8.1.1.7Organizational Process Assets

8.1.2.7Flowcharting

 

 

8.1.2.8Proprietary Quality Management Methodologies

 

 

8.1.2.9Additional Quality Planning Tools

 

8.2Perform Quality Assurance

The process of auditing the quality requirements and the results from quality control measurements to ensure appropriate quality standards and operational definitions are used.

8.2.1.1Project Management Plan
-Quality Management Plan
-Quality Improvement Plan

8.2.2.1Plan Quality and Perform Quality Control Tools and Techniques

8.2.3.1Organizational Process Assets Updates

8.2.1.2Quality Metrics

8.2.2.2Quality Audits

8.2.3.2Change Requests

8.2.1.3Work Performance Information

8.2.2.3Process Analysis

8.2.3.3Project Management Plan Updates

8.2.1.4Quality Control Measurements

8.2.3.4Project Document Updates

8.3Perform Quality Control

The process of monitoring and recording results of executing the quality activities to access performance and recommend necessary changes.

8.3.1.1Project Management Plan

8.3.2.1Cause And Effect Diagram

8.3.3.1Quality Control Measurements

8.3.1.2Quality Metrics

8.3.2.2Control Charts

8.3.3.2Validated Changes

8.3.1.3Quality Checklists

8.3.2.3Flowcharting

8.3.3.3Validated Deliverables

8.3.1.4Work Performance Measurements

8.3.2.4Histrogram

8.3.3.4Organizational Process Assets Updates

8.3.1.5Approved Change Requests

8.3.2.5Pareto Chart

8.3.3.5Change Requests

8.3.1.6Deliverables

8.3.2.6Run Chart

8.3.3.6Project Management Plan Updates

8.3.1.7Organizational Process Assets

8.3.2.7Scatter Diagram

8.3.3.7Project Document Updates

 

8.3.2.8Statistical Sampling

 

 

8.3.2.9Inspection

 

 

8.3.2.10Approved Change Requests Review

 

從上表可知,QP重點為產出MetricChecklist,以為後續QAQC所遵從的基準。


品質保證與品質控制,對於不熟悉品質管理的人來說,有時還真讓人搞不清楚!根據ISO 9000的定義:品質保證(Quality Assurance)為「All those planned and systematic activities implemented to provide adequate confidence that an entity will fulfill requirements for quality.」;品質控制(Quality Control)為「The operational techniques and activities that are used to fulfill requirements for quality.」我肥蝦是如此加以區別:「品質保證重點為在實作的過程採行正確的方法(do the right thing),品質控制為檢測結果的正確性(do the thing right)。」針對ISO 9000對於QAQC的差別,可以整理如下表:

品質保證(Quality Assurance)

品質控制(Quality Control)

強調重點

(1)Process

(2)Proactive

(3)Staff function

(4)Prevent defects

(1)Product

(2)Reactive

(3)Line function

(4)Find defects

採用方法

(1)Quality Audit

(2)Defining Process

(3)Selection of tools

(4)Training

(1)Walkthrough

(2)Testing

(3)Inspection

(4)Checkpoint review


目前學理一再強調的預防重於治療的觀點下,當然品質保證的重要性優於品質控制,就如那書中強調的:「軟體品質保證人員是推動品質管理的核心角色。」但說句實話,在臺灣現有的軟體開發環境下,能作好品質控制就不容易了,那有多餘的經費與時程去作QA


記得上週去一家算是國際品牌本土化的銀行核心軟體系統商開會,會中一個資深的系統開發副總說:「客戶都質疑建議書上寫的專案組織架構人手不夠,在臺灣那家公司不是拿到案子,有錢就有人。」像這種逐案而居的心態,如何有效的提升人力平均水平,落實嚴謹的程式開發準則?因此,專案經理或者公司,不得不儘量作好品質控制,品質保證,唉!想想就好。

就算是品質控制,一些理論書籍中也強調要有一定的程序與測試類別,如【圖二】的測試步驟與測試階段。


有那幾家公司會在系統分析與設計之時就作好測試案例?有誰真得去找品質測試人員來作黑箱測試?能叫系統開發人員(系統分析師與程式設計師)作作照劇本演練的單元測試就算不錯了!那來作什白箱、黑箱、灰箱的測試呢?又有誰會真得會逐步進行單元、整合、系統與平行測試?這些都是要錢、要時間的。

測試階段與所謂的確認與驗證要如何對應呢?也許有人會像我一樣在接觸確認(Verification)與驗證(Validation)之時把QAQC搞得一團模糊!直到公司的順淵兄上了外面的訓練課程-「軟體品質專案管理」,不吝跟肥蝦分享了他在課堂上的收穫,其中就有測試階段與確認與驗證的對應關係,肥蝦整理成下表:

項目

定義

測試階段

確認(Verification)

確保軟體的發展過程中,每一階段符合前一階段之結果(Do the things right)

單元測試、整合測試

驗證 (Validation)

確保最終產品功能及特性符合其相關規格及需求所要求之水準(Do the right things)

系統測試、驗收測試


這基夲上是先驗證再驗認,因此所謂的測試階段,都是針對結果,而不是對實作的過程作檢測。因此我把這些測試都歸類於PMBOK 8.3Perform Quality Control 中的Inspection,僅是因為對於層級、範圍與滿足標的不同,作了不同的區別,單元測試、整合測試針對的滿足標的是系統分析與設計後的規範;系統測試、驗收測試的滿足標的是系統分析與設計的來源-使用者需求。


如此一來,肥蝦便可將軟體工程的確認(Verification)與驗證(Validation)融入PMBOKQAQC,以及5.4Verify Scope。就不會像當初肥蝦於參加PMBOK的認證課程中被授課老師混淆了品管與專管,攪得一團亂。QA是過程,產出的delivery要經QC因為軟體的QC要作確認(Verification)與驗證(Validation)所以產生了Validated Deliverables ,確認符合了使用者的需求,再經過5.4Verify Scope中客戶的劃押,就是Accepted Deliverables了。以上當然是肥蝦的見解與看法,因此以下的理解也是依此而發,若認為肥蝦對此認知有誤,當然以下就不需要瀏覽了!也許那一天,肥蝦也會再次發現現有的認知有誤呢!


肥蝦整理了一下手頭上有的一些資料,先前順淵兄分享的「軟體確認與驗證(Software Verification and Validation)」簡報資料,以及經濟部工業局所頒布的九十六年度提升資訊軟體品質計畫,環境建立分項中的「流程改善量化績效度量指標操作型定義」。


其實要將QC分為確認(Verification)與驗證(Validation),是要作到『早期發現、早期治療』。但說實話要靠這些測試階段作到如此的期望,那就只能設法將軟體專案的開發設定了一些milestones,定義每個milestones所要交付的delivery。這其中最常用的就是依據軟體生命週期來定義milestones ,而最常聽人說及的就是V Model。【圖三】就是V Model的示意圖:


其中左邊為開發階段的活動,右邊為對應的測試階段。開發階段由上到下,測試階段由下到上,因此為了真要作到『早期發現、早期治療』,就需要在開發階段之時作好QA的工作。就像炯佑同學在第八週所舉例的X通公司所承作的國O部的專案,在整合測試或系統測試,才發現一些功能性或非功能性需求達不到客戶明載於合約或徵求建議書的要求時,那可真得來不及了!


對於QCQA所可依據的MetricChecklist,經濟部工業局九十六年度所頒布的「流程改善量化績效度量指標操作型定義」可以參考。該文件提出了六個構面22個量測指標,肥蝦整理呈於下表中:

構面

量測指標

成本

工時預估誤差率(Effort Estimate Error Rate, EEE)

軟體規模單位工時(Software Scale Unit Effort, SSUE)

軟體缺失檢測單位工時(Defect Find Effort, DFdE)

軟體缺失修復單位工時(Defect Fix Effort, DFxE)

需求變動單位工時(Requirement Change Unit Cost, RCUC)

時程

時程預估誤差率(Schedule Estimate Error Rate, SEE)

準時結案率(On-Time Delivery Rate, OTDR)

軟體專案規模單位時間(Software Scale Unit Time, SSUT)

里程碑達成率(Milestone Achievement Rate, MAR)

品質

缺失密度(Defect Density, DD)

缺失移除率(Defect Removal Rate, DRR)

需求穩定性(Requirement Stability, RS)

軟體交付後之瑕疵率(Software Failure Rate, SFR)

功能完成率(Function Completion Rate, FCR)

客戶滿意度

客戶滿意程度(Customer Satisfy Level, CSL)

客訴次數(Count of Customer Complain, CCC)

客戶回流率(Customer Turnover Rate, CTR)

投資報酬率

得標率(Successful Bid Rate, SBR)

獲利率(Return On Investment, ROI)

員工

離職率(Turnover Rate, TR)

教育訓練支出比率(Education & Training Expense Rate, ETER)

員工生產力(Employee Productivity, EP)


當然以上的構面或者指標是否足夠,當然是見人見智,但肥蝦是以為政府能有此用心,也算是不錯了。現在當紅的度量指標,當然非EVM(Earned Value Management)莫屬了,這已經在課程的第八週由第五組的同學簡報過了。但以肥蝦認知,種種的指標都是呈現出一種結果,重要的是背後的理論、假設與限制,專案經理與公司千萬不能沉迷於數字,一心喊說數字管理,卻忘了數字的意義與範圍、限制。更更重要的還是公司能否把專案管理融入組織與文化之中!不然指標也可以做假的。