2019年4月29日 星期一

2019 04 29 左永安顧問 精準訓練 職能基準 職能導向課程 左記歐洲商行 安永經營管理顧問集團 台北左府(無極)鳳清道德宮司 台大 台師大 EMBA 共通核心職能 專案管理 TTQS ICAP PMP WINEAgile Practice Guide 作者: Project Management Institute (COR) 原文出版社:Project Management Inst 出版日期:2017/10/01 語言:英文 定價:1715元Agile Practice Guide – First Edition has been developed as a resource to understand, evaluate, and use agile and hybrid agile approaches. This practice guide provides guidance on when, where, and how to apply agile approaches and provides practical tools for practitioners and organizations wanting to increase agility. This practice guide is aligned with other PMI standards, including A Guide to t he Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition, and was developed as the result of collaboration between the Project Management Institute and the Agile Alliance.



Agile Practice Guide

  • 作者: Project Management Institute (COR)
  • 原文出版社:Project Management Inst
  • 出版日期:2017/10/01
  • 語言:英文
  • 定價:1715
Agile Practice Guide – First Edition has been developed as a resource to 

understand, evaluate, and use agile and hybrid agile approaches. 

This practice guide provides guidance on when, where, and how to apply 

agile approaches and provides practical tools for practitioners and organizations 

wanting to increase agility. 

This practice guide is aligned with other PMI standards, including A Guide to t
he Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition, 

and was developed as the result of collaboration between the
 Project Management Institute and the Agile Alliance.

2019 04 29 左永安顧問 台師大 台大 EMBA 執行專案前的核心任務,商業分析提高專案成功率 1專案常常做到結案才發現不符合公司需要, 2專案發生問題的解決方案,好像常常只解決企業部分問題,但還是有其他問題無法 有效解決, 3.專案執行到最後才知道無法為公司帶來任何效益, 這是不是您執行專案常常遇到的問題呢? 根據國際專案管理學會 (Project Management Institute, PMI) 研究顯示, 企業組織一直面臨和需求活動執行不佳有關的專案議題—這是商業分析實務的 核心任務,也是導致專案失敗的主要因素。 本會出版的《商業分析實務指南》提供實務價值的方法與對策,處理在 商業分析領域中的專案相關議題,並且解決產業界在商業分析領域所迫切需要 的引導指南。 不論職稱或是產業別,本指南將能提供商業分析與需求相關工作的實務引導, 以使專案集或專案更為成功。



執行專案前的核心任務,商業分析提高專案成功率

1專案常常做到結案才發現不符合公司需要,
2專案發生問題的解決方案,好像常常只解決企業部分問題,但還是有其他問題無法
  有效解決,
3.專案執行到最後才知道無法為公司帶來任何效益,
這是不是您執行專案常常遇到的問題呢?
根據國際專案管理學會 (Project Management Institute, PMI) 研究顯示,
企業組織一直面臨和需求活動執行不佳有關的專案議題—這是商業分析實務的
核心任務,也是導致專案失敗的主要因素。
本會出版的《商業分析實務指南》提供實務價值的方法與對策,處理在
商業分析領域中的專案相關議題,並且解決產業界在商業分析領域所迫切需要
的引導指南。
不論職稱或是產業別,本指南將能提供商業分析與需求相關工作的實務引導,
以使專案集或專案更為成功。

2019年4月28日 星期日

2019 04 29. 左永安顧問 台大 台師大 EMBA PMP考試讀書計畫 專案管理知識體指南 PMBOK Guide 第六版 繁體中文版+敏捷實務指南Agile Practice Guide繁體中文版 [套書](2本) 2.商業分析實務指南 第一版 繁體中文版Business Analysis for Practitioners: A Practice Guide(1本) 3.計劃管理標準Program Management第三版 繁體中文版(1本) 4.專案組合管理標準Portfolio Management第三版 繁體中文版(1本)

2019 04 29. 左永安顧問 台大 台師大 EMBA PMP考試讀書計畫 專案管理知識體指南 PMBOK Guide 第六版 繁體中文版+敏捷實務指南Agile Practice Guide繁體中文版 [套書](2本) 2.商業分析實務指南 第一版 繁體中文版Business Analysis for Practitioners: A Practice Guide(1本) 3.計劃管理標準Program Management第三版 繁體中文版(1本) 4.專案組合管理標準Portfolio Management第三版 繁體中文版(1本)


