我是如何失去团队掌控的？(转)

[leegradyllljjjj]

我是一个不合格的技术总监，在过去的快三个月里。我带着从 40 多个人的研发团队（包含需求、开发、测试）里抽调出 20 多个人去为公司开疆拓土。在这快三个月中，我们一起奋战奋斗拼搏。在过程中，我通宵时间超过半个月，干到凌晨 4/5 点的日子数不胜数，干到凌晨 1/2 点日子更是习以为常。整个团队绝大多数人近乎两个月没有周末，辛苦异常，是实实在在的高峰体验。但是三个月后，我带着失败和一身的惨痛教训回到公司。

我在这次的经历中感受到了我是怎么失去团队掌控力的。我所谓的团队掌控，不是说兄弟们不听安排，不按计划行事。而是我对整个开发团队、测试团队、需求团队都有了新的认识，重新认识了团队，重新认识了这二十多个人。因为对个人和团队的能力判断误差和对项目难度的判断失误，导致了这次惨痛的教训。

我把我所面临的的困境和遇到的问题分享给大家，也将把我所做的决策分享给大家，并把我所意识到的错误分享给大家。希望能给每个面临此种局面的同行进行提醒。

---

项目和团队背景

1. 共计三个月内有四个项目，没有正式的项目经理，只有三个实习项目经理
2. 三个实习项目经理中，一个带过一个小型持续性项目（前后端共 3 人）接近一年；一个带过小项目（ 4 人）一个月；一个带过两个中小项目（ 7 人），共计半年时间
3. 开发同事都相对年轻，工作年限最长的也就三年。朝气蓬勃但的确经验不足
4. 团队中老同事新同事各占一半吧，超过半数的同事来公司不到一年
5. 四个项目都基于同一个客户提供基础版本（或者说框架）进行开发
6. 客户方使用的基础框架过于老旧，十多年前的前后端框架，前端使用技术特别偏门，学习成本巨大
7. 框架混乱不堪，表就有快 2000 张，说是框架但杂含着各种各样的业务代码，且又必须使用
8. 开发调试的环境配置困难，项目必须跑在 linux 上，只能远程调试。项目由于过大，启动缓慢，编译一次大概 10 多分钟。我们团队不熟悉此种模式，摸索浪费了一段时间
9. 客户公司较大，研发部门较多。开发过程中部门协调工作占比超过一半，需要和各种各样的设备做对接，都是别的部门开发的。部门之间互相踢皮球，找人协助困难

错误一：高估团队水平

1. 自以为很了解同事，其实了解的太片面。在过去一年中，由于做的项目比较稳定。持续产出在可控范围内，客户也比较认可。导致我产生了觉得我们团队还不错的错觉
2. 整个团队在面对全新环境的情况下，适应能力偏弱。难以快速稳定的产出，项目开始了两个星期，基本都处于熟悉环境、熟悉项目的状态，一直没有有效产出。导致时间被浪费
3. 比如某 A 刚入职 3 个多月，在其他项目中，项目负责人给出的评价还不错，导致我把他放在了重要的开发位置上。但项目一开始，我就发现某 A 技术水平差的有点厉害，多表联查的 sql 都写不溜。此时已无人可替他，只能我上去协助他 比如某 B 一年多来，带的项目一直稳定未出大问题。但到了新项目中，理解能力较弱无法快速全面理解需求。同时也暴露出了某 B 没有风险意识的致命缺陷，不能识别风险，识别出了风险也不反馈不作为，导致项目多次跳票

反思：

1. 考核很重要，全面的考核反馈更重要
   • 在人员和团队方面，产生最要命的问题，我想就是考核机制的问题了。由于种种原因，对同事的了解都太片面。在用人方面把人放错了位置。狙击手放到了主攻手的位置上，主攻手放到了指挥员的位置上。这样战斗不失败才怪呢
   • 站在一个较高的位置，很容易对下面同事的能力判断失误。就我认为，在人数不多的情况下，最好的了解大家的方式，是一起战斗。在一场战斗里，观察每个人每天的态度表现、效率产出、代码质量、协调能力、对外沟通能力等。经过一个项目下来，就能对这个项目组中的成员有个较全面的了解。但这种方式不能只是站在项目外看，而要和大家一起就同一个项目开展工作
   • 从多方去了解一个人，不只听某一人之言。对如上的某 A 来说，就是因为只听了一人之言产生了较大的误判（某 A 在另一个项目中，只做了导出功能，未接触数据库）
2. 不用静止的眼光看人，人都是在不断变化的
   • 人都是在不断变化的，而我用了以往的经验去评判大家。有的高估了，有的低估了。没有把最合适的人安排给最合适的项目
   • 不应把过去的错误或者功能记在今天的账上，要持续的跟进大家的变化，持续的保持对大家的新认识。不以固有的眼光看人
   • 也应通过积极的引导，帮助同事改掉自己的不足。而不是听之任之，由其自生自灭。只有这样，团队才能进步，这也是一个 leader 最应该做好的事情，我在这方面差的还太远
