矩阵式团队
一个人汇报给多个经理，而这些经理并不能理解每个人的任务优先级。
之前一直想往矩阵式团队靠，现在看来问题确实挺多，仔细想想向多人汇报就觉得够头疼的了。目前的状况看起来，我们的团队组织形式是强职能型的矩阵式开发合作团队。
敏捷型组织
聚焦团队搭建，最好的构架，需求和设计源于自组织的团队。它不是以角色为基础，而是专注于满足客户的需求。
每个敏捷团队都拥有一个用户服务，并且包括了需要的所有技能。（包括了，研发，测试，运维，产品等）
改善冲突，授权和组织边界来实现创造力的提升。团队按照服务组织起来，自主管理并让人员跨越职能部门，结果是大幅度地降低了情感性冲突。团队成员共享一个目标，不再需要争辩谁来负责或谁应该负责某个任务。每个人要对其提供的高质量，高可用性并能满足商业目标的服务负责。
劣势是，为了按照计划的方式正常发挥作用，团队需要按照构架设计中面向用户的服务重新组织。如果高质量的功能和高可用性的服务来度量，当敏捷型结构的团队在代码质量和责任上出现重叠的时候，团队将无法自治，会导致较低的创新力。
希望目前的小团队可以继续在一起工作，成立第一个敏捷型的团队。
团队规模下限为6人，上限为15人。当团队内出现沟通不畅，生产率低下，士气低落时都是团队规模太大 的信号。团队规模过小，需要注意业务合作伙伴，微观管理的经理，过度劳累的成员，团队可能无法及时 交付，或者被合作放抱怨需要更多的交付。
拆分团队，必须要考虑一些事情，比如谁出任新的经理，每个团队成员的参与度有多高，于业务负责人的关系怎么处理？首先要根据代码和工作来聚焦，最佳方案时根据故障域来拆分团队和代码，通过隔离服务来限制故障所带来的影响。
我们团队目前出现的情况是，过度劳累，有好些同学私底下再问目前的状况什么时候能结束，太累了。另外一方面，需求方还在不停地抱怨，什么时候他们提的需求可以上线。
posted on
