开发部门经理干什么

开门见山：开发部门三大根基职责（你能很快速很肯定的说出来吗）：
1、功能代码实现符合设计

 

2、开发符合计划进度

 

3、代码质量稳定性、高性能

 

开发部门经理的最基本职责就是力求自己本部门的工作能够达到这三个基本要求。如果连这三个基本点都做不到，我们何再奢求谈什么分层、解耦、设计模式、面向对象、易用、安全、易维护、易阅读、易扩展呢？

 

但很遗憾，我们确实没有达到。每次都奔着命的加班，就连星期六日都被加了班就更别说占用双周交流会时间。我对比了3年来的历次版本BUG统计，我们没有任何长进，历次版本的每个系统的BUG数量仍然停留在800-1000。

 

我们怎么提升呢？我们的方法是什么呢？我们历年强调的要更仔细一些、更到位一些、更严控一些，但这些方法奏效了吗？没有明确方法，能提升那就真见了鬼了。

 

我个人以为，历年没有明显长进，最大的根源就是开发部门经理飘在项目外面，无法痛彻心扉地亲历项目过程中的问题，那怎么能能提出有效的解决方法呢？

 

所以，开发部门经理必须深度参与到项目中去真实的第一感触的去经历，去感受问题，去思考问题，去想出解决方法并在项目中去应用看看能不能真的解决问题，去不断改进问题解决方法。参与项目是手段，目的是夯实与提升开发部门三大根基职责（你现在能很快速很肯定的说出来吗）。

 

所以，开发部门经理要做这样的事：

 

1、参与每个项目的详细功能设计评审，为后来出现问题能很快理解问题，准确做出支持决策而铺垫；也为更为准确的制定开发计划、开发人员调配、开发工作量做铺垫；顺带还能为以后参与项目开发小组一起做技术实现、代码实现架构、分层解耦、疑难技术验证攻关、技术隐患识别的讨论而做铺垫。

 

2、和各个项目组的PM、产品设计人员、开发leader一起估算开发工作量；但准确评估开发工作量的前提是开发部门经理要做好第一点的基础，否则你怎么能估算出准确的开发工作量呢？

 

3、参与实现架构设计/数据库设计讨论。架子没有问题，代码就不会越写越缠绕。

 

4、参与技术风险识别、技术验证，深刻理解项目中的技术困难。这是出现进度异常的最难搞定的。

 

5、参与性能优化。思考如何从物理数据库设计层面去前期做好性能

 

6、逐个分析BUG清单思考BUG根源找规律找机制，看通过什么技术底层技术框架技术工具能够在前期就避免这些BUG，而不要遗留到代码审查阶段甚至是测试阶段。

 

7、参加PMO会议，整体上了解每个项目的进展和风险。你如果不了解真正的开发进展、风险，你怎么能够给开发人员下达下个月的工作计划、绩效目标呢？

 

只有这样，你就能知道开发中常遇见什么问题，应该怎么避免什么常见代码错误，应该针对性给开发人员培训规范什么，这样才有非常针对性的培训。

 

进度滞后于计划，看似无法下手。其实进度滞后是个表面假象。背后的问题根源可能是被技术难题挡住了，可能是开发人员不理解业务，可能是开发人员不理解现有代码关联关系和复杂绕弯，可能修改了这处又莫名引发了其他模块的突然报错。你深刻参与了上述的环节，你才能知道进度到底卡哪里了，你才能采取正确的解决方法。

 

我审查了3个版本4个子系统的BUG统计，BUG前三类是：功能错误、界面缺陷、数据错误。而前三类却占了所有BUG数量的50%还多。

 

如果你没有精力解决这么多稳定性、性能、进度，那么咱们就集中力量彻底扑下身子去研究稳定性，集中火力能提升一个就提升一个。就如同我们有JS浮点运算，我们就做一个工具去自动检查和自动修复这个BUG。我们解决一个问题就消灭一个问题。况且我们的问题不是个性怪异问题，而是我们已经历年历次犯，我们的问题我们过去都见过，但就是没有方法来根治。我们年年强控年年控不住，就是我们方法不对头。

 

1、每个问题有明确的解决方法。如针对JS浮点运算这个错误，就有一个工具。不要再提更详细的思考更严格的自测之类的没用话。

 

2、力求做成工具。工具既是手段也是目的。逼迫你做成工具，其实是逼迫你把问题想的能落地，这就是手段。另外，如果能做成工具，那么换谁来做都能保证质量。而不是只有高手才能做。毕竟高手太少，而有限的高手被忙的团团转根本没有那么多时间，这就是目的。

 

如果我们的BUG数量能够减少一半，如果我们能够从容而自信的等着产品发布日而不是奔命追赶产品发布日，那说明我们的开发部门管理就越做越好了。