我供职的第一家公司里，公司的企业文化中一个重要的观点就是敏捷开发，快速迭代。 这个观点来源自母公司，母公司的CEO认为做产品不要怕犯错， 要不停地尝试、快速地实现，哪怕在这期间出现了错误也是可以原谅的，只要能及时调整过来就可以。 当然，这个观点也被高层从大洋彼岸带过来了。 因此，公司里是木有专职的测试人员，测试工作都是由工程师和产品共同完成的。
In the first company I worked for, Agile Development and Rapid Iterations is an important part of corporate culture. The CEO of parent company consider that one must not be afraid to make mistakes when developing a product. It’s ok if a mistake is made but quickly is fixed. This opinion is bring here by the leaders, leading to that there’s no tester and both engineer and product manager are in responsible for all test work.
但是，今年的一些经历让我对这一观点有了新的认识。不同的公司之间企业文化有差异非常正常， 现在供职的公司主要关注移动互联网，虽说都有互联网“字眼”，但是区别还是挺大的。产品形态的区别， 导致了公司对产品质量的态度和重视程度有非常大的差别。
But I have some new opinions in this subject since last year. My new company is focused on mobile apps. There are many difference between two companies.
现在，产品与工程师团队之间的合作称为“交付”。这个词的含义相信大家都不难理解，只是互联网产品面向终端用户，很少提“交付”一词。 之前，我对互联网产品的理解是：一个产品应该是产品团队与工程师团队相互配合，共同合作完成，“交付”给终端用户的。 无论技术上还是产品上出现了错误，都是双方的责任，当然纯语法错误除外。 如果技术、产品人员（测试）对各个需求点的在发布前都一一验证一遍的话，就不会有那么多bug了。 但是，文档的缺失让技术、测试甚至产品都无法准确把握产品需求，无法将需求点梳理顺畅，导致各项工作在极度混乱的情况下展开， 那顾此失彼的情况的发生也就很容易理解了。当口头沟通成为常态，“交付”一词也就出现了，当然还有罚款。
最后会发现，事情的真相其实是“试错“与”出错”。只有“试错”是允许的，“出错”的不允许的。 OK，“试错”的只能是产品，“出错”的才是工程师。于是，你会发现， 技术团队辛辛苦苦每天加班到深夜做出的产品还没上线就已经在下一版设计中去掉了，或者是花了几个月时间做的功能， 在一次战略调整后全部砍掉，这些称之为“试错”，是被允许的。一个API在十几个小时内不能访问是不能允许的，这称之为“出错”。
所以作为技术团队的一员，无论公司文化怎么提倡说不要怕出错，一定要清楚，这不是针对技术的，对技术人员来说，软件质量都是第一位的！