2019 04 29. 左永安顧問 台大 台師大 EMBA PMP考試讀書計畫 專案管理知識體指南 PMBOK Guide 第六版 繁體中文版+敏捷實務指南Agile Practice Guide繁體中文版 [套書](2本) 2.商業分析實務指南 第一版 繁體中文版Business Analysis for Practitioners: A Practice Guide(1本) 3.計劃管理標準Program Management第三版 繁體中文版(1本) 4.專案組合管理標準Portfolio Management第三版 繁體中文版(1本)


  PMP考試讀書計畫 

 1.專案管理知識體指南 PMBOK Guide 第六版 繁體中文版

    +敏捷實務指南Agile Practice Guide繁體中文版  [套書](2)
     
2.商業分析實務指南 第一版 繁體中文版Business Analysis for Practitioners: A Practice Guide(1)
    
 3.計劃管理標準Program Management第三版 繁體中文版(1)
   
 4.專案組合管理標準Portfolio Management第三版 繁體中文版(1)







2019年4月22日 星期一

2019 04 22 左永安顧問 個案討論 領導者風格華頓商學院教授班納與哈佛商學院教授塔希曼 企業管理的最高殿堂非奇異(GE)莫屬。神殿的祭師是前奇異執行長傑克.威爾許(Jack Walch)威爾許嫡傳弟子是詹姆斯.麥克納尼(James McNerney) 他在奇異角逐威爾許接班人失利後即獲明尼蘇達礦業公司(3M)禮聘為公司執行長。3M董事會視麥克納尼為珍寶,在二○○○年十二月五日宣布麥克納尼出任公司執行長的消息後,幾天內3M股價大漲將近兩成。曾與3M在發明計畫上有合作經驗的MIT史隆管理學院教授希波(Eric von Hippel)達特茅斯大學塔克商學院管理教授葛文達拉彥 這套管理方法源自一九八六年的摩托羅拉公司,後經奇異採用,成為九○年代企業圈的管理熱潮。DMAIC分別代表定義、量測、分析、改善與控制等五個步驟英文字字母的縮寫,這五大步驟是六標準差解決問題的要素。

2007-06-07 林晨

3M曾擁有連Google都自嘆弗如的創新文化,但在導入六個標準差之後,卻發現效率與創新之間,存在著不可避免的衝突。
不過幾年前,企業管理的最高殿堂非奇異(GE)莫屬。神殿的祭師是前奇異執行長傑克.威爾許(Jack Walch),其門生將其口諭傳達給世上管理界的所有信徒,其中最受外界關注的一名威爾許嫡傳弟子是詹姆斯.麥克納尼(James McNerney)

他在奇異角逐威爾許接班人失利後即獲明尼蘇達礦業公司(3M)禮聘為公司執行長。3M董事會視麥克納尼為珍寶,在二○○○年十二月五日宣布麥克納尼出任公司執行長的消息後,幾天內3M股價大漲將近兩成。


管理聖經  令發明機器褪色

麥克納尼是這家百年老店首位外來的空降執行長,甚至還未踏入新東家一步,他就宣布說要對3M進行大改造,採用的正是純正的奇異兵法。

麥克納尼裁掉八千名員工(約占總人力的一一%),強化績效考核的過程,並使這家以出手闊綽為名的企業大幅縮減開支。他同時引進奇異自豪的六個標準差(Six Sigma)計畫││旨在減少生產缺失與提升效率的一系列管理手段,數以千計的職員都經培訓成為「黑帶級」的頂尖人才。

該計畫似乎也發揮功效,麥克納尼讓牛皮的3M股價回復生機,並且為一個龐大懶散且管理無章法的組織導入了紀律,而獲得外界的稱許。

就在掌舵四年半後,麥克納尼跳槽至波音公司接掌營運兵符。而今,接替他在3M公司位置的繼任者面臨一項難題:過度強調效率是否已讓3M成為一家不具創新能力的公司?對於一家當初以創新起家的公司來說,這個問題非同小可,畢竟3M是催生皺紋紙膠帶、保溫棉與便利貼等產品的發明公司。