3. 因事定人不可取
   • 某 D 之前由于某次技术预研的工作，让我认定他一般。但在这次的项目中，他却成了最稳定输出的一环
   • 由此可见，不能因为某人一时做的好或者不好，就给这个人定了型，先入为主的下定论。要客观的评价一下个人，需要了解他的全部历史和全部工作。也就是第一条说的，要有全面的考核反馈机制

错误二：低估项目难度

1. 项目共计 4 个，每个项目（只支持 IE ）都需要和额外的客户自研中间件、插件（ ActiveX ）、多种硬件设备对接。此前未做过和硬件对接的设备，低估了对接的难度
2. 中间件、插件、硬件设备的对接我万万没想到，什么文档都没有。只能去搜历史代码学习测试，或者到相关部门去问问。而此前沟通过程中，我心中默认对接是有文档或专人指导的，没有问清楚
3. 前端使用框架（ 2006 年的框架和版本）过于老旧，由于对前端了解不足，错误的估计了学习曲线，团队前端同事开发前期非常吃力，进度在这块也拖延了一大段
4. 跨部门沟通的难度远超我的想象，此前沟通过程中，明确好跨部门沟通有专人负责，但到了实际工作中，都变成了我们自己去对接。各个部门互相踢皮球，一个摄像头到底是什么型号的问题（测试需要特定型号的摄像头，对接人不清楚借来的是什么型号），我能花 3 个小时跑遍五层楼才得到答案。更不用说代码层面的指导了
5. 没有了解到客户方框架的真实情况，心中以为是在 spring 上封装的脚手架。没想到框架中包含了快 2000 张表，数百万的历史代码。光用户模块就有不同的三套（该框架会在各个定制的基础上，定期的把定制内容合到框架主干上，导致了各种没有用的历史遗留代码），找想要使用的功能搜索难度大增

反思：

1. 经验很重要，但经验也很致命
   • 在此次前期沟通中，很多我以为，我认为都是经验主义所害。比如对接文档的问题，多问一句，可能情况就很不一样
   • 经验也可能成为风险之一，需要警惕
2. 想法设法获取更多信息
   • 四个项目的对接人了解的信息都不全面，到我这的信息就缺失更多，而我当时以为这就是全部的情况。信息的缺失是会让判断失去方向
   • 在现有信息中，要去挖掘出更多的问题和信息，并找对接人确认。越多的信息越能为判断提供更准确的方向
   • 对接人也不清晰的情况，需要推动对接人去找相应人员获取，得到相对准确和完善的信息
3. 锁定项目核心重难点
   • 在这几个项目中，有的项目没有在一开始就抓住项目核心重难点。比如甲项目中核心功能是存储，且需要使用客户自研存储设备，项目初期未锁定该重点问题，导致后期项目核心功能全部返工
   • 一般采取排除法来锁定核心重难点。把所有的页面可见功能点和隐含功能点列上，以排除法排除独立的关联少的模块。留下的就是重难点的核心要素
   • 针对每个核心要素搞清楚联系关系，得到最终的功能关系图（业务架构图）

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

1. 回过头来看，人手不足的情况同时接了过多的项目是错误的。但这的确是一个两难的问题，不能简单的用错或者对来概述
2. 接或者不接，这本就是一个博弈的过程。综合分析项目是否确定会交由我们来做，再分析是否有能力完成，考虑清楚后再下结论

反思：

1. 项目中总是会面临资源不足的情况，永远不要想着项目中拥有最适合的资源、人员。毕竟最适合的人员不可能一直等着你的项目
2. 带项目就像打牌，一手好牌做好了项目是应该。而一手烂牌打赢了才是你的能力

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

1. 最后一个错误，是在项目无人可带的时候，迫不得已我去带了项目。陷入了某个项目的具体细节后，没有了统一对所有项目进行管理协调的人
2. 管理是很耗费精力的，需要专人专职的去处理。管理者一大职责就是沟通协调，尤其在这种需要强沟通的项目中
3. 一旦陷入了具体的某个项目中，就很难有精力去维持其他项目了
4. 授权很重要，但检查更重要。交付出去的工作，要定期检查，保证交付物是完成的、完整的、不返工的

我所吸取的教训总结

1. 建立更全面的考核反馈体系对认识团队至关重要
2. 不要局限于经验，沟通胜于一切
3. 反思每一次战术失误，保证下一次的精确打击
4. 专人专事，专职管理的人，就不要陷入开发细节中，一旦大量精力投入了开发。这将是致命的风险

[tkHello]

我就是其中某个手下，你就是个 xx ，加班费给到我了吗！反思你 xxx!

[zhoufenfens]

