不喜欢被管理的程序员，你能做好自我管理吗？很少看到有人对于公司的管理制度表示赞

作者｜周明耀编辑｜小智很少看到有人对于公司的管理制度表示赞赏，要么是不满考勤、要么是不满 KPI、要么是不满绩效。很多程序员觉得，对于程序员最好的管理就是什么都不管，让他们做好自我管理。但自我管理真的是那么容易做的吗？作为程序员的你，觉得这样的管理方式有效否？写在前面

最难管理的人是自己。我们每个人都善于，也喜欢否认自己的弱点或者坏习惯，对于自己做得不够好的地方总是避重就轻。我自己以前也有这个毛病，每次领导谈话，总是给自己找很多理由，不多谈自己做得不好的，或者明显是能力弱项的内容，其实这样很不好，职业发展过程中你不能重视依赖于别人的容忍，你总是会遇到想要挑战你的人，所以，不断加强自己，才是王道。

自我管理，具体来说，需要做好时间管理、能力成长管理、沟通管理、以及形象管理，同时，也要避免过度管理。

时间管理

一般意义上的个人管理，是为了更高效、更方便地实现自我提升而建立的一种相互作用、相互促进的价值观、决策判断、思考模式、任务流程、生活习惯等一系列世界观、方法论形成的有机整体。简单来说个人管理系统就是一个有机整体，是世界观和方法论组成的整体，构建这个整体的目的是为了实现自我提升，这个整体里包含了个人价值观、对事情决策判断的方法、个人思考模式、固定的流程体系，以及健康的生活习惯等。

我记得刚开始做 Leader 时，我没有理解这一条，我的美国领导和我说，麦克，你一天最多最有 12 小时在工作，你得充分利用整个团队的时间，不能只有你一个人在干！当时的我并不理解她的话，还把这样的建议当成笑话，后来逐渐发现，做好自己的时间管理，做好团队的时间管理，本身两者是统一的，做得好，则时间变成了 N*M。

要有效地管理时间，首先需要有效地管理自己的时间，毕竟每个人一天只有 24 小时，真正的工作时间只有 10 小时左右，首先需要实事求是地评估自己的工作习惯，需要非常清楚地理解自己的工作目标，只有这样才能明确哪些工作需要自己亲自做，哪些工作需要自己承担组织和指导作用，哪些工作需要指派下属负责，哪些工作需要验收，然后确定自己每天的工作内容，最好是能够反复思考，最后以天为单位实施自己的每日工作计划。

能力成长管理

个人能力成长分为技术成长和业务成长。我们这里只谈个人的综合能力，沟通这样的管理能力我们放到后面单独讨论。

个人技术成长对于一名程序员来说至关重要，当有一天你想成为管理者，或者已经成为管理者时。你要知道，你管理的这群程序员，他们从小到大可能是学霸，不是随便糊弄的！成功地管理程序员最重要、最关键的因素，是得到被你管理的下属的技术尊重（对于同级别的同僚之间也是如此）。如果没有技术尊重，那么你的每一个具体想法，都可能会遇到主动或者被动的阻碍。正是由于这个原因，那些在职业生涯的某个时期没有做过程序员的团队管理者，才会觉得有效地管理程序员是一件极其困难的事情。技术尊重来自日常点滴的技术成长，一点点积累，你才会逐渐成长为大牛，而只有保持自己作为大牛，你才能在这个行业一直做下去。

对于业务成长，首先应该明确业务、架构和技术之间是共生的关系，而不是互斥的关系。技术人员很多时候所关心的技术，和业务的主要目标往往不是直接对应的。业务是负责某一部分的业务，只是业务架构树的分支节点。只有直接解决业务问题的那个技术或业务，也就是树的根节点，才会和业务直接相关。由于业务和技术属于两个不同的树，也就是说有两个不同的根节点，因此只有沟通才能解决问题。

技术总是在人类对业务目标要求不断提高的情况下产生，其目的是为了获取更大的利益。所以：

技术是为了解决业务问题而产生的，没有了业务，技术也就没有了存在的前提；

有了更好的技术后，效率较差的技术，就会慢慢地被淘汰，从而消失，一切都遵从人类的利益诉求。

也就是说，先有业务问题，才会有技术来解决业务问题。而业务的长达要求，提高了对技术的要求，导致了对业务生命周期的拆分，以并行的方式提升效率，形成了架构，也形成了新的技术。

讲了这么多，你明白了吧，做好自己的业务管理，我知道这很难，毕竟又要学技术，又要学管理，还要学业务，很累！但是我们这个行业，只相信实力，不相信眼泪，加油吧！

过度管理

切记，造成任务延迟和团队混乱的最主要的原因之一，就是让自己直接管理过多的下属。我在过去的十几年一线团队管理过程中，逐渐地学会了一点，那就是不要让自己直接管理的下属超过 10 人以上。无论团队由多少人组成，你都应该细心观察每个人的工作能力和责任心，逐渐综根据综合能力划分人员层级，第一档次是团队核心成员，第二档次是团队较重要成员，第三档次是团队一般技能人员，第四档次是团队可有可无的成员。如果团队成员大于 10 人，你就可以考虑采用分小组形式间接管理，而小组长可以从第一档次或者第二档次里面挑选，这样你的团队就可以有了一个良性的金字塔型结构。

