职场上，我们都很讨厌那种话只说一半，或者只说一句话的人。一样，我们也不希望自己成为这种人。那作为产品经理，碰到这种人怎么办？如何避免自己成为“一句话”的产品呢？
“一句话需求”，比较笼统的概述，这个不是产品管理中对于需求描述的简洁表达方式，不是那个，那个是有很强概括能力的，我们文本讲的是很简单的需求描述，让开发去做。
很多产品经理在开始的时候多少都会遇到，尤其是一些不太规范的公司，这种对于产品经理的专业成长就很差了，我开始做产品经理那会儿，对于需求文档这些，也不太懂，很多时候也是挺简单的，不会写，对开发就很不友好，也不利于自己的产品设计。
长此以往，只会“一句话需求”的产品经理一定会越变越差、越变越懒，直至被社会淘汰。
那么，为什么会存在“一句话需求”？我们该怎么避免这种呢？
我们今天就聊聊“一句话需求”的事。
01 何为“一句话需求”？
前面我们有简单提到，很简单的需求描述，简单到只有一句话，然后给到开发去做，天马行空，任凭想象。
产品经理作为产品的设计者，或者需求的接收者，你自己的想法、业务方给你的需求描述，可能一句话就够了，但是给到开发是不行的，更何况后面还有测试。
你的需求文档，这个功能需求，就一句话需求描述，这咋去做呢？
02 为什么会存在“一句话需求”？
关键应该还是规范问题，工作不规范。
具体表现：
团队的工作流程，产品经理接收需求就直接转述开发，没有审核；产品经理的专业，需求文档功底很差，不会那些专业描述，只懂得像业务方跟你提需一样；时间问题，排期太紧急了，来不及写需求文档，就简单跟开发说了；工作习惯，这个也挺重要的，规范、专业都是一回事，还有一种就是这个产品经理就是这样的习惯，不喜欢写需求文档。
03 “一句话需求”的影响
这里就是不好的影响了。
比如理解问题，你的一句话需求，开发可能理解成那样，测试可能理解成这样，最终实现的功能又可能是另一个样子。
比如效率问题，我们的工作，一定要为下游服务，这都是相辅相成的，给了下游更详细的信息，他们就可以更高效地工作，对于整个团队的产出就是正向的，如果我们只是简单的需求描述，开发还要思考很久，到底怎么搞，这种效率是很低的。
比如功能缺失，跟理解问题类似，做完了，最终发现还少了功能，又得返工。
比如成本问题，沟通成本、版本迭代成本、时间成本，这些都是，只要是前期不清晰，后面一定会出现多次沟通，一定要加多成本。
比如资源分配问题，需求优先级排期问题，尤其是对于开发和测试，产品经理把需求给到他们，他们对于需求不理解，就无法给出合理的时间评估，也就没法去分配当下的资源，优先级那些，都会影响需求开发进度。
最后一个就是项目管理问题了，产品经理是需要跟项目的，这种简单的需求描述，风险太高，很不利于项目管控。
04 如何避免“一句话需求”？
有问题解决就好了，刚出来，尤其在一些小公司的产品经理，规范和专业上确实有待提高，只要我们有了正确的方法，及时调整就行。
1）提升需求文档书写能力，或者原型图标注需求内容的能力，这应该是产生一句话需求最根本的原因，如果你可以写得很好，很容易描述清楚，就不会一直在用一句话需求了。
需求文档的书写，可以参考下之前发过的文章：
当开发和测试不再吐槽你的需求文档之后…
2）提升需求调研能力，你在跟业务方聊需求时，透过现象看本质，了解他们背后的业务逻辑，分析出真正的需求和痛点，确保功能设计依赖于此。
需求调研，可以看看这篇文章：
从0到1搭建电商系统，你该怎样去调研？
3）提升需求管理能力，有些时候也会因为需求管理问题，疏忽了需求文档，比如太赶了，资源协调不合理，排期问题等，这种时候就需要提升你的需求管理能力，或者项目管理能力，多想想。
4）加入需求评审环节，或者说工作规范，如果你们的工作流程是很规范的，你的一句话需求是过不了评审的，开发不会接受，那你必须认真书写。
5）要接受版本迭代，“罗马不是一天建成的”，微信上线那么久了，还在迭代，所以我们要接受，需求是可以拆分的，不需要一次性完工，这样就可以把你的工作压力减小，需求上线的周期拉长，你就有更充足的时间好好设计产品功能，好好写需求文档。
6）其他的一些，比如培养用户的系统思维，培养开发和测试的业务思维，多注重细节，需求多和相关者一起沟通等，都是可以避免这种情况发生的。
专业的人要做专业的事，既然选择做产品经理，就要把该做的做好，认真写需求，踏实做设计。
希望简单的文字对大家的产品学习有些帮助。
题图来自Unsplash，基于 CC0 协议。