【好書分享】The Deadline — 最後期限:專案管理101個成功法則

The Deadline 最後期限:專案管理101個成功法則
The Deadline: A Novel About Project Management

作者/湯姆‧狄馬克/著
譯者/UMLChina翻譯組
出版社/經濟新潮社
ISBN/9867889169

內容簡介:
這是一本令人回味無窮、愛不釋手的管理書。《最後期限》的故事兼具創新及趣味性,在每一章結尾還附有對於團隊專案管理非常有用的實務法則。——John Sculley,蘋果電腦公司前執行長

這是一部故事性很強的技術管理書籍。它涵蓋了許多主題,從專案評估到選擇度量單位,從解決衝突到處理含混不清的規格說明……盡情揮灑的管理智慧已使本書物超所值……《最後期限》就像呆伯特的漫畫一樣有趣,但是不那麼諷刺。更重要的是,書中蘊含許多深刻的智慧,可以幫助你在面對下一個「最後期限」時能增加成功的機會。我強烈推薦這本書。——Edward Yourdon,軟體業知名顧問與作家

  湯普金斯是名資深的專案經理,但不幸被公司裁員了。有人出高價「請」他到一個海上小國,負責6個軟體產品的開發專案。資金、人員、設備都已齊備,湯普金斯以為可以大顯身手,甚至進行一次難得的專案管理實驗——將所有人分成18個團隊,也就是每個產品成立3個大小不同的團隊彼此競爭,藉此觀察不同的人數、工作方法對專案有何影響。但是他漸漸發現,事情沒有那麼簡單,各種問題紛紛出現,時間越來越少,眼看著「最後期限」即將來臨……

  本書用一則虛構的故事,闡述了真實世界中專案管理的一般原則。它將專案管理的條列式知識,以生動的場景、淺顯易懂的方式來呈現,一掃專案管理書籍的枯燥之感,讓您在輕鬆閱讀小說的同時受益良多。每一章以主角的日記結尾,並歸納出101個成功管理專案的法則,這些是本書作者——資訊管理界的權威湯姆‧狄馬克累積數十年實務經驗,所得到的經驗與智慧,可以幫助你在下一個專案中無往不利!

將生硬的專案管理理論以寓言、奇幻的方式寫成小說的型態,作者的文筆及功力真是了不起!

湯普金斯被 “綁架” 至一個奇境的國家(摩羅維亞)擔任專案經理,管理著 1500 人的軟體開發人員,分為六個產品線開發,約 710 個工作天時程;結果又被上面的 “豬頭” 執行長壓榨再將時程縮短 5 個月之多。這種不可能的任務,湯普金斯該如何完成?

這本書道盡了現實軟體專案開發理想與現實的難點:如何達成成本、品質、時程、規模之間的平衡?
軟體公司內永遠都會有個 “豬頭” 執行長,他只管成本與時程。

不能說他完全不對,但專案開發是需要從許多面的 “構面” 來衡量的;不只”財務”的構面,還包括了 “人力資源” 、 “資訊” 、 “組織” 等構面的整體考量,尤其,專案管理的本質仍在於 “無形” 的價值,即在於 “人性” 上的關懷。

由於執行長會量化,而 “財務” 、 “人力成本” 等是容易被量化的,至於無形的資產,因為不容易被量化,所以很容易就被忽略掉了。絕大部分軟體專案的失敗,亦源自於此:忽視掉了 “人本”。

本書裡面提到了許多專案管理方面的 技巧及觀念,例如:

  • 如何將專案經理的 “直覺” 量化,成為可以計量的 “因子”,而得以建立模型與模擬。書中提到的 iThink 工具,其實就是 “系統思考(System Thinking)” 的模擬工具。
  • 內文提到的 “CMMI”,沒有人對它會有興趣(除了執行長)。不是沒有幫助,而是太容易浮濫,往表面功夫來做文章。深得我心!!
  • 少做表面功夫,思考如何減少無效會議。
  • “簡單設計” 與 “除錯”。這是 XP(Extreme Programming)的實務精髓。
    尤其小說內的產品時程估算從原始的計算程式碼行數,至修正為改以 “功能點(Functional Point)” 來估算。務實又有效!
    至於如何才叫做 “完成功能點” 的開發?利用 “驗收測試(Acceptance Test)” 測試功能點,是最直接、且最不容易有糾紛的方法;內文也談到了 “單元測試”,嘿嘿,很有趣,基於時程,專案經理認為有些可以略過,與我原來的想法可說是不謀而合。:D

稍微有點可惜的,本書並沒有著墨太多在軟體設計的 “系統內部”,如,軟體系統的結構及整體架構設計考量等。畢竟,該書並非為軟體設計類的專書。 🙂

