書摘：『用一半的時間做兩倍的事』

大家高度專注
並肩作戰
渴望衝開阻礙

作者：傑夫．薩瑟蘭 (Jeff Sutherland) 譯者：江裕真 出版社：天下文化 出版日期：2015年04月29日

有一種新的管理手法：
以較少的人力，在較短的時間裡，用較低的成本，
創造出更多的成果，而且品質還更好；
我知道這聽起來好像不是真的，但事實擺在眼前.....

※※※※※
※  人  ※
※※※※※

    如何實施Scrum方法來創造高效率團隊？首先從專案組織做起，挑選出各種角色人才來合組團隊。(註：沒說要天才，而是讓大家有機會發揮自己的長才)

    我們要建立一支小而美的團隊。

    要知道3人~7人的組織是剛剛好的，當多於9人時運作速度就會下降。在人月神話一書的研究指出，對一個延遲進度的專案中「加人」會讓專案進展更緩慢。因為更多新人加入，勢必讓更多老人分心去帶領新人，兩兩間的溝通也變得更多，超出負荷。因此，20人以上的專案耗費的額外心力比5人以下專案多；當只有3~7人組成的團隊，做同樣工作量的心力，只要 9~20人的 1/4。

    所以盲目的加人，只是增加問題的複雜度罷了。這並不是慣老闆的表現，要現有團隊員工爆肝加班，而是要對『事』不對人!!?? 是不是某些事情執行的方式有問題，造成了『人力』不足。

※※※※※
※  事  ※
※※※※※

    團隊真誠面對自己，檢視工作流程中的浪費，包括公司或專案僵硬制度下的繁文縟節。擬定計畫是有用的，但盲目跟隨計畫是愚蠢的....；不時檢驗與調整看看手邊的事，是否是仍然是該做的事，有沒更好的方法去達成。

    不過，我們常對人並歸因於他不努力。指責是一種愚行：別數落成員的不是，應該是挑出不良制度的毛病，也就是針對那些鼓勵不良行為、獎勵低劣表現的制度挑毛病。一起逼出那些偷了專案時間的問題並解決它，重要的是「未來」。

    切記，讓專案成員一次只做一件事，多工只是在切換中浪費時間與注意力。而事情做一半等於沒做，只有做完一件事，這件事才會產生價值。當遇到問題時，就停下來修復，讓這件事第一次完成時就做好。

    也因此如何制訂出依序在某段時間內要完成的多個目標，成為成功的關鍵。

※※※※※
※  時  ※
※※※※※

    你要怎麼吃掉一頭大象？ 就是一口一口的吃!!

    和傳統製訂出一個專案從開始到結束的每一項任務全時程甘特圖，有所不同。Scrum強調的是決定未來 2週內要完成的工作，並將之視為一段「衝刺」，大家要對自己能完成的事有所承諾 (但非過度)。

    每段的衝刺時間 都一致，建立起一致的工作節奏，讓每個人知道每一段衝刺，自己可以完成多少事。這樣計畫才有機會務實，不會淪於空想。

    因此要安排工作優先順序，雖然每件事可能都很重要，但請先做最能為這個專案 創造價值的事。接著針對這些項目推估要花費的人力、時間、成本。記得是由專案團隊成員一起評估，如用費氏數列1、2、3、5、8、13、..讓大家拋出估值，將大家出牌加總平均，若級距超過2級距要請頭尾者說明原因，並由大家針對該項重新出估值。然後從中挑選出本次衝刺的目標們。接著用便利貼寫下要完成的事項與何謂完成 (可以用顏色分團隊、成員或作業類別 ....)，並貼在SCRUM板上讓大家一目瞭然。

※※※※※
※  地  ※
※※※※※

    有了規畫但該如何落實？簡單的說，就是要『守、破、離』

＃ 守：遵守規則 ＃

    例如不間斷在同時段召集每位成員執行每日立會，每次僅能花15分鐘，並說出三個問題：

1. 你昨天做了什麼 來協助 團隊完成衝刺
2. 今天你準備做什麼事 來協助 團隊完成衝刺
3. 有什麼阻礙 團隊完成衝刺

    要深入討論的議題，則會後另外召開；不是每個人單純報告自已的流水帳，而是每個人對報告的人提出可以支援的方式或主動接手難題，主動追求「一起卓越」。

＃ 破：懂得機變 ＃

    管理者大師(Scrum Master) 負責每週會議召開，確保團隊運作透明化；並協助找出影響進度的阻礙。而每次提出的新成果，都是為了是讓產品負責人(Product Owner)可以去收集對產品價值的看法回饋。重點：優先的事情先做，但切記優先的順序永遠在變動，不要墨守。

＃ 離：隨心所欲 ＃

    蓋蚊子館不如造橋鋪路，SCRUM 強調每次都多一點點。擬定清單並檢查兩次，確保高價值低風險優先，才能在最低風險下創造出最多價值。Product Owner決定必須要做的原因與決定價值，但如何做由團隊決定。主動出擊比被動好；不是做完而是做出價值，並儘快提供價值給顧客(註：最小可行產品 Minimum Viable Product)。

※※※※※
※  物  ※
※※※※※

    因為SCRUM不僅想加快速度，更想擴大成效，也因此更注重產品的價值。而產品80%的價值來自20%功能，因此SCRUM的能耐就是找出那20%的核心功能

• 如果只專注能做的則：沒人用
• 如果只專注能賣的則：做不到
• 如果只專注沒熱情的則：產生平庸結果

    所以要觀察全貌而非自己的觀點，從足以激發顧客購買意願角度，列出系統必須具備的全部功能。然後決定先做甚麼。如果你比對手快5倍提出價值高5倍的的產品如何不贏？

《簡介 Agile 與 Scrum》

《如何在組織內有效引領敏捷變革》

