团队管理规范
2021-09-26 16:45:57 53 举报AI智能生成
团队管理中涉及到的相关事务梳理
作者其他创作
大纲/内容
团队管理规范
团队文档内容规范
a.概要设计内容规范
1.需求背景
2.设计目标
3.模块设计
1.业务复杂的需提供业务流程图
2.提供初版的页面原型图
3.对原型图重点功能逻辑进行图文说明
b.详细设计内容规范
1.功能使用场景说明
2.提供业务流程图
3.提供页面原型图
4.对页面原型图进行功能操作说明
5.表结构设计
6.外部对接接口规范（包括需要第三方提供的接口清单）
准入接口规范
准入调用集控的接口
集控平台提供给调用准入的接口
内网接口规范
内网提供给平台的接口
平台提供给内网的接口
c.测试用例内容规范
黑盒测试
页面样式、输入校验用例
一个功能需求可以一条用例包含，也可以多条用例分开验证
页面控件操作验证用例
常规的增删改查操作用例
功能流程是否畅通验证用例
完成某个功能目标全过程验证用例
白盒测试
重要业务逻辑验证用例
后台关键代码段逻辑验证用例
关键逻辑的数据入库是否正确，是否存在脏数据
d.操作手册内容规范
1.功能作用、使用场景说明
2.特殊数据来源，重要的统计逻辑做简要说明
e.产品项目bug文档内容规范
f.产品项目需求文档内容规范
代码管理规范
脚本保存规范
脚本文件名日期按照需求开发的起始日期，以需求提交升级包的日期为截止日期
一旦打包后，后续再由需求，就需要重新创建爱你一个脚本更新文件，并用的开发日期为开始日期
代码分支使用规范
主干分支（DEV）
只做为测试通过之后
升级包打包规范
如何避免文件或代码遗漏升级
团队沟通规范
与现场运维人员沟通
原则
必须要将运维人员当做小白来看，沟通过程中我方作为主导来引导协助现场分析处理现场问题或需求
沟通需要注意的点
1.答复明确
1.对重要内容一定要运维人员给出最明确的答复，不能是模糊不清还需要再让人去细细理解的答案
2.问题确认以截图为证
2.对原因排查的关键问题一定要运维人员给出明确的截图为证，防止双方对需要确认的问题点理解产生歧义
3.问题分解
3.向运维人员确认问题时，一定要将问题分解成一个个的小问题进行分步确认，不能笼统的提一个模糊的问题让运维人员去理解答复，这样很容易产生理解偏差
4.信息传递有度
4.对于问题原因表述，如果是程序代码层面的问题，不需要告知运维太多，只需要告知是程序的bug，且承诺修复的时间节点即可；如果是运维操作错误导致，则需要告知其详细操作方式，并事后检查操作手册对此功能描述是否不够详细
5.问题分析、处理、配合都需要给对方明确时间节点
5.与现场运维配合分析、验证问题时，如果中途需要某一方独自分析确认，暂不需要另一方时，需要给对方一个明确的时间节点，好让对方合理安排配合协助的时间，不然双方都会将该问题处理优先级降低，有时间了就在群里回复下， 大大降低了问题处理沟通的效率。
团队成员之间沟通
对事不对人，以解决问题为目标，不能带个人情绪来沟通
与领导之间的沟通
条例清晰，目的明确
1.目的明确
沟通之前一定要先明确沟通的最终目的是什么，围绕这个目的进行表述沟通
2.先结果后过程
先阐述要表达的问题现象或事情的结果，再对此现场或结果表述具体原因
3.条例清晰
建议沟通汇报之前可以将要表述的问题或者观点列个清单，沟通时对照清单逐条说明
事务流程闭环规范
1.计划制定
事务分解
工作量评估
必须要包含完整流程的工作量
需求分析耗时
需求设计耗时
需求开发耗时
需求测试用例编写耗时
自测耗时
测试人员测试耗时
交付环节验证耗时
研发组长验收耗时
现场测试环境验证耗时
2.任务分配
目标明确
要求任务接收方明确知道要做什么，验收标准是什么，最终成果物是什么
任务执行时间明确
任务接收方明确知道任务周期多长，截止验收时间
3.任务跟踪
进度控制
及时关注任务进展，进度计划是否偏离，如果偏离，如何保证后续按计划完成，或加班赶进度，或延期交付
问题协助
进度汇报
4.任务完成验收
功能验收
代码验收
对照需求验收功能点是否遗漏
功能通过测试
功能配套文档验收
测试用例验收
操作手册更新验收
设计说明文档更新验收
职业：本科
0 条评论
回复 删除
下一页
