众所周知，制订项目计划是决定一个项目能否顺利实施的根本，而IT项目尤其是金融行业的IT项目，时间跨度长，专业度深，业务逻辑复杂，往往还是模式创新。不仅如此，部分客户还会在招投标阶段亦或是项目初期就要求我们制订详细的项目计划。愿望很美好，但完全不现实。
在项目实践中，从领导到售前到开发，层层加码后，研发团队会被要求在一个晚上就对长达半年以上的项目做一个粒度细到功能点的每周计划，而此时需求分析还完全没有做，更别提功能点了。团队只能停下手头的工作，项目经理、产品经理、开发经理等人凑一块儿，以拍脑袋的方式强行列出功能点，并按客户要求倒推一个实现时间。这种情况下制订出来的计划必然偏差很大，只能作为ppt供客户欣赏，或许客户就缺一页ppt，再去向上汇报以推动立项。而研发团队的核心力量却浪费了大把宝贵时间，连续几个类似的“项目计划”下来，正常的研发工作会受到极大的干扰，而赶出的“计划”也价值甚微。
当然，不是说不应该制订计划，项目计划制订也是软件开发项目中重要的一项工作。那一份有益于项目进行的计划是如何制订的呢？
在敏捷开发中，项目计划的制订是先粗后细的。项目初期，了解到的信息很有限，往往只是若干大的功能模块，此时团队会将各模块进行优先级的划分，并排定几个大的里程碑时间点。开发工作正式开始后，对要完成的第一个功能模块进行分析后，会拆分出详细功能点，细化为开发任务，估算出任务时间点，再分配到一个或几个迭代中实现。开发团队会时刻保障当前迭代和下一迭代中的任务是细且致明确的，但较远的迭代只有大致目标。这样的计划制订方式才是成本低收益大的。
通常还会碰到的，客户的需求与业务实践发生冲突了，该如何解决呢？客户就是上帝，需求当然要满足。所以，要完全杜绝此问题，可能性不大，但可以考虑从几方面来缓解：
1、销售人员应当意识到，项目前期沟通中，客户要求出“详细项目计划”没有实际意义，对团队是负担和伤害。在一切可能的情形下，应尽量避免向客户承诺给出细致的项目计划。当然，里程碑计划是完全合理且必要的，而里程碑计划通常也是客户自己提出的。
2、条件允许时，教育客户“先粗后细”或“远粗近细”的项目计划原则，承诺提供近期较详细计划和远期里程碑。当然，即便如此，近期的详细计划也得在一定需求分析的前提下才能制订，是需要时间的，多数客户应该也能理解。
3、多数情况下，只能无条件服从客户的要求，比如在标书中有明确要求呈现计划，或需要取悦客户以拿下订单时。这些情况下，考虑的目标是如何出一个尽可能合理的计划，而不应考虑可执行性，毕竟信息有限，无论如何花精力考虑都是没有意义的。性价比最高的解决办法，是在客户已提出的大功能模块下，按照瀑布式研发的方式，划分需求分析、架构设计、代码编写、功能测试等阶段，按照固定的比例（如需求:设计:开发:测试=2:3:3:2）划分时间，每个阶段下面都可以有细化项，由于与实际的需求无关，这种计划可提前准备详细模板，需要时快速生成，相信也能满足大部分需求。
4、倘若一定要按功能点排，还必须是详细计划，客户不给还价空间，那只好加班了……人生总会有时间是被浪费的。但相信经过前三条的筛选，需要这一条来解决的已经很少了。
立项初期，很多变数不可控，不考虑场外因素，只要做到将心比心，急客户所需，思客户所想，诚恳沟通敬业务实，相信客户会做出情理中的选择。