起点学院课程

都是写需求,高手和菜鸟为何差别这么大?

41 评论 2.1万 浏览 174 收藏 20 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

无论是互联网产品还是产品项目,所有这一切的开端都始于需求分析,一份好的需求文档往往是项目成功的先决条件,对一个产品经理或项目经理来说就显得尤为重要。但是,同样是写需求,不同的人写出来效果却截然不同。相比产品菜鸟,高手究竟在哪些方面表现得更为突出呢?

  • 同样是写需求,为什么有的人能一次过,而有的人改了又改,甚至还要推倒重来?
  • 同样是写需求,为什么有的人考虑全面,而有的人丢三落四,直到评审的时候被怼得体无完肤?
  • 同样是写需求,为什么有的人简单易懂,而有的人长篇大论,大家却看不懂?

这种情况在我们工作中经常会看到,优秀的需求文档和拙劣的需求文档,就像产品经理的脸面。

那么,怎么才能写出一份漂亮的需求文档,结合这几年的工作总结,和大家聊一聊

一、准确理解需求,才能有的放矢

写需求的大忌之一,就是自嗨。

很多自嗨型选手,自傲型的,会觉得自己的理解才是最完美的,用户提的需求或者场景,都是欠考虑的。

他们不屑去找用户求证,也不会使用简单的方案先验证需求,而是完美主义的妄想一步到位,他们信奉乔帮主的一句话:用户并不知道自己需要的是什么,直到我们拿出自己的产品,他们就发现这是我想要的。

自卑型的,他们不愿意找用户,害怕找用户求证。因为担心自己没有理解用户的需求,会被其他人看不起,怀疑自己的能力。

所以即使不理解,也不愿意找用户求证,但是又要交差,最后就只能按照自己的理解硬着头皮上。

不能准确理解业务场景,就敢写需求的,最后都会成为烈士。理解了需求是1,后面所有的文档,开发和测试都建立在这个1上,没有1,后面再多的0也白搭。

准确理解需求,其实就是要理解需求背后的使用场景,可以使用常用的5W1H框架。

  • what:用户的问题和需求是什么?
  • when:用户什么时候会遇到这样的问题?
  • why:用户为什么会遇到这样的问题?
  • where:用户一般在什么地方遇到这样的问题:
  • who:遇到这个问题的用户是谁?用户群体有什么特征?
  • how:用户当前是怎么解决这个问题的?

比如我最近负责的产品,有一个预警的需求,主要是针对平台的异常数据进行预警。

预警一般就分为三步:预警的数据从哪来?预警的规则如何设置?产生预警后以怎样的形式发送给谁?

前两步我跟用户(公司的业务方)都对的比较清楚。而在第三步通知上,我就犯了理所当然的错误,陷入了自己的想象中。

我的想法是,产生预警的消息通知因为需要根据模板来配置的,这就有点类似于微信消息通知,都有固定的模板。

所以我想当然的认为,我们也只能通过设置几个固定的模板,然后根据产生预警的内容往模板里面填充信息。

但实际用户的需求并不是这样,固定的模板不能满足用户的需求,用户不仅需要预警消息,还需要自定义通知哪些信息给哪些用户。

所以最终的后果就是定好的开发计划需要重新制定,需求需要重新评审。好在还没有进入开发,只是耽误了2天的时间。如果是在验收的时候发现这个问题,那简直就是灾难了。

磨刀不误砍柴工,前期需求确认越准确,需求的不确定就越小,后期修改和返工的概率就越小。

二、学会制造和使用工具

确认好需求以后,就可以着手开始写文档了。

需求文档本质上是将我们脑子里对需求功能的构想,准确的传达给设计师、开发和测试同事。

那么,有哪些方法能提高信息的传达率呢?总结起来,大概有三种方法:

第一,换位思考,站在开发的角度思考问题

既然我们主要是写给开发同学看的,那么就应该用他们熟悉的思考方式来撰写需求文档。

什么是开发的思维方式呢?答案是函数思维。所有的函数都由三部分组成:输入—方法—输出。针对某一功能,用户的输入是什么?经过什么样的方法或流程?最终输出是什么?

例如,登录功能,用户输入账号和密码,点击登录按钮,这过程经过了哪些?

  • 输入:用户的账号、密码;
  • 方法或流程:请求后台用户账号表,校验用户账号和密码;
  • 输出:返回登录结果,登录成功跳转到首页,登录失败则返回失败的原因。

