UI设计师如何应对To B百万级项目——转型产品经理实录

5 评论 6222 浏览 29 收藏 18 分钟

编辑导语:近年来,产品经理是很多互联网人都向往的一大岗位,那么作为一名UI设计师如果想转行做产品经理该如何做?作者总结自身项目经验,给大家介绍与总结自己接触百万级项目,负责产品经理工作的方法,希望对正在转型的你有所帮助。

俗话说不想当产品经理的UI不是好设计,这次跟大家聊一聊“UI设计师如何应对To B百万级项目-转型产品经理并0-1项目落地”。

第一次写文章,分享一下自己的经历和总结经验,供大家参考;内容涉及的环节比较多,很多地方写的也比较笼统,如果大家感兴趣欢迎一起深入讨论。

做UI也有几年的时间,产品经理的种子也一直埋在心里,先跟大家介绍一下我是怎样接触到百万级的项目,负责产品经理工作的。

由于我们产品经理人员的流失,导致刚刚接手的项目无人接手(其他产品经理也不想去接这个项目)因素有两点:一是要与新的团队去合作(成员比较难搞)、二是政企项目的复杂度(项目与合作对象),下面会给大家简单介绍一下。

领导经过多方谈话后,无人接手的项目就转到我这里来了,人们总是对于未知的事物产生恐惧。而我此时也是悲喜交加,喜的是终于有机会去做产品经理的工作了;悲的是万一项目搞砸了怎么办?

其实一开始我是拒绝的,与其说拒绝不如说是害怕,怕什么?怕把项目搞砸、被开发甲方怼、Bug乱飞、产品不能如期交付…你不接手可以说是不在职责范围内,一旦你接手后再出现问题那就是你的工作失误,影响极大。

既然上了贼船那就好好当个海盗吧,万一成功了呢?怀着恐惧的心理,接手了项目及近20人的团队,并开始了与甲方第一次沟通(产品经理生涯正式开始)。

相信大家对产品的流程也倒背如流了吧,产品前期要进行需求沟通、需求分析、需求挖掘、产品原型设计、需求评审、开发、测试、验收等一系列的环节。接下来分别从上述环节一一详述并举例说明。

一、需求沟通

1. 了解产品背景、业务流程

知己知彼,百战不殆。这一环节主要是要与甲方沟通项目的背景、目标、方向,了解业务和流程,说通俗点就是为什么要做这个产品,要解决什么问题,怎么解决?业务流程是怎样的?这里至关重要,一定要搞清楚业务流程、甲方要做的事情,切合现实场景帮助甲方去把需求说清楚、更具象化,并落实到文档中,抄送所有相关人员知晓。

这里要注意一点:你所对接的干系人是否具有话语权或者决策权,是否代表领导或者用户(往往对接人和使用产品的不是一拨人)如果以上都不是就要注意了,这时候如果不制定策略那产品开发完成后,你大概率就会听到:

  • “这不是我想要的”
  • “为什么要这么做?”
  • “这样不合理需要改一下”
  • ……

不仅会导致需求延期还会影响整个团队的情绪。

二、需求分析

1. 分析需求,将原始需求转换为产品功能点

为什么要将原始需求转换成产品需求?一是要梳理产品逻辑和层级、二是要将语言翻译成开发团队可以看的懂的内容,这样才可以进行后续的工作量评估、迭代计划的制定等。

通过我们上一轮儿沟通后,已经对产品的背景、方向、目标、业务都已深入了解。这时心中大概也有了一个产品雏形,对接下来要做的事情也逐渐清晰。

第一步:我们将甲方提供的原始需求文档,分析需求后转换成产品功能点。这里通过第一轮的沟通和深入了解业务,对于用户要做的事情已经清楚,所以转换成功能点难度不是很大。举个例子,如下:

  • 甲方原始需求:“我们要通过手持终端现场把管井、隧道井、杆、塔……一些要素资源采集到手机上,并且可以录入地理位置、相关信息以此来提高作业效率,帮助我们对资源的管理”
  • 产品需求:“移动端增加井、杆、塔等要素功能图标,支持点击后地图打点,打点成功后右侧弹出信息卡片,用户可编辑录入;打点成功后,要素支持增删改功能。”

