一番码客 : 挖掘你关心的亮点。
程序员的职业发展道路基本分为三个方向：
因为完成大型项目，需要协同工作，因此就需要技术管理。
技术专家和技术管理可能界线比较模糊，能做到技术专家往往是善于自我管理者，将自我管理的方法扩展提升一下便扩展为团队管理。很多架构师、技术负责人都会同时担任小组组长甚至技术部门负责人。
也有一些技术很厉害，但很讨厌管理工作或者管理能力比较差，喜欢做技术的单纯，那就发展为单纯的技术专家，这种似乎国外比较普遍，四五十岁的资深程序员。
作为技术管理，最常见的就是要细化需求，分派工作，管理成员的工作量。
不熟悉业务的管理者，经常出现会说：
产品说明天就要，这个功能很简单，紧急做一下，应该花不了多长时间吧？
真正交付的人便会清楚，最终的交付不仅仅是交付基础功能，还要考虑调试时间、兼容性、可扩展性、可维护性、可靠性等等。所以技术管理者评估工作量的时候需要考虑这个任务需要做到什么程度，不同程度的交付分别需要多少的工作量。
否则成员便会抱怨：
你们这些做管理的，怎么总感觉做什么都很简单，总嫌我们做的慢、工作量不饱和。YOU CAN YOU UP。
初期管理者便会想：
有那么难吗，我来就我来，你不行我自己来。
最终导致自己忙的不可开交，黑夜里办公室总是技术管理孤独的身影，最终交付也不理想。
因此，技术管理，偶尔写写代码，实现一个功能，可以保持对工作量的具体认知，感受成员的实际工作状态。
如果技术管理者总在实现具体的技术细节，那部门交付一定会出问题。
技术管理，需要宏观把控，团队的技术能力培养，总体任务交付的节奏，开发过程的管理，部门间的沟通协作，这些才是技术管理的主要工作。每个人的精力都是有限的，总是在做具体的技术细节实现，整个团队的管理一定会出问题。
好的产品除了基本功能的实现，还需要注重细节，所谓细节决定成败。对细节的敏锐程度，需要技术管理者有过实际的开发经验，知道细节需要做到什么程度。不需要对每个技术细节都很清楚，但需要管理、评估技术细节。
对于软件行业来讲，偶尔做一些具体的代码实现，可以保持对细节的敏锐感。
试想一下，如果技术管理者说：
任务都交代下去了啊，你们好好干，我先下班了，明天我们对齐下进度。
具体做事的成员要么心中万马奔腾，要么各自开溜。
更好的方式当然是有难同当，有福同享：
这个功能明天要交付，时间很紧，我们晚上一起攻关下。
因此，技术管理者，不应该只是任务的分派者，应该保持一定的业务能力，困难时刻可以与成员风雨同舟。
今天写这篇文章刚开始只是一些零星感悟，早上要真写起来，发现成文还是很难，但最终还是写出来了，一方面整理了对这个问题的思路，一方面也对自己的工作做了一些总结回顾。
一番雾语：先上路，才知路难易。
微信公众号：一番码客
免费知识星球： 一番码客-积累交流
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.
