背景

前几天和领导沟通，领导觉得他对我们程序猿的技术能力很放心，但是觉得大家的工程能力比较弱。觉得我们需要加强这一块。

技术能力

技术能力很容易理解，包括编程基础、算法、主流框架原理与运用、架构设计、数据库、项目优化等。

现在技术发展日新月异，每每都有新技术出现。个人觉得对新技术新框架的追求、理解、运用程序猿最基本的素养和能力，这个新技术的原理是什么、怎么使用、业务场景是什么、适不适合在公司的项目中使用等。

我们程序猿一直在追求的就是这个技术能力，我想这一部分也是由于这个大环境所决定的。

第一个原因是程序猿想涨薪得换工作，换工作得面试，面试都问些啥？就是我们的技术能力。第二个原因是现在外面的线上线下初级中级高级程序猿的各种培训，培训的也都是技术能力。

这就造成了我们为了拿高薪，为了找好工作，大量时间都在研究代码、研究框架，提升自己的技术能力，而忽略了工程能力。那么什么是工程能力呢？

工程能力就是在一个团队中将项目做好的能力。以敏捷开发的思维，按照一定的流程、规范和方法论，在单元测试和自动化测试的基础上，完成一个项目的初版，并在初版的基础上做到快速快速响应需求和迭代开发。

领导最关心的其实不是我们的技术能力，而是工程能力。他将一个项目交给我们，将一个技术团队交给我们带领，是希望我们能将项目做好做完善，线上运行稳定、没有bug，能快速响应产品的需求并迭代开发。领导不会关心功能实现的技术细节。

我将工程能力大致分为以下三个方面：

虽然领导不关心功能的技术实现，但一个好的技术架构能解决软件系统带来的复杂度问题；一个好的技术架构能让开发的同事事半功倍；一个好的技术架构能提高代码的可维护性可扩展性；一个好的技术架构能在项目做大时减少项目重构的时间精力。

我认为好的技术架构需具备以下几点：

这一部分应该是工程能力中最重要的能力了，也是领导最看重的能力。因为这一部分是可视的、可文档化、也是领导懂的。如果能把这一部分和领导讲清楚，让领导认可，他才会放心的将团队将项目交给我们。

流程上，可以引入scrum敏捷开发，但不建议完全生搬硬套，可以参考scrum找到适合自己项目组的开发流程。

敏捷开始是以测试为驱动的，单元测试和自动化测试是特别重要的一个环节。能否做到快速的持续集成就要看自动化测试做的好不好，每增加一个新功能，跑一遍所有单元测试，检查出新功能的依赖处和强耦合处，易于排错。单元测试没问题后再部署测试环境，然后进行自动化测试。

另外，轻文档、重沟通是很重要的一点。小公司如果每个流程、每个步骤都需要详细的文档的话，那开发周期就太长了，成本太高。生搬硬套大公司的各个流程只会。多沟通也可以加强开发人员对需求的理解。

管理上，经验较少，分享自己已知的小技巧吧。

首先是周计划和日报，这个每个程序猿都必须写。每周开始要了解自己这一周的任务目标，需要完成哪些功能的开发。若程序猿自己不清楚，可找项目负责人讨论。日报也是每天必须写的，这个会方便项目负责人跟踪项目进度，也是对程序猿的一个约束，不会让我们无所事事过一天，这样我们日报也没法写。

再是晨会，每天早上必开晨会，每位开发成员都要交代3点，昨天完成了什么，今天计划完成什么，是否有困难需要帮助。遇到的困难可以大家一起讨论怎么解决这个困难。晨会可以让团队每个人都知晓其他人在做什么，晨会需控制在15分钟内。

第三点是适合的人员。首先是适合团队氛围的人员，程序猿基本上都很安分踏实，少数那种带来负能量，带节奏的人员，整天的抱怨让本来安心工作的人也容易被负面情绪干扰。再是要适合管理者的人员，若某些人桀骜不驯，自认很聪明却不踏实做事，你与他相处不融洽，你管理不好他，还是早点请他离开的好。

以上仅为个人的拙见，如有不对的地方请指正！