一个需求的落地往往会有多个角色，比如产品、测试、研发、数据、运营、业务方等等，做一个需求就像三军打仗，要一个统帅，掌控全局。当然了这里的【统帅】不是职级上的最大，而是一个全局的协调人( 不同于pmo，下面有些工作pmo是不参与的，也不在pmo的职责范畴)；那做为后端的技术人员，这个角色在合适不过了。有机会要主动争取一下，成长很快。
一、技术主R职责
1.1、需求把控
- 明确背景：明确需求产生场景、使用场景(what)
- 明确目标：为什么要做、解决什么问题（Why）
- 不做行不行，有什么影响（If）
- 是否有其他办法来解决这个问题（Whether）
核心目标：确保需求能达到的业务目标，找到合适的评价指标 smart
1.2、方案把控
- 确保各端对需求及方案的理解一致（这个非常重要，跨部门合作时吃过亏）
- 确保技术方案的合理性，投入最小化，收益最大化
- 明确各端排期、主R和沟通协作机制（沟通的成本，决定项目的进度，参与人员越多，沟通成本越高）
核心目标：方案清晰、透明、周知各端
1.3、项目把控
- 明确项目关键节点
- 及时沟通、推进及周知
- 项目风险（延期、质量、协作）识别与管理
- 项目结果与质量保证
核心目标：保证项目进度和质量
二、项目流程把控
2.1、项目周期的参与
需求分析
- 明确业务目标，价值收益
- 明确业务流程，业务数据结构
- 梳理数据处理流程
梳理内部和外部系统交互，PS.建议采用时序图等工具
技术方案
包括方案设计、任务拆解、各端主R、各端排期
模块设计
复杂模块可以单独建立doc来进行方案设计和对比。
接口文档
后端接口，可以使用YAPI记录。
测试用例
明确和推动测试用例的评审
上线检查
- 梳理上线流程，形成CheckList，协调各端按流程上线
- 梳理代码用到的配置项、开关
- 梳理系统需要的权限配置
- 准备好降级预案，防止突发状况
2.2、项目组织与执行
参与需求评审
- PM组织需求评审，参与方包括PM、后端RD、前端RD、测试QA；
- 明确业务背景和业务目标，明确项目优先级，是否存在工期倒排情况等
明确项目组成员
- 技术方案阶段，确定项目组成员，明确各端主R：业务主R、QA主R、后端主R、PM主R；
- 担任主R的同学，需要对本次项目业务比较熟悉；
- 各端一般只有一个主R+n个S；
需求分析及方案设计评审
- 后端主R完成整体需求分析，任务拆解及工时预估；
- 后端主R完成整体方案设计，组织技术方案评审，确保需求理解一致、方案设计合理；
- 推动各端确定项目排期，包括：开发时间、接口提供时间、联调时间、提测时间、上线时间等关键时间节点；
- 确定项目沟通协作机制，比如：建立项目进度doc、建立沟通群、项目站会、项目周会、项目周报及邮件
项目推进与沟通
- 项目进度及时周知各端，并得到明确反馈，可以依次通过沟通群、电话、站会、会议、Leader等方法和渠道，确保项目沟通机制的落地
- 项目变更及时周知各端，包括需求变更、方案变更、工期延长等，并进行影响范围评估，影响工期超过2~3天（视情况而定），需周知Leader和相关负责人。
- 关注延期和质量风险，及时周知PM、Leader；确定影响范围大小，组织会议讨论解决方案；
- 推动PM组织协调各端，进行需求变更、项目阻塞等问题的处理；会议进度和结论在群里周知；
项目上线与线上故障处理
- 后端主R组织整体上线流程、上线方案，梳理上线Checklist，并组织会议评审
- 协调各端上线时间，严格按照上线CheckList执行上线
- 上线后功能验证、线上故障跟踪并及时周知和处理
三、项目总结与复盘
后端主R对项目进行总结，从研发角度对项目进行复盘；这块就不多说了，之前写过一个关于复盘的文章，有兴趣的可以看下，地址如下：点我查看
四、总结
我为什么说当一回技术主R会让你有巨大的成长呢，如果你把我上面说的都想到了，也都做到了同时项目能顺利上线，并且线上无重大问题；那恭喜你，你可能真的成长了。
人们都说：“机会是留给有准备的人”，但是,我也坚信一句：“机会也是是靠自己争取的”，天上不会掉馅饼，所以不要等待你的领导给你安排这个角色，你要自己去争取，毛遂自荐；即使一个项目落地，主R不是你，你也要以我就是主R的思想来要求自己，并寻求机会，做一回真正的技术主R，来锻炼自己。
注：以上都是我根据个人经验总结的，肯定有不完善的地方，但大方向是正确的，希望读到文章的你去其糟粕，取其精华，自己的成长才是最重要的。