需求整理汇总（待磨合）

[Fatman13]

背景

理顺当前Venus团队吸收各种需求，并把需求结合到开发计划中的流程。

流程

• 在dev-guidance中，现有的产品需求流程。

[Fatman13]

Sprint 47 Requirement Grooming

近期已转化需求

• [venus-wallet] 远程wallet兼容lotus节点的需求 #5186
• [依赖] libp2p依赖升级？ #5221
• [venus] StateActorManifestCID API? #5222
• [venus-market] 借鉴boost统计算力方式？ #5108
• （Cluster）https://github.com/ipfs-force-community/venus-cluster/issues?q=is%3Aissue+is%3Aclosed+author%3Afatman13

待triage（社区，产品，生态需求）

• C-triage Category: Need triage
• （Cluster）https://github.com/ipfs-force-community/venus-cluster/issues/created_by/fatman13

TODO List（研发需求）

• https://github.com/orgs/filecoin-project/projects/51/views/8
• （Cluster）https://github.com/orgs/ipfs-force-community/projects/5/views/1

问题

• 是否需要恒定的一个需求对齐会议？(requirement grooming)
• venus和cluster两边是否需要统一？
• 之前一个案例；社区成员跳过对场景描述，直接PR；
• 类似 [venus-wallet] 远程wallet兼容lotus节点的需求 #5186 的大需求是否需要向上对齐？

[diwufeiwen]

#5168 转成了需求是说后续需要当做需求去花时间研究，并非一定能或者需要按照需求所述去实现。这个向上对齐？是向哪里？如果与其他组有影响就对齐没有就不对齐，我认为按这个原则处理

[Dio7777777]

根据整个需求工作流的一些系统思考，可详细讨论：

1. 需求创建
   需求池最好是统一一处进行管理，方便项目后续的需求规划、需求进度跟进、统一的需求管理。
   建议1:建议使用tb创建需求池进行全量需求管理
2. 需求规划
   迭代需求规划应遵循需求的优先级排序，优先完成高优先级需求。因此需要在planning前对所有需求进行排序，一般来说是负责把控产品的产品经理对需求的优先级进行判断，但venus需求源头众多，因此可类比将所有需求方代表当作产品经理。那么需求池中需求的优先级的判定即通过所有需求方代表共识确定——即下个迭代做哪些优先级高的需求。
   建议2:grooming会议所有需求方都统一参与共同评判所有需求的优先级、确定下迭代做哪些需求。
3. 需求进度跟进
   早会使用的看板未覆盖全部需求且早会参与方并非全员，因此对于内部需求的跟进还有所缺失。
   建议3:要么更改早会模式，早会将所有需求进度进行同步清晰；要么内部需求单独采用其他形式如每日跟对应需求方进行私下进度同步
4. 需求验收
   需求完成的定义一般是通过研发、测试、最终产品验收完代表需求的完成。
   建议4:需求的完成应对应需求方对需求进行验收

[diwufeiwen]

来自社区的探索性需求不一定非要套具有明确结果性导向的产品需求管理，本身它也很难套的进去

[Dio7777777]

我觉得“探索性需求”这个两个词汇本身就是有一定冲突的。需求应该指的是有比较明确的完成路径、完成后具备可预测的结果的工作（DoD）；探索性指的是应该需要调研，不清楚具体方向、结果的工作，更应该是需求的一个前置的探索工作。
所以探索、调研更像是一个task，完成前期准备之后产出可行性方案。规划、开展、完成这个可行性方案产出具体结果的过程是需求的工作流，届时就完全可以用到需求的整个工作流管理里面。

[Fatman13]

另外一个可以考虑的是，以后venus条线产品的区分。现在以链服务，订单服务，算力服务，3大块区分。3大块工作量都比较大，但是没有做太多的品牌区分，导致grant申请时，审核人对产品不理解。反观Lotus全新的订单服务，品牌升级为boost，有自己logo和项目管理，自己的slack社区频道，团队和运营和lotus进行了剥离。如果venus也能3大服务做一个区分，对社区和对自身日后的产品发展应该都会有比较好的帮助。