作者 | 蓝灰_q
地址 | https://www.jianshu.com/p/688deb48d243
声明 | 本文是 蓝灰_q 原创，已获授权发布，未经原作者允许请勿转载
关于生产流程混乱问题
在软件研发这件事上，由于研发并不直接带来收入和利润，在实际情况中，业务优先、功能优先的思想，很容易导致生产流程的混乱，例如：
-
版本管理失控：没有人整体把控整个产品线的研发/测试进度、不能明确每个最新版apk。
-
Apk的发布风险：由开发直接提供apk，存在事故风险（未测试/版本错误）。
-
测试介入太晚：测试人员在提交apk后才开始理解业务，如果设计阶段有缺陷，到测试时才发现，修复成本高。
-
Apk提测与发布：用邮件附件提交apk导致难以追溯历史版本，apk中的非上线功能会干扰到上线流程。
-
没有迭代计划：没有规划出每个迭代版本的实现功能，需求不分优先级，上线前没有明确哪些功能暂不上线，并行开发的功能在上线前还在提测，导致上线混乱。
-
产品发布流程不清晰：上线发布的角色、职责未明确，发布流程未明确，工作任务缺少计划性。
-
版本号命名不规范：现有产品版本号命名不规范，应按照业界规范进行命名。
混乱的生产流程，隐含着非常可怕的隐患。我们从生产流程中各角色的职责分析一下。
角色与职责
一般来说，产品研发过程中，产品经理->研发人员->测试人员->产品经理应该形成一个完整的闭环，那么这三个角色应该有各自的职责。
产品经理的角色，提出产品需求、管理产品版本、提供最新产品，也就是：
-
向开发人员&测试人员发送产品需求，并跟踪开发-测试进度。
-
维护历史版本及变更内容，从开发人员手里获取已测试过的apk。
-
向业务人员提供最新产品版本。
对于产品经理的角色来说，要能实时了解产品进度，有效管理产品版本，了解历次变更，避免业务上使用了错误版本或低质量版本。
开发人员的角色，理解产品需求、实现业务功能、修复软件bug，也就是：
-
与产品经理沟通，理解产品的运作逻辑和理想状态，以便开发。
-
根据对产品的理解，实现软件业务功能。
-
根据测试人员的反馈，修复软件bug。
-
完成开发或修复bug后，向测试人员发送提测邮件，抄送产品经理，说明提测产品的版本号及变更内容。
对于开发人员来说，产品都是从这里开始输出，但不能直接输出给业务人员，因为研发人员并不直接了解需求，且不能保证产品质量稳定，所以开发人员的输出只能给到测试部门，经测试通过后，由产品经理统一向外提供产品，以避免事故。
因为开发的节奏和测试的节奏可能并不一致，为了避免相互干扰，开发人员的输出可以统一到一个输出池中，通过规范有规律的版本号，以及各种沟通机制，来保证测试人员以及相关开发人员能很容易地获取到最新的开发待测产品，而且还容易追溯历史版本。
测试人员的角色，理解产品需求、测试软件bug，也就是：
-
深入理解产品需求，尽早发现潜在缺陷。
-
向研发人员发测试问题邮件时，通过抄送开发人员提测邮件，说明通过测试的apk版本号及变更内容，这个邮件还应该抄送给产品经理，以便产品经理掌握产品现状。
对于测试人员来说，最好从设计阶段，就对产品原型开始测试，这样既能对产品理解更深，还能尽早发现设计缺陷。
总结来说，虽然三个角色有各自的职责，但应该有一个核心角色掌握全局，这个角色一般是产品经理，因为只有他是既了解整个需求，又了解研发进度和产品质量的。
所以，核心在于产品经理，他需要分析需求变化，紧跟产品研发，提供既满足需求又质量可靠的产品，对于经常需要根据市场需求进行变更的产品来说，还需要制定和执行一个长期的版本迭代计划。
基于上述分析，我们梳理出一个理想的开发流程。
理想开发流程
一个完整的开发流程包括需求-开发-测试-产品提交四个阶段，每次产品更新其实都是这样一个循环，每个产品都是无数个循环的过程。
具体来说，每个阶段涉及的角色和动作如下。
1.产品经理发布需求
2.开发人员完成开发并提交测试
3.测试反馈测试结果
4.产品经理提供产品
这个流程中，使用的Samba是团队内部共享文件系统，我们通过这个系统来提交和管理各版本的产品。其中主要分成两部分，一部分是开发内部使用的，都是质量未经验证的待测产品，另一部分是向外（业务）公开的，用于提供质量稳定的各版本产品。
samba的目录结构是这样设计的：
总结一下，整体流程如下：
其他
产品研发还经常有这样几个问题，包括产品迭代计划、产品发布流程、产品版本号规划、产品基线管理等。
产品经理制定产品迭代计划，并在产品上线过程中，跟踪本次上线功能，排除非上线功能干扰。
每次产品发布上线其实可以看做一个短期项目，按阶段实施，每个阶段有一定的角色参与。
软件产品的版本号有业界通用的命名规则。
开发中经常遇到测试与开发并行的情况，一边测试修复开发的功能，一边做新功能，如果不做好管理，很容易产生混乱，这时候可以利用代码管理工具辅助管理。