組織圖也可以這麼畫

    想到畫組織圖之類，有層級概念的圖表時，大家會想到啥？會怎麼畫!?!? 腦海中浮現的是跟我一樣的方塊嗎?

    說真的，當初發明這樣表格呈現的人真的很強，而且也真的非常的清楚，一點也沒有不好，所以如果要我畫組織圖、階層圖時，我的首選仍是它。覺得單調，那加每個人的照片好了，感覺很適合房仲業使用：

    太Low!? 那或許加點設計細胞讓它更美觀些!! 下圖有沒有很有架式的Fu，也還是很適合房仲業，當然設計業更覺貼切就是了：

    等等，你以為這樣就很棒了嗎? 前幾天看了本講設計師該如何經營公司的書，又讓我開了眼界，連組織圖都打破我的想像

書名：設計生意經：空間設計師的創業獲利提案(The Business of Design: Balancing Creativity and Profitability) 作者：基斯．葛蘭內特(Keith Grane) 譯者：郭玢玢 出版社：典藏藝術家庭 出版日期：2016年02月01日

翻拍自書籍

    原來，只是我的腦袋單純的被僵化了，表達與視覺傳達這件事，從來並不會只有一種選擇，我並不是說，上圖的設計比原來的方塊階層圖好，而是我們該不時思考，有沒有另一種可能性。我們不該被制約所限制，特別是想像空間。網路上找到一些其它的組織圖，也都很棒，讓人想「Wow」一聲嚕。

為何台灣資服界業務更該學商業分析？？

PMP → To do the thing right ： 教導了我們如何把事情『做對』

PBA → To do the right thing ：

則告訴我們如何找出『對的事』，接著幫助別人把事情『做對』

前言

    用迷你裙或一昧討好來爭取青睞，犧牲自己用人情換來的小訂單只會是一時的，但後患卻可能是無窮的。  要知道在商言商，除非這個主管是真正的豬頭，不然每個企業(或主管)都會想更上一層樓，只有幫助他們贏得對企業真正的有利的價值，他們才可能真正對你推心置腹、言聽計從，訂單(或升遷)不斷。所以有能力的Member或Top Sales 一定都懂下面這個道理：

不是我們說服『客戶』，而是要讓『客戶』說服自己。

因此我們的唯一要務 ~

提供足夠且正確的『情報』，
讓客戶做出真正有價值的正確決定，
如此而已。

    許多資訊公司業務常有一個疑問，明明產品很好啊(??)，明明客戶缺這樣的解決方案阿(!!)，為何產品還是不被買單或是老是被價格對半砍？ 結果回到公司還要花時間欺上瞞下，鼓吹說：「這是策略性客戶??   所以值得給策略性優惠!!」

    其實因為客戶有時間讓你這不知所云的業務老爺來喝茶打屁吃你帶來的甜膩膩點心，兼讓你做不知所云的問題或需求分析，虛度了大家寶貴青春年華時，代表客戶早就找了「替代方案」，可將問題降低或減少損失… (例：重開機就好了、改用人工作業)。所以可以『根本』解決『root cause』的方案的『價值』降低了，甚至被忽略以為是不存在的需求，因為不再有『急迫性』。而此時真正的 Top Sales就懂得，重點不在原先的root cause，而是要轉向針對替代方案引發的問題，找出『新的急迫性』、『新的風險』、找出隱藏的損失和競爭力的流失，並將之轉換成替代方案造成客戶實際增加的成本金額。然後對照引進你要賣的solution後，所要投資的金額，回收的期間，兩相對照，只要是有利的，相信就會大幅提高客戶的買單意願。

    所以找出對客戶『現狀』最有價值的事去分析，並用真確的「多久時間」、「多少數字」來描述將帶回怎樣的「『有感』價值」，才是贏得訂單的不二法門。

    這讓我想起先前看的電影《紙之月》(笑)，女主角走頭無路使出色誘手段想換取訂單時，色老頭卻一把推開了女主角 ：

『
    妳是不是誤會些啥麼？

當初會跟妳買國庫券，是因為妳說出了：

「可以愉快的享受半年一次的利息(幾多錢?)」

而其他業務卻只會說：「期滿領回會增值」

』

(大笑)


如果是讀懂商業分析的Top Sales 會怎麼銷售出產品咧？？ 常見的流程如下：


※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
Define business need：定義真正的問題或現況需求

    很多時候，結局在開始就已經決定；因為人們常被眼前的迷霧所欺瞞。
我們要針對發生問題(或機會)的『物(Data)』，定義出『偏差(Delta)』現象為何？

例如說：銷售不佳，客戶說問題在「成本太高」；

事實上售價已低於對手，但營收卻沒增加，所以真的問題在「毛利太低」，導至可投入成本太低，結果造成品質太差，最後遭消費者揚棄，因此銷售不佳。

    因此不能只看表面現象，而要進行根因分析(Root case)或問題分析(如Fault Tree Analysis 故障樹分析)。不論哪一種方法論，其基本精神都帶有

＃ Five why(五個為什麼)：持續一直問為何甚麼會這樣 … !?!? ＃

• so what : 向上找影響或是是否是別人的二次因，找出後果
• so why : 找處方

＃ 問正規流程外的事：如果不是這樣會怎樣 … !?!? ＃

• exception 例外
• 其他可行性 (替代方式)

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
Access capability gaps：找出現實與目標差距

    要透過科學的測量去解釋對公司目標影響，“why / what” 要做這件事，並避免和公司目標相違背；指出要改善目標，訂出可行步驟，與決定驗證改善的方式，並做如此執行後的影響分析(好處或壞處)。然而有時要處理或改善的範圍這麼大，那就必須有所取捨，如採用AAA分類法找出最少預算卻可達大最大效果的事：

• MUST 必做
• NEEDS 想做做不到
• SHOULD 下次要必做
• COULD 可做

例如說：原本有500個基地台可能會發生故障

