数极客首页

从产品经理“甩锅”来看外包项目的开发流程(业务篇)

产品经理在工作中如何避免背锅?先做好这三方面:业务逻辑(也有可能是产品形态),确定我们做什么;原型文档,确定我们怎么做;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协议

新一代大数据用户行为分析与数据智能平台:数极客(https://www.shujike.com),是支持无埋点、前端埋点、后端埋点、API导入四种混合数据采集方式,整合分析用户行为数据和业务数据,可以自动监测网站、APP、小程序等多种渠道推广效果分析,是增长黑客们必备的互联网数据分析软件。数极客支持实时多维分析、漏斗分析、留存分析、路径分析等十大数据分析方法以及APP数据分析网站统计网站分析小程序数据统计用户画像等应用场景,业内首创了六种提升转化率的数据分析模型,是数据分析软件领域首款应用定量分析与定性分析方法的数据分析产品

发表评论

评论已关闭。

相关文章