里碰得头破血流。那么，我们该怎么办？
让我们从开发过程中寻找答案吧!唐柳宗元道：“苛政猛于虎”，我们常常会畏“最后期限”如虎，然而殊不知错误的开发过程或方法有时候会比这条“虎”更为凶猛！此外，我们还可以从计划执行、任务安排、团队合作等诸多方面找到可以挤出来的时间。这个时候，项目管理者必须像葛朗台老头一般，精打细算，珍惜每分钟项目时间的运用。然而，项目管理者绝对不能因为时间紧促，而像周扒皮那样半夜学鸡叫，让团队成员加班加点，像牲口一般的对待。偶尔为之，或许无伤大雅，然而每日都如此，那么只能说明这个项目已经到头了，赶紧准备失败的毒药吧。因此，我们要做到：
1、合理裁减开发过程。
在项目管理过程中，必须执行相应的开发流程，例如计划评审、同行评审、阶段评审等。此外，QA会拿着众多检查点，每日走查项目组是否在质量保证方面存在缺陷。因此，在项目周期紧张的情况之下，项目管理者与QA就必须针对项目的实际情况，合理地裁减开发过程，省去一些不必要的官僚会议以及QA检查的表面文章。同时，随之而来的利益则是大量工件，尤其是文档的减少。如果能够让开发人员能够从文山会海中解脱出来，谢天谢地，他会成为项目开发的急先锋。要知道，世界上所有的程序员都在为文档的编撰而苦恼。减少文档不等于说不写文档，即使是敏捷开发，注重代码与可工作的产品胜过完整的文档，仍然不会忽略基本文档的编写。虽然在对需求和设计进行分析期间，我们可以考虑用面对面交谈的方式，或者在白板上写下我们的设计方案，但为了项目沉淀或者产品维护与重构，以及考虑成员变化等种种因素，文档的编写仍然是项目开发中不可缺失的重要环节。关键是编写文档的“度”。敏捷的布道者Alistair Cockburn在其书《敏捷软件开发》中写道：“团队成员应当在为将来的使用而超支的成本与未来文档不足的风险之间进行平衡。找到两者之间的平衡点是一门艺术……”我对那种形而上学的开发过程管理深恶痛绝。为了通过阶段评审，我们必须要腾出时间来编写阶段评审文档，然后请来那些大多数尸位素餐的评审委员会专家，然后不痛不痒地提出几个缺陷或错误，最后一团和气的结束会议。显然，这是一种官僚思想，是集体的资源浪费。即使为了某些办公室政治考虑，那么项目经理也应该像牧羊犬那样，保护自己的团队成员免受这方面的干扰，就像Scrum所要求的那样。
2、合理的设定功能优先级，并以此制定开发计划。
这里我们可以玩弄一个花招，即使我们无法在客户那里寻求到裁减功能的支持，但我们仍然可以在功能优先级方面大作文章。例如将客户要求的优先级高的功能，以及技术实现必须的高优先级功能先行实现，那么，到了最后期限来临之际，即使我们还有一大堆低优先级的功能未曾实现，但由于客户最关心的功能点能够高质量地运行，最后的产品虽然没有完全满足客户的需求，但凭借着优先级的合理划分，也可以让我们在后面的商务谈判中占据先机。此外，我们还可以信誓旦旦地向客户承诺，我们会在交付产品之后，继续完成剩下的功能。客户是否完全满意，谁知道呢？但至少我们交付了产品！以己之见，虽然这个产品不够全面，但总比交付一个全面的产品，却错误频现要来得好。
3、提高会议效率。
无论是传统的软件开发方法，还是敏捷方法，在软件开发过程中，不可避免要召开各种各样的会议。毕竟软件是人开发的，而且是组成一个团队的人开发的，因而交流成为必然。我并不反对召开这样的会议，相反，我很乐于参加这样的会议，因为这样可以让我的口才在全体同僚面前得到充分地展示。然而，会有多少的宝贵时间淹没在这样的夸夸其谈，或者口沫横飞之