但全面更新不僅費時且成本過高，所以無法執行(案子沒了)。

如將各基地台依狀態、影響客戶數等加以分類，找出一定會發生異常，且一發生就應影響很大的先去做，可能這樣找出了20家，那麼就可以建議先做這20家(案子有了)。

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
Determine solution approach：決定解決方案

    找到了問題，接著業務帶著Pre-sale，開始來找出客戶的需求(錯~ stop)。

    要知道，簽合約前，不可能獲得足夠資訊做出完整需求彙整，一方面因為時間不足，另方面客戶機密或內部資訊也不可能在此時提供。

    既然，怎麼問也問不清需求(Requirements)，所以厲害的Pre-sale(或顧問)會繼續深談問題，分析找出解決問題的價值。是談客戶的『問題』而非滿足客戶的『需求』。重點是分析『BUSINESS NEEDs』，找出價值、急迫性，拱出大預算；而非討論Requirements，陷入報價多少砍多少的輪迴。

所有提出的解決方案，都要用最保守的數字去描述「損失」和「回收」值，因為在分析會議上，若被任何人質疑資料可信性。那麼整個方案的價值的可信度，也將被大打折扣。

例：客戶提出機台難用，目前替代方案是“多用三個人操作”，而你想賣進新機台。

找出風險：人員離職時，只能暫時用外包，但外包品質不穩，交期差。
分析：三個人 成本 60萬 (用最低工資算)
二次因問題：每年平均離職 1 人，每次都需短期外包，但期間常被被罰款(平均30萬)

而買新機台成本：只要OOXX，可不用多找3個人；換算起來回收期為?
創造緊急性：下次出貨時間 為…

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
Define solution scope：界定解決方案範圍

    此時最重要的是簽下合約!!?? 然而條約內容的訂定卻成了大麻煩，特別是軟體服務這種虛無飄渺的「需求」，最後

甲方不敢寫清楚，因為怕不能改
乙方不肯寫清楚，因為怕做不到

    最好的簽訂方式是羅列要解決的問題與達成的效果，並寫明如何評量效果。這樣才有機會做出更好的實際解決方案，特別是不斷更新進步的資訊產業。當然這種先進合約大家可能不知怎麼簽怎麼寫。那退而求其次，可以明訂需求，並訂出可被調整的幅度如20%，並訂出決定修改幅度價值的機制，這樣明看是乙方吃虧，但或許吃虧就是占便宜嚕。

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
Define business case：事前與事後效益評估

    我們都知道「problem」和「opportune」常像攣生兄弟，就是因為客戶有損失才會需要我們所帶來解決方案，所可能帶來的價值。

    但為何客戶嫌貴，因為無從得知每花下去 1元，可以帶來多少效益 (賺回幾元)，多久可回收成本，會從哪些地方回收成本 …..。

   所以在專案啟動前就應該決定評量價值的標準，這樣事後才能有比較相關解決方案。想想，若專案完成後，成效遠高於預期，就可用來最為吸引下一個客戶的最佳實務。但若不如規劃，則可以檢討與改進。而沒有訂出對客戶產生的價值，只在乎專案花了多少錢，有沒有賠錢，並不能讓你長期建立和客戶的戰略夥伴關係嚕。

後記

    想了想，工作近20年，合作超過50位業務，但僅有1位是我心目中的Top Sales，其他不是靠殺價，就是根本拿不到生意。記得第一次和她出門談生意，是從1個我連聽都沒聽過我們根本沒做的排櫃軟體開始；原來是客戶秘書打錯電話，原本大股東暗示找某家他旗下的業者，卻不小心打到敵對公司的我們。然而，短短半年那位Top Sales卻從原本僅值30萬的生意，拱出了3個合計千萬的新case。因為她從客戶要用排櫃軟體一路順瓜摸藤引導客戶發展出，真正可以幫助客戶改善作業流程的解決方案。從此之後，我才相信原來軟體業界還是有真正的業務高手存在的。

    但到了上完課後，我才了解到，原來這些手法都是有脈絡可循的，想想後也就不在神奇。重點是為客戶創造價值，而非想著要海噱客戶多少錢或想用小恩小惠拉攏承辦，客戶可不傻瓜阿。哈~

上課日：2015/6
課程名稱：★PMI-PBA★

書摘：『PeopleWare』

腦力密集產業的人才管理之道

寫在前面的感想與推薦

    所謂天時、地利、人和在古代常用在指作戰時的自然氣候條件，地理環境和人心的向背。然而時空移轉到今日，這些古人的智慧運用在專案管理上，尤其是在軟體專案的管理上，仍是十分貼切；如何才能管理天馬行空、但能力特強的腦力工作者？

《孟子•公孫醜下》：『天時不如地利，地利不如人和。』

    軟體專案經理必須懂得如何去掌握天時(時間管理)，這包括嚴謹的時間安排，也代表管理者如何去爭取更有利的條件、降低阻礙專案前進的風險、創造出更多的時間。

    然而，『天時』常得仰賴外界的鼻息，看客戶的臉色。也因此，強化內部的戰鬥力，讓生產力高於其他團隊，則可將時間無形間倍化。這樣的成效，首先可從良好的工作環境中獲得，簡單說就是創造讓專案團隊感到可以專心於工作的場所。兵法有云：以逸待勞。擁有『地利』使成員可以更健康、長效的付出，又可減少不必要的外界干擾；讓專案成員可以一心一意埋首工作。

    只是即使擁有天時和地利，卻沒有『人和』，也是將一事無成的。因為一個沒有凝聚的團隊就像一盤散沙，無法發揮 1+1 大於 2的群體力量，甚至可能發生相互扯後腿、相互攻訐的情事。專案的成敗可想而知。

