gipi的學習筆記-經營管理、數據思考、終身學習

沒有限制，是所有人夢寐以求的，但這是對你最大的考驗，你必須要給自己設定清楚的目標，有計畫性的去把目標實現，而實際上，計畫也是一種限制，計畫讓你知道自己現在正在什麼位置上，接下來又要往什麼方向去。

當你接到一個時程極其不合理的專案時，你首先該做的不是哀嚎抱怨，而是去了解為什麼這個案子會來的又快又急，是因為公司面臨了很大的困難或挑戰？還是因為策略的急轉彎？又或者是老闆純粹等不急了？了解原因你才有可能知道如何去解決當下的問題，也許你的老闆是因為看到競爭對手推出了某項服務，所以希望自己最少不要輸人，要快點把這個功能(後稱A功能)加上去，而在本來的產品規劃中，A功能是包含在1.05版裡，老闆只知道1.05版裡頭有A功能，在他的心裡認為『1.05版=A功能』，所以他是直接跟你說：「一個月內把1.05版做完上線。」
 

[專案管理]五原則，讓你避開不合格PM

讓Sponsor安心，說到做到只是第一步，但這還不夠，身為專案經理，你必須要能站在對方的角度思考問題，你知道他有什麼不安，知道他希望能在老闆面前有好表現，知道他有不能delay的壓力，若你總是能從這些角度思考，並且一次、兩次、三次的協助他達到他想達成的目的，那信任感就會逐步建立起來，另一個重要的關鍵就是不要讓對方有surprise，能提前讓對方知道的事情就提前讓對方知道，如果時程會delay，或者出了其他問題，而這個問題勢必對專案造成衝擊時，提前告知是很重要的一件事，知道彼此沒有隱瞞重要的事情時，信任感才會提升，而且在告知時請務必先想好解決方案，並站在對方角度思考哪個方案最好？哪個方案對專案的衝擊最小？並讓對方知道你建議的方案是什麼。

講到這邊為止，我相信很多的PM都自認為能做的到，說話算話、提前告知、站在對方角度、給予最好的建議，這是多數我們在教育PM時一定會提到的，但一個不錯的PM跟一個卓越的PM間還有一個很顯著的差別，那就是「當責」

延續上一篇，本篇我們繼續來談談專案中的六種會議以及四種溝通類型：
啟動會議(Kick-off Meeting)
里程碑會議
決策方案會議
例行性會議
結案會議
變更管理會議

專案會議中，身為主席的你除了要弄清楚會議目的與找對的人來開會外，你還必須要確保會議最終能取得你預期的結論，那你應該要留意以下六件事：
1. 目的要清晰
2. 成員要挑選
3. 相關人員要表態
4. 結論要明確
5. 會議記錄要確實
6. 待辦事項要追蹤

常設性組織，人力資源被直接歸為固定成本，而也是因為這樣，人你不管怎麼用都是花一樣的錢，就算你省了2.5個人月的時間，但一整年下來我還是要花這麼多錢，但如果我讓你買3萬塊的元件，那等於我全年度的成本就多了3萬，從成本上看是增長的，在凡事講求cost reduction的年代，你這樣做老闆說不定還要好好稱讚你，但這是從成本角度來看，但企業經營應當同時看重獲利，而非只看成本過活。

專案規劃過程常犯的那些小錯誤：
1.因為工作量小或簡單而沒排入專案計畫
2.錯估資源的可用性
3.以工作量來規劃專案而未考慮工期
4.沒有考慮相依關係
5.資源沒有撫平

專案在正式啟動之前，往往會召開一場專案啟動會議(Kick-off meeting)，這場啟動會議的目的有以下幾個：
1.邀請專案的利害關係人(Stakeholder)參與，包含Sponsor、專案成員、客戶代表、需求提供者等人參與說明專案的目的、範疇、限制
2.說明專案主要的里程碑
3.介紹專案中的成員(包含主要Stakeholder)，並說明每個人擔任的角色
4.說明專案執行計畫書(PEP)中的內容
5.Buy-in專案成員
啟動會議要執行的工作很多，相對的前置工作也不會太過輕鬆的，以下我們以一個案例來說明究竟在專案啟動之前，專案經理有哪些重要的工作該進行吧。

其實專案經理的遴選不應該是如此的草率，還是該依專案特性、影響範圍、權責單位等來決定專案經理由誰來扮演較合適，如果專案的特性偏向產品研發，那專案經理大概都是研發主管；如果影響範圍遍及多個單位，那選擇一個位高權重或者具備專業的資深人員通常會比較容易執行；如果這是行銷部發起的案子，那其他單位的人大多只是擔任team member，因為當責人通常就是專案經理的首選

