Android开发项目管理7宗罪之一——需求变更罪

其实在写本系列总结之前，原本是想先写写部分技术总结的。但后来想想，技术方面，有代码在，技术点不会遗忘。反倒是这些管理过程中的一些体验和感悟很容易随着时间的演变、工作强度的提高而遗忘。故先出了本系列总结。

需求变更——可以说是导致项目管理各种问题的罪魁祸首，没有之一，上至项目经理，下至开发实现者，无不对其深通恶绝。简直到了谈需求色变的地步。

所谓的需求变更，主要包含一下几个方面：

1、原需求确定后，随着项目的推进，项目成果逐步的展现出来，这时需求方看到效果以及对同行更多更深入的了解后，对这块需求有了“更多更好”的实现想法提出，导致需求变更。
2、期初产品经理对项目需求了解的不够深思考不够全面，导致其对需求并无明确的目标和思路，最终引发了其后的需求不断变化。
3、项目初期或者说前半段，负责人由于某种原因对项目不上心或者无精力过问项目质量。某种原因——比如年底了，快年关了，大家都轻松点，年后再说；或者，前期演宫斗剧去了，现在有了结果，该干事拿表现了等等。然后下半段投入了大量的精力在项目上，于是乎，各种新的需求开始如流水般的提出。不改就在后面的审查阶段卡脖子不签字，不付款。需求实现方不得不改。
4、新增需求。这个在项目开发中依然是很普遍的事情。

笔者曾经的一个项目情况就如第三种，至于原因么，未知，也没八卦的好奇心去打听。

对于第一种情况，我们通常需要根据开发情况制定计划，如果要变更的那部分需求已经实现，现在变更需求，我们需要评估因变更这部分需求带来的工时影响，如果工时影响超过1天，那么得慎重，毕竟超过一天的工作量，无法在一个加班天内完成，这势必影响到项目的正常推进。这时可考虑该需求变更延后解决。如果变更的需求只实现了一部分，那么我们要考虑新老需求切换的工时影响。然后调整项目安排，避免影响后续工作的推进。

对于第二种情况，开发和需求双方要多沟通，充分了解需求方的想法，想要什么，想要实现什么样的功能或者效果。然后参照同行或者经验，保守或者创新性的提出最优方案供对方参考。以尽可能的在开发前充分了解需求，以便斡旋。当然这种情况下，面对未知的需求，是不适合立即投入开发的。

说实话，最无解的是第三种情况。典型的一个巴掌拍不响一拳打在棉花堆上软绵无力。

最后一种情况，应该是相当普遍存在的，加需求就像吃饭一样。小需求可以酌情考虑再开发后期测试阶段加入。大需求，
要数人数周才能完成的。想必影响上线内测，相互协商放到上线后再开发最佳。

开发期间，必须与需求方保持有效的沟通，让对方清楚的知道当前项目推进的情况，防止需求方盲目的提出需求变更并要求实施。影响项目推进。同时项目上遇到的问题，对方也能提供有效的信息。消息互通。