一个事情团队内部闭环来做,一般推动起来比较容易,也很少遇到阻塞点。
但一旦涉及到需要多个团队支持,就可能会处处受限制,甚至处处碰壁。
其实换位思考也合理,因为想想如果有其他团队人员直接找你做技术支持,如果是简单的答疑还好,如果是需要协助排查线上问题或者做一些开发事情还是比较占用时间的
一般来说人力更多的是会去承接业务需求,那么应对外部的一些事情,不管合不合理、刚不刚需、紧不紧急,大多数同学第一本能反应应该是排斥的
因为这些事情的合理性、紧急性没有得到确定,且每个人手里可能都有更重要或者更紧急的事情要做,花半天甚至一天并不会增加其他需求的排期,
因此我说对于外部同学提的问题或者需求,大多数人应该是排斥、或者反馈不积极、态度不友好等。
如果是产品需求,一般由产品发起,受到的阻力会更小,只需要拉齐方案和排期即可,但也会存在多团队合作问题,比如说沟通成本和排期上。
如果是纯技术改造,没有产品支持的情况下,阻力久可想而知了,何况是在业务团队里,如果技术改造涉及多方团队那更是难上加难。
那么跨团队合作主要遇到哪些问题呢?
- 沟通成本
- 需求优先级
- 边界不够清晰
- 反馈不及时
- 配合不积极
- 理解不一致
- 重复解释、沟通
- 文档缺失
- 信息gap
- 排期相差比较大
- 合作方没有及时投入资源
那么有了一些跨团队合作项目的经验,我有了一些心得,可能不一定全面和不一定都对:
首先事情的推进要提前获得各方老板的支持,老板们知晓了这个事情,至少推动起来没那么费劲
稍大的需求和项目要引入PMO引入周会甚至日会,保证项目进度,每周项目负责人在群内做进度的同步
项目负责人需要把稳项目的整体进度
需求的启动会议和方案确定会议是必不可少的,然后就是一个整体的各方排期表,承诺联调时间、提测时间、上线时间
还有跨团队沟通更需要的就是诚意和耐心吧,其实我觉得吧,项目初期推动起来都会有阻力,所以更多的需要项目负责人做很多的沟通,让大家知道项目的重要程度,诚意和耐心到了,大家其实也不会特别难合作的。
最后还是需要再强调一些点吧
比如多团队合作一个比较关键的点就是排期表
那么排期一定不要替合作方填,确定了最终排期不能只在群里简单的艾特几次,一定要有对接人或者对接研发同学首肯,才算最终决定
(亲身教训。。。还和一个大佬起了口头冲突,我把他主管拉进群,他把我主管拉进群,哈哈,现在想想也好笑,打工人何苦难为打工人)
还有一点就是涉及多团队合作,大家投入的时间节点不一样,这一点其实是可以理解的,
比如刚好有其他以来团队人力是hang在了其他需求或者说每一方的工作量不太相同、相差较大
只要约定了一个最终联调时间即可
下面有个场景也是亲身经历的,比较恶心。。。
转载请注明:汪明鑫的个人博客 » 跨多团队合作的一点心得
说点什么
您将是第一位评论人!