产品的设计过程中，需求的挖掘、产品的设计、产品的研发不可避免的会交织在一起，多数项目都存在需求滞后的问题，存在即是合理，这完全是一种合理的现象。多数公司的需求都是通过同行竞争者或行业内潜在竞争者的前端分析而得。这种未经过深层次业务检验挖掘出的需求无可厚非的成为产品设计和产品研发排斥的对象，多数项目不能根据项目的进程完成任务，75%以上都是由需求有限或无限的扩展导致；15%是无法建立合适的团队沟通机制导致；5%由需求错误导致；

主要有三原因导致：

第一：随着产品设计深入到了表现层、业务层和交互层，产品研发涉及到数据层的架构时，我们必须处于产品的可扩展性或性能方面提出更多的优异解决方案给业务部门，需求被第一次扩展；

第二：在产品设计的中期或末期阶段，实施产品策划，讲解DEMO（原型）的阶段，我们会进一步的拓宽业务部门对业务的理解，这时候业务部门会在当前产品的设计过程中进一步明确需求，此阶段极有可能推翻前期需求，甚至是对产品设计前期工作的推翻。(相信多数的产品经理对这个阶段最头疼)，需求被第二次扩展；

第三：在产品代码实施阶段，不同团队的技术研发能力或者产品设计者的设计经验的局限，导致产品遭遇了可实施性的挑战。很多情况，产品设计是创意产业，设计不缺乏更好的创意，但必须在可发挥的技术框架内，因为种种实现或性能方面的考虑，这里需求是被压缩的过程（不论是国内成熟的优秀企业，多少都有这个情况）

非常强调一点；抱怨解决不了这些问题；

从业务部门的情况考虑，前期的调研是非常消耗人力和物力的，最重要的很多成熟的商业模式，不需要我们业务部门重复去调研，偷懒点说，超市里有现成的蔬菜包，我们就不要再花费时间去菜场挑选了，结果一样，都是撒了农药的蔬菜；作为产品经理，应该加强对业务的挖掘，对业务挖掘的过程是个协作的过程，不要期望一次就达到成功的产品，要通过多次的产品设计，产品演示，帮助决策部门、业务部门提供更多的思路，有利于多维度的去剖析产品的业务模式。

从产品研发的角度去考虑问题，技术的实现是需要过程的，事先多沟通，对没有把握的技术多和研发人员确认。对于绝对必要的功能，要懂得坚持！对于可有可无的功能，要懂得妥协！

下面说说解决方法：

产品要对上游下游负责，最好的方法就是及时沟通！

对于业务部门的原始需求，先要进行需求的确认，指出明显有缺陷的需求（这部分需求或许是有害的），赛选出原始需求，该阶段的产品设计中我们可以发挥我们一切的思路，并尝试做一个简易的产品原型，组织一次需求讨论会，拉上业务部门和研发部门，对原型进行讨论，划出边缘需求、缺失部门的核心业务需求及出于产品拓展性考虑的需求，让业务部门将这三部分内容和原先的原始需求进行再一次组织，生成带有版本号的需求文档；也是在这个阶段，我们可以基本了解技术可实现的基本范围；版本号意味着需求已被划定，根据需求文档，我们开始一次正式的产品设计，这次设计要在划定的需求范围和技术实现范围内有限制的发挥我们的想象力，当然这个过程会根据项目的大小涉及的深度往返重复几次，不用担心，磨刀不误砍柴工！经过这样的沟通，我们的上游业务部门、我们的下游研发部门才能对需求有所把握。（确切的说，没有人可以完整的看完几百页的设计文档！）

当然上面说的是正常流程的状况，很多同事会问，现实中不可能这么顺利，的确如此，我们要对这个过程进行规范，通过加强版本管理对这个流程进行规范，主要设计两个业务：“需求修正”和“需求变更”。需求修正是指不影响大范围的局部修正，一般对项目产生影响非常小；需求变更则是指业务的增加业务的补充等，轻则增加设计研发任务，重则导致产品的推翻重来，这个业务必须经过需求评审的过程。

或许多数人对这个业务不太熟悉，这里我做了一个图形，希望对大家有所帮助。

装载请注明出处：www.seesem.com