淘粉吧产品开发流程说明文档（beta)

需求管理 wiki

文档更新日志

1. 前言

本文档目的为规范淘粉吧产品开发流程，避免在各环节出现信息不对称导致需求上线后出现问题。并对各环节进行责任划分，更好的保证需求为有人跟进的状态

2. 需求产生（to需求方）

2.1 需求解释及定义：

• 需求方定义：对淘粉吧产品提出功能上的改进或增加新功能的个体或群体。
• 需求方包括但不限于：运营，市场，客服，产品经理，UED，技术，BI，合作伙伴（玛瑙湾，海狐）
• 本流程适用范围：包含所有使用淘粉吧产品，技术资源的所有需求

2.2 需求方定义

2.3 需求产出流程

2.3.1 需求立项

立项入口：

在淘粉吧teambition「淘粉吧需求提交」中提交对应需求。首次访问请联系任意产品经理开通tb

立项素材准备：

• 在待添加中添加对应的需求名称，起到可快速识别需求目的的作用
• 将具体的需求描述填写在备注中，如有附件请直接上传附件
• 将执行人选择为 @曾争
• 调整任务的优先级红色为紧急，橙色为较紧急
• 如有具体需求期望完成时间时添加截止时间
• 24小时内需求将分配给对应的产品并了解需求
• 通过立项的需求将进入「淘粉吧产品需求管理」中，可随时跟进需求对应的状态

立项原则（重要）：

• 立项流程主要目的为合理判断需求，将产品开发资源投入到同期更有价值的需求当中
• 每个需求必须有对应的产品经理跟进
• 需求方主要提供需要达到的目的，对于当前需求提交可达到的需求预期
• 需求越详细则通过率越高
• 每个需求立项必须由钉钉title为高级专家及以上人员进行拍板立项
• 紧急需求可直接跳过所有环节直接进入开发阶段，但必须由@曾争 进行确认
• 后台不涉及用户端界面调整可直接进行立项
  
  • 后台需求小于等于0.5个人天可直接安排技术开发

立项Q&A

1. 我有个想法但是还没有完善的需求是否可以提前和产品经理沟通？
   可以，可直接找对应业务负责的产品经理进行沟通。当无法判断对应产品经理时请直接找@曾争沟通

2. 我只是做一个小小的一行代码的修改，是否可以直接找技术来改掉？
   不行，无数次案例证明「小小的一行代码」的未考虑周全的修改会造成后续大量的维护成本。需在产品经理知情下，由产品经理及叶航判断是否可行。由于需求造成的bug和资损由对应跟进的产品经理承担。

3. 我的需求很紧急，但是为何不给我走紧急流程？
   每次需求的插入意味着其他需求将被延期，在未判断为一定需要打乱当前排期的情况下，不予进行需求插入。 紧急需求的判断人为@曾争。

4. 我的需求被否决了，但是我认为这不合理，我的需求很好，我该如何做？
   为避免因为产品个人判断导致的需求把控不准确。需求被否决后可向否决需求的产品更高级产品或管理人员提出复议。
   例：曾争否决 —— 万力复议 。 陈宣如否决 —— 曾争复议

5. 为什么要有这么复杂的流程来做产品开发？
   主要出于
   a.需求支撑部门资源的合理使用
   b. 对于各个需求的留档复查，便于手续问题定位 c.多数需求与线上逻辑具备耦合性，需要全方位的考虑，避免出现功能逻辑设计错误造成资损

2.3.2 需求处理流程

详细说明

• 需求立项完成后会在「淘粉吧产品需求管理」中生成该需求，根据需求方将可收到对应需求变更（需求状态）的提醒
• 当需求涉及视觉设计时，需求方需要进行视觉验收。视觉验收完成的后续阶段将不再对需求视觉进行改动
• 需求发布前大多数情况需求方可在测试环境针对需求进行验收，验收通过后进行发布上线
• 需求开发过程中对需求发生了变更或增加了额外需求，由对应产品经理判断是否进行变更。如变更成功则可能造成需求交付时间的同步变化
• 需求进入开发阶段即可获知明确的需求上线时间
• teambition使用教程请见 点击

原则

• 需求进行沟通或变更时需要产品经理，开发人员，测试人员均知道变更内容
• 不提倡不经过产品经理直接找开发人员变更需求，如出现上述情况后续出现的delay以及上线造成的bug资损由需求方承担
• 需求进入开发过程不提倡进行需求变更，需求变更导致的delay将不可避免

Q&A

1. 什么是需求变更？
   例1：我想要在淘粉吧首页的banner区可以无限挂banner，后经讨论发现还是设置一个最多可上banner数量。
   例2：首页商品流我希望通过系统的方式来进行排序，后经推敲发现需要可以手动干预这个排序。

2. 需求变更会造成什么？
   轻则导致需求的开发周期发生变更，重则由于未做详细的需求讨论导致变更的需求未经过严禁的评估从而产生bug

3. 视觉和需求验收需求方能做些什么？
   视觉验收：这个视觉稿做出来的是否符合我对这个需求的预期，如不符合与产品视觉沟通出自己实际的预期效果
   需求验收：开发交付的功能是否可用，是否和视觉稿以及产品经理描述的功能一致。如不一致可推进进行修改调整

