【IT168 分析评论】

     今天凌晨不停的协调各方资源，但还是失败了，我们的产品V110版本从staging server向production server部署失败！发现了两个严重的错误，而这些错误竟然没有在staging server上发现！

    失败的结果让人挫折。为什么会失败？

    1. 在staging server上没有发现问题，最直接的是QA的失职。虽说质量是整个Team的责任，但研发和QA在Team中的具体职责还是有侧重的，“发布的标准”是QA的测试报告。这两个严重错误不包含在QA的测试用例中，而这两个严重错误又是出现在正常业务流程中。

    2. 之所以部署了5个小时，是因为第一次部署后有一些数据库的问题，我们的DBA居然不清楚数据库表和实现的关系，询问了开发人员之后才搞定。

    3. 公司有太多的业务需求，都要求在很短的时间内完成，仓促提交（包括开发和测试的质量都不好）是表层的原因；但作为PM/SM，不能说服管理层以科学的方式来研发产品，也说明了理性的工作方式和创业初期的急功近利之间巨大的冲突。如何化解这个冲突，是深层的原因。

    下一步我们怎么做：

    1. 减慢team的Velocity，增加Team向管理层承诺的研发时间。

    2. 评审、评审、评审测试用例，特别是正常的业务流程，往往acceptance test不能覆盖所有的正常业务流程

    3. 我们今后要加强：Team内部的沟通，特别是DBA、QA这些不直接编写代码的同事

    这次失败的部署，和公司的管理层也有一些沟通，有一个发现：

    这次V110部署的最主要目的是保证了浏览器的兼容性，提高了用户体验，这对于服务的试商用有关键的意义。而这次部署在兼容性上没有问题，只是其他的功能有Bug。最关键的是产品经理向管理层做了汇报，询问是否可以部署，按照部署流程，功能性的Bug属于Critical，是不能部署的，所以管理层要求不能部署。这次部署不成功，产品经理承担了很大的压力。

    其实我们和管理层私下聊天，有一个说法：所谓民不举官不究，如果产品经理不向管理层汇报Bug，而是自己判断已经达到了部署最主要的目的，就可以判定部署成功。管理层一般也不会深究违反流程的问题。我们的流程是这样的：如果产品经理判断是功能性的Bug，则一定不能部署。如果要部署，必须有管理层的认可。这里的民不举官不究，我认为是否有规避责任的问题？如果民举了，而官没有究，出了问题就是官的；如果民没有举，那官自然也不会究，出了问题就是民的。但是“民不举官不究”是不会放在流程中的。

    职场之道，需要再研究一下...