项目和团队背景共计三个月内有四个项目没有正式的项目经理只有三个实习项目经理三个实习项目经理中一个带过一个小型持续性项目前后端共3人接近一年一个带过小项目4人一个月一个带过两个中小项目7人共计半年时间开发同事都相对年轻工作年限最长的也就三年。朝气蓬勃但的确经验不足团队中老同事新同事各占一半吧超过半数的同事来公司不到一年四个项目都基于同一个客户提供基础版本或者说框架进行开发客户方使用的基础框架过于老旧十多年前的前后端框架前端使用技术特别偏门学习成本巨大框架混乱不堪表就有快2000张说是框架但杂含着各种各样的业务代码且又必须使用开发调试的环境配置困难项目必须跑在linux上只能远程调试。项目由于过大启动缓慢编译一次大概10多分钟。我们团队不熟悉此种模式摸索浪费了一段时间客户公司较大研发部门较多。开发过程中部门协调工作占比超过一半需要和各种各样的设备做对接都是别的部门开发的。部门之间互相踢皮球找人协助困难错误一高估团队水平自以为很了解同事其实了解的太片面。在过去一年中由于做的项目比较稳定。持续产出在可控范围内客户也比较认可。导致我产生了觉得我们团队还不错的错觉整个团队在面对全新环境的情况下适应能力偏弱。难以快速稳定的产出项目开始了两个星期基本都处于熟悉环境、熟悉项目的状态一直没有有效产出。导致时间被浪费比如某A刚入职3个多月在其他项目中项目负责人给出的评价还不错导致我把他放在了重要的开发位置上。但项目一开始我就发现某A技术水平差的有点厉害多表联查的sql都写不溜。此时已无人可替他只能我上去协助他比如某B一年多来带的项目一直稳定未出大问题。但到了新项目中理解能力较弱无法快速全面理解需求。同时也暴露出了某B没有风险意识的致命缺陷不能识别风险识别出了风险也不反馈不作为导致项目多次跳票反思考核很重要全面的考核反馈更重要在人员和团队方面产生最要命的问题我想就是考核机制的问题了。由于种种原因对同事的了解都太片面。在用人方面把人放错了位置。狙击手放到了主攻手的位置上主攻手放到了指挥员的位置上。这样战斗不失败才怪呢站在一个较高的位置很容易对下面同事的能力判断失误。就我认为在人数不多的情况下最好的了解大家的方式是一起战斗。在一场战斗里观察每个人每天的态度表现、效率产出、代码质量、协调能力、对外沟通能力等。经过一个项目下来就能对这个项目组中的成员有个较全面的了解。但这种方式不能只是站在项目外看而要和大家一起就同一个项目开展工作从多方去了解一个人不只听某一人之言。对如上的某A来说就是因为只听了一人之言产生了较大的误判某A在另一个项目中只做了导出功能未接触数据库不用静止的眼光看人人都是在不断变化的人都是在不断变化的而我用了以往的经验去评判大家。有的高估了有的低估了。没有把最合适的人安排给最合适的项目不应把过去的错误或者功能记在今天的账上要持续的跟进大家的变化持续的保持对大家的新认识。不以固有的眼光看人也应通过积极的引导帮助同事改掉自己的不足。而不是听之任之由其自生自灭。只有这样团队才能进步这也是一个leader最应该做好的事情我在这方面差的还太远因事定人不可取某D之前由于某次技术预研的工作让我认定他一般。但在这次的项目中他却成了最稳定输出的一环由此可见不能因为某人一时做的好或者不好就给这个人定了型先入为主的下定论。要客观的评价一下个人需要了解他的全部历史和全部工作。也就是第一条说的要有全面的考核反馈机制错误二低估项目难度项目共计4个每个项目只支持IE都需要和额外的客户自研中间件、插件ActiveX、多种硬件设备对接。此前未做过和硬件对接的设备低估了对接的难度中间件、插件、硬件设备的对接我万万没想到什么文档都没有。只能去搜历史代码学习测试或者到相关部门去问问。而此前沟通过程中我心中默认对接是有文档或专人指导的没有问清楚前端使用框架2006年的框架和版本过于老旧由于对前端了解不足错误的估计了学习曲线团队前端同事开发前期非常吃力进度在这块也拖延了一大段跨部门沟通的难度远超我的想象此前沟通过程中明确好跨部门沟通有专人负责但到了实际工作中都变成了我们自己去对接。各个部门互相踢皮球一个摄像头到底是什么型号的问题测试需要特定型号的摄像头对接人不清楚借来的是什么型号我能花3个小时跑遍五层楼才得到答案。更不用说代码层面的指导了没有了解到客户方框架的真实情况心中以为是在spring上封装的脚手架。没想到框架中包含了快2000张表数百万的历史代码。光用户模块就有不同的三套该框架会在各个定制的基础上定期的把定制内容合到框架主干上导致了各种没有用的历史遗留代码找想要使用的功能搜索难度大增反思经验很重要但经验也很致命在此次前期沟通中很多我以为我认为都是经验主义所害。比如对接文档的问题多问一句可能情况就很不一样经验也可能成为风险之一需要警惕想法设法获取更多信息四个项目的对接人了解的信息都不全面到我这的信息就缺失更多而我当时以为这就是全部的情况。信息的缺失是会让判断失去方向在现有信息中要去挖掘出更多的问题和信息并找对接人确认。越多的信息越能为判断提供更准确的方向对接人也不清晰的情况需要推动对接人去找相应人员获取得到相对准确和完善的信息锁定项目核心重难点在这几个项目中有的项目没有在一开始就抓住项目核心重难点。比如甲项目中核心功能是存储且需要使用客户自研存储设备项目初期未锁定该重点问题导致后期项目核心功能全部返工一般采取排除法来锁定核心重难点。把所有的页面可见功能点和隐含功能点列上以排除法排除独立的关联少的模块。留下的就是重难点的核心要素针对每个核心要素搞清楚联系关系得到最终的功能关系图业务架构图错误三战术错误同时面对过多的项目回过头来看人手不足的情况同时接了过多的项目是错误的。但这的确是一个两难的问题不能简单的用错或者对来概述接或者不接这本就是一个博弈的过程。综合分析项目是否确定会交由我们来做再分析是否有能力完成考虑清楚后再下结论反思项目中总是会面临资源不足的情况永远不要想着项目中拥有最适合的资源、人员。毕竟最适合的人员不可能一直等着你的项目带项目就像打牌一手好牌做好了项目是应该。而一手烂牌打赢了才是你的能力错误四管理不是轻松的事