建立一个多学科团队可以让成员身兼数职, 根据需要交换帽子, 他们可以专注于重要的事情, 传递用户价值.
为特定的团队角色(如QA)雇佣或承包专家, 专门从事特定技术的测试人员或开发运维工程师和开发人员, 当你的团队专注于交付产出时，是否会导致问题. They might deliver a lot more, and add value to your team if you don’t stick them in a box.
为了探讨这个话题，我们将看看下面的例子团队，团队A和团队B.
A队有:
- 后台开发人员
- 前端开发人员
- 测试人员
- 用户研究
- 产品经理
- 交付经理
B组有:
- 三个开发人员
- 用户研究
- 产品经理
- 交付经理
Team A consists of 3 specialists: Backend developer, Frontend developer and a tester. Whereas, in Team B we have 3 developers who are able to work on all aspects of the system. In our hypothetical scenario we have a backlog of issues and we’ve done a discovery of work and we know what we think we should be building to enable the citizens to achieve their goal. 所以，我们开始工作.
在A队和B队中，一切看起来都很好. 团队沟通和合作良好, 团队成员之间的工作分配得很好.
We’re 2 sprints in and we’ve developed some functionality and are able to test the real application with users. We get some initial user feedback and it transpires that one of our assumptions is wrong and we need to pivot. We initially started our service with simple business logic and it needs to be expanded for the user to fulfil their goal. We identify that our backend application powering our service needs to be a lot more complex than once thought.
Team B is able to respond to this with no issue as our developers are able to work on all aspects of our service. As Team B has no tester the team identify that they need to do some manual Quality Assurance to ensure they’ve understood the complex business rules before getting feedback from the users. 因为开发人员的团队中没有测试人员, they ask the product manager and one of the developers who hasn’t worked on the feature to test it themselves. Everything works out as they’re able to split all the work and react to other important feedback from users.
A队举步维艰. 我们只有一个人负责后端应用程序. The frontend developer isn’t confident enough to work in an area they’re not familiar with, 而且对那个领域没有兴趣. 除此之外，他们还面临着团队必须交付的压力. The backend developer now feels like they need to rush to deliver and start taking shortcuts. They stop writing comprehensive tests and throw that responsibility over the fence for the tester to pick up. 这减慢了后端开发人员的反馈循环. 而不是知道他们写的代码在写的时候是不正确的, 现在要花几天时间才能得到同样的反馈. 前端开发人员现在正在等待后端应用程序完成. 他们在找事情做, 但他们很高兴，团队的速度下降并不是他们的错.
Passing whole responsibilities to individuals within the team rather than owning the responsibilities as a team can lead to toxic behaviours like blame culture. Team A’s developers are now focusing on output they can control rather than the whole journey. An example of this can be seen when a team with specialists have tickets in their backlog that are very system based and technical focused. Compared with Team B’s tickets that are user story focused that focus on an outcome that requires changes to one or more systems.
I’ve created my example to emphasise how easily focusing on output can negatively influence different parts of the delivery process. Like where the frontend developer and tester can use their specialisms as a way of avoiding to help solve the problem. It’s important to note that a team shape like Team B would not always succeed when things start going wrong. You’d still need to ensure your team is aligned around outcomes they need/want to deliver.
Focusing on what outcomes we’re delivering and enabling the team to share the responsibility of all aspects of delivery, 我们建立了一个共同的动力来交付. 拥有一个多面手团队, they are more likely to self-organise around the work and look for support from each other. 然而, 如果你有专家的话, having a strong product manager/delivery manager to keep the focus on delivering the outcome as specifying that direction is key. 关闭 attention is required for making sure the specialists are focusing on achieving outcomes.
Sometimes we do need specialists to solve well understood specific problems with well defined outcomes. For example, Team B is looking at integrating their new system with a specific legacy application. 然而, 团队中没有人熟悉这项技术, 他们有一个交付最小可行产品的截止日期. 在这里, it makes sense to bring in a specialist who can help upskill the team to enable them to have the knowledge to progress quickly. What we don’t want to happen here is the whole responsibility of integrating the systems together to lie solely with this specialist person, 隔离服务的关键路径.
你的团队不应该以专业为中心, it’s all too easy to amplify toxic behaviours and encourage those behaviours within a team. Specialists are more likely to work within their area of expertise and start creating other issues like gaps of knowledge, 筒仓, 阻滞剂和半成品溶液. 团队B将共同努力解决问题, allowing them to share knowledge as they go and ensure everyone has the same level of understanding. 然而, within Team A specific system knowledge would only exist in specific individuals. 这就带来了其他问题, such as if a team member is not available this would impact the ability for the team to deliver, 有效地阻碍了整个团队.
Sometimes our users do not have a choice whether or not they want to use the service we build. We should be doing our best to ensure that we’re building software that delivers actual value by focusing on outcomes rather than output.