4. 需求验收通过了但是我想调整一点点内容，算不算需求变更？
   算， 以产品进行需求宣讲为节点，需求进入技术开发排期后进行任何变更都属于需求变更

5. 我不清楚新上的功能后台怎么用，希望产品能出一个说明文档算需求变更吗？
   不算，需求变更指的是针对需求在开发过程中的逻辑，交互的变化。而功能使用文档为对于当前逻辑及功能的说明。在功能复杂或操作事项较多时产品有义务提供该文档给需求方。

6. 我有个紧急需求被采纳了，会有什么变化？
   开发工作量是恒定的（不考虑人员增加减小的情况），每次需求的正常排期，技术会根据当前工作量将需求排满，当插入紧急需求时，相当于有人需要停下手头的工作开始处理紧急需求。会导致原本计划的发布时间延后。由于紧急需求从需求评审到最后的上线都追求的快，在某些方面可能考虑并不周全，所以在正常情况下并不建议走紧急发布流程

7. 做一个需求，走正常流程大概多久可以发布？
   常规需求：每周五，产品和技术会进行需求宣讲，技术和产品会根据当前需求的优先级进行排期，如提交的需求在周五前完成了PRD的相关内容且为较重要需求，则在周五即可排期。正常技术发布周期为每周四，根据实际需求工作量来判断具体哪个周四完成，最快为次周的周四发布
   紧急需求：无排期时间，确认为紧急需求后立刻开始进行需求开发流程，在最短时间内进行发布。

8. 什么叫PRD完成？
   PRD（产品需求文档）指的是需求的所有逻辑被梳理完毕并产出文档，当有视觉稿的需求时，完成视觉评审并更新到PRD中算PRD完成。技术开发参考唯一依据为PRD，PRD为需求说明的核心所在

2.3.3 需求验收流程

需求方端

• 验收一般是在测试环境下，模拟线上的效果进行测试体验。需求方应根据功能的流程来测试是否与产品描述的PRD内容一致，当不一致时可提出修改。

• 当体验过程中出现bug时，应及时反馈给产品进行跟进解决。

• 测试内容为：需求正常流程是否能走通， 需求异常流程是否考虑周全且符合预期

产品端

• 针对功能逻辑的正常及异常流程进行回归测试
• 当需求为客户端需求时需对客户端整体功能进行回归测试
• 未进行验收上线的需求，出现任何bug由对应产品承担损失
• 对应产品功能因产品逻辑问题导致出现bug，由产品端发布事故报告说明

Q&A

1. 验收流程的作用是什么？
   情况1：由于技术通过产品交付的PRD进行开发，可能会存在需求方-产品-技术3方消息不对称的场景。会导致最终交付的需求与原本预期的需求不一致在验收过程中将此问题杜绝。情况2：程序开发过程中不可避免存在bug，在功能上线前将bug都修复再进行发布从而不会影响到正常用户使用产品。

2. 如果我完全相信产品不做需求验收可以吗？
   可以，按照产品验收的功能进行上线，该功能如需进行非bug类的微调需进行下次排期来解决

3. 每次都是什么时候对功能进行验收？
   常规需求为每周四晚发布，紧急需求根据实际开发周期发布。具体时间在发布前可通过teambition及产品告知。需提前预留时间对跟进需求进行验收操作。当需求为后台逻辑类需求，不易于需求方进行验收时，由产品和技术进行需求验收即可。

4. 需求验收完成上线了，我想修改怎么办？有bug怎么办？
   需求验收完成并上线后代表本期需求已完结，如需修改请继续进行需求排期流程进行排期。需求在验收过程中需求方完成验收流程则代表对本期上线功能无异议，需求不再会进行变更。当需求上线后出现bug：逻辑设计类bug由产品承担全部责任；功能出现无法使用的bug，由于通过了产品验收则有产品承担大部分责任。

2.3.4 需求优先级定义

淘粉吧优先级定义

淘粉吧优先级判断标准

Q&A

1. 优先级如何判断出来的？
   优先级由当前所有待排期需求进行综合考量，根据判断标准以及需求响应时间，当前的资源情况，由负责产品及leader共同商讨完成评定。也就是同样的需求在不同的时期优先级可能会存在差异。

2. 我什么时候知道优先级情况？
   P0需求，在立项过程中即完成需求优先级定义。其他需求在每周四产品排期会上进行定义并同步调整TB中优先级状态。红色：P1或P0需求；黄色：P2需求 ；无色为P3需求

3. 同样优先级的需求为何有些排进去做了有些却被顺延？
   技术会根据优先级对需求进行评估，相同优先级的需求会根据技术内部对于需求的复杂程度，需求价值等因素综合考虑。本期进入待排期却未排上的需求在下期需求排期时会有部分优先级加权。

4. 我对于产品定义的需求优先级不满意是否可协商？
   可以，在每周四优先级状态变更至周五下班前均可找需求跟进的对应产品进行协商，在双方无法达成一致时可向上一层进行推进。