《孫臏兵法•月戰》：『天時、地利、人和，三者不得，雖勝有殃。』

    不過，就算展現出了人和，但沒有天時和地利的搭配，也會顯得事倍功半，且長久以往也將磨損成員的熱情。也因此，專案經理必須努力同時去掌握住專案的『天時』、『地利』、『人和』，才能無往不利，所向披靡。

作者：湯姆．狄馬克、和提摩西．李斯特 (Tom DeMarco、Timothy Lister) 譯者：方亞瀾、錢一一 出版社：經濟新潮社 出版日期：2007年12月02日 我的推薦指數：★★★★★

    軟體專案的管理者，常犯一種特別的毛病，就是將人當成零件來管理。但實際上我們應將人力資源以非模組特徵的思維來思考，並應該將整個專案管理的焦點放在強化開發工作動力中。因為我們面臨的，在本質上，主要都是社會性的問題，而非技術性………。

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
爭取天時：創造出時間

＃ 減少白做的工作 ＃

許多經理人，花太多時間去嘗試把事情做好；卻沒有花時間思考：這件事真的該做嗎？ 透過事前的調查新方法、避免做次要工作、不斷地閱讀與學習，可以幫助我們做對的事情。

＃ 減少重作的工作 ＃

創作者對品質要求較高。因為他們的自尊與產品品質緊緊相依，因此，常讓此一標準高於市場所需。品質能夠超過最終使用者所需要的標準，乃是通往更高生產力的途徑。而當讓客戶在品質與成本間做出合理個取捨時，客戶通常要求的比創作者低；因此，單純的以市場為導向將導致遠離卓越。只有堅持讓品質成為一種信仰，讓創造者自訂高品質標準，才能提升了工作滿意度。對於那些肯為品質付出相當代價的人，品質將是免費的，最終將可省去產品一再重作的浪費，享受高品質帶來成本降低的好處，進而創造出更高生產力。

＃ 減少無益加班 ＃

有些經理人談到生產力，常曲解為透過簡單的無薪加班制，提高生產力。即使員工工作80個小時，他們仍以一周40小時計算生產力，他們用威脅哄騙部屬，誘使員工接受緊密到令人絕望的時程，讓他們愧疚道只好犧牲一切來追趕進度。然而，人生苦短，每個員工內心都知道，人生有許多比工作更重要的事。長期加班成為降低生產力的兇手，這些組織裏沒有效益的長期白工，最終僅是傾向把工作時間耗光而已。

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
創造地利：打造高效率空間

    干擾讓員工沒有辦法好好花一分鐘在真正該做好的事情上。浪費一個工作天的辦法有千萬種，卻沒有任何一個辦法可以重拾一個工作天。有些開發人員以為加班就是生活的常態，事實上，我們加班常不是增加工作的量，而是彌補改善工作的質，因為上班時間太吵雜，你無法真正靜心做事。

    當人一心一意埋首工作時，會進入一種有如冥想，深深沉醉的狀態，時間不知不覺流逝，此時工作似乎順其自然地往前進。特別是程式開發這類需要高度集中精力的工作者，然而，一通電話可能就打斷，而每次中斷可能要再花15分鐘才能重新進入狀況。

    而若比較環境可以發現，頂尖好手的工作環境較為安靜、隱私，也比較不會受到打擾：

1. 好環境讓人工作較快
2. 好環境讓好手留下

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
凝聚人和：組織我們的團隊

    真正成功的專案經理知道，管理者的工作並不是叫人去工作，而是創造讓人想去工作的情境。回想過往最讓我們樂在其中的工作經驗，那肯定是某一次的「挑戰」；而且是團隊一起互動完成一件有意義的工作。凝結的團隊可以發揮驚人的成效，專案經理懂得確立團隊的目的並不是在於達成目標，而在於統一目標；這樣團隊因方向正確而更有效率。這樣凝結的團隊通常有強烈的認同感、低離職率且樂在工作中。

    在對良好績效具正面影響的因素中，有一個最重大的因素跟你配對的夥伴有很大個關係。任何工作的最終成果而言，由「誰」來做，比「如何」去做更重要。所以我們該給員工選擇想做的專案或和誰一起共事，藉此

〜  找到適任的人

    接著要注意減少團隊成員缺乏長期的工作參與感，而有過客心態；並且不會把把員工當成可替代的零件，使他們對自己產生可有可無的感覺，才能

〜  讓他們快樂到不想走

    最後，提供成員輔助模型等工具和透過廣泛的再訓練讓員工知道如何用自己的方法來做事，最終

〜  放手給他們自由發揮

    團隊將形成的化學效應，發揮驚人的成效。

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
其他補充

有關軟體專案團隊績效的研究：

• 薪資和工作表現幾無關聯
• 經驗年資10年經驗和2年經驗者差異不大
• 程式設計師的生產力最佳和最差存在 10倍的差距

• 最棒的公司比最差的快了11倍的工作速度
• 一個團隊的整體表現，趨近團隊中最差的那個人

書摘：『專案管理人應該知道的97件事』

我們遇到了敵人......就是我們自己

作者：Barbee Davis 譯者：莊惠淳 出版社：歐萊禮 出版日期：2012年12月06日

引言

    理論上而言，建立新產品或引進新流程都是簡單的。但事實上，這類行動卻是變得越來越難!! 這是因為這世界變化太快，頻率太高。尤其是軟體開發專案。所以，專案成功的機率越來越低。

    但這也可能是好處，因為我們可以改變專案範疇。若是建築業想蓋100層的摩天大樓，大概不能蓋到50層就先結束，剩下以後再蓋；只有軟體專案可以。只是，現今軟體界面臨的問題不是少蓋幾層，而是得面對是只能蓋50層卻想改成100層的窘境。不過，再怎樣的困境，還是要堅持專案管理的專業態度嚕。

時刻銘記在心的專案三角函數：專案的三重限制(triple constraint)

時間、成本、範疇，而中心則是品質。

當三角形的任一邊有所變動，勢必影響另一邊。進而改變了專案的品質。

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※

