某项目因为多次流标导致实际项目时间严重压缩，我该咋办？

本文主要是介绍某项目因为多次流标导致实际项目时间严重压缩，我该咋办？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

问题：

某政府项目，三个月前就开始招标，因各种原因，流标三次，导致时间拖太长。
原计划一期工期三个月+，1月底上线，但因为招投标影响直到一个月前签订了合同，
上线时间不变，需求各种不明确，但是客户对上线时间卡得特别紧，范围在一定程度上不可变，时间因为某些原因固定，你们怎么处理？

Fireball的建议：（我的建议）

1.对于需求各种不明确的问题
这个可能是首先要解决的，可以让你们公司对业务最熟的人出手，或派需求分析能力最强的出手。
基本原则：客户不清楚要什么，你就帮他定；根据需求重要程度和依赖关系排序。

2.对于1个月后上线，客户对这个卡得很死的问题
搞清楚为什么卡得死，另外到时会有谁来检查？
一般来说时间点卡得死是正常的，因为客户向上级提交了计划，需要有东西交付。如果仅仅是这样，其实你做到有东西交付就行了，不一定都要做出来。
如果到时有重要领导检查，则你需要取舍，某些必要功能需要实现，但某些功能可以做成可以达到演示效果就可以了，什么是“演示效果”? 就是有个样子，看上去好像可以操作，实质上是不能用的

3.牺牲质量来保进度是不可行的
如果这样做，你可能会绝大部分功能都有问题，不如舍弃部分功能来保证基本功能能用。
对于这样的情况，不要指望做到80分或更多，这是不可能的，客户满意度能有60分就可以了。如果你勉强答应所有需求，你做不到最后客户会更加不满意，客户满意度可能只有0分！
如果你够魄力顶住压力，集中火力保证基本功能能用，虽然客户和老板会骂你，但你至少可以有个60分。

4.分包估计也很难解决问题
可能会带来更多管理成本、沟通成本和磨合成本，工作质量也很难保证。
这么多短的时候，找到合适的供应商很难，另外我们的项目一般是智力密集型的，很难简单暴力拆分工作。用户故事之间的关系，技术底层和数据库底层等，这些不是简单的暴力拆分可以搞掂的。

上面说得这么复杂，其实简单说就是：你要勇敢地砍范围！老板不答应也不要管，顶住压力，将在外君命有所不受