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

[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. 专人专事，专职管理的人，就不要陷入开发细节中，一旦大量精力投入了开发。这将是致命的风险

[duxiansen]

“整个团队绝大多数人近乎两个月没有周末，辛苦异常，是实实在在的高峰体验。”
这方面没有反思吗？

[leegradyllljjjj]

最近看到的一篇写得很好的文章，一般大家都写自己怎么怎么牛，做了哪些，很少对自己失败进行剖析清楚

[leegradyllljjjj]

不知道大家对项目管理有什么看法

[dangyuluo]

把团队成员当驴使，不失败才怪了

[eric614802]

技术团队管理与技术领导力公开课： http://hdxu.cn/gS6C6 ，明天的直播，供参考～

[nothingistrue]

@leegradyllljjjj #2 说句实话，这个开篇就写工作时间多长的，还不如那些写自己很牛的。排除吹牛的，剩下那些只跨自己牛的，还有补足其他地方然后成功的机会。而这种以吃苦为基地的，基本表明了除了会吃苦就啥也不会了，铁定了最好的结果也就是“没有功劳只有苦劳”。

[bk201]

项目管理的书籍好像都包括了上面吸取教训的部分，如果要避免这些教训，建议多看看书。
然后呢，我觉得一般工程都不是造火箭，能力不行的情况其实都是可以用正规的流程规避的，如果出现问题，那一定是流程里有不合理或者疏忽的地方。

[bk201]

我带着从 40 多个人的研发团队（包含需求、开发、测试）里抽调出 20 多个人去为公司开疆拓土。在这快三个月中，我们一起奋战奋斗拼搏。在过程中，我通宵时间超过半个月，干到凌晨 4/5 点的日子数不胜数，干到凌晨 1/2 点日子更是习以为常。整个团队绝大多数人近乎两个月没有周末，辛苦异常，是实实在在的高峰体验。
====
从这里就可以看出这个人管理能力，把控能力是非常非常弱的，下面人如果跟着上面一直吃苦，那肯定是士气低下，毫无战斗力

[cp19890714]

一个技术总监确实不应该犯这么多错误。
很明显，作者的能力还不足以承担这个岗位。

[hangbale]

好家伙，看完开头，去掉奋斗拼搏之类的字眼，妥妥的血汗工厂，比工地还惨

[theoda]

文中提到的很多客观问题的确是难以逃避的困难，但似乎看起来当事人容错率很低，把事情安排得满满当当，发生了种种「万万没想到」的问题只能靠加班加点亡羊补牢，称之为「奋战奋斗拼搏」，这不仅仅是高估、低估的问题

[MarkP]

"整个团队绝大多数人近乎两个月没有周末，辛苦异常，是实实在在的高峰体验。但是三个月后，我带着失败和一身的惨痛教训回到公司。"

领导反思：建立更全面的考核反馈体系对认识团队至关重要
下面小兵：一个月才几百块玩什么命啊 （ from 《给爸爸的一封信》台词）

[laolaowang]

作为一个切兔崽，看到支持 IE ，就知道这攻坚战不好打！

[hxndg]

知乎的帖子： https://zhuanlan.zhihu.com/p/364764659
基本上提到的问题都有评论了

[kkkiio]

@duxiansen 越是加班就越没精力思考，把未知的工作当体力活来做真的搞笑

[leegradyllljjjj]

楼主遇到过一个项目，项目需求没有扯明白，硬着头皮上了，最后项目上线客户各种不满意，当然也有客户提出的无理要求，最后公司领导妥协了，但是倒霉的就是我们这些开发兄弟了，被两头架在火上烤

[frankies]

我 27 岁那年反思自己认识到个词叫一般锚定：即自己只有一般水平的智商、技术、行动力、领导力。
自己就是个普普通通平平庸庸的叫灵长类的生物，在灵长类生态内也就只能做成一般的事罢了，成亦欣然，败亦可喜，尝试和自己和解。

[alsas]

好家伙 妥妥的把人当牛马使

[HQKM]

整个团队绝大多数人近乎两个月没有周末，辛苦异常 不是人啊
看了下评论确实是-我是如何在三个月毁掉团队和项目的
确实不合格 项目结束后还可能导致研发团队人员流失
说不定下次就是我是如何在半年内毁掉公司的

[www5070504]

这项目情况这么复杂 "项目开始了两个星期，基本都处于熟悉环境、熟悉项目的状态，一直没有有效产出" 应该不算浪费时间吧

另外 A 在重要位置 是不是也应该再有一个人当备份 或者互为备份会好一点

[h1104350235]

这种领导不跟也罢，自己对项目没有把控能力，连带底下的兄弟们加班加点。

[wbrobot]

1,需求不明
2,沟通不畅(外部和内部)
3,厚重的技术债
4,多项目,多任务,紧工期
5,年轻的生瓜蛋子,菜鸡的领导,再加上陌生的地理环境,陌生的开发环境,紧急的工期,无人分解任务, 杂乱无章, 导致的底层员工士气低落

带兵打仗所有的忌讳全犯了,这能打胜仗?

但凡, 有明确的需求, 或者细致分解的任务, 或者力挽狂澜的技术 leader, 任何一项, 这项目不至于失败
一场战争,一般不是兵的问题,大部分是战术和战略的问题.

[joApioVVx4M4X6Rf]

我曾经就在这种团队待过，领导无能，加班加得差点把我命丢了

[kop1989smurf]

通读了，给了我三点感受：

1 、把自身的错误转嫁给别人。
2 、试图靠别人的发挥来成就项目，而不是自己。
3 、狗眼看人低。

通篇总结，这个作者就是个官儿迷。
嘴上全是自己的错误，但字里行间全是别人太烂。看别人全都是自上而下的眼光，动不动就对谁高估了对谁低估了，动不动就是需要考核监督，把别人当牲口用鞭子抽。

全文没有一点是对项目本身，以及对他自身行为的总结。

[oatw]

没有恶意，直观感受是像拽了一票人在一座屎山的基础上继续堆……

感觉问题不在够不够努力，是一开始的选择就不太正确，既然是屎山，那就忽悠客户推倒重来啊～忽悠好了还能多挣钱，老板一看，哎！这 CTO 靠谱啊，又能带人干活又能忽悠客户，是个人才！

[lusi1990]

如果 20 个程序员都有 10 年的工作经验,我感觉还能拯救下

[mrzx]

@oatw 接着在拉一堆屎山，等着下面一批人帮你们收拾？

最关键是客户那边领导收不收回扣？收的话，当然好忽悠重构，就当新项目做吗，领导有回扣吃干嘛不做？

[mrzx]

@kop1989smurf 说的太好了。我真怀疑，技术和总监，他哪一样都不配。

[GeorgeGalway]

“一个摄像头到底是什么型号的问题（测试需要特定型号的摄像头，对接人不清楚借来的是什么型号），我能花 3 个小时跑遍五层楼才得到答案”
- - - - - - - - - - - - - - -
霍，这技术总监是从健身教练晋升的吧？都这么下沉吗？

[urnoob]

开发同事都相对年轻，工作年限最长的也就三年-->客户方使用的基础框架过于老旧，十多年前的前后端框架
光这条就已经注定失败。也许外卖员可能比这些开发更适合做这个项目。
文中提到的“前后端框架”，数百万代码，2000 张表。必然是经过了 2 ，3 年的开发，得可用版。之后慢慢积累，打磨而来。三年经验的开发想使用，怎么都要近一个月。
这种项目，带队的总监要有深厚的行业经验，项目经理，核心开发都要有行业经验。否则必然失败。
这样总监要靠挖。其他人要去楼下外卖队伍找。

[corningsun]

@lusi1990 哈哈哈，你想什么呢，全是 10 年的，第一周熬夜就要倒下一半。

[liprais]

傻逼玩意周末不放假还要啥自行车
三个月算非常能坚持了，一个月就应该完蛋了

[BeforeTooLate]

开篇加班真的把我看吐了，先好好反省下自己作为项目经理时间预估都做不到，加班描述写的好像很自豪的样子真是服了，能不能带头先自我批评一下？

[wangyzj]

我还以为是招聘广告

[shijingshijing]

开头《项目和团队背景》 1-9 都是在找负面的理由，并非从中立的立场介绍项目和团队背景，为后面归因找理由。

[lusi1990]

@urnoob 外卖团队, 哈哈 这个帖子承包了一天的笑点

[zhzy0077]

一个项目排期出来要三个月不休息每天加班的时候 你就该把需求砍掉一半了
按照不休息排期 能按时做出来才是奇迹

[la2la]

我想知道给加班费了没有，给调休了没有。还有请别说兄弟，听着恶心。还失去掌控了，要是我直接就离职了，惹不起还躲不起么？

[zilongzixue]

我看完了，就觉得你在甩锅，你自己都评估这个项目不能做，就带员工去硬啃，出了事怪队友？

[momowei]

我觉得对应这个项目背景，极其老旧的技术，2000 个表，多个对接，大部分都会失败，跟人无关了。

[creatdate]

看到支持 ie 就血压升高了，还只支持 ie

[zunceng]

现在都这么卷了吗 这种项目都接

[tzigone]

IE, ActiveX, 2000+ Table , 都是深坑 , 别说 20 人，就是 100 人去了也能团灭❄❄

[mikuazusa]

一将无能，累死全军

[morty0]

听起来像个垃圾外包团队

[winnie2012]

听起来像是接国企的烂摊子，做个记号避坑。

[leegradyllljjjj]

@kop1989smurf 属于是深得韩非厚黑哲学之精髓

[touchmii]

带着下面的人吃苦是没有什么效率的，如果结果还不是很满意那更是灾难，面对新项目还是要评估风险。

[yazinnnn]

一篇写得很好的文章

-----
好你妈了个逼

[jjwjiang]

啥几把玩意总监？

没想到框架中包含了快 2000 张表，数百万的历史代码。

这你还能没想到？这不该立项的时候就得整清楚？最核心的要做的地方你都不知道大概怎么做，这项目就能定时间开始？

看完了我可以说项目失败这总监基本全锅

[darkengine]

@leegradyllljjjj #3 关于项目管理，老板认不认可很重要，给老板讲过项目时间质量成本三角形，老板说你要化不可能为可能。

现在是前老板了。

[anzu]

至少考个项目管理的证书。我在备考，所以我知道这种抽调式人员组成的组织结构容易失控，对管理者或协调人的要求很高，就这还要加班……

[pastor]

课代表总结：一将无能累死千军。

[qping]

@corningsun #31 你也太真实了

[seesky]

就是本来不能接的项目硬接了，总结所谓的经验再多也没用。 再接一个也是这结果， 还不如花点时间研究怎么和甲方扯个合理的工期实际点。

[jtwor]

[开发同事都相对年轻，工作年限最长的也就三年]
[多表联查的 sql 都写不溜]
[只做了导出功能，未接触数据库]
如果都是后端，给个公司名避雷把。。doge:)