因此,功能的详细需求描述,应该包括:

  1. 要写清楚功能的输入是什么?输入的参数有哪些?是否是必填,参数的字段类型是怎样的?
  2. 调用什么样的方法或流程
  3. 输出是什么
  4. 异常情况有哪些,如何处理?

其中,调用的方法或流程,我们可以使用流程图来对功能的数据在各个系统之间的流转做出精确的刻画。如果涉及到多个角色或系统,可以使用泳道图来进行描述。

异常情况的梳理,后面会具体讲到。

第二,学会使用动态面板

字不如表,表不如图。将我们脑子里对需求和功能的构思用原型图的方式展示出来,这是最直观的方式。

对语言的理解,由于各自的理解水平、阅历经验等不同,一千个读者就有一千个哈姆雷特。

用原型图画出来的保真图,能够清晰的告诉大家,我们最终想要实现的效果,页面自己的跳转是怎样的?同时在我们绘制原型图时,也是我们对需求的进一步梳理。

第三,搭建专属的高保真组件库

写需求的颜值和效率如何兼顾?怎样又快又美观的完成需求文档?答案是高保真组件库。

这里的组件库,不是市面上流传的那些通用的组件库,而是专属于我们所负责产品的组件库。

通用组件库因为是通用的,所以每次我们使用这些组件库时,都还需要对这些组件进行一些个性化改造。

所以为了进一步提高我们的效率,可以在这些通用组件库的基础上,进一步个性化为自己所负责产品的组件库。

组件库搭建成功以后,写需求就真的是搭积木一样了,不仅美观而且效率很高。

通用组件库可以在antidesign上下载一份。当然,如果你有一位交互设计大佬,也可以求她帮你做一份,就看你的本事了~

如果是自己来设计组件库,可以参考制作PPT的一些基本设计原则,这些都是相通的。

这里简单介绍下美国著名设计师Roibin Williams提出了四个关于设计的基本原则:

  1. 重复,作品中的一些元素可以在整个设计中重复出现,可能是某种图案、颜色、文字、空间关系等,重复促成统一;例如一些重复组件的样式和设计,弹窗、提示、输入框等
  2. 对齐,任何元素都不能在页面上随意安排,每一项都应当与页面上的内容存在某种联系。页面上的组件都应该才有某种方式对齐,组件与组件见的间距也要一样。
  3. 对比是为作品增加视觉效果的最有效途径之一,同时也能清晰地起到区分作用。例如:标题、正文、说明注释等字体的大小应该有层次感,相同类型的文字格式,包括字体大小,加粗/倾斜,颜色等都应该保持一致
  4. 亲密性原则是指,将相关项组织在一起而使他们之间产生凝聚力,因为物理位置的接近意味着存在关联。文字建议使用冷色调,文字颜色和背景色要对比明显,例如黑底白字,蓝底白字,白底黑子等。只有一些特殊的信息使用鲜艳的提示,例如报警、注意、异常情况等

三、增删查改显算传,尽量做到MECE

我们写需求的时候总是会遇到考虑不周全的情况。

首先要说明的是,切忌不要完美主义,没有人总是一次就能把所有因素都考虑在内。

关于需求的完整度,我们尽力即可,而且这其实是非常吃经验的事,我们可以在工作过程中多总结。

MECE虽然做起来很难,但是做得好的话,它其实是一件令人上瘾的事情。那种算尽一切的感觉真的很棒。

尤其是在需求评审,研发、测试等同学问什么问题,你都能回答出来的时候,不仅会给人一种专业的感觉,而且自己也会获得一种极大的成就感。

给大家分享一些写需求时,可以提高需求完整度的“7字真言”:增删查改显算传。

就是新增,就是删除,就是查询,就是修改,增删查改是形影不离的四兄弟。

所以在设计功能的时候,有其中之一,你就要考虑其他三个有没有漏掉。

当然,还是要根据业务实事求是。例如有的系统对删除比较敏感,有的低权限的用户只能新增,不能删除,也是有可能的。

就是显示,以怎样的形式呈现给用户。列表,还是图形,弹窗还是新的页面,文字展示不完怎么办?数据太多是否需要翻页?数值数据使用哪种格式?最终,还是要根据具体的业务来。

