我是一個對日軟件的項目管理者，從事軟件工作已經8年有余，我從普普通通的Programer到項目經理，經歷了被人管理和管理別人。我赴日當過IT“民工”，體會了國內軟件管理模式和日本軟件管理模式的相同與不同。下面我跟大家分享一下我在管理過程中的一點點心得。
軟件開發(fā)，歸根結底是讓客戶滿意，看到高質量的產品。所以對于管理者來說，如何在規(guī)定的時間，規(guī)定的成本，規(guī)定的范圍內，完成高質量的產品，成為評價一個管理者是否優(yōu)秀的基本標準。
現實管理過程中，作為項目經理的我們很少有機會接觸到成本，我們看到的只是時間和范圍，我們的組員天天也都是各擔其職，在規(guī)定的時間做好項目經理分配的任務。但是組員按期不能完成任務，是我們平時工作中經常會遇到的問題，模塊擔當者由于經驗不足，能力不足等等原因，在開發(fā)中前期沒有足夠的能力判斷自己能否勝任分配的工作，以至于時間馬上就要到了，才發(fā)現已經無法在規(guī)定的時間做完。這時候才報告給項目經理，為時已晚。
輕者可以通過增加人員，加班加點把進度趕回來，重者影響到這個項目的成敗。所以跟蹤進度，召開定期的進度會，能夠有效的使項目經理了解項目整體以及各模塊的進展狀況，提前做好預防措施，避免項目整體質量受到嚴重影響。
開會，有些人喜歡而有些人認為是浪費時間。從我個人的角度，作為一個項目管理者，很好的了解你的組員，很好的了解你的組員擔當作業(yè)的狀況，定期開會是必不可少的。
好多IT業(yè)的項目經理，大學學的都是計算機專業(yè)，而且大多都是技術上的尖子，對技術的研究勝過對于“管理”的思考。他們有時候會把較難的工作分配給自己，每天埋頭苦干，加上管理上的瑣碎事情，好多這樣的項目經理，總是感覺一天滿滿的，壓得自己喘不過氣，根本沒有時間開會或者思考項目中的不足和需要改善的事項。
我想對這樣的管理者說，既然我們走上的管理，我們就需要足夠的信任自己的組員，讓他們茁壯成長，慢慢的擔起重任，也給我們自己喘息的時間，發(fā)現項目中的缺點和不足。完善自己的隊伍，這才是我們應該注重的工作重點。
對于項目經理來說把握好了時間，想要得到高質量的產品，另一方面就是把握好范圍了。
東西做完了，東西做的好不好?是不是客戶想要的東西?是不是完成了所有式樣書的功能?功能上是否還存在缺陷?這除了需要我們更精細的測試，還跟需要完善項目的確認流程。
組員向你匯報“程序寫完了”，你的第一反應是什么呢?繼續(xù)測試?還是先確認代碼?
好多國內公司缺少代碼確認環(huán)節(jié)，同樣是一個項目編出來的代碼，代碼樣式形形色色，花樣百出，而且有時候實現同樣功能的代碼，會出現在不同的代碼文件中。組員完成的代碼，功能可能都不會有太大問題，但是代碼的質量是一個不能被我們忽略的課題。
我們反復強調代碼的一致性，代碼的共通性，其實就是為了使我們編碼的流程更加規(guī)范，編出來的代碼效率更高，可讀性更好，更便于維護。所以在程序完成后，開一個代碼確認會，我認為還是比較必要的。尤其在項目初期，模板代碼的質量可能直接決定以后編碼的工作效率及代碼的規(guī)范程度。
在代碼確認會上，擔當組員主講代碼實現功能，其他組員隨時參與意見，會后整理代碼的指摘事項，作成checklist，以便后人能夠參照，避免同樣類似問題的發(fā)生。
UT結果更是同樣，擔當者往往都認為自己的代碼不會有什么大問題，測試有時候過于敷衍，有些測試事項可能都沒有實際執(zhí)行，出于自信，寫上“確認完了”。這樣的事情，我相信在每個項目組都會出現。所以最好的解決
辦法是，找一個擔當以外的人進行測試結果的確認。而且確認后往往需要對于發(fā)現的問題，橫向的展開調查，以防同樣類似問題的發(fā)生。
現在我管理的項目人數較少，人員能力比較平均，項目組氣氛比較柔和，管理壓力相對較小。
因為一直沒有系統(tǒng)的學過管理方面的知識，所以去年參加了PMP培訓，補了補管理的基礎知識，受益匪淺。管理是門學問，自從參加了PMP學習，我才發(fā)現我的管理之路才剛剛開始，需要走的路還很長很長。