做APP要比做小程序困难很多。

不管是小程序还是APP，当一个项目走到这样的一个情况的时候，大家就一定要注意了，这种情况项目交付是很可怕的。

 一、项目交付  

一个项目本身功能也确实做的七七八八了，然后就剩下一些小尾巴。

针对这些小尾巴的处理呢，可能整个项目的开发时间也就40天，但是为了处理小尾巴，处理了一两个月处理不完。

这种项目最终的交付是很困难的，因为双方在需求的对接，以及细节优化和bug问题的处理上都会非常疲惫。

开发团队天天改细节、修Bug，客户那边看着没完没了的调整，也对交付进度失去信心，陷入双向消耗。

 二、影响因素  

我们公司也会遇到一些这样的项目，这种项目导致最终交付是这个情况的原因，我大概总结了一下。

 1.开发方：需求沟通不足

第一点是软件开发公司自身的一个原因。

就是产品设计环节这个需求沟通没有和客户说清楚，而导致后续的优化问题不断，没有个尽头。

比如做一款在线教育APP，开发前没和客户明确“课程视频缓存功能是仅支持WiFi环境，还是也涵盖移动网络”。

开发中默认做了WiFi环境缓存，快交付时客户要求补充移动网络缓存场景。

这类因沟通缺失产生的需求补改，让“小尾巴”越积越多。

 2.客户方：需求偏离

还有一个可能性是客户层面的原因，就是整个的需求在交付阶段和合同签署阶段偏离的会特别多。

像做企业办公APP，签合同时需求是“实现基本的审批流程、文件存储”。

交付阶段客户又提出“要增加与原有业务系统的数据互通、定制化报表功能” 。

这就导致了最终做出来的成品不断的去做修改，不断的去做补充。

再加上bug问题的处理，那这个项目永远都会只剩下一点小尾巴，陷入改需求、修Bug、补功能的死循环。

 三、解决方法  

那这种类型的情况要去怎么处理呢？

我觉得主要的方式还是在于双方的沟通。

就是双方需要共同的把最终的需求给完全落地掉，不能改一部分，看一部分，再想一部分这样去做。

可以参考项目管理里的“需求冻结” 机制。

比如在项目开发到70%进度时，双方把功能细节、交互逻辑、异常处理等全部敲定。

把这个无终止的需求做下限制，把费用还有时间以及需求都整体性的做下控制。

 费用上：约定需求变更超出原需求，额外收取费用。

 时间上：设定需求确认后，需预留1开发周期用于细微调整。

 需求上：明确仅聚焦已确认的核心功能收尾，新需求放入下一版本规划。

这样的话，这个项目的进度管理才能正常化，开发和需求双方都能高效推进工作，让项目真正“落地生效”。