今天真是好日子，发工资的日子，今天真不是好日子，下班的时候被告知，年终奖没了。今年部门的业绩据说还行，不过由于和香港、台湾一起计算后，利润就很低了，低到不足以发年终奖，我们一帮悲催的兄弟姐妹盼了一年的bonus,居然是这样的结果。郁闷归郁闷，公司没钱，也没有办法，不过好好想一下，这一年多我们的项目的确做得不算好，现在回想很多地方都有改进的空间。
项目做了一年多了，到现在延时5个多月，严重超出预算，bug一大堆，改了几个月才慢慢稳定，代码混乱，现在都没人敢去重构，也没有时间允许我们重构，造成这样的后果有多方面的原因，现在总结一下，以为后者鉴之。
1. 项目初期对项目的复杂度估计不足，因为是将一个原有的系统使用新的技术和框架进行升级，所以理所当然的认为很简单;
2. 忽略了技术风险，因为采用了SCA来架构，大家对SCA完全一无所知，maven,websphere对于大家来说也都没有什么经验，导致在SCA和websphere上花的时间太多;
3. 业务复杂度被低估，虽然是升级系统，但是由于文档严重不足，原有代码经过二十多年的维护十分的混乱，没有人对需求完全了解，而客户也没有给我们足够的时间来了解这些业务，我们的PM认为有代码，所以也没有重视这方面的风险，结果很多人直接从老系统拷贝代码，甚至连老系统的逻辑都没有弄明白，拷过来如果能运行就一切OK，导致最后大家还是对业务不熟悉;
4. 前期有要求大家写单元测试，并且使用sonar进行代码规范，但是由于项目进度催得太急，大家又没有写单元测试的经验，对单元测试的重要性也认识不足，所以最后没有坚持下来，现在的单元测试很不完整，有的完全是应付任务了事;
5. 团队沟通太少，知识分享不足，团队工作效率不高。
针对以上问题，要如何应对呢？
1. 前期的分析一定要详细，特别对于我们这种中大型项目，如果信息不足，可以试着做一个小的原型。
2. 如果引入了新的技术，且大部分团队成员对这种技术不熟悉，那么一定要想办法找一些熟悉的人来做一些指导，如果找不到这样的资源，那么团队成员一定要有一部分人提前学习这种技术，并且及时给出一些对该技术风险的判断，PM一定要及时和这些队员沟通。
3. 绝对不能在需求不明确的情况下开发，像拷贝代码这样的事情，其实也是因为催进度催得太急，大家做出了妥协，现在想来这种妥协太致命了，一发而不可收拾，这应该要一开始就杜绝的，程序员一定要学会说NO，不能因为PM催就草率应付了事，一定要对自己的代码负责，做为team leader更要帮助队员顶住这种压力，并且与PM多做沟通，讲明历害关系，不能叫做什么都是Yes。由于需求不清楚，拷贝过来代码甚至不知道是做了什么事情，所以单元测试完全无从写起，由于时间紧，更有理由不写单元测试，最后的结果就是集成测试的时候bug一大堆，改一个bug又引出另一个bug，代码质量没有保证，没有单元测试又导致不敢重构，所以最后延时非常严重，一直不能发布最终版本。
因此，team leader绝对要是能担当责任，自信，敢于说NO的人。单元测试一定要认真完成，不一定要测试驱动，但是每一个复杂的方法一定要有单元测试，能写出单元测试说明你完全明白你写的代码是做了什么，同时如果有问题通过单元测试也能较早的发现，后期的bug会少很多。重构的时候风险也小很多，每次重构完成跑一遍单元测试可以及时发现是否有影响到别的代码。
4. 团队的沟通，协作能力很重要，team leader不能只是分配任务，督促任务完成，更要在平时多关心大家，经常在一起开些小会，了解大家的情况，经常和队员沟通，了解他们的情况 ， 是否对公司有什么建议，或是有什么困难，及时的把这些反馈给PM或是更高层的领导。经常性组织一些培训，可以让大家轮流的分享技术或是业务知识，每周花一小部分时间，这样大家都一起提高。
今天想到了这些，记录下来，希望在以后的项目中能记得这些经验和教训，不能在犯同样的错误。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