自從推出接合LCD面板的多層光學薄膜產品之後,3M已好久沒有研發出可改變賽局的新技術。以往3M總是吹噓公司營收至少有三分之一來自最近五年的新產品,如今新產品對營收的貢獻比重下滑至四分之一。

這樣的結果絕非偶然。六標準差這種效率計畫用意就在找出生產流程的問題,然後用精準的方法減少變因與去除缺失但當這類的計畫被植入於像3M這樣公司的文化中,創意很容易遭到抹殺,再怎麼說,突破的創新都會挑戰既有的常規。

「發明的本質就是一種毫無定律可言的過程,」3M現任執行長巴克利(George Buckley)說,他已取消麥克納尼任內所實施的許多計畫

「你不可能在該領域實施六個標準差,好比說,嗯,我現在發明的進度落後,所以周三要想出三個好點子,周五再想出兩個,創意不是這樣子運作的。」麥克納尼則拒絕回應此篇報導。

傳統來說,六個標準差採用精準的統計分析所產生的資料,協助改善品質、降低成本與提升效率。

曾與3M在發明計畫上有合作經驗的MIT史隆管理學院教授希波(Eric von Hippel)表示,這一套標準應用在發明上的問題相當大。

他還說當六標準差引進後,3M的發明計畫都受到衝擊。

達特茅斯大學塔克商學院管理教授葛文達拉彥

也附和說:「當一家公司導入全面品質管控的程度愈深,對突破性創新的傷害會更大,其所需的心態、能力、方法,以及創新所需的文化是根本不一樣的。」


學者不認同  投資人捧場

華爾街在乎的又是另外一回事。投資人喜歡麥克納尼提振獲利的方法,儘管這可能犧牲了創意。麥克納尼任內公司獲利平均一年成長二二%,在巴克利主政的第一年,營收來到二三○億美元,獲利達一四億美元,但後來有兩季獲利低於市場預期,股價因而震盪走低。

○七年巴克利似乎成功地杜華爾街悠悠之口,讓他們相信在不破壞麥克納尼的生產力增長前提下,他能夠重新點燃營運成長的火花,自年初迄今,3M股價上漲一二%。

3M的傳統之一,是員工可以利用公司某些資源來從事自己的寶貝計畫(pet project),公司政策允許員工利用一五%的上班時間研究私人計畫,同時公開鼓勵員工進行冒險,也容忍員工研究失敗。

3M當初鼓勵創新的企業文化,就連現今各界高度推崇的Google都相形見絀。

可能也是因為這樣,

3M高度自豪的員工才會難以面對公司九○年代末期營運表現不佳的事實。當時獲利與營收成長極為不穩定,一九九八年亞洲金融危機期間,3M的亞洲營運狀況一塌糊塗,九○年代末期全球股市走了一波大多頭,3M股價卻在原地踏步。富彈性與開明的企業組織,是當初讓3M營運得以發光發亮的主因,但也因此產生人力膨脹、勞動力不具效率的問題,才會給予麥克納尼由外空降進行撥亂反正的充分理由。

麥氏採用的主要手段就是六個標準差,這套管理方法源自一九八六年的摩托羅拉公司,後經奇異採用,成為九○年代企業圈的管理熱潮。

由於受到廣泛採納與應用,如今很難明確指出其所真正代表的意義。

在有些公司,六個標準差只是撙節成本的代名詞,其他公司則將它形容為分析問題的工具,但依據基本的定義,六個標準差的目標是去除流程中的不確定性,以此來避免出錯與缺失,進而增加可預測性

(技術層次而言,六標準差的品質必須達到每一百萬個產品最多只能容許三.四個瑕疵)。

麥克納尼在3M時引進兩項六個標準差工具。

第一個是比較傳統版本的方法DMAIC,

DMAIC分別代表定義、量測、分析、改善與控制等五個步驟英文字字母的縮寫,這五大步驟是六標準差解決問題的要素。

另一個方法是

六個標準差設計(DFSS),用意是將新產品開發流程系統化,以便於產品在一開始就符合六標準差的品質要求。

數千名3M員工接受未來出任企業內部顧問的「黑帶」專家培訓,幾乎所有人都得參加為期數天的「綠帶」訓練課程,

