【创业新闻】我是如何失去对团队的控制的

我当一个不合格的技术总监已经快三个月了。 我从40多人的研发团队（包括需求、开发、测试）中带了20多人来拓展公司的版图。 这近三个月的时间，我们一起努力。 过程中我熬夜了半个多月。 工作到凌晨4/5的日子不计其数，工作到凌晨1/2的日子更是常见。 整个团队绝大多数人几乎两个月没有周末，异常辛苦，也是真正的巅峰体验。 但三个月后，我带着失败和惨痛的教训回到了公司。

在这次经历中，我感受到了我是如何失去对团队的控制的。

我所说的团队控制，并不是说兄弟们不听安排，不按计划行事。 相反，我对整个开发团队、测试团队和需求团队有了新的认识。 我重新认识了这个团队，重新认识了这20多人。 这个惨痛的教训是由于对个人和团队的能力以及项目难度的判断失误而造成的。

我将与大家分享我所面临的困境和问题、我所做的决定以及我认识到的错误。 希望这可以给每一位面临这种情况的同事一个提醒。

项目及团队背景

三个月内总共有四个项目，没有正式的项目经理，只有三个实习项目经理。 三位实习项目经理中，一位领导了一个正在进行的小型项目（前后端共3人）近一年；一位领导了一个小型正在进行的项目（前后端共3人）。 一个人领导了一个小项目（4人）一个月； 主持中小型项目2个（7人）1人。 总共半年时间。

开发同事都比较年轻，最长的工作经验也只有三年。 精力充沛但缺乏经验； 团队一半是老同事和新同事，一半以上的同事加入公司还不到一年。

这四个项目都是基于客户提供的同一个基础版本（或框架）开发的。 客户端使用的基础框架太旧。 前后端框架都是十多年前使用的。 前端技术很偏，学习成本巨大。 框架很乱，有近2000张表。 说是框架，但是里面包含了各种业务代码，必须要用到。

开发调试环境配置困难。 该项目必须在Linux上运行，并且只能远程调试。 由于项目太大，启动速度慢，编译一次需要10多分钟。 我们的团队对这个模型并不熟悉，花了一段时间才弄清楚。

客户公司规模较大，研发部门较多。 部门协调占开发过程的一半以上，需要与各种设备的接口，都是由其他部门开发的。 各部门互相配合，很难找到人来提供帮助。

错误一：高估团队水平

我自认为我很了解我的同事，但其实我的理解太片面了。 近一年来，因为我接手的项目比较稳定。 连续产量在可控范围内，客户也认同。 这让我产生了一种错觉，我们的团队还不错。

整个团队面对新环境的适应能力较弱。 很难产生快速稳定的输出。 项目启动两周后，基本熟悉了环境和项目，也没有什么有效的产出。 导致时间被浪费。

例如，A刚入职三个月多。 在其他项目中，项目负责人给予了很好的评价，这使得我把他放在了重要的开发位置上。 但项目刚开始的时候，我发现A的技术水平有点差，不会写多表联合查询的SQL。 这时候没人能代替他，我只好上去扶他。

比如，一年多来，某B主导的项目一直稳定，没有出现大问题。 但到了新项目时，理解能力较弱，无法快速完全理解需求。 同时，也暴露了某B没有风险意识、无法识别风险、识别风险后没有应对或采取任何行动的致命缺陷，导致项目多次延误。

反思：评估很重要，全面的评估反馈更重要。

在人员和团队方面，我认为最关键的问题是考核机制。 由于种种原因，同事们的认识过于片面。 在就业方面，人们被放置在错误的位置上。 狙击手被安排在主攻位置，主攻被安排在指挥官位置。 这一战不失败才怪！

站在较高的位置，很容易误判下面同事的能力。 在我看来，人不多的时候，认识大家最好的办法就是一起战斗。 在一场战斗中，观察每个人日常的态度表现、效率输出、代码质量、协调能力、对外沟通能力等。完成一个项目后，可以对项目组的成员有更全面的了解。 但这种方法不能只是站在项目之外看待它，而是要与同一个项目的每个人一起工作。

要从多方面了解一个人，不要只听一个人说的话。 对于上面提到的A来说，因为只听了一个人的话，所以发生了重大误判（A在另一个项目中只做了导出功能，没有接触数据库）。

不要用静止的眼光看人，人是在不断变化的

人总是在变化的，我用过去的经验来评判每个人。 有的被高估，有的被低估。 如果没有将最合适的人分配到最合适的项目，过去的错误或职能就不应该记录在今天的账目中。 我们要持续跟进大家的变化，持续保持对大家新的认识。 不要以特定的方式看待人。

