如何實(shí)行信息系統(tǒng)項(xiàng)目管理？

項(xiàng)目經(jīng)理關(guān)鍵在于對老板，對客戶，對合作伙伴，團(tuán)隊(duì)成員的溝通把握好"度"。以下是我的幾點(diǎn)積累，如有不妥之處，煩請指正。 一、讓老板知道，信息系統(tǒng)的項(xiàng)目是比較獨(dú)特的、漸進(jìn)的，是項(xiàng)較復(fù)雜的工程 信息系統(tǒng)項(xiàng)目,它不是硬件產(chǎn)品。具有相對可見的、固定的屬性。正因?yàn)樗目啥ㄖ菩詮?qiáng)，才具有活力。一旦接觸，就要作好打持久戰(zhàn)的準(zhǔn)備，公司所有資源要優(yōu)先供項(xiàng)目組利用。項(xiàng)目推遲驗(yàn)收，客戶需求頻繁變更也是一個(gè)重大原因。 一個(gè)公司的成功與否，很大程度上取決于對項(xiàng)目的 管理是否得當(dāng)。 二、作好項(xiàng)目范圍和項(xiàng)目目標(biāo)控制 項(xiàng)目范圍一定要用規(guī)范的文檔描述?？蛻舸蠖嗍怯每陬^描述他們心中所想，而且是相當(dāng)臨散的,尤其是政務(wù)項(xiàng)目，他們可能寫公文很在行，但是要他把需求用文字有條理的表達(dá)出來。一句話很難，就算他們提出來了,也已經(jīng)是幾周之后了。 再者項(xiàng)目范圍不清晰，隨著項(xiàng)目的進(jìn)展,項(xiàng)目組所有人員的工作熱情很容易被拖垮，雙方都覺得項(xiàng)目越作越大，嚴(yán)重超出開始的范圍、超出計(jì)劃完成日期。今天這個(gè)功能不完善,明天那個(gè)要細(xì)化。日子一久，開發(fā)工程師都有點(diǎn)懷疑自己的能力了。最好是注明是第幾期工程，項(xiàng)目范圍和目標(biāo)提出來了，同時(shí)在文檔中注明，如超出此項(xiàng)目范圍的作何處理。 一定要客戶方使用的業(yè)務(wù)科室和客戶領(lǐng)導(dǎo)簽字?；蛟S有這種情況出現(xiàn)，客戶方有推脫的理由不方便簽字，那么請說服他，這是公司的項(xiàng)目流程和規(guī)定。 三、嚴(yán)格控制客戶需求變更，告訴他并不是所有的變更都必須實(shí)現(xiàn)和能實(shí)現(xiàn) 客戶是上帝,不可否認(rèn)。項(xiàng)目最終是給客戶方使用的。我們是否發(fā)現(xiàn)，有時(shí)客戶提的需求有點(diǎn)奇異，有點(diǎn)脫離實(shí)際,或者說暫且實(shí)現(xiàn)成本很大。那么你要堅(jiān)定些，告訴他們.如按照他所做會(huì)如何如何,會(huì)帶來有成本、進(jìn)度、質(zhì)量相關(guān)實(shí)際的問題。給他們這樣的感覺，我們是系統(tǒng)解決方案提供者，關(guān)注的全局的,關(guān)鍵性的，必要性問題的解決。何況微軟還有補(bǔ)丁呢？ 對他們的需求我們實(shí)行的方針是:"全部記錄，全部評估和控制，部分實(shí)施，全部驗(yàn)收" 四、要讓客戶提供相關(guān)的負(fù)責(zé)人，整些必須的"整"事情 在實(shí)際中，有些客戶只知道把想要的東西說出來，然后要求完成日期，到時(shí)候要用上。之后好象與他無關(guān)?？蛻舴胶芸赡苁菢I(yè)務(wù)科室的工作人員, 畢竟他們有自己的日常工作。 那么，勇敢地告訴他，在上次項(xiàng)目啟動(dòng)會(huì)議上，他們領(lǐng)導(dǎo)已發(fā)表了他在項(xiàng)目中的職責(zé)。并告知他你的實(shí)際工作難處。相信他很難再猶豫和推脫了。 五、讓開發(fā)工程師"走出去",充分理解調(diào)研，面對客戶溝通 千萬不要認(rèn)為，調(diào)研是浪費(fèi)時(shí)間，調(diào)研如果方便的話，帶上女同事(嘿....嘿....別小看女同事哦)和開發(fā)工程師。我不贊成，調(diào)研人員中只有項(xiàng)目經(jīng)理和需求分析人員兩種角色。調(diào)研中的問題，要生成分析報(bào)告。并能根據(jù)調(diào)研內(nèi)容，迅速提出重點(diǎn)和難點(diǎn),及關(guān)鍵性的問題。這樣開發(fā)工程師是會(huì)將大部分精力放在重點(diǎn)模塊上，會(huì)更好地細(xì)化關(guān)鍵性的模塊。 我們每個(gè)人的理解不一樣,開發(fā)工程師更關(guān)注的編碼的技巧和功能的實(shí)現(xiàn)。開發(fā)工程師代表，參與調(diào)研可以很好地保證調(diào)研是指導(dǎo)開發(fā)，更好地的避免出現(xiàn)業(yè)務(wù)需求和開發(fā)脫節(jié)。再者讓他們切實(shí)感覺用戶的所說，所想。讓他們也了解下原來有時(shí)客戶需求表達(dá)的不清晰和多變性。平時(shí)并不是需求分析人員和調(diào)研員故意為難開發(fā)工程師。這樣比你天天喊提高產(chǎn)品質(zhì)量,站在用戶角度換位思考強(qiáng)多了。 六、作好實(shí)施準(zhǔn)備，先"跑"為"贏" 系統(tǒng)好了，要人用呀，相信只有用了，才能體現(xiàn)系統(tǒng)的價(jià)值和公司的信譽(yù)度。也只有系統(tǒng)用了，才能體現(xiàn)你作為項(xiàng)目經(jīng)理的價(jià)值。因此要想法設(shè)法，盡一切可能讓客戶先把數(shù)據(jù)采集上來。數(shù)據(jù)上來了， 主動(dòng)權(quán)就掌握在咱手里了。之后的種種修改，不再是系統(tǒng)的功能不完善了。更重要的是公司里，老板會(huì)認(rèn)為你之前所作的各種變更和修改是有意義的。切莫要把所有功能都細(xì)化，抱著等先完善好了，再上線采集數(shù)據(jù)的心態(tài)。這樣成功的可能性很小， 甚至有可能直到你離開之日，系統(tǒng)功能還在作差不多的修改，里面卻因沒有客戶的業(yè)務(wù)數(shù)據(jù)作支撐而變得毫無意義。 很多不大不小的項(xiàng)目，缺少實(shí)施方法論。我見過很多軟件公司。就只有業(yè)務(wù)員和軟件工程師兩中角色，沒有專門的實(shí)施工程師?？赡茼?xiàng)目小不覺得，項(xiàng)目稍上一點(diǎn)規(guī)模，問題就暴露了。俗話說"三分開發(fā)，七分實(shí)施"呀。 建議當(dāng)系統(tǒng)大部分功能經(jīng)過測試就可以了，先跑起來吧。一些小修改，非關(guān)鍵性目標(biāo)的，在"跑后"再作為升級處理。這樣即使某些功能不夠細(xì)化,你能可以放心的對客戶和老板說項(xiàng)目達(dá)到預(yù)期目標(biāo)了，甚至可以說成功了。 七、關(guān)于在開發(fā)過程中的用戶征求意見會(huì)議 項(xiàng)目經(jīng)理或開發(fā)公司方負(fù)責(zé)人一定要掌握會(huì)議進(jìn)展的主動(dòng)權(quán)。但凡有客戶方參加的項(xiàng)目會(huì)議，介紹完系統(tǒng)之后，客戶方領(lǐng)導(dǎo)往往會(huì)發(fā)表意見，有的是與系統(tǒng)功能有關(guān)，有的可能是涉及客戶方各職能部門的管理機(jī)制，工作流程，甚至是工作上的繁瑣。連春晚都眾口難調(diào)呀。記住,跑題了，及時(shí)把話題拉回來, 在這些發(fā)表意見中不排除有阻礙項(xiàng)目者的高論。 會(huì)議不能太長,凡是與信息系統(tǒng)有關(guān)的會(huì)議,主題切莫離開中心思想"你們開發(fā)的系統(tǒng)是什么,能為他們干什么，是怎么體現(xiàn)和優(yōu)化他們實(shí)際的業(yè)務(wù)流程"勿需太多地用演示帳戶，操作開發(fā)的信息系統(tǒng)。他們討論的時(shí)間不能太長（控制在四十分鐘左右）。會(huì)議結(jié)束后，要第一時(shí)間內(nèi)整理出會(huì)議報(bào)告，最好是開會(huì)時(shí)，有專人現(xiàn)場作Word文檔?，F(xiàn)場簽完名后，才讓他們拍屁股走人。 會(huì)議記錄之后，回到公司召集項(xiàng)目組所有成員及客戶方的支持者，對會(huì)議記錄中相關(guān)問題作出評估和控制，最后生產(chǎn)客戶需求變更評估和控制文檔。 存檔(三份,一份交于客戶確認(rèn)，一份交于公司商務(wù)部，當(dāng)然自己得留份底。到時(shí)候老板過問進(jìn)度，也好有個(gè)交代呀)。