技术经理这个词并非一个能够精确定义的岗位，但有一点很明确：技术经理不是一个直接贡献者，而是一个间接贡献者。
直接贡献者，又常常称之为个人贡献者（Individual Contributor），是通过施展自己的专业技能做贡献；而间接贡献者只能通过他人做贡献（Contribute Through Others），他们可能从事管理岗位，也可能是非管理岗位，常常需要克制自己直接去干活的冲动。
这里的“他人”通常是团队，既然是通过团队做贡献，那么所有的决策都应该以 “提高团队协作效率、提高技术研发效率（从而最终提高产品竞争力）” 作为最重要的决策原则。
技术经理在典型的日常工作中会涉及到多方面的内容（仅仅是涉及，不一定全程参与），大概有那么两类：事、人。本期只谈事。
第一类：技术管理
**版本管理和分支规范。**一个人写代码的时候，常常就一个仓库，并且直接master了，但是当多人协作，一定会碰到以下问题：代码仓库如何规划？分支如何划分？如何定义需求版本和技术版本？怎样做既规范又不影响协作效率？
**发布规范。**什么样的代码产品才是可发布的？发布的步骤应该如何描述？如何减少发布过程的犯错机率，如何减少系统波动？程序员们可以直接操纵线上应用吗？什么时候需要回滚？怎么设计回滚机制？
**代码规范（可能需要比较深的技术能力）。**如何规划仓库中的目录划分、配置分离、文档注释、调用风格、URL命名风格？这些设计要素都会直接影响到代码在不同开发人员之间传递、交流和讨论。
**质量管理。**需求开发流程中哪些节点需要引入测试？开发人员自测、测试人员集成测试？需要单元测试吗？需要UI自动化测试吗？如何在测试、研发速度方面寻求平衡？质量管理应该贯穿在整个产品的生命周期里面吗？
**系统监控。**功能上线后，如何通过多级别、立体的监控手段来保障运营状态？
**系统安全。**根据产品特征，它会面对哪些可能的风险？如何控制代码层面的风险？是否有必要的安全编程规范？如何控制架构层面的风险？
**容量规划。**产品的增长规模如何？是突发性的，还是持续性的？什么时候可以开始考虑扩容问题？
第二类：项目管理
**需求管理。**需求的一般流程是收集需求->评估需求->确认需求->进入开发。技术经理最需要关注需求评估环节，考察可行性、复杂度、研发成本，适当的时候做减法来保障迭代速度。
**任务分工与协作。**需求确定后，可以参与需求的拆解，基于不同工程师对代码的熟悉程度，不同的需求可以安排给最熟悉的人来做。必要的时候，可以安排给不熟悉的人来做，起到交叉熟悉的作用，未来碰到难点，也可以多一个人讨论技术方案。研发节奏方面也要注意把握，通常先出技术方案和接口定义，然后才开始写代码。
**迭代周期。**什么样的产品应该有什么样的迭代周期？例如App按惯例就是一月一版，其他网页端可以更快。紧急需求介入当前迭代周期时，应该如何调整当前的任务安排？
**内测/外测。**什么时候需要提供内部测试，什么时候提供给业务测试？业务测试应该算作外部测试（可能取决于技术和业务方的亲密程度、以及所在企业的文化）吗？
**晨会。**是否需要安排每天晨会？什么样的频率合适？
**项目总结反馈。**每期项目可以有一个复盘总结的时机。可以小规模（1、2个人），也可以大规模，取决于你要传达的信息是什么，需要谁接收信息。
**跨部门协作。**收到来自跨部门的一些技术工作，如何安排和处理。
下期预告：关于人。