谈软件项目中的外行管理内行

掘友的一个评论，让我又想跟大家唠会儿嗑了。

我之前写过一篇文章叫《该写好代码吗？我也迷茫了》。于是，这位掘友评论说，他在上家公司的时候，他们组代码质量要求高，前期设计考虑全面，所以上线后问题少。但是在领导眼里就像没事做一样。其他组经常出事故，反而很忙，像是一直在攻克难题。

我回复说：那可能是领导不够专业，没有深入到项目里。

回复完了，我仍然意犹未尽。于是，才有了这篇文章。

正常情况下，对于一个软件项目或者一次版本迭代，负责人应该是心中有数的。这个项目的难度如何？手里的人员能力如何？大约做多长时间？最终会达到什么效果？这些应该是负责人的基本功。我不自夸，反正我带项目时，我们几个负责人都是能做到的。

据此，你才能更好地把握一个项目的始终。有时，项目中间出现难题，要干预。有时，大家超额完成，要嘉奖。有时，很简单的功能，他开发出了很多bug，要扣奖金。甚至有时候，一个月的工期，老板硬要半个月完成，这时对结果不能要求太高，你不能又要做完又要做好，那是找打的节奏，最终会两败俱伤。

但是，存在一种叫“外行管理内行”的情况。这类领导呢，他不知道你干了啥，也不知道对你来说这活好不好干，甚至你干没干完他也分辨不出，全靠读你的周报和计划。但他却是你的分管领导。

我原本以为，在技术领域不会存在这类情况。后来发现，不但有，居然还很普遍。而且在国内，这还是一道别致的景观。

听过一个报道，说国内有一位教授，他从国外买来高端芯片，先把标志磨掉，再印上自己的Logo。然后，他对外宣传是自主研发的。出人意料的是，他还开发布会，还拿到了上亿的科研资金。随后几年，他甚至还推出了第二代、第三代、第四代，都是通过自己印标签的手段完成的。

整个过程，但凡有内行审一下图纸，看一下生产车间，都会很容易识破骗局。

当然，咱们普通人一般到不了研究芯片，那么高精尖的层次。但是，我觉得作为一个普通企业的小领导，参与到项目中，这总是可以的吧。

从实际情况来看，其实很少有领导能躬身入局。哪怕这个领导只管六、七个人，他也会再分成三四个组。遇到一项任务，领导会安排给员工，让它们去协商完成。而他，要去规划团队未来的发展。

我有种很明显的感觉，但现在还找不到一个合适的名词来描述它。只能从一些例子上去体会其中的差异。

我有一个任领导，开周会是他做总结。他说这一周，后端完成了什么，前端没有完成什么。前端还反驳他，说自己完成了。领导说，别糊弄我，你只是把接口地址敲上了，根本没调用过，你跑跑试试，数据结构对不上。他是最了解整个项目开发进度的人。

还有些领导与他形成鲜明的对比。他们了解事情靠开会听汇报，就算只有三个下属，也要他们说说这周干了啥。他做一下汇总，然后再上报给他的领导。功能交付后，项目出现了问题，他会说是下属欺骗他，居然谎报工期，没测说测了，没做说做了。

至于形成这种区别的原因，可能跟文化和制度有关。不能说哪种绝对好或者不好。

前面那种“严管型”领导所在的公司，企业文化中，负责人制，不讲理由。出了问题不要推脱是张三、李四没做好，他们担不起这个责任，就是你负责人的问题。所以，这才导致了领导会落实每一项流程。

后者那类“汇报型”的企业，从上到下都注重文书的格式、措辞，讲究高瞻远瞩，着眼未来，允许试错，探索创新。因此，他们便将更多的精力投入到了汇报上。

作为一名老程序员，我感觉，软件开发是一种很工程化的工作，一层层拆分好，安排到基层人员手里，告诉他们如何执行就可以了。但是新一代领导说，管理的最高境界是让团队具备自驱力，硅谷就是这样的。自驱力就是你不用安排，他们自己就能主动克服困难去完成。即便领导不在，团队也能照常运转，这才是健康的团队。

抱歉，有点儿跑题了。

本文的初衷是“外行管理内行”与“躬身入局”。

我觉得“外行管理内行”在国内是必然现象，尤其在技术领域。

在国内的中小企业，作为团队的领导，“行政类”的事情要比“专业类”多。你看看你的领导，他经常开会和写材料。这不是它自己要干的，也不是老板要求的，是受行业和环境的影响。你想要申报科技企业，申请政策扶持，参加高新评级，你就得去准备。

除此之外，团队的日常管理，年计划、月计划，人员流动、评优、优化等等，都会耗费日常的精力。而这些活，专业的程序员并不想干。

另外，就算一个内行被推上管理岗位，程序员工种复杂，知识更新也快，那他干上几年，也会慢慢被磨成“外行”。

因此，内行外行只是相对的，并不重要。我则更强调“躬身入局”。

躬身入局，就是参与到项目中。就算不写代码，起码也了解下大家遇到的问题。在这个过程中，作为管理者，可以制定一些规则和标准，来保证良性运作。好的流程制度，是可以实现员工自驱动的。

举一个身边的例子。现在夏天了，天气很热，办公室都会开一天的空调，温度调到23度。

这天下过大暴雨，空气清爽，气温很低。这时，23度的空调就很冷了。正对着空调口的瘦同事，就想去关掉空调。结果被一个静止都会喘粗气的大胖子给制止了。

胖子问：为啥关空调？

瘦子说：外面下雨，不热了！我冷。

胖子说：你冷你穿衣服。你关了我热。

瘦子说：你热，你打开小风扇。

说完，瘦子关了空调。 随后，胖子又打开了空调。

这类事情就是公说公有理，婆说婆有理。搞不好还需要领导出面调停，或者搞一个群体性的投票。如果没人理你，那就看谁的底线更低，或者说谁更狠。

但是，如果说团队制定这么一个小规则，就是室温超过26度可以开空调制冷，制冷底线是23度。那么，即便没有领导在场，大家也能很好处理此类事情。甚至，这类情况根本都不会发生。

这只是为了体现规则重要性的例子。到软件开发中，可能就是比如这类情形：一个接口如果多个端都调用，那么就由后端组织特定的数据格式。

如果你躬身入局，你就会经历类似的事情。否则的话，你可能会说，吵什么吵，大家要以大局为重（只是要求停止争吵，没有决定开不开空调）。

可能说这么多，有人朝我笑了：你以为我傻？我这么做，老板给我涨工资，多拿钱！

抱歉，抱歉！我只想着如何提高项目质量了。关于挣钱方面，我外行了！

唉，大家一定要重视环境的重要性。