甲方的时间表对我们的可能影响包括：

    A、 要弄清楚甲方真正的时间表，尤其是反对方的，并传达到公司内部每一个相关人员，所有计划都就应按这个时间表走。（反观我们，一方面我们只考虑友好甲方的时间表。另一方面，现在整个时间表其实已被开发人员劫持，我们的计划是按开发人员人数×每周工作量摊开的，呵呵。)

    B、 系统主要功能的真正完成，是真正完成，需要与客户多次反复交互、反复调试修改。第一次提交的版本，完全不能算是最终版本。对于具体的某个功能，或对于整个系统来说，都是这样。（反观我们，我们可能无法在客户要求的时间表之前（之前！）提交版本，即使提交了，也是首次提交，而非经与客户反复联调过的版本）

    C、 准确把握业务需求，还要准确地把握客户的非业务需求（如性能、推动试运行、UI易用性人性化、配套的培训等等）。准确地把握这两件东西，将会对开发效率，乃至于项目进度都会产生极大的助益。（反观我们，我们现在的绝大部分兵力，都投在研发环节，投在客户身上的时间实在不够，下面还会着重提到。）

    D、 公司应该有自己的时间表，产品研发计划应与市场运作联动。如获取业内行家的好评，需要我们及时发布可用的、漂亮界面的、稳定的、功能完整的版本；如搞财政系统内的推介会，我们也需要这样一套东西。对于我们没有的系统，我们应该有演示版本，而演示版的制作，也需要公司有专门的部门提前研究潜在的客户要求、业务需求。

    E、 产品研发的进度，任何时候都应该有5～10％的弹性。不是说要把时间表随意向前一调就叫弹性。（如果所谓的时间表到了一点动静都没有，下次开发人员也会学精的。同一个老鼠夹都会给老鼠识破，何况是自以为天下最聪明的程序员们呢。这是事实，不止一次发生了。比如说1月1号系统上线，1.1到了什么事也没有。结果才知道原来甲方要求的是2月1号上线。而甲方给上级的承诺是2月15号。双重忽悠！下次再说某月某日上线，大家就心里有底了，反正还有一个半月。忽悠的反作用。要么，就说1.1是我们上线第一次全面测试；1.15再做一次全面测试；2.1如果有时间就做第三次全面测试。我们的要求是最少做两次全面测试。这听起来都会好一点。）而是需要我们真正掌握产品研发中哪些因素在影响我们的开发进度，如何激活这些因素，在必要的时候为我们所用。比如说建立一套量化的、可监测的指标系统，在需要时加入一些物质激励，让各项指标在固定时间内得到实质性的增长。（如在服装厂，假设剪线工段是瓶颈，平时一个剪线工每天可以剪100件牛仔裤的线头，赶单的时候只要提出每人日产量达到150件，每件的单价提高20％。那么用一个瓶颈工段的费用，激活了整个生产线。前提是有指标衡量，而且知道哪一个工段是瓶颈。我家里是曾经做牛仔裤的，且家乡共计有1000多家牛仔裤公司，这是实例。）

    F、时间表至少应该有两份，公开也无所谓。一份为最优时间表，一份为合格时间表。项目整体时间，或具体的小项任务都应该有。Time is money. 报价1000万的项目，用500万/年成本×1年完成，跟用250万/年成本×2年完成，其结果是截然不同的。推荐高德拉特的《关键链――突破项目管理的瓶颈》P53，第九章，其中有“安全时间”的讨论。