Skip to content

Latest commit

 

History

History
78 lines (40 loc) · 4.2 KB

section2.md

File metadata and controls

78 lines (40 loc) · 4.2 KB

需求分析/评审

对于有经验的产品经理来说,在做任何需求的时候,都会计划的足够细致,落实到一个功能点。更好的是能够出原型稿。之后可以通过原型来对每一个功能点进行逐一核对。

对技术来说评审的目的有三个

  • 一、明确所有的需求点,避免返工;
  • 二、确认技术可行性,避免延期或者后面再修改需求;
  • 三、确认工期,是否需要分期开发;

博客需求评审

针对产品提出的每个需求,我们都需要仔细核对,尽量避免歧义或者沟通不畅。下面我们逐条来分析。

用户端部分

  • 需要能够通过搜索引擎搜索到博客内容,进而来到博客

技术上来说这个属于SEO的部分,只需要提供Sitemap到搜索引擎即可。同时页面需要对爬虫友好。需要跟产品明确的事情是,技术上无法保证一定能够通过搜索引擎搜索到博客,这最终取决于搜索引擎。

  • 可在博客中进行关键词搜索,然后展示出文章列表

需要明确搜索哪些字段,比如title,标签,分类等。如果需要全文搜索,就要考虑数据量的问题,如果数据量大,就不能直接使用MySQL的LIKE语句,需要增加Elasticsearch之类的技术栈进来。

  • 能够根据某个分类查看所有关于这一分类的文章

对于分类,要明确的是有没有子分类这样的需求,如果有子分类,那子分类的文章要不要在父分类下展示。

  • 访问首页需要能看到有新到旧的文章列表,以便于查看最新的文章

首页排序从新到旧没问题,是否有置顶的需求,另外是通过分页的方式展示列表还是,一个页面可以不断加载的方式。每个页面/每次加载多少条数据。

  • 需要能够通过RSS阅读器订阅博客的文章

需要提供rss格式数据的页面

  • 要能够对某一个文章进行评论

是否需要前台(用户端)有查看所有评论的页面。

  • 能够配置友链,方便与网友进行链接

友链在前台如何展示,只是一个页面还是一个列表页

作者端需求

  • 博客后台需要登录后方可进入

是否有多用户登录的需求?如果有,那么用户之间权限如何划分?

  • 能够创建分类和标签

跟上面问题一样,是否有多级分类和标签的情况,如果有,需要明确,父级分类或者标签是否包含子级所关联的内容。

  • 能够编写文章,以Markdown格式编写

作者编写文章时,有哪些是必填的,在网页上编写是否需要实时保存

  • 能够配置导航,以便引导读者

导航是否是指分类?是否包含标签?需要明确的需求。

  • 作者更新后,读者能够收到通知

博客的整个需求中并没有读者的用户系统,无法对读者进行实时通知。但是可以考虑增加邮件订阅功能。通过邮件的方式通知读者。需要产品上明确邮件的内容格式,以及作者是否需要控制发送邮件的开关。

评审之后

其实在实际的需求评审中,不需要每个需求点都抛出问题来确认的,因为大部分都是专业的产品经理,知道用户想要什么的同时也知道技术能实现什么,主要是基于过往的经验。所以这类产品经理会给出很明确的需求,配合起来和比较默契。不过也不能太相信产品经理,毕竟术业有专攻。

对于不太懂技术,又没有太多经验的产品经理来说,上面的阶段必不可少。

经过这么一轮的问答,产品经理也会在产品文档上更加明确自己的需求点,最终的描述应该是包含了技术所提问题的解答。

另外有一点需要注意到的是,对于PM自己也不是特别明确的功能点,比如涉及到技术方面的,开发人员应该能够根据以往的开发经验以及技术积累,给出合适的建议,在满足同等功能的情况下,让技术实现上更加容易。但是,记住一点,用户需求是第一位的,技术复杂度是第二位的。

在这之后,我们应该能得到一份详细的需求列表。下一节我们开始对需求进行拆分,把需求转为技术上需要实现的功能点/技术点。