App产品设计『技术篇』开发基础流程
这是《App产品设计指南》系列文章的第6篇内容，更多精彩可以点击下方链接查看。
产品生命周期是指产品从准备进入市场开始到被淘汰退出市场为止的全部过程，一般分为导入期、成长期、成熟期、衰退期四个阶段。本文中提到的基础流程可以理解为引入期之前的产品设计过程，或者是在不同周期内每一个小版本的产品研发过程，不包括产品的运营环节。
来自网络
流程说明
App产品开发的基础流程主要包括：需求定义&需求评审—产品设计&PRD方案评审—视觉设计&视觉评审—敏捷会议—软件开发—软件测试—发布上线，下面来分别说明一下。
需求定义&需求评审
在这个环节我们要定义产品、需求、使用场景等等。只有充分理解商业模式，业务流程，才能发现合理的需求。无论是老板还是用户的需求都应该被同等对待，客观分析产品流程，业务优先级才能制定出科学的需求规划。需求评审环节主要是由产品团队参加，研发部门和业务部门也可以考虑参加提供意见。
产品设计&PRD方案评审
在需求阶段产品经理内部进行需求讨论：讨论下版本需求重点是什么，做什么功能，怎么做。通过反复调研、讨论、输出产品PRD方案，这份文档是产品、设计、开发、测试等人员工作的依据。所以产品团队应该尽可能的精细化，使用文档让沟通更顺畅而不是增加复杂度。
视觉设计&视觉评审
通俗来说就是设计师根据产品方案来完成设计稿，进行标注和切图的过程。设计稿完成后需要在团队中进行评审，修改优化细节。
需要说明是在大公司会有专门的交互设计环节，交互设计师提交交互文档给视觉设计师，视觉设计师才开始做视觉设计稿。只不过在中小公司，一般是由产品经理和视觉设计师来完成这个流程。
敏捷会议
不同团队使用的开发模式不一定一样，在互联网行业比较常用的是敏捷模式。
在设计稿完成之后，在敏捷团队中一般会进行两个会议，分别是需求评审会和迭代计划会。
需求评审会由产品经理主导，会议的主题是针对下个迭代可能要做的需求进行逐个讲解，开发人员针对需求的优先级，选择下个迭代要开发的需求。一旦选定，这些需求就被冻结，原则上不允许再变更。
迭代计划会有项目经理主导，会议的主题是针对迭代的需求进行分解，分解成具体的任务，同时进行估时和指定到具体的开发人员。这两个会议结束后一般就表示迭代正式开始启动。
软件开发
项目正式启动后，开始进入软件开发环节。在研发过程中，产品经理和项目经理需要协同跟进研发进度，保证需求按照规划的目标被实现，同时要解决研发过程中发现的新问题。
软件测试
在迭代初期测试就需要着手理解需求细节，编写测试用例。在软件开发的中后期测试需要正式介入开始测试环节。在测试过程中，测试需要和开发，产品持续沟通以确定问题的优先级。理论上所有的问题都应该被解决，但实际中一些不太重要的问题可以延期处理。测试工作完成后，测试需要输出测试报告给项目组全体成员。
产品团队在接收测试报告后需要进行产品验收工作，如果发现有明显的问题需要对接给研发团队处理。需要说明的是产品验收环节虽然也属于测试，但力度相对要小一点因为绝大部分问题已经被提前发现和处理了。
发布上线
验收通过后就需要进行产品发布上线工作。线上发布一般都在晚上，不能影响到用户的正常使用。线上发布有不同的策略，比如说蓝绿部署，灰度发布，金丝雀发布等等。
后端代码和接口发布后，客户端开发人员可以提交线上安装包。团队成员需要最终检查一遍配置和产品功能，验收无误后需要提交对应的应用市场，发送升级通知。到这里整个研发流程才算真正结束。
在产品发布后，产品团队和运营团队根据用户反馈，进行数据监测、数据分析，制定后续计划，这里就不再展开。
来自网络
经验总结
每一期的产品迭代一般都有一个核心主题，一般是根据产品运营的节奏来制定的。产品研发周期一般控制到2-4周，这样才能保证项目足够敏捷，灵活，提高工作效率；较短的周期也能让用户保持新鲜感。这种策略一般适合于产品的成长期，一旦进入成熟期，所有的决定都需要慎重，因为任何改动都可能影响到用户，对数据带来巨大影响。
以我所在的公司为例，产品团队包括产品经理，前端和设计师。产品团队的规划最好能提前开发团队1-2个版本。在迭代启动的同时，产品经理着手规划下期迭代的设计，设计师在做下期迭代的设计稿，前端也开始切图，整个产品团队是领先于开发团队的。
不同公司的流程会有较大差别，但整体上都是按照这样的流程。大公司分工明确，做事比较精细，每个人都是按部就班地处理自己的事情；小公司做的事情比较杂，对人的要求比较高，通常都是一个人负责多项事物。无论在大公司还是小公司，只要大家遵循基础流程，充分沟通，相信一定能做出非常出色的产品。
在写作过程中，如果有意见或者想法，欢迎有兴趣的读者添加我的微信一起交流探索，共同进步。