另外,有趣的是,作者還蠻有幽默感的,他所設定的虛構國家元首這個角色,設為 “比爾(Bill)” — 用股票交換然後買了這個國家。 😉

壓力的效果

摘錄:「The Deadline 最後期限」

Oracle(先知)對專案經理的回覆:
>為什麼給程式設計人員的壓力最多只能得到 6% 的生產力提升呢?

在壓力下的人思考不會變快。

專案經理的註記 — 壓力的效果:

  • 壓力之下的人思考不會變快
  • 增加加班時間只會降低生產力。
  • 短期的壓力甚至加班可能是有用的策略,因為它們能使員工集中精力,並且讓他們感到工作的重要性。但是長期的壓力肯定是錯誤的。
  • 經理之所以會施加那麼多的壓力,也許是因為他們不知道該怎麼做,或者因為其他辦法的困難而感到畏縮。
  • 最壞的可能性:使用壓力和加班的真正原因是為了在專案失敗時,證明大家並非沒有努力。

“簡簡單單”的概述軟體開發流程與UML

或許?剛入門的軟體開發者還不一定很清楚軟體的開發流程(Development Process)與UML到底有何關連?
所以我想用簡簡單單的幾句話來概述為何是 UML?又,為何沒有所謂標準的開發流程?

軟體應用系統的開發,通常是以專案(Project)的方式來進行。由包括 PM(Project Manager)、Architect(架構師)、HSD(High-level system designer)、DSD(Detailed system designer, 接近 CTO 的角色)、Programmer(程式設計師)等各種角色所組成的團隊。在一定的時程內,運用有效的資源,來達成有效率的系統開發。

專案開發的期間,在每一個階段會由不同角色的開發人員,依據職責來產出包括需求設計、軟體設計圖、程式碼...等。在有限的時程與資源,如何做最有效率的專案控管,團隊之間的 ”溝通”與所制訂的 ”開發製程” 可說是影響整個專案成敗的最重要關鍵了。

UML(Unified Modeling Language),統一模式語言,已成為標準化、視覺化的塑模工具。無論作為軟體開發團隊內部溝通、或軟體設計與程式寫碼的兩地(如台灣設計、大陸施工)分工模式,UML 是唯一可以跨國界、無縫式地從企業流程分析、系統分析/設計、並銜接到系統開發階段的最佳表示法(Notation)。UML 並已成為軟體業界的國際標準。

至於開發製程,也有業界所推出 RUP(Rational Unified Process)、XP(eXtreme Programming)乃至於所謂的 “Agile Modeling Process”。
每種開發製程理論均有它的核心思維,但其目的均在於期望能在專案的四大變數:”成本”、”品質”、”時程” 與 “規模” 之間達成一定的均衡。

開發製程無法如 UML 一般可以成為所謂的 “國際標準”,原因即在於專案的性質及成員的素質等因素均不盡相同。但上述提及業界所推的開發製程,卻可以成為開發團隊在自訂自己內容開發程序時的最佳參考與範本(Template),甚而可以成為很好的輔導工具。

這麼說好了,團隊開發成員之間可以講相同的語言(UML),以利相互的溝通;但每個團隊要如何達成目標,則各有其方法與程序(Process)來達成任務。程序是 “How-to”,每個團隊的 “How-to” 是不會完全一樣的。

又,為何是用 UML 來作為溝通的工具?

由於擔任系統開發的各種不同角色的團隊成員之間需要能做有效率地溝通,傳統的系統開發,大部分是以所謂企業流程圖(Business-flow diagram)或以程式碼來溝通。
前者是從在企業內部擔任高階經理人的角度來看待系統,所表達的往往是系統的功能面需求(Functional Requirement),並不足以表達軟體系統的內部結構;而後者,又太接近與系統平台面相關的程式碼,且每個程式設計師的程式碼撰寫風格不盡相同,直接以程式碼來作為團隊之間的溝通,對 PM及SA/D等人的解讀障礙度非常高。
前者太粗糙(coarse-grained);後者又太細緻(fine-grained),都不足以成為團隊所有成員之間的溝通工具。

俗話說:「一圖勝過千言萬語」。使用圖形(Diagram)的方式來表達內心的設計思維,會是一個很好的溝通工具。
就如同建築業的建築師,在施工前會先以設計的藍圖來表達對建構實體高樓大廈的想法。且設計的藍圖會因為不同的作用而有不同種類的表達,例如鋼架結構設計圖、水電管線配置圖、室內設計圖...等,均是設計師與施工人員在施工之前作為溝通及確認施工前的最重要依據。

貝多芬用五線譜來創造音樂,我們用UML(Unified Modeling Language)來設計軟體;UML有如五線譜,兩者都是模式語言,只不過前者通用於軟體界,而後者通用於音樂界。

