精选文章 我是如何失去团队掌控的?一个技术总监的反思

我是如何失去团队掌控的?一个技术总监的反思

作者:Java斗帝之路 时间: 2020-08-05 01:58:00
Java斗帝之路 2020-08-05 01:58:00

我是一个不合格的技术总监,在过去的快三个月里。我带着从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. 专人专事,专职管理的人,就不要陷入开发细节中,一旦大量精力投入了开发。这将是致命的风险
勿删,copyright占位
分享文章到微博
分享文章到朋友圈

上一篇:解决Windows下Redis出现“MISCONF Redis is configured to save RDB snapshots”的错误

下一篇:E:大疆M300二次开发PSDKV2.1.0。无法识别无人机型号。一直出现 aircraft type 0

您可能感兴趣

  • 新职业教育的三节课,凭什么做到今天这样

    历时7天、翻遍15个平台渠道、访谈25位参与课程的从业者、挖掘了136条推文的标题和内容,我们得到了12500字的拆解。可以点击右上角☝:收藏、分享、在看,不用担心看一半,找不到文章。 本文信息公开来源:三节课官方公众号、虎嗅网、36氪、深网、东方财富网、新榜、知乎、简书、增长黑盒、短书··· 我们认为,这可能比任何官方复盘更能诠释:「三节课」是如何在3年内,做到互联网职业教育(Almost...

  • 《重新定义公司》读书笔记

    激励偏向的是事成之后的利益分享,而赋能强调的,是激起创意人的兴趣与动力,给予挑战。唯有发自内心的志趣,才能激发持续的创造,命令则不适用于他们。因此,组织的职能不再是分派任务和监工,而更多的是让员工的专长、兴趣和客户的问题有更好的匹配,这往往要求更多的员工自主性、更高的流动性和更灵活的组织。我们甚至可以说,是员工使用了组织的公共服务,而不是公司雇用了员工。两者的根本关系发生了颠倒。 年少时,第...

  • 目前UI就业前景好不好 企业招聘有哪些面试题

      目前UI就业前景好不好?企业招聘有哪些面试题?对于想要加入互联网行业却又不愿意敲代码的人来说,UI设计是一个非常不错的选择。随着用户体验度即审美要求的提升,UI设计师地位进一步提升,很多企业都乐意给出高薪招聘专业的设计人才。下面就给大家详细介绍一下。   UI就业前景好不好?   从市场需求来看,目前UI设计热度呈现持续上升的趋势,国内外很多从事软件、网站、增值服务、手机等企业和公司都设...

  • 为什么苏联打下了如此强的数学基础,俄罗斯却至今无法成为AI强国?

    作者:俄罗斯小笨笨 链接:https://www.zhihu.com/question/395842406/answer/1243718056 来源:知乎 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 数学实力有多强我不清楚,我也对数学的了解也不专业。但是让俄罗斯无法成为AI强国的最大问题之一,肯定包含了人才外流这一原因。 或者往大了说,是俄罗斯各个行业一直面临的一个...

  • 关于前端学习路线的一些建议

    前言 对于刚开始学习前端的伙伴俩说,问得最多的问题就是 ——前端技术现在如此繁杂,我到底应该如何学习。这个话题太大了,几句话回答不好;也由于这个问题确实困扰了很多前端开发人员,所以我也就着手系统的输出这篇文章。 虽然这篇文章花了很长时间,肯定也有其局限性;希望各位不吝指出。 入题 我们俨然能感受到前端岗位现在已经发展成了最重要的研发岗位之一,所以对我们提出的要求也就越来越高。所以我们需要学的...

  • 选型必看:RabbitMQ 七战 Kafka,差异立现

    点击上方“肉眼品世界”,选择“设为星标” 深度价值体系传递 作为一个有丰富经验的微服务系统架构师,经常有人问我,“应该选择RabbitMQ还是Kafka?”。基于某些原因, 许多开发者会把这两种技术当做等价的来看待。的确,在一些案例场景下选择RabbitMQ还是Kafka没什么差别,但是这两种技术在底层实现方面是有许多差异的。 不同的场景需要不同的解决方案,选错一个方案能够严重的影响你对软件...

  • Netflix 微服务架构设计解析

    1 概述 数年来,Netflix 一直是全球体验最好的在线订阅制视频流媒体服务,其流量占全球互联网带宽容量的 15%以上。 在过去的2019 年,Netflix 已经有 1.67 亿名订阅用户,平均每个季度新增 500 万订户,服务覆盖全球 200 多个国家 / 地区。 Netflix 用户每天在 4000 多部电影和 47000 集电视剧上花费超过 1.65 亿小时的时间。从工程角度看,这...

  • 『互联网架构』软件架构-git服务搭建与使用(四)

    很多跟我一样大概有十多年的同事,一直做着企业内部开发,现在还在使用svn,跟大家聊起来git,他们都知道,只是项目里用习惯了svn一直也没改变,我相信这只是时间的问题,在不久的将来必然会使用git,正如我刚入行的时候ssh还是struts1 和hibernate。git更接近互联网,更方便。有一次一个老铁告诉我,他们是上市公司,研发中心负责管理总体的代码都在svn总部那边,svn服务器挂了,...

华为云40多款云服务产品0元试用活动

免费套餐,马上领取!
CSDN

CSDN

中国开发者社区CSDN (Chinese Software Developer Network) 创立于1999年,致力为中国开发者提供知识传播、在线学习、职业发展等全生命周期服务。