相信每个企业都碰到过推、拖、谈、压、补的情况，这也是在实行所谓责任制的公司里经常遇到的。下面举例来说明一下。
H公司有产品、开发和测试3组人马。在项目开始前客户已经提供了详尽的需求说明书，并且客户有专门的团队对需求功能进行测试。H公司在原有产品的基础上，很快就做出了满足客户需求的产品，并送交客户进行验收。客户有老板B，B对同类产品相当熟悉，拿到H公司的产品后进行了使用。B根据使用情况和已有经验，对H公司产品提出了改进意见。
H公司产品经理如实向开发团队反应了B的需求，并希望在合同期前完成。产品、开发、测试3组人马凑在一起进行了Meeting，产品经理再次阐述了B的需求，并强调了若不实现客户可能不会买单的情况。
开发倾听需求后，B的需求来的太晚，没有resource去做，即使要做，也要花X人天进行调研，有可能还需要跨门合作，比如和硬件部门沟通。测试说，需要需求具体化，才能进行测试用例的编写，开发完成后才能进行测试。
之后的若干时间内，开发在调研后，不断地强调resource不足，该需求未在plan之内，工期会很长等等，希望产品能够和客户沟通，将B的需求放在第二阶段解决，或者出货后以补丁的形式提供。测试说，我们需要开发确定schedule之后，才能提前安排测试的resource。产品经理不断给客户列举现实困难，目的就是要客户放弃B的需求或允许延迟完成。
某天，老板B再次使用了H公司的产品，发现所提的需求仍然不存在，气愤之余对H公司产品经理说，若不能在交付之前完成，我们将不予采购。
产品经理将此信息报告H公司高层，开发迅速对此进行了评估，结果是在交付之前只能完成基本需求，完全完成已经来不及；测试马上对resource做了调整，随时可以开始测试。B的需求在交付前得到满足，它缺少统一的外观，糟糕的用户体验，缺乏足够的竞争力，但满足了B的需求，不是吗？
产品交付后，客户要求在后续产品中需要对B的需求进行细化处理，新一轮的责任大讨论在H公司展开，只不过这次针对的是，如果去修补紧急赶工出来的满目疮痍。
如果解决这样的问题呢？恐怕没有答案。首先公司高层要意识到这种情况的存在，其次需要制度自上而下的改革，再次提高执行力。这些都需要温水煮青蛙式的前行，暴风雨式的挺进，会造成旧秩序的崩溃和新秩序的混乱。
人治还是法治呢？
