工作大半年了，上次和老師聊天，邀請我寫篇項目開發(fā)感想，這個項目是個很趕時間的項目,周末也要自覺加班。很累，但是還是撐過來了，終于把手頭上的一個大項目做完了，才得以騰出時間寫寫總結。

　　從4月開始投標然后陸陸續(xù)續(xù)有人加進來，我是5月初加進來的。4月部門經理吳經理就先主導需求調研，同時招聘這個項目的項目經理。初步需求搞定了就到了5月份。由于自己有相同的項目的開發(fā)和管理經驗，吳經理要求我過來支撐一下前期開發(fā)工作。等到項目經理到位了，吳經理就脫身了。然后就進入了我們辛苦的6月和痛苦的7月。

　　做項目的向來都很辛苦，不加班不正常。人員配備齊全后，吳經理問我這個項目問題大不大。自己當時沒有理解吳經理的意思，就很樂觀地說沒問題。我這么一說，吳經理就漸漸脫離了這個項目，等到我反應過來的時候，自己已經集開發(fā)管理、設計和開發(fā)于一身了。新來的項目經理大劉一直在熟悉需求，遲遲沒有上手。需求和進度的控制也沒有人做。

1、吳經理脫身太早，需求調研銜接不好。我和大劉到位后，吳經理就成天出差。雖然做了初步的需求調研，很多東西又是有待客戶確認的甚至是業(yè)務邏輯不清晰的。需求的不明就直接得影響到我們對業(yè)務的理解和系統(tǒng)設計。

2、大劉遲遲不能把握需求。在我看來，一個項目的責任是自上而下的。所以談感想的時候也要自上而下。大劉是吳經理強力推薦的。估計在社會經驗上面的豐富程度讓吳經理做出了這個決定。8月份的大劉始終都處于整體業(yè)務的梳理階段，至于需求調研和項目進度的控制做的很少。

3、原本以為吳經理會一直主導本項目的需求調研和項目管理。所以給自己的定位是開發(fā)兼內部技術支持的角色。后來發(fā)現(xiàn)吳經理脫身的時候，自己已經在做他做的事情了。這個時候，如果可以及時和吳經理溝通，討論如果繼續(xù)支持項目進度的話，估計自己不用經常加班、項目管理也會比較順暢。我只是默默的加班，經常性的加班也導致工作效率的下降，以此惡性循環(huán)。

4、開發(fā)環(huán)境的搭建問題。7月份在調研的時候已經有人進入這個項目并開始做架構的梳理和公共環(huán)境的搭建了。不過搭建的環(huán)境確實不敢恭維。我們擁有相同的項目經驗，當不一定可以原班照抄的把原先的項目搬過來用，這一點小公司應該最清楚。搬過來后的結構，無用的代碼堆積得讓人感覺像是一個超級大胖子身上的肥肉。另外我們使用的數(shù)據(jù)庫的試用版的只支持一個用戶連接，嚴重影響了共同開發(fā)的效率。另外沒有搭建WEB服務器為我們后來部署給用戶的時候保留了相當大的難度。

5、合作的問題。這個問題在我們的開發(fā)中沒有成為一個大問題，因為大家都想把這個項目做好。需要提到的一點，就是和老板的溝通問題。在為用戶部署程序的時候，發(fā)現(xiàn)的web服務器支持jstl有些問題，導致需要現(xiàn)場更改很多的代碼。事后問道大劉，回答：老板說web服務器沒什么差別，就沒有管。如果是當時的我，同樣也不會反駁老板，因為我確實沒有用過websphere，更不要說和tomcat的差別了。更何況是老板，沒有充足的理由，也最好不要反駁他?，F(xiàn)在的話，有了徹夜修改代碼的慘痛經歷后，情況應該會不一樣了。說到頭還是經驗的問題。

6、亂七八糟的問題。比如代碼管理服務器經常死掉、數(shù)據(jù)庫版本不一致等等。

　　總結一下：

　　大多情況下，付出是有回報的。有朋友就跟我提議，趕快讓老板加工資。很現(xiàn)實，可我沒有這個習慣，也不習慣在這個節(jié)骨眼上做這樣的事。作為經驗的總結，我很高興自己能以當前的角色進入這個項目，雖然沒有得到相應的物資或者精神獎勵，但是我很清楚自己得到了什么。這是最重要的，至少對現(xiàn)階段的我來說。

1、要把需求寫好。這個不用說了，誰都不想更改設計。

2、做好需求的跟進和需求的版本控制。需求也有版本，做好了，加以時間的控制。切切實實讓內部的開發(fā)人員感到自己沒對的是一個確定了的需求。

3、模擬環(huán)境和開發(fā)環(huán)境。

4、控制好用戶的進度要求。這個需要比較高的談判技巧和應變能力。總體來說還是為內部創(chuàng)造比較寬松的開發(fā)時間。不要三天兩頭的過去調試系統(tǒng)，時間浪費很大。

5、合理分工，盡量發(fā)揮各人的優(yōu)勢。再牛的人也有極限，分工要合理。

6、需要注意程序員的心態(tài)。過長時間的加班會導致身心疲憊，開發(fā)效率可想而知。需要一些休息或這實質性的進展讓同志們看到希望。

7、牢牢地跟進開發(fā)進度。適當?shù)刈稣{整，讓項目始終處于掌控之中。