it專案助理工作內容
it專案助理工作內容
1、 專案經理為整個專案的第一責任人。
2、 專案經理對《質量檢查報告》中的所有細則負首要責任。
3、 專案經理必須有效掌控專案開發的各個環節，協助、指導專案組成員的工作，及時發現 並處理專案中存在的問題，並對專案組成員的工作進行合理的評價。
4、 負責管理和控制專案全過程的質量、進度。分析偏差，採取糾正措施。如果發現專案實 際進展顯著偏離計劃，則及時採取糾正措施。
5、 根據專案規範建立專案組內部管理和溝通機制。
6、 可根據需要調配組內人員等資源。
7、 有權對專案組成員提出獎懲建議。
8、 專案經理負責組織需求分析工作，並組織對需求文件和需求變更文件進行復審。
9、 分配系統設計任務，包括體系結構設計、模組設計、使用者介面設計、資料庫設計等。
10、組織對體系結構設計、模組設計、使用者介面設計、資料庫設計進行評審。
11、負責組織專案開發小組會議並編寫會議紀要。 開發小組會議每週至少舉行一次 (可與項 目例會合並) ，對難點、疑點問題進行分析、解決，保證小組內成員充分溝通。
12、負責每週對開發人員的程式碼進行檢查。
13、負責提交測試版本、搭建符合實際的整合測試環境，每個專案只能有一個測試環境，開 發環境不可與測試環境混合。
14、所需提交文件： 立項後製定《專案計劃》並保證該計劃的合理性和現實性。
延伸閱讀：
IT專案經理怎樣做好專案管理
IT專案管理最重要的一項任務就是跟蹤與控制，時刻把握專案方向，保證專案計劃得以順利執行，偏差控制在可控風險範圍內。但專案總是有太多意外因素，尤其是週期長的專案，人們常用夜長夢多來形容風險會隨時間的延長而增加，所以IT專案經理一定時刻都要保持頭腦清醒，對專案無益的事情不做，對專案有風險的事情更不能做。
隨著專案的逐步開展，尤其是複雜專案：人多、事多、週期長，很多專案經理會逐漸因為個人喜好而忘記了專案的大目標，比較典型的有：技術出身的專案經理會沉迷於技術細節，大量時間花在學習新技術或者一頭悶在解決技術難題上。脾氣火爆的專案經理會因為很多不值當的事情大發脾氣，把團隊搞得烏煙瘴氣。小心眼、愛面子的專案經理會因為某個組員無意的頂撞而懷恨在心，從此總給其穿小鞋，搞得團隊拉幫結派，毫不團結。還有更糟糕的，比如愛玩遊戲的，愛喝小酒的等等。所有這些，無論原因是自身不成熟，還是管理經驗、管理能力不足，結果都一樣，那就是專案管理出問題，甚至失敗。
任何專案在開展過程中都會不斷面對機會和誘惑，專案經理一定要能明確專案大目標，才能清晰地識別哪些是使專案成功的機會，哪些是會給專案帶來風險的誘惑，才會少走彎路，早日成功。
人是需要不斷被提醒的，這由人性決定。智慧的人能夠不斷的反省從而自我提醒，愚笨的人會被挫折、外界的警示不斷提醒，這就形成了成功與失敗的差異。
有這種看法的人不在少數。根據觀察，之所以形成這種看法，一是對專案的真正概念不清晰，二是對管理的概念神話了，把管理理解成了高深莫測，非一般人能做的事情。首先有必要普及一下專案的概念。對專案有很多人下過定義，專案管理聖經PMBOK第三版(2004版)的定義是：為創造某個獨特的產品或服務，或完成某獨特的任務所做的臨時性努力。圍繞這句話PMBOK做了詳細的解釋和舉例說明，很嚴謹，想了解的請學習PMBOK。因為都是翻譯過來的定義，翻譯得過於術語化很容易把人繞進去，在國內不排除已經拿到PMP認證證書的專業人士還搞不清楚專案究竟是什麼。筆者在這裡只想用漢語最通俗的語言來說明什麼是專案和專案管理。專案，就是在限定的時間要人完成的事。記住三個關鍵字即可把握：人、時、事。
專案管理就是參與者用什麼(知識、技能、工具、方法)來圓滿地幹好這件事。明白了這些，你就會明白從日常生活的吃喝拉撒到國家管理，處處都是專案，處處都需要專案管理，也就能明白每個人都需要專案管理，也就能理解學會了專案管理將會多麼受益無窮，嫻熟運用專案管理思維將無往不勝!
但需要提醒大家一點，現在的PMBOK是把傳統制造行業、建築行業、IT行業等多個行業領域的專案管理知識糅合到了一起，大而全，但針對性不夠好，所以很多人覺得PMBOK理論化太強，學完了覺得很多東西沒用。現在國際知名的另外一套專案管理認證，IPMP是按照工作崗位能力進行了分級，也沒有針對行業進行分解。所以，無論拿到PMP或者IPMP，很多人都會有同樣的困惑。據瞭解，PMI已經準備做這樣的改進，這是一個很好的訊息。
在軟體行業，在介面設計沒有正式展現給客戶之前，所有的工作都處於需求調研階段。其實建築行業已經給我們做好了先例：客戶買房子之前是先要看看樣板房和模型的，什麼都看不到這房子你敢買麼?除非你不是自己住!而在我們所學的'軟體工程概念模型中，這是三個階段：需求調研、需求分析、概要設計。
在客戶把他們想要管理的業務模組以及與之相關的業務資料，流程，表單交付你的時候，你千萬不要把這個階段定性為需要調研結束，寫出《需要規格說明書》就可以了。大量的實踐證明，在概要設計階段所衍生出來的需求工作量是之前的5~10倍，甚至更多，因為這要看設計人員的業務溝通能力和建模水平。
有實施經驗比較豐富的專案管理人員總結說，在中國實施軟體專案，必須以諮詢方式展開：要推出自己的方案，而不能完全按照客戶來提需求作專案。這是一種很好的解決思路，但無法解決所有實施專案的難題。這種解決方案的前提，要麼專案實施者有成熟的業務模型，要麼有成熟的產品(包含了成熟的業務模型)，否則是不可能做到的。但如果沒有3~5年在同一行業，同一領域的實施經驗和理論總結，沒有哪家IT企業能達到這樣的前提要求。
其實得出這樣結論的深層原因，是因為國內多數企業管理思想不成熟，更談不上完善的業務模型，所以客戶的思維一定程度是發散的，還未形成系統。甚至還有些客戶的領導，腦子中有很多新鮮的點子，他都有可能想在企業資訊化的實施過程中加進來，這對把控專案範圍和專案實施效果來說，都可能是災難的開始。
所以，要做好實施專案，實施者必須有很好的業務建模能力，快速的給客戶展示合理的軟體原型軟體Demo。請記住：軟體實施專案，一定要給使用者看到樣板房軟體Demo，才算需求調研結束!
學以致用，就怕亂用。無論是產品、技術還是管理方法，都存在為了更先進、更科學而罔顧現實，盲目亂用的現象，結果先進和科學的技術、工具不僅未提高生產效率，卻成了累贅，這樣的情況到處都是，在IT專案中也為數不少。
國內大量失敗的ERP專案就是這類錯誤的典型。有人把ERP專案歸結為一把手工程，意思是隻有領導重視並推動才能成功。領導支援是專案成功很重要的一個條件，但絕不是有領導支援就一定能夠成功。有些專案就是領導決策失誤盲目上的，從開始就註定專案要失敗。一個資訊化專案的實施，對很多企業來說就是一場大的改革，對所有員工從思維、技能到工作習慣等多方面都需要進行調整。如果企業的員工素質不能跟上，縱然有各種各樣的培訓，但不顧員工基礎和學習曲線，使用者不能真正掌握全新的系統，結果就只能增加使用者負擔，而產生不了期望的效果。
很多IT專案經理在學習了一些新的技術後，總想立刻在專案中實踐，而不去仔細分析這些技術在這個專案中是否需要，是否適合。IT技術日新月異，不斷有新的理論被提出來，被翻譯引進到國內。有些專案經理在一知半解，對這些技術還不是很熟悉的情況下，就敢向人吹噓他所掌握技術的科學性、先進性，進而強制要求在專案中實踐。這可能是甲方的專案經理，也可能是乙方的專案經理。因為技術選擇錯誤導致專案失敗的例子在國內過去有，現在也還有!絕對不可準備不足，大範圍引入全新的技術，待到專案時間過去一半了，才發現選擇的技術不適用，那時候一切都晚了。掌握任何新東西都有學習曲線，專案的時間限制是專案經理必須時刻牢記的要素，把握不好就會給專案帶來極大風險。
涉及到具體的IT專案管理，PMBOK的知識體系可謂博大，還有一些其他新的專案管理工具，不能說不先進，但是哪些知識、工具、方法適合本專案，需要專案經理根據實情，認真分析後進行篩選使用。
科學、先進、好用等等修飾頭銜這些都不是要選擇的首要理由，需要、適用和有效才是首要考慮的事情。很多IT專案經理因為年輕，初生牛犢不怕虎，膽量大，勇氣足，敢於在實踐中引入新的工具、方法。敢於嘗試不是壞事，但試驗的風險一定要控制好。對於專案經理來說，所有的決策都要圍繞專案目標進行。專案經理的首要任務是保證專案成功，如果同時能引入新的技術、工具，增加組員的知識技能，提升專案組工作效率，提高產品的質量和可靠性，絕對是錦上添花，但絕對不能為了錦上添花而導致專案失控甚至失敗，撿了芝麻，丟了西瓜!
專案一定要盈利，這句話被無數IT專案經理奉為真理，也就註定了要創造很多悲劇!為了達到這個目的，很多IT專案經理甚至都在悉心研究厚黑學，學習用什麼辦法把小弟搞得熱情高漲，比民工累，從而用最低的成本創造最大的利潤。專案管理作為戰術層次的管理手段，一定要服務於戰略層次的大方向。商場如戰場，有勝利就會有失敗。為了戰略勝利，很多戰役要誘敵深入，必須打敗仗。敗仗不要緊，關鍵要弄清楚敗到什麼層次，損失到何種地步，明確本次戰役的真實目標，再去打這場戰役，就會做到駕輕就熟，從而不至於到最後形成不僅損兵折將，還未能誘敵深入的局面。
開拓市場、佔領市場、站穩市場、挖掘市場，這是每個公司發展必不可少的步驟。很多專案，對公司來說都是為了佔領市場，甚至虎口奪食。這樣的專案，公司從戰略層面首先要求的絕對不是盈利，而是如何能把市場佔領，繼而站穩，專案經理必須明白這個戰略意圖。
平衡是專案管理最為重要的一個思想，從過去的做好質量、時間、成本專案三要素的平衡，到現在滿足相關干係人的需求，所有的最佳實踐和理論研究成果，都絕不會提倡走極端，殺機取卵!利潤只是專案的一個目標，並且一定要明白有短期利潤和長期利潤之分，過分單一追求利潤的專案註定要失敗，過分追求利潤的公司也不會長久。
該花的錢不能省，不該花的錢一分也不要花，專案經理把成本控制在合理的預算範圍內，就是成本控制的成功。萬萬不可為了把一個註定要賠錢的專案做得盈利而想盡辦法、絞盡腦汁壓縮成本，從而讓組員加班加點，玩命幹活，到最後，專案幹完了，人也走光了，還極有可能因為趕工導致專案質量不合格，客戶不滿意，那就真的賠了夫人又折兵!專案組要能保持激情高效，不能懶散拖沓，專案經理一定要把握好這個度，絕不能走極端。平衡是一門藝術，也是展示專案經理能力水平的一個重要標尺!
怎樣才能保證專案成功?計劃，計劃，再計劃，這是專案管理的最佳實踐!所以，做專案管理的一般都知道如何編制專案計劃，並且很多人能熟練的使用 Project工具，知道80小時或者40小時法則、WBS和關鍵路徑的概念。每個專案經理都會記住計劃一旦形成，就嚴格按照計劃去執行，而不受某個人、某件事的影響這個原則，也明白這樣做不僅能夠減少大量資源的浪費，產品的質量也能得到保障。所以，很多專案經理排斥，甚至拒絕改變計劃。堅持原則，這貌似沒什麼錯，但真的這樣麼?要弄清楚一件事是否有必要做，首先就得弄清楚兩個問題：一、這件事為什麼要做?二、做了有什麼好處?
那我們首先問一下編制計劃的目的是什麼?我們知道計劃是專案管理的最佳實踐，計劃是保證專案成功的一種手段和方法，做這件事只有一個目的，那就是為了保證專案成功，但前提是，這份計劃是周密的、可行的。嚴格執行一份周密可行的專案計劃才能保證專案成功。很多專案經理記住了上面的嚴格執行原則，但忘記了這個大前提。
第二個問題，計劃有什麼好處?專案管理的計劃方法，把專案活動、持續時間、所需資源有機地結合在一起，並且有嚴格的先後次序、里程碑和關鍵路徑，可以清晰地提醒專案所有成員在什麼時間，做什麼事情，保證每個專案任務都得以執行;透過對計劃的執行跟蹤，專案經理可以清晰地瞭解專案進展情況和偏差情況，評估並及時有效的控制專案風險，從而保證專案的成功。
明白了這兩點，我們再來看IT專案。對多數IT專案，尤其是軟體實施專案，啟動時都存在範圍不夠明晰，需求不確定的情況。只有到軟體Demo產生，才可能需求清晰，範圍確定，這些情況就決定了IT專案計劃需要根據專案的實際情況及時進行修正。如何壓縮範圍確定的時間，早日製定出周密可行的計劃，是軟體專案的一個重要課題。
制定一份周密可行的計劃是專案經理優秀能力的體現，尤其是WBS的制定，對複雜專案有很大難度。在談2008奧運專案的管理體會時，專案專家曹蕾就提到奧運會專案最難的一點就是WBS的制定。要保證專案的成功，就要保證專案的每個活動都能得以順利執行。所以，在專案情況發生變化，在原有的計劃基礎上有需求變更時，就要把新的任務補充到計劃中，修正計劃，確保WBS的完整，確保計劃周密可行，之後的工作才是嚴格執行。順便提一句，有些專案經理會走另外一個極端：因為需求不確定，所以不制定專案計劃。這同樣是對計劃的錯誤理解。即使計劃不夠周密，但它可以提醒我們專案的大目標是什麼，保證專案團隊所採取的行動不偏離大方向。
任何一項大的專案，都可以拆分成很多小專案，WBS的漸進明細，也是專案必須完成的任務之一，所有任務的持續時間都是要估算的，即使不夠準確，至少可以作為經驗累積，為今後的準確估算做了準備。因此，專案的任何階段都一定要有計劃。