大家好，我目前就职于一家小公司，工作了 3 年多。最近在回顾我们公司的产品线和测试流程时，发现了很多混乱和困惑，想在这里和大家讨论，也欢迎批评指正。
公司现状
这几年，公司人员经历了比较大的变化：
产品部门：
原本 5 人（1 个经理、1 个产品定义设计、1 个助理、2 个 UI），1 年前因为业绩不佳被高层认为 “不重要”，整个部门被撤掉。最近又开始重建产品部门。
研发部门：
从原来的 30 人左右，缩减到现在只剩 10 人。
测试部门：
从原来的 10 人，缩减到现在只有 2 人。
在这种变化下，整个产品线运作极度混乱，跨部门协作阻碍非常大。
作为测试人员，我经常陷入迷茫：一个好的产品线到底应该是什么样？
我目前主要负责某条产品线的功能测试、回归测试，也尝试做了一部分接口自动化。
因为公司人员缩减，很多流程没人管，所以我开始关注并尝试推动流程改进。
之前公司的产品线流程（现状）
需求 → 确认需求 → 设计产品定义 → 开会谈论产品定义 → 确定产品定义 → 开发 → 提测 → 测试
以下是我以 测试视角 对整个流程的分析（不带偏见，仅个人困惑，虚心请教）：
1. 需求
- 不清楚需求来源，通常是领导口头说要做什么就做什么。
- 没有需求文档，更没有文档归档。
后果：后续优化或维护时，无法追溯需求来源，功能堆叠，产品越来越复杂，用户用不明白，
开发、测试、维护成本极大增加。
2. 确认需求
3. 设计产品定义
4. 开会谈论 / 确定产品定义
- 设计完成后，没有及时通知相关人员。
- 开会时相关人员不了解产品定义的背景和合理性，只知道 “要做什么”，
导致后期产品定义频繁修改。
5. 开发
- 遇到产品定义不清晰，开发会按照自己的理解实现，没有知会任何人，直到测试阶段才暴露问题。
6. 提测
- 没有提测文档、没有自测管理、没有流程图。
- 只是在做完后通知测试 “可以测了”。
7. 测试
- 测试和开发阶段同步设计用例。
- 提测后测试发现问题时，产品定义还在反复修改，而这些修改没有通知到任何相关人员。
我理想中的产品线（个人总结）
我认为应该这样（欢迎补充和指正）：
1. 需求 / 确认需求
- 建立 需求文档，与相关部门开会充分分析必要性。
- 确认需求后 归档处理，可追溯。
2. 设计产品定义
3. 开会谈论 / 确定产品定义
- 设计完成后，必须通知所有相关人员，让大家充分理解产品定义。
- 会议中能提前找出不合理点，避免后期大量修改。
4. 开发
- 遇到定义不清晰的地方，及时沟通。
- 产品有重大调整时，及时同步给所有人。
- 进行 代码审查 和 走查。
5. 提测
- 提测阶段 必须输出流程图、自测文档，保证提测质量。
6. 测试
我的目标和困惑
我明白小公司人员有限，流程不可能一步到位，但至少希望 建立基础的可追溯和沟通机制。目前在想，如果想 逐步优化流程，应该先从哪一步做起？是先推动需求评审？还是先推动提测标准化？或者先从测试这边建立自己的提测/回归规范？
想向大家请教
- 你们公司产品线/测试流程的关键节点是怎样的？
- 在小公司里，最实用的流程改进方法有哪些？
- 有没有成功的 “轻量级” 流程管理经验可以分享？
欢迎大家留言讨论，非常感谢！
↙↙↙阅读原文可查看相关链接，并与作者交流