就是计算,常见的就是功能的某些字段的值是如何计算得来的?最常见的就是数据埋点,数据的来源,指标的计算方式等

就是传值,该功能前后端的数据交互是怎样的,中间的数据流转涉及到哪些系统。例如支付功能,就至少涉及用户账号系统,钱包系统,第三方支付系统等。

除了这些,还有写需求经常会犯的一个错误,就是只考虑正常流程,不考虑异常流程。

其实对于异常流程考虑得是否完整,才是对一个PM的专业度的考验。

常见的一些异常,供大家参考:

  1. 当功能有限制时,就需要考虑两头的极端情况,例如活动是有时间限制的,就需要考虑用户在参加活动时,刚好超过时间限制,此时该如何处理?
  2. 输入框,支持哪些字符,中文,英文,数字。如果支持特殊符号,具体支持哪些符号,这些都需要提前定义好。输入框的长度限制,最大最小支持多少字符,输入时超过最大长度怎么办?字段字符太长展示不完怎么办?
  3. 批量导入文件,文件支持哪些格式?文件大小有哪些限制?是否一次性支持多个文件导入?如果支持多个文件导入,有个别文件格式不正确或大小超出限制怎么办?文件的内容不符合要求怎么办?
  4. 有权限限制,正常情况下操作权限范围内的功能没问题,但是在操作过程中,如果没有权限了,此时该怎么处理?如果对同一个页面,有多个用户拥有编辑权限,那么同时编辑的时候,如何处理?
  5. 定时任务型功能,例如预警任务,预警任务的运行频次是怎样的?是否允许重复发送预警?预警消息发送失败了怎么办?定时任务启动失败怎么办?
  6. 页面没数据时该怎么展示?这个是比较容易被遗忘的点,很多页面的缺省页都是需要设计师设计的,因为放一个空白页面太不友好了,不知道是正在加载,还是没网,还是出bug了。
  7. 网络异常如何处理?网络弱的情况如何处理?(APP比较常见)

异常情况,其实可以多跟测试同学聊聊,他们才是真正的专家~

如果能把以上7字真言和常见的异常情况都考虑清楚,可以说就是一个合格的需求文档了,更进一步,就需要从整体上进行设计,当前的设计要为后续的迭代和完善做好铺垫。

这个比较吃经验,我们在工作的过程中可以多总结,针对一些常见的功能复盘他们的迭代路径。

这样积累下去,以后一看到类似的需求,就能做到胸有成竹了。

四、追根溯源,举一反三

如果是新需求,要举一反三。简单来说,就是在细化需求的时候,要把和这个需求相关的其他功能点都考虑在内。

我做这个需求会影响到哪些功能模块,需要哪些功能模块配合?

举个我做过的APP的例子来说,为方便理解,先交代下背景:

我们的APP里有代驾和打车两项技能,打车已有,代驾需要新增。

打车和代驾都是属于先享受服务,然后再支付的类型。那么,为了防止白嫖,我们采取的是先冻结部分用户在APP账户内的金额。

原来只有打车的话,那么冻结金额就只有打车的,现在增加了代驾,也需要冻结金额。

那么,在写代驾订单逻辑的时候,就需要考虑到这部分冻结金额的逻辑,该如何处理,才能不影响打车。

冻结金额就需要从原来的只有打车,变成需要区分为打车和代驾。其实不止这些,代驾还涉及到订单后台,账单系统和钱包系统的修改,都要考虑到。

如果你没考虑到打车这个已有功能,就会让别人对你的专业能力产生质疑,三番几次就会失去开发的信任。

所以,我们在完善需求的时候,不仅要关注当前的需求,还要抬头看看四周,与这个需求有关的还有哪些其他的系统,这些系统要相应做哪些修改,都要考虑周全。

如果是功能优化,那么不仅需要考虑与其他功能的关系,还要考虑与自身的关系。

简单来说,就是要考虑以前数据,功能和交互的兼容性。我在做后台的时候,吃了很多次亏。

还是举个我自己的例子。

最近我们对账单进行了升级,原来的账单数据非常简单,就是对账单数据的简单罗列,没有筛选功能。