由 MVC 看軟體設計思維(2)

觀察 MVC 的設計思維,可以得知:畫面的設計並不是軟體設計的重心首在,畫面是手段,僅是為了表達展示給操作使用者來觀看的,若有更好的畫面呈現方式,系統可以整個抽離掉畫面而不致影響核心,就好比樹葉會代謝再長出新葉也是為了讓整棵樹能呈現更茂盛的一面。

同樣地,資料庫也是手段,是資料儲存的倉庫。若因為分散及負荷的因素,則需考慮配置多個資料庫,甚至,有效能更好、更便宜的資料庫,則隨時可更換之。

畫面(View)與資料庫都是手段,目的即是為了要能維護軟體的主幹–來自專業領域(Problem Domain)上的概念(Domain Concepts),概念往往成為軟體設計內的企業元件(Business Component)。

為了要能維護企業元件不因外在環境的變動而牽動,進而提升系統的彈性度及增進再利用的價值,軟體開發人員,要能考慮:

  • 變與不變的相對性。
  • 虛與實的相依性。

同時,又要能兼顧系統的效率與問題與使用者的便利性,也要能瞭解:

  • Stateless 與 Stateful 物件相互的配合。

閱讀全文 »

MVC的軟體設計觀(1)

■ What is MVC?

MVC,Model-View-Controller Separation 樣式(Pattern)
Problem:
希望能夠從視窗畫面(View)之中去掉領域(Model)的耦合,因而支援領域物件(Domain Object)的可重再利用性(Reuse),而且將對隨領域物件而改變的介面所造成衝擊減至最低,該如何作?
Solution:
將領域(Model)類別定義成無法直接耦合或看見視窗畫面(View)類別,並且應用的資料與功能是在領域物件之內維護,而不是視窗類別。

MVC Pattern 其實就是在 Model-View-Controller 三者之間作一個責任的釐清:

  • View:專注於畫面設計,不牽涉資料與邏輯處理。
  • Model:反應企業領域中真實世界的概念,例如“員工”、”部門”等物件。在 ”員工”物件中,它專注的責任在於取得(Get)及設定(Set)員工相關的資訊,並負責所需處理的企業邏輯(Business Logic),如計算員工紅利等 ; 而“部門”物件,則可以取得及設定部門相關的資訊。
  • Controller:承接 View 與 Model 的中間角色,以維護 View 與 Model 兩者之間的獨立性,並負責控制及協調 Model 內物件的互動邏輯。它的角色就好像是公司的總機小姐,當外部的使用者打電話(View)尋求該公司的幫助時,總機小姐(Controller)會依需求的不同再轉達需求至可以服務的部門工作者(Model)。

而且 View、Controller、Model 有著分層的關係,View 可以看見或者傳送訊息到 Controller或 Model 物件,反之,Controller和 Model 物件將會忽略視窗畫面的存在。
未了解 MVC 樣式,而把這些物件都混在一起,使用者介面程式往往亂成一團。
MVC 解開糾結,增進彈性及再利用性!

閱讀全文 »

到底什麼是 “Component(元件)”?

前陣子看到討論區有人提問,元件與類別有何不同?
直覺上,覺得蠻奇怪的,怎麼會拿這兩者來比較?因為這兩者是不同等位的:類別是虛的;元件是實的。

類別,即是種類上的區別。簡單的說,即是「物以類聚」。自然而然,我們會把較同性質的事物擺在一起,以別於其他的事物。
所以,分類是一種本能(不一定單指人類才有這種本能),是一種從抽象的角度來區別事物在行為或特徵上的不同點。
為了作比較,我們會區分為動物類、植物類;再更進一步的觀察,又會再把動物類更細分為哺乳類、爬蟲類...等。在更深入,會再將哺乳類細分為人類、狗、貓、猩猩、猴子等各種類別...。
以此推知,元件也會分門別類,諸如,UI(User Interface)元件、企業元件(Business Component)、功能性元件(Functional Component)等。

在軟體設計上,如何分類,是一門相當深入的功夫。這又是另外一篇重要的主題了。
回到本標題,真要作比較,可能是元件(Component)與物件(Object)來作比較說明會來得恰當。

學習軟體設計多年,我個人覺得有兩個專業的字彙,是最難最難解釋的了:一個是 “架構(Architecture)”;另外一個就是 “元件” 了。因為,這兩個字太容易太容易被濫用及泛用了。
針對上述兩個字彙,我個人也思考多年,或多或少有些自己的見解(至現在為止,除了高煥堂大師有這種能耐可以解釋這兩個字彙,我還沒有看過有人可以說出此兩個字彙真正的意涵)。
因為是我個人的見解來解釋什麼是 “元件”。並無所謂絕對的「對」與「錯」,只能說:僅供參考!

閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal