产品经理的“甩锅”行为对外包项目开发流程的影响

发表时间: 2019-01-16 14:40

产品经理在工作中如何避免背锅?先做好这三方面:业务逻辑(也有可能是产品形态),确定我们做什么;原型文档,确定我们怎么做;UI设计,确定未来项目的“模样”。

“背锅”这个词,对于产品经理并不陌生,身为产品,每天都要背不同的锅。甚至有些人还会找一些不明不白的锅飞过来,如项目中的收款账号不对,代码出现bug等等问题,似乎项目中遇到什么问题,只要甩锅给产品经理就对了。

产品经理能否不背锅,答案似乎是否定,因为产品经理对产品负责,产品出了问题都要找产品,这句话听起来似乎并没有错。

产品经理能不能甩锅,答案似乎是肯定的,产品经理工作性质决定着需要大量的资源,并且需要各个资源之间的协同,需要各个资源之间的利益平衡。任何资源之间出现问题,都会导致项目不能正常进行。理论上知道找到会出现问题点,就能甩掉一些锅。

如何找到这些点,或者说如何避免这些坑?最好的解决方案就是流程。在关键的点确认某件事情,而确认的结果,是开启下一个进程的前提。

流程的是否通畅健康,决定着产品的成败,也直接关系到产品经理的工作成果。产品经理是流程成是直接受益者。一个健康的流程实际上是对产品经理最好的保护。如果一家公司完全没有流程。那么产品经理需要做的是,建立流程或者离开。

今天聊聊如何“甩锅”给业务,及项目前期的流程。这里有一个限制,我说的一切都是围绕着外包项目进行的。

抱歉本人只做过外包项目,而且还不保证是否专业。本文目的在于抛砖引玉,希望听到不同的声音和批评的意见。

一、确认产品形态和业务逻辑,确认我们要“做什么”

在项目立项之初,或者在产品立项之前,产品经理首先要明确项目的产品形态。什么样的产品形态能够帮助客户解决现有的问题。这样在需求获取之初就可以确定下来。有很多项目一开始是做微信公众号,结果做着做着,就做成了APP。

确认产品形态可以通过多个维度,如客户需要解决的问题,客户对于产品有无长期的规划等等,但是这些都不是最重要的,最重要的是客户的为这个项目的投入和我们需要开发的成本。这也是确认产品形态的目的之一。毕竟外包公司是要通过项目来赚钱的。

其次就是业务逻辑,无论是官网还是庞杂的业务系统,贯穿整个系统的都是业务逻辑。通过业务逻辑的梳理,产品经理可以规划出产品的整体框架,模块,甚至产品有哪些页面都可以“推演”出来,可以说业务逻辑确定了,也就确认了整个项目的框架。确认了想项目的大方向。

如果业务逻辑错了,系统的框架、模块也就错了,那么功能需求理解的再透彻、原型画的再好,UI再完美,这个产品也是失败的。并且项目会有推翻重做的可能,不仅工期要比预期延长一倍,成本也要增加一倍。

产品形态和业务逻辑承载体是BRD或者流程图,或者二者想结合,这个要看项目。

BRD的作用在于证明我们的思路是和客户的思路同频的,包括项目的目的、帮助客户解决的问题,项目受众群体等。尽管这些是客户在做之前就已经想清楚的,但是还是要有一份BRD作为确认。尤其在官网,H5等项目时,这份文档可以为设计提供设计灵感及范围。

业务流程图的作用在于描述复杂的业务流程时,直观的显示项目整个流程。这个时候的业务流程不要过于复杂,只要说明用户从哪进,到哪出,设计到哪些模块,每个模块如何连接即可。这份文档可以原型设计和开发文档提供依据。

接下来就是沟通讲解,无论是会议也好,还是线上沟通也好,这个业务的逻辑究竟如何,业务人员是需要知道的。

这里需要说明的是,如果需要客户确认,不建议业务直接将业务流程转发给客户,客户自己研究,而是根据自己的理解去和客户讲清楚,至于能否将清楚,那就要看产品经理的理解能和业务的表达能力了。

二、确认原型,确认我们要“怎么做”

在同意了产品形态、业务逻辑之后,产品经理进入了最喜欢的原型阶段。

之所以确认原型,是告知客户我们“怎么做”,从功能点,页面的逻辑,页面的设计结构,用户的进入项目,走出项目的动线,用户都会通过原型有所知晓。

制作产品原型,每个产品经理有都有不同的标准。不过我问过很多开发产品原型在他们心中地位,开发回复是,我们只看设计图。

原型究竟要做到什么程度,还是要看项目,有些官网的项目,功能就是为了展示,只要把各个连接点在原型上提现出来就好,页面上包含的文字也要和业务确认好就可以了。甚至有些官网都不会用到原型,只是一个文档就可以解决问题。

但是项目如果是一套系统,那就需要将原型做细一些了,这里说的细并不是说在设计上,而是要考虑的全面一些,各个分支,各个异常情况都要考虑进去,并给与解决方案。不然在需求评审时,几个问题下来,就会变得灰头土脸。

对于产品原型,其实我没有太多发言权,和我合作过的UI开发都埋怨我说原型做的不太细,很多字段都是很模糊的。在这里自我检讨一下。

除了原型,还有一份MRD文档,这份文档在外包的项目中,最大的作用就是用作合同附件,所以用词一定一定一定要准确,尽量避免“等”这样模糊的字眼,比如说,导航栏包括产品介绍、公司介绍、新闻媒体等。如果按照这样写,那么导航栏会包含很多内容。开发会为这个坑不停的加班,同时也会不停的骂产品。

在这里我有个建议,业务和客户在确认原型的时候,最好产品经理也在场,这样在遇到关于产品方面的问题是,产品也好解答,毕竟产品原型不是业务设计的。

在业务人员确认了原型之后,产品经理就可以组织开发人员进行数据库,运营后台的开发,这需要确认的东西,我会在后面和大家讨论。UI的设计是产品经理需要和业务人员确认的第三个点。

三、确定UI设计,确认项目“什么样子”

一般来说,在外包的开发过程中,第一次提交设计方案,多是项目的首页,或者是项目的主要页面,这样的好处在于,客户既能想到产品未来的样子,也能节省设计的时间。待首页确认后,再陆续提供其他页面。

客户在拿到UI之后,基本上都会有一些修改。毕竟大家考虑的角度会不一样,客户更多的是站在自己业务层面上思考这些设计图,而UI设计师则是站在美学的角度来进行设计。这就造成了很多冲突。有的设计师设计的很好看,但是客户却说无法突出自己的品牌或者自己的产品。不过一旦按照客户的要求进行设计,难免会成为设计师设计生涯的“污点”。

在这里产品经理就应该从这几个方面进行协调:

  • 听取设计师从专业的角度来给出的意见,了解设计师为什么这么设计。
  • 听取客户的建议,获取客户对设计的需求。
  • 从这两点中找到平衡,与客户讲设计的理念,以及该理念对客户的好处。与设计师沟通,告知客户的痛点,让设计师在客户痛点和美观度方面找到一个平衡。

大部分设计基本上会按照原型进行设计,有些会根据自己的想法改变原型的结构,但是原型的内容不会改变。UI设计稿一定会比原型设计的要漂亮。当然也有UI设计的还不如原型的线框图好看。如果你作为产品经理拿到这样的UI,我的建议是,赶快换人吧。

UI设计确认完了,业务方面算是搞定了吧,别急,你回头看看,一群开发在虎视眈眈的看着你。

小结

上面说的确认、甩锅,实则是对产品经理的要求。产品经理要在开发前提供这些东西交给业务人员。无论是业务人员自己确认也好,还是交给客户确认,都是将项目方在一个框架内,这样在日后的开发过程中,不会出现太出格的需求。

开发前需要确认的:

  1. 业务逻辑(也有可能是产品形态),确定我们做什么;
  2. 原型文档,确定我们怎么做;
  3. UI设计,确定未来项目的“模样”。

有了这些,就可以进行开发了吗?

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

题图来自Unsplash,基于CC0协议