專案經理的責任

    『我們遇到的敵人，就是我們自己』，這句話很適合用來描述初接觸軟體開發流程的專案經理。要知道我們是專案經理人，不是超級英雄。所以對自己要實在，就像坐飛機發生危急事件是，正確的安全步驟是：先載上自己的氧氣罩，再協助老人或小孩戴上。因為如果我們先試著幫別人，可能因為自己缺氧而失敗，然後全部一起死去。

    因此當專案經理，失去了自我控制，因而無法照顧團隊，就會像缺氧的團隊，專案也終將失敗。

組成並打造出馬拉松團隊


    要建立一個強大的團隊，並不是找出一堆符合「技能」條件的強者；而是要找
出一堆有「天分」的人，包括：是否能和別人和平相處、是否遵守規定、是否對新事物流露出興奮之情、是否喜愛學習等，這樣才能打造出能跑馬拉松的團隊。

    另一方是從中找出優秀人才，要知道：「人數永遠不等於人力。」找一個中庸的開發人員，只會拖累進度，並不會改善問題。甚至，造成優秀人才的流失與困擾。特別是軟體開發，軟體開發是門藝術，並不是靠人力生產的產線。

    而要維持這樣的團隊，保持專案成員的士氣很重要。如果專案經理學習尊重團隊成員，並願意和成員談心，士氣就會改善。並且還懂得分享專案願景，讓團隊成員知道若達成自己的專案特定目標，將對整體計畫目標的成功有何貢獻。將激發成員的榮譽感，並會想要努力達成任務。


※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
有效方法

團隊合作依賴兩項關鍵原則：授權與負責

只要領導風格、授權與責任都各就各位，就能互相支援。並保證出現更好的成果。

幫助成員解決效能問題

套用 CRAM：限制(Constraints)、資源 (Resources)、才能 (Aptitude)、動機 (motivation)。依序去找出可能問題 並協助解決。當成員的才能不適合目前角色時，轉換其工作或讓他到其他團隊發揮所長。

引導利害關係人參與專案


    每個專案都需要贊助者，不論是好或不佳的贊助者，都是身為專案經理人的我們所要去管理的。及早讓這些贊助者或利害關係人參與專案，可有助於專案不會偏離目標。而要達成這樣的目標，要先讓所有利害關係人必須對於專案運行流程有著共同的理解。所以要讓他們保有足夠的資訊、參與必要的過程，並學習與他們相應的相處之道。

    特別是針對最後的使用者，我們在開發時一些軟體開發人員或專案經理覺得很有道理的決定(改變)，卻可能造成實際使用者工作上的混亂。我們應該尊重他們過去的習慣，所以我們應該引導使用者儘早(越早越好)對軟體開發人員(經常)表達意見。

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※

建立適合專案的流程


    專案要與廣大的群眾組合互動，為了效率，所以應該先行規劃專案行政工作。也就是說導入適合的方法論；其中敏捷式專案管理與開發是一個不錯的選項。只是，當專案經理過度於遵循某種理論方法，反將妨礙了他們對專案管理的專業能力。專案管理的流程重點應該是放在效率與保持簡單。別依賴任何單一的管理規則，而是要彈性的運用所有可用的規則。並且繪製一條可變更的道路，來面對未來的挑戰。最後，就是要書面記錄流程(重要部分)，並確實遵守。這樣專案的管理流程才能落實到每一個成員。

SCRUM

發展有效率的溝通模式


    回顧失敗專案時，大部分的原因都歸因於溝通的失敗。對任何產業中的專案經理人而言，所必須具備的知識就是溝通，並和別人共同合作。

    因此，專案會議很重要，除了能促進溝通，更能建立專案成員的對專案的認同感。 但別落入純為開會而開會的陷阱，如果只有老闆或專案經理出席才能開的會，就屬這種，這類會議通常無法讓專案成員獲得價值。簡單的說，就是別讓PM成為所有溝通的樞紐與傳聲筒；而是讓所有利害關係人能一起溝通，這樣才能保持專案前進。

    另一方面，光開會寫不了程式。我們經常看到許多可以更有生產力的人被困在會議中，因此要讓開會變得有效率。故要避免讓會議變成例行公事 (試著先公告會議主題，並僅讓相關人參與) 或太深入 (真正的解決建議都不會在會議上出現，請指定適當人員於會後研究)，另外就是太常開會或是超出時間。


※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
有效方法

每日站立會議：

報告15分鐘、約10人的團隊會議，每人有1~2分鐘機會對團隊報告自己的進度；描述上次報告後所達成事項，與今日預計工作事項

輔助工具：

• ★建立布告欄，更新成員在勤時間，張貼每位成員大頭照，說明執掌與代理人
• ★運用 wiki 或IM 等工具；採用同步溝通或簡短的非同步溝通，可以有效補強面對面溝通的不足
• ★建立資料分享區：DROPBOX 等是不錯的選擇
• ★整合的專案儀表板：公布最新專案狀態、短期議題、長期議題、風險、預算追蹤、里程碑達成狀態……

專案經理的領導力展現，來自於對人際問題的管理


    專案經理常身陷於時程表的細節，但缺忽略了真正造成專案失敗的元素：人。專案中的成員或資源不可能自動校正並往前進，一切複雜的事並不會自動消失，甚至夾藏是『懷恨在心的人力資源』、『緊張兮兮的利害關係人』等。這些問題的管理也就是專案經理的存在價值，所以不該將這些狀況是為障礙，而是我們職務的核心。

    身為專案經理我們要注意壓力將導致成員行為退縮，且不願積極尋求解決問題的行動。我們要透過與成員的積極對話，並仔細經營工作的環境，來避免壓力的影響。在我們監控與保護非人資源時，也要小心培育跟管理手邊的人性資本。

    只是要知道，專案經理無法掌控一切!! 當一個專案經理人顯然想成為控制一切的中心點，參與所有「重大」的決策討論，並由他做出所有決定，表現出他可以掌控一切，但其實事實的結果可能正好相反，儘管專案成員會在口頭上同意，但離開會議後卻不見得會完全反映出我們的意向。更糟的是，這只會造成讓專案成員痛恨，讓成員覺得意見未受到重視，當他們有問題需要解決時，則會試圖從其他方面獲得援助。

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
專案經理真正要做的事只有4件

