进入TW后，很早就接触了feature owner这个概念，但没有真正实践过，总有一些雾里看花的朦胧。
在Serai项目，第一次有机会参与承担feature owner角色，通过亲身体验，对于其价值、职责等终于算是形成了一些有实感的理解。
关于feature owner的实践其实已有很多相关经验总结，本文主要是记录一下个人在Serai项目的体会，期待抛转以引玉。
一、什么是feature owner？
通常在一个项目中，一个团队负责开发一个产品，通过完成一个个feature，最后得到由多个feature构成的复杂系统。
如果团队规模较小，每位成员都可能掌握所有业务与技术上下文。
当团队到达十几至二十几人，交付任务的复杂度将会变得较为可观，也很难再让每个人都掌握所有上下文。
对于需要数十人乃至上百人的项目，通常会划分出多个团队进行开发。
类似于拆分大型项目，对于规模较大的团队，开发不同feature时，可以看作组成了不同的子团队，feature owner就可以理解为是各个feature子团队的主导推进者。更具体的定义是什么呢？让我们来继续看下一部分。
二、为什么需要feature owner？
没有引入feature owner时，团队在迭代中可能遇到哪些情况？
PM要把控整体进度，识别风险，保证交付完成。
如何确认feature整体是否有风险？
如何保证showcase如期展示当前迭代所有feature？
某个feature有风险时，怎样推进完成？
站会之外，PM得分别去找成员确认每张故事卡的状态，有问题就要找TL支持。临近showcase，PM时常要到处抓人。
（PM：不好意思，想确认下这张卡showcase能不能上呀？要不TL帮忙看一下？🤔）
BA要进行需求分析，同时要考虑到后续可能的其他需求，此外还要负责IKM与showcase。
新feature的需求会在技术方面带来多大改动？
需求突然变化时，如何快速确认技术上影响范围？
所有需求都确定后，如何更好地拆分故事卡？
进行IKM时，如何大让家更高效地理解卡的内容，更准确地估点？
准备showcase时，需要找谁进行支持？
BA过需求时要与TL对齐，否则会出现业务侧与技术侧理解不一致的情况，而一旦TL繁忙，就会陷入阻塞。准备showcase时，BA也只能随机去找有空的开发或测试支持。
（BA：这里数据有问题，谁能帮忙查一下？UAT挂了，谁能帮忙看一下？😱）
QA要对系统进行测试，及时发现并处理问题，保证交付质量。
测试feature时，对于涉及面较广的问题，要找谁对齐？
发现问题，要排查原因时，应该找谁帮助？
确认问题原因后，由谁进行修复？
对于不少问题，QA并不能直接定位到故事卡级别，那么分析问题时，就只能找TL或者随机找有带宽的人了。
（QA：让我们来抓一个幸运开发来看看这个问题~ 🤗）
与客户或者其他供应商的开发团队合作时，通常会涉及到大量的沟通、对接、联调等工作。
合作开发做卡时，如何做好日常沟通，问题处理，联调，结卡等？
有技术上下文需要交接时，由谁负责进行说明？
客户有时候也不知道找谁，会一个个去@团队里的人，抓住一个就不放手。
（Dev：没想到给客户的前端小哥当BA了…… 😂）
TL作为技术总负责人，需要处理繁多的高优先级事务，包括把控整体技术方案，参加与客户的各种会议，支持解决线上紧急问题，等等。
而大家很容易看出，在以上提及的多个环节中，TL也都扮演着重要角色，如果没有其他人分担，时常会陷入分身乏术，忙不过来的情况，甚至成为团队的瓶颈。
这种情况下，也很难再有余力去兼顾具体开发细节，提供技术帮助等，增加了出问题的风险。
（TL：这会不参加了！我要写卡，写卡！😤）
引入feature owner，可以更好地应对以上种种状况。
对于一个feature，feature owner可以说就是集PM，BA，TL，Dev，QA为一身的角色，承担各个角色的一部分功能，从开始分析需求直至上线正常运行，持续参与负责feature的交付流程，更流畅地引导协作，更高效地推进工作，更妥善地把控风险，更充分地保证质量。
对于一般为两周的一个迭代，考虑团队规模和feature复杂度，通常可能会涉及两到四个feature的开发，对应地分配feature owner负责，团队内职责明晰，可以有序推进交付，同时减轻了其他成员的压力。
由不同成员负责各个feature，可以尽可能保证所有人都参与其中，充分发挥个人价值，也能够使项目的每一部分都有掌握较为完整上下文的人作为feature owner。
对于在不同迭代里有关联的feature，可以由同一人负责，较为熟悉，能够更全面地进行考虑，也可以进行轮转，需要交接，但也能让更多人掌握不同上下文。
三、如何做feature owner？
1、分析业务需求
在BA完成与客户关于需求的前期沟通后，feature owner就要开始与BA对接，了解需求的背景与内容，然后参与到需求的进一步分析与澄清中。这一阶段应该充分理清需求以及对应场景，如果有模糊或者遗漏要及时澄清，可能还需与客户再做确认。
在技术方案完成后，再与BA进行对齐，根据技术方案，预估工作量给出大概点数，更合理地拆卡与排期。在IKM中，可以协助BA，简要说明每张卡相关的技术方案，让其他成员更高效地理解，给出更合理的估点，进程上也会更流畅。
进入迭代开发过程后，双方也要继续保持沟通，如果发现了遗漏的点，或者客户的需求还有一些变化，要保证信息及时流通，避免造成进度延误。
2、设计技术方案
项目前期，一般还是会由TL先与客户技术负责人沟通，产出一些基本方案。这个阶段，feature owner可以先与TL对齐，了解技术上下文，然后接手，进一步验证方案可行性。
随着项目进行，担任feature owner的成员，保证有足够技术基础，对相关上下文也足够熟悉后，就可以开始承担TL下放的职责，独立完成技术方案设计，再分别与TL和客户勾兑。因为负责的范围相对小，那么准备过程中也可以更加仔细。
技术方案，是开发feature的基础，设计时要进行较为全面地考虑。在这个过程中，也可以发现自身的不足，找到进一步学习的方向。相关内容展开来说可能会有很多，这里暂时只简单罗列一下基于后端考虑可能涉及的一些方面。
保证能够满足业务需求
检查所有相关代码，不漏过任何可能影响的点
如何设计微服务架构，是否需要创建并部署新微服务
如何设计数据库表
如何设计API以及代码结构，是否需要大规模重构
考虑安全性，如何进行权限控制
匹配前端实现
绘制流程图、时序图或其他示意图
编写技术方案文档进行总结说明
……
3、参与开发，把控进展
作为feature owner，对feature上下文最熟悉，开始开发前，除了在IKM向团队成员同步信息，在开卡时也要与对应成员再次对齐以保证理解一致。
迭代中，feature owner一般需要负责部分主要故事卡的开发，这样可以更高效地推动feature完成，与其他开发成员也能更好地沟通一些细节，同时有助于持续思考技术方案是否有潜藏的问题。
除了参与开发，feature owner还需要注意其他卡的进度与质量。站会时，了解每张卡的进度，如果发现风险要及时与相关成员沟通，必要时提供帮助。在code review中，要更专注地理解分析相关代码，及时发现问题与优化点。
按照估点与排期，feature owner需要保证所负责feature整体进展正常，不影响对接、联调工作以及其他feature开发，方便后续测试。如果发现了预计外风险，应该及时暴露出来。PM与TL的关注点可以更聚焦，只需定时与feature owner对齐。
4、与客户或其他供应商合作
需要与客户或者其他供应商的开发团队合作时，feature owner应该负责统筹，这样客户也能明确知道对接人。团队其他成员只需专注于做卡以及记录需要的信息，完成后即可释放出带宽去做其他事情。
客户需要了解技术上下文时，由feature owner进行解释说明。客户在开发中遇到疑问时，由feature owner响应并帮助解答。联调或结卡时，由feature owner对接并推进，发现问题先进行识别，如有必要再与做卡成员沟通。
合作过程中，会有很多书面或会议交流，听说读写都会涉及，语言能力与表达能力都能得到充分锻炼。
5、跟进测试与上线
测试feature时，如果QA或客户发现问题，feature owner应该跟进，协助进行排查，然后负责修复或找到做卡成员进一步勾兑。这样保证了任何feature出现问题时，QA都能通过识别表征找到有上下文的feature owner帮助，提高解决问题的效率。
在showcase中，BA或UX负责向客户展示feature，feature owner需要在准备阶段进行支持，包括提供数据，解决突发问题等，保障showcase顺利进行。
上线时，feature owner需要配合TL与DevOps，主要是确认相关代码都已在对应分支，需要做的数据migration，权限配置等操作都已记录在检查清单。如果在上线过程或回归测试中发现问题，也要协助处理，避免将更大的问题暴露给客户。
6、整理资料
在feature完成后，feature owner需要整理归档所有相关资料，包括故事卡，UI设计图，技术设计文档，API文档等，尽可能完整地保存相关业务与技术上下文，以供团队与客户后续查阅。
四、总结
对于有一定复杂度与持续性的项目，以及对应的有一定规模的团队，我认为feature owner角色有助于优化迭代流程，保证交付质量，提升成员体验，锻炼个人素质，可以充分发挥价值，是非常值得引入的实践。
对于作为feature owner的个人，对项目在整体与细节上都能够有更深入的认知，各方面的能力也都能有充分发挥与成长，虽然可能需要多分配一些时间与精力，不过相信可以在实践中找到一个较好的平衡点
进入TW后，很早就接触了feature owner这个概念，但没有真正实践过，总有一些雾里看花的朦胧。
在Serai项目，第一次有机会参与承担feature owner角色，通过亲身体验，对于其价值、职责等终于算是形成了一些有实感的理解。
关于feature owner的实践其实已有很多相关经验总结，本文主要是记录一下个人在Serai项目的体会，期待抛转以引玉。
一、什么是feature owner？
通常在一个项目中，一个团队负责开发一个产品，通过完成一个个feature，最后得到由多个feature构成的复杂系统。
如果团队规模较小，每位成员都可能掌握所有业务与技术上下文。
当团队到达十几至二十几人，交付任务的复杂度将会变得较为可观，也很难再让每个人都掌握所有上下文。
对于需要数十人乃至上百人的项目，通常会划分出多个团队进行开发。
类似于拆分大型项目，对于规模较大的团队，开发不同feature时，可以看作组成了不同的子团队，feature owner就可以理解为是各个feature子团队的主导推进者。更具体的定义是什么呢？让我们来继续看下一部分。
二、为什么需要feature owner？
没有引入feature owner时，团队在迭代中可能遇到哪些情况？
PM要把控整体进度，识别风险，保证交付完成。
如何确认feature整体是否有风险？
如何保证showcase如期展示当前迭代所有feature？
某个feature有风险时，怎样推进完成？
站会之外，PM得分别去找成员确认每张故事卡的状态，有问题就要找TL支持。临近showcase，PM时常要到处抓人。
（PM：不好意思，想确认下这张卡showcase能不能上呀？要不TL帮忙看一下？🤔）
BA要进行需求分析，同时要考虑到后续可能的其他需求，此外还要负责IKM与showcase。
新feature的需求会在技术方面带来多大改动？
需求突然变化时，如何快速确认技术上影响范围？
所有需求都确定后，如何更好地拆分故事卡？
进行IKM时，如何大让家更高效地理解卡的内容，更准确地估点？
准备showcase时，需要找谁进行支持？
BA过需求时要与TL对齐，否则会出现业务侧与技术侧理解不一致的情况，而一旦TL繁忙，就会陷入阻塞。准备showcase时，BA也只能随机去找有空的开发或测试支持。
（BA：这里数据有问题，谁能帮忙查一下？UAT挂了，谁能帮忙看一下？😱）
QA要对系统进行测试，及时发现并处理问题，保证交付质量。
测试feature时，对于涉及面较广的问题，要找谁对齐？
发现问题，要排查原因时，应该找谁帮助？
确认问题原因后，由谁进行修复？
对于不少问题，QA并不能直接定位到故事卡级别，那么分析问题时，就只能找TL或者随机找有带宽的人了。
（QA：让我们来抓一个幸运开发来看看这个问题~ 🤗）
与客户或者其他供应商的开发团队合作时，通常会涉及到大量的沟通、对接、联调等工作。
合作开发做卡时，如何做好日常沟通，问题处理，联调，结卡等？
有技术上下文需要交接时，由谁负责进行说明？
客户有时候也不知道找谁，会一个个去@团队里的人，抓住一个就不放手。
（Dev：没想到给客户的前端小哥当BA了…… 😂）
TL作为技术总负责人，需要处理繁多的高优先级事务，包括把控整体技术方案，参加与客户的各种会议，支持解决线上紧急问题，等等。
而大家很容易看出，在以上提及的多个环节中，TL也都扮演着重要角色，如果没有其他人分担，时常会陷入分身乏术，忙不过来的情况，甚至成为团队的瓶颈。
这种情况下，也很难再有余力去兼顾具体开发细节，提供技术帮助等，增加了出问题的风险。
（TL：这会不参加了！我要写卡，写卡！😤）
引入feature owner，可以更好地应对以上种种状况。
对于一个feature，feature owner可以说就是集PM，BA，TL，Dev，QA为一身的角色，承担各个角色的一部分功能，从开始分析需求直至上线正常运行，持续参与负责feature的交付流程，更流畅地引导协作，更高效地推进工作，更妥善地把控风险，更充分地保证质量。
对于一般为两周的一个迭代，考虑团队规模和feature复杂度，通常可能会涉及两到四个feature的开发，对应地分配feature owner负责，团队内职责明晰，可以有序推进交付，同时减轻了其他成员的压力。
由不同成员负责各个feature，可以尽可能保证所有人都参与其中，充分发挥个人价值，也能够使项目的每一部分都有掌握较为完整上下文的人作为feature owner。
对于在不同迭代里有关联的feature，可以由同一人负责，较为熟悉，能够更全面地进行考虑，也可以进行轮转，需要交接，但也能让更多人掌握不同上下文。
三、如何做feature owner？
1、分析业务需求
在BA完成与客户关于需求的前期沟通后，feature owner就要开始与BA对接，了解需求的背景与内容，然后参与到需求的进一步分析与澄清中。这一阶段应该充分理清需求以及对应场景，如果有模糊或者遗漏要及时澄清，可能还需与客户再做确认。
在技术方案完成后，再与BA进行对齐，根据技术方案，预估工作量给出大概点数，更合理地拆卡与排期。在IKM中，可以协助BA，简要说明每张卡相关的技术方案，让其他成员更高效地理解，给出更合理的估点，进程上也会更流畅。
进入迭代开发过程后，双方也要继续保持沟通，如果发现了遗漏的点，或者客户的需求还有一些变化，要保证信息及时流通，避免造成进度延误。
2、设计技术方案
项目前期，一般还是会由TL先与客户技术负责人沟通，产出一些基本方案。这个阶段，feature owner可以先与TL对齐，了解技术上下文，然后接手，进一步验证方案可行性。
随着项目进行，担任feature owner的成员，保证有足够技术基础，对相关上下文也足够熟悉后，就可以开始承担TL下放的职责，独立完成技术方案设计，再分别与TL和客户勾兑。因为负责的范围相对小，那么准备过程中也可以更加仔细。
技术方案，是开发feature的基础，设计时要进行较为全面地考虑。在这个过程中，也可以发现自身的不足，找到进一步学习的方向。相关内容展开来说可能会有很多，这里暂时只简单罗列一下基于后端考虑可能涉及的一些方面。
保证能够满足业务需求
检查所有相关代码，不漏过任何可能影响的点
如何设计微服务架构，是否需要创建并部署新微服务
如何设计数据库表
如何设计API以及代码结构，是否需要大规模重构
考虑安全性，如何进行权限控制
匹配前端实现
绘制流程图、时序图或其他示意图
编写技术方案文档进行总结说明
……
3、参与开发，把控进展
作为feature owner，对feature上下文最熟悉，开始开发前，除了在IKM向团队成员同步信息，在开卡时也要与对应成员再次对齐以保证理解一致。
迭代中，feature owner一般需要负责部分主要故事卡的开发，这样可以更高效地推动feature完成，与其他开发成员也能更好地沟通一些细节，同时有助于持续思考技术方案是否有潜藏的问题。
除了参与开发，feature owner还需要注意其他卡的进度与质量。站会时，了解每张卡的进度，如果发现风险要及时与相关成员沟通，必要时提供帮助。在code review中，要更专注地理解分析相关代码，及时发现问题与优化点。
按照估点与排期，feature owner需要保证所负责feature整体进展正常，不影响对接、联调工作以及其他feature开发，方便后续测试。如果发现了预计外风险，应该及时暴露出来。PM与TL的关注点可以更聚焦，只需定时与feature owner对齐。
4、与客户或其他供应商合作
需要与客户或者其他供应商的开发团队合作时，feature owner应该负责统筹，这样客户也能明确知道对接人。团队其他成员只需专注于做卡以及记录需要的信息，完成后即可释放出带宽去做其他事情。
客户需要了解技术上下文时，由feature owner进行解释说明。客户在开发中遇到疑问时，由feature owner响应并帮助解答。联调或结卡时，由feature owner对接并推进，发现问题先进行识别，如有必要再与做卡成员沟通。
合作过程中，会有很多书面或会议交流，听说读写都会涉及，语言能力与表达能力都能得到充分锻炼。
5、跟进测试与上线
测试feature时，如果QA或客户发现问题，feature owner应该跟进，协助进行排查，然后负责修复或找到做卡成员进一步勾兑。这样保证了任何feature出现问题时，QA都能通过识别表征找到有上下文的feature owner帮助，提高解决问题的效率。
在showcase中，BA或UX负责向客户展示feature，feature owner需要在准备阶段进行支持，包括提供数据，解决突发问题等，保障showcase顺利进行。
上线时，feature owner需要配合TL与DevOps，主要是确认相关代码都已在对应分支，需要做的数据migration，权限配置等操作都已记录在检查清单。如果在上线过程或回归测试中发现问题，也要协助处理，避免将更大的问题暴露给客户。
6、整理资料
在feature完成后，feature owner需要整理归档所有相关资料，包括故事卡，UI设计图，技术设计文档，API文档等，尽可能完整地保存相关业务与技术上下文，以供团队与客户后续查阅。
四、总结
对于有一定复杂度与持续性的项目，以及对应的有一定规模的团队，我认为feature owner角色有助于优化迭代流程，保证交付质量，提升成员体验，锻炼个人素质，可以充分发挥价值，是非常值得引入的实践。
对于作为feature owner的个人，对项目在整体与细节上都能够有更深入的认知，各方面的能力也都能有充分发挥与成长，虽然可能需要多分配一些时间与精力，不过相信可以在实践中找到一个较好的平衡点