[SchneeHertz]

“在这快三个月中，我们一起奋战奋斗拼搏。在过程中，我通宵时间超过半个月，干到凌晨 4/5 点的日子数不胜数，干到凌晨 1/2 点日子更是习以为常。整个团队绝大多数人近乎两个月没有周末，辛苦异常，是实实在在的高峰体验。但是三个月后，我带着失败和一身的惨痛教训回到公司。”

写到这里就行了，大家就都知道你无能了

[Flobit]

能左右的项目成功和失败的因素很多，这不是你一个人能控制的。项目经理再牛逼也不是啥都能控制的，大多数情况还是得看老板和客户。毕竟人家才是出钱的，你只是出力的。而且很多时候国内的项目经理就是个救火员。

[Evrins]

全程甩锅

能熬三个月也是了不起，我最多一个星期

失去团队掌控应该是人都跑了吧，跟这么一个玩意儿

[infun]

只能说 这个人活该

[charlie21]

只有拿捏和被拿捏两种选择

“当前大环境里，我好不容易说服公司总部分发了 20 个岗位 HC ，精选了高学历简历好看的兄弟加盟我们。前期大家配合无间，后期却因为大老板的问题，把工期压得太紧了，而我又是一个非常注重工作质量的人，我知道 一旦抱着宁缺毋滥精神，就必然得罪不少人，世间之事莫不如此。