@microxiaoxiao 这个文章是作者转载的.

[beijinglowb]

我觉得您还是别反思了。。。。。

[beijinglowb]

没看清，原来是转载。。。。
很容易误伤友军，建议下次顶部加粗写清。。

[microxiaoxiao]

@zhoufenfens 额，没看括号，直接看内容了。

[James369]

我发现干 IT 的，都喜欢折磨人，不是折磨自己，就是折磨别人。其实我觉得把这本事放在马云这种类型身上，一定会成为第二个马云。

[danhahaha]

总结：技术总监自以为是用 D 级水平团队接了 A 级水平难度的项目。

通篇都没有任何意义的结论，文中各种角度提到，之前各个同事队友配合都不错，都很满意，进度都在掌握中，说明之前项目都在水平之内。这次玩砸完全就是因为没有金刚转，拦了瓷器活。

[yuanshrn]

非常中肯

[ericgui]

天天加班，你自己不累吗

[fakeshadow]

做事之前先做人。你拿别人当人，别人才拿你当人。

[shanyuhai123]

只能说运气不错，正常情况搞一个月内人都跑光了，干翻公司的概率更大。

[iloveios]

两个月都没有周末还继续跟你干的。都是…
我就不明白干到大半夜这种事情不久已经能说明很蠢了吗

[MengiNo]

绝大多数项目从立项到那一刻就注定是没有好结果的，企图用技术和人力把瓜扭甜是很幼稚的，但不做的话能怎么办呢，全部去送外卖么。

[ws52001]

@duxiansen 在关键项目前，怎么可能没有攻坚的觉悟和勇气？站着说话不腰疼的。

[clifftts]

换个总监可能就没有这个问题了

[turi]

要是我，tmd 肯定摸鱼，写 bug 了。
连续几个月不休息，这是人干的事情？

[nVic]

尊重，祝福。

[icetea12138]

没 tm 抽你就不错了

[abc0123xyz]

我只能：呵呵

[hanbing135]

最大感受就是这个作者也就是团队的管理者自己水平不行能力不行还过度自信 导致把项目搞砸了 居然推到下面人身上 这就是个垃圾啊

[MEIerer]

能力不足呗，管理不是随便当的，架构也是

[kenvix]

你活该

[ericguo]

> 每个项目（只支持 IE ）都需要和额外的客户自研中间件、插件（ ActiveX ）、多种硬件设备对接。

这项目应该马上死掉，换我我压根不会接这任务。

[ma836323493]

把我当驴使，代码给你写成屎

[chenPiMeiHaoChi]

经典二鬼子比鬼子还狠，哈哈。
你手下工资多少啊？要是万把块那我的评价是纯纯牛马。

[zooeymango]

不是很理解这种项目为什么不在立项的时候就 kill 掉，我们接手了一个 10 年的项目一个月就决定重写，投入这种无底洞项目根本是浪费生命

[roundgis]

這是被人坑了吧 連 pm 都是見習的

[lasuar]

[原文——2019]( https://www.cnblogs.com/zer0Black/p/11819696.html)

[SmiteChow]

看到大家都在骂我就放心了：）

[deetz]

你加班成这样，还有脑子想管理？ 996 促成 tunnel view ，带来低质量的思考。

[lavenderkissyou]

我说难听一点

“将帅无能 ，累死三军”

[XiaoBaiYa]

这个作者以为自己写的很好，实则就是个大傻叉

[Dogtler]

@leegradyllljjjj 楼主洋洋洒洒正文一大列不是把自己的缺点罗列晒出来，这样子的批评就蚌埠住了啊？这人得多虚伪，还反讽别人厚黑。

听不到自己想听的话就很失望对吧，没有那么大的勇气和心胸逞什么呀

[Mark24]

“近乎两个月没有周末”

所以总结完了会引咎辞职么？

[rangoBen]

内部文章吗？不是的话原文链接提一下呗

[wangtian2020]

ctrl + F 打开浏览器搜索框，输入“傻逼”
找到结果，满意离开

[liangxiaowen]

错误四：管理不是轻松的事 应该排在第一个说明。
项目管理肯定是会遇到很多困难，如果都给你最强的人，做最简单的事情，就不叫项目管理了，那叫过家家。
项目管理就是要给公司产生最多价值的，项目败了，责任人就要负责，小兵往往是没有太大的责任的。
二十多个人，一个人直接管确实太难了，应该分成三个左右小团队，而你的工作重点应该是辅导小团队的负责人快速成长，协调各个小团队之间的工作；一个数据库的问题，搞不定就要你来协助..那你每天还得盯着人写代码啊。
错误三：战术错误，同时面对过多的项目
这个肯定就是你的问题了，底下兄弟只会说你：扛不住上面的压力，啥项目都接，接了又搞不定，恶性循环。
错误一、二 应该是所有项目都会有的问题，并非重点