我们在对原始需求分析的时候,要先从产品的一级开始,也就是业务的第一步开始。这样的好处是逻辑、层级不会混乱,是按照业务逻辑一步一步的深入产品功能;如果我们上来就对照原始需求一条条拆分,接下来你很可能就迷失在产品中,非常混乱。

原始需求分析完成后,基本上产品的逻辑、方向、功能都清晰了,这时不要急于开始产品设计、开发,切记!哪怕你已经和甲方看过了需求内容,甲方也觉得没有问题,也请不要暗自窃喜,急于进行下一流程。

有一点需要注意:在和甲方过产品功能文档之前,最好先给内部开发团队的同学讲一遍,让团队知晓我们即将要做的事情,心理上有个准备(或者是哪些方案的成本较大,在给甲方看时,内部先消化掉,避免一些不必要的麻烦)。

三、需求挖掘

1. 继续明确需求、发现隐藏需求(真伪需求)

相信大家都知道那匹马的故事,这里在赘述一下:

100多年前,福特公司的创始人亨利·福特先生到处跑去问客户:“您需要一个什么样的更好的交通工具?”

几乎所有人的答案都是:“我要一匹更快的马”。很多人听到这个答案,于是立马跑到马场去选马配种,以满足客户的需求。但是福特先生却没有立马往马场跑,而是接着往下问。

福特:“你为什么需要一匹更快的马?”

客户:“因为可以跑得更快!”

福特:“你为什么需要跑得更快?”

客户:“因为这样我就可以更早的到达目的地。”

福特:“所以,你要一匹更快的马的真正用意是?”

客户:“用更短的时间、更快地到达目的地!”

我们需要对产品需求文档结合多方用户、业务、多角度进行深度挖掘,以此来发现还有哪些我们未知的、隐藏的需求。包括现在的功能点是否真的是用户想要的?这些功能的实现能给用户带来什么价值?还有没有更好的方案?

(不要觉得他们对业务了如指掌,流程极其完美,其实他们只是没有发现问题而已,或者已经发现问题,没有更好的解决方案,一旦有了更好方案即将面临需求变更。)

我们在前期就需要把这些可能会发生的事情,尽量扼杀在摇篮里,将风险降低到最小值。举个例子,如下:

甲方:“一条光缆会通过多个井、杆、塔等等一些物体,我需要批量添加光缆,以关联放置在不同要素中,避免我们机械化的操作,提高工作效率”

产品:“为什么要做批量添加的功能?同一条光缆穿过不同的要素,光缆信息都是一样的,而不同的光缆信息是不一样的;现实场景中也不存在突然要添加一批光缆的情况,即使小概率出现,为满足这一场景,很容易造成数据出错,程序没办法控制。”

甲方:“我想先创建一批光缆,再去建立关联,这样就省去了一条条的创建时间,而且我们作业员都是专业的。”

产品:“我们在要素关联表中,支持搜索功能,只要未被当前要素所关联的光缆都可以搜索出来并建立关联;创建光缆时,自动赋值共有字段既可以规避脏数据,又可以保证数据的正确性,同时也提高了效率,这个方案可以吗?”

甲方:“可以。”

Ps:需求刚开始看起来似乎是合理的,那如果不进行分析、挖掘就将功能接下,那极有可能会要求在加一条“批量删除光缆”的功能,既然都支持批量添加了,那批量删除也一定会提出来。一旦用户在实际使用时,发现不好用或者有更好的方案,那等待的只有需求变更,而且甲方还能够说出为什么要变更,导致你哑口无言。

实际上一种场景,会有多种解决方案,这个时候就需要尽可能的把所有方案都罗列出来,从用户、项目、商业的角度去选择合适的方案,这样在跟甲方阐述时也会更容易被接受。

在明确需求后,接下来就需要组织开发团队进行需求讲解,让大家知晓我们要做的事情(在前期也需要将一些专业术语、相关业务资料给到大家)要注意一定要将情况实时同步给开发同学,这样你就会发现合作顺畅很多。

接下来就是开发团队工作量的评估,排需求优先级,制定迭代计划。(如一个月拆分4周,每周的开发内容,每周四发版验收)等等。

三、产品原型设计

1. 原型文档

在经过我们需求分析、需求挖掘环节后,一定要将结果,以书面形式抄送各相关干系人,让大家知晓,切记(一定要抄送到位,不容小觑)!

