为什么不能照搬以前的成功经验？

之前提到，笔者刚换了一家公司，说一下笔者在开展工作过程中遇到的一些问题。

先介绍一下公司现在的情况。

1. 目前产品的文档几乎没有，研发人员+测试人员中精通全部业务的没有，每个人都只了解自己负责的那一小块。
2. 版本送测后，测试人员没有编写测试计划，也没有设计测试用例，都是靠个人能力进行测试。
3. 每周都要进行新版本发布，而且经常有为了客户要求，版本在存在较大风险的情况下紧急上线。有时候，领导也会因为一些关键需求要求研发中心一定要按规定的时间上线。之前研发总监还有北京的测试经理跟领导说，有什么限制，没办法按时上线。领导就说不想听任何理由，只想看到产品按时上线。有的时候，领导甚至会要求一些主要负责人一起开会来解决上线问题。当然了，我们大家都知道，领导也知道我们的做法有风险，也不符合规范。但是为了达到客户的要求，领导这也是没有办法的办法！毕竟我们要先服务好客户才行。但是最近大家都发现这种方法越来越不好用了。现在不管领导怎么催，质量故障或不能满足客户要求的情况还是出现的越来越频繁。也正是因为这个样子，领导也开始召开专题会议，讨论怎么解决这个问题。

正文

如果只是为了提高质量，我有很多经过验证的、成熟的经验，不过这些经验很多并不适用于当前的情况。

我经常在考虑，我们公司的竞争优势在哪里，或者我们公司希望在未来的三到五年保持或者创造什么样的竞争优势？响应速度快是不是我们的优势？如果是，很显而易见的，现在虽然我们想继续维持原有优势，但随着情况的变化，我们的优势正在不断丧失。不过这个问题也可以通过提升管理水平来重新稳固。

我目前还不清楚我们的竞争对手有哪些，以及他们的优势。先不妨做一个假设，如果我们竞争对手的响应速度不那么快，并且我们公司也为了质量而让响应速度跟我们的竞争对手一样，领导能否接受？客户能否接受？公司生存是否受影响？还能否保持现在这样快速的发展速度？

情况不了解情况，立测试规范的底气就不那么足。

今天就遇到一个问题，就是现在测试周期紧张时，要不要写《测试计划》？

如果作为一个面试问题，即使是一个刚接触测试的人，也能说出个一二三来。但在工作中，一旦测试周期紧张了，就会有一部分测试人员会想，能不能不写计划，本来测试时间就紧张了，还要花那么多时间在计划上，值得吗？对质量提高有帮助吗？

以我面临的情况为例，会有员工觉得，我们现在迭代这么频繁，可以认为是敏捷开发了。既然敏捷开发不重文档，我们就不写了吧。

说说我的看法：

• 做工作要多问思考，多问为什么，比如我们是敏捷开发吗？我们真的需要敏捷开发吗？敏捷开发解决的是快速变化的需求，那么我们的需求（具体到每个产品线）变化快吗？需求变化的快慢，是短期还现象是长期现象？
• 我们是否有能力做敏捷开发？敏捷开发中，对测试的要求是非常高的。测试和开发的区别只是负责编写测试代码和负责编写代码，从难度上讲没有区别。甚至从思考的程度上，编写测试代码要想得更多。
• 不要纠结手段，敏捷开发和瀑布模型只是手段不同，目标还是一样的，敏捷开发也可以采用瀑布模型的手段。我们公司的开发迭代模式类似于敏捷，但其实不是，只是似是而非。
• 凡事预则立，不预则废。越是在需求不明确的时候，越需要分析我们的测试范围。写计划主要是为了分析测试范围，无论写不写计划，都需要做。计划，有时候只是让我们的思考过程有个记录。
• 担心写计划要花时间，这个其实是另一个问题了，即如何缩短测试计划编写的时间。

总结

说点响应标题的，作为管理者新加入一家公司后，不要着急推行自己掌握的管理模式。

管理是需要符合企业实际情况的。每个企业的工作环境、人员素质、业务特点往往有很大的区别。如果空降兵没有及时意识到这种差异，继而根据新公司的特点提出对策，那么改革将很难成功。有的人指望引入一些大企业的先进管理流程和管理方法来解决公司的问题，这很容易走入一个死胡同。