關於項目發佈包前後遇到的問題
近期團隊就發包的問題，展開了一次討論性的會議。與其說是一次會議，更確切的說是一次溝通。項目是java人力外包，下面就讓我介紹一下團隊和本次溝通的內容吧。
團隊構成
| 分工 | 人數 | 程序數量 | 平均工齡 |
|---|---|---|---|
| 前端（含後臺取數） | 4 | 1 | 2 |
| 後臺 | 4 | 9 | 2 |
問題
- 發佈包升級手冊中腳本及問題驗證編寫粗心，發佈包的驗證馬虎。
- 需求/bug與現場溝通不夠
- 問題修復不完整或改出新問題的現象
- 各程序之間的聯合測試問題
- svn使用不當,代碼衝突或覆蓋
- 程序的版本控制問題
在溝通的過程中，大家都可以說出幾個如何改進的點。在大家看來，這些都是項目運行過程中都會遇到的小問題。部分成員又是中途插隊，很難再短時間內做好這樣的工作。但這不是藉口。對於如上問題，我也有自己的一些小建議，或者說小看法。
看法
發佈包升級手冊中腳本及問題驗證編寫粗心，發佈包的驗證馬虎
這個也不能完完全全說是成員個人的問題。在很多團隊中，也並不要求成員對文檔的編寫有很大的要求。往往“麻雀雖小，但五臟俱全”的小團隊反而壓抑住成員的主人翁精神。這裏我並沒有說細分工種是件不好的事情。也由於目前的市場情況及團隊任務的繁瑣工作，在工作日內完成上級分配的任務已經算是很大的結果了（我們項目還不算太忙），非工作情況下的學習算是種“奢侈的消費”。
需求/bug與現場溝通不夠
在我待過的團隊中，很少有“內向”的人存在。衆所周知，程序猿找對象都用new的形式去完成，大部分人都是“宅”。但是這些“宅”們在一起可是無話不談的。在與業務人員溝通的情況下，是否出現“自以爲是”，“已經可以”，“無需確認”的情況。往往這些都是致命的。
問題修復不完整或改出新問題的現象
如果把這個歸納到短期內無法完全理解項目業務和融入團隊這裏的話，有點牽強。有一份原因也可以歸納到與業務員的溝通問題上面。成員的項目經驗問題還有待提高。
各程序之間的聯合測試問題
有人說，我很難想到我修改的程序是否影響到其他程序功能的運行。對，想想看，這的確有點道理，各何況團隊程序那麼多，誰來把控？項目經理？要知道，團隊可是個0測試的構成啊。難道就不能規避這個問題了嗎？這麼多程序，是否存在“麻煩”，“就這樣了”，“不用測”的話語。業務瞭解的夠不夠？一個人就要面對2-3個程序，是否就應該無視或者不關心其他應用程序？肯定有人會說，哪有時間啊，搞完自己的就已經不錯啦。我覺得這很值得深思啊。
svn使用不當,代碼衝突或覆蓋
我覺得百度比我懂的更多。
程序的版本控制問題
不要做一個只會敲代碼的好程序猿，也要爲自己留條“後路”吧。