課程主要是說明DMAIC與DFSS,讓員工熟悉統計數字,並教他們如何使用Minitab電腦程式來追蹤數據與做圖表。

黑帶級的專家再各自領導規模更大的「黑帶計畫」,像是去除生產的不確定性因素與不必要的步驟,以使生產速度加快四○%。這些黑帶專家同時還督導規模小一點的「綠帶計畫」,

好比說訂單履約流程的改善。導入六個標準差無疑是麥克納尼讓3M獲利出現驚人成長的主因,3M的營益率從○一年的一七%增至○五年的二三%。


省時省錢  衝撞創新本質

雖說六個標準差設計的原意是要改善品質,但如今在業界看來,其最大的價值反而在於節省時間與金錢。

麥氏剛上任時3M一直被批評為只會花大錢來解決問題,但他上任後第一個完整年度,3M的資本支出隨即從九.八億美元,砍到七.六三億美元,減幅達二二%,隔年再砍一一%至六.七七億美元,資本支出的營收占比從○一年的六.一%,下滑至○三年的僅僅三.七%。

3M的研究人員過去都被給予相當大的空間從事自己喜歡的研究計畫,但在來了新老闆(麥克納尼)後,DMAIC為創新建構一個階段評估的流程,這在3M是一項創舉,其目的是要加速發明至新產品流程的進度,同時讓其系統化。

長久以來,

3M都讓研究人員花上幾年的時間進行產品的測試。舉便利貼來說,它的發明人是一名叫阿特.富萊(Art Fry)現已退休的科學家,富萊與其他同事花了好些年構思,最後才在一九八○年化為實際的產品。

在3M效力二十七年並於○四年去職的穆希(Michael Mucci)宣稱:「在推動六個標準差計畫初期,公司向技術性員工舉辦一場新流程的說明會後,我們大家都認為當初要是採用此套系統,便利貼就不可能問世。」

六個標準差與創新之間存在著不可避免的衝突,相關的正式研究一直以來十分有限,但最有名的一次嘗試是由華頓商學院教授班納與哈佛商學院教授塔希曼兩人聯手完成,

他們發現六個標準差是會導致新發明數量變多,但也會犧牲許多毫無範圍限制的發明。

3M公司內六個標準差的支持派則辯稱,更有系統的新產品引進流程,可以加快從創新到產品上市的時間。

然而,便利貼的發明家富萊卻不贊同,他甚至還將3M近期缺乏創新動能的矛頭,直接指向應用在3M實驗室的六個標準差。

創新,他說,其實是一項數字遊戲,「你必須從五千到六千個原始的創意中找到一個有用的商機,六個標準差必然會問,何以不去除一些沒用的想法,在一開始就先想出正確的創意?

這樣的思惟方式會有嚴重的副作用,其最大的成就即是迅速破壞一項企業文化,還好3M沒被(麥克納尼)完全摧毀,因為他在位的時間不夠長,若是他再待久一些,我想文化肯定葬送在他手上。」


重振傳統  六個標準差淡出

擁有化學工程博士學位的巴克利,似乎在這家命運及歷史均與發明新事物綁在一起的組織,為強調流程的管理計畫找到一個合適的定位。

「你在綁手綁腳與千篇一律的環境中是無法有新發明,」巴克利說。「以一家企業來說,我們或許所犯的錯誤就是重視一致性更甚創造力,我想這可能已損及像3M這樣一家公司的核心與文化,而這正是六標準差的風險之一。」

近幾年來,該公司的發明威名不斷下滑,○四年在波士頓顧問集團的最具創新企業評比中還名列榜首,○五年退步至第二,去年掉至第三,今年更滑落至第七。

於是,巴克利稍微放寬相關規定,讓3M做研究的科學家免於遵守六個標準差的規範。

為了讓創意之泉源源不絕的流出,巴克利也再次打開企業支出的水龍頭:大幅增加研發、購併與資本支出方面的支出。

今年整體研發預算將增加兩成至十五億美元,更重要的是,巴克利重新調整支出的配置,大多數的資金都投入在他稱為是3M「核心」技術,共四十五個領域,包括研磨、奈米科技與軟性電子等等。這也與麥克納尼的作法大相逕庭

