团队通用工作流程SOP方案.docx
《团队通用工作流程SOP方案.docx》由会员分享，可在线阅读，更多相关《团队通用工作流程SOP方案.docx（20页珍藏版）》请在冰豆网上搜索。
团队通用工作流程SOP方案
团队通用工作流程SOP方案
一、跨部门工作流程
跨部门流程及职能如下图展示。
二、运营
1.日常提交需求
运营及业务同窗，按照下方模板填写后，提交给产品经理。
2.活动需求
根据活动大小，至少提早15-30天，提交活动方案给产品经理。
活动方案模板暂时未整理，后续特地开一篇文章讲活动。
三、产品
产品经理的日常工作流程。
1.需求池
每日需更新产品的需求池，做出对应的状态变卦。
可根据下方模板汇总。
2.需求评审
需求评审会召开前，发正式邮件通知相关干系人。
邮件模板如下：
Dearall，
本人近期完成了对某某某功用的调研，并在此基础上完成了某某某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不会以单词方式呈如今软件封面上，取而代之的是符号（R）。
六、测试
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
【测试机型】iPhone6、GooglePixel
【系统版本】9.1.1
【测试版本】给动身现bug的版本号、构建号、tag即可
【研发分工】前端、后端
【前提条件】
【复现步骤】
1.XXX
2.XXXXX
【预期结果】预期的正确结果
【理论现象】理论看到的错误的现象
【其他补充】可以提供附件文档、日志、截图等一切可以辅佐开发分析问题的信息。
七、发布
1.v1.0上线通知
上线邮件模板如下：
各位指导，各位同仁：
“某某”项目在全体同仁的共同努力下，于X年X月X日正式上线了！
项目自X年X月X日立项，历经XX天的艰苦奋战，项目组抑制了XX和XXX等困难，各部门都按时完成任务，整个项目才得以顺利上线。
感谢大家的辛劳付出，向项目组每一位成员致谢！
本次项目上线的平台包括：
∙iOS（版本号：
V1.0.0可在AppStore搜索“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，构成一个高效密切且具有战役力的团队。
升级会员 