1、有没有必要写需求文档
当产品规模小、项目人员少时，没有文档不会出现太大的问题，项目依然可以灵活、顺利地进行。但当产品规模不断扩大、项目人员不断增多时，缺乏文档的弊端就会渐渐显现出来。比如，当人员流动时，工作难以交接清楚，因为历史的功能信息均没有记录。当系统越来越庞大时，谁也无法描述清楚底层的完整业务逻辑，更新维护的成本极高，工作流程十分混乱，团队内部沟通不畅、效率低下……
假如在一个大型项目团队中，产品经理没有写需求文档的习惯，而是直接深入细节，绘制线框图，那对整个项目团队可能都是一场巨大的灾难。因为即使是一个非常专业的设计师，也不能保证在处理一个复杂的问题时，能够立刻描绘出正确的设计方案来，他必须经过一系列思考的过程。
小型团队中虽然不需要详尽的需求文档，但产品定位、需求优先级等总是要有的，只是不限制文档格式，普通列表也可以，只要方便团队成员理解、沟通即可。
所以说，作为产品经理，应该养成写需求文档的好习惯。第一，需求文档可以有效地帮助产品经理理清产品功能、内容、业务逻辑等整体信息。如果跳过这一步，过早地陷入界面细节，很容易得到盲人摸象的结果，给后续环节造成灾难性的后果。第二，需求文档大大地方便了团队的沟通，让团队成员在项目前期迅速准确、全面地了解你的想法，而仅靠简单的沟通则很难遍历到所有的需求点，且面对多人团队时效率很低。需求文档也规范了项目的具体内容，不会出现越跑越偏的情况，增强了对项目的把控力。第三，需求文档可以帮助其他项目成员有针对性地提出问题，而不是感到困惑和无所适从，这样也提升了工作效率。第四，需求文档不仅有利于项目的持续发展，还能促进产品经理自身能力、专业性的提升。就像交互设计师要产出原型、视觉设计师要产出视觉稿、开发人员要产出代码一样，需求文档就是产品经理的重要产出物。很难想象不会设计原型的交互设计师、不会画视觉稿的视觉设计师，不会写代码的开发人员，能称得上专业。有些产品经理自认为很有才华，不屑于因循守旧、墨守成规，须知再才华横溢、满腹经纶的人，也需要脚踏实地，才能得到团队的认可。
在具备一定规模的团队中，产品经理不仅需要提供需求文档，还应该不断地与团队成员沟通。前期沟通主要传递想法。中期沟通解决不断发现的问题、迭代需求。后期沟通确认问题是否得到解决。
2、无需求文档或文档不标准怎么办
如果产品经理不写需求文档或需求文档不标准，我们应首先给予充分的理解，并督促他解决这个问题。
如果是面对一个较大的项目或是比较复杂的需求，且团队人数较多，则需求文档应该保证一定的规范性。很多公司都有通用的需求文档模板，以保障形式和内容上的统一。这样既不容易遗漏重要的内容，也让需求文档看起来更专业，同时统一的形式也降低了项目成员的理解成本。
如果产品经理提供的需求文档不够标准，设计师应该提醒产品经理修改需求文档。一来，如果需求文档不合格，说明产品经理根本没有想清楚需求，设计师难以进行后续的设计任务；二来，没有需求文档这个依据，产品经理可以在设计环节随意更改想法，导致后续环节效率极低。所以设计师必须做到心中有数，清楚需求文档中应该包含什么内容。内容不全时要求产品经理补全即可。如果产品经理确实没有时间补充，也要自己想办法把这些内容搞明白，并和产品经理确认清楚，否则后面的设计工作也难以顺利地进行。
而如果是一些比较小的功能点，设计师可以灵活处理。可以总结自己在项目中需要知道和了解的问题，列出一份清单，请产品经理回答。相信每个产品经理都不会拒绝为大家回答问题吧。如果觉得对方回答得不清楚，可以继续细化问题，直至回答清楚为止。
3、辨别需求文档的内容是否合理
我们知道需求文档不可能一次到位，即使采用合理的流程，需求文档也会经过正常的迭代。
如果设计师并没有和产品经理一同参与前期的需求分析过程，而是直接拿到了需求文档（这也是最常见的情况），那么就需要注意了。需求文档中关于业务逻辑、产品要求、资源限制等是设计师必须要正确理解的内容。而与设计有关的信息结构、任务流程、功能说明、界面描述等，仅需作为参考即可。
有的产品经理设计的需求并不是用户的真实需求；没有正确理解用户的意图；把自己当做了目标用户，提出的需求过于主观化；需求明显不合乎常理，等等。
所以设计师需要重新考虑正确的需求，在设计过程中与产品经理保持密切沟通，双方不断地达成一致，而不是仅把需求文档作为设计指南来对待。
如果设计师收到的不是需求文档，而是产品经理绘制的一系列精致的线框图，也不要感到无奈。我们可以通过这些线框图去理解产品的本质需求、业务逻辑，再和产品经理沟通确认他的想法，然后彻底忘掉这些线框图，再重新去设计，而不是在原有基础上做简单修改。
如果产品经理直接要求设计师照抄竞品，设计师也可采用同样的方式。从竞品界面去理解业务、需求，再重新设计。
网友评论