在账单升级后,数据结构发生了改变,增加了可按照业务类型(打车和代驾),支付时间和支付方式三个维度进行筛选。

当时我做的时候,没有考虑到一个重要的因素,就是要对以前的账单数据做兼容,导致账单升级以后,只能看到升级以后的数据。

这样就只能后面再补需求进行处理。虽然这没有造成很大的影响,但是如果是后续处理不了了,那就是真的大麻烦了。

所以,我们在迭代需求的时候,一定要考虑这个需求的来龙去脉,注意对这个需求以前的数据,交互方式等进行兼容。

五、注意考虑相关方,尤其是B端

相关方,简单来说就是跟你做这个项目或者需求有任意联系的人。比如说你负责的是某业务后台的搭建项目,那么相关的人就至少有:

你的领导,该业务负责人,该业务核心人员(实际使用你后台干活的),开发人员,测试人员,设计人员。

如何识别这些相关方呢?可以从是否参与项目与所受影响两个维度来区分。也可以按照相关方类型来区分。

比如:上游供应商,下游客户,中间有老板,领导,开发团队,测试团队,设计团队,运营团队,业务团队等。

将相关方识别出来之后,我们就知道哪些相关方是需要我们重点关注,哪些相关方是无关紧要的。

毕竟我们的精力是有限的,我们必须把80%的精力用在关键的20%的人身上,才能保证效率最大化。否则面面俱到只会把自己累死,吃力且不讨好。

最后,虽然我们总说不要成为功能或者需求经理,但是过硬的写需求的能力,是决定我们底线的关键,只有基础夯实,才能建起高楼大厦~

 