我们还应该通过积极引导帮助同事改正缺点。 而不是放手让它自生自灭。 只有这样，团队才能进步。 这也是一个领导者最应该做的事情。 我在这方面还远远落后。

不宜根据情况来判断人

由于进行了一定的技术预研工作，我认为D是一般。 但在这个项目中，他成为了最稳定的输出环节。 由此可见，我们不能仅仅因为某人当下表现得好或差而对他做出刻板印象或先入为主的结论。 要客观地评价一个人，你需要了解他的整个历史和整个工作。 也就是说，第一点说要有一个完善的评估和反馈机制。

错误二：低估项目难度

总共有4个项目，每个项目（仅支持IE）都需要连接额外的客户开发的中间件、插件（ActiveX）以及各种硬件设备。 我以前从未将设备连接到硬件，所以我低估了对接的难度。

我没想到中间件、插件和硬件设备之间会有联系。 没有任何文档。 只能搜索历史代码进行学习和测试，或者去相关部门询问。 在之前的沟通过程中，我以为对接会提供文档或者专业指导，并没有问清楚。

前端使用框架（2006年的框架及版本）太老了。 由于对前端的了解不够，以及对学习曲线的错误估计，导致团队的前端同事在开发初期过得很艰难，进度被拖延了很长时间。

跨部门沟通远比我想象的困难。 在之前的沟通过程中，明确会有一个专人负责跨部门的沟通，但在实际工作中，却变成了我们自己的责任。 各个部门互相搞球，花了三个小时跑了五层楼才得到相机是什么型号的问题的答案（测试需要特定型号的相机，联系人也不知道）借用了什么型号）。 更不用说代码级指导了。

不知道客户端框架的实际情况，以为是spring封装的脚手架。 出乎意料的是，该框架包含近2000张表和数百万条历史代码。 光是用户模块就有三组不同（框架会根据每次定制定期将定制内容集成到主框架中，从而产生各种无用的历史遗留代码）。 搜索您要使用的功能。 难度大大增加。

反思：经验固然重要，但经验也是致命的。

在这次早期的交流中，我认为很多事情都是经验主义造成的。 比如，如果你问更多对接文档的问题，情况可能就大不一样了。

经验也可能成为风险之一，需要警惕。

我试图了解更多信息，但四个项目的联系人并没有掌握全面的信息。 到了我这里，缺失的信息就更多了，我当时就以为这就是全部情况了。 信息的缺乏会让判断失去方向。

从现有的信息中，需要挖掘出更多的问题和信息，并找到联系人进行确认。 信息越多，就越能为判断提供准确的方向。 如果联系人不清楚，就需要推送联系人找到对应的人，以获得相对准确、完整的信息。

锁定项目的核心点和难点。

这些项目中，有的项目一开始就没有抓住项目的核心和难点。 例如，项目A的核心功能是存储，需要使用客户自行开发的存储设备。 这个关键问题在项目前期没有锁定，导致项目后期所有核心功能都需要返工。 一般采用排除法来找出核心点和难点。 列出所有页面上所有可见的功能点和隐藏的功能点，并使用排除的方法排除连接较少的独立模块。 剩下的就是重点难点的核心要素。 理清各个核心要素之间的关系，得到最终的功能关系图（业务架构图）。

错误三：战术错误，同时面对太多项目

回顾过去，在人手不足的情况下承担太多项目是一个错误。 但这确实是一个两难的选择。 不能简单地用对错来概括。 接受或者不接受，这是一个博弈的过程。 综合分析该项目是否确定交给我们，然后分析我们是否有能力完成，经过深思熟虑后做出结论。

反思：项目总会面临资源不足的问题。 永远不要想着项目中有最合适的资源和人员。

毕竟，最合适的人不可能总是在等待你的项目。 领导一个项目就像打牌。 为了完成这个项目，你应该做一手好牌。 战胜坏牌就是你的能力。

误区四：管理并不容易

最后一个错误是，在没有人领导的情况下，我别无选择，只能领导该项目。陷入某个项目的具体细节后，没有一个人来管理和协调所有项目。

管理非常耗费精力，需要专人来处理。 经理的职责之一是沟通和协调，尤其是在像这样需要强有力沟通的项目中。 一旦陷入某个特定项目，就很难有精力去维护其他项目。

授权固然重要，但检查更重要。 交付的工作必须定期检查，确保交付成果完成、完整、不返工。

总结我的经验教训，建立更全面的评估反馈系统对于了解团队至关重要。 不要局限于经验。 沟通胜过一切。 反思每一个战术错误，确保下次精准打击。 让人员专门从事特殊任务和全职管理。 人们，一旦投入了大量的精力进行开发，就不要陷入开发的细节之中。 这将是一个致命的风险。