“不重视需求过程的项目团队将自食其果。”
需求分析是产品研发前期的铺垫工作，也是重要的基础工作之一。需求工作中的缺陷将给项目成果带来极大风险，在推出产品时，体现在质量、功能、场景等情境下影响着用户的满意度和期望值。
综合自身近年来的工作经验总结出一些不当的需求过程所引起的一些风险：
前期没有任何一项站得住脚的用户需求分析，领导经常不明白为什么收集和确保需求质量需要花费那么多时间。开发人员可能也不重视用户的参与。大部分情况下，开发人员感觉与用户接触不如埋头写代码、推出新功能代替不足来得效率。某些情况下是因为条件和环境因素而无法获取来自终端用户、典型用户的需求分析，以至于无法预计产品最终上线时的应用情景，方向容易走偏，习惯上线后才根据真实用户的主动反馈进行被动变更，似是减轻前期成本投入，其实隐形成本已尽透支，这时除了不断的用更多的成本填补之前的漏缺也别无他法。应尽早让具有代表性的用户在项目早起用户的期望值也在逐步减少。
产品和开发人员在实践过程中也能感觉到，在前期若无足够的用户参与，产品人员获得的需求是片面的，不完整的。而开发人员意识到这样的程序在开发之初就埋下了风险，因为随着市场和用户的需求不断增加，在开发中若不断补充需求，项目就越变越庞大以致超过其预算范围。计划就不足以对项目的规模和复杂性、风险、开发周期及需求变更进行合理预估，这使得问题更难解决。产品开发中不断延续的变更会使其结构日见紊乱，补丁代码也使得整个程序难以理解和维护。如果你尽早地区别这些可能带来变更的特性，你就能开发一个更为健壮的结构，并能更好地适应它。
如何避免埋下如此罪恶的祸根？就要想办法把需求变更的范围控制到最小，并陪伴整个产品的研发周期。一开始就对约束限制、范围、目标及验收标准给予明确说明，并制定或将此做为需求变更的约束参照，说明中包括了对变更产生的影响因素分析，有助于让风险承担者及其他干系人明白业务决策的合理性，即为何进行某些变更，消耗的时间和资源。
每一次进行需求变更都要及时修正产品roadmap，形成v1、v2、v3…以便将风险控制到最小。
明确需求规格说明的规范，模凌两可的是最可怕的，它的一层含义可以被多个人解读为不同的版本。切图脱离实际，天马行空的乱加功能，很多的时候非常被动。
(会不断更新…)
有时，需求方并不明白需求分析有如此重要，于是只作一份简略之至的规格说明，仅涉及了产品概念上的内容，然后让开发人员在项目进展中去完善，结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明。这种方法在大多数情况下，只会给开发人员带来挫折（使他们在不正确的假设前提和极其有限的指导下工作），也会给需求方带来烦恼（他们无法得到他们所设想的产品）。
据统计，导致需求过程中软件成本估计极不准确的原因主要有以下五点：频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析。对不准确的要求所提问题的正确响应是“等我真正明白你的需求时，我就会来告诉你”。基于不充分信息和未经深思的对需求不成熟的估计很容易为一些因素左右。
最后告诫：非B2B的朋友们千万不要一厢情愿认为产品是由市场驱动，什么无奈啊，没办法啊，都不是你把产品带入穷途末路的正当理由。真是无计可施时，认真负责的方法是——辞职。既然你已经做了最后的一份耕田却还是改变不了，一款产品诞生时由于内在问题强大得可怕（外在原因多出现在产品运营时期），那么离开也是一种负责的精神，不过这是对自己的负责。
就算是市场人员在跑，他们顶多是扮演推广的角色。又或者营运人员在接触用户，但也不代表他们就是合格的需求提炼者。凡是没能参与到产品研发生命周期里的人员都不能完全当做产品的驱动方。应该由用户驱动需求，需求驱动产品。然而产品的整个生命周期中，一名具备丰富实战经验的产品经理也是非常重要的。
