專案管理經驗分享
專案怎麼可能沒有目標呢？仔細想一下吧，你的專案目標明確嗎？會不會有好幾個目標？是否大家都有一致的認同？
專案應該只有一個主要的目標，過多的目標會分散注意力。超過兩個的主要目標，將會使專案組在以後的工作中難以分清工作重點，並且在某些目標不能實現時產生失落感。
如果有些目標是大家認為可以在專案過程中順便產生的，那麼就讓它自然產生好了，不要一開始把它定為專案的目標。有時公司可能需要在專案中建立規範或其他嘗試性的工作 ——最好把這些工作作為獨立的專案——如果一定要在專案中進行，那麼請注意計劃出這部分工作需要的投入。將目標儘可能的細分為明細的任務（子目標），這與多個目標不同，每個任務都是圍繞一箇中心服從統一的原則的，不會互相抵觸。
更重要的一點是，大家眼中的目標是否一致。在專案開始前一定要與公司領導和客戶（如果與客戶有關）就該問題達成絕對一致的看法，然後將這個資訊傳達到所有相關的人員。如何描述不是主要問題，可以直接交流、提交專門的報告，當然最好在正式的計劃中作出闡述。
二、 明確職責許可權
是否有崗位職責書、專案任命書？有，那最好，仔細研讀一下，明確管理的職責和許可權。
有些事是你能做的，有些是你願做的，這裡要明確哪些是你負責做的——具體的事情可能需要其他人協助或者授權給別人，但是責任還是你的。
作為管理者一定要明確你有哪些權利，而且要清楚如何利用職權（可不是濫用職權），這樣才能清楚可以採取的策略。權利很大，可以更威嚴，但是要公證；權利很小，試試多一些的感情投資。
明確的文件也好，直接的交流也好，總之最好在專案開始前確定該做和能做的事。
三、 熟悉工作流程
通常公司會有對專案管理的規範，如ISO9000或CMM或其他即定的規範，應該使自己的專案過程符合規定。
專案開始前就應該弄清楚你的一些習慣是否與公司規範有衝突。如果確實有些好的操作是規範以外的，可以在專案中將它們結合起來，或者提出來並修改規範，但不能作為違反規範的理由。
有時規範可以在許可的情況下進行裁減或調整，但前題也是你要先清楚規範是什麼。你所理解的流程會在專案中得以貫徹，所以一開始就要讓它是合乎要求的。
一般規範中都規定了需要產生的文件和其他提交項，建議在專案開始的時候就將各環節需要的文件建立好（當然只有名字和目錄），這樣在需要用時就不用到處找，也不會遺漏。
四、 掌握技術要點
如果專案是在需求明確後才確定實現的技術，那麼現在可以不考慮這個問題。不過大多數情況在專案開始時就已決定使用某種技術了。
通常專案經理可以不需要非常嫻熟的技術能力，因為可以在專案組或公司層面配置技術專家，但是專案經理還是應該對需要使用的技術有一定的理解——這樣可以理解其他專家或資深技術人員所描述的問題和解決方案，然後作出決策。
專案經理可以根據實際情況制定一個自己的學習計劃，不需要公佈，但是最好有一個明確的計劃，並按照計劃執行，否則日後忙於各種事務時就會總覺得沒時間補課——這很正常，因為開始就沒有給這件事安排時間。總是用可能剩餘的零星時間來做的事是很難有成效的，所以要對應該做的事有個計劃。
五、 瞭解人力狀況
人員其實也是一種可用資源，之所以與其他資源分開考慮，是覺得這是最重要的要素。一般專案中人員的使用是分階段的，但是需要什麼樣的人應該是開始就確定的，除非使用什麼技術還沒確定，那人員確定也必定是階段性的。
確定專案需要的人員技能，瞭解所有可用的人員資訊，根據需求選擇合適的人員組建專案組——這是理想狀況，幾乎沒見過。不過這作為一個原則還是適用的。
首先對專案組進行角色組織，應綜合考慮公司的規定、目前的技術能力、專案的時間要求等因數設計專案組的角色，確定各角色的職責和能力要求。實際上這也是憑經驗而定，沒有什麼公式可用。
然後從人力資源部，各專案組瞭解可用人員的情況，如果人員是既定的，也可以在瞭解已定人員的資訊後，多瞭解一些其他人員，畢竟你可能還有其他的選擇。
最後就是看人員是否能適用於專案組，這頗有些“按圖索驥”的味道，不過不盡然，很多時候，不可能直接找到所有合適的人，所以現在不“完全合適”的人，不一定是不可用的。如果有差距那麼相應的培訓計劃，招聘計劃就該列入考慮了。
當然，實際上遠沒有這麼簡單，人不同於零件——按照設計要求組裝之後就可以用了，要使一個團隊合理運做，發揮效益，是另外專門的話題了。
六、 把握內外資源
儘可能在專案早期明確需要的資源，除了剛才提到的人力，還有資金，裝置等等。僅僅清楚資源需求是不夠的，要明確這些資源的提供者。不可能指望提交一份“資源需求清單”，就可以等著你要的資源在計劃的時候出現，專案經理必須清楚通過什麼途徑可以獲得這些資源。
特別注意，一般總是認為客戶總是對專案提出要求的人，但是客戶也往往是能夠提供各種資源的人，比如測試環境，特殊裝置等。
七、 制定專案計劃
以上工作都完成後，可以開始完成專案計劃了，實際專案計劃就是這些資訊的固化表示。之所以讓每項工作都做為獨立的任務去完成，而不包括在制定計劃這一個工作中，是希望避免出現還沒有完全瞭解狀況就急於完成計劃的狀況。
就是因為計劃很重要，所以更不要急於寫出專案計劃。
制定專案計劃的第一個重要原則是實際：計劃要合理和可行，寫出一個大家都感覺良好的計劃，不一定是好事，應該充分考慮目前的運做能力，專案風險等因素後製定出可操作的計劃。計劃第二個原則是分步明細：很難在一開始就將所有的階段計劃細化，可以先定出階段性的計劃和細化計劃的時機，然後只細化最近步驟的內容。計劃第三個原則是描述清晰，沒有歧異。
專案計劃最好不是一個人定出（當然可以由一個人執筆），否則一定要與主要的相關人員充分交流討論後得出。最後計劃一定要通過認真的評審，得到所有相關部門、人員的認可。
相關推薦
專案管理經驗分享
一、 確定專案目標 專案怎麼可能沒有目標呢？仔細想一下吧，你的專案目標明確嗎？會不會有好幾個目標？是否大家都有一致的認同？ 專案應該只有一個主要的目標，過多的目標會分散注意力。超過兩個的主要目標，將會使專案組在以後的工作中難以分清工作重點，並且在某些目標不能實現時產生失落感。 如果有些目標是大家認
主資料管理專案建設經驗分享
一、主資料建設的術法道 隨著企業資訊化系統建設逐漸增多，領導、業務部門對資訊系統支撐決策、管控、業務執行難度也隨之提高，導致解決業務系統間的互動困難和資料多頭管理不一致等問題成為資訊化建設的難點和重點。借鑑業界成熟的資訊化建設思路，建設步驟分為三步：立標準通過資料標準化建設，達到關鍵主資料的管理制度化，資料
分享學習——ERP專案管理經驗
為什麼在實施過程中有的專案就能做的非常好，有的專案應用效果就非常差？原因在哪裡？下面本人就從下面幾個方面進行分析： 1、什麼是專案？ 2、在ERP軟體行業專案應該怎麼做？ 3、為什麼有一些專案會失敗，失敗的原因在哪裡？ 4、怎樣最大程度避免專案失敗？ 1、什
軟件項目的需求管理經驗分享
軟件項目 需求管理 做軟件項目，客戶是上帝，同時也是惡魔。在做需求管理的時候，需要謹慎對待客戶提出的每一個需求。對於一些合理有用需求需要重視，對於一些只是沒有實現可行性的理想中的需求，請果斷拒絕，並說明原由，盡可能說服客戶。下面是一個軟件項目管理者的經驗分享，希望對大家的需求管理的工作有所幫助。
項目管理經驗分享1 - 項目經理的核心競爭力
核心競爭力 連鎖 關註 需要 註意 好處 相互 永遠 咨詢顧問 項目管理並不僅僅是一種硬技能，而是一項軟實力，更重要的不是招式，而是內功！ 知識和技能並不能構成項目經理的核心競爭力，核心競爭力永遠不在招式本身，而是學會在不同的情境下，在合適的時機點，
量化敏捷專案管理案例分享
“真感謝你這幾個月幫助我們試點專案應用這專案管理工具，現在我才理解這個工具確實很適用於我們軟體開發專案的管理。下個月我會開始要求所有研發專案都使用這方式與新的專案管理模板。”——進入CMMI評估前的最後準備的第一天，技術總監對我們的顧問這樣說。 讓我們一起回顧他們公司如何結
vn.py專案安裝經驗分享
本人電腦是window7 64位系統 一定要嚴格按照順序安裝。但還是難免會遇到各種問題，我在根據教程安裝的過程中，雖然沒有遇到任何問題，但最終就是沒有辦法開啟。 安裝好後，進入之前解壓資料夾下的examples/VnTrader，雙擊VnTrader.bat，即可啟
軟體專案管理經驗點滴總結
一、研究背景 在這幾年的軟體專案管理中，一些失敗的軟體專案給我留下了深刻的印象。後來，我們結合專案管理的知識(參加了信產部《整合系統專案經理》的 培訓及美國PMP專案管理的學習)，開始反思，吸取教訓，總結經驗，並根據公司的實際情況，結合PMP的五大過程九個知識領域及CMMI
我從華為身上學到的專案管理經驗 -- 概述篇
記錄這三年，關於專案管理上的一些心得體會 – 概述篇 本文主要目的，是記錄我從華為身上學到的一些專案管理上的知識精華，記錄在案，一來供個人今後在職業生涯道路上越走越遠的時候，不時回來觀望一番；二來供奮鬥在行業前線又想了解一下的同學一起交流。個人愚見，
React 架構設計：專案實戰經驗分享
本場 Chat 我將分享 React 大型電商專案實戰經驗。技術棧涉及 React.js、Redux、webpack、Node.js、ES6，等等。大家都知道三大框架，React 的難易程度算三大框架之最，它體現了大前端新的設計理念。俗話說，三年河東，三年河西，React新的
專案優化經驗分享（四）需求與原型圖
上一篇部落格我們分享了Ajax資料交換經驗《》。今天我們來分享新增需求和產品原型工具的互動經驗：需求與原型圖！概念： 是什麼？需求：參與過軟體開發的同學應該對軟體需求（分析）有一定的瞭解，
我從華為身上學到的專案管理經驗 -- 需求篇
記錄這三年，關於專案管理上的一些心得體會 – 需求篇 對於需求，我們可以根據不同的角色、理解拆分成三個過程： 簡單來說就是： 需求分析原始需求、 需求拆分為系統需求、 需求實現為功能需求 ** 需求分析 **： 將客戶需求 輸出成
草根做專案的經驗分享一
第六：按模組做頁面或者按功能流程做頁面，這個時候可以讓測試人員和使用者進行相應的單元測試，如果有bug，提交bug追蹤文件，由專案負責人指派給相應的開發人員進行更改，更改後提交測試重新測試。這個bug記錄可以當做考核指標。
2018年3月一次性通過PMP專案管理考試取得5A的經驗分享
我自己是在2018年3月份考取的PMP證書，我們行業PMP證書對於很看重，所以領導想讓我考一個。我當時想，既然領導都讓考，那麼肯定有用，再就是說不定有晉升的機會，就去考了。我考後還把自己整理的資料集中放在這個群裡，大家也可以自己看一下有沒有用。下面是我的成績通知單。 下面說下我自己的備考技
外包專案管理五點經驗分享
目前本人在做外包專案，負責產品和專案兩方面工作。總的來說，外包專案的產品更偏向於專案管理，但內心對於產品的追求始終在。也沒有過太多專案管理的經驗，只能從個人出發，說一說自己對專案管理的一些粗俗的見解。 本次經驗分享主要有以下五個方面： 結果導向 要事第一，明確核心需求，制訂里程碑計
專案管理PMP的備考經驗分享，看我是如何60天考過PMP的？
最好的學習方式就是不斷的輸出分享，然後在從別人的想法中瞭解一些不同的觀點是我們要學習的。講講一位在我們社群裡考過5A學員的在校經歷吧，供大家參考。本人是17年12月份參加的pmp考試，很幸運以4A1T的成績通過了考試。先說我自己吧，經常在外出差，備考的時間並不是很多，總共加起
IdentityServer4系列之中文文件及實際專案經驗分享
0、前言 原文：http://docs.identityserver.io/en/release/宣告： 1、目錄一至五章節根據IdentityServer英文文件翻譯而來，有些內容會根據自己的理解來表述的（包括標題），文件的內容會不斷的更新。 2、第六章節會進行闡述在實際專案中所用的內容以及問題 &
記錄一次小型專案管理的經驗
專案背景：從IE6升級到IE11，時間長度大概為2個月，人數為3個人，內容不多，但是需要寫一些文件（詳細設計與測試結果報告書）。我帶兩個新入職的員工來完成這次的升級專案。 總結的教訓： 1.任務的劃分不夠細，沒有明確的劃分出每個人應該負責的部分，也沒有劃分到每個人每天應該完成的工作 2.即使是
汽車行業案例分享：海馬汽車選擇藍雲EasyTrack專案管理軟體
專案背景 上海海馬汽車研發有限公司是海馬汽車在上海的研發中心。 上海海馬汽車研發有限公司是海馬鄭州的全資子公司，是整車研發機構，上海海馬擁有造型、設計、試製、試驗裝置，致力於新產品的設計、產品的改進設計、樣車的試製試驗等業務，並與多家專業服務機構開展了緊密合作，形成了完整的合作團隊。 汽車研發有著技術複
SaaS管理系統開發經驗------Dva（Redux）實戰經驗分享
寫在前面 SaaS 2.1 已經開發結束了，時間早已過去了好幾個月，今天若是說從Dva基礎入門講起的話，實在沒必要 ，沒有比官網上的作者自己的介紹更專業更詳盡了，既然這個系列想說的是實戰經驗，那今天就把Dva 在實戰中總結一下，向各位大佬求證一下： Dva封裝了Redux和Redux-saga，最大