一名菜鳥IT項目經理的成長筆記

cc68 9年前發布 | 81K 次閱讀 項目經理 項目管理

是什么?

Q: 項目經理是什么?

項目經理是公司委派,負責實現項目目標的個人,是公司授權的項目負責人,是項目的直 接組織者和管理者。

Q:項目經理的職責是什么?

  • 對項目全過程進行組織和管理,按預期交付項目的成果
  • 管理客戶關系,以取得客戶對交付的成果和過程最滿意的評價
  • 管理項目團隊,使之高效而愉快的工作,并獲得最滿意的工作體驗
  • </ul>

    Q:IT項目經理的主要任務是什么?

    1. 支持售前過程。IT項目一般比較復雜,交付風險大,需要在合同中約定工作范圍,進度 計劃要估算成本和人力資源,制定切實可行的實施方案。
    2. 負責項目交付。圍繞目標,按照規范執行項目計劃。按期匯報進度,保證項目在計劃內 交付。
    3. 完成項目收尾。完成交付成果之后,要講成果轉移給客戶,確保客戶可以穩定地使用系 統。
    4. 管理干系人的關系。溝通各方人員信息,保持密切聯系,解決矛盾沖突。
    5. 管理項目團隊。尋找合適的資源,優化資源配置,建立合理的組織結構,確定清晰的職 責分工,打造高效的項目團隊。
    6. </ol>

      需要什么素質?

      1. 領導力。領導力是指通過他人來完成工作的能力。領導力并不意味著『官』,而應 該是『領頭的』。不僅要求別人做的自己能做到,而且要知道『下一步』,目標在哪里。
      2. 責任心。出于對承諾的負責,會傾盡全力達成目標。
      3. 積極主動。善于利用自身的優勢改變局勢。
      4. 壓力承受。需要在壓力中仍能保持鎮定,冷靜思考。
      5. </ol>

        需要的知識和技能

        專業知識

        • 項目管理專業知識
        • IT技術
        • 行業知識
        • </ul>

          實踐技能

          • 商務技能。要代表公司管理項目,履行合同。
          • 項目啟動。真正進入項目的第一個階段往往是最慌亂的,必須清楚知道每天要做什么,這 樣才能有條不紊。
          • 計劃的制定需要工具和平臺,執行需要推進,質量需要把控。明確質量管理內容,以及在 什么情況下有權利喊『停』。
          • </ul>

            軟技能

            • 溝通和協調。溝通包括識別溝通對象,建立溝通渠道,明確溝通信息。
            • 團隊和激勵。必須讓成員能夠團結,為了共同的目標而努力。
            • 政治和文化。
            • </ul>

              項目啟動的第一周

              項目啟動時,需要做的事情:

              • 建立組織和制度。建立組織結構,確定職責分工,確定基本規章制度和工作流程。
              • 明確工作思路。一邊是要確認工作范圍,制定工作計劃;另一邊要確定開發方法,特別是 馬上要確定需求文檔格式和工作流程。
              • </ul>

                啟動的準備工作

                1. 確認項目范圍。項目中范圍包括兩大類:一類是產品范圍,也就是應該覆蓋的業務 需求;一類是為了實現項目目標所需要完成的工作。
                  將功能層級進行約定:

                  • 子系統:指相對比較獨立、功能完整一組業務功能。
                  • 功能集:指在子系統內,按照業務特性歸集的一組操作。
                  • 執行單元:一次完成的一個獨立業務操作。
                  • </ul> </li>

                  • 粗略工作量估算
                  • 人力資源的配置
                  • 確定開發過程。按照項目的實際情況,制定一個《項目開發過程》的文件。明確項 目的開發階段,明確各階段的交付物,制定交付物的模板。
                  • </ol>

                    群策群力,制定項目計劃的方法

                    • 根據WBS方法指定活動清單。
                    • 確定活動之間的依賴,繪制網絡圖。
                    • 根據網絡圖的依賴關系和工期需求,分配資源,確定進度計劃和資源計劃。
                    • 根據資源和進度計劃,制定項目預算。
                    • </ul>

                      通過需求矩陣,進行具體項目管理

                      需求矩陣按照子系統、功能集和執行單元的結構列出所有的功能需求,每列對應每項工作的 工作步驟以及每個步驟的工作量。

                      一名菜鳥IT項目經理的成長筆記

                      制定活動清單

                      計劃過程的步驟如下:

                      一名菜鳥IT項目經理的成長筆記

                      排序和網絡圖分析

                      有了活動清單和依賴關系,就可以進行排序了。我們可以使用節點表示任務,用箭頭表示依 賴關系。

                      一名菜鳥IT項目經理的成長筆記

                      通過對網絡圖進行分析,可以得到項目與時間相關的一些重要信息:

                      • 給定項目的預計和開始時間,能夠計算每項活動必須開始和完成的最早時間。
                      • 給定項目的要求完工時間,能夠計算每項活動必須開始和完成的最晚時間。
                      • 確定項目的關鍵路徑,也就是最長活動路徑。
                      • </ul>

                        資源和進度計劃

                        進度計劃是將工作計劃安排到日歷上,它不僅規定了整個項目各個階段的起止日期,還規定 了所有項目的開始和結束日期。可以使用甘特圖進行項目中的進度管理。

                        進度計劃排定時,重點考慮兩點:

                        • 資源的使用情況是否合理,是否存在資源沖突的情況。
                        • 對于那些有較大浮動時間的活動,可以初步確定是越早開始越好,還是越晚開始越好。
                        • </ul>

                          執行和檢查

                          對于辛苦制定地計劃,如何讓每個人按照計劃工作?如果知道每個人的工作進展?

                          阻礙計劃落地執行的原因

                          主要計劃落地的主要原因有兩點:

                          • 沒有將計劃細分,個人和計劃之間缺少一個橋梁。但是將計劃拆分到每天做什么也不現實, 所以,這里是一個工作的難點。
                          • 執行項目的人員之間水平有差異。
                          • </ul>

                            任務的分解和委派

                            為了解決上述問題,初步有了以下方案:

                            一名菜鳥IT項目經理的成長筆記

                            1. 每組安周一周作為單位指定落實到個人頭上的計劃,制定一份一周工作計劃表。
                            2. 一周工作計劃表每天檢查,如果出現了異常,隨時修改。
                            3. 周五大家根據一周的工作內容,整理工作周報。
                            4. </ol>

                              這個方法是不錯。但是如果將工作分解到每天的粒度呢?

                              基本思路是將工作按照工作的流程,分解為『關鍵步驟』,每項任務的一項關鍵步驟,作為 一個人的工作任務,也是最小的管理單元。個人工作任務只有『完成』和『未完成』兩種狀 態。

                              檢查和調整

                              為了有效控制和掌握進度,檢查和調整是很重要的一個環節。

                              每日記錄

                              每天下班前,可由相關人員自己在標記當日工作計劃的完成情況,有完成、延遲完成和延遲 中三種狀態,并進行匯總統計。并且可以提出自己的問題,由相關人員討論解決問題或者安 排時間專門討論。

                              周例會

                              周例會檢查和調整項目計劃,需要一定的討論,討論的重點是:任務完成了嗎?沒完成的原 因是什么?怎么調整?

                              質量管理

                              管什么?

                              經過多年的發展,質量管理已經有了一套基本的理論和方法。質量管理包括質量保證和質量 控制兩大類。質量保證是指在項目過程中實施的有計劃、有系統的活動,確保滿足相關的標 準,典型的例子是評審和審計。質量控制是指采取適當的方法監控項目結果,確保結果符合 質量標準,典型的例子就是測試以及之后的缺陷跟蹤。

                              在IT行業軟件開發領域中,常見的公認的質量活動包括:配置管理、評審、測試以及缺陷跟 蹤。

                              • 評審:檢查項目中間產品,早期發現缺陷以減少后期項目返工和修改的工作量。
                              • 測試:直接檢測軟件產品中的缺陷,確保符合質量要求。一般通過單元測試、集成測試、 系統測試和性能測試實現。
                              • 缺陷跟蹤:記錄和追蹤缺陷從發現到解決的整個過程,確保所有的結論都有結論。
                              • 審計:對項目工作過程進行檢查,確保所有活動按照規程進行。
                              • 變更控制:版本本更控制,也是重要的一環。
                              • 配置管理:記錄中間和最終產品(配置項)的變更歷史。
                              • </ul>

                                質量經理在項目中的職責如下:

                                • 貫徹公司的質量管理規范,負責質量管理過程中的檢查和指導。
                                • 負責制定項目開發/測試環境的標準和規范。
                                • 負責項目的配置管理,通過權限控制和備份機制確保交付物的完備和安全。
                                • 負責組織同行評審,確保中間交付物的質量。
                                • 制定測試策略和測試計劃,組織測試,確保最終交付成果的質量。
                                • </ul>

                                  項目配置管理

                                  項目配置管理是一項看不見的財富,可以在無形中減少因為版本意外等開發中出現的問題導 致的返工、重做等資源浪費。

                                  Q: 什么是項目配置管理?

                                  配置管理是在某一特定時點,確定軟件配置的一個過程,通過對已標識的軟件配置的一個過 程,通過對已表示的軟件的配置的變更進行系統控制,從而在整個軟件生命周期中保持軟件 的整體性和可追溯性。

                                  Q: 配置管理的具體要做什么?

                                  通常來說,軟件配置管理主要通過計劃、標識和控制變更和發布配置狀態報告來協調軟件開 發,目的是使錯誤率達到最小并最有效地提高生產效率。

                                  質量評審

                                  評審的目的是盡早發現問題,一團和氣的評審會完全達不到發現問題的目的。

                                  Q: 評審中的角色有哪些?

                                  首先要把評審中設計到的各個人員確認下來。評審過程中涉及的角色主要有四種:責任人、 主審人、評審專家和記錄員。

                                  主審人要先選定評審組的成員,然后再做評審的前期準備。在 評審過程中保證規范和高效, 評審結束后要將結果及時發布被評審相關人員。最后,還要對 評審中發現的問題追蹤,直 到問題關閉。

                                  責任人就是要被評審的對象。他們在評審之前準備好資料,在評審過程中解答提出的問題。 對于發現的問題要積極修正后提交給主審人。

                                  記錄員就是在評審過程中,把專家提出的問題都記錄下來,還要記錄責任人的回答信息,最 終要行程會議紀要,并且記錄評審結果。

                                  評審專家要徹底了解被評審的資料,其任務是尋找這些資料中的缺陷,側重于發現問題而不 是解決問題。要保持客觀。

                                  Q: 評審的過程是什么?

                                  評審的過程分為計劃、預備會議、準備、評審會議和追蹤幾個階段。

                                  • 計劃階段與項目計劃同步,也就是說項目中有哪些要評審在項目計劃中就已經提前定義好 了。
                                  • 預備會議,針對要評審的資料對評審組進行培訓,并討論評審資料。
                                  • 準備工作,是評審專家要徹底熟悉評審資料,以保證評審的質量和高效。
                                  • 評審會議,是主審人和評審專家對項目資料中的錯誤和缺陷進行確認。
                                  • 跟蹤,主審人要確保責任人采取必要的措施修正發現的錯誤。
                                  • </ul>

                                    一個評審反饋表如下:

                                    一名菜鳥IT項目經理的成長筆記

                                    讓測試深入人心

                                    保證質量最有效的措施就是測試。

                                    Q: 為什么要有多種測試呢?

                                    不同的測試是針對不同的開發活動來設置的。下面是軟件測試的一個『V模型』:

                                    一名菜鳥IT項目經理的成長筆記

                                    • 單元測試,主要是開發人員對編寫的代碼進行自測或相互進行交叉測試,用以檢查代碼是 否符合編碼規范,是否存在邏輯錯誤。
                                    • 集成測試,將經過單元測試的模塊組裝成完整的程序。工作任務包括制定集成測試策略, 確定集成測試步驟,設計集成測試用例,然后逐一添加模塊進行測試。
                                    • 系統測試,是為了驗證需求分析確定的功能是否被正確的實現,同時還要對安裝、部署、 適應性、安全性、界面等非功能性需求進行測試。
                                    • 性能測試,用來測試系統是否滿足規定的性能需求。性能測試通常選擇一些典型的功能, 檢驗這些功能在大量用戶同時使用時是否穩定。
                                    • 用戶驗收測試,目的是驗證需求與系統的匹配性,以及界面的友好性,響應時間等等。
                                    • </ul>

                                      缺陷跟蹤

                                      Q: 為什么要進行缺陷跟蹤?

                                      缺陷跟蹤可以記錄測試結果,確定代碼質量,是確保問題得到解決的一個關鍵流程。其目的 是規范評審、測試、試運行等過程中發現缺陷的更改活動;跟蹤缺陷處理的各個環節、避免 缺陷修改失控和遺漏;如實的反映缺陷處理過程。

                                      Q: 怎么進行缺陷跟蹤?

                                      缺陷跟蹤的起點是各種發現缺陷的活動,發現缺陷之后就進入了缺陷的跟蹤流程,包括提交、 判斷、分發、修改、復核和關閉幾個關鍵步驟。

                                      缺陷跟蹤除了記錄和跟蹤缺陷的修復過程,很重要的還有對缺陷進行分類、統計和分析。

                                      缺陷的類型一般分為一下幾種:

                                      </tr> </tbody>

                                      </tr>

                                      </tr>

                                      </tr>

                                      </tr>

                                      </tr>

                                      </tr>

                                      </tr>

                                      </tr> </tbody> </table>

                                      缺陷的嚴重性說明了缺陷給最終交付的系統或者產品可能造成的影響程度。其中A級影響程 度最大,E級最小。

                                      缺陷類型 描述 可能的缺陷來源
                                      用戶界面 用戶界面顯示或者操作存在問題 詳細設計
                                      架構 系統存在架構方面問題 架構設計、概要設計
                                      接口 系統內、外部接口錯誤,不能正常連接和工作 架構設計、概要設計
                                      業務功能 業務功能不完善、未實現或者出現錯誤 需求分析、需求規格
                                      系統功能 與業務無關,但是系統必須實現的功能不完整、未實現或者出現錯誤 架構設計、概要設計
                                      性能 系統的響應時間、吞吐量、并發量等不滿足需求 架構設計、概要設計、編碼
                                      可重用性 不滿足被其他系統或者模塊復用的要求 概要設計、編碼
                                      可移植性 不滿足可跨平臺移植或者部署的要求 概要設計、詳細設計

                                      </tr> </tbody>

                                      </tr>

                                      </tr>

                                      </tr>

                                      </tr>

                                      </tr> </tbody> </table>
                                      來自:http://yuez.me/yi-ming-cai-niao-itxiang-mu-jing-li-de-cheng-chang-bi-ji/

                                       本文由用戶 cc68 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
                                       轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
                                       本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!
                                      嚴重性等級 描述
                                      A級(系統級) 系統整體崩潰,或者不能穩定地連續工作
                                      B級(應用級) 部分應用或者子系統不能運行,或者不能穩定地連續工作
                                      C級(業務級) 導致業務流程終止,或者因結果錯誤、數據不一致失敗;因安全、容錯性和性能問題等非功能性問題影響使用
                                      D級(操作級) 不易于學習使用,界面操作困難;難以理解而不容易使用
                                      E級(文檔級) 安裝手冊、操作手冊、在線幫助等文檔不能提供幫助或者存在錯誤
sesese色