5. 我怎么知道我的优先级变化情况？
   需求立项后，产品会将需求方加入到TB中的参与人中，当任务发生任何变化时，参与人均可收到实时的变更消息。请打开TB的桌面提示功能，更快接受消息。

3. 产品需求规范（to PM&RD）

3.1 需求规范具体内容简介

• 明确需求产出各环节流程及责任
• 明确需求各流程价值
• 明确各流程正常及异常状态处理方案

3.2 需求流程详细说明

3.2.1 时间节点

3.2.2 各环节流程

3.2.2.1 流程

产品需求流转流程图

流程图（常规流程）

流程图（紧急流程）

产品需求变更图

BUG处理流程

3.2.2.2 流程解释

常规流程
指正常产品开发迭代的情况下进行的流程，流程中各环节需按照流程进行。
紧急流程
突发情况下的需求流程，该流程绕开了所有需要进行评审的环节直接进入到开发阶段，旨在更快速的完成需求。本类需求由于速度要求高，需经验丰富的产品进行判断及背书。
产品流程
产品经理完成需求过程的流程，目的为更好的保证每个需求的质量，从而更好的利用技术资源。

3.2.3 流程注意事项

• 所有需求必须有对应的产品
• 非紧急需求一定需要进行需求评审后才可进入排期
• 有需求方参与的需求，视觉环节验收环节需要参与
• PRD完成状态为：逻辑图（如逻辑超过2步以上），原型图（如界面交互程度超过普通页面跳转），需求描述，需求背景
• 需求变更需先于对应技术及PM（项目经理）沟通，达成一致后同步修改PRD，当PRD未修改该部分逻辑出现错误时，技术无需承担任何责任
• 需求变更需要通过排期后指定的PM（项目经理）确认

3.2.3.1 Q&A

1. 为何要设计流程？
   规范需求全阶段的处理方案，产出更有质量的功能，保证整体各环节资源的效率。

2. 流程这么多效率不就下降了？
   效率来自于各环节的配合，有迹可循降低了各环节的沟通成本，在流程正常进行的情况下不会对需求的交付时间产生较大影响。且流程设计的目的为提高需求质量，保证每个需求的产出在价值上大于过去野蛮生长的开发方式

3. 部分流程建议修改或补充我可以提出吗？
   流程的目的是提升效率，增大产出。有更好的方案及分支时，随时欢迎修改本流程

3.2.4 产品各环节职能

4. UED需求（to UED)

4.1 需求规范具体内容简介

• 明确需求产出各环节流程
• 明确UED内部流转流程
• 明确各流程正常及异常状态处理方案

4.2 需求流程详细说明

4.2.1 各环节须知

4.2.2 流程解释

常规流程
指正常产品开发迭代的情况下进行的流程，流程中各环节需按照流程进行。
紧急流程
突发情况下的需求流程，该流程绕开了所有需要进行评审的环节直接进入到开发阶段，旨在更快速的完成需求。本类需求由于速度要求高，需经验丰富的产品进行判断及背书。根据情况快速成立项目组完成该需求。
日常流程
日常图片内容更换修改，无需进行立项

4.2.3 流程注意事项

• 产品设计类视觉需求前置条件：必须在tb中立项才可进行
• 复杂需求需要进行多团队统一的视觉评审，是否需要评审由产品决定
• 有需求方参与的需求，视觉验收环节需要参与
• 产品有义务将需求描述详细给视觉
• 需要前端资源的需求，在视觉完成后交付给前端，视觉及产品共同与前端进行需求描述
• 开发过程中视觉进行变更时，如果涉及工作量大，则需delay当前已经在设计中的需求

4.2.4 Q&A

1. 和之前工作流程有什么变化呢？
   a. 需求需先立项再提交视觉设计
   b. 复杂需求强制要求提供原型
   c. 视觉需求需要给出具体交付时间
   d. 复杂需求需要进行多方视觉评审
   e. 设计完成后续视觉和产品共同与前端做需求宣讲

2. 这些流程有什么好处呢？
   杜绝无用功。明确流程环节，避免重复劳动。需求流转透明化，便于后续管理。

3. 产品让我修改一张banner，是否也需要立项呢？
   常规的图片资源位设计为日常需求，无需进行立项，但也需要在tb中创建任务走正常排期完成。

4. 我觉得现在有些线上的页面需要修改，我该怎么推动呢？
   修改线上的内容视为需求，请根据需求方流程进行需求提交。无论需求大小需要有产品参与其中

5. 当我遇到意见和需求方产品意见不统一时该如何处理？
   扩大沟通范围，直到大家意见统一

6. 什么时候算视觉需求完成呢？
   当无视觉评审时通过验收后则需求完成。 当有视觉评审时通过评审后需求完成。

5. 流程补充

• 个人微信号为非涉及淘粉吧站内体验项目，需求无需走产品流程，但需要按照正常视觉流程进行设计
• 部分独立项目，在经过@曾争 审批后，项目相关需求可不走常规开发流程
• 本流程由@曾争负责撰写，@产品部负责进行维护，流程需按照本流程文档进行执行