接下来就开始我们的原型设计环节了,除了从商业、用户、甲方、项目的维度去考虑产品框架,还要注意项目周期、开发成本、资源的问题。这些因素都将直接影响你的产品形态。而原型设计也要注意后续的可扩展性,具备快速响应需求变更的框架。

这一环节不要急着动手画原型,而是要先思考;准备好纸、笔,将你的想法快速的留在纸张上,尽可能多的去思考方案,逐一去分析每个方案的利弊,最终得到结果,再去画原型进行细节补充优化。切记!不要只考虑当前功能的展现,要结合整个产品流程,进行原型设计。

根据迭代计划,我们将需求原型设计完成后,先内部过方案,内部达成一致后再去跟甲方过方案,切记!在跟甲方过完方案无误后,一定要将结果抄送相关干系人,再进行开发阶段,切记!!不要急于开发。

由于团队的技术负责人前期一直强调,要注意开发成本,尽量降低开发同学难度的同时要满足业务诉求……所以导致我接下来满脑子都是怎样的设计方案开发成本最低,复用率更高。

当你被一些外来因素干扰你决策时,不要急着去排斥,要去分析这些建设性的意见是否是合理的,如果是合理的我们就采纳,去想办法解决掉。如果一开始就带有极强的排斥心里,那将会影响你后续的工作进展,心态一定要放平。

2. 交互文档

交互文档具体写哪些内容?要怎么写?以什么形式展现?

  • 交互文档的展示形式有很多,这里我习惯将交互说明文档,放置在原型右侧。这样可以对照着原型去看具体的交互逻辑。
  • 交互文档内容包括:功能操作描述、跳转逻辑、逻辑判断等。其目的就是要让开发同学明白功能是做什么的,怎么操作,有哪些状态、校验、判断等等。
  • 根据原型内容,按照顺序逐一将功能进行展开描述;可分为功能描述、业务原则描述两类。

注意原型文档一定要有变更记录,不同时间节点备份迭代内容,切记在一个文档中从开始改到结束。如下图:

四、需求评审

由于我们在与甲方过方案之前,已经与内部沟通过了,所以接下来的评审相对会比较顺利。召集相关开发人员,进行需求评审就可以了。前面说到要将进展、方案同步给开发,并不是以开发成本为中心设计需求,而是要让开发同学有参与感、责任感;更重要的是整个团队都要熟悉了解业务,前期做好充足准备,避免大家出现为了做需求而做需求的现象。

会议开始之前不必过于担心会出现反对声音,因为你的方案是在众多方案中推演决策而来的,所以这个时候你也有充足的依据去进行讨论,当然如果有更好的方案也要虚心采纳。

需求评审结束后,将最终的结果整理好,告知各个相关人员,接下来就是开发阶段了。切记!如果出现需求变更,或者原型内容的改动,一定要第一时间告诉团队内所有成员。

五、开发/测试/验收

当大的功能开发、测试完成后,可以将产品成果给甲方进行验收。主要形式为拉会议,召集甲方干系人,将产品进行演示、确认。这里目的就是再一次确认,因为开发之前已经给甲方做了心里建设,这里在通过平台化继续确认。

六、交付/验收

项目交付后,如果出现需求变更,这里基本上都是大领导级别的了,一般都是当面会谈,将变更内容落在纸面上,各方领导进行签字确认后,再回到产品研发部。

机会是留给有所准备的人,希望大家能永远保持积极的心态,一路披荆斩棘,升职加薪。

 

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

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
1人打赏
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 我司也是做政企项目的,但工作流程有差别。我们是先出一版原型,再去和局里调研。空着手去,局里是说不出什么东西的。

    回复
  2. 请问项目流程的配图与文章中的产品流程为什么不一样?图片是随便配的么?

    回复
    1. 你好,产品流程是在整个项目流程前环节中,拆分后进行细化的;而项目流程在实际工作中也会有所出入,比如很多公司没有“交互设计师”,这一环节的工作内容也被融合到了产品工作中。

      回复
  3. 为什么要将原始需求转换成产品需求?一是要梳理产品逻辑和层级、二是要将语言翻译成开发团队可以看的懂的内容,这样才可以进行后续的工作量评估、迭代计划的制定等。

    回复
  4. 走心的文章,细节的配图,生活中一定是有品质的人。要继续写下去哦(头像都很好看 )!

    回复