第一个接手管理的项目总结

今天看了微信朋友圈分析的文章《一个项目经理是如何把项目带崩的》后，我是深有感触。作为一个没有任何管理经验的人，本来应该是从事开发工作的。无奈项目组无人可用，只能顶包。

1.项目和团队背景

  我所在的公司是一个偏向于国企的公司，我临时接手的项目属于一个活动项目，项目的成员除了我以外，还有3个成员是从别的团队临时借调过来的第三方的同事。
  刚开始他们过来的时候，我们领导说，我不用负责开发，只负责监督项目的进度即可。我就信以为真，以为真的不需要管了。每天跟他们在下班前沟通一下开发进度，问问他们存在的问题。刚开始还好，没有出现什么大问题，不过后期在需求中出现了一个小插曲。

2.需求确认

  我们4个人负责开发的是参与三个活动的人员的活动数据的展示项目，比如小张参与了活动A，B，C，我们的项目就是展示一些小张参与活动A，B，C的活动统计数据，比如参与多少场，赢了多少场，得了多少积分。刚开始看上去，感觉是挺简单的。不就是一个前端的数据展示嘛，但是仔细一想问题就不那么简单了。

1. 活动数据从哪里呢？
2. 通过什么方式获取数据呢？
3. 是实时查询还是每天更新查询？

  活动A 、C是我们公司Q自己做的，活动B是集团公司另外一个公司M负责开发的。我们需要跟开发三个活动的团队商量数据获取的接口，到底是我们这边调用活动方的接口拉取数据还是活动方调用我们的接口推送数据。
  最后结果是活动A提供接口，让我们拉取数据；活动B提供接口，让我们拉取dat文件；活动C最坑，我们自己查询数据库，查询完成以后将结果数据插入到数据库。
  活动B当初没有经过领导同意就私自同意活动B提供实时数据查询的接口，被领导批评了，说是这么做，我们这边服务器受不了。（以后的项目多请示肯定没错）

3.项目开发

  项目开发了一段时间以后，我感觉他们的进度和人员好像不怎么匹配，感觉是三个人干了2个人的活。后来一个同事说另外一个女生基本上就是看代码，不动手敲代码。我一看这么下去，肯定是会影响进度的，我就负责了前端部分，通过AngularJS调用后台接口。
  在组建项目组的时候一定要了解每个开发人员的技术水平和性格特征。以便把控后期的项目进度，减少挖坑和填坑。了解技术水平可以分析他是否可以在规定时间内完成开发任务，保证开发质量；了解性格特征是为了让大家在一起合作的更加愉快。有些人执行力很强，只需要在几个里程碑处监督一下即可，给下属重复授权，他们更喜欢自由；有些人执行力较差，比较被动，总需要别人去推着他走，因此对于这种人就需要让他勤反馈项目进度了，否则后患无穷。

4.项目测试

  这个活动总结的项目从9月20日开发，大约开发了一个月到10月15日左右开发完成，开始由测试进行测试，项目计划10月26日上线。测试的时间不到2周，测试过程中发现页面的进度条不行不符合原型图。协调了一个前端人员，但是他只做了移动端和web端的页面适配。积分进度条他是用的图片，只能我自己在网上找了一个js文件，加了几天班，终于搞好了。
  项目组没有专门的前端人员，都是借调的。这种项目组以后不要去，太折磨人了。另外的三个同事开发的后端接口中，调用活动A的接口分批拉取数据，每次1万条数据，最后写成dat文件存入本地；然后再通过jdbc连接数据库读取文件批量插入。这个接口本地测试没有问题，测试环境由于没有并发，短期没有发现问题（后期发现了很大的问题）。调用活动B的接口比较简单，从活动B直接获取的是dat文件（以后推荐这种方式，稳定）。活动C查询数据和插入数据库的逻辑都是我们完成，测试也没有问题。接着就是准备上线了，也就开始了后期的填坑之路了。

5.项目填坑

  刚开始的一周，项目还算稳定（因为表中数据量少）。活动A出现了无法展示数据问题；活动B偶尔会出现没有插入数据的问题，生成的dat文件大小为0；活动C倒是还算稳定（点赞表中数据量目前还算少）。最后通过排查发现活动A是因为redis缓存中读取数据有问题，就把缓存去掉了，直接从数据库读取；对于活动B的问题，我们一开始不清楚什么原因（开发的哥们没有打印异常日志，无语），我跟他们说过这个问题，他们总是以本地测试没有问题为由，不积极寻求问题的根本原因（最后导致我折腾了一周去排错，被领导骂，都有离职的打算了）。前期针对于活动B，由于他们没有想办法去排错，我自己没有参与开发，所以只能通过手动调用接口去拉取数据去在客户发现前弥补问题。但是这么做治标不治本，项目上线第二周就这么对付过去了。到了项目上线第三周，我早晨巡检的时候发现我通过手动去拉取活动B的接口去获取数据，接口没有任何反应。噩梦开始了，客户开始向集团投诉，集团的领导跟我们领导沟通，让我们排错，我们领导发飙了。让我加班解决问题，我只能让活动C的一个经验丰富的同事帮忙看一下，最后发现是调用活动B的接口采用HttpClient去连接的，写代码的哥们每次请求的时候没有关闭连接，还有很多其他的IO流没有关流。他没有使用可关闭连接的方式：CloseableHttpClient httpclient = HttpClients.createDefault();而是采用了HttpClient client = new DefaultHttpClient();导致连接太多，还有一个致命的问题就是他们没有测试大量数据的时候比如读写10万条数据时连接的稳定性问题，经过我们在本地测试发现使用HttpClient进行连接获取数据的时候，获取少量数据是没有问题的。但是对于多次调用接口获取数据的时候，可能会出现连接超时的问题。他们没有给代码加上try catch，导致代码抛出连接超时异常以后就不执行了；后来给代码换成了可关闭的HTTPClient，并且加上了try catch块保证代码及时抛出异常也可以继续执行。
  那么为什么会出现执行接口也不行的问题呢？后来我们通过添加日志后发现，第一次执行插入数据是没有问题，但是第二次进行调用接口就不行。原因是执行接口是的查询开始和结尾的参数用的是上次调用的参数，没有初始化为0，1000（晕了）。我真是服了这个开发哥们了，后来我在调用接口前初始化了参数后，在本地和测试环境中调用生成接口都没有问题了。目前项目上线到了第五周了，总算是消停两周了。
  你以为就这样完事了吗？答案是NO，还有活动C的坑没有填怎么能算玩呢？由于领导们号召，集团的员工开始疯狂的点赞。导致点赞表每天增长由10几万到几百万，活动C当初的查询sql效率太低了。各种子查询，对于数据量少的情况没有问题，但是对于大数据量的情况就崩溃了。后来领导感觉我的sql水平有限，就把查询数据插入数据库的业务逻辑交给活动C的同事通过存储过程来实现了。我们的活动只负责查询数据，不负责跑批工作了。到此为止，我们的活动终于消停了。目前稳定运行2周了，及时插入数据有问题也不用我们操心了。

6.总结

  在项目的前期一定要确认好需求，搞清楚分工的边界。不要自作主张乱作好人，否则后期有任何的问题都会找你。一定要搞清楚项目团队的人员技术水平，及时在本地测试通过的代码也有测试大数据场景的情况，否则后期肯定需要填坑。自己一定要掌握项目的进度和技术的风险，不清楚的地方技术咨询经验丰富的同事，避免后期调整业务逻辑。希望大家能够在今后项目过程中，少走弯路。