独角兽企业重金招聘Python工程师标准>>>
“这个需求做不了”，这或许是一句每个产品经理都曾经听到过的话吧。其实，我觉得，大部分的情况下，那个需求不是做不了，而是没必要。造成这个问题的根源就是，产品经理与技术人员之间的沟通有问题。要求每个产品经理都精通前端后端的各种技术，以此来解决与技术人员之间的沟通问题显然是不太实际的。但是，产品经理完全可以尝试建立一套需求规范，只要技术人员也认可这套规范，就可以很大程度上解决沟通问题。
我一般会在以下三个方面来规范自己的需求。下面，我以技能树为例分享下这些需求规范。
一、需求是否与现有产品架构兼容
在建立包括数据库在内的产品架构时，应该充分考虑到以后的弹性需求。而一旦产品架构确立之后，以后再提需求，就务必要保证与现有产品架构的兼容。比如，根据已经明确的产品逻辑，技能树App后台数据库里的表大多是与技能点与话题讨论相关的。代码也都是围绕着这两个体系的。如果说，突然提出想做一个用户之间互相关注或互相发私信的需求，这无疑就是个做不了的需求。再比如，在技能树App现有的代码中，技能点的具体介绍内容是从服务端取出来的，而技能点本身的命名和图标则是写死在本地的。所以，想在不更新版本的情况下更新技能点的名字或图标，自然也会是个做不了的需求。
二、需求背后是否有完整的数据论证
有句话说：兵马未动，粮草先行。远离战场的人也许会认为打仗就是指挥千军万马上阵杀敌；而亲临战场的人则会知道，保证后勤供应也许是件更重要的事情。同样得，产品新人也许会以为产品经理的工作就是提出一个又一个的功能需求，但实际上，需求提出前的数据论证，需求提出后的效果评估才是更重要的事情。有了数据论证，技术人员就知道自己工作的目的什么，又会达成怎样的成果。对于缺乏数据论证，带有明显个人偏好的需求被技术人员用“做不了”的理由拒绝其实也并不是一件很难理解的事情。
三、需求涉及的各种细节是否已经考虑充分
一个功能需求的背后往往附带着许多连带的子任务。比如说，技能树App中引入了“话题讨论”的概念。这个需求的背后就有四个连带的子任务：第一，因为“话题讨论”是从服务端查询的，那么无网络的情况下要如何处理？第二，因为“话题讨论”是UGC（User-Generated Content）的内容，由用户来提供。那么，当一技能点下没有任何讨论的空状态要如何处理？第三，同样因为是UGC的内容，用户会需要有管理自己的“话题讨论”的需求。类似“草稿箱”、“已发布的讨论”这样的管理机制要如何建立？第四，为了鼓励用户生产内容，需要有反馈机制。最简单的反馈机制就是，当有人赞了一个“话题讨论”的时候，作者应该要能够收到通知。类似这样的反馈机制要怎样建立？以上所说的这些子任务或许并不会构成技术难点，但却会耗费大量的时间和精力。如果没有对这些子任务的详细描述，技术人员很可能就会给这个需求打上“做不了”的标签。如果冒冒然接受了，一个最实际的问题就是，如果因为对子任务没有完整规划而造成了项目确定后发生延期，这个责任应该要由谁来负。
