我是怎么失去团队掌控力的？

在过去的三个月里，我是一名不合格的技术总监。我从一个由40多人组成的研发团队(包括需求、开发和测试)中挑选了20多人来拓展公司的领域。在过去的三个月里，我们并肩作战。在这个过程中，我熬了半个多月的通宵，工作到凌晨4点半是数不胜数的，工作到凌晨1点半甚至更常见。整个团队的绝大多数人已经将近两个月没有周末了。他们的辛勤工作非同寻常，是一次真正的巅峰体验。但是三个月后，我带着失败和全身的痛苦回到了公司。

在这次经历中，我感觉到自己是如何失去了对团队的控制。我说团队控制，并不是说兄弟们不听安排，不按计划行事。但是我对整个开发团队、测试团队和需求团队有了新的理解，对团队有了新的理解，对20多人也有了新的理解。这个痛苦的教训是由判断个人和团队能力的错误以及项目的难度造成的。

我会和你分享我所面临的困难和问题，我所做的决定，以及我意识到的错误。我希望我能提醒每个面临这种情况的人。

项目和团队背景

1)三个月内有四个项目，没有正式的项目经理，只有三个实习项目经理。

2)三个实习项目经理中的一个已经接受了一个小规模的连续项目(前后三个人)将近一年。一人参加了为期一个月的小型活动(4人)；其中一个项目历时六个月，涉及两个中小型项目(7人)。

3)开发同事相对年轻，最长工作年限为三年。精力充沛但缺乏经验。

4)团队中的老同事和新同事各占一半。一半以上的同事在公司工作不到一年。

5)所有四个项目都是基于同一客户提供的基本版本(或框架)开发的。

6)客户端使用的基本框架太旧。十多年前的前端和后端框架，前端采用特殊技术，有巨大的学习成本。

7)框架是混乱的。几乎有2000张桌子。据说它们是框架，但它们包含各种业务代码，必须使用。

8)开发和调试环境难以配置。该项目必须在linux上运行，并且只能远程调试。因为这个项目太大，所以启动很慢，大约需要10分钟来编译。我们的团队不熟悉这种模式，已经浪费了一些时间摸索。

9)更大的客户公司和更多的R&D部门。在发展过程中，各部门的协调工作占总工作的一半以上。它需要与其他部门开发的各种设备连接。各部门互相帮助。

错误一：高估团队水平

认为他非常了解他的同事，但事实上他知道的太少了。在过去的一年里，这个项目一直相对稳定。连续输出在可控范围内，客户也相对认可。这让我产生了一种错觉，以为我们队还不错。

整个团队在新环境下的适应性很弱。很难产生快速稳定的产出。这个项目已经熟悉环境和项目两个星期了。没有有效的产出。导致时间被浪费。

例如，甲刚开始工作3个多月。在其他项目中，项目经理给予了很好的评价，这使我把他放在了一个重要的发展位置上。然而，从项目一开始，我就发现某个特定的a在技术水平上稍差一点，并且不能编写多个表链接在一起的sql。这时没有人代替他，只有我上去帮助他。

例如，一年多来，与乙的项目一直稳定，没有重大问题。然而，在新项目中，理解能力较弱，需求不能很快得到充分理解。同时，它也暴露了一个致命的缺陷，即甲乙双方没有风险意识，不能识别风险，识别风险后没有给出反馈和不作为，导致多次跳票。

反思

1)评估非常重要，全面的评估反馈更为重要

站在更高的位置上，很容易误判以下同事的能力。就我而言，了解每个人的最好方法是在人数不多的时候一起战斗。在战斗中，观察每个人的日常态度表现、效率输出、代码质量、协调能力、外部沟通能力等。项目结束后，您可以对项目团队成员有更全面的了解。然而，这种方法不能只是站在项目之外，与同一项目中的每个人一起工作。要从多方面理解一个人，一个人不应该只听他说什么。对于上面的，这是因为只听一个人的话会造成很大的误判(另一个项目中的只执行导出功能，而不联系数据库)。

2)不要用静止的眼睛看着人，人总是在变化

