如何更清晰的说明产品规格

围绕着产品规格,可以归纳出很多的主题,我们通常会接触到以下主题-产品需求(Product Requirements/PRD’s),市场需求(Market Requirements/MRD’s,),商业需求(Business Requirements/BRD’s),功能需求(Functional Specs/FSD),等等-这些主题在内容上差异很大(编者注:这些不同的文档不是为同一个目的服务的,但是,有时候,他们被合并成了一个,从而使它们本身的差异性丧失掉了),例如细节的描述程度,当然还有产品规格本身的质量说明,这些内容都没有了。甚至在表现形式上也是五花八门,许多人用MS word文档来记录,而有些人则是用电子表格,还有一些人是通过wiki站点来记录,当然也有使用那种商业需求管理工具来记录的。

我看到过一些真正好的产品规格说明,但更多的却不尽如人意,很多人花了很多的时间去写产品规格,但是他们却很少自己去看,他们很少在里面提供必要的细节,标注难以解决的问题,或者记录他们需要进行讨论的问题,更重要的是,他们把现实存在的产品规格记录的过于简单,这样会传递给管理者和产品团队一个错误的信号,就是所有事情只要开展就可以了,不会有什么问题的。

我个人的观点是,产品经理的主要职责就是确保传递给研发团队一份能够详细描述出产品为什么会成功,在过程中,我们不得不去面对那些薄弱环节,并且应该如何去应对的产品规格文档。

一份好的,有用的产品规格说明,我认为应该包括以下因素:

1、这个规格说明必须能够描述出完整的用户体验,不但要包括产品需求,而且还要包括用户交互和视觉设计。现在,我从心眼里希望,每个产品经理都要认识到产品需求和设计之间的关系是相当的密切。

2、产品规格说明须准确反映出软件的表现行为,我们需要承认,文字和漂亮的图片在描述这种行为的能力上是非常有限的。

3、产品规格必须说明要面对几类关键读者,研发人员,QA,客服,市场人员,网站运营,销售,例如,以上说到的这几类人员,对于产品规格的说明都有不同的需要,产品经理就要想办法用一种大家都能接受的形式进行沟通。

4、产品规格是会变化的,一旦进入到研发阶段,你会发现产品规格的变化频率会出现戏剧化的变化,而这种变化会减慢研发的速度,而且会出现新的决定和意见,因此,产品规格必须改变来适应最新的决定。

5在产品规格实现的过程中,会有一些依赖于人工的工作,例如需求优先级列表,线框图以及实体模型等,但是,这需要一个独立的,良好的产品规格记录,来减少歧义,避免版本的混乱。

以我的观点,仅有一种产品规格模式能够实现这些需求,这就是高保真的模型。

这里的“高保真”是指能够对用户体验进行的一种真实的体现。除了最微不足道的用户界面,我并不推崇“纸面原型”。随着现在可利用的工具越来越多,现在要制作一个产品的“高保真”模型是越来越迅速、简单、廉价,这让我们没有理由不去用它。当然,这仍然就是一个模型,因此,只要用户体验是仿真的,那么,虚造一些数据的流程也是可以的。

在过去的几年里,我个人的思路从仅去为一些关键的用户体验部分塑造原型,逐步转变到今天,我支持用原型去塑造每一件事情,包括所有的页面/屏幕,所有主要用户的情况。当然,现在仍然有一些错误的环境和角落,无法用原型来塑造,但是,拥有一个真正明白即将要研发的产品,并且能够为这个产品塑造原型的真正意义上的产品团队所带来的益处而言,这些成本的增加都将显得微不足道。

事实上,你仍然需要对产品原型进行补充和完善,在一个产品原型中,产品会有好多不容易表现出来的行为,例如产品的必要条件(如:可靠性、可执行性,可扩展性等)或者产品平台需要的条件(如:安装条件、支持的浏览器版本列表等)。此外,还要通过描述最重要的使用流程来作为使用实例的补充,这对补充和完善产品原型,也是有用的。

如何能够更好地不断地完善产品原型的元素仍将会是一个问题。我真正想要的是对产品原型的注解,但是在这种技术普遍应用之前,我宁可使用wiki或者其它的在线信息交流站点。最大的原因是我希望产品团队中的每个人都知道能在那里随时找到最新的答案,而不是由个人随处放置版本不同的文档。当产品规格发生更新的时候,去发布一个Q&A,设置一个可自动提示的email,这是非常容易的,这样,就可以对最新的决策进行跟进。

只有大部分的产品规格忠于产品原型,才能作为功能需求、信息架构、互动设计以及用户体验视觉设计的代表。

除了上面说到的,产品的“高保真”原型可以带来的好处外,我认为还有一点重要的就是,它不像纸质文档,这个模型是可以进行测试的。你可以把这个模型放到目标用户的面前,确保他们能够勾勒出是如何使用你的产品的(可用性),以及评估出他们是否会对你的产品继续关注(渴望度)。直到你的原型在经过这两次测试后,你才可以把每一个产品规格交付研发部门。如果你的产品已经进入到QA或者beta阶段的时候,那么,再进行这样的测试,就为时已晚了。

如果你能去尝试,并建立一个既定功能和用户体验的产品“高保真”原型,我相信,你的产品团队绝对会喜欢上它的。当工程师们拿到的是一个描述的非常清晰、有效的即将开发的产品规格说明时,他们会感到胸有成竹的,如果他们对一些事情还感到困惑,那么,他们也能在任何时候提出来。这样,即使是QA的工作,也会变得相对容易些,因为,他们知道当他们去测试实际的产品时,会发生什么。而对于市场、销售以及客服人员来说,他们也能够在产品周期的早期,就能够很好的去理解产品。

同时,你还会发现,你的上司们也会非常喜欢它,因为,这个原型会让投资商、合作伙伴以及顾问明白你在做什么,这要比只让他们去看PowerPoint要更有效率。

对于大多数团队来说,最大的惊喜就是可以用这种方法来建立产品规格,而这将大大缩短产品进入市场的时间。是的,我知道这或许听起来不符合常理,不明白为什么进入市场的总时间会加快,要回答这个问题,就必须进一步了解,通常在软件项目中,会发生什么情况。

在软件项目中,比较典型的情况是产品规格过于简陋(不完整、无条理,缺乏测试等),因此,在这个过程中,团队很少能发现尖锐的问题以及重要的细节,并对这些进行确切的标注以及考虑解决方法,这样,就会在研发期间,团队不得不去疲于应付各种预料之外的问题,另外,还有来自于内心的不安(规格的不断变化使研发过程不得不拖延时间,以致使他们疲惫不堪),或者是研发人员只能依靠自己的想法来尽力做好工作,这样,产品开发的过程就是一团糟,最终不得不多次更新产品的发布时间。

因此,我真诚的希望你,产品经理,在做下一个产品的时候,去尝试一下这种方法。去和你的设计人员一起工作,建立一个新产品的原型,要比花几周时间去写一个很少让人一目了然,并且无法测试的50页的文档要好的多。然后把这个原型展示给你的目标用户和产品团队,当然,你肯定会进行几次调整(这也要好于研发人员花几个月时间,最终却做了一个糟糕的产品),当你得到最终正确的模型,确定用这个模型作为进行产品研发基础的时候,你就会看到一切都发生了变化。



分享到QQ 分享到微信 分享到微博

0 条评论

发表我的观点

取消

  • 昵称 *
  • 邮箱 *
  • 网址