1. 經常清掃團隊中不合現狀的習慣 (註：但非增加更多程序。)
2. 分享願景，讓大家齊心協力；千萬別視其他人為笨蛋，只想搞垮公司。要知每一個專案成員都想要成功，並為自己的貢獻感到驕傲。
3. 傾聽客戶的聲音。但這並不是一昧的用「讓使用者好過一些」的心情來決定解決方案。而是傾聽他們宣洩對日常遭遇的表面症狀的不滿，然後對使用者提出一連串的問題，找出沮喪下的真正根源。確定了正確的目標才是對使用者最好的做法。
4. 為你的團隊服務。

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※

規劃是為了找出成功的道路


    計畫的目的並非建立一套文件，而是要讓我們思考專案的問題，找出讓專案成功所需的要件，因為或許專案進行時路程會依實際狀況而有所改變，但目標的變更卻是很少見的。所以可以先為達成目標勾畫出一條合理的道路。

    只是何謂合理？根據統計，軟體開發有60/60 法則：也就說，軟體開發週期中，實際上僅 40%是花在開發，而有60%是花在維護。甚至，是花60%在維護，而另外花60%在強化。因此，所以得合理是指據現實以規劃，並再加上維護與風險管控用的緩衝時間，也許是10%...或更多。

    而誰是最佳估計人選？請直接邀請負責工作的人來協助。一個良好的方式是使用DELPHI 法，由實際開發者與其他同輩們共同去估計每一項工作，大家分開估，同時亮出答案，然後討論找出合適的對應值。這樣不僅可以互相討論找出合適的作法，而且也會最接近實際開發的時間。

    只是，常見的狀況是，專案經理常在專案開始時做了規劃，但卻在專案執行過程中，未曾再審視這份評估報告。其實，正確的作法是定期的進行評估，並持續追蹤狀態、適當調整計畫內容。透過這種持續、積極的反饋，將使我們日漸進步，且更清楚掌握專案。

評估真正獲得的事項


    軟體的困難處在於『沒有可以驗證的優良、可驗證的建構方式。』或許可以說，因為可以用來組合的方式太多，反而沒有方法可以預測。

    專案的工作狀態完成與否，是由客戶定義而非狀態報告。當專案團隊回報95%工作已完成的事實，和客戶能否使用我們交付的成果，兩者並無真正關聯。

    因此要了解自己的整合點，基本方式就是拿出 工作說明書 (SOW) 找出 WANT 和 NEED，並比較出差異。然後回答，我們試著達成甚麼？甚麼可以讓這個專案對客戶、我的公司和我而言都算成功。

    然後，擱置不重要也不緊急的工作；減少不重要但緊急的工作。然後，立即處理重要並緊急的工作，但要優先建立處理該類事情的反饋迴圈。但最重要的是，處理重要但不緊急的事。因為這些才是最有價值的事，或許當下沒法看出好處，但隨著時間將會發現這才是專案成敗的關鍵。試著評估、分類這些專案的大小事，並評估完成工作的方式，而是單純針對交付標的，不是去在意成員工作了多久，而是注重其產出成果；這樣才能讓願景、期望與專案進行狀態保持一致。

規律的專案排程與私人生活時間


    專案經理人通常會是專案中的唯一一人，沒有備援人選，因此很多專案經理人常會因為責任感而放棄了假期。但一個專案經理真的需要定期的休假，才能從專案的高壓中喘口氣。因此，在專案中試著培養可以填補專案經理角色的人，或是建立自我導向的敏捷團隊。千萬別覺得專案少了你將會停滯不前，就取消渡假計畫。

    不僅僅是專案經理自己，也要替專案成員著想，安排規律時間以恢復專注力。另一方面，也可將專案分切成更多小的周期，配合週期來工作；因為我們的身體充滿各種自然週期，生產力自然也一樣。我們把工作分成較小的周期，提供了追蹤進度與讚揚良好開發的機會。還可會為團隊成員提供相互反應與回饋的溝通機會。

    最後，最重要的就是，避免打地鼠式的開發。當時間因素非常重要時，我們該如何提升速度?? 『保持一致的適當速度前進』。當我們只是一味求快，卻可能造成未來更大的時間與成本投入。若我們能從頭就用穩健與注重品質的方式投入，最終，你卻會發現「慢」才是快，而「快」卻可能永遠沒有抵達終點。因為品質永遠是結案的唯一選擇。

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※

企業、組織與環境


    真正的成功，伴隨著公司組織的支援而來

    當身處不支援或功能不健全的公司組織，則可

1. 反覆詢問，直到理解專案的範疇
2. 找出利害關係人，在時機允許下邀請他們參與計畫進行
3. 讓實際做事的人可以全面參與專案更新與決策
4. 做個誠實的專案經理，不要掩飾或簡化問題

    而想要保持長期成功的組織，可以試著導入PMO(專案辦公室)。讓專案管理的紀律與風格可以傳承與持續改善。

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※

資源的運用與管理

※ ※ ※ ※ ※
人才
    專案經理普遍同意，『人』是專案最重要的資源，但最為困難的挑戰是如何適當地讓團隊成員參與到專案中。因為當成員尚有其他重要的日常職責時，將會使他們做出選擇。

    只要透過讓專案的目標與公司的目標一致化，讓在專案中成功的成員獲得在公司更多更上層樓的機會，才能使成員願意花更多心思投入。