人们在不断变化，我用过去的经验来评判每个人。有些高估了，有些低估了。最合适的人没有被分配到最合适的项目。我们不应该把过去的错误或职能归咎于今天。我们应该继续关注每个人的变化，保持对每个人的新理解。不要根据人与生俱来的眼睛来判断人。我们还应该通过积极的指导帮助同事们克服缺点。而不是放手让它死去。只有这样，团队才能取得进步，这也是领导者应该做好的最重要的事情。在这方面我仍然远远落后。

3)不明智的判断是因为错误二：低估项目难度

公元前，由于一项技术前期研究工作，我认定他是普通人。然而，在这个项目中，他已经成为最稳定的出口环节。由此，我们可以看到，仅仅因为某人此刻做得好或不好，我们不能给这个人一个明确的形状，并做出一个先入为主的结论。为了客观地评价一个人，一个人需要知道他所有的历史和工作。换句话说，第一个说应该有一个全面的评估和反馈机制。总共有4个

反思

项目，每个项目(仅工业工程)需要与额外的客户自行开发的中间件、插件(ActiveX)和各种硬件设备接口。以前没有与硬件对接的设备低估了对接的难度。中间件、插件和硬件设备的对接从未让我想到没有文档。只能搜索历史代码学习测试，或者向相关部门询问。然而，在之前的沟通过程中，我的心默许有文件或特殊人员来指导对接，我没有问清楚。前端使用框架(2006框架和版本)太旧了。由于对前端的理解不足和对学习曲线的不正确估计，团队的前端同事在开发的早期阶段经历了一段困难时期，进度被延迟了很长时间。跨部门沟通比我想象的要困难得多。在之前的沟通过程中，很明显有一个特别的人负责良好的跨部门沟通，但在实际工作中，这一切都变成了我们自己的对接。每个部门互相踢对方的球，我可以花3个小时在五层楼找到它是什么类型相机的问题的答案(测试需要特定类型的相机，对接人员不知道借用的是什么类型的相机)。更不用说代码级指南了。我不知道客户框架的真实情况，但我认为它是封装在春天的脚手架。出乎意料的是，该框架包含近2000个表和数百万个历史代码。单独有三组不同的用户模块(框架会在每次定制的基础上将定制的内容定期集成到框架的主干中，导致各种无用的历史遗留代码)，这大大增加了搜索所需功能的难度。在早期的交流中，我认为他们中的许多人都是经验主义的受害者。例如，如果你问更多关于文档的问题，情况可能会大不相同。

1)经验很重要，但经验也很致命

2)想法设法获取更多信息

在这些项目中，有些没有抓住关键

3)锁定项目核心重难点

错误三：同时面对过多项目

一般采用排除法锁定核心难点。列出页面上所有可见的功能点和隐藏的功能点，以排除连接较少的独立模块。剩下的是困难的核心因素。明确每个核心元素的关系，并得到最终的功能关系图(业务架构图)。

错误四：管理不是轻松的事

回顾过去，在人力不足的情况下，同时承担太多的项目是错误的。然而，这确实是一个难题，不能简单地用错误或正确来概括。要么接受要么放弃，这是一个游戏过程。综合分析项目是否一定会交给我们，我们是否有能力完成它，我们可以在考虑清楚后得出结论。

反思

项目将永远面临资源短缺。永远不要考虑在项目中拥有最合适的资源和人员。毕竟，最合适的人员不可能一直在等你的项目。参加一个项目就像打牌。一手好牌是一个好项目。赢得一手好牌是你的能力。

我所吸取的教训总结

最后一个错误是，当没有人接手这个项目时，我不得不接手。陷入一个项目的具体细节之后，没有人能够以统一的方式管理和协调所有的项目。管理非常耗费精力，需要专门的人员来处理。管理者的主要职责之一是沟通和协调，尤其是在需要强有力沟通的项目中。一旦参与了一个特定的项目，就很难有精力去维护其他项目。授权很重要，但检查更重要。应定期检查交付的工程，以确保交付的工程完整、完整且未返工。

建立更全面的评估反馈系统对理解团队至关重要；不要把自己局限于经验，沟通比一切都好。思考每一个战术错误，以确保下一次精确打击；被特别指派和管理的人不应该被发展的细节所困扰。一旦大量能源投入开发，这将是一个致命的风险。