App移动端项目管理

前言

刚刚做完一个项目，值得总结，在此记录一下。

版权归作者所有，如有转发，请注明文章出处：https://xiaodanchen.github.io/archives/ 。 欢迎加入学习小组QQ群: 193765960。

项目流程

一款应用的开发大体流程如下：
1、项目立项：产品经理
2、需求确认：产品经理(业务逻辑说明文档)
3、业务确认：产品经理，技术经理，架构师
4、业务架构：技术经理，架构师（业务流程文档）
5、UI确认：产品经理，设计人员，开发人员全体
6、UI交互确认：产品经理，移动端，前段开发人员
7、接口确认：架构师，接口开发人员，移动端、前端开发人员
8.1、UI工时评估：产品经理，设计人员
8.2、接口工时评估：架构师，接口开发人员
8.3、移动端、前端工时评估：相关开发人员，技术经理
9、工时确认：产品经理，技术经理，设计人员
10、项目开发
11、测试用例及流程设计：产品经理、测试组
12、测试用例及流程确认：产品经理、开发人员，测试组
13、测试及debug：产品经理，测试组，开发
14、产品定版，release

项目管理

文档管理：

1、需求文档：需求列表，业务说明文档 by svn
2、UI交互文档：交互稿（交互细节）by svn
3、技术文档：业务逻辑的技术实现流程（技术流程文档：异常处理）by Confluence管理
4、接口文档：数据格式（统一大小写，编码格式，浮点型精度，使用long类型表示浮点数据），通讯协议，数据结构 。by Confluence管理
5、设计文档：效果图，切图，标注图（https://app.zeplin.io线上管理）
6、代码：代码更新和共同维护 。by svn or git
7、上线资料 by svn
8、测试用例 by svn

流程管理：

1、需求变更：原则上可以中前期增加需求；原则上不允许频繁变更需求；原则上不允许修改业务逻辑。需求变更必须经过产品经理、技术经理共同确认后才可变更。
2、业务逻辑变更：原则上不允许更改业务逻辑。
3、技术逻辑变更：架构师，接口开发人员，移动端开发人员共同确认
4、测试流程变更：产品经理确认

开发管理：

1、开发人员：明确需求和业务、交互逻辑。开发以需求和业务逻辑为准。
2、发现业务缺陷：需与产品经理，技术经理汇报。如要变更业务逻辑：必须重新评估开发工时和工期。
3、如没有明确要求，UI在细节和使用习惯上，请尽量遵守各自系统的设计规范。
4、协同开发：需分工明确，工作量尽量均衡。分工应报与技术经理知晓。
5、变更需求，开发人员需向技术经理确认。
6、当前的bug,当日尽量解决。
7、优化性、新需求性bug：请分发产品经理。
8、优化性、新需求性修改：请知会其他平台开发人员。
9、周报：本周开发内容；本周技术点总结；自评开发中最好的地方；遇到的问题；下周计划。
10、开发后台数据模拟：http://rap.taobao.org/account/doLogout.do

测试：mantis bug tracker管理bug or Jira管理；jekins打包

1、新需求性bug：提交产品经理，产品经理作为新需求提出，不分发bug。
2、优化型bug：提交产品经理，产品经理作为新需求提出，不分发bug。
3、开发bug：提交开发人员。

注：
1、明确bug等级，非业务性bug、非严重缺陷bug、非崩溃性bug谨慎提交为严重缺陷等级。
2、重点把握测试流程，明确测试方向：前期重点为功能性测试，业务逻辑测试。中后期加入交互性测试。
3、谨慎使用边开发边测试的开发测试流程：这种模式下，请明确测试重点（开发完毕前侧重功能性、业务性测试）
4、开发没有结束前的测试：测试人员禁止频繁交涉开发人员，所有bug只需提交服务器。
5、测试人员发起的需求性、优化性bug，请提交产品经理，产品经理请严格遵守需求变更流程。

上线：

1、测试发布测试完结，产品达到上线要求报告。
2、技术经理发布上线申请。
3、产品经理确认可以上线，发布上线请求。
4、上线人员release应用到各个渠道，上线后邮件知会相关人员产品上线情况。

项目总结：

1、产品经理：新需求追加列表，优化性需求追加列表。
2、设计人员：改版明细
3、开发人员：改版明细，开发模块，代码量及技术点总结报告。
4、测试报告，测试数据统计。
5、项目总结报告

情绪管理

情绪管理在项目开发中尤其是高压快节奏的开发中很重要但也很容易被忽略。一旦产生了情绪，对项目的推进和沟通必然存在影响。

其实，开发人员希望自己能够开发出具有良好用户体验和易扩展的应用；测试人员希望尽可能多的测出bug，尽可能的优化用户体验；产品经理希望自己的产品能够尽量的功能完善，体验最佳；管理人员希望我们的软件能够尽可能的稳定、健壮。

单独来看，大家的意愿和目标都是好的，高度一致的，那为什么还会产生情绪，进而发生执行困难呢？
经过思考，总结出大体以下几点：
1、初期业务没有思虑清晰、周全，导致中后期业务逻辑发生改变。
2、业务逻辑的改变，导致UI交互逻辑的改变。
3、业务和交互逻辑（流程）缺乏有效、明确的文档，导致开发人员、产品对业务的理解各自出现偏差，这种偏差发现的越晚，矛盾就会越大。
4、研发人员技术崇拜，又或者软件上的设计方案和各平台本身的设计规范冲突，导致开发人员的开发意愿和产品经理的设计意愿冲突。
5、高强度工作等导致的生理性反应。
6、不同平台的开发者之间，对一些细节或需求变更没有相互通知，造成相互挖坑的被坑情绪。
7、加入存在边开发边测试的情况，测试人员频繁的交涉技术人员，会导致开发流程中断，在开发阶段为开发人员产生非功能性、业务逻辑性的bug,导致开发人员可测试人员各自的情绪波动。
8、产品失败，努力白流，付出无法得到认可导致的情绪。

以上几点，基本可以涵盖主要的影响整个产品涉及人员的情绪波动的原因。
那么，该如何尽量的减少负面的情绪波动呢？
1、产品在立项和需求确认阶段，要充分的讨论和思考整个业务逻辑，尽量达到少更改或不更改需求。
2、业务逻辑和交互逻辑，要形成明确细致的流程性文档，避免出现需求不明确和业务理解偏差。
3、在开发阶段，产品与测试人员尽量减少交涉，有问题尽量通过技术经理沟通传达。
4、在产品开发阶段，如果要进行并行测试，尽量合理规划测试流程，明确测试重点。
5、整个产品周期中，遇到任何问题，需要主动沟通。
6、开发启动前，明确项目的管理流程，开发中尽量严格按照管理流程推进。
7、产生负面情绪，要学会调节和沟通释放负面情绪，归根结底，大家的目标都是一致的。

后记
流程是死的，人是活的，问题是在所难免的。在实际的项目管理中，各自都尽量的把自己的工作在项目早期完善，后面才会更加顺利的推进。

工作状态
如图所示，一项工作，假如我们在前50%的时间完成了80%工作，那么最终的结果我们可能会达到90%或100%期望；如果我们在前50%的时间只完成了30%的工作，那么我们就有很大的风险到最后只达到60%的期望。

这是我以前学到的一个道理，送给各位看官。