梦想一定要有

两年前，刚走出校园，怀着迷迷糊糊的工作梦走进了现在这家公司，依稀记得面试时，面试官问我近期的计划是什么。我当时说想当个组长，现在想想都觉得有点好笑，笑自己的那份狂妄和天真。今年6月，由于一些因素，我开始全面接手 Android 团队的管理工作，在这半年管理中，主要展开了这些工作：健全团队建设文档、开站立会议、代码审查、技术分享、搭建团队基础框架和自动化构建平台等。

团队建设文档

看一个团队是否成熟，只要去看它的团队建设文档就够了，无规矩不成方圆。在这个个性张扬的时代，谁都想表现得不一样，这本来没错，但在一个团队协作中，没有一定的规范约束，大家就会乱来。这里列出团队建设中我觉得必要的文档。

开发命名规范

团队开发中，统一开发命名规范，可以减少组员之间交接和沟通的成本，代码规范没有严格的好与坏，只要做到见名知义，方便梳理即可。

项目结构规范

今年 MVP（Model-View-Presenter） 特别火热，甚至 Google 都出了自家的 MVP 规范，目前市面上的 MVP 规范数不胜数。是否 MVP 能完全取代 MVC（Model-View-Controller），其实没有绝对之说，适合自己的才是最好的。确定了开发架构后，就把该架构对应的项目结构细则整理成文档。

项目文档管理规范

一个 App 从需求到部署上线，会有产品组、项目组、开发组等的参与，每个阶段各组都会产生相应的文档，将它们用 SVN 的形式整理起来，形成了项目文档，开发期间不仅方便跨组沟通，而且有利于项目后期的维护和交接。

项目发布规范

项目发布这一步特别重要，稍有不慎就会酿成大错。特别是像服务器地址、商品价格、支付流程、签名、证书等这些信息要检查正确。

版本控制策略

不管是 SVN 还是 Git，多人协作总得有一套版本控制策略。本人比较推荐使用 Git，分布式、功能强大方便。Git 的版本控制策略可参考「A successful Git branching model」

站立会议

开会是很多程序员都不喜欢的，有些喜欢在讨论组开会，效率不高。站立会议，总结昨天，计划今天，只需10 ~ 15 min，简短高效，执行以来，效果甚好。

代码审查

如果你觉得有了「开发命名规范」和「项目结构规范」，组员的代码就会按照上面的规范写好，那真的是太天真了。所谓 5% 在策略，95% 在执行，组员的代码须通过代码审查不断纠正。一般老员工代码相对规范，不需过多审查，可由老员工审查试用期童鞋的代码，组长不定期抽查。代码审查工作可借助 GitLab、Gogs 等第三方平台，把不符合规范的代码打回重做。但这种形式的审查效果有点粗糙，所以我要求项目主负责人每周整体过一次搭档代码，找个时间统一修改完，这样效果会更好。

技术分享

每周技术分享，说来惭愧，搞了 2 个月就夭折了。究其原因，一是团队比较年轻，技术积累较少，技术分享质量不高，二是组员积极性不高。后来就改为不定期技术分享，但是这样一来很少人主动技术分享，一方面是项目赶，另一方面是主动进修的人不多。

团队基础框架

以前在 W 团队时，听他们说过，只要把「骨架」搭好，以后想变肥变瘦就轻而易举了。这里的「骨架」就是团队基础框架，它包含了大多数项目必须的功能，如网络请求、缓存、数据库操作、通用自定义控件等，只需简单配置就可以使用，避免重复造轮子，提高开发效率。

自动化构建平台

手动打包 -> 上传到 SVN -> 通知测试人员测试，好重复的动作，电脑也不给力，浪费时间。这些操作目前都过自动化平台解放双手。

自我反省

当上管理层，最大的感受是责任感变强了。毕竟不再是小喽喽，组员的问题，就是我的问题。所以一直不敢怠慢，想方法去管理好团队。经过所有成员半年来的努力，团队逐渐走向规范，这特别让我欣慰，但我管理方面的能力还有待加强，目前发现的问题是给的压力不够、监管不严、手软等。2017 年，希望在管理好团队的同时，开始涉略产品方面，生活上多去接触周边人，不能太孤独，工作可不是作生活的全部，人生还有很多事没做，比如交女朋友哈。