Think about manage project

ID:51773 · 發(fā)表于 2013-8-16 15:36

Thinking ...

在這里已經整整一年了，覺得還是有必要總結一下發(fā)現的問題。

1，版本。
問題：沒有真正把CVS的功能使用起來，check in時注釋不寫或者不寫清楚，沒有及時update和
diff，造成check in舊版本的覆蓋著新版本的；CVS使用不嚴謹，造成check in太隨便，版本過多，一天N
個版本的現象比比皆是，有點像收到垃圾郵件似的，想diff一下都困難重重。
解決：版本控制的使用不僅僅是管理者熟悉，重要的還是使用者的使用，只有更多地去學習，更
有效地使用才是正道。
2，需求。
問題：需求變化太快，快過了開發(fā)的速度。有總會有想法的，腦袋轉得比手腳還快也正常。
解決：不管是領導還是客戶，不管需求變化得如何地快，都不能來個大轉彎改向，應該在保持原來大計劃的方向下急時地做出一些改動來適應新的變化，后面再抽時間來去改變。
3，大局。
問題：有計劃就不亂就不累，沒有側反然。沒人把握大局，沒有計劃，整個團隊就沉浸在修改需
求，修改BUG的大漩渦之中。
解決：找個人能不受外界的影響來定下長遠和各種中期的計劃，然后一直走下去，并定期按實際情況和進度進行適度的調整。
4，項目。
問題：有問題就整個團隊進入進行解決，如果是戰(zhàn)場的話那可能就會得個全軍覆沒的結局，可是
，難道我們這不是戰(zhàn)場嗎？
解決：幾年前就看過當時剛起步的一種軟件工程的新管理方法--XP。現在雖然沒怎么關注了，不
過應該發(fā)展得不錯了吧。XP比較合適小團隊開發(fā)，特別是多變化式的。我覺得，從大局來看，應該保持整
個項目的前進，如果有問題只留小部分人進行處理，大部隊繼續(xù)前進。這是我的戰(zhàn)略。
5，架構。
問題：沒有架構或者架構很差，那就給維護帶來很多很大的麻煩，成本也會上升，壞的結果還會
讓項目流產或失敗。
解決：
6，設計。
問題：只有最差的工人才會死著腦筋按著設計師的意思去做東西，不管是否有問題。說有人就借
說：那是他們設計的，我只負責編碼！
解決：不要做代碼工人，要就做軟件工程師。不管是誰設計的，你都要了解清楚，要知道是否有
問題，有好的吸收，有壞的改出進。

帳號		自動登錄	找回密碼
密碼			立即注冊