I work for a small software company; we only have two developers. Before I started writing software, I studied psychology and I got an MBA after that, so I can tell you from extant literature that the average person can manage 2 - 7 things with the optimal being 4- 5. So, your best bet is to get to groups of 5 or fewer. If you have 5 teams, one person can manage all 5 of those teams. If you have 25 teams, one person manages each of those teams and one person manages the 5 managers.
Personally, I will always have two programmers working at the same desk. My lead developer and I work at a very large desk. We face each other and there's no divider. We get along really well and the ease of collaboration makes us very efficient. I'll probably always have as many as 3 - 4 programmers working in the same office at a time. I'll keep them facing each other so you still get privacy and so that making eye contact to ask questions is easy and comfortable.
Also, I won't keep my programmers in a common area. Distractions can be extremely costly for programmers. I like them to have the ability to close their doors and say, "nobody bug me today . . . I'm in the zone!"
Finally, ideally, developers would work on as few projects at a time as possible. Context switches are killer in a development environment. A simple distraction can cost as much as an hours worth of productivity. A context switch can be several hours. Because we're so small, we often work on 5 or 6 projects in the same day. Larger companies dedicate programmers almost exclusively to one project and this cuts back on the efficiency losses due to context switches.
In the Microsoft Windows and office organizations, product development teams (mostly) consist of people in three roles, program management (PM's), testers and developers.
Of course, developers are responsible for developing. The test team is responsible for developing functional and related tests and infrastructure; and running the tests to find bugs. Very little testing is done by hand - we spend a lot of time automating things. This includes designing things to make them more easily testable.
The program management role is responsible for communication, coordination and planning. This will mean different things to different teams. But they are the glue that holds everything together.
From an org chart perspective, things are very conventional. Most mangers have between 3 and 9 people reporting to them - not too flat, but not too deep. A very flat org tree would not work well at Microsoft (this doesn't mean the are bad, but from a cultural standpoint, having more than 9 direct reports is challenging).
We also have "Team Lead" positions and "Project Engineer" positions. I'm sure there are other ones that I'm forgetting but I haven't had enough coffee yet this morning.
At my company, we have an extremely flat management structure. There is no hierarchy whatsoever in our dev team; all the software engineers are at the same "level" and report directly to the VP of Software Development. Occasionally one of us will be tapped to lead a project, but in our company, that just means a different set of responsibilities, not a promotion. This is kind of cool as it has caused our dev team to become a meritocracy.
We have an HR reporting relationship that differs from the teams that do the work. We have three Scrum teams that have a couple of product owners, but the people on those teams don't necessarily report to someone on their team. The senior devs (three of us) report to the director of engineering, and the remaining other devs (six) report to two of the senior devs. Meanwhile, the testers and SDETs all report to the senior SDET. So, in terms of HR management, there are three middle managers who report to the director of engineering, along with one senior dev who doesn't have any reports and our architect. Those fifteen or so people are in turn spread across three Scrum teams that don't necessarily align to the org chart. The Scrum teams are responsible for the day-to-day determination of what people should be working on, while the HR reporting relationship is for job performance, any problems people might have, career path stuff, things like that.
发布评论
评论（8）
我在一家小型软件公司工作； 我们只有两个开发人员。 在我开始编写软件之前，我学习了心理学，之后获得了 MBA 学位，所以我可以从现有的文献中告诉你，普通人可以管理 2 - 7 件事，最佳数量是 4 - 5 件事。所以，你最好的选择是参加 5 人或更少的小组。 如果您有 5 个团队，则一个人可以管理所有 5 个团队。 如果您有 25 个团队，则每个团队由一名人员管理，并由一名人员管理 5 名经理。
就我个人而言，我总是让两个程序员在同一张办公桌上工作。 我和我的首席开发人员在一张非常大的办公桌前工作。 我们面对面，没有任何隔阂。 我们相处得很好，轻松的协作使我们非常高效。 我可能总是同时有 3 - 4 名程序员在同一个办公室工作。 我会让他们面对面，这样您仍然可以获得隐私，并且通过眼神交流来提问会变得轻松舒适。
另外，我不会让我的程序员呆在公共区域。 对于程序员来说，分心的代价可能极其高昂。 我喜欢他们能够关上门并说：“今天没人打扰我……我很专注！”
最后，理想情况下，开发人员一次应处理尽可能少的项目。 上下文切换是开发环境中的杀手。 一个简单的干扰就会导致一个小时的生产力损失。 上下文切换可能需要几个小时。 因为我们规模很小，所以我们经常在同一天处理 5 或 6 个项目。 较大的公司几乎将程序员专门致力于一个项目，这减少了由于上下文切换而造成的效率损失。
I work for a small software company; we only have two developers. Before I started writing software, I studied psychology and I got an MBA after that, so I can tell you from extant literature that the average person can manage 2 - 7 things with the optimal being 4- 5. So, your best bet is to get to groups of 5 or fewer. If you have 5 teams, one person can manage all 5 of those teams. If you have 25 teams, one person manages each of those teams and one person manages the 5 managers.
Personally, I will always have two programmers working at the same desk. My lead developer and I work at a very large desk. We face each other and there's no divider. We get along really well and the ease of collaboration makes us very efficient. I'll probably always have as many as 3 - 4 programmers working in the same office at a time. I'll keep them facing each other so you still get privacy and so that making eye contact to ask questions is easy and comfortable.
Also, I won't keep my programmers in a common area. Distractions can be extremely costly for programmers. I like them to have the ability to close their doors and say, "nobody bug me today . . . I'm in the zone!"
Finally, ideally, developers would work on as few projects at a time as possible. Context switches are killer in a development environment. A simple distraction can cost as much as an hours worth of productivity. A context switch can be several hours. Because we're so small, we often work on 5 or 6 projects in the same day. Larger companies dedicate programmers almost exclusively to one project and this cuts back on the efficiency losses due to context switches.
在 Microsoft Windows 和 Office 组织中，产品开发团队（大部分）由三个角色组成：项目管理 (PM)、测试人员和开发人员。
当然，开发者负责开发。 测试团队负责开发功能及相关测试和基础设施； 并运行测试以发现错误。 很少有测试是手工完成的——我们花了很多时间来实现自动化。 这包括设计一些东西以使其更容易测试。
项目管理角色负责沟通、协调和规划。 这对于不同的团队来说意味着不同的事情。 但它们是将一切粘合在一起的粘合剂。
从组织结构图的角度来看，事情非常传统。 大多数经理有 3 到 9 名员工向他们汇报——不会太扁平，但也不会太深入。 非常扁平的组织树在 Microsoft 不会很好地发挥作用（这并不意味着组织树不好，但从文化的角度来看，拥有超过 9 名直接报告是具有挑战性的）。
In the Microsoft Windows and office organizations, product development teams (mostly) consist of people in three roles, program management (PM's), testers and developers.
Of course, developers are responsible for developing. The test team is responsible for developing functional and related tests and infrastructure; and running the tests to find bugs. Very little testing is done by hand - we spend a lot of time automating things. This includes designing things to make them more easily testable.
The program management role is responsible for communication, coordination and planning. This will mean different things to different teams. But they are the glue that holds everything together.
From an org chart perspective, things are very conventional. Most mangers have between 3 and 9 people reporting to them - not too flat, but not too deep. A very flat org tree would not work well at Microsoft (this doesn't mean the are bad, but from a cultural standpoint, having more than 9 direct reports is challenging).
我们还有“团队负责人”职位和“项目工程师”职位。 我确信还有其他的事情我忘记了，但今天早上我还没有喝足够的咖啡。
We also have "Team Lead" positions and "Project Engineer" positions. I'm sure there are other ones that I'm forgetting but I haven't had enough coffee yet this morning.
我们有：
业主。
开发人员（从技术上讲，所有者是开发人员之一）。
没有中层管理人员，没有头衔，没有不必要的手续。
对我有用。
We have:
The owner.
The devs (the owner is technically one of the devs).
No mid-level managers, no titles, no unnecessary formalities.
Works for me.
在我的公司，我们有一个非常扁平的管理结构。 我们的开发团队没有任何等级制度； 所有软件工程师都处于同一“级别”，并直接向软件开发副总裁报告。 有时我们中的一个人会被任命领导一个项目，但在我们公司，这仅仅意味着一系列不同的职责，而不是晋升。 这很酷，因为它使我们的开发团队成为精英管理团队。
At my company, we have an extremely flat management structure. There is no hierarchy whatsoever in our dev team; all the software engineers are at the same "level" and report directly to the VP of Software Development. Occasionally one of us will be tapped to lead a project, but in our company, that just means a different set of responsibilities, not a promotion. This is kind of cool as it has caused our dev team to become a meritocracy.
大多数情况下，我们的设置如下：
经理 <- CMMI 协调员 <- 软件工程师 I-IV
经理 <- 系统工程师
这是一个相当简单的设置，但效果很好。
For the most part, we're setup like this:
Manager <- CMMI Facilitator <- Software Engineer I-IV
Manager <- Systems Engineer
It's a fairly simple setup, but it works well.
[导演] <-> [PM] <-> [开发人员、测试人员]
[开发人员] <-> [导演]
相当平淡。
[Director] <-> [PM] <-> [Developer, Tester]
[Developer] <-> [Director]
Quite flat.
我们的人力资源报告关系与开展工作的团队不同。 我们有三个 Scrum 团队，其中有几个产品负责人，但这些团队中的人员不一定向其团队中的某人汇报。 高级开发人员（我们三人）向工程总监报告，其余其他开发人员（六人）向其中两名高级开发人员报告。 同时，测试人员和 SDET 均向高级 SDET 汇报。 所以，在人力资源管理方面，有三名中层管理人员向工程总监汇报，还有一名没有任何报告的高级开发人员和我们的架构师。 这十五个人左右又分布在三个 Scrum 团队中，而这些团队不一定与组织结构图保持一致。 Scrum 团队负责确定人们应该做什么的日常工作，而 HR 报告关系则负责工作绩效、人们可能遇到的任何问题、职业道路等。
We have an HR reporting relationship that differs from the teams that do the work. We have three Scrum teams that have a couple of product owners, but the people on those teams don't necessarily report to someone on their team. The senior devs (three of us) report to the director of engineering, and the remaining other devs (six) report to two of the senior devs. Meanwhile, the testers and SDETs all report to the senior SDET. So, in terms of HR management, there are three middle managers who report to the director of engineering, along with one senior dev who doesn't have any reports and our architect. Those fifteen or so people are in turn spread across three Scrum teams that don't necessarily align to the org chart. The Scrum teams are responsible for the day-to-day determination of what people should be working on, while the HR reporting relationship is for job performance, any problems people might have, career path stuff, things like that.