Android开发项目管理7宗罪之四——开发任务的分派

之所以特地将这部分看似平常的工作单独提出来讲，是因为这项工作管理的好坏，将直接影响项目的质量，后期bug缺陷率高低。

每个项目都有其核心功能，业务 逻辑复杂的功能，与用户和后台交互繁杂的功能，这些功能一定要分派给经验丰富的、在岗状态稳定且可靠的员工来完成。开发经验丰富的员工开发复杂的业务逻辑的功能质量自然会比较高，思考问题和场景也更全面，代码的可扩张性性能也更灵活，为后期的维护大开方便之门。在岗状态稳定这一点很好理解，一个随时都可能离职，或者被调到其他项目组的员工，或者原本心就不在这个项目的人，有几个能够出色的完成开发工作？至于可靠，这个理解的比较模糊了，但总的来说就是对待工作的态度、对待技术的态度，对待团队合作的态度。另外一个整体废话不断，时时洗别人闹脑壳的人，开发思路都是混乱的，这可不适合完成这些工作。

毕竟核心功能、业务逻辑复杂的功能往往具有开发周期长、需要考虑的场景和逻辑交叉复杂、交互复杂的特点。若是这些功能模块交给不可靠、经验不足、随时可能离职或者被调离岗位的员工来担任，这部分功能的质量堪忧。后续接手负责的员工不得不花费大量的时间和精力去熟悉业务逻辑和代码风格，以及功能完成情况。然后才能开展工作。造成资源的大量浪费。

这里仍以笔者所在公司曾经的项目为例，银行App项目，转账必然是核心功能之一，逻辑很复杂，该功能被分派给从别的项目组、从外地外派过来的一位员工承担，该员工所在的部门随时可能因为新的项目启动而召回该员工。结果在员工在岗两个月后，即被调回。而他所负责的转账功能实际上只是完成了三分之一的工作量，剩余的部分并没有在交接文档中提及，旁人还以为全部完成了，细细研究发现其实还有很多的分支逻辑没有考虑进去，也没有实现，代码中也没有注释及提醒。给后续接手的员工造成了极大地困然，花费了两周多的时间去梳理逻辑，完善功能。这就浪费了少两周**·**人的人工，至少半个月的人力成本。

另一个项目的转账功能分派给了一个接近两年的员工负责。该员工在地第二轮测试结束后就被调回去另外，但即便是经过了 前面两轮测试，在第三轮第四轮测试中，bug数量还是以百计，改的后续接手的人吐血，改到绝望，改到发飙咆哮。每天新增十多二十个bug，每天加班到十一二点，还是无法把bug数量降下来。完全看不到bug修复完成的希望。后来不得不新招人力给他分担部分压力了。

由此可见，合理的分配开发任务，是多么重要的一件事情。任务分派要考虑的因素可真不少。。。