「项目管理」如何做好研发FO角色？
角色定位
FO （Feature Owner），项目某一阶段/版本迭代生命周期的总负责人。基于从需求发起、研发接入、上线等项目过程阶段，可以根据职责本位不同来推荐具体项目成员、干系人担任FO角色，前端、 客户端 、服务端、测试、产品都可以根据Feature特性来进行选择，从项目长期实践结果来看，由于研发角色的特殊性，在项目实践中参与度和投入度更高，更接近具体项目动作，容易识别问题和风险并身体力行推进，大部分会推荐研发角色来进行FO履职。
能力要求
-
沟通协调能力
- FO要具备团队服务意识。善于沟通表达，能够在团队中主导项目过程，调和各方面矛盾，保证信息通道的有效性、及时性和准确性，为团队事件保驾护航。
-
解决问题能力
- FO要具备结果导向意识。能够基于项目经验主动识别潜在风险进行暴露和标记，对问题施加手段进行干预和治理并最终解决，凡事必有反馈和结论，避免抛出问题、浮于问题直接逃逸。
-
文档沉淀能力
- FO要具备客观数据驱动意识。项目流程是书面规范和共事认知，规范的约束力需要领导角色督促把控，更需要参与者的执行力履行。项目过程的核心节点需要配套有相关文档交付物做支撑，工作任务需要量化清晰明细，问题要记录和反馈，一切过程数据都尽可能可溯源。
-
决策影响能力
- FO要具备本位主人翁意识。把项目核心事件及时推进作为第一要务，对项目生命周期时间轴、进度条敏感，通过沟通、文档、规范、反馈等多种方式在各环节植入影响力，引导各成员朝着最终交付迈进，对Feature结果全盘负责。
权利责任
-
权利：对Feature生命周期管理
-
项目核心事件的主导权
-
项目过程数据的知情权
-
问题风险的追究权
-
矛盾争议的决策权
-
-
责任：对Feature最终结果负责
-
跟进并推动项目核心事件
-
明确干系人并保持信息同步
-
识别暴露风险并及时干预进行解决
-
量化明细项目过程数据交付各节点输出物
-
项目过程
项目过程由核心里程碑节点进行拼接，阶段分为需求设计阶段、研发接入阶段、测试介入阶段、上线验收阶段。
核心里程碑
节点交付物
每个核心节点要进行交付对应输出物，主要有技术方案、项目过程文档、联调文档、测试报告、上线报告等。
| 项目阶段 | 核心节点 | 交付物 |
|---|---|---|
| 需求设计阶段 | PRD初稿、结稿 | - |
| 研发介入阶段 | 技术评审 | 技术方案文档 |
| 编码开发 | 项目过程文档（开发阶段） | |
| 联调 | 项目过程文档（联调阶段）联调文档（联调进度、联调问题）技术方案文档（接口文档） | |
| 测试介入阶段 | 用例评审 | - |
| 测试 | 项目过程文档（测试阶段）测试报告 | |
| 上线验收阶段 | 上线 | 技术方案文档（上线checklist）上线报告 |
把控原则
团队协作沟通有效、透明、充分
一般而言，项目过程的干系人是比较固化的，要充分明确Feature的具体参与人和执行人，哪些是负责模块决策的，哪些是负责具体执行的，保持端对端沟通的有效性。
涉及多方关注的沟通内容及输出方式尽量采取Feature同步群内进行，避免点对点出现信息遗漏，保证信息传递的透明性。
沟通意味着信息不光有发起，还要有反馈，沟通的目的是将信息传达到位？还是寻求认可观点？更或者是需要讨论并达成共识？信息发起方要及时拿到反馈结论，没有反馈和达成共识的信息输出是无效的。
项目过程数据量化、具体、准确
项目阶段的开发过程、联调过程、测试过程等是整个项目周期中耗时占比较长的核心过程，也是项目出现风险最频繁的节点，项目过程的任务进度、测试进度、问题解决进度等是项目稳定推进是否存在风险的晴雨表，项目文档一定要完备记录并进行数据量化。
项目过程数据需要客观、详细记录，落实到模块、负责人，将每个模块、每个参与人的任务进度、问题进度进行时间轴和节点对齐，严格把控每个参与者的进度校准来保证整体项目进度的准确度。
风险问题必须识别、暴露、反馈
项目风险发现越早，干预越早对项目的稳定性破坏越小，保持敏锐的风险意识和嗅觉才能挖掘和主动发现潜在问题，定位后需要进行及时暴露和同步，拉取干系人进行同步并归档入项目过程文档进行记录，达成干预手段和预期最终进行反馈。
治理手段
个人维度：任务拆解进行行为把控
对于个人而言，要分模块分角色进行任务拆解，让每个人明确意识到Feature中职责、工作范围、完成时间、实现难度、潜在风险等，可以进行有效的WBS 管理，举例如下：
- ✅ *正常*：记录归档即可
- 🔶 *延误*：信息需要同步，可控可不升级
- 🔴 *阻塞*：明显进度卡点需要暴露、升级
| 角色 | 模块 | 任务内容 | 负责人 | 排期（人/天） | 实际进度 | 备注 |
|---|---|---|---|---|---|---|
| WEB端 | XXX | XXX | @XXX | 1 | 🔶 80% | 进度DELAY，加班追赶，暂无风险 |
| - | XXX | XXX | @XXX | 1 | ✅ 50% | 进度正常 |
| 客户端 （IOS） | XXX | XXX | @XXX | 1 | 🔶 80% | 进度DELAY，加班追赶，暂无风险 |
| - | XXX | XXX | @XXX | 1 | ✅ 50% | 进度正常 |
| 客户端 （Android） | XXX | XXX | @XXX | 1 | 🔴 80% | XXX原因，阻塞 |
| - | XXX | XXX | @XXX | 1 | ✅ 50% | 进度正常 |
| 服务端 | XXX | XXX | @XXX | 1 | 🔴 80% | XXX原因，阻塞 |
| - | XXX | XXX | @XXX | 1 | ✅ 50% | 进度正常 |
时间维度：里程碑节点进行目标把控
- 里程碑时间轴：强化时间节点意识，小阶段目标导向
- 项目甘特图：WBS+Timeline结合量化进度条
沟通维度：日会机制进行进度把控
-
频率： 进度正常保持每日一次，建议每天晚饭前进行，如17:45开始，持续5~10分钟完成
-
形式： 线上、固定会议室均可，以项目过程文档为核心内容进行展开。
-
内容 ：闭环上一轮TODO；同步参与人工作任务进度；挖掘评估风险，产出问题需要落实到人、DDL、解决方案并达成共识。
FO要提前安排会议内容，把控会议节奏，引导成员讨论项目过程和风险问题，不要过于深入某个细节演变成问题谈论会。
- 沉淀：会议纪要
非正常、高风险项目进度阶段、风险频繁阶段可以适当增加沟通频次，加速信息流通，避免造成资源占用可以针对责任人提高沟通频次和影响干预，阻塞卡点可以随时升级寻找资源支持。
| 任务内容 | 完成时间 | 负责人 | 是否完成 |
|---|---|---|---|
| 任务内容A | yyyy-mm-dd | 负责人A | ✅ |
| 任务内容B | yyyy-mm-dd | 负责人B | ✅ |
| 任务内容C | yyyy-mm-dd | 负责人C | ✅ |
数据维度：沉淀交付物进行数据把控
-
『文档』 项目过程文档、技术方案、联调文档、测试文档等，可在相关文档模板中查找或者自建。
-
『平台』 需求管理、测试管理、Feature沟通群等
风险维度：阻塞卡点进行逐层升级
项目过程中最重要的是参与者和工作任务。
参与者出现问题则按照工作汇报层级关系进行同步和升级，寻求核心角色介入干预，板正参与方角色异常问题。
工作任务出现问题则按照Feature的最终交付关系逐层同步和升级，寻求Feature链路上参与各方的理解和方案，给予时间或资源支持。
核心动作
产品协作
| 协作角色 | 涉及里程碑节点 |
|---|---|
| 产品 | PRD评审、产品验收 |
💁 FO核心动作
-
🚩 PRD评审中
-
PRD质量把控 FO需要敦促产品补充评审环节遗漏的逻辑、细化需求，完善流程图、状态机、枚举、原型图、数据埋点等，帮助团队成员更好地理解Feature诉求，扫除认知障碍。
-
需求合理性评估 如果FO即Feature执行人，可自行完成评估，若Feature涉及多端多角色干系人则需要依靠具体负责人或执行人评估结论进行确认完成综合评估。
-
人力排期评估 同上。
-
变更风险评估 同上。
-
-
🚩 PRD评审后
-
项目过程问题暴露
产品是每一个Feature发起的负责人，在整个产品交付链路上处于上游，产品工作投入重点在需求调研、PRD设计评审等环节，进入技术设计等后续节点后的一系列问题需要研发FO来进行上游反馈和有效沟通 -
核心里程碑进度同步
首先，在技术方案评审通过后，人力排期也完成确认，需要把开发周期、联调、提测、用例评审、PPE上线、正式上线、APP发布等每一个核心里程碑明确、清晰地输出到产品侧并敦促其与业务沟通确认。其次，FO要按照至少日维度频次进行进度同步，阻塞问题需要第一时间进行同步。 -
需求明细化调整
工程项目的一大特点是需求渐进明细化，这是客观原因决定的，再完美周全的设计和评估也难免在实践过程中遇到疑问和阻碍，这时候需要和产品进行确认沟通将需求再次进行明细或者调整，这种明细化理论上是可以接受的，而且FO应当多督促产品在更早地环节明细需求要点，这样才能更好的进行评估和实现，规避变更风险，它能增强彼此对Feature的理解，对于交付输出来说更贴近诉求本身。
❗️注意：该环节容易升格为“需求变更”问题，由于逻辑漏洞、考虑不足等进行了补充甚至修改，导致与评审版本大相径庭，潜在地破坏设计动摇排期，此类问题是项目风险点之一，FO需要特别留意，防止这种悄无声息地“加码”操作，严重时需要坚持退回到PRD评审节点重新发起，不要把风险下沉到下游领域。 -
需求变更控制
完成PRD评审后，代表PRD处于封板状态，任何变更调整都需要重启流程进行评估，识别好“明细化”与“变更”的区别。Feature团队要统一认知，减少这种操作，让上游同学充分理解“需求变更”的风险，FO需要充分利用项目机制和流程规范来约束该操作，加重变更的风险成本到上游变更方而非下游交付方来达到治理目的。
-
-
🚩 产品验收
- 功能灰度 在测试工作结束后，FO要督促产品同学在BOE/PPE环境进行Feature体验，确认交付物与Feature预期，记录差距进行及时修正。
- Feature闭环 功能上线后，FO要敦促产品同学完成Feature验收，推进项目过程到交付闭环。
研发协作
| 协作角色 | 涉及里程碑节点 |
|---|---|
| 研发 | 技术评审、开发过程、联调、showcase、上线 |
💁 FO核心动作
-
🚩 技术评审
FO要充分了解技术方案的设计，挖掘技术方案变更对现有系统自身及外部上下游的影响，考虑兼容性，识别风险。能在技术层面治理把控的优先协作各方调整完善技术方案，超出技术方案可控范围的要充分和产品、业务等上游沟通进行评估和确认。
标识风险点的问题，不限于已确认、已知悉的内容，潜在风险也可根据经验、以往沉淀进行罗列和暴露，如与公司外部某业务进行联调由于联调开发环境、工作时间不匹配等不确定因素可以进行一定程度的悲观评估、降低预期。
FO要组织各模块参与人进行精度适中的工作任务拆解，帮助参与人充分意识到工作内容细节和构成，比如研发同学不能仅仅评估开发任务时间，还要算入自测时间、UT时间等；测试同学不能仅仅评估功能测试，还要算入各种冒烟、接口测试等工作量。工作量评估、排期确认一定要明细化，通过拆解详细任务来把控，而不是“大概齐”、拍脑袋评估。 -
🚩 开发过程
FO要在项目开发过程中拉起日会机制，若项目进程正常可以一日一会，若风险问题过多需要及时检查进度可以一日早晚两会进行敦促和把控，会议内容要通过项目过程记录文档来记录和呈现，主要记录任务进度和风险问题，切忌拉会口头形式交流。
FO的核心职责之一是要发现问题，日会是项目沟通汇报发现问题的重要一环，无效的问答式“有问题吗？”“没问题”是主观判断，一定要拉出文档面对工作任务清单进行进度推演和计算，通过客观数据来把控真实情况，这既是对项目真实进度情况的充分了解，又是对每位项目成员个人工作情况的监督和管理。 -
🚩 联调
-
联调进度
FO需要将各联调模块进行任务拆解，明细化成具象数据呈现和进行推进，每个最原子任务落实到人维度，方便确认和问题跟进追踪。 -
联调交付物
要联调了什么？联调的结果怎么样？联调的问题是什么？等等，都需要落实到联调文档进行记录和跟进追踪。 -
联调问题
联调问题需要坚持“日清、日净”，FO可以把正常联调任务明细拉起一个进度板，再把联调问题拉起一个进度板，一手抓正常联调任务，另一手抓联调问题，同时综合评估联调过程的风险。 -
Showcase
showcase环节最大的问题就是showcase不通过。
首先，FO可以在showcase提前一天结束时确认自测case计划完成度，在日会进程中追拿结论，如果不能及时完成需要敦促延误方给出结论和DDL，流程节点上及时干预来避免问题产生。
其次，如果showcase不通过，督促加快自测case完成和问题解决并给出时间预期，切忌频繁组织不充分的showcase无意义会议再次耽搁进度。 -
上线
FO督促研发完成checklist检查，输出上线清单和上线报告，督促各方观测上线后业务数据和稳定性等。
-
测试协作
| 协作角色 | 涉及里程碑节点 |
|---|---|
| 测试 | 用例评审、测试过程、上线 |
💁 FO核心动作
-
🚩 用例评审
帮助Review核心用例是否有缺失，同步强调核心流程、变更的风险，加强测试同学的关注度。 -
🚩 测试过程
测试过程的风险点大多数在于问题过多严重影响测试进度，FO要敦促问题“日清、日净”，和开发过程动作类似，此时日会进度切换为测试进度和测试问题，明细化两部分数据进行综合评估。
此阶段的主导角色是QA同学，FO需要和QA进行充分沟通，频繁、严重阻塞测试进度是否需要重新发起showcase，也要review用例情况和历史showcase情况。 -
🚩 上线
督促测试同学及时完成上线后验证，问题需要及时记录并跟进。
业务/运营协作
| 协作角色 | 涉及里程碑节点 |
|---|---|
| 业务/运营 | BRD评审、产品验收 |
💁 FO核心动作
-
🚩 BRD评审
一般核心Owner会参与到业务BRD设计评审工作中，在Feature源头进行方案影响和引导，可以通过个人经验或者研发、测试等职能本位视角给予更多的补充甚至修正。 -
🚩 产品验收
确认好上线节点时间，让产品预留好时间及时进行线上验收工作，切忌上线后无验收或延迟太久完成验收。
BadCase
- 只反馈结果不足以反馈客观情况
“项目进度正常吗？”“正常。”
进度反馈不要使用“空头支票”来获取，拉出项目过程文档，针对已经拆解好的任务分配（WBS）逐条进行对齐，可以使用百分比、 进度条形式进行量化检查，对齐每个人的进度来治理个人进度概况，汇总后每个人进度及模块整体进度后展示项目整体进度，是否出现进度问题需要客观数据表达，而不是通过参与人主观输出，参与人只需要对个人任务进度同步负责。
- 一直有人应答跟进却没有结论反馈
“这个问题XX来跟进。”“…”
问题定位和认领后需要分配到人及时记录入档并提供反馈时间，在反馈时间给予解决结论并确认是否解决。
- 缺乏项目过程数据支持
“这个问题是XXX。”“好的。”
会议纪要、沟通纪要需要落实到项目过程文档中做沉淀和归档，不要流于形式，要养成工作留痕的好习惯。
- 一团和气缺乏求知精神
“这方案似乎有问题，算了。”
会议碍于情面或行动懒惰放弃正常的工作沟通机会和求知过程，风险可能就此隐藏充满隐患。遇到不合理的方案、操作、流程等都可以第一时间抛出问题、质疑，上升Feature团队共同探讨解决，必要时可以组织问题复盘提高关注度，填充进团队知识库备案。
- 工作本位和 FO 角色冲突
“这都是XXX端的问题。”“然后呢？”
确认问题归属方无可厚非，问题在于作为FO自身也是某一端、更或者是Feature某模块的直接参与者，除了基于工作职责本位思考抛出问题、归因，还需要站在FO角色具备大局观，与问题、与团队伙伴共进退，FO并不是交给某一方向或者某些模块参与人员的特权，而是责任。
Q&A
-
为什么每天开日会都没事，最后才发现问题？
❌ 任务进度全靠问答式反馈，项目成员个人对自身工作任务进度的主观判断输出一定是不确定的，大部分时间都会保持“风平浪静”、个人无从感知异常的“虚假汇报”。
✅ 宣贯子阶段的目标导向和时间节点观念 。 开发阶段的目标导向是按时联调，联调阶段的目标导向是按时提测。
✅ 善用 WBS 进行任务进度管理和把控。让进度数据说话，通过数据反馈真实情况做问题发现，让每个人有具象化感知途径，校准自身工作任务是否存在问题。
-
为什么总是会出现项目延期，很少听说项目进度提前？
❌ 工作任务拆分不够细化，提到一点看到一点，无法关联出影响面的工作负荷。开发只评估编码工期，没有罗列UT时间，联调只评估正常情况，没有给卡点留适当Buffer
❌ 碍于业务迫切期盼，“逞能”、“极限”排期，资源产值跟不上，最终无法按期交付
❌ 缺乏工作、项目经验，不知道如何合理评估排期，做任务拆解，输出的排期与客观需要不符
✅ 宣贯工作任务拆解的重要性 。 协助团队成员提高对排期任务评估的重视程度，多花时间在需求梳理、任务拆分上，不要因为评估不准确把风险全部逃逸到开发、测试等环节再进行拼力追回，磨刀不误砍柴工。
✅ 利用 WBS 和甘特图工具进行把控和治理 。 同Question-1。