我依然认为一个好团队需要一个好 leader ，而我是第一次做 leader ，还有很大成长空间。于我，只能继续在项目中磨砺了。现在我将我这一段经历发出来，警示后人。

好的，我的罪己诏在此，现在我司正在招人，请有兴趣一起干大事的小伙伴发简历给我，我们可以聊一聊，尤其是对于管理工作颇有心得的大牛们，快到碗里来

｛ 二维码 ｝
｛ 邮箱 ｝

”

如果这样发帖子，lz 可以立刻扭转局面，之前痛骂落水狗一般的网友们就会立刻把简历发给你了。

人们甚至还要找你微信私聊，不但表示同情，而且表达网友们很无礼，自己才是最懂你的人。我真的不是很懂这有什么意义，或许这就是男人之间的惺惺相惜

[tool2d]

这应该属于二次开发，其实 90%的码农，内心是不愿意去维护别人写的老代码。

何况有上百万的代码，俗称屎山，这项目在启动的时候，就存在大概率失败的因素。

如果沿用以前老的开发模式，不挑战高难度，也许结局并不会那么糟糕。

[oatw]

@mrzx 哥呀……你 @我干神马？又不是我拉的屎山……

[ChillRaven]

还好这个项目失败了，要是成功得树立多歪的反例

[ming159]