※ ※ ※ ※ ※
工具
    「所需工具尚未發明」症候群害的大部分可以偉大的團隊脫軌翻車。這些團隊成員總認為他們遇到「非常特殊的需求」，需要客製化解決工具。但殊不知，早已有適合的工具被他們棄之如敝屣。所以，他們開發出了真正的「敝屣」。

    透過購買現成軟體可以減少花費在開發和實作階段的時間。並可以購買到軟體公司的know-how。但前提是要辨識出真正的需求，且詳實了解要購買的軟體的細節。

資源的運用與管理


    糟糕的需求定義永遠是專案失敗的主因之一。所以專案的擁有者(甲方) 更應該從頭到尾的投入。並認真地思考出需求，要知道，專案的失敗，傷害最大的擁有是擁有者。除了投資下去的成本外，更重要的是可能因為重要專案的失敗，導致喪失的競爭能力。

    為了有清晰可見、定義良好的規格和接受度準則，要試著讓解決方案更簡單、容易，如用樹狀圖、心智圖來描繪需求，並保持需求的簡單；透過敏捷開發流程，來縮短代溝。

    要達到上述結果，就要儘可能將專案分解成許多各自獨立的，但可管理的workstream，並讓其中重要成員略有重疊，以保持資訊的分享。而且再將每個workstream 做出工作分解結構，讓工作內容分解到最小工作包。事前多花一點時間，取得專案成員的理解與同意(包括專案利害關係人)，將是成功的不二法門。


※ ※ ※ ※ ※
重要的文件

專案範疇聲明 (scope statement)

它是專案的藍圖，描述了專案最終成品或服務的特性；定期舉行會議檢視專案範疇聲明，將可以增加專案成功的機會。並讓所有利害關係人的期待與專案的目標一致。

故事(stories)

將需求寫成故事：

1. 根據使用者的反應來設定及討論其優先順序。
2. 團隊版的專案範圍從故事中建構而成，並建立良好的接受度準則。
3. 故事拆解成任務，並由負責完成任務的開發人員予以評估。

狀態報告

要讓報告本身簡單，並協助開發人員愛上寫狀態報告。這樣靠幫成員理解這些報告對其他人的重要性 (註：不是只有對專案經理)，並即時與適當的回應內容，解決成員提出的問題，使成員覺得透過狀態報告有價值。

商業價值永遠是衡量成敗的標準

    專案經理對該交付原本承諾的事物：不要多、也不要少。

    有經驗的PM知道自己必須從第一天開始就保持堅定立場。並在專案中事先計畫祕密的應急時段與計畫，並將其視為最珍貴的資產，在絕對必要或專案結束才使用它。

    另一方面，專案經理也該深知，專案並不單單只是為符合成本、品質、時程和規格而努力。也要注意一項重要的任務，那就是專案要能為組織增加多少價值，這也是決定專案有多成功的唯一準則。

書摘：『一頁紙專案管理』

以最簡潔的溝通工具，將正確的資訊，在正確的時間內，傳達給正確的人；就能打造最精實的執行力。

作者：克拉克．坎波、麥克．柯林斯 (Clark A. Campbell、Mike Collins) 譯者：文林 出版社：臉譜 出版日期：2011年04月29日

    每個專案利害關係人，都希望知道事情進行得如何，但又不想花太多時間在上面，所以不希望收到太冗長的報告。可是也不想要拿到沒有因果關係、沒有連續性的簡單結果，因為這樣得到的問題比解答還多。所以透過一頁專案報告，提供彩色的視覺化呈現。可簡單清楚的表達與說明專案在某個時點的狀態。進一步的說，就是呈現專案五大要素間的進展關係。

專案的五大要素：

• 任務(How)：任務是專案的中心，要完成它才能達到目標。
• 目標(What and Why)：目標是一種願景，也是專案要前往的地方。
• 時間線(When)：測量事情應該何時可以完成，以及實際完成的時間。
• 成本(How much)：專案費用可以是實際支出的成本，或隱藏性成本。
• 負責人(Who)：那些任務有哪些人負責。

＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃
一頁紙專案管理範例 (小編：這是我改寫過的，和原書並不同喔!!)

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
A區：專案說明區

    主要是放專案負責人、名稱和專案目標。等同是專案的血統證明書 (授權書 Project chart)。另外，建議可以在左上角寫上專案代碼，或是放上代表專案的幸運 Logo。若是多層次報表則可放上層次編號。右上角則放上報告發行的日期，用來區別版次。

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
B區 + F區：專案子目標狀態

    將一個大的專案目標，再拆成數個子目標。子目標設定可依「簡單」、「可衡量」、「可達到」、「相關的」、「有時基的」的SMART法則。通常建議分成 3個最適當，最多不應超過7個。做完所有   子目標代表專案就完成。
    而每個子目標將又要執行數個主要子任務才能完成，每個子任務的執行狀態就放在B區，並用不同顏色區分，就可快速掌握專案的健康度。

• ● 專案表現優異的部分用明亮的綠色
• ● 落後或超出預算的部分則用明亮的紅色
• ● 狀況不明處則用黃色

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
C區 + D區和D線：主要任務說明區

    標示出主要的任務內容於C區，以大項目任務為主 (小編:更細節的任務可以放到另一張的專案子報告，透過連結變成多層式一頁紙專案報告)，並用WBS編碼原則編碼。而D區則是時程安排線，以周為單位 (小編：最多12週，超過12周則切割成多個專案階段；透過多階段的方式更容易管理)。另外，加上一條明顯的時間軸(即 D線)，方便對照目前應完成進度與實際完成間的關係。

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
E區：任務當責分配

    標示出主要的任務內容應由誰負責來執行與完成。安排方式可採 RACI 模式。(小編：請參閱《當責式管理》)

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
G區：重大里程碑或重要交付項目日期

    標示出重大里程碑或重要交付項目日期。主要是用來提醒有哪些檢核點和一些主要任務所要產生並提交的項目。若有其他說明或補充，就寫到 H區的備註。

