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