麥氏○四年曾向《商業周刊》表示,3M最具潛力的產品是製藥部門的主力支柱樂得美(Aldara)護膚乳膏。今年一月,巴克利卻以二十億美元出售製藥部門。

3M如今正悄然地推翻麥氏主政時所施行的政策。這位前執行長肯定是為公司引進一些正面的改變,然而許多員工表示,他們現在士氣大振,因為公司的營運重心已從獲利和流程紀律轉回至成長和創新。

策略商業發展部主管海曼德指出:「巴克利為公司帶來發明的火花。」3M無線射頻識別部門事務主管安德森也附和說:「我們覺得又可以漫無邊際的作夢了。」(By Brian Hindo)


收與放的拿捏    麥克納尼與巴克利兩人管理風格與策略的比較
       
麥克納尼(前任)

就任時的聲望:
知名奇異(GE)經理人,在取代威爾許接任奇異執行長的爭奪戰中輸給伊梅特。
主要任務:
提升獲利。3M財報表現愈來愈緩滯,投資人大感失望。
對六個標準差的態度:
對3M進行企業文化改造,推動在企業史上一次最具爭議性的六個標準差計畫。
資本支出:
限制揮霍無度的支出,增加現金流量,並且提升營益率。
研究優先順序:
不增加研發支出,預算以投入諸如製藥等具潛力的新市場為主。
企業文化:
導入奇異風格的管理能力。

巴克利(後任)

就任時的聲望:
幾無。在艾默生電氣公司吸取管理經驗,成功再造製船廠Brunswick。
主要任務:
一方面重現3M著名的創造力,另一方面也保持麥克納尼任內達成的營運效率。
對六個標準差的態度: 
調整六個標準差的相關規定,特別是實驗室免於適用,但在製造部門繼續施行。
資本支出:
憂心投資不足,斥資15億美元籌蓋18座新廠與其他擴張計畫
研究優先順序:
增加研發預算。重心放回「核心」研究,淡出像是製藥等次要業務。
企業文化:

藉由鼓勵冒險重新啟動創新機器。

2019年4月18日 星期四

2019 04 18 左永安顧問 工業4.0 哈佛個案 精準訓練 職能基準 職能導向課程 左記歐洲商行 安永經營管理顧問集團 台北左府(無極)鳳清道德宮司 台大 台師大 EMBA 共通核心職能 專案管理 TTQS ICAP PMP WINE Agile Alliance 2001年時支持敏捷式開發的社群組成了Agile Alliance,並且發表了Agile宣言與原則。 The Agile Manifesto (敏捷宣言) 獨立的工作成員與人員互動 勝於 流程與工具的管理 工作產生的軟體 勝於 廣泛而全面的文件 客戶的合作 勝於 契約的談判 回應變動 勝於 遵循計畫 The Agile Principles (敏捷原則) 最為優先的事情是透過早期與持續交付有價值的軟體來使客戶滿意。 歡迎需求的變動,即使是在開發的晚期。敏捷式流程駕馭變動來作為客戶的競爭優勢。 頻繁的交付工作產生的軟體,自數週至數月,週期越短越好。 領域專家與開發成員必須一同作業,並貫穿整個專案開發時期。 使用積極的工作成員來建構專案,給予他們環境以及支援所需的一切,然後信任他們能夠完成工作。 在開發團隊中最快也最有效的傳遞資訊方法就是面對面的溝通。 工作產生的軟體是衡量進度最主要的依據。 敏捷式流程倡導水平一致的軟體開發 專案發起者,開發人員以及使用者都必須持續的維持專案進度。 持續重視技術的優勢以及設計品質 最好的架構、需求以及設計會出現在能夠自我管理的團隊裡 在規律的反覆之間,團隊會反省與思考如何更有效率,然後相對的來調整與修正團隊的開發方式。Product Lifecycle Management and Project Lifecycle Management


2015-01-08 15:30呂中力


你真的搞懂了什麼叫敏捷式 ( Agile ) 開發嗎?
敏捷式開發(Agile Development)是近來時常耳聞的一個名詞,
我們或多或少對於這個名詞有些微的概念,但是卻又很難具體的
描述出一個全面性的觀點來。
敏捷式的精神
原則上敏捷式開發主要的精神在於較短的開發循環(建立在反覆式開發方式上)
以及漸進式開發與交付。
換句話來說,
專案的成果,包含計畫、各類的需求細節、
設計等都會隨著專案的進行而漸漸完整,而非在一開始將所有的計畫與需求擬定完成。
 在Craig Larman的Applying UML and Patterns第三版
