总阅读量:次

⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 cnblogs.com/zer0Black/p/11819696.html 「zer0black」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
  4. 新的源码解析文章实时收到通知。每周更新一篇左右。
  5. 认真的源码交流微信群。

我是一个不合格的技术总监，在过去的快三个月里。我带着从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在另一个项目中，只做了导出功能，未接触数据库）

  3. 不用静止的眼光看人，人都是在不断变化的

    • 人都是在不断变化的，而我用了以往的经验去评判大家。有的高估了，有的低估了。没有把最合适的人安排给最合适的项目
    • 不应把过去的错误或者功能记在今天的账上，要持续的跟进大家的变化，持续的保持对大家的新认识。不以固有的眼光看人
    • 也应通过积极的引导，帮助同事改掉自己的不足。而不是听之任之，由其自生自灭。只有这样，团队才能进步，这也是一个leader最应该做好的事情，我在这方面差的还太远

  5. 因事定人不可取

    • 某D之前由于某次技术预研的工作，让我认定他一般。但在这次的项目中，他却成了最稳定输出的一环
    • 由此可见，不能因为某人一时做的好或者不好，就给这个人定了型，先入为主的下定论。要客观的评价一下个人，需要了解他的全部历史和全部工作。也就是第一条说的，要有全面的考核反馈机制

错误二：低估项目难度

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

反思：

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

    • 在此次前期沟通中，很多我以为，我认为都是经验主义所害。比如对接文档的问题，多问一句，可能情况就很不一样
    • 经验也可能成为风险之一，需要警惕

  3. 想法设法获取更多信息

    • 四个项目的对接人了解的信息都不全面，到我这的信息就缺失更多，而我当时以为这就是全部的情况。信息的缺失是会让判断失去方向
    • 在现有信息中，要去挖掘出更多的问题和信息，并找对接人确认。越多的信息越能为判断提供更准确的方向
    • 对接人也不清晰的情况，需要推动对接人去找相应人员获取，得到相对准确和完善的信息

  5. 锁定项目核心重难点

    • 在这几个项目中，有的项目没有在一开始就抓住项目核心重难点。比如甲项目中核心功能是存储，且需要使用客户自研存储设备，项目初期未锁定该重点问题，导致后期项目核心功能全部返工
    • 一般采取排除法来锁定核心重难点。把所有的页面可见功能点和隐含功能点列上，以排除法排除独立的关联少的模块。留下的就是重难点的核心要素
    • 针对每个核心要素搞清楚联系关系，得到最终的功能关系图（业务架构图）

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

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

反思：

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

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

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

我所吸取的教训总结

  1. 建立更全面的考核反馈体系对认识团队至关重要
  2. 不要局限于经验，沟通胜于一切
  3. 反思每一次战术失误，保证下一次的精确打击
  4. 专人专事，专职管理的人，就不要陷入开发细节中，一旦大量精力投入了开发。这将是致命的风险
文章目录
  1. 1. 项目和团队背景
  2. 2. 错误一：高估团队水平
    1. 2.1. 反思：
  3. 3. 错误二：低估项目难度
    1. 3.1. 反思：
  4. 4. 错误三：战术错误，同时面对过多的项目
    1. 4.1. 反思：
  5. 5. 错误四：管理不是轻松的事
  6. 6. 我所吸取的教训总结