作者Wzy-CC
六人定律
一个最小的组织单位不应该超过六个人。这个数字不是我随口说的,全球知名的游戏工作室supercell也奉行这个规律。
如果一旦组织的人数超过六人,那么很显然,要不然就是组织有待拆分,要不然就是组织存在冗余。在一个最小的敏捷开发组织中,我认为的最佳实践应该是(事实上,每一个创业公司都应该这么做来节约人力成本):
1-2人 产品经理&&项目经理:可以画原型图,高保真图的设计师。必须可以把控项目进度。一个未来的产品经理必须会使用figma等协作设计软件。而且必须有一些前端知识。
1-2人 前端开发工程师
1-2人 后端开发工程师&&运维
1人 测试
其实如果存在全栈工程师的话实际人数甚至可以更少。
我可以从更广阔的领域来解释为什么一个组织六个人是一个最合适的数字。因为人类天生就只能对五个事物产生足够的关注,人类的五个手指数量天生就限制了人类对第六个事物的认识和关注,如果你在同时focus on六件事听起来就不太能忙的过来了。所以你最多也只能关注五个人在做什么事,加上你自己,正好是六个人。 《重构》的作者认为,每一个函数的行数不应该超过六行。这也是基于上述的原因,超过六行的代码可能理解起来就没有六行的代码看起来舒服了。
关键节点
一个组织的人数应该是六个人,一个公司中如果有五个高层向ceo进行汇报,这五个人同时每个人都管理着五个人的时候,那么这五个“高层”我称之为关键节点。 关键节点之所以关键当然是因为他既承上又启下,一旦关键节点做出了错误的选择,会导致整个小组进入错误的方向。我在之后的篇幅会结合工程原理介绍如何避免这种灾难级的错误。 在跨组织的会议中,关键节点在这个时候就应该参与进来,成为打破组织墙的存在。