尽管总结的字数很多,但看起来没有触及到根本问题. 需求调研没有做细致,缺少架构设计能力.任务拆分不合理.

需求调研不细致,才导致各种 "万万没想到"; 才会让你低估项目难度, 进而导致任务分配给了不合适的人身上.

缺少架构设计能力,4 个项目,老框架,中间件,插件,设备,按理说应该先收集评估相关技术,然后设计整合的架构方案.然而并没看到,而是直接分配任务了. 也会导致任务分配给不合适的人.

[daolanfler]

推卸责任倒是很多，自己所谓的反思就是看人不准。辣鸡

[mysalt]

咋立项目的，咋评估开发时间的。把人当牲口用，还高估团队水平，我看是高估自己的能力了。

[h1104350235]

看到大家都在骂都好了

[czfy]

原文是不是这个？底下评论区也可以一看
https://zhuanlan.zhihu.com/p/364764659

[wupher]

笑死了，尤其是看了“我所吸取的经验教训”。


2022 年了 ， “每个项目（只支持 IE ）”， “插件（ ActiveX ）” “2006 年的框架和版本” 人的问题先不说，技术的问题已经很让人疯狂了。

[littiefish]

自己说专人专事，自己还去指导别人。。

我工作最讨厌做一半别人过来指导了，所有流程思路断了

[itskingname]

觉都没睡好，还想把项目做好？

[billzhuang]

1. 人能力不行，包括总监自己
2. 没有人把控风险及时止损

[pkwenda]

和明清战争一样，有的人的能力放现在其实就能当个连长，非带兵 2000 当团长，指挥不过来，没那个能力。
韩信带兵多多益善，但不是谁都有这个能力啊。
这个活儿我看他是脑门一拍，啪叽，工作量就定下了，一将无能，累死三军啊

[pkwenda]

重新认识了团队， [重新认识了这二十多个人] 。因为对个人 [和团队] 的能力判断误差和对项目难度的判断失误，导致了这次惨痛的教训。

---------------

话里话外，团队不行。

[karatsuba]

不到三年经验刚过实习期就去扛把子，疯狂加班两个月，是我早溜了

[theguagua]

整个团队绝大多数人近乎两个月没有周末，辛苦异常，是实实在在的高峰体验。

要我是你的团队成员，不到半个月就走人了，自个当光杆司令去吧，这个故事告诉我们，远离无能的团队和领导，将帅无能，累死三军

[whyrookie]

这么加班不失败才奇怪

[james2013]

确实不合格,这种总监应该被开掉,让一线开发这么加班谁受的了?

[checkzhzzzzz]

穿越了?两年前好像就看过了

[krui]

我现在最多只会让加班 1 天，我曾经自己连续加班 3 周，最后导致项目个人精神状态不好，产出不高，还被投诉。后面分析了原因，没人就是没人，没有必要承担着么多，就应该让 leader 承担项目缺少资源的责任，现在没有资源的项目，我都不往前冲了，让 leader 自己去项目沟通，把缺人的问题解决了，我在安排人干活

[imycc]

