众所周知，制定项目计划是决定一个项目能否成功实施的基础，而IT项目，尤其是金融行业的IT项目，时间跨度长，专业性深，业务逻辑复杂，往往有创新的模式。不仅如此，有些客户还会要求我们在投标阶段或项目初期制定详细的项目方案。愿望是美好的，但完全不现实。 在项目实践中，从领导到售前，再到开发，研发和管理人员都在为项目提供支持。对于一个持续半年以上的项目，一个晚上就会要求d团队做一个细粒度到功能点的周计划，而需求分析根本没做，更别说功能点了。团队只能停下手头的工作，项目经理、产品经理、开发经理等人聚在一起，拍着脑袋强行列出功能点，按照客户要求推后一个实现时间。这种情况下，拟定的方案必然会出现较大偏差，只能作为ppt供客户欣赏。也许客户会缺一页ppt，然后向上汇报推广项目。然而，R & amp；amp；d队浪费了很多宝贵的时间。在连续几个类似的“项目计划”下来后，正常的研发工作就开始了。d工作会受到很大干扰，赶出来的“计划”价值不大。 当然，这并不意味着我们不应该制定计划。项目规划也是软件开发项目中的一项重要任务。有利于项目的方案是如何制定的？ 敏捷开发中，项目计划的制定是先粗后细。项目初期，了解到的信息非常有限，往往只是几个大的功能模块。此时，团队将对每个模块进行优先排序，并安排几个大的里程碑。正式开始开发后，在分析第一个要完成的功能模块后，会将详细的功能点划分为开发任务、预计任务时间点，然后分配到一个或几个迭代中进行实施。开发团队会一直保证当前迭代和下一次迭代中的任务都是详细清晰的，但是下一次迭代只有大概的目标。这种策划方式成本低，利润高。 通常，客户的需求与商业惯例相冲突。如何解决它们？是客户上帝，当然需要满足。所以这个问题不太可能完全杜绝，但可以从几个方面缓解： 1.销售人员要认识到，客户在项目前期的沟通中要求提供“详细的项目方案”是没有实际意义的，对团队来说是一种负担和伤害。只要有可能，我们应该尽量避免向客户承诺详细的项目计划。当然，里程碑计划是完全合理和必要的，里程碑计划通常是客户自己提出来的。 2.在条件允许的情况下，教育客户“先粗后细”或“远粗近细”的项目规划原则，并承诺提供近期详细规划和远期里程碑。当然，即便如此，近期的详细计划也只能在一定需求分析的前提下才能制定出来，这需要时间，大部分客户应该能看懂。 3.绝大多数情况下，我们只能无条件服从客户的要求，比如标书中有明确要求呈现方案的时候，或者需要讨好客户争取订单的时候。在这些情况下，考虑的目标是如何使计划尽可能合理，不应该考虑可执行性。毕竟信息有限，反正花精力在这上面也没什么意义。最划算的方案是在客户提出的大功能模块下，按照瀑布式的研发方法划分需求分析、架构设计、代码编写、功能测试等阶段，按照固定的比例划分时间(比如需求：设计：开发：测试=23:333:2)，每个阶段下都可以有明细项，因为和实际需求不同。 4.如果一定要按功能来安排，那一定是详细的计划。客户不给还价空间，就得加班.人生总会有浪费的时间。不过我相信经过前三条的筛选，需要这一条解决的是极少数。 项目立项初期，很多变量是不可控的，不考虑场外因素。只要我们关心客户的需求，想客户所想，真诚沟通，敬业务实，相信客户会做出合理的选择。 |
