<div id="uxblo"></div>

<progress id="uxblo"></progress>

      <div id="uxblo"></div>

        <em id="uxblo"></em>
          <div id="uxblo"></div>

          業務咨詢:13759956002,18009217775
          加入收藏
          設為首頁
          新聞中心NEWS
          聯系我們CONTACT
          西安市吉祥路169號太白新苑D座10樓D戶
          18009217775,13759956002

          IT項目管理經驗分享

          發表人: 發表日期:2015-11-04 來源:

          項目管理pmpit經驗軟件管理

          項目開始階段是一個最重要的階段。項目經理在接手一個新項目的時候,首先要盡可能地多從各個方面了解項目的情況,如:

           1.這個項目是什么項目

          具體大概做什么事情,是誰提出來的,目的是解決什么問題。前期了解情況的工作越詳細,后面的驚訝就越少,項目的風險就越小。

          2.項目干系人識別

          如投資方、具體業務干系方、項目建成后的運營方、技術監督方等等,很多項目里除了業主單位的結構很復雜以外,還有一些其他單位也會牽涉進來,如項目監理公司、業主的行業主管機構等。項目經理需要了解每個方面的人對這個項目的看法和期望是什么。事先了解各個方面的看法和期望,可以讓你在做項目碰到問題的時候,就每件事情分析哪些人會在什么方面支持你,哪些人會出于什么目的反對你,從而提前準備聯合朋友去對抗敵人,讓事情向你所希望的方向發展。沒有永遠的朋友,也沒有永遠的敵人,只有一致的利益,這句話作為項目經理是一定要記住的;

           3.了解自己公司對這個項目的看法

          首先是高層領導是否重視,這個決定了你在需要資源的時候,公司是否會根據你的要求提供最有力的支持。領導口頭肯定是說支持的,你需要做的是了解公司對這個項目的實際期望,是想把項目越做越大還是想賺錢?是想做樣板工程還是干脆想敷衍了事,公司領導對項目的態度決定了你做這個項目的戰略,而這個戰略方針將對你做項目計劃產生直接的影響;
           4.了解項目對于資源的要求

          首先是時間,往往很多項目要求在幾乎不可能的時間范圍里完成。對于這一點,你在做項目的風險控制計劃的時候要充分考慮。其次是人員,根據項目預算和已往經驗,大致計算一下未來的項目小組有多少種角色,每個角色目前公司是否有人,是否能完全歸這個項目使用,是否需要另外招聘一些人員,招聘的準備工作要盡早啟動。最后就是一些設備的準備,項目所需大件關鍵設備要盡早預定,以后不管發生設備等人還是人等設備的情況,浪費的都是你的時間;

           5.項目說明書

          一份好的項目說明書不僅將要做的事情描述得很清楚(主要是講做什么,而不是說怎么做),而且把如何檢查也說明得很透徹。也就是說它不僅說明白了要做哪些事情,也讓客戶的業務人員(一般不懂技術)知道項目做成什么樣就算完成了。簡單地說,項目說明書描述項目做哪些事情和每件事情做到什么程度以及如何檢查每一個結果。
           6. 與自己公司及客戶進行資源溝通

          在做計劃以前,你還需要和你的經理及客戶充分溝通資源的問題。因為很多資源是還不明確的,你需要寫一份報告,詳細分析這個項目的風險以及對資源的需求情況。如果一些問題不能得到解決的話,將發生什么樣的后果。如果資源不夠,就要高層改變策略,增加對這個項目的投入。甚至在條件許可的情況下,有些公司會放棄這個項目。總之,沒有人能完成一個不可能完成的任務,如果項目經理不能盡早發現風險,那么就只能去當烈士了。

           7.成立項目小組

          很多項目經理都沒有自己選擇組員的權利,那么,就盡量發揮你的影響力去尋找那些你想要的人吧。成員的組成根據項目不同,相差較大,很難有什么具體要求,但是,一定要有精通客戶業務的人,很多小項目里,這個人就是項目經理本人,大項目里會配備行業專家(Industry expert),這樣和客戶溝通起來才不會雞同鴨講,雙方才可以相互理解。我經常看到的情況是我們的技術人員和客戶交談時滿口的專業術語,結果搞得客戶一頭霧水,反過來,他還指責客戶不懂技術。其實,明白自己想做什么的客戶已經是很好的客戶了,不知道自己要做什么,更不懂怎么做還要指手畫腳的客戶到處存在,但是要明白,是客戶選擇了你,而不是你選擇了客戶,有了客戶你才有工資拿,心平氣和一點吧。

           8.與三群人溝通:你的領導、你的組員和你的客戶

          和這些人溝通,讓他們知道你打算怎么做,什么時候要他們做什么準備這些事情將是你的主要工作。既然溝通這么重要,那些事先定義一下溝通的原則也是一件很要緊的事情。很多溝通原則都是潛規則,如果你在一個部門時間做長了,對這些規則的運用覺得是一件理所應當的事情,但是,你現在面對的是多個部門甚至多個單位,不把溝通規則說清楚,你以后就會吃虧。

          9.項目計劃

          首先是找幾個關鍵組員,比如客戶業務專家、系統分析員等等,做一下項目模塊劃分工作。項目分成幾塊去做,每一塊完成什么,模塊之間的信息如何交換等等。需求定義的是做什么的問題,而這里說的是怎么做的問題。這里要強調一點:完成一個目標有很多種方式,你要選一種你最熟悉的,而不是看上去最完美的,這個思路會讓你的項目減少很多風險。有時候客戶會被某種新技術打動,堅持要你采用那種新技術,你就應該告訴他:你選我做這個項目,就應該容許我采用自己最喜歡的方式做事情,新技術之所以有誘惑力,就是因為吃虧的人還不多,我不希望你成為第一批受害者。

          采用一個計劃會讓你的工作更加明確,比如用微軟的Project軟件,你填寫完表格以后,就可以知道這個項目有多少件事情要做,每件事情需要什么資源,他們之間的前后關系如何,消耗的時間有多長,完成后有什么標志等。所有的結果最后用一個叫做干特圖的形式表現出來。你做完這個表以后會驚奇地發現,干特圖上項目的結束時間會遠遠落后于你的計劃結束時間(簽合同的人永遠不會先征求你的意見的)。當然,學過項目管理的人會大談什么WBS、優化路徑之類的東西,但是我的經驗是你再優化也不可能把這些東西安排到計劃的時間結束。如果你沒碰到這個問題,在我恭喜你挑了一個輕松活之前,請你再去確認你是否羅列了所有要做的事情和正確評估了他們所需要的時間。這時候,你就要考慮犧牲一些任務的時間(也意味著質量)了。按照什么標準犧牲?這個項目的戰略!我們在第三節提到過的戰略。我的經驗是如果你什么都趕進度,其結果可能就是十件事情你一件也沒做好,想想多么失敗啊。所以,把資源投到你熟悉和有把握的事情上,最后的結果是十件事情,你有三件做成了精品,三件完成,還有四件因為某些原因延誤,成績單是否靚麗了很多呢?戰略決定優先級,而正確排列事情的優先級是一個項目經理能力的主要體現。

          10.項目實施階段。

           項目經理這段時間的主要工作是保持和客戶領導以及自己領導的溝通。和客戶領導溝通時特別要注意,除非你需要對方給你支持,那么你才需要講得具體一點,否則,告訴他一切正常就可以了,而且態度要積極一些,千萬不要說一些領導不懂的細節,除非他是一個技術高手,你需要他的技術經驗,否則一般就匯報進度是否正常以及有問題時你的對策和打算就可以了,有些需要他支持的地方,比如資源調用需要說詳細一點。

          和組員開會,除了一些項目進度跟蹤會議以外,還有很多討論會,需要大家用頭腦風暴方法給出解決問題。與會人員很多都是技術人員,他們的特點是注重細節、缺乏大局觀、有點消極悲觀、自尊心強(如果總結得不對,歡迎大家拍磚),所以,你作為會議的主持人,只要負責提出問題和記錄下他們的觀點,千萬不要做評判者的角色。一個問題,有很多方面,從不同的角度看,現象是完全不同的,想想盲人摸象的故事吧。這些技術人員,他們往往精通一個方面,就自己的角度發表見解,除非一些很特別的情況,你都應該認為,他們提出的方案,從他們的角度來看是最合理的。你的長處是掌握事情的優先級,評估各個方面的輕重緩急,從而根據他們的意見得出一個合適的(而不是正確的)方案。所以,在會議上,你要充分尊重每一個人和他的意見,夸獎那些意見提得比較好的人,千萬不要把會議帶入無休止的爭論(你要讓大家知道事情不是非黑即白的,而是多元的,唉,我們的教育惹的禍…)。會后,你自己寫文檔,做決定。會議上大家的面子都被照顧了,自己實施起來的阻力就小,如果還有意見的,你就私下找他聊,如果還不能說服他,你就要讓他明白,因為你負責這個項目、你擔當風險,所以,這個優先級應該你來判斷。組織中的高層,并不見得水平會比一般的成員高,但是,他要承擔組織的風險,加之信息的不對稱性,所以,對事情的優先級的判斷肯定比下屬強。

          在開發過程中,內部管理還要注意的一點是時刻強調以驗收為目的的思想,每個任務的最終可交付成果一定要是可以被檢查的,比如,【界面要求:美觀大方、簡潔明快】,這個要求我就不知道如何檢查。所以,給開發小組布置任務的時候就要考慮如何檢查結果。時刻考慮如何檢查結果、如何向客戶交付是項目經理一直要注意的事情,我聽說有些老項目經理拿到項目是倒排計劃的,即首先看如何驗收和驗收標準,然后決定工作計劃。很多項目開始了很久,還不知道如何驗收,那么這個項目出問題的可能性就很大了。做項目就是為了驗收,我們的角色不是研究機構,我們的目的就是在付出那么多勞動后得到結果。
          11.需求變更

          變更通常分為兩種:一種是部分更改了原先的目標,即需求變更;另一種是沒改變目標,但是客戶不滿意目前的實現方式,大到流程的實現,小到界面的布局,都是屬于這類。碰到這種情況是難以避免的,主要是事先溝通的不夠充分和客戶隨著項目的進展,慢慢想清楚了問題,改變了以前的思路。這時候,如果需要改并且你的戰略是容許這種情況的,那么注意下面幾點:

          1. 確保以前的文檔,就是記載著以前的結論的東西,客戶是否簽過字,如果沒有,趕緊把你的工作停下來,趕快再和客戶自己確認一下你的方案,然后讓他簽字,避免以后說話沒有憑據;
          2. 和客戶坐下來,自己探討他修改的根本目的是什么,是不是有同樣能達到相同目的,但是對你來說有代價更小的選擇?
          3. (項目初期的工作)明確更改流程,一般是客戶指定一人簽字(否則客戶每個領導都有權力來插一杠子,你就廢了),以正式項目文件的方式提交給你,然后,你做評估分析,分析對成本、進度的影響,在你的領導同意后,出相應意見書,主要是要說明更改設計的原因和指出由此帶來的不確定后果(這個東西先寫出來,后面如果真的發生了,至少不是你的錯)。然后再讓客戶在上面簽字。見過醫院給病人做手術以前讓家人簽的免責條款嗎?對,就學習那個,讓大家都意識到任何的更改都有成本和代價。

          12.客戶培訓、系統驗收階段

            一、給客戶做培訓前,多注意一些表面功夫。很多程序員認為,系統的邏輯核心是否正確是關鍵,至于界面如何,界面上的用詞是否準確,那是無關緊要的問題,而且培訓的時候也是信手拈來,想到哪里說到哪里,下面聽講的人不知所云,云山霧罩,培訓效果自然可以想象。我的體會是,給客戶做培訓的版本,如果你在做多次測試以后仍然不能確定邏輯是否合乎要求,那么,你至少要在界面上多花一點功夫。注意每個界面的布局、用詞、鏈接的正確性等等,總之不要讓客戶看到一些他不該看到的東西。文檔方面,準備至少兩個文檔:用戶手冊和培訓手冊。這兩個文檔的內容很多都是一致的,但是角度完全不同。用戶手冊往往是站在系統設計者的角度,按照自己的思路,分模塊講解系統的操作和功能;而培訓手冊,一定要站在客戶業務人員的角度,根據每個角色面對不同業務的辦理,如何通過使用本系統的一系列功能來實現目標。所以,第一次培訓以前,系統界面是否完整正確、培訓文檔是否完備都是很關鍵的因素,第一炮打不響,以后就麻煩很多。

          作為項目經理,其實腦子里就是幾樣東西:做哪些事情、做到什么程度、怎么交貨、手上的資源以及各個事情的優先級。所謂多快好省,這四個方面都是相互矛盾的。考慮問題的輕重緩急方面,往往是把快放在第一位,各方領導都會給你最后期限,所以保進度是第一位的;省是第二位的,企業的根本目的是盈利,如果收入不能增加的話,至少費用要控制住;好是第三位的,沒辦法,誰都想精益求精,但是,沒有強大的資源保障,質量只好先犧牲了;最后是多,客戶的要求源源不斷,如何降低客戶的期望值,讓他們從理想回到現實也是項目經理的分內工作。
           驗收前,除了做好文檔工作,即可交付成果以外,多花時間搞清楚客戶的做事情流程是很重要的事情,這些在前面已經有所提及,這里就不再多說。
          我對驗收最大的體會就是舉證問題。即千萬不要讓客戶這么想:你必須有證據證明你的系統是沒問題的。這樣你就沒戲了,微軟那么多天才,做了XP還天天打補丁,要你的程序沒問題,既不可能,你也沒辦法拿出證據。你要讓客戶明白,所謂驗收,就是我按照測試文檔的測試用例跑一遍,結果和預期結果一致就應該算通過了,而且還容許有一些小錯誤留在驗收后改正,他可以對測試用例提意見。所以,驗收前雙方要確認測試計劃和測試用例。如果他認為系統不符合要求,那么他應該舉證,證明這個系統和最初設計相背離的。所以,參考法律概念,千萬不要舉證倒置。另外,認為系統完美了才能驗收的想法也是錯誤的,軟件開發合同里一定要注明驗收以后維護期的費用問題,否則,客戶擔心一旦驗收就得不到你們的支持,自然不配合驗收,那么,你這個項目經理就很難交功課了。

           

          广东十一选五人工计划