这天，过去、现在、未来的三个不同历史阶段的QA又相遇了

　　过去的QA又提了另外一个问题：

　　另外一个老板和项目之间关于项目周期的纠结，我听到一些经理的抱怨：公司下达任务，时常会发现一些时间要求的打埋伏，本来45天以内完成就可以了，任务书上写30天，接着下达到具体的任务负责人时变成了22天，而QA老是疑心项目组打埋伏，把22天的工作说成45天。

　　公司认为Team打埋伏，Team觉得不打埋伏会损害自己的利益，于是互相猜疑.然后公司想办法和Team讨价还价，争取削减时间，而Team为了保证质量，讨价还价，争取更多时间，而且除了保证质量，私下还有不可说的想法是为了避免混乱的需求带来的无休止的时间后延。

　　现在的QA分析道：

　　老板预留了buffer缓冲期，其实是为了预防某种风险的，也是必须的。

　　但是从管理层面来说，如果重在追究延期的责任，那就等于鼓励项目经理对项目周期打埋伏，这种情况归根结底的确是老板带来的，所谓恶性循环就是这个道理。

　　未来的QA总结症结：

　　观察多个产品情况，确实掌握信息之后，把讨价还价/(讨价还价任何企业都有的，总比一言堂好，学名博奕)变成基于任务的讨论。

　　比如买服装，我不愿意去市场，因为没有标准。厉害的人可以“对折拦腰半”，也就是说50%×50%×50%，100元的13块搞定。卖家不知道买家的出价意愿，买家不知道卖家的利润空间，靠察言观色来互相考验底线。

　　如果软件企业内Team和老板互相信息不透明，极端情况也会这样。

　　老板这个角色任期比别的角色更长，所以先不要管讨价还价的细节，把每天延期任务的分析做好，通过每个任务的确认接口把关，在此基础上把讨价还价的摇摆空间降低。

　　1、技术人员通常更愿意坦诚相待，如果依赖察言观色来沟通，技术人员多数是吃亏的一方;

　　2、工程师多数会高估自己的能力，而不是低估自己的能力;

　　3、开发工程师多数容易做乐观的估计，而不是悲观的估计，当然，测试工程师可能反之。

　　最后了解工程师的思维，对QA是有帮助的。