矩阵式团队

一个人汇报给多个经理,而这些经理并不能理解每个人的任务优先级。

之前一直想往矩阵式团队靠,现在看来问题确实挺多,仔细想想向多人汇报就觉得够头疼的了。目前的状况看起来,我们的团队组织形式是强职能型的矩阵式开发合作团队

敏捷型组织

聚焦团队搭建,最好的构架,需求和设计源于自组织的团队。它不是以角色为基础,而是专注于满足客户的需求。

每个敏捷团队都拥有一个用户服务,并且包括了需要的所有技能。(包括了,研发,测试,运维,产品等)

改善冲突,授权和组织边界来实现创造力的提升。团队按照服务组织起来,自主管理并让人员跨越职能部门,结果是大幅度地降低了情感性冲突。团队成员共享一个目标,不再需要争辩谁来负责或谁应该负责某个任务。每个人要对其提供的高质量,高可用性并能满足商业目标的服务负责。

劣势是,为了按照计划的方式正常发挥作用,团队需要按照构架设计中面向用户的服务重新组织。如果高质量的功能和高可用性的服务来度量,当敏捷型结构的团队在代码质量和责任上出现重叠的时候,团队将无法自治,会导致较低的创新力。

希望目前的小团队可以继续在一起工作,成立第一个敏捷型的团队。

团队规模下限为6人,上限为15人。当团队内出现沟通不畅,生产率低下,士气低落时都是团队规模太大 的信号。团队规模过小,需要注意业务合作伙伴,微观管理的经理,过度劳累的成员,团队可能无法及时 交付,或者被合作放抱怨需要更多的交付。

拆分团队,必须要考虑一些事情,比如谁出任新的经理,每个团队成员的参与度有多高,于业务负责人的关系怎么处理?首先要根据代码和工作来聚焦,最佳方案时根据故障域来拆分团队和代码,通过隔离服务来限制故障所带来的影响。

我们团队目前出现的情况是,过度劳累,有好些同学私底下再问目前的状况什么时候能结束,太累了。另外一方面,需求方还在不停地抱怨,什么时候他们提的需求可以上线。

 posted on 2020-06-12 22:16  Aurinko  阅读(105)  评论(0编辑  收藏  举报