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

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

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

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

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

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

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

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

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

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

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

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

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

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

比如我最近负责的产品,有一个预jǐng的需qiú,主要是zhēn对平台的异常数据进行预jǐng。

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

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

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

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

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

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

磨dāo不误砍柴工,前期需qiú确认越准确,需qiú的不确定就越小,后期修改和返工的概率就越小。

二、学会X和使用工具

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

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

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

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

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

什么是开发的思维方式呢?X是函数思维。所有的函数都由三部分组成:输入—方fǎ—输出。zhēn对某一功能,用户的输入是什么?经过什么样的方fǎ或liú程?最终输出是什么?

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

  • 输入:用户的账号、密码;
  • 方fǎ或liú程:请qiúX用户账号表,校验用户账号和密码;
  • 输出:返回登录结果,登录成功跳转到首页,登录失败则返回失败的原因。

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

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

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

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

第二,学会使用动态面板

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

当然,还是要根据X实事qiú是。例如有的系统对册刂除比较X,有的低泉限的用户只能新增,不能册刂除,也是有可能的。

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

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

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

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

其实对于异常liú程考虑得是否完整,才是对一个PM的X度的考验。

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

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

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

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

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

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

四、追根溯源,举一反三

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

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

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

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

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

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

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

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

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

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

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

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

还是举个我自己的例子。

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

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

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

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

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

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

相关方,简单来说就是跟你做这个项目或者需qiú有任意X的人。比如说你负责的是某XX的搭建项目,那么相关的人就至少有:

你的X,该X负责人,该X核心人员(实际使用你X干活的),开发人员,测试人员,设计人员。

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

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

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

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

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

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 都是写需求,高手和菜鸟为何差别这么大? https://www.xiongfawang.com/2189.html

常见问题

相关文章

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

分享本文封面