外企項(xiàng)目管理個人經(jīng)驗(yàn)總結(jié)(編輯修改稿)
2025-05-09 06:08 本頁面
【文章內(nèi)容簡介】 用以下體系管理不良，共同對有問題的事項(xiàng)采取有效的對策。有 在原處發(fā)生的 原處固有 通常的錯誤 （1）性能衰減/修改不徹底 （2）問 挪用處也有關(guān) 通常的錯誤 （3）*性能衰減/修改不徹底 （4）*題 在挪用處發(fā)生的 在挪用處發(fā)生的 通常的錯誤 （5）性能衰減/修改不徹底 （6）固體潛在不良 在原處已發(fā)生 （7）*在挪用側(cè)未發(fā)生 （8）** 適合對方，要取得修改內(nèi)容的同步圖1 問題的分離體系事例：在程序挪用處發(fā)生了不良時，輕率的判斷為時挪用處的特有不良而不通知原處，使原處也發(fā)生了同樣的故障。反之，也是如此。質(zhì)量管理題目對必要的工程進(jìn)行必要的檢查，采取必要的體制解說： 進(jìn)入綜合測試，檢驗(yàn)階段后，每天早晚都要追蹤對不良的調(diào)查和對策狀況。 如不進(jìn)行上述工作，就不能把握系統(tǒng)的質(zhì)量，最終成為項(xiàng)目混亂的原因。 定期檢查，決定調(diào)查人和調(diào)查的優(yōu)先順序，防止發(fā)生混亂十分重要。事例：在體制夠的情況下，由于工作集中于某個人而使工作效率低下，另外，一個人兼顧多項(xiàng)工作而造成項(xiàng)目混亂。質(zhì)量管理題目質(zhì)量不好的程序要下決心返工解說： 質(zhì)量不好的程序要下決心返工。 質(zhì)量不好的程序即使多次修改也不能完全排除不良（成為公司外的故障根源）。 此時，應(yīng)下決心撤換程序制作者，重新編制程序，消除后患（以達(dá)到高枕無憂之目的）。事例：從工作量，維護(hù)等方面考慮，對質(zhì)量極差的程序進(jìn)行修改倒不如從頭重編更合適。質(zhì)量管理題目雜亂無章的質(zhì)量提高是無意義的，要抓住重點(diǎn)。解說： 只籠統(tǒng)地說“要提高質(zhì)量”是不會有什么效果的。 編程序的人總是認(rèn)為自己的產(chǎn)品沒有錯誤，應(yīng)該在對不良進(jìn)行了分析的基礎(chǔ)上決定重點(diǎn)，然后再開始提高質(zhì)量的作業(yè)。 此時，設(shè)定的觀點(diǎn)未必都很準(zhǔn)確，但一點(diǎn)點(diǎn)地檢查，通過的部分不斷地積累，質(zhì)量好的程序逐漸擴(kuò)大。另外，例如，即使設(shè)定的觀點(diǎn)不準(zhǔn)確，也可能會在此過程中發(fā)現(xiàn)很多觀點(diǎn)以外的不良。事例：在無周密計(jì)劃的情況下去提高程序質(zhì)量，其結(jié)果往往是花費(fèi)的勞力多但質(zhì)量不穩(wěn)定。這是因?yàn)閷ο嗤臋z查沒有作記錄而多次重復(fù)實(shí)施同一想法所造成的。人員管理題目有計(jì)劃地統(tǒng)一項(xiàng)目的方向，目標(biāo)解說： 有計(jì)劃地相互交流，統(tǒng)一方向目標(biāo)。 定期例會 ○ 組長會 都作為定期例會每周開一次。 副組長會 另外，應(yīng)每月1次把大家召集 ○○○○ 小組長會 在一起溝通思想。 ○○○○ ○○○○○ 其他除上述定期例會外，還應(yīng)定期召開各種專題（工程，質(zhì)量，作業(yè)等）會。事例：由于組長和組員的意見，步調(diào)不統(tǒng)一而導(dǎo)致返工作業(yè)多，挫傷了組員的工作積極性。人員管理題目缺乏有經(jīng)驗(yàn)人員的項(xiàng)目要充分利用原型開發(fā)解說： 在幾乎都是由無經(jīng)驗(yàn)者組成的軟件開發(fā)項(xiàng)目中應(yīng)先行開發(fā)原型系統(tǒng)以求強(qiáng)化技術(shù)力量。在都是由無經(jīng)驗(yàn)者組成的軟件開發(fā)項(xiàng)目中，如果一開始就開發(fā)正式軟件，不但進(jìn)度慢，而且不能保證質(zhì)量。因此，在有了一定的規(guī)格時，可將其基本部分抽出來作為原型系統(tǒng)先行開發(fā)。這樣可事先強(qiáng)化項(xiàng)目人員的技術(shù)力量，以便在開發(fā)正式軟件時可以原型系統(tǒng)為基礎(chǔ)，有效地利用其經(jīng)驗(yàn)。事例：對于全都是無經(jīng)驗(yàn)者的項(xiàng)目人員來說，一切都是新的工作，會陷于試驗(yàn)性錯誤狀態(tài)，不能按計(jì)劃開發(fā)出符合要求的軟件產(chǎn)品，造成大混亂。（結(jié)果，到期不能交出確保質(zhì)量的軟件產(chǎn)品，給用戶添麻煩。）事件管理題目事件管理要由總管者日程化解說： 對于系統(tǒng)開發(fā)中的問題和要研究的事項(xiàng)等，如果個別處理，則無法取得它們之間的同步聯(lián)系而發(fā)生故障。 規(guī)格總管部門要按期將所有事件匯總在一覽表中，分析判斷它們的關(guān)聯(lián)，排成日程表。事例：收到規(guī)格變更的指示后，便把采取對策的事交給了現(xiàn)場。在A業(yè)務(wù)上采取了對策后便完事了，而與此相關(guān)連的主程序尚未對策，結(jié)果無法測試，只好推遲預(yù)定的運(yùn)行測試。事件管理題目必須用書面文件進(jìn)行確認(rèn)解說： 對于和用戶及公司內(nèi)其他部門間的咨詢、委托事項(xiàng)、規(guī)格變更等有關(guān)事項(xiàng)，如果只用口頭互相傳遞，會由于遺忘或解釋錯誤等而出問題。事例：得到用戶規(guī)格變更的口頭要求后，在沒有相互確認(rèn)有關(guān)程序的處理、測試數(shù)據(jù)的作成、文件過渡作業(yè)的分工等的情況下就擅自答應(yīng)了對方。當(dāng)快到交貨期檢查工作時，經(jīng)詳細(xì)調(diào)查才發(fā)現(xiàn)工作量很大，已來不及變更。報價題目每當(dāng)報價條件變化，就要重新提交報價單解說： 隨著反復(fù)的交涉，新系統(tǒng)的條件在不斷地改變。如條件變了卻不重新報價或雖重新報價了，但卻只停留在口頭上或筆記本上，那么新的報價可能會被忽視，對方只承認(rèn)最初的低報價。 再次報價的結(jié)果應(yīng)以正式文件提出。事例：某項(xiàng)目經(jīng)程序設(shè)計(jì)、生產(chǎn)階段順利地進(jìn)入了測試階段。當(dāng)初未明確化部分的規(guī)格也確定了，由于承擔(dān)人員的努力，可按時交貨，在工程會上向用戶提出當(dāng)初的報價要增加XXKS。因營業(yè)部門為重新報價，協(xié)作公司提出要加錢，便急忙向用戶提出，結(jié)果遭到了用戶的嚴(yán)厲拒絕。報價題目明確分工解說： 有時會有這種情況：認(rèn)為無需一開始就明確用戶和公司之間、公司內(nèi)部的營業(yè)、SE、設(shè)計(jì)部門之間的分工。雙方都想當(dāng)然地認(rèn)為對系統(tǒng)測試、為測試用的生成等體制及費(fèi)用有重大影響的作業(yè)應(yīng)由對方承擔(dān)。 實(shí)際上，在交涉談判時，因列出作業(yè)一覽表，事先明確各自的分工。事例：批量訂貨時，沒有討論和決定測試環(huán)境生成作業(yè)的細(xì)節(jié)和分工。接受APP定制作業(yè)的B公司在實(shí)施單機(jī)測試和子系統(tǒng)內(nèi)組合測試時才發(fā)現(xiàn)需要用超過了他們所承擔(dān)的程序變更作業(yè)范圍的測試數(shù)據(jù)主文件。于是便請求用戶支援，但用戶也無有經(jīng)驗(yàn)者，因而使工程晚了三個月。報價題目報價條件需得到用戶認(rèn)可解說： 報價條件是報價的前提條件。前提條件如果錯了，報價的內(nèi)容也就變了。通過與用戶深入地討論報價條件，才能使最初的方案生效
公司管理相關(guān)推薦
鄂ICP備17016276號-1