本文由 @Jarvan 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 很受用 学习了

    回复
  2. 感谢作者,文章对于B端产品新手帮助很大,可能产品原型这方面不同公司策略不同吧,迭代周期快的公司可能只需要尽量保真的原型就好了确实好用但是耗时嘞

    回复
    1. 有帮助就好,原型不需要强求,哈哈哈,主要是业务逻辑,流程和异常情况的考虑

      回复
  3. 文章写的很好,感觉很有帮助,动态面板我也经常用,但是确实存在出现需求改动时,改起来会比较麻烦,不过可能就是习惯吧,从交互的演示上动态面板我觉着还是很好的

    回复
    1. 动态面板尤其要注意命名,不然设置动效或者修改的时候,就更痛苦了

      回复
  4. 看大家在说动态面板,这种感觉还是要看公司看业务看项目。如果是快速迭代的功能型需求,思维导图/流程图可能更适合;如果是像要新建一个App产品,这时候原型动态面板可能比较合适。楼主写的挺好的,每个人习惯也不一样,赞一个。

    回复
    1. 是的,看公司业务和团队习惯吧,我现在的团队文档用的是石墨,就不太需要动态面板了~

      回复
  5. 对于新手而言干货挺多的,很受教。可是为什么有些人就喜欢针对某个词挑刺呢?说话冷嘲热讽的,很不解。。。

    回复
    1. 有帮助就好,无需在意,哈哈哈~

      回复
  6. 下面那些说不用动态面板的多半是些混日子的low品经理
    楼主不用太在意,搞不好他们连动态面板怎么用都不会 🙂

    回复
    1. 习惯不一样吧~

      回复
  7. 心态好点不行么,别人写个文章作为同行取其精华去其糟粕,为何就得跳出来杠,有自己的看法也可以自己写几篇然后发表出来让大家共同学习一下,这种心态平时是怎么和开发友好沟通的。

    回复
    1. 感谢您的理解~

      回复
  8. 我也是看到要用动态面板那块就震惊了,作者做没做过产品啊….首先不光说需求量给不给你时间去做动态面板,而是看得人根本不去点击你做的交互,还得跟他解释,一般技术都喜欢直接看不带交互的原型,而且动态面板一旦要大改就会非常麻烦,耽误时间效率奇低…..

    回复
    1. 我来稍微解(狡)释(辩)一下,第一,我做过产品,3年经验吧,可能跟您比还是菜鸟;第二,没有时间做动态面板我觉得这个不是理由吧,写需求文档也要花很多时间啊,这个看产品的个人习惯,以及和团队的磨合吧;第三,别人根本不去点击,你就不做吗?那需求文档开发也不看的啊,那咱们也不写了吗?动态面板不是给开发去点的,我觉得主要作用是方便我们自己梳理需求之间的逻辑,以及我们在需求评审的时候比较方便演示和大家的理解;我觉得主要还是看个人习惯和团队的磨合吧,文章里也主要是我自己的习惯了,看看就好~

      回复
    2. 其实最终还是看团队跟公司。干了7年多产品也就最初一年多的公司写过文档,其他的公司技术直接说不要写文档,我们不看,所以直接原型后上禅道,效率还高,所以并不是通过文章上面几个简单的点来区分菜鸟跟高手,产品其实不分高不高手,实用效率才是王道,最后还是看公司财力及业务,产品做的再完美再敬业,没财力没业务一切都是空谈…… 😎

      回复
    3. 动态面板这些适合给老板和客户演示demo,实际给技术的需求文档我觉侧重点应该在业务流程、逻辑、状态、异常这些 😎

      回复
    4. 您说得对~

      回复
  9. 赞一个加油

    回复
    1. 谢谢~

      回复
  10. 菜鸟文 反面教材案例

    回复
    1. 跟大佬您没得比啦

      回复
  11. 产品经验6年,看到这个动态面板就没有兴趣往下看了,实际用户量大,需求多的做不完,你还要高保真???????

    回复
    1. 确实不太适合大佬看

      回复
    2. 比如说预警功能,先搞明白的绝对应该是什么是预警,为什么要预警,预警的目的,一切需求都要围绕目的去拆分拆解

      回复
    3. 所谓预警,预见而发出警告,用户是遇见了什么问题需要预警,预警需要什么内容(举一反三,产品需要有拓展思维),最后再考虑预警用什么方式输出,搞明白的绝对应该是什么是预警,为什么要预警,预警的目的,一切需求都要围绕目的去拆分拆解

      回复
    4. 一切的需求都是为了解决具体的问题,有了问题就有了目标,就方便后边去分解目标,拆解需求。

      回复
  12. 抽点碎片化时间看看碎片化知识,哈哈哈哈

    回复
  13. b端比较多的是公司内容人员,建议将操作岗、管理岗分开,分离财务查看需求和业务查看需求。这样会减少需求冲突,同时为实现操作、流程的自动化做铺垫;

    回复
    1. 这些主要还是看公司的具体业务情况,有的公司财务和业务的系统是分开的,有的公司是一个系统,是通过角色来控制功能和数据权限

      回复
    2. 只能说不建议这样实现,这样实现的缺点在于未来的拓展能力会很弱而且后端系统的终极目标就是自动化处理,业务与财务角色在管理职能和诉求上是有差异的。如果在一个系统靠角色来处理的,公司小就算了,但凡上了规模,这方案一定会被推倒。

      回复
    3. 不通过分角色分配功能的话要怎么分配?

      回复
  14. 收藏学习

    回复
  15. 旧数据处理是经常容易忽略的一个点。曾经就翻过一次车,业务部门对现有的制度进行的改变,需要技术上的改变,当时完全按照业务部门需求实现后,发现有30%左右的长期用户一直使用的是老版订单以及订单下的旧业务制度,一刀切的改动让我头秃了好几天,当然这也不是一个产品经理能够决定的(除非你的决策权已经很大了),旧数据处理建议以多向业务部门沟通为主,比较产品经理再熟悉业务也不会比一线业务部门了解业务流程和制度边界。但是忘记做旧数据处理那就是产品经理的职能失误了。另外,关于B端产品的,有一点很重要就是一线业务人员的需求,往往是以个人利益出发的,而B端产品往往是一个工具型的产品(对现有公司的业务做技术抽象化、和业务边界技术化),所以在迭代的时候,往往你的实现和一线业务人员的需求的相背的(不用怀疑自己,B端产品是公司的产品,大部分功能要代表公司的整体利益)

    回复
    1. 非常赞同您说的!

      回复
  16. 产品做久了,不怎么用动态面板了,因为容易遗漏关键事项。

    回复
    1. 这个可以用来演示,还是很形象的

      回复
  17. 写得很好,受教了 😆

    回复
    1. 谢谢~

      回复
  18. 写文章也是做产品,这也是好文,但是建议多一些图文互动,吸引读者。长篇大文很难看完··· ···

    回复
    1. 有点懒了,谢谢建议~ ➡

      回复