(該書的第二版著重在UP開發流程的說明,
在第三版中才加進了敏捷式開發的精神)中花了不少篇幅在闡述敏捷式開發的一些定義。
敏捷式開發並非一種制式的開發方法,而是一種軟體開發的精神(spirit),
任何開發方法都可以加入敏捷式開發的一些原則進而改善軟體開發的成效。
在敏捷式開發中有個很重要的觀點是筆者很感興趣的,它認為塑模(Modeling)
的目的在於增加開發者了解軟體的程度,進而使得軟體更接近於使用者的需求,
而非使用塑模之後產生的文件。
The purpose of modeling (Sketching UML,…) is primarily to understand,not to document.[Apply UML and Patterns,3/e]
換句話說,它希望開發者使用塑模的時機,是當使用這個技術有助於開發者
更了解被開發的軟體時才使用,例如某些具關鍵性的議題或者高風險性的項目,
而非不管三七二十一的將軟體所有範圍的設計都加以塑模留下文件。
草稿與藍圖
有趣的是,如果我們延伸這個觀點,塑模在敏捷式開發的精神下是一種類似草圖
或者草稿的作用。也就是說,用以在團隊開發時討論以及研究議題的一種工具,
在過程中利用塑模的技術來讓問題得到解決,一開始的動機並非為了留下設計圖
讓程式設計師去實作。
同樣的觀點在Martin FowlerUML Distilled Third Edition中也有所著墨,
Martin認為,UML作為一項工具,可以有三種被使用的方式,
一種是草圖,一種是所謂的藍圖,最後一種則是程式語言。
Martin本身則是將作為一種草圖的工具來使用,當然也有人將其作為藍圖來使用。
而將UML作為藍圖來使用到一種極至時將出現UML本身就可視為一種程式語言,
例如所謂的模型驅動(MDA)開發。當然這並不在本文的討論範圍內。
Agile Alliance
2001年時支持敏捷式開發的社群組成了Agile Alliance,並且發表了Agile宣言與原則。
The Agile Manifesto (敏捷宣言)
  • 獨立的工作成員與人員互動 勝於 流程與工具的管理
  • 工作產生的軟體 勝於 廣泛而全面的文件
  • 客戶的合作 勝於 契約的談判
  • 回應變動 勝於 遵循計畫
The Agile Principles (敏捷原則)
  1. 最為優先的事情是透過早期與持續交付有價值的軟體來使客戶滿意。
  2. 歡迎需求的變動,即使是在開發的晚期。敏捷式流程駕馭變動來作為客戶的競爭優勢。
  3. 頻繁的交付工作產生的軟體,自數週至數月,週期越短越好。
  4. 領域專家與開發成員必須一同作業,並貫穿整個專案開發時期。
  5. 使用積極的工作成員來建構專案,給予他們環境以及支援所需的一切,然後信任他們能夠完成工作。
  6. 在開發團隊中最快也最有效的傳遞資訊方法就是面對面的溝通。
  7. 工作產生的軟體是衡量進度最主要的依據。
  8. 敏捷式流程倡導水平一致的軟體開發
  9. 專案發起者,開發人員以及使用者都必須持續的維持專案進度。
  10. 持續重視技術的優勢以及設計品質
  11. 最好的架構、需求以及設計會出現在能夠自我管理的團隊裡
  12. 在規律的反覆之間,團隊會反省與思考如何更有效率,然後相對的來調整與修正團隊的開發方式。
透過以上的條文相信讀者都能比較了解敏捷式開發的一些精神。當然,既然稱作一種原則,就代表團隊引用敏捷式開發時,並非照本宣科的一股腦引用,而是應該審視團隊與公司的文化及產業特性,來評估能夠參考的部份。
延伸思考
其實延伸敏捷式開發的議題,筆者聯想到一個一直在台灣軟體資訊界爭論不休的問題,就是CMMI究竟對臺灣軟體有沒有幫助。其實敏捷式開發的精神與CMMI這類流程與制度導向的觀點在某些層面是有衝突的,如果制度化一切是個良方,那麼敏捷式開發出現就顯得沒有道理。
但是反過來思考,制度化的開發也使得印度內的軟體公司不斷壯大,他們很顯然的不會是使用敏捷式開發來運作。
若是有時間,或許大家可以來思考這樣的議題,希望對於台灣的軟體界能夠有所助益吧。

