团队情况这个问题老生常谈了，大部分互联网公司的项目都可能会遇到这样的问题，这里并不能给到大家一个具体的、彻底的、完美的解决方案，具体的项目、团队情况需要具体的分析，我这里记录一下遇到这种问题时候的一些思考和处理方式吧。
来到新的公司后，担任XX项目开发组长，主管先让我带5个人的团队：2个前端、2个后端、1个测试。
我主要负责项目的重要业务模块开发、进度把控和日常问题处理，一半开发一半管理，在上家公司已有技术管理经验2年多，再上任技术管理工作很快 能适应。
和团队成员接接触第一周后：- 明显察觉到了人员的能力参差不齐：有1个前端和1个后端的开发能力、项目经验有很大的问题，这就为后面的项目延期埋下了雷。
- 需求不明确的情况比较多，很多流程梳理不通，研发也不主动去解决
我是4月中旬来到公司的，4月最后2周团队都有目标要完成，结果看来都是最后2天大家都加班了去搞，但是最后也没有搞出一个好的结果。
开始思考于是我开始反思自己来到新团队后，
- 团队目前有哪些问题？
- 怎么去解决这些问题？
今天是5月劳动节回来后的第一天工作日，早上到公司后，9.30组织大家开早会
主题为:4月遇到两次项目延期了，原因是啥？如何解决？并总结。
我也早早地做好了总结，这里做下记录：
项目延期的主要原因：- 产品给的需求文档不明确。
- 前端XX也要总结一下，页面校验参数的统一方法、文件上传及回显、后台的常规页面基础开发，前端开发比较拖，所以导致延期的一个主要原因，属于人员能力问题。
- 后端需要给出接口文档(请求参数、返回参数)，属于开发规范性问题。
- 我们研发主动找产品、找提需求的人花时间去弄清楚，不要被动，大家积极起来才能把工作干好！这样做才是当前情况最快的解决方案，只有大家积极主动起来，事情才能推动去解决。
- 当然后续还需要和领导沟通，减少需求不明确的情况发生，这个也是领导正在做的事情。
团队成员不是我招的，所以对每个人的来历不清楚，所以当我发现人员能力不足的问题，第一时间和领导沟通了解相关人员情况，并向领导说明了能力不足的问题，领导说也注意到这个问题，说后面公司会经过考核处理。
当然结果怎么样不是我能决定的，我提出了我看到的问题，也给出了对应的建议解决方案，同样我也是一个刚来公司的人，如果我没带好团队，没做好自己的工作，我也要对自己的工作负责。
我认为团队成员应该有的最最最最基础能力
- 能胜任基础开发工作，比如前后端开发一个模块的后台增删查改的模块，能够在指定时间内开发完成。
- 如果有技术相关的问题，会主动找你沟通寻找解决方案，基本的沟通能力、主动性！！！
- 拿到需求有提问，先思考、后开发（经验的体现）。
这里主要是针对有工作经验的情况，不考虑实习生，因为公司目前招人都是马上干活的，如果满足，团队的整体效率就会高很多。
如果都不满足上述基础能力的人，该优化就优化，如果确实要继续用，那这个人除了能力差点，但是主动沟通，做事也比较积极、那这样的人是可以培养的。反之，如果经过了多方面的考核，还是拖团队后腿，该优化就优化掉，不要犹豫！
这也是时刻对自己的提醒：如果自己不学习提示自己，下一次优化的就是自己。总之，木桶效应非常适用于团队情况。
规范性问题木桶效应是讲一只水桶能装多少水取决于它最短的那块木板。
规范性问题需要管理者去制定一套标准的规范，比如接口文档使用XX，接口统一返回数据格式等...这个就比较好解决。
以后怎么做保证不延期？- 所有的开发拿到需求开发工作前，都要有一个评估完成时间，也就是截止时间，组长做好记录。
关于评估时间方法：
1.5倍方法:即你评估时间 X 1.5倍，比如开发这个需求我需要2天，那么你评估3天是一个比较合适的，因为这个评估时间主要包含了
- 你的正常开发时间
- 沟通时间（和产品扯皮的时间）
- 预留时间（预防其他事情影响你的开发进度时间）
一定要说明的这个是研发完成开发时间，不包含测试时间。
评估时间的合理性:
如果一个简单的模块研发评估时间较长，组长需要评审他这个时间是否合理，根据实际人员能力和情况评估。
- 评估时间是开发前期一个重要的能力体现,绝对不能说做一步看一步，也不能因为需求不明确我们就没有办法评估，这种情况找我沟通，不明确的需求我们就和提需求的人对，多花点时间把不清楚的地方理出来，就能更准确评估。
- 如果在需求理清楚的情况下，以及和我沟通过了，你还没有办法评估一个开发时间,这个就是你的问题了！
- 提前预警，意思就是不要到了最后1、2天才发现进度问题做不完了，组长应该每天跟进，早发现早解决。
基于前提，已经有评估时间的情况下，那到了时间没完成，该加班就得加班了，全体项目组都要一起加班去完成。
一只鸟站在树枝上从不怕会断,因为它相信的是自己的翅膀,这就是生存法则，I·m Focus,下期再见！