发帖
雷达卡
曾经有一段时间，我努力确保每一件小事都不出问题，然而我却发现，在这个过程中我我忽视了很多其它我更应该思考和重视的问题。我当时甚至不知道这些问题的存在，过了很长时间以后才知道。那段时间，尽管我们已经有几十号员工了，但我还是忙得脚不离地，尽最大努力自己多做事。我会参加绝大部分的公司会议，员工遇到不管遇到什么问题都来问我，而我必须要为他们提供解决问题的方案。这种忙其实并非好事。
这里存在一个真正的危险：作为领导者，你可能会为自己的异常忙碌而自我感觉良好，感觉就像自己为公司创造了多少价值一样。其实背后隐藏的是正在快速堆积的层层危机。
那段时间，我没有时间停下来去思考。然而当其中一位工程师向我说起康威定律时，我顿时愣住了，立刻决定花时间对此进行反省。康威定律的大概意思是这样的：“公司开发的产品和服务其实都是公司自身组织架构、沟通与工作方式的反映。” 确实如此，很多时候，我们从产品和服务的架构就能看出公司的组织架构。
在 Yammer 发展初期，我只负责监督一个小的工程师团队开发最初的产品，他们都在代码库里开发，然而随着越来越多工程师的加入，那个代码库变得日益庞大，也愈加难以管理，就像日益庞大的工程师团队本身面临的问题一样。只有当他们将所有工程师分为不同的小组后，他们也得以将庞大的代码库巧妙地分解成不同的小服务。我发现，人员的组织架构是可以改变产品的架构的。
在上个世纪 90年 代，我还是一位 web 开发者，那时还没有任何流程的概念，人们也不重视这一块。工程师只是简单地在网络服务器上编辑活动文件。那时也没有所谓的测试，更没有版本控制。如果放在今天，那样绝对乱套了。现在我们要想让众多工程师在一块高效工作，我们就需要有一个开发方法学。除了适用于工程师的开发方法学外，现在很多公司甚至缺少一个有效的组织方法学：一个不是什么工作都要你亲自来管的情况下依然能确保公司高效运转的系统或流程。
在 Yammer 的时候，我们做的非常正确的一件事是：持续迭代和完善开发方法。随着团队规模的扩大，团队的开发效率反而降低了，这迫使大家不得不思考这样一个问题：“一个团队在黑客马拉松上开发产品的速度为何比平日里开发快那么多？” 大家开始意识到，因为我们平时同时在开发的东西太多，而在开发过程中的沟通效率却又非常低效。大多数时间里，人们需要同时兼顾多个项目。
后来我们制定了一个规则：在一个新项目所需的全部人员没有齐备并可以完全投入到这个项目里之前，我们是不会启动这个项目的。一旦人员齐备，我们会赋予这个新组建的项目团队绝对的自主权和决策权，不需要外部授权审批就能独自把项目做好。一般情况下，一个项目 2-10 周能完成。一个项目完成后，团队就会解散，大家再各自进入其它项目。通过这种方法，公司创始人就不需要凡事亲力亲为。例如，践行上面的规定后，我就不需要亲自过问开发架构或编码规范，他们自己完全可以高效完成。
作为领导者，你的目标是建立一个不再依靠你、甚至不需要你的组织架构和工作流程。
来源：36氪
提升卡
置顶卡
沉默卡
变色卡
抢沙发
千斤顶
显身卡
京公网安备 11010802022788号