關於軟體開發到底該重視制度還是強調自由,網友Kate的回應值得參考:
我覺得軟體開發,就好比養一個小孩一樣 (養成遊戲的觀點), 在適當的年齡還是得進入必要的管理流程,如果讓小孩自己順著他的天分成長,少有的天才,才能在18歲大學畢業。
我從 Programmer 晉升到專案經理後,在回頭看看這個過程,才發現當眼界變大變廣的時候,思考角度又不同了。
舉例及回應:
1. 客戶的合作 勝於 契約的談判----------同意

當需求訪談時,為了要討好客戶,也為了整個Team 在客戶端有好的工作atmosphere,
對於客戶的要求,多半會做很多溝通,有時就義務性的多給1,2個 Service. 但要求多了,
就得把合約拿出來提醒一下、PM 要保持良好的交際手腕—打電話給合約部門或洽談者
接洽。由合約部門的來扮演黑臉。

2. 領域專家與開發成員必須一同作業,並貫穿整個專案開發時期

我記得自己是程式設計師時,參加需求訪談時,客戶著重在講流程,
在初始定義的時候,brainstorming 做一堆,當時覺得這些人真是囉唆,
例如一個下拉值可以做很多不同的選擇 list, 把要選的東西定好就行了,
但是Field Define, list item define, option define, 怎麼 user site 的不能區分清楚呢,
覺得好浪費我的時間喔~
等到我變成專案經理的時候,老闆著重在成本節省,很多programmer 
只要專心coding 即可,因此,在project initiate 時候,
只有Project manager , process analyst 分析,程式設計師不必介入,
因為他們還在忙別的project 上面的coding.

等到 project lifecycle from initiate transfer to design. PM 要花很多時間從頭講起,
若直接切入重點,會有很多回應說應該如何做,其實都是之前與客戶討論過的,
只不過是在沙盤推演的時候,因為執行性的不合適被否決,有些是起因於標準,
或是已經的policy. 這時,你不得不告訴Engineer 照做就行的。別再扯了。
但心裡也犯低估,老闆要是准許他們一開始參加會議,PM我就不必解釋這麼多了,
寫的文件,人家也懶得看,還不如用講的比較快~

但是,有可能你的需求訪談要經歷2,3個月,
因為Project scope and Business process 不同,在Cost view 的考量下
不可能這麼做喔~
外界定了一堆 CMM/CMMI, 北美還有 SDLC/ITIL 在有了實際經驗後,
去參加PMP Project Management Profession,
真的要說死老外,定這麼多東西,要累死這些 IT 領域的工作者~
但是說真的,管理階層看的View 就好比父母親,希望自己的孩子能在10歲
就大學畢業既能省時,又有good名聲,
這時就引進一堆管理手法,讓自己的小孩,照書養~這樣也比較能預期成品
在什麼時候可以達到什麼樣的火候。

而天真快樂的小孩本身-(程式設計師本身),重點看的是這個過程能累積什麼
樣好的記憶,好氣氛,好情景在自己腦海裡,而後顯現出自己的行為給外在
的人做評估,這個部分不用做文件的。隨便長,也是一個樣,照書養也是一個樣,
基本上功能性健全就可以了,至於氣質及完善程度,或有沒有賣相就無所謂了。

這是我個人的比喻及看法,也許有些人看不太懂我的比喻,
Product Lifecycle Management and Project Lifecycle Management 
又是另一套大系統,我從這個導入經驗中得到很多人生成長的想法,
所以就用這個例子來比喻。

作者:呂中力Terence Leu
作者簡介:曾任電視節目執行製作、網站企劃、程式設計師、軟體公司研發部副理。深信在全球化浪潮下,只有不斷的思考才是成長的唯一途徑。
文章出處:軟體開發的兩三事
圖片出處:www.syncit.in