※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※
其他

    成本或預算雖然很重要，但有時並不方便揭露；且在台灣尤其是軟體界，預算與成本的主要支出都是人力部分。所以會建議直接改用實獲值來呈現。

＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃ ＃

感想與推薦

    專案管理是一門大學問，而如何做管理報表也是門學問。過去，我們常用MS Project 之類的製作。有時，卻有點不太順手。而且呈現又通常不是很直覺。所以，常常見到PM每個人都有自己的一套Excel版專案管制表。我自己就有一套。而這本書介紹的，也是一種好方法。想辦法將資訊填入一張A4大小的報告內，這樣就可以清楚的一目了然。若太多資訊要呈現，則應該分割到多個子層下面。當要看更細一點時，透過EXCEL的連結叫出來，感覺還蠻實用的。不過，我覺得還是要加上自動化的計算巨集之類的，自動去顯示紅黃綠燈，這樣才有一致的標準，也更實用囉。

專案管理的心得

沒有多偉大的流程，只要是習慣的流程就好

• 由於每一家公司的規模、文化、人員素質、專案特性與開發團隊的成熟度都不同，所以沒有足以一體適用的流程可以套用。
• 但要在落實專案管理的大框架下，針對不同的專案特性，可採用不同的方法論。
• 讓制度融入企業成為文化與習慣的一部分，就是成功的專案管理流程。

希臘式, 或是羅馬制

根據《Empire and Communication》一書研究指出

希臘崇尚英雄

   由於沒有輕便且制度化的通訊與管理方式，愛用「口耳相傳」，所以在擴張版圖時容易遇到阻礙。所以領內各小城邦各自為政。難以長期建立統一的帝國。不過，小型的組織文化，鼓勵了人們相互討論，並易於接受外部見解。所以激發了綿延不覺的創意和靈感，使希臘成為許多實驗性思維如數學、幾何學、西方建築學、哲學與科學的發源地。



羅馬講求制度

    則是因為使用了輕便的通訊媒介(紙)，並且建立了統一的行政系統。所有資迅透過「文字書寫」的方式，避免錯誤。而且，能運用來推行一致的規定。利於建構金字塔型，由上而下有效率的組織架構。但這樣的方式，在組織日益擴大時，變成需要更多、更複雜的法典和標準才能管理，反而漸漸成了包袱。再加上層層官僚難免人謀不臧或顢頇，將導自最終失去了活力與想像力。

    想想這不就和軟體專案管理的派別之爭很像。

    一方面像是CMMI、RUP之類，講究嚴謹的程序與規劃；就如同羅馬軍團般，期望用整齊劃一的步伐，踏平敵軍，攻克目標。而另一方面，最近新的流派，則講求敏捷，如Agile、SCRUM等。希望較少的規範，讓英雄們傾全力用於戰鬥。但到底誰好？卻沒有絕對的定論。或許，就像希臘一樣，若大家能遵從這種持續學習、良性溝通和互動，並將專案切割成多個階段。那麼也許真的，用這種輕便的體系才是長治久安的王道吧。

專案管理中的溝通管理

在專案溝通管理中，不僅要定義溝通的方法，也該試著檢驗溝通的強度

－ 【組織溝通真實關係圖】

    在專案管理的各知識體係中，我一直覺得最容易理解，卻最難執行的就是溝通管理。起碼，我很難去判定，到底溝通順不順暢。似乎沒有好的工具可以去檢測。小專案也罷，抬個頭就可以發現誰和誰氣氛不對；但如果是數十人、甚至是數百數千人的專案咧？

    在麥考倫發明的企業組織圖裡，簡單明瞭。每個人都知道要向誰報告，也因為格式統一所以大家一看就知含意。也因為每個人在組織圖中都有一個位置，所以組織圖讓體系變得清楚明確。

    然後，當責的思考制度下，加上ARCI的觀念：誰當責、誰執行、誰可以被問、誰要被知會。顯然工作的合作與權責的分派時，無法像組織的樹狀圖那麼單純，而是可能變成一張蜘蛛網。但上述的蜘蛛網真實存在嗎？

    新社會地圖學者Valdis Krebs 提出新的概念，因為這個整齊的組織或權責圖隱藏掉了許多我們更關心的事物。我們若用不同顏色代表不同部門，則在分析失敗專案的電子郵件往來時，會發現顏色群集相當整齊，或是發現由一小撮人(主管)接收許多線條。也就是說專案成員溝通非常少。

    新的組織溝通真實關係圖，表現了某種社群關係和線路集散點。人們工作出現問題時的溝通對象、誰和誰是日常工作夥伴、誰是流言收發處 … 這張圖建構了複雜的人際網路。

    顯然若是我們有一個系統，持續定時收集來往電郵、各式開會名單、工時記錄中的訪問的對象，另外不定期的採用問卷收集溝通的意見。那樣應該就可以提早發現是否有溝通的問題發生，雖僅能判定溝通強度，而無法了解溝通品質。但起碼可有效預防與預測溝通障礙發生的可能點，相信對執行專案管理會是很好的輔助工具。

專案時程的安排

『工作量會膨脹到把這項工作被賦予的時間全部用完為止』

                                                   ~ 帕金森法則

意指原本可以在短時間內或是用較少預算完成的工作，如不有效率積極處理，就會把所有時間和預算消耗殆盡。

所以安排專案的時間是門很重要的技巧，過與不及都不好，
安排太緊→ 則專案成員認為反正達不到，專案時程是用來 Delay 的；
安排太鬆→ 則專案成員不會有時間壓力，反而會拖到最後一刻，所以依舊是 Delay；

因此適當的安排時間，並稍有一點壓力，
反能會使專案成員更專注於眼前工作，
而準時完成專案。