开发管理者们常犯之错误与解决办法

管理一支软件开发队伍无疑是一项艰巨的任务。而一旦在管理工作中囊括了组织结构职务（包括职业生涯发展与人力资源管理等）乃至团队业绩责任制度，其 难度又会更度攀升至新的量级。在这种情况下，管理者需要深刻理解其日常业绩表现，从而评估自身工作成效并推动改进举措——然而事实上，团队成员的工作内容 往往并不具备理想的透明性。而在执行相关工作时，管理者往往相当于同时扮演球队教练与比赛裁判的角色——更可怕的是，比赛规则通常并不明确。因此正如前面 提到，这不啻为一项艰巨的任务。

作为项目管理者，大家应该已经在特定时间点上——甚至是最近——对相关技术有所了解。即使从未深入了解技术方案，大家也一定对其有着长期接触并熟知 其中的大量基础性概念，至少对其抽象理论较为熟稔。不过无论如何，我们都不可能明确知晓团队中的特定成员昨天编写了哪些代码内容。总而言之，也许是由于缺 乏技术经验、也许是因为多年来未进行编程而导致知识遗忘、又或者暂时没有关注其他成员的日常工作进度，总之在管理者眼中，团队成员们的工作内容并无透明度 可言。

就像是在不了解相关规则的情况下对某种体育项目进行指导或者裁判，我们往往可以通过肢体语言及手势逐步弄清当前态势。如果团队中的全部成员都对某种 措施表达反感，那么其中一定出现了严重问题。虽然项目管理者在工作中或多或少会引入部分背景线索及调整手段，但将全部线索乃至手段纳入管理机制仍然极为困 难。在这种情况下，管理者的引导将不再是种指南——而更像是一场预先设置好的障碍训练。

在这种情况下，犯错的可能性亦会大大提高。外行指导内行总会引发无数矛盾，下面我们就将一同了解其中部分常见失误，并探讨通过哪些可行性方法——而非模糊的思路——对其加以解决。

事必躬亲

开发团队中的成员往往会不自常见地建立起一种非透明化运作流程，使得管理者感到自己失去了控制能力甚至被排除在外。面对这样的情况，我们的下意识反 应就是采取矫枉过正的举措，并试图通过多种手段尽可能提高控制水平。大多数事必躬亲型管理者并没有意识到自己存在这种问题，即他们已经成为那种“一切都要 插手介入的控制狂”。相反，在他们看来，其各项工作只是“想要真正参与进来以符合时间规划，当事情解决后我会立刻退出。”

不过问题在于，这种方式会给团队效率造成极大影响。作为管理者，这种行为可能会让你“误以为”团队效率有所提升，因为你能够掌握每项工作的发展进 程。然而，实际情况是管理者自身这时已经成为一种瓶颈。我们必须放任成员们处理任务，并接受这种不受控甚至在一定程度上无法感知的现状。这有点像拍电影， 导演要做的不是用一个个枯燥的长镜头将所有细节展现给观众。相反，管理者需要信任自己的团队——如果做不到这一点，那么管理者本身将成为比时间安排更难搞 定的大问题。因此，保持冷静与对团队成员的充足信心，他们的自治效果绝对会让你满意。

糟糕的定期会议

强迫开发人员拿出宝贵时间解释其执行细节还仅仅是毁掉生产效率的手段之一。另一种常见错误在于选择糟糕的时间点召开定期会议。编程工作要求各位参与 者始终处于流动状态，从而最大程度发挥其有效性与积极性。然而这种流程绝不能简单用上下班打卡来衡量——而是一种非常奇妙的推进状态。

很多开发人员都经历过把一整天时间用于召开不间断会议的状况，如果他们认同这种作法并将其视为提升生产效率的必要手段，那么整个氛围将非常和谐。然 而一旦以强制性举措刻意安排其参加会议，那么开发人员的情绪乃至生产能力都将受到严重影响。另外，会议的召开时间也很有讲究。选在刚刚上班时、午餐之前或 者之后往往效果更好，因为这些不会打断开发人员的既定流程安排或者工作思路。然而，一旦把会议时间定在上午10点或者下午2点，那么其结果几乎必然导致与 会者们这一整天都无法进入工作状态。

我的职业生涯基本可以划分成管理工作与软件开发工作两大类，而且我打刚上班时就意识到，自己不能总是把时间浪费在考察开发人员的生产效率身上。这种 错误常见于工作繁忙的管理者群体，即使曾经从事过技术方面的工作，他们仍然倾向于由自身时间规划出发组织会议并获取信息。很明显，这种作法会令开发者本身 付出沉重代价。因此尽可能减少开发团队会议活动并帮助其将主要精力集中在真正的日常任务上才是明智之举。

过度积极地加以激励

大家在对开发团队进行激励时，同样应该抱有审慎的态度。在这方面，最典型的例子就是开发团队管理者会设定一套自动化单元测试方案。我们不妨从这样的 角度思考问题：为什么要设定这样一个目标？是不是因为大家针对提升软件质量及降低缺陷数量进行过深入研究，而大量文章、博客乃至高人气讲师认为高测试覆盖 度正是衡量软件团队出色与否的关键？本身并不需要实际编写代码的管理者是否在努力向开发人员（需要实际编写代码）讲解如何才能更好地完成工作，并迫使他们 按照管理层的思路行事？

这就又回到了之前提到的信任度话题，不过我们为什么不让开发人员们自行找到最理想的任务完成方式？如果目标在于减少缺陷或者使发布流程更为顺畅，那 为什么不直接提出要求并允许团队成员自己找到可行途径？我很明白，大家是希望帮助团队充分发挥业内总结出的优势举措，但这种思路无法让开发人员在日常工作 中获得快乐。如果大家强行引入目标测试机制并要求团队成员遵守，那么他们最终实现的也只能是目标测试机制的部署——而非真正重要的项目发展诉求。

因此，不要过度干涉成员们的执行思路。为这些睿智的同伴们提供必要帮助，同时相信他们有能力将理想转化为现实。

信任才是关键

虽然这个主题此前已经被论证过无数次，但我们仍然值得将其作为总结陈词加以重视。大家必须信任自己的开发团队，也只有这样我们才能够实现规模扩展并取得成功。

如果无法给予信任，那么我们该怎么办？这个问题可以说见仁见智，而企业领导者的存在意义也在于此——负责制定艰难的决策。大家需要想办法让团队内的 成员在专业层面具备可信度，同时发现并雇用那些值得信赖的潜在成员。大家的主要职责应该是找到值得依赖的人员、对其加以雇用并排除包括自己在内的全部干扰 因素，从而保证他们能够按照自己的理解完成工作。我们有我们的工作，他们有他们的——这就是所谓各司其职。