晚上又加班到现在，没多少时间写技术随笔，刚又在架构栈上看到这篇文章感觉不错，就再发一下。
说到底提升战斗力的关键还是明确组织架构和每个人目标，带头师范行动，加强沟通反馈，大家心往一处想，劲往一处使。
1. 明确的职责和团队架构
对一个技术团队管理者而言，最需要做的一件事就是明确每一个工程师的职责和建立组织架构。职责的关键是：谁负责什么内容；团队架构的关键是：谁在什么位置，一定要足够清楚。
对于一个技术团队，“清楚”的意思是：
同一个服务/功能只有一个负责人
一条邮件/短信报警，能准确找到一个负责人处理
每一个对外暴露的API都能找到对应负责的工程师
...
在这里，我还可以列举出很多条目，简单一句话，出了问题，每一个人都清楚谁应该出来承担责任。取得了成绩，该给谁颁奖也很确定。
2. 研发流程可视化
技术团队一旦超过20人，一个明显的感受：你开始看不到问题。已经无法靠简单的晨会和口头同步来暴露问题，这和业务团队的每天销售业绩很不一样，技术团队表现出来的数据是多元化的。
所以，组建一个可视化的工具和流程的组合是必须的。这样团队每天的表现都能被清晰的观察到，并且随着团队的发展，有足够的可扩展性。
比如
github 可以让我看到每个程序员的每一次 commit 。
JIRA 可以让我看到每一个Release的推进过程 (有多少bug, 多少个任务已经进入提测，然后准备上线。。)
Jenkins可以让我看到整个团队的项目构建情况。
钉钉/微信群可以让我和团队做到实时沟通。
Confluence 上的技术/方案文档可以让团队每个人对项目的状况一目了然。
Zabbix/Grafana可以让我每天一大早看到所有服务的运行情况，了解所有交易数据的情况，保证我每天可以安心的睡觉。
ELK/CAT跟踪所有服务的错误日志
....
即便我不会每天都去关注这些，但是我需要有看到这些的能力。这样才能在出问题的时候掌握第一手资料，并每天确认是否团队中存在任何问题和风险，并指导团队提升执行的效率和质量。可视化的工具和流程，保证团队用最低的成本了解项目中的“新鲜事”（Yes, it's interesting!），保证团队能快速准确的响应任何突发状况。总之，我需要达到“信息的对称”。
3. 带头要结果，不要借口
我一直认为在技术工作中，只会有两个结果：搞定，或者没搞定。
所以对于团队的日常的项目推进，如果遇到技术难题，被block住了没搞定，我只想听工程师试过什么方案？每种方案遇到的问题是什么？离我们目标的距离在哪里。如果需要更多的时间或者需要更多技术方案，告诉我，我来和大家一起想办法解决。
线上出现生产故障了，中间的“狗血”情节，其实不用给我汇报。事故已经发生了，事后汇报没有任何意义，我只需要知道现在状况是怎样，我们一起想办法，用最快的速度fix掉。
4. 明确的目标，并给予团队对应的权力
作为一名技术管理者，无论是技术的基础设施建设还是团队技术的发展方向，都需要给出足够明确的方向，及时向全员传达，并坚持长期贯彻下去，让团队每个人都清楚。
明确了要求，就要放权和投入资源给团队。否则，出了问题责任不是他的，而是我自己的。相信我的团队，即便是出现了差错，也要给予支持，和团队一起分析原因，下次做到更好。
技术管理者的重要职责，就是为团队解决他们解决不了的问题，同时提供对应的权力和资源给他们。