一个好的技术领导者真的可以为公司省很多钱，可以保障产品的质量。自己在这条路上还有很多路要走，现将自己的一些感悟记录下来。
一个优秀的团队，首先要有靠谱的成员，至少核心成员要靠谱，要有主见，要想当“将军”，这样他才能带好手下的兵。
一个优秀的团队，需要好的规范，无规矩不成方圆，有了规矩，大家都按照规矩来做事，能减少很多不必要的麻烦，不会让成员觉得无所适从。
开发流程
需要的工具：
文档管理工具
团队的产品、设计、技术文档进行整理归档，随着版本不停的迭代，团队成员进进出出若干，如果没有这些文档，会需要很多时间跟新同事交代哪里哪里是干嘛的，哪里哪里需要注意什么。有了这些文档，一方面方便新来的同事，一方面也是对现有技术的沉淀。
文档分为：
- 公共文档：用来存放团队所有成员都应知晓的事情，比如团队的开发流程，各个岗位的指责，一些规范注意事项等；
- 产品文档：用来存放产品的版本迭代详细文案，使用说明等；
- 设计文档：用来存放PS源文件，sketch源文件，sketch导出的html文件，设计规范等；
- 技术接口文档：存放不同端的API Docs，方便其他端同事查阅，特别是后端接口文档，非常必要；
- 技术博客，技术上的沉淀能反映出一家公司的技术底蕴；
- 各种release包的存放，方便以后使用，有时候需要找到很老的版本找不到的时候会很痛苦的。
如何进行管理：
目前的做法是将文档统一存放到服务器上，服务器通过配置Nginx指向不同的文件夹，配置不同的域名分别表示各种类型的文档。
项目管理工具
- 项目整个周期的时间规划；
- 任务的分派，所有人都应该把自己的任务规划好计划开始、结束时间，实际开始、结束时间；
- 项目需要一个人来跟踪进度，每天汇总、统计，同步给项目相关的所有人，发现问题及时调整；（这样做的目的是让大家彼此知道大家的进展，督促自己按时完成自己的任务，管理人员也好根据实际情况调配）
自动构建、持续集成工具
Jenkins自动构建，比起本地构建，不依赖个人机器的环境，相应有权限的人都可以进行构建。
Bug统计、管理工具
友盟等第三方统计
持续部署工具
Docker Kubernetes
技术管理
OKRs
制定目标，目标拆分，制定关键节点，核对结果。
Review Code
代码Review，提升代码质量
Unit Test
单元测试，减少bug数
技术分享
技术沉淀
一些感悟
金无足赤、人无完人，想要团队内所有的人都积极主动，把工作当成自己生命中很重要的东西是很困难的。所以才需要管理，需要规则。让大家努力工作的几个核心：
- 赏罚分明。且要加大力度，如果做的很好，才奖励几百块，出了事故就批评一下；会让大家变的不在乎。所以一定要加大赏罚力度。让大家感觉有奔头，比如如果能完成全年KPI，奖金就能超过基本工资，那大家一定会想尽办法来完成它。
如果出现严重的bug，会严厉批评，扣奖金；更严重的会让你直接走人。那么大家就会重视自己的每一行代码了。 - 比较强势的团队文化。一个好的团队，是需要狼性的，为了目标就应该全力以赴。而不是拖拖拉拉。当然，适当的调整也是有必要的，如果一直在强压力工作下，人也会受不了的。这是相辅相成的。
关于需求变动
在日常开发中，需求的变动是很正常的。但因此带来的影响则需要好好分析，而不是一味的来了需求就安排。正常情况下，每个周期的需求定好之后，团队中所有人的工作安排应该都是100%满负荷的。如果在开发过程中，有需求
要修改或者新增，则要么版本的周期进行调整，要么大家加班加点把它做完。在这里，我会先评估改动对整个周期造成的影响，如果影响并不大，则会安排人员在周期内进行消化；如果消化不了，也是不建议修改版本周期的。如果
因为个别的改动，造成大部分人的影响是不值得的。比如，开发团队30人，新增的需求需要3个人开发3天，如果将周期延后3天，则其他27人是要重新安排工作的。如果经常出现需求变动的时候，就应该思考需求提出者是不是没有
把本职工作做好。
按职能还是按业务来分配子团队
不同人数的团队
如何进行良好的沟通
所有事情有开始有结束。当你把一件事情交代给某一个人时，首先要描述清楚自己想要的结果，然后让对方明确是否明白，再确认最后完成时间。作为收到任务的一方，也应该把自己的理解表达清楚，双方达成一致；最好能在deadline之前就找需求方告知结果，而不是踩着时间线甚至延期告知。
如何带新人
对于刚进来的同事，应该准备一份详细的注意事项。比如我们的开发流程是怎样的；有那些账号需要申请，申请流程；常用的工具，工具的使用文档、下载地址；还有许多平常开发中常见的问题。有这样一份文档，新人也不需要一遇到问题就来找你，也节省了你的时间。