为什么需要分小组？因为随着控制范围的扩大，管理者与下级的交互次数（以及由此产生的指导）会呈几何级别增长。这个说法需要考虑到管理者与下级、下级与下级以及管理者与所有下级组合之间的交互，并且假定花在指导上面的时间与交互的次数成正比。例如，你有 4 个直接下属，在增加第 5 个直接下属时，完成更多工作的可能性会上升 20%，但是交互的次数则可能会从 44 增加到 100，增加了 127%。直接管理 8 个下属可能需要 1080 次交互，直接管理 12 个下属可能需要 24564 次跟进管理！

沟通管理

这里我们所讨论的沟通管理分为被动沟通和主动沟通。

首先说说被动沟通，既然是被动沟通，那么一定有很多的信息是从外部摄入的。技术的进步创造了很多沟通途径，远远超过了我们的处理能力。我们可以数一数信息来源，电子邮件、短信、博客、微博、微信、社交网络、Skype、RSS 订阅以及其他技术，已经渗入到了我们的生活当中，而这在几年前是不可想象的。我们已经成为沟通泛滥的奴隶，这些沟通方式似乎降低了我们的整体生活质量。

我认为，要想成为一个有效且高效的技术团队管理者，你必须建立机制来控制和管理洪水般的信息，不能让它控制你！我有一些建议，你看看是否有效：

制定一个靠谱的办法或者流程管理你工作上的电子邮件，不能让接二连三的电子邮件分散你的注意力。

别人打电话或发短信给你时，你不必一定答复或回应。

在会议上或在其他需要的时候，尽量关闭电话，不要让电话或短信转移你的注意力。

如果需要，可以委托助理管理会议议程、整理会议纪要、联系会议参与人。

仔细规划你的时间，以减少受到需求和信息的洪流冲击。

尽量少拉微信群，其实没什么大用处，不如大家通过 Conference Call 形式直接说清楚，然后通过一个电子邮件进行后续的进度管理和问题解答。

前面讲的是对于被动沟通的管理，现在聊聊主动沟通，也就是我们主动发起的沟通。我觉得既然是我们主动发起的，我们不讨论沟通技巧，已经在向下管理里讨论了，这里我希望你能够在沟通时注意以下几点：

沟通时关注对方，放下你的手机，停止处理电子邮件或写代码，坐下来，看着说话的人。用眼神交流，仔细聆听对方在说什么（并思考他们呈现的信息）。注意，信息并不局限于他们的话语，观察他们的姿势、身体语言、热情或专注的程度。留意一切信息，通常语言之外的线索反而是最能说明问题的。

谈话时隔着办公桌，或者隔着任务其他东西，都会让人不舒服。

许多人认为管理是自上而下的，具有权威性的地方，也就是说，处在金字塔的顶端。虽然我们的组织结构是这样的，但是在一家科技公司，建议你把自己看成是处于金字塔的底部，而你的员工在顶端。他们和他们做的工作才是真正重要的。

多听、少说。亚里士多德说过智慧是您一生从聆听而非说话中所得的奖赏。

形象管理

“人靠衣装”这句话其实需要好好思考。

我们程序员出身的人，衣着都很朴素，这一点确实是这样的，夏天穿个无领的 T 恤和七分裤，冬天穿件大棉袄，好像几年不洗的样子，平时胡子拉碴的，也不会喜欢戴个手表，因为戴着手表敲代码很难受。总之，很多团队负责人都是这样很随意的，完全没有衣着规范或者个人卫生标准。我想说的是，在团队内部其实这样问题不大，但是如果你去参加技术会议，或者去见客户，或者出席高层会议，如果你看起来邋里邋遢，那么你需要尽快改变一下了，让你老婆带你去买几件衣服（如果你有老婆的话），好好整理一下自己，毕竟高层或者客户一般都会在乎这些，除非也是技术出身的高层，才有可能理解你。

写在最后

好了，今天我们讨论得不少了，时间管理、能力成长管理、沟通管理、以及形象管理，还有避免过度管理，希望对你能有所帮助，只有做好自我管理的人，才有可能在事业上更上一层楼，加油，也希望你能提出自己的问题，我们可以线上交流！

今日话题

为什么你不喜欢被管理？被管理会影响到你的码代码效率，还是会让你写出更多的 bug？

如果只提倡自我管理，不做硬性的规定，你觉得这样的技术团队最后会是怎样的场景？

作者介绍

周明耀，2004 年毕业于浙江大学，工学硕士。13 年软件研发经验，近 10 年技术团队管理经验，4 年分布式计算、大数据技术经验。出版书籍包括《大话 Java 性能优化》、《深入理解 JVM&G1 GC》、《技术领导力 - 码农如何才能带团队》，个人公众号“麦克叔叔每晚 10 点说”出品人。个人微信号 michael_tec。

今日荐文

点击下方图片即可阅读

禅与互联网技术：龙泉寺的程序员们

还没看够？

扫码或戳 阅读原文 解锁更多技术神器▽