反思的问题确实暴露出他的不足之处，这个老哥显然不具备带 20 个人团队的能力。
1. 项目进度把握能力差。开篇拿“加班量”来衡量有多努力就是错的，工作排太满，之后每出现一件“想不到的事”，就会造成工期的整体后延。员工在这种高压下表现失常，也可以理解。
2. 项目调研不充分。用了什么技术框架，项目复杂度多高，开发难度如何，这些应当在早期“熟悉环境”的时候，就尽可能地调研清楚。从他认为前两个星期产出低的这点来看，他并没有很重视早期的准备工作，造成了后期进度的失控。
3. 没有发挥好管理者的职能。A 的工作不达标，抽调谁去顶上都行，但不应该自己下场去协助。项目管理已经一团糟了，管理者的精力不能陷入到某项具体的工作中。
4. 缺乏协调资源的能力。自己做为领导，团队要什么资源，要跟其他团队的领导要，细节再由对接人去对，而不是让下属四处碰壁。

[zjq07]

我靠，我前总监之前也是带着十几个人去开疆拓土。咱也不清楚具体结果怎么样。然后年会的时候被老总来了一句：一将无能，累死三军。后来整个研发部分成了两个，去新的研发部继续当总监了。

[RightHand]

能接受连续两周上班的，技术能力肯定不咋地，就算是大佬也会被拖成又不是不能用

[JamChiu]

这种强度，没人倒下就烧香拜佛吧~

[iloveayu]

不用反思了，没被反杀就偷着乐吧

[lawler]

作者能力不行，或者作者并不适合做管理者，亦或者培训后可以上岗。

他这些问题，在书本中是很常见的判例。

[documentzhangx66]

你们最大的问题是，没有做小规模的可行性分析与测试，就直接团队过去了。风险太高，直接翻车。

可行性分析做完后，该调通的能调通，团队过去只是做规模，自然顺理成章水到渠成，但因为缺失这第一环，导致你们后面一直卡在第一步测试上。

这是你最重要的问题，没看见你分析。

[simonCN]

这种人都能当总监，下面干活的人真是倒了血霉了

[tohuer00]

20 个人的团队工作年限最高三年，估计这个总监也不到十年，一听就是又要多揽活又要省成本的低端外包。结果成本花了活还搞不定，真是个大快人心的故事。

[xmge]

“”“
干到凌晨 4/5 点的日子数不胜数，干到凌晨 1/2 点日子更是习以为常。
“”“

看到经常性地熬夜加班，就感觉这人有问题。

连自己的身体都不当回事的人，会在乎手下的人吗？当然是不会的。

这种人为了人生安全还是要离远点。

[maplelin]

身为一个管理者，居然没有为最坏的情况做预案，而是拿一个比较理想的情况去评估一个甲方的项目，我觉得就这一点这个管理者就不及格，跟下面员工水平没有任何关系。

[nill92234]

我是如何失去团队掌控的？(转)（×）
我是如何暴露自己是个菜鸡（✔）

[microxiaoxiao]

傻逼 OP ，你开发个新项目还要天天搞通宵。通篇看下来，就是老子很厉害，团队里面的都是傻逼，其实很有可能你在团队里面别人看你才是有毛病那位。遇到过类似的，自己整天苦逼哈哈的，觉得委屈，却不知道别人怎么评价自己的。还在这沾沾自喜自己劳苦功高分享经验。

[microxiaoxiao]

看到你这种废材我就烦，非得把自己的锅甩给队友。什么低估，高估，一句你不会当技术总监很难吗。作为一个技术总监，技术难点，团队水平，工作协调，工作量评估、啥都不会？也能叫技术总监？

[levelworm]

每次看到这种文章就庆幸润了，换我现在一个礼拜就进医院了，真的。

[ieiayaobb]

这种项目大概率就是开始前，老板的饼画的太大了（比如项目成功能分多少钱，或者成为合伙人啥的），自以为是的总监吃的饱饱的，然后就不顾不管的上去干

[zgray]

把团队的人当兄弟？还是当同事？还是当驴？
劳逸结合很重要，没有休息再团结的队伍也会分崩离析。

[noparking188]

团队里的工人同志们身体还好吧，有安排做体检吗？

[unregister]

死亡行军。。