假設現在要起一個有關新產品的上市推廣專案，總經理委派行銷部的主管擔任整個專案的PM，整個專案的內容中應會仍包含了產品開發與合作夥伴的開發，因此把研發部跟業務部的部份成員也納了進來，所以整個專案團隊的組成為PM、行銷部*3、研發部*2、業務部*1，總共七位成員，如果今天你是PM，直接隸屬於你的三位行銷成員的管理自然不成問題，但研發部跟業務部的3位成員將是你要關注的要點，因為這3位成員的績效仍掌握在各自主管的手上，這意味著什麼？他會努力的去做他主管要他做的事情，但對你交代的事情並不會過度關注，除非他的主管要他全力配合你，所以我們可以說「功能性主管掌握了專案的人力資源」，當PM無法從功能性主管手上取得資源時，專案註定要以失敗告終，而這種專案狀況在你我的公司中肯定都存在著，做這種案子的專案經理，也大多不得善終(驚)，為了避免大家成為烈士，這篇文章主要跟大家分享的就是當你擔任跨部門專案的PM時，你如何好好的活下去。

專案規劃與估算會直接影響到專案本身的健康程度，規劃不當會直接反應在專案的範疇、時間、成本、品質等交付指標上，由於我本身負責的專案都是屬於新產品的發展，很難一次將所有的需求看清楚，必須隨著專案的展開而逐步精進，但因為這種性質，我們可能會在專案執行1/5時才知道有個模組必須要被加進專案裡頭，而這個模組的總工作量佔了整體專案的30%，所以一開始提報給老闆的時程與成本將會大幅增加，專案的SPI/CPI也將失準，為了讓專案後續的運作可以更順暢的執行，一般我會進行重規劃(Re-plan)的動作。

你無法預估半年後的專案計畫是否會變動，但你對這一兩個月的專案計畫應該是有把握的，做的事情應該要十分的明確，既然已經明確，那我們要管理就會相對簡單很多，我們可以把一個一年期的專案切開成數等份，每一等份就是「局部的」專案，我們的目標就是讓每個局部專案能順利推進，我只要確保這段時間內的工作準時完成，原則上就能保障下個局部專案可以準時開工，一個比較長的專案，原則上我會把它切成數個局部專案(或子專案)，然後進行局部要徑管理

一個專案的範疇在定義上並不困難，但卻是很多專案無法驗收的關鍵點，範疇錯誤，時程、成本與資源的預估都是錯誤的，甚至可以說是整個專案的規劃都會出了問題，一個範疇定義不清或者範疇控制不當的專案，到專案後期的修正成本往往非常高，而範疇定義首重需求的收集與確認，前頭多下功夫，後頭才會輕鬆。

圈圈內的事是客戶在意的，也是你該去滿足的，但部門與個人想創造的價值你也不能忽略，不過在訴求價值時也不要忘了這個大前提「專案必須滿足客戶對範疇、時間、成本、品質」，若你連滿足客戶需求都沒有做到，也不要談其他的了，對個人來說也是一樣的，你若連老闆要求的事情都沒做到，你額外做的對他來說就什麼都不是，只有當你滿足他的要求後，他才會注意到你其他方面的貢獻，所以不管如何，滿足需求是首要，在不違反這個原則下才去思考其他的。

在不影響客戶期望下，你額外做的若對部門、對個人的價值是有提昇的，那我不認為是鍍金，而是一種價值差異化。

流程是實際的執行階段，也就是不管如何，專案通常就是會經歷這些階段，而知識領域則是先備知識，所以我個人在學習以及在幫人家做教育訓練時，我的方式都是先學習九大知識領域以及各領域的子流程，最後才是透過一個實際的專案讓大家可以將這些知識串起來，但我不要求大家去背這些流程，而是先挑選重要的子流程，要求大家一定要先做到這些項目。

一個沒有設定交期的產品是不健康的，一個沒有範疇的專案是不合理的，Diablo3固然是一個很大的開發工程，可能會分很多個開發階段，並切成數十個大小專案，但一個好的開發專案應該是明定好交付時間、開發範圍，並嚴格控管好人力資源(確保關鍵人員不被挖角)、時程與風險，Diablo3理論上不會拖了10多年才上市的，希望隨著產品上市，能看到更多關於這個產品在開發與管理上的一些細節，應該是個很好的教材。

[專案管理]如何展開WBS、排定時程與規劃資源？
在專案控管時我相信大家都會展WBS(Work Breakdown Structure)，WBS在專案管理裡已經是根本中的根本，WBS展的好不好，某種程度已經先決定了你專案做的對不對，有沒有遺漏或多做？也就是所謂的範疇(Scope)是否有誤，而透過對每個工作項的時間預估與資源分配，也能讓你能一睹專案的全貌，更加清楚你完成了多少工作，還剩下多少工作。

[專案管理]從「復仇者聯盟」看專案管理
這部戲過程中有許多值得玩味之處，如何找到合適的人？如何管理一支夢幻隊？如何讓團隊對目標有共識？如何激勵每個人？如何善用每個人的能力？這些都是專案管理中很重要的工作，今天看完片子的一些心得，跟大家分享。

在專案執行過程中，在每個工作項中，我們一般會定義「交付產出物」，也就是完成這項工作後會產生的結果，將此結果交予下手，讓下手可以執行他的工作，例如在開發一個系統時，SA交付給SD的就是系統分析規格，裡頭可能包含了系統結構、模組、介面、主要需求描述、需求配置等等內容，這些就是SA階段的交付產出物，而SD可透過這些來自SA的產出物往下開立SD規格。