笔者从事互联网行业已有几年了，每家互联网公司都有自己的团队，每个公司都有很多部门，各部门协调不好的话，进度慢，并且大家还累的要死，说一下我脑子里印象比较深的几个。
1、不要为了赶项目进度，而忽视质量
当进度表，安排下去了以后，人手不够，任务重，所以大家都重进度，轻质量。这个必须自己把好关，测试人员把好关，一块一块完成，而不能把小问题全部放到后期来改，这样的话，后期的压力比较大。
举个例子：套模板，模板基本都是死的，套上程序后(比如做了一些特效)，样式上会跟静态的模块有可能会不同，这样的问题积累多了的话，到后来在跟前端配合改，会很累，做前端的还不能统畴考虑。所以遇到这样的问题，一开始就和前端配合，这样前端也能了解到，套过后样式的不同等。这样后期bug会少很多。
2、责任心要强
跟项目责任心很重要，如果我手头上有很多工作，没有完成，我什么时候都会想着它，做公交车都会做过站。但是也有一些人，可以说根本没有责任心。
就以改bug为例吧，把一个bug交给别人，过一段时间问他，改好了没有，他说改好了，我一看根本没有改好不说，还又改出来一些bug，像这种人尽快的让他离开。到后来基本上项目团队里面的对他都不信认了。对别人负责任，就是对自己负责任。项目管理者联盟文章
3、学会勾通，善于勾通
怎么样把自己的想法很清楚的告诉别人，怎么样很快的了解别人是怎么想的。这不是件容易的事。个人认为最好还是要学会站在别人的立场上考虑问题。做程序，还是做其他的都要有自己的思想，不能别人说什么就是什么。别人说的就一定是对的，一定是最好的吗?多种想法的碰撞后，才会有精华出来。
4、需求变动
这一点是最要命的，需求如果没有书面的形势确定下来的话，就比较容易变动。人的思想都是不断改变的，今天一个想法，明天一个想法这谁都受不了。想法的不同可能会导致程序要重开发，或者数据库要重新设计。这样的情况，做程序的肯定都遇到过,有的情况是这样的，跟别人有合作，假如有100合作伙伴，这100家可能会提出100种可能性，并且这100个需求并不是一次给你的，可能开始的时候只有10种需求，后来需求越来越多，最终的结果是，如果不进行数据库重新设计或者代码重构根本满足不了这种需求。或者是做了很多个小系统，来满足不同用户的需求，这样后期维护就是悲催了。
需求变动有的时候是避免不了的，随着时间的推移，需求肯定会有所变化的，但是要以书面或者是电子档的形势来确定下来，这里确定只是一个阶段，确定下来就有了依据，至少提需求的人会认真的思考，会尽量把需求提得更清楚，更全面，对于他来说也是一种责任。如果真的有需求变动，要在原来的基础上有所改进，也要等到一期做完。因为改进是永无止静的，没有最好，只有更好，所以这种改进要一步一步完成，不能一口吃个胖子出来。