开发任务管理分析报告

创业公司，那么就必须经受事情越来越多、越来越杂、越来越急，很多人给你分配任务，你需要参加的会议越来越多的情况，开始的时候还可以通过加班来处理，然而事情无限时间有限，任务管理势在必行了。这次会议各组通过接收、计划、执行和复盘四个节点来阐述任务管理的过程。该讲的点其实都讲到了，我站在开发的角度更细粒度的剖析一下。

任务接收

接收一个任务优先级必须先排一下，而后看初步判断是否需要马上立刻去了解详情，重要紧急的就找到任务分派人拿到对应的资料，看文档资料结合其他资料先过一遍，把问题点记录，之后找到对应的分配人进一步交流确定任务细节、沟通的时候要时常站在相关方的角度提出这个问题的原因，需求的方法是否就是最优解，是不是有其他的方案来解决提出方的痛点。差不多之后就用uml简图把需求转成开发实现的方案，方案更要提到局部对整体的影响点，在进一步确认方案是否有偏离。重要不紧急的、紧急不重要在处理重要紧急的去了解情况。对于不紧急不重要的也要分析问题，提出自己的建议。

制定计划

制定计划要考虑的就多了，需求的量、复杂度、人员的熟悉程度、人员能力、相关方的完成时间。开发来讲，按照复杂度留给足够的设计时间是非常有必要的，毕竟现阶段系统要的是安全、稳定、高性能、高可用和易于维护。设计上如果和需求方和测试达成了一致意见，那么其实开发测试都是很快的，如果设计时机不够没有考虑清楚，那么转测试的时候就有很多的问题，各种反工重新测试，代码也是各种补丁，腐坏滋生，我目前也是慢慢更多转向，把握总体设计，表的设计、包和接口存放位置，利用什么设计模式进行操作都是考虑的点。还有一个点是自测试这个点要加强，以前自测试很少，所有很多压力都留给了测试，就会发现项目每次都是在上线前还在修改bug，我强烈建议开发中自测试时间加长，基本测试用例由测试提供。让开发了解自己所作的功能，自己演示和说明逻辑，其他人可以提问题，可以让其操作各种场景，这样出了问题也是自己操作出来的，心理上比较容易接受改动的积极性比较强烈。这种情况下基本可以排除大部分问题和排除需求逻辑和测试对不上的问题。那么这样测试的时间就可以集中的各种复杂场景的验证上了。开始的的时候可能开发时间长了，但是返工少了，bug少了，情绪好了，质量好了，习惯了那么后面测试的时间也就可以相应调整，总体时间会下降，而总体效率、质量都会提高，开发会更重主动学习和写出利于维护的代码。坚持下去就是个良性循环了。假如中间有其他任务插入进来，大方向上，产品业务需求优先，非业务需求可以视项目进度，资源是否空余、紧急程度灵活安排，这样可以保证制定的项目计划正常进行。

如何执行

执行过程也是很考究的过程，首先要明确时间观念，把任务分配到对于的时间段，前期保证质量的情况下尽量往前赶。过程中需求有变动，或相关方工作没有按期完成，也要有备用的方案，不可以中途就堵住了，不可抗力那就要提前报备风险，同时也要继续想办法解决，执行过程中有问题及时和产品或上级沟通，组员的情况要每天跟进。对于核心功能，那么要组员在实现部分功能的时候也要说一下逻辑，看看是否有偏离，保证大方向上不变。中间有紧急任务插入的话，视情况而定，一定要做的那就不可避免了，影响不大可以维持原来的计划，影响大的比如总体超过了一天的，那么就看情况是否要项目延期处理，总得来说，对项目要有设计、质量、进度和目标达成度都是要考虑的。开发中还有个很重要的是代码走读，演示功能提高成就感，说明实现逻辑也是锻炼业务能力，同时也是检查代码实现的一个参考依据，组员各自吸取优秀的部分，隐藏的bug也可以揪出大部分，优秀的部分会留下，那么实现风格就趋于统一了。一是利于组员对整体业务逻辑代码实现有更全面的认识，方便日后的维护和需求的开发。这些都是开始需要多点时间后期就要较少的时间就可以达到持续优化项目的目的。我觉得这个是非常必要的。

复盘总结

复盘总结开始要说的就是任务的实现情况，优良中差哪个级别，好的要说，要保留经验，我们项目就有个知识库保存起来，出现的问题担任要分析，找出根本原因，还有点需要说明的是要给问题定性，让大家知道这个问题的影响，这个很有必要的，这样可以加深大家对问题的重视程度。改进措施要有跟进的检查。有些问题就是属性提高类的，其实这类问题是比较难处理的，时间不够，一直写逻辑，就没发提高知识的广度和深度，眼界窄格局小的问题就很难得到解决了。这类问题需要专项培训提高。说白了，不管是改正还是提高都是要大家认识到危害很多或价值很高才会去做。

我这边后期就会更多的注重安全、稳定、高性能、高可用、易维护，快速实现变化需求为目标去努力，去寻找和学习这方面的知识和积累经验。业务实现方案上我会持续跟进，代码都读要持续进行。争取把项目越做越顺、越做越好。