技术团队如何高效开发

各位做产品技术的小伙伴们，今天跟大家聊一聊如何高效的开发。
最近工作非常多，大家也非常忙，看着大家经常的加班非常辛苦，我也一直在思考如何做出改变。加上前端设计我们的技术团队也基本上快20人，已经不是去年几个人的小团队了，但大家依然是忙忙碌碌，除了一些客观的原因我们无力改变，我们自己是否还有提升的空间，当事情无法改变，资源一定的情况下，只有提升单位的作战效率，才能让整个团队的执行更加顺畅。
当然，效率的提升不是一早一夕的事情，但是对于如何提高技能，如何用高明的方法解决问题，却是我们时时刻刻都要去关注并付诸实践的，如果我们平时没有这方面意识，我们就很难去改变，最终就会造成书到用时方恨少的结局。日常的积累决定了一个人甚至一个团队的厚度，个人的积累相对比较容易，但团队的积累需要建立在个人积累的基础上有组织的规划协调。
既然是有组织的规划，这就对团队整体提出了更高的要求，这也对技术负责人提出更大的挑战。我认为团队的积累需要从以下几个方面进行：
1、团队的组织形式一定是纵横交错的，而不是单一线路的。互联网产品团队往往以产品线划分组织，而忽视了技能的分层结构；而项目开发团队，往往以技能划分组织，而加大了在同一件产品模块上的协作成本。作为互联网产品团队，要以产品线作为项目组织形式，但要以技能分层构建团队积累成长的体系。让擅长的人做更擅长的事，在专业领域有专业的人才解决一类的问题。立体式的组织结构对管理提出了更大的挑战，但我们不得不面对。而对于个人来说，每个人都要向一专多能的方向去发展。有自己的专长，能解决某一类的复杂问题，同时具备其他能力，小团队需要各种补位，只有具备多种能力才能弥补小团队人力不足的问题。
2、团队要具有整体规划能力，这就需要我们要在微观的事情之上做出宏观的思考，具有抽象、归纳、规划的能力。这就像下棋一样，下一步看三步，甚至看的更远，只有这样才能把控全局。李世石输给了阿尔法狗，聂卫平说李世石输在了大局上，机器尚且重大局，更何况我们人呢？很多事情的确是当下的事情，局部的事情，但是如果我们站在更高的高度看当下的事情，它或许在不久的将来还有类似的事情等着我们，这就是为什么读史使人明志一样，今朝所发生的都是历史的轮回，只是换了形式，如果看到这些我们做出规划，多牺牲一部分时间换取了整体的效率，总要比用当下的高效造成整体的低效要好得多。所以，我们找出软件开发中变与不变的东西，尽可能的组件化，服务化，积累通用的工具，开发基础的服务，规范局部的开发方式，在团队中充分共享。对于个人来说，虽然做的事情很微小，但是一旦事情多了，如果没有统筹规划就会一团乱麻，严重影响效率。一个好厨子半小时可以做一桌菜，一个差厨子半小时可能一道菜都做不完，这就取决与一个人的统筹规划能力。作为开发人员，眼光不能过于短视，一定要面向未来积累，有的开发人员刚开始总是感觉慢慢的，但是最后发现他越来越快了，为什么？他慢是因为他在做积累，他前期多做了很多工作，是为了以后更快的做事。
3、团队需要不断的总结和分享。积累是一次次总结后的沉淀，每个项目要总结，每个新技术的应用要总结，每个问题的解决要总结，总结的结果最好能形成团队级的知识库，在一个团队里，一个坑不能掉进去两次，要总结其他人走过的路从而找出捷径。团队内部要多组织技术分享，将分享成为团队工作的一项重要内容，现在这部分我们做的很不够，可能考虑到工作太忙，没有时间做分享。其实不然，我们很多时候忙是因为我们没有找到好的方法而耗费了大量时间，而这些好的方法正好可以在分享中去学习，分享是将个人经验转化为团队经验的一种最好的方式。最近我们上了tita企业协作管理平台以后，大家写日志，周报，月报的习惯开始在培养，这是一个好的开始。但我提倡的总结不是简简单单的陈述一下今天干了什么，而是每天花一小段时间思考下今天的收获，遇到的困难，一些好的想法。这些内容也不要只给自己的上级看，要开放给所有人看。我们还有wiz作为团队知识库的管理，好的东西一定要总结出来，分享出来，你帮助别人提高了效率，别人自然也有时间帮助你完成工作提高效率。
谈完组织上的事，再简单说说技术方面的事情，我虽然不做技术有两年了，但是依然还是能发现我们团队的一些问题，比较突出的可以总结为：
1、相比于后端开发，前端开发严重缺乏规范和积累，UI的模板化抽象能力太弱。这个在web端和APP端表现的都比较突出。同样一个评论列表，在UI上基本上是差不多的，结果一个地方一套，要升级评论需要各个地方都要改，把它抽象出一个通用的模板，变化地方通过传参数调用来处理，这样后续的升级岂不是非常简单。
2、云端开发的标准还没有统一。app的界面总是根据接口的不同而适应，造成同样一个列表UI，APP上要开发多套，接口稍一变动，又得跟着改，又得升级，这个问题在去年年底我跟大家借鉴微信的接口开发做过一次调整，端上根据UI展现抽象出标准结构，由后台接口适应前端标准，此次改变对app的适应能力得到很大提升。接下来依然要将稳定的部分原生化改造，云接口适应客户端的标准，同时H5部分要像微信一样提供一个标准的交互标准。
3、代码还不是非常规范，我说的这个规范不只是命名方式，注释方式，而是深层的技术约定。开发框架其实就是一个深层次的约定，一个团队内部或多或少或大或小的都要有一个自己的框架约定，在这个约定下大家用同样的方式开发，语言统一了，后期就更容易协作和维护了，在一个标准下就更容易积累和广泛使用。我前几年开发camel平台的时候最核心的本意就在于此。今年也发现这个代码坏味了，所以我们启动了重构的工作，就是希望规范不仅要建立更要贯彻执行。
4、架构设计和抽象能力还比较差，从成本和效率上来讲，架构设计是为了长期过程中提升效率降低成本，不要因为前期太耽误时间，成本太大，而轻视甚至放弃。一个好的架构设计长期来看成本曲线逐步降低，效率曲线逐步升高，反之亦然。架构设计不是立马实现，而是预估未来可能及早做出准备，在这种方案的指导下，我们开发就会更加有的放矢，更有延续性。所以当一个新的产品功能，一个新的项目要做，我们不要吝啬在设计这个环节投入的脑力，设计是一个宏观的思考，只有对大局的掌控，才能将微观的事情有机的关联起来。
写了这么多，其实就像跟大家讲一个道理，要努力的工作，更要聪明的工作，努力是种态度，而聪明是种能力，能力的改变源于思维的改变，希望大家做的更好！
yongtree 2016年3月17日 有感于繁杂的开发工作给公司搞技术写的一篇博客