架构即未来之组织
这篇内容来自《架构即未来》这本书,分别从组织架构、流程制定、技术架构三个层面来讲构建一个可伸缩可扩展的技术型产品的方法论,可以看出本书的作者是这方面多年耕耘的专家,对问题的理解非常系统性,有很深的洞见。本书可以说是截止到目前今年读过的最好的技术书籍,下面把我比较有感触的点记录下来。
组织的形式
1、职能型组织
优点:
- 每个人都是按照职级提升,大家至少知道如何按部就班工作,容易分配工作,职责明确
- 无需解释每个人都能明白这种组织形式安排的奥秘和细节,即使是新人也很容易明白哪些人哪些团队负责哪些项目
- 员工专业性方面容易达成一致,同样工种的员工坐在一起互相解答一律和制定统一规范,可以更好的执行标准
缺点:
- 单一的负责人,缺乏项目负责人。即使是开发最简单的项目都有不同部门配合完成,上面的职级列表,各部门之前都有独立的负责人,直到最上面的CTO才有公共的管理层级上的父节点,项目一旦出现问题,各个部门很容易出现责任推诿的现象
- 这种职级结构下,被证明跨部门沟通其难,一个研发工程师要找到一个对他的项目进行测试的工程师必须在职级体系中上下求索才能找到这个人
- 容易造成部门之间的利益冲突
2、矩阵型组织
如图所示,相比于职能型团队除了纵向的管理团队,还增加了项目管理团队,同样颜色的员工归属于同一项目团队
矩阵型组织,解决了职能型组织的缺点:
- 职能型组织没有项目负责人,跨部门沟通不畅,存在情感冲突,矩阵型组织项目负责人负责解决这些问题
矩阵型组织也有其缺点
- 一个人要参与多个组织,向两个或者三个人汇报,成员会有很大压力,因为各方对他的要求是不完全一致的,而且参与多个组织也必须参与到多个组织的会议中,花费更多的精力用来沟通
3、敏捷型组织
敏捷型组织的优势:
- 可以改善跨部门间合作的情感冲突,因为这是一个团队了,团队共享目标,荣辱与共,而且员工会有被授权感,这些都能实现创造力
敏捷型组织的劣势:
- 去除了一些传统上的管理岗位,这会让一些经理感到不安
- 当组织不当,如代码所有权或者责任范围有重叠的时候,会导致团队无法自治,导致创新力下降;这不意味着不能有团队来提供基础服务或者代码库,可以以内部开源的方式给其他团队提供基础能力
度量的重要性
你会开没有油量表和速度表的车出门吗?
- 管理意味着度量,度量失败即管理失败
- 如果组织很难度量每个人的表现,那么就无法度量每个人的产出
- 如果你无法度量组织的产出和工作的质量,你就无法应对突然发生和快速发展所带来的问题
使用可度量的方法工作,可以按照如下步骤:
- 把产品/服务拆分隔离,便于故障隔离,产品/服务可独立运行,可以度量
- 定义要度量的指标和结构,定时评估
- 为了完成目标,确定优化点和执行计划
度量指标方面可以以下几个方面做参考:
- 成本指标
- 绝对成本:多少工程师支出,多少服务器支出
- 每笔交易成本:把开支摊在项目上,计算每笔交易的支出成本
- 可用性指标
- 宕机时间,服务可用性时间
- 服务性能
- 生产效率指标
- 同等成本可以生产更多产品,或以较低成本生产同样多的产品
- 平均每人日产出的场景数,功能点数
- 质量相关指标
- 上线后的缺陷数目
- 每千行代码故障数
联系我: