从技术经理到CTO -《技术为径》读书笔记

从技术经理的能力边界，再往前就需要考虑系统的商业模式，如何变现盈利，用户如何交互和增长，其实有无限的可能性。从技术小组长的职责开始，跟管理多个团队的过程，其实是很像的，如何设定目标，监督评估执行进度，会变成更重要的事情。

无论是一对一沟通，任务拆分，通过敏捷方法快速迭代发布，还是时间管理、定义优先级，都是为了把事情做成。

技术管理的最终目标是业务成功

---

非常明显的趋势是，随着管理职责越来越大，主要任务逐渐从管理过程变成定义目标、组织资源和团队结构，要深入的理解业务，并通过技术和管理推动业务和公司在商业上成功。之后要具备在信息不完备的情况下做决策的能力，同时对决策产生的后果负责，也就是战略。

感觉越往后面越有意思，在规模较大的组织，高层必然需要跟团队保持一定距离感，这样就不会传递非预期的错误信号，因为高管的任何态度，都会被组织层级放大，所以必须小心翼翼的表达自己的观点；

有时放慢响应速度是有意义的，真正重要的事，值得说三遍，不然有可能是干扰信号或者过度反应，一旦做出决策，组织就需要调动资源应对，如果任何信号都处理，无论精力还是资源都会造成浪费，所以作者指出，应该先让子弹飞一会。

管理研发过程

---

一个复杂但有效的系统往往是从一个有效的简单系统演化而来的，一个从头设计的复杂系统是不可能正常运行的，再怎么修补也无济于事，必须从一个可以运行的简单系统开始。

管理者的首要任务，是搞清楚对自己团队的客户，什么才是最重要的，从产品和技术角度超前思考。

帮助团队成员了解哪些目标是关键的，并且能够专注在关键的目标上，每个人都应该意识到，自己应该只关注那些凭借自己的努力可以改变的事情，而忽视那些自己本来就无能为力的事，这应该就是能力圈吧。

在实际开发的过程中，哪怕响应变化优于遵循计划，团队也要培养制定计划的习惯，制定的过程，可以强迫工程师动手之前，先对项目进行深度的思考，必要的设计和思考过程，是非常有价值的。

研发时间的损耗，在现代软件开发过程中，似乎是根本无法避免的，哪怕排除非技术因素，在技术层面，也有非计划内的不可控时间开销，使得理想情况无法达到，调研、调试、联调对接、问题排查或者结构性代码重构。

作者认为，应该预留20%时间在处理这些研发可持续性工作上，我觉得这是很务实的。就算理想情况下，这些不确定性活动，也是会带来风险，影响计划的固有因素，如果计划提前识别，主动优化，不但可以更有可行性，还能通过优化债务，实现价值提升。

最重要的事情是定义目标

---

无论什么时候，定义目标都是至关重要的，尤其是管理范围更大，能调动更多资源之后，设定目标，会变成最重要的事情。

只有能够精确测量的事情，才能改进。一个管理者帮助团队成功的方式，是创造一个清晰，针对性强，以及可衡量的目标。

而最好的管理，就是团队不断打胜战，制定小型目标并且不断取得胜利，是人类获得成就感的重要方式。

为此要把复杂的最终目标，拆分成小目标，并且以最高效的方式排序，识别依赖关系和优先级至关重要。

如果设定了目标，就必须想尽一切办法实现这个目标，而不能只是等待，直接说出来，往往是推动事情发展的最快方法。

从技术小组长到CTO

---

技术小组长不仅要继续交付高质量代码，还要承担作为技术代表与管理层合作的职责，还要通过项目管理能力，将大型项目拆解为一个个小型项目。

技术经理需要向技术团队交付一系列定义清晰，实现成本合理的产品需求，同时向产品团队解释清楚完成所有需求所需要的额外时间。

技术总监的工作重心是保障复杂业务需求的持续顺利交付，为此要持续评估和优化内部开发流程和基础设施，以便团队能持续高效交付业务需求，构建高效灵活的团队结构，根据业务需求发展，不停迭代技术团队内部流程。

CTO，应该思考公司长期发展，帮助公司制定未来业务计划，以及执行细节，将长期战略转化为实际可执行的计划，对问题进行拆分并指挥具体执行过程。

越往上，管理的职责会越来越接近产品负责人，最终承担如何让业务成功的目标。

如果您喜欢这篇文章，欢迎关注我的公众号【软件十书】，获取更多精彩内容，点击阅读原文。