电商的项目往往具有狼性的特性，而在刀尖上舔血的项目经理们需要错综复杂的实践中快速沉淀一些约定、制度，给团队带来一些积极的能量。
在考拉移动端项目中，我们吃一堑长一智，通过不断地打磨， 团队逐步形成了一些约定，带来了一些积极的改变。有些约定已经形成制度或模板，而有些还只是口头约定，口口相传。为避免这些宝贵财富湮没，巩固积极改变的效果，也方便所有同事知悉了解，特此汇总考拉移动端项目中的一些约定 （实际工作中 还有 许多常规性基础的约定规范就不一一列入了，如：缺陷大扫除 、冒烟测试 、接口测试等）。
原则定期反思并调整，倾向于小步快跑，产品开发测试及项目经理合作共赢，简单真诚。
价值观注重当面沟通，就事论事解决问题，正向积极应对。
1. 大小需求评审
小评审，尽可能点对点沟通，相关的三五人协商约定评审日期及形式。大评审，最终需求确认会，意义在于将全局信息传递到全体项目组成员。大评审确认会后，需求评审窗口期关闭进入需求冻结。
需求评审窗口期。经评审委员会确认，以每个版本的缺陷大扫除完成日为下一版本需求评审窗口期开放日。特殊情况需当下版本立即解决响应的属需求变更，请先向移动端评审委员会发起申请确认，确认 ok 后方可发起需求评审。
2. 交互稿更新周知并注明更新记录
相关人当面约谈并邮件周知所有移动端项目组成员。
文档首页标注更新记录。
3. 需求冻结制度
需求大评审确认会后进入需求冻结。待缺陷大扫除完成后进入需求评审窗口期，结束需求冻结。
为了更快速完成交付，在一个迭代期内需求不可能无休无止的改来改去。需要适当冻结以满足快速交付的要求，为下次迭代中快速响应新变化留有余地。
需求冻结指的是影响到迭代交付等的需求冻结，并不是拒绝拥抱变化，具体需要团队自身去评判。例如无节制无节操的需求蔓延需求变更则需禁止，再例如，迭代进行中因外界突发情况特别是法律法规等政策因素导致需求变更，则可团队自身评估，尽量去拥抱这个变化降低风险。
4. 紧急任务申请规范
移动端评审委员会一票否决制。
紧急任务申请规范。邮件标题：【移动端紧急任务申请】【 ios+android 】任务标题。注明申请人、申请原因、 jira 地址、希望上线时间、需求来源等。
邮件回复格式，包含以下内容但不局限于以下内容。开发评估结论邮件，开发用时、开发影响范围、风险、开发结论。测试评估结论邮件，测试时间、测试范围、测试风险、测试结论。
5. 技术负责人制度
针对大块功能点或重点需求，及其他任何需要特殊关切的原因，由自主申请或团队协商任命一名同事担任该功能点或需求的技术负责人。可以是开发也可以是测试。在项目排期会中明确公示。
负责接收产品同事信息更新，并向所辖团队各端（ ios 、安卓、后台、前端）同步信息并按需收集反馈，告知产品同事。如涉及需求变更则需监督相关责任发出变更申请。
技术负责人有权力询问进展，协调所辖团队进度安排，团队成员需尽力配合。
技术负责人有义务周知风险，透明进展情况。
技术负责人福利， 可按需申请项目管理初步知识培训等 。
6. 项目时间轴
需包含关键评审时间点、 视觉提供时间点、 外部依赖任务时间约定、提测时间点、上线时间、灰度时间、冻结时间、渠道包提供时间等。
7. 延期需当面沟通并发邮件周知
如已预计某项任务会晚于约定时间提测，需当面沟通，并发送延期说明邮件周知所有移动端项目组成员。
延期邮件发送责任人。需求变更、插单等，由产品同事邮件周知；开发时间评估有误实际延迟的，由开发同事邮件周知；测试时间评估有误实际延迟的，由测试同事邮件周知。
8. 项目变更需申请，通过后邮件周知
变更需向评审委员会发起邮件申请。评审委员会审核通过方可开工并邮件周知所有移动端项目组成员，严禁越过评审委员会接私活。
如造成其他任务延误，也需走延期处理。
9. 代码冻结制度
一般服务器上线日 为客户端代码冻结开始日。
冻结代码，代码另起分支准备发版之用，但并不是完全就停止代码更新。允许谨慎可控的缺陷修复等。
需特别强调的一点是，代码冻结期，原则上讲是禁止新增任何需求或者任何调整功能点的开发任务的。
10. 提前十天再次知会市场部各渠道安装包提供时间
11. 项目回顾会，分组站会及移动端组长以上各方站会
借用《南赣乡约》里的话，与君共勉。勿忘相约！
“ 患难相恤，善相劝勉，恶相告戒，息讼罢争，讲信修睦，务为良善之民，共成仁厚之俗 。呜呼！人虽至愚，责人则明；虽有聪明，责己则昏。尔等父老子弟毋念新民之旧恶而不与其善，彼一念而善，即善人矣；毋自恃为良民而不修其身，尔一念而恶，即恶人矣；人之善恶，由于一念之间。 ”
—— 《南赣乡约》
