：所谓SOP，即标准作业程序，指将某一事件的标准操作步骤和要求以统一的格式描述出来，用于指导和规范日常的工作。实际执行过程中sop核心是符合本企业并可执行，不流于形式。
一、跨部门工作流程
跨部门流程及职能如下图展示。
二、运营
- 日常提交需求
运营及业务同学，按照下方模板填写后，提交给产品经理。
2. 活动需求
根据活动大小，至少提前15-30天，提交活动方案给产品经理。活动方案模板暂时未整理，后续专门开一篇文章讲活动。
三、产品
产品经理的日常工作流程。
1. 需求池
每日需更新产品的需求池，做出对应的状态变更。可根据下方模板汇总。
2. 需求评审
需求评审会召开前，发正式邮件通知相关干系人。邮件模板如下：
Dear all，
本人近期完成了对某某某功能的调研，并在此基础上完成了某某某v3.0的版本设计，现邀请诸位举行会议对此次需求进行评审，具体安排如下：
会议时间：2018年9月1日 上午10:00
会议形式：线下会议
会议目的：某某某v3.0需求评审
参会人员：
1）iOS-小张、android-小陈、研发……
2）测试小红、产品小黄、设计小亮……
以下是本次会议的会议概要，请大家查阅：
××××××××××××
tips：请大家提前阅读需求说明。准时参会。
可能出现的问题（讨论要点）如下：
××××××××××××
以上
祝生活愉快！
需求评审的流程如下：
3. 原型及需求管理
需求以需求原型及标注的形式呈现，需求原型上传至蓝湖，具体的需求点，同步更新于禅道。
4. 数据埋点模板
小程序：
其他系统：
四、UI
1. 设计图及标注
UI设计图上传至蓝湖，并提供对应的切图。
2. 统一设计规范
例如，后台管理系统。
五、开发
1. git代码规范（截取片段，详见代码规范文档）
2. git工作流程规范（截取片段，详见具体文档）
3. 版本号命名规范
以 YinLiFang_1.0.0.170517_beta.apk 为例：
主版本号（1）：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。
子版本号（0）：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。
阶段版本号（0）：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。
日期版本号（170517）：用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。
希腊字母版本号（beta）:此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。
希腊字母所代表的版本阶段介绍：
Alpha版：也叫α版，此版本主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。
Beta版：此版本相对于α版已经有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
RC版：此版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几，测试人员基本通过的版本。
Release版：此版本意味着“最终版本”、“上线版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号®。
六、测试
1. 提测
开发完毕，以较为正式的形式提交给测试人员，模板如下：
测试版本的版本号：V1.0.0-beta
版本名称：20190102发布内容
提测时间：2020-01-16
版本内容：
××××××××××××
测试环境地址：
××××××××××××
测试登录账号及密码：
××××××××××××
其他注意内容：
如果验收测试过程中发现严重bug，则退回版本，修复完毕重新提测。
2. 测试用例
模板如下：
测试要点：
UI测试：
- 确保手头的原型图与效果图为当前最新版本。
- 确保产品UI符合产品经理制定的原型图与效果图。
- 一切界面问题以效果图为准，若有用户体验方面的建议，必须先以邮件或口头的形式询问产品经理。
- 由于测试环境中的数据为模拟数据，测试时必须预先考虑到正式环境中可能出现的数据类型。
功能测试：
- 确保手头的功能需求文档为当前最新版本。
- 确保所有的软件功能都已实现且逻辑正常。
- 一切功能问题以需求文档为准，若有用户体验方面的建议，必须先以邮件或口头的形式询问产品经理。个人建议，用户体验方面的建议，优先级放在修复bug之后。
- 若有些功能在技术上难以实现或者由于排期的原因无法在短时间内实现，必须得到产品经理的确认，而不是单单只听开发人员的技术解释。此处确认最好以邮件形式存在。
- 所有的“外部原因”问题，都需要尽早地督促开发人员与客户服务端人员联系协调解决。并在之后的测试报告中予以体现。
- 所有的“设计如此”、“延期处理”问题，都需要和产品经理确认后再进行验证。并在之后的测试报告中予以体现。
- 测试下单时，注册的测试账号必须符合公司规范；收货地址必须包含“测试”关键字，最好每次下单的名称中含有日期，以便查询；在正式环境中下单后必须取消该订单等。
兼容测试/性能测试：
- 确保软件在所有兼容机型上都能正常使用（ios一般需要兼容到6, ios5可以不用考虑，用户使用率已经低于5%以下）
- 性能测试方面必须满足硬件压力条件下的测试需要（例如多线程，用户常用的app都要后台运行的环境中测试。）
- 网络响应用户体验方面的性能测试，需要保证在wifi、3g、2g网络下的切换效果。比如wifi切换到2g，网络响应的速度以及切换界面。
3.测试日报
测试人员每天需对所测项目发送测试日报。测试日报所包含的内容为：
- 对当前测试版本质量进行分级
- 对较严重的问题进行例举，提示开发人员优先修改
- 对版本的整体情况进行评估
- 对版本测试过程中修改的内容进行记录
4. 上线报告
产品上线前，测试人员发送产品上线报告。上线报告所包含的内容为：
- 对当前版本质量进行分级
- 附上测试报告（功能测试报告、兼容性测试报告、性能测试报告等）
- 总结上线版本的基本情况。若有遗留问题必须列出并记录解决方案
5. bug提交管理规范
模板如下：
【所属功能】bug出现的功能模块，比如个人中心。
【主题】一句话描述问题产生的模块、现象、错误现象及正确结果。比如个人中心上传头像照片不成功。
【复现率】bug重现的概率，可以用百分比形容，也可以用always、sometimes。
【平台】Android、iOS、H5、Web、PC
【问题类型】界面/功能/性能/兼容/安全/体验
【严重级别】可以用P0、P1、P2形容，也可以用高、中、低或者是严重、普通、低级。
【复现环境】DEV、TEST、LIVE
【测试机型】iPhone 6、Google Pixel
【系统版本】9.1.1
【测试版本】给出发现bug的版本号、构建号、tag即可
【研发分工】前端、后端
【前提条件】
【复现步骤】
- XXX
- XXXXX
【预期结果】预期的正确结果
【实际现象】实际看到的错误的现象
【其他补充】可以提供附件文档、日志、截图等一切可以协助开发分析问题的信息。
七、发布
1. v1.0上线通知
上线邮件模板如下：
各位领导，各位同仁：
“某某”项目在全体同仁的共同努力下，于 X 年 X 月 X 日正式上线了！项目自 X 年 X 月 X 日立项，历经 XX 天的艰苦奋战，项目组克服了 XX 和 XXX 等困难，各部门都按时完成任务，整个项目才得以顺利上线。感谢大家的辛苦付出，向项目组每一位成员致谢！
本次项目上线的平台包括：
- iOS（版本号：V1.0.0 可在 App Store 搜索“XX”，大概排名第 N 位）
- Android（版本号：V1.0.0 可在应用宝、XX 软件商店，搜索“XX”大概排名第 N 位）
- 下载二维码如图：【这里假装有一个二维码】
本次版本主要包含如下功能：
- XXXX 功能，解决了 XX 问题
- XXXX 功能，满足了 XX 需求
欢迎大家下载体验，在体验的过程中遇到什么问题、有什么意见和建议，欢迎及时反馈给产品经理（邮箱 XXX）
“某某”项目承载着公司在追逐 XX 市场的期许，未来，我们将在 XX 领域劈荆斩刺，为公司创造无限可能！这里面需要我们付出更多的艰辛。上线只是起点，而非终点，我们也已经与各个小组制定好接下来要开展的工作，这将让我们的产品进入市场，与竞品真刀真枪地一分高下！
接下来我们要开展的主要工作：
- 做好产品优化工作，XXXX
- 做好产品推广工作，XXXX
- 做好产品运营工作，XXXX
请各小组同学再接再厉，继续为“某某”项目 XXXXXX。
谢谢！
2. 版本发布通知
通知模板如下：
版本号：v1.1.2
版本内容：XXXX
发版日期：2020-01-16
代码更新时间：具体时间段（如影响正常使用，要前提告知。）
八、其他
1. 会议模板
会议记录：
会议纪要：
2. 周报、日报模板
日报：
今日工作内容：内容+工时
明日工作计划
问题及其他内容
周报：
本周工作进展
下周工作安排
问题及解决办法
总结：希望大家能从中受益，制定符合自己团队的sop，形成一个高效密切且具有战斗力的团队。
