persona

Git 分支管理：1.DEV 开发独立的新功能时，尽量拉出新分支（feature/name-of-feature），以便随时合入需要上线的 Develop节点2.开分支时，在 Slack 群组中通知分支的名称、目的、命运（合入 develop / 做实验不合并）、预计开发时间等对其他 DEV 和 PM 可能有帮助的信息3.谁开的分支谁负责闭环，最后合入 develop，并检查 PM 最终上线时是否打了正确的 Tag，Tag 格式待定。

PM START&DEV Review

1.SDK的更新需要用Adsdemo测试通过，需要严格意义上查看log的正确性。2.GoldenEye的更新需要用GoldenEye的Demo测试通过，需要严格意义上查看log的正确性3.有些是UI需求的，则需要拿Puzzle或Glass或Dike进行验证。

1.在不涉及机型与Android型号的需求中，可以使用一个常规手机进行逐项的功能验证。2.在涉及机型与Android的型号的需求中，需要逐个遍历一遍功能验证。3.Flurry拿一个常规手机验证正确上报事件，不多上报，不漏报，有些极限不好测的Flurry需要Dev协助。4.UI一般需要机型适配，所以需要逐个遍历一遍功能验证。

一份比较好的需求文档需要注意的细节：1.研发人员需要`开发`的部分需要单独标注出来，对于新版本需求更新需要用***红色标记新增、下划线标记删除或者修改前内容、绿色标记修改后内容***2.如果有 RemoteConfig 的控制项，需要写清楚`配置路径`和`默认值`，例如 *Application-LockScreen-DefaultEnabled 默认值为 YES*3.需求如果有学习和参照竞品的部分，需要对竞品的需求研究的清晰透彻，边界情况和特殊情况同样需要在需求文档中写清晰（例如打开数据流量开关失败需要提示、网络失败情况处理、涉及内容输入时，需要考虑各种可能的非法输入值，比如过长、空内容等），严禁文档和沟通中出现`参考某某 app` 、 `和谁谁谁做一模一样` 的言语4.新需求功能点中如果和 app 中已经有的功能相同和相似，尽可能要复用，避免对相同类似功能进行多次重复开发的发生（`此处需要多向组内其它 PM 询问以及对产品整体都有了解`）；例如 *引导、提示类需求的触发条件（安装后 X 小时 / 最多 X 次 / 距离上次展示最少 X 时间 / 在回到桌面时 / 退出 X 功能时展示等），建议规范设计和表述方式，尽量挑已有的形式中能有效果的，不要每次都重新设计* 5.需求文档的最后署名写上 PM 和 DEV 的大名，以保证后人接手时有前人可以求教（尤其是项目组之间共享需求时）

长期数据观察

Dev Research&PM Test

需求评审

在相应平台的Trello Board从需求收集开始建立好卡片，卡片的几个重要信息：1.标题要表达完整（平台、内容、PM上线时间、上线在哪个产品）2.参与人员要选正确且全3.重要程度按照需求优先级来排序

上线产品

需求处理

需求收集

libAcbAds&adapter命名规范：如果是beta : 1.4.1.beta01如果是SNAPSHOT：1.4.1-01-SNAPSHOT

PM线上数据分析

1.找Lead指派Reviewer进行代码Review，移动卡片到“代码Review”，将Reviewer添加到卡片，并更新Due Date2.Review完成。（如果review结果需要较大改动，重新移动卡片到“开发进行中”，并更新Due Date，取消所有已勾选的checkbox）

Release & Feedback

需求收集的来源：项目组、上级领导、竞品&市场、用户、自我

1. 线上App产品至少2个测试通过或者GoldenEye组内产品测试通过则发版GM，并发送GM邮件，附属上Git上的Release Note地址，

Dev Code Review

DEV Meger Code

发版GM

1.需求分析：搞明白需求的上下文2.需求分类：是Feature还是修复bug3.需求优先级：短期内第一优先级是项目组的crash，fetal bug，ANR ，OM以及新功能

PM 产品测试

1.根据需求文档的计算公式，输出客观给的数据计算结果2. 严谨分析数据结果，输出实验结果

1.如果是GoldenEye组内产品，则采用Beta正常上线，上线三天内观察数据，并输出数据结果到对应的需求文档中，如果有需要通知的，第一时间通知在相应的Slack群中2.如果是其他项目组的产品，采用beta上线，三天则需要MKT介入进行商业数据的计算，然后将正向结果输出到leader群中，不好的结果也需要发出来。

启动开发

需求文档输出

开发自测

功能开发：1.对于需求文档中有 checkbox 的做完哪里点哪里2.如果自己发现有 bug 要提出来，即使是偶然出现，不要藏着掖着3.开发过程中要多沟通，如果觉得有实现难度或者问题的要及时找 PM & Dev Leader沟通，可以修改方案和优先级等，不要自己憋着不说4.DEV 一定要看 slack，要给一个反馈，ok 回一下5.DEV 之间也多沟通，遇到问题卡住了要提出来找方法解决

1.在Dev Leader与PM Leader Review完成的前提下，开会与具体Dev进行需求讲解评审2.在1通过的情况下，在相应平台建立Trello开发卡片，并确定开发截止时间，建议将一个开发按照天来划分开发进度，PM确定上线截止时间，确定上线产品

和Leader确认是在Developer上直接开发还是开新分支，分支的命名要规范，将自己开发的分支名称填写到trello相应的卡片上

1.需求文档的基本点：背景、目的、目标、解决方案、反馈指标2.需求方案：技术方案分析--模块、类、接口、算法、存储、逻辑流程、复杂动画、机型和适配。表象描述--明确判断点的逻辑，明确边界条件情况，考虑到99%的场景3.测试方案：与Dev一起制定测试方案4.数据指标分析：明确观察指标，计算公式5.其他：多用图文结合、给出全面的log、画流程图、列计算公式、粘贴视频资料、与相关Dev、PM Leader Review

需求评审：1.需求评审经过了PM、DEV Leader评估、设计师评估2.输出物检查：设计图、动画、最终文案、逻辑图、需求文档、A/B test需求、多语言、数据观察方案、数据统计表格3.DEV 帮助 PM 细化和改进需求文档，PM 没考虑全面的提醒帮助他们补充上4.需求评审的时候要专注，有问题尽可能在会上提出并讨论，尽可能降低开发进行后发现大问题5.有实现难度的要第一时间提出来，集思广益

管理Trello卡片

需求文档输出：**如果是需求是随版本而更新迭代需要按照如下步骤来完成**1. Evernote 中拷贝上一个版本的需求文档对应的笔记（例如创建ID 1.0.0 需求说明 - 创建ID 1.1.0 需求说明）2.将新拷贝的需求文档笔记内容涂黑，然后在上面进行修改（并用颜色或者划线标记出需求的增加、删除以及变更）3.新需求要确定一个统一的`英文名称` 放在`需求文档开始部分`（方便在代码、图片、Flurry事件命名上的统一），例如 AutomaticCreateId、AutomaticModifyWorldWideFloor、BatchDisableFacebookId4.根据【需求分析PRD#缺】模板，进行完整的PRD需求分析，粘贴附件到本卡片（PRD涵盖内容：设计目标（动机、能力、触发点）；算法、流程图、文案等各种输出物）5.输出物检查：设计图、动画、最终文案、逻辑图、需求文档、A/B test需求、多语言、数据观察方案、数据统计表格

PM功能验证