• Alice: May妳有覺得我最近屁股變大了嗎,我褲子都穿不下了 May: 恩,妳想聽實話還是好話? Alice: ……………..
  • Chelsea是天真活潑,剛大學畢業進入職場設計部的畢業生.在校成績相當優異,作品也相當完整,唯獨有一個小問題,剛進職場的她,還沒有辦法應付每天成堆的工作,每當被工作壓得喘不過去來,她總是會將極度不滿的情緒寫在臉上,「每個業務都來找我,我到底是有幾隻手啊!」
  • 大量的專案交付過程中,經常會出現專案交付的進度於計劃有較大的偏差,導致這種偏差的原因往往是多種多樣的,排除掉各個專案不同的因素之後,一般常見的引起進度失控的原因是下面這五種錯誤。
  • 要成為一個成功的專案經理,我們必須管理好自己的時間。專業的專案經理會確保他們的時間投入使富有成效,盡可能避免時間浪費。現在介紹六種必備的時間管理的技巧。
  • 到底專案進度是超前還是落後、成本是充足還是透支… 為了有效的管控專案進度,專案經理需要隨時掌握專案的現況,以主管的角度來看了解目前現階段的專案完成百分比不如掌握專案的時間及成本是否如期,因此,專案進度是超前還是落後?成本是充足還是透支?絕對是高階主管關心專案狀況重要的一環。
  • 現在的專案進度是… 為了有效的管控專案,專案經理通常會要求團隊成員回報任務進度,然而,我們怎麼去定義任務的完成百分比呢?由於任務性質不同,定義任務完成百分比的方式也就不一樣,就好比,寫了100行程式碼,請問這樣的進度代表多少?10%?20% ?還是80%?有些任務其實只有開始跟完成,也就是0%或100%!中間的過程其實很難定義完成百分比的!
  • 你知道軟體廠商是如何規劃出報價的嗎? 你知道軟體廠商在進行客製化開發,報價是如何計算的嗎?如果沒有標準化,最常用的計算方式便是先列出客戶所有需要開發的功能,接著一一計算,每個功能需要花費多少工時量,最後,再根據每單位小時多少費用,藉由總工時量*單位費用,便可以產出報價單了!
  • 專案怎麼估算總成本 想像一下,當你想要來場出國自助遊,你會計算需要準備多少錢呢? 首先,一定會花費的包含了:機+酒,當然了,也需要準備一些吃飯、交通、以及購物的預算,最後,為了安全起見,再帶一張信用卡好了!沒錯,大體上出國自助一般都會這樣的方式預估需要準備的金錢。
  • 待執行工作報表 有些任務我們能難定義任務完成百分比,例如:開發某項功能目前已撰寫了100行程式碼,你覺得這項任務的完成百分比是多少呢?很難定義是吧!所以在敏捷專案Agile 中,我們僅用『已完成』以及『未完成』來看任務的完成百分比。
  • 人力資源用量報表解決什麼問題 『人力資源用量表』通常會用在兩個階段,第一個階段是在專案啟動階段,專案經理先盤點專案需要哪些資源,接著完成一份『人力資源用量表清單』
  • 從一條線到兩條線 『追蹤甘特圖』與『甘特圖』最大的差別在於,『追蹤甘特圖』至少兩條長條圖,其中一條長條圖表示:專案原來預計的總工期、原來預計何時開始與何時結束,另外一條長條圖則為:任務真正開始的時間,實際上做了多少時間,還需要做多久才能完成,以及根據開始時間而推出最後該任務何時結束。
  • 以工時量來計算完成百分比 隨時掌握專案進度,並即時修正是專案經理必要的工作,藉此,像是軟體開發產界,專案進度該如何追蹤呢?在回答這個問題前,我們先考大家一個問題:『你覺得,撰寫程式10行厲害,讓還是100行厲害呢?』其實答案是…
  • 『甘特圖』(Gantt Chart) 是1917年亨利·甘特所想出來的,其實就是一條長條圖,所以甘特圖也稱(Bar Chart),橫軸表示時間,縱軸表示任務,線條表示活動計劃開始至完成的時間,下圖為利用MS Project所產出的甘特圖,長條圖顯示的為每個任務計劃的工作長度。
  • 什麼是『里程碑』?   你可以想像就像在切一塊長形的大蛋糕,由於一開始不知道有多少貴賓會吃,最簡單的方式便是先切幾大段,每一大段再根據來的貴賓進行細部切割,每一大段就像里程碑一樣的概念。
  • 當你啟動一個新的專案計劃,為了能夠讓專案發起人、高階主管、客戶或是團隊成員們清楚掌握專案脈絡,我們最常用的專案管理手法便是先繪出一份專案里程碑,根據專案管理聖經PMBOK描述,專案里程碑可用於:
  • 一、有工作沒能力=0 對於每位專案經理來說一定要學會珍惜每個專案,學會感恩每一位專案上接觸到的人。千里之行、始於足下,懂得把握機會的人才會笑到最後,有了工作如果不加以珍惜,金飯碗也會變成泥飯碗。
  • 很多人做專案經理都集中在如何把專案做完、按時完成,或者與客戶協商溝通後的時間內完成專案。雖然大家都在講控制專案成本,但很多人卻無法做到確實的控制。在排除方案談判及業務談判的時候的成本資金以外,專案經理的主要工作還是在專案實施過程中的控制。
  • 作為一名專案經理,很多工作實際做起來要比想像中的難得多,有些時候你會發現,很多工作的難度都被低估了。你一旦發現專案不能如期完成,要做的第一件事肯定是查明原因。如果不了解導致專案不能如期完成的原因就盲目的採取補救措施,這些措施是很難真正奏效的。 那麽,在知道了導致專案不能如期完成的原因之後,應該怎樣做呢?是不是應該立即通知客戶,將專案延期呢?當然不。首先,專案經理和專案小組的成員應該努力採取補救措施,使專案能夠重新回到預計的時間軌道上來。
  • 假設你是美國航空航天局(NASA)太空船專案的一名科學家,你負責計劃太空船的下一次升空。NASA所有的資源和供應商都歸你管。每個人都完全服從你的指揮。在這個專案中你實際上不需要親自做什麽,除了一件事:為升空之前所有要完成的步驟做一個計劃,並且執行這個計劃。 聽上去不難,對嗎?你覺得自己必須要考慮多少因素呢?讓我們看看:天氣,在距離地球幾千英里的高空將要和太空船相連的衛星軌道,宇航員的挑選和培訓,飛行期間要進行的實驗,還有,降落的地點,現場的人和設備,把太空船推上太空的火箭。你還需要照顧現場的做報導的媒體工作人員,控制觀眾人群。怎麽樣,這些夠你忙的嗎?
  • 當前,中國建築工程專案管理的總體水平偏低,存在許多問題:一是專案經理部在企業管理中的地位偏低,沒有用人權或沒有財權,不利於獨立、迅速地做出決策,不利於專案管理中的各種目標控制;作為專案的直接實施者和組織者,雖然有豐富的現場施工經驗,但大多停留在較低的管理水平上,缺乏先進的管理思想和管理方法,直接影響到專案成本。二是新工藝、新材料的應用不夠。一些施工企業為了單純降低材料成本,盲目地將質量好、性能高但造價偏高的材料排斥在外,不但影響了建築產品整體質量,也影響了新施工技術和工藝在工程的應用和發展。
  • 與工業生產中所強調的執行力不同,工業生產中由於規模化的原因,前期可以花大量的時間進行細化,工作步驟可以到操作層面,每個層面有具體的完成標準,然後進行規模化推廣,盡可能減少執行者的能動性,從標準化向機械化發展,通過機械化操作,減少執行者的判斷時間,從而達到提高工作效率和工作質量基本一致的目的。  
  • 一、使用敏捷開發 敏捷開發,這是現在非常時興的一個詞,聽起來挺牛的,敏捷,讓我們感覺用了它就會“快”。在被這種開發模式折磨了一年多的我想說,其實它跟其他所有的事情都一樣,它有自己適用的領域,假如錯誤的以爲任何專案用敏捷開發都能敏捷,那就是自找苦吃。 爲什麽?敏捷開發的特點就是根據用戶的需求迭代,一個迭代解决一個迭代的問題,對於一個對於架構清晰的專案來說,這樣每一個迭代都會有一些成果。而對於有些專案而言,比如說殺毒軟體,磁盤分析器等等,對於這種産品類的專案,很多時候它的需求都是一開始需要定義清楚的,客戶名義上是廣大的PC用戶,實際上是PM或是PGM,PM說這個專案裏面我們要做3個功能,那我們就需要做3個功能,多一個不行,少一個也不行,如果PGM在你做了3個功能後告訴你,要加一個功能,而且這個功能在舊的架構上是很難實現的,那麽這個PGM就是不合格的,爲什麽?因爲他加大了專案的成本。 所以,我想說的是,如果需求是由我們自己定義,而且我們很清楚要做一個什麽東西的時候了,采用敏捷開發的風險可能會加大,因爲它過多的依賴於“迭代”,認爲迭代可以解决大多數的問題,可是實際情况遠不如此樂觀!當你的PM對你我們要加這個新功能,之前的定義的功能不行這個迭代要改的時候,作爲一個程序員,我們能做什麽呢?去跟PM說,對不起,我們之前的底層架構不支持這種變態的需求,PM會告訴你,我就是代表客戶,這個功能就得這麽做,我說了算,爲什麽不支持,我們不是採用的敏捷開發嗎,敏捷開發的特點不是迭代來解决問題嗎? 老實說,瀑布模型的好處之一,就是你的PM可以少幾個變需求的理由,PM一個星期變一次需求,我們程序員就沒有幸福可言了,所以,我想勸有些專案經理,別拿需求的變更當做理所應當的,你不是一個嬌生慣養的小孩,沒有必要變的需求就不要變,如果你把敏捷開發的需求變更當做是你隔三差五變需求的理由,那下個專案,當你的程序員聽說你要用敏捷開發,肯定想抱頭痛哭。你是産品的設計師,這個産品的外觀功能,應該一開始就定義好,不要前一個月說要做個電飯煲,這個月又說要在電飯煲加個微波爐的功能,如果你手下的程序員任勞任怨,把微波爐的功能真的加進了電飯煲,那只能說PM幸運,碰到了技術牛人,並且技術確實是可行的,但是如果功能實現不了,那麽PM可能就怪開發者,覺得他們技術不行,心想我用的是敏捷開發,爲什麽我給了你們時間缺不能解决問題呢? 時間確實是可以解决問題,但是作爲開發者更希望把時間多花在需求分析階段,而不是修改舊的代碼上。開發模型只是一種工具,依賴敏捷開發這個工具,並不是解决所有問題的萬金油。 作爲專案經理,你不光要對客戶負責,更需要對産品負責,對你手下的程序員負責。其實,假如做不到後面兩點第一點也不好做到,因爲專案很可能經常delay,到最後客戶不滿意,或者産品上綫的時候早已經落於市場上其他的産品。 二、角色分配 角色分配的問題在整個軟件開發過程也是很重要的,說簡單點就是分工要明確,按照博弈論的觀點,假如我們每個人的目標都是合理的,那麽我們通過相互的制約很好的推進專案的周期,但是如果角色分配的不合理,比如說職責重複,缺少角色等等,那麽開發的過程中就會遇到很多利益衝突,解决不好,就容易導致團隊不和諧,沒有凝聚力等等,最嚴重的情况就是大家各自爲政,都聽不進別人的意見,大家都是會爲別人著想的人,但是有時候想得太多,總是會覺得不合理,不公平,難免影響工作情緒。 在我現在這個專案就有類似的問題,首先,就是沒有一個架構設計人員,經驗豐富的開發和經驗較淺的開發做的事情是差不多的,整體架構的設計名義上是大家一起來做,但是在開發過程中就發現了問題,對於一個架構變動,沒有人有决策能力,TM只會說,有問題跟我說,然後你發現了問題告訴他,他却不知道和誰來商量,經過和一個個的開發者進行了討論,認爲這個架構的變更確實是必須並且可行的時候又要開一次會,來討論怎麽來做這個變更,由誰來負責這個變更,所以說,SD是必須的。而在一次會議上我聽別人說做SD必須要有10年的經驗,我覺得有點可笑,有很多優秀的開發在很早就做上了架構師,我認識的人裡面就有一個,其實我覺得邏輯思維能力較强,有整體架構思想,並且對專案中使用技術有一定研究就可以做SD了,倒是我不明白現在爲什麽很多軟件公司都特別在乎工作年限,認爲做了10年IT就是萬金油了,什麽事情都可以解决,真是大錯特錯。 ˋ 我認爲,做什麽事情都有一個精與不精的區別,假如那句什麽語言不重要,重要的是思想,一通百通的話我覺得真是沒什麽意義。我們都知道C和JAVA.NET的側重點不一樣,一個偏向底層,一個偏向應用,讓一個做C做了10的人去做一個網站可能都做不好,爲什麽?因爲他沒有對網站應用根本就不瞭解,用戶需要什麽他都不知道,他腦袋想的只是如何使用戶體驗更加的絢,但是卻不知道網頁上能不能實現這個效果,網頁上上傳做個進度條能不能實現,實現的難度大不大,他都不知道,這樣的架構師能做好網站嗎。同樣讓NET程序員去做JAVA的事情也不一定做的好。聞道有先後,術業有專攻,這句話是有道理滴。 角色分配的問題還體現在我們不能越庖代厨,如果你是RD,你就不要過多的去擺弄需求,覺得需求不該這麽做,因爲這個問題不該你想,想這個問題只是浪費時間,如果你是PM,你就不要過問架構和技術細節,因爲你始終不如開發瞭解實際的問題,如果你是一個做了十幾年開發的PM,自己手下的技術不如自己,硬要按照自己的想法去做事,那麽不要做PM,你可以做個SD。我以前就碰到過這樣一個PM,讓我去做一個圖片處理的程序,他想讓我把一張圖變清晰,我覺得一張從100K壓縮成了10K的圖你還想讓他變清晰仿佛是不可能的事情,用脚趾頭想問題也知道那丟的90K是幹什麽的,PM要我多測試幾次,經過測試確實是不可行的,但是PM不相信,因爲他做了一年多的開發,於是中午不吃飯跑到我的機器上寫代碼,口中還念念有詞的,等我吃完飯睡好午覺,他終於認輸了,雖然如此,但是從這件事上我就覺得有點不痛快,多的就不想說了。   文章截錄:中國項目管理者聯盟 圖片來源:1 2 3   ProjectClub 專案俱樂部為一群專案經理人組成的平台,網站分享專案運作的各種專案管理手法與實用專案工具,並分享如何提昇職場人的軟技巧與硬實力。
  • 很多時候,人們都在強調執行力,專案的成敗,很多人都將最後的結果歸結為執行人的執行力不夠!怎樣的執行力才算夠?專案的成敗該不該把責任歸到執行人的頭上?專案結束後,在總結會上,往往是互相埋怨,互相指責,成為了誰都不承擔責任的指責批判會。出現了,專案的策劃人說執行人的執行力太差。執行人說策劃方案根本行不通,落不了地!誰之過?  
  • 只要流程界定清晰,專案經理就能保證專案的發展方向與最終目標相契合。廣義而言,要掌控各種類型專案的發展,首先要關注十個關鍵的流程。 一、生命周期與方法論 專案的生命周期與方法論,是專案的紀律,為專案開展劃出了清晰的界限,以保證專案進程。生命周期主要是協調相關專案,而方法論為專案進程提供了持續穩定的方式方法。 生命周期通常由專案的階段組成(包括:開始、規劃、執行/控制、完成),或由工作的重複周期構成。專案生命周期的細節一般都會隨具體業務、專案、客戶要求而改變。因此即使在同一個專案中,周期也會有多種可能的變化。對工作細致度、文件管理、專案交付、專案溝通的要求體現在生命周期標準和考核的方方面面。大專案的階段一般更多更長,而小專案的階段少,考核點也少。 與生命周期類似,專案方法也因專案而易,細節關注程度高。產品開發專案的方法經常涉及使用何種工具或系統,以及如何使用。  
  • 多專案管理是伴隨著專案管理方法在企業或政府部門等組織中的廣泛運用而形成的一種以長期性組織為物件的管理模式。形象來講,就是指在企業中同時管理、協調多個專案的選擇、評估、計畫、控制、執行,以及收尾等各項工作,使所有專案的綜合執行效果達到最優的專案管理方式。 多專案管理是通過對專案群、專案組合,以及專案的成功管理來實現的。多專案同時進行如何做好進度管理?我們從兩個不同的角度來考慮分析,你一定會有所收穫!  
  • 時間管理工作開始以前應該先完成專案管理工作中的範圍管理部分。如果只圖節省時間,把這些前期的工作省略,後面的工作必然會走彎路,反而會耽誤時間。合理安排專案時間是專案管理中的關鍵內容,它的目的是保證按時完成專案、合理分配資源、發揮最佳工作效率。“按時、保質的完成專案”大概是每一位專案經理最希望做到的。但工期拖延的情況卻時常發生。其主要工作包括定義專案活動、任務、活動排序、每項活動的合理工期估算、制定專案完整的進度計劃、資源共享分配、監控專案進度等內容。
  • 在專案實施中,要將所有活動列成一個明確的活動清單,並且讓專案團隊的每一個成員能夠清楚有多少工作需要處理。隨著專案活動分解的深入和細化,工作分解結構(WBS)可能會需要修改,這也會影響專案的其他部分。例如成本估算,在更詳盡的考慮了活動後,成本可能會有所增加,因此完成活動定義後,要更新專案工作分解結構上的內容。
  • 當你接到一個時程極其不合理的專案時,你首先該做的不是哀嚎抱怨,而是去了解為什麼這個案子會來的又快又急,是因為公司面臨了很大的困難或挑戰?還是因為策略的急轉彎?又或者是老闆純粹等不急了?了解原因你才有可能知道如何去解決當下的問題,也許你的老闆是因為看到競爭對手推出了某項服務,所以希望自己最少不要輸人,要快點把這個功能(後稱A功能)加上去,而在本來的產品規劃中,A功能是包含在1.05版裡,老闆只知道1.05版裡頭有A功能,在他的心裡認為『1.05版=A功能』,所以他是直接跟你說:「一個月內把1.05版做完上線。」
  • 你如何知道你在什麼時候能完成專案呢?很簡單,你只要在完成一個專案項目時就將它紀錄下來,那麼你就會了解你的專案還剩下多少部分沒有完成。因此,你需要一個非常具體的方式去評估你的專案進展,讓你清楚知道專案進度是否有照著專案時程走。以下提供了三個技巧,讓你能清楚了解專案資訊並確認專案進展是否有如預期地進行。  
  • 阿緯是一個初出茅廬的專案經理,透過在職進修努力考上了PMP,公司也開始將專案交由他負責,短期內即將負責三到五個大小不一的專案,面對不同團隊成員、不同時間與進度的專案,阿緯該怎麼辦呢?
  • 阿緯是一個初出茅廬的專案經理,透過在職進修努力考上了PMP,公司也開始將專案交由他負責,短期內即將負責三到五個大小不一的專案,面對不同團隊成員、不同時間與進度的專案,阿緯該怎麼辦呢?
  • 專案管理貴在如期如質完成專案範疇內的任務,但品質的好壞與時間、範疇、資源有極大的關聯,稱之為專案的三重限制。在星際效應電影中,以庫柏為首的太空人與科學家們,在sponsor布蘭德教授的遊說下,穿越蟲洞前往未知的星際去探詢適合人類居住的星球,是十年前拉撒路任務的延續。拉撒路一詞取自聖經,在新約《約翰福音》11章中記載,拉撒路病死後被埋葬在一個洞穴中,四天之後耶穌吩咐他從墳墓中出來,因而奇跡似復活。言下之意,這一趟太空任務猶如尋找奇蹟般的旅程,充滿挑戰。
  • 你如何知道你在什麼時候能完成專案呢?很簡單,你只要在完成一個專案項目時就將它紀錄下來,那麼你就會了解你的專案還剩下多少部分沒有完成。 因此,你需要一個非常具體的方式去評估你的專案進展,讓你清楚知道專案進度是否有照著專案時程走。以下提供了三個技巧,讓你能清楚了解專案資訊並確認專案進展是否有如預期地進行。
  • 小偉是一家公司的專案經理,他的工作除了需要協調與溝通專案團隊間的工作事項外,也需要隨時在專案會議上回報目前專案的進度,以往他會用Microsoft Excel 做為報告專案進度的工具軟體,因為這是他與大家都熟悉且常用的軟體。
  • 每隔一段時間,我總是會靜下心來好好規劃年度的工作目標,不管我是否能徹底確實的實踐,仍會仔細思考計畫。想著之前的履歷及面試經驗,總覺得少了一些什麼,對未來失去了方向,但是當自己再次翻閱著曾經寫下的目標,又會找回初衷,明白自己想要什麼,需要增強什麼技能才能順利的到達那裡。如果您開始思考如何把自己行銷出去,這裡有一些小秘訣幫助您的職涯尋找下一份工作更加順遂。
  • 你一天能做多少事情?你一定像我一樣,希望一天能擁有更多時間來使用。 如果你能有效地管理你的時間,那麼你將會有更多的時間可以利用。以下所說的時間管理的技巧,可以幫助你保持專注並增加效率。
  • “真是有趣!"我的團隊某位成員這樣說 "我們可以在午後期間學習事物?我相信其他人一定很樂意聽到。”這是一個很輕鬆的訓練活動,在中午或午後時間舉辦,你可以請大家帶自己的餐盒或是提供小點心。參加者聽從舉辦者指示,當他們有疑問時可以直接發言,對大部份的人來說,在活動的進行中他們可以互相分享自己的知識,對於個性相較害羞的人來說這是個大好機會,他們可以在這個迷你的聚會發表自己的意見。  
  • 前一陣子我去一家公司進行專案管理培訓時,聽別人述說一個十分有趣的案例故事,這個實務案例的背後延伸出專案團隊成員們沒有使用正確的管理手法與專案工具,最終不僅讓專案時程出現嚴重的落後,甚至專案運作到一半便已經註定失敗,到底是什麼狀況?且讓我一一述說:(基於隱私考慮,該公司的真實資料已重新撰寫過)  
  • 一個人手上絕對不會只有一個專案在進行,因此如何在對的時間做對的事情就顯得十分重要,個人如此,一整個專案的運籌帷幄更是如此。專案規劃期間,常需要針對時間與資源進行反覆的安排調整,但不比大型專案有人力調度或資金的限制,小專案若太著重事先的時程規劃及資源分配,很容易會變成多此一舉的嘴砲,或成為純粹滿足sponsor的paper work。
  • 專案名稱 : 魔戒遠征軍 專案目的 : 將魔戒投入末日火山中銷毀 專案限制 : 1. 必須小組進行,避免打草驚蛇2. 魔戒僅能交由較不受其控制心智的佛羅多保管3. 戒靈已出動搶奪魔戒,時間有限
  • 你有沒有這樣的經驗?你花了很多的時間在準備一個大專案,到後面才發現,你的專案團隊成員卻從來沒跟上這個進度,有可能你一開始就知道,但是你卻睜一隻眼閉一隻眼,團隊成員們會堅持自己一定可以完成,而沒有照著你精心編制的里程碑行走,到最後才發現這一切都來不及啦!  
  • 估算時間是專案規劃的一個關鍵要素,以下提供估算時間的十大方法供你參考。
  • 在第一階段的範疇管理中,我們大致上已經確認了我們做一件事情該做的範圍了,接下來就要看我們能否在時限內完成這項任務,因此接著要談的是時間管理,在談時間管理時有幾個詞就不能不提了:里程碑、WBS與優先順序。
  • 企業並非每一個時刻都會覺得需要專案管理, 以下我們分享七個狀況,只有在這些狀況下 企業才會覺得 需要導入專案管理
  • 當我們在運作專案時,總是會需要做很多…很多…的事,那麼,相信你一定會覺得時間不夠用,不妨建議你閱讀以下五個技巧,以便讓你省下更多的時間。如果你在專案一開始,便想省下更多時間,專案結束時你將會發現花了更多時間哦!所以,請看以下五個經典技巧:  
  • 最近時常被人問我有關專案管理工具軟體的問題,其中像是: 有需要用Microsoft Project 來管理專案嗎? 投資這些專案管理軟體何時可以回收呢? 我也想了很久到底要如何用比較簡單的方式來回答,我想到一個比較好的例子: