我们假设经理应负的基本职责包括以下三点：确保给工程师分配了项目，无论是自己分配的，还是根据管理层指示分配的；确保执行了行政工作，如解决了薪资问题或者传达了人事信息等；以及接收项目的状态更新信息，以便报告给高级管理层。考虑到这种基础水平的管理职责，一个新近从工程师升到管理层的初级经理可能会发现，即使只管理 6 个人的团队，行政工作和项目管理的工作都会耗费她一整天的时间。... 比起那些做过一遍又一遍的工作来说，新工作通常需要花费更多时间，而且要求更加专注。在决定一个团队的最佳规模时，经验水平是一个要考虑的关键因素。
一般来说，业务责任人和产品经理都想建立更多更大的面向客户的项目，这样他们才能不停地击败竞争对手，扩大收益来源，拓展客户基础。这时团队规模过小会带来两个主要问题。首先，根据所采用的产品开发生命周期方法不同，较大的项目需要更多的迭代或更长的开发时间。... 其次，如果增加了工程师数量，那么支持人员的数量也随之增加，包括经理的人数。
工程师天生会对自己能够完成的工作保持过分乐观的态度，如果他们推脱过去能够完成的工作量，这会是一个明显的信号，说明他们自觉生产力下降了。
比这个难得多的是在团队规模过大时，拆分团队。如果团队拆分不当，会造成可怕的后果，如代码的所有权不清楚、更难以沟通、重新适应新经理而工作压力增大。... 首先需要关注的是代码或工作，我们将在第三部分详细地讨论故障域这个概念，这些域通过隔离服务，从而限制了故障的影响范围，也许拆分团队是个把代码拆分到故障域的好机会。
Read full article from 左棍圣母F叔对《可扩展的艺术》的笔记(2)
No comments:
Post a Comment