做技术管理了，还要不要写代码

一番码客 : 挖掘你关心的亮点。
http://efonfighting.imwork.net

前言

程序员的职业发展道路基本分为三个方向：

1. 技术转技术专家：架构师、技术负责人。
2. 技术转技术管理：小组组长、软件项目经理、技术部门负责人、公司技术负责人CTO。
3. 转行：产品经理、市场销售等

因为完成大型项目，需要协同工作，因此就需要技术管理。

技术专家和技术管理可能界线比较模糊，能做到技术专家往往是善于自我管理者，将自我管理的方法扩展提升一下便扩展为团队管理。很多架构师、技术负责人都会同时担任小组组长甚至技术部门负责人。

也有一些技术很厉害，但很讨厌管理工作或者管理能力比较差，喜欢做技术的单纯，那就发展为单纯的技术专家，这种似乎国外比较普遍，四五十岁的资深程序员。

工作量评估

作为技术管理，最常见的就是要细化需求，分派工作，管理成员的工作量。

不熟悉业务的管理者，经常出现会说：

产品说明天就要，这个功能很简单，紧急做一下，应该花不了多长时间吧？

真正交付的人便会清楚，最终的交付不仅仅是交付基础功能，还要考虑调试时间、兼容性、可扩展性、可维护性、可靠性等等。所以技术管理者评估工作量的时候需要考虑这个任务需要做到什么程度，不同程度的交付分别需要多少的工作量。

否则成员便会抱怨：

你们这些做管理的，怎么总感觉做什么都很简单，总嫌我们做的慢、工作量不饱和。YOU CAN YOU UP。

初期管理者便会想：

有那么难吗，我来就我来，你不行我自己来。

最终导致自己忙的不可开交，黑夜里办公室总是技术管理孤独的身影，最终交付也不理想。

因此，技术管理，偶尔写写代码，实现一个功能，可以保持对工作量的具体认知，感受成员的实际工作状态。

宏观把控，管理细节

如果技术管理者总在实现具体的技术细节，那部门交付一定会出问题。

技术管理，需要宏观把控，团队的技术能力培养，总体任务交付的节奏，开发过程的管理，部门间的沟通协作，这些才是技术管理的主要工作。每个人的精力都是有限的，总是在做具体的技术细节实现，整个团队的管理一定会出问题。

好的产品除了基本功能的实现，还需要注重细节，所谓细节决定成败。对细节的敏锐程度，需要技术管理者有过实际的开发经验，知道细节需要做到什么程度。不需要对每个技术细节都很清楚，但需要管理、评估技术细节。

对于软件行业来讲，偶尔做一些具体的代码实现，可以保持对细节的敏锐感。

以身作则

试想一下，如果技术管理者说：

任务都交代下去了啊，你们好好干，我先下班了，明天我们对齐下进度。

具体做事的成员要么心中万马奔腾，要么各自开溜。

更好的方式当然是有难同当，有福同享：

这个功能明天要交付，时间很紧，我们晚上一起攻关下。

因此，技术管理者，不应该只是任务的分派者，应该保持一定的业务能力，困难时刻可以与成员风雨同舟。

参考

• 技术总监到底要不要写代码？
• CTO 到底应不应该写代码?

一番今日

今天写这篇文章刚开始只是一些零星感悟，早上要真写起来，发现成文还是很难，但最终还是写出来了，一方面整理了对这个问题的思路，一方面也对自己的工作做了一些总结回顾。

一番雾语：先上路，才知路难易。

免费知识星球： 一番码客-积累交流
微信公众号：一番码客
微信：Efon-fighting
网站： http://efonfighting.imwork.net