筆者從事互聯網行業(yè)已有幾年了，每家互聯網公司都有自己的團隊，每個公司都有很多部門，各部門協(xié)調不好的話，進度慢，并且大家還累的要死，說一下我腦子里印象比較深的幾個。
1、不要為了趕項目進度，而忽視質量
當進度表，安排下去了以后，人手不夠，任務重，所以大家都重進度，輕質量。這個必須自己把好關，測試人員把好關，一塊一塊完成，而不能把小問題全部放到后期來改，這樣的話，后期的壓力比較大。
舉個例子：套模板，模板基本都是死的，套上程序后(比如做了一些特效)，樣式上會跟靜態(tài)的模塊有可能會不同，這樣的問題積累多了的話，到后來在跟前端配合改，會很累，做前端的還不能統(tǒng)疇考慮。所以遇到這樣的問題，一開始就和前端配合，這樣前端也能了解到，套過后樣式的不同等。這樣后期bug會少很多。
2、責任心要強
跟項目責任心很重要，如果我手頭上有很多工作，沒有完成，我什么時候都會想著它，做公交車都會做過站。但是也有一些人，可以說根本沒有責任心。
就以改bug為例吧，把一個bug交給別人，過一段時間問他，改好了沒有，他說改好了，我一看根本沒有改好不說，還又改出來一些bug，像這種人盡快的讓他離開。到后來基本上項目團隊里面的對他都不信認了。對別人負責任，就是對自己負責任。項目管理者聯盟文章
3、學會勾通，善于勾通
怎么樣把自己的想法很清楚的告訴別人，怎么樣很快的了解別人是怎么想的。這不是件容易的事。個人認為最好還是要學會站在別人的立場上考慮問題。做程序，還是做其他的都要有自己的思想，不能別人說什么就是什么。別人說的就一定是對的，一定是最好的嗎?多種想法的碰撞后，才會有精華出來。
4、需求變動
這一點是最要命的，需求如果沒有書面的形勢確定下來的話，就比較容易變動。人的思想都是不斷改變的，今天一個想法，明天一個想法這誰都受不了。想法的不同可能會導致程序要重開發(fā)，或者數據庫要重新設計。這樣的情況，做程序的肯定都遇到過,有的情況是這樣的，跟別人有合作，假如有100合作伙伴，這100家可能會提出100種可能性，并且這100個需求并不是一次給你的，可能開始的時候只有10種需求，后來需求越來越多，最終的結果是，如果不進行數據庫重新設計或者代碼重構根本滿足不了這種需求?；蛘呤亲隽撕芏鄠€小系統(tǒng)，來滿足不同用戶的需求，這樣后期維護就是悲催了。
需求變動有的時候是避免不了的，隨著時間的推移，需求肯定會有所變化的，但是要以書面或者是電子檔的形勢來確定下來，這里確定只是一個階段，確定下來就有了依據，至少提需求的人會認真的思考，會盡量把需求提得更清楚，更全面，對于他來說也是一種責任。如果真的有需求變動，要在原來的基礎上有所改進，也要等到一期做完。因為改進是永無止靜的，沒有最好，只有更好，所以這種改進要一步一步完成，不能一口吃個胖子出來。