UI 设计师如何转行成为产品经理？设计师想本文作者通过自己的实战经历 ，梳理了一个完整的做产战项产品设计流程 。
俗话说不想当产品经理的品经品设 UI 不是好设计 ，这次跟大家聊一聊"UI 设计师如何应对 To B 百万级项目-转型产品经理并 0-1 项目落地" 。百万
第一次写文章 ，实结出计流分享一下自己的目总经历和总结经验 ，供大家参考；内容涉及的份产环节比较多 ，很多地方写的设计师想也比较笼统 ，如果大家感兴趣欢迎一起深入讨论。做产战项
做 UI 也有几年的品经品设时间 ，产品经理的百万种子也一直埋在心里 ，先跟大家介绍一下我是实结出计流怎样接触到百万级的项目 ，负责产品经理工作的目总 。
由于我们产品经理人员的份产流失，导致刚刚接手的设计师想项目无人接手（其他产品经理也不想去接这个项目）因素有两点 ：一是要与新的团队去合作（成员比较难搞） 、二是政企项目的复杂度（项目与合作对象） ，下面会给大家简单介绍一下。
领导经过多方谈话后 ，无人接手的项目就转到我这里来了 ，人们总是对于未知的事物产生恐惧 。而我此时也是悲喜交加 ，喜的是终于有机会去做产品经理的工作了；悲的是万一项目搞砸了怎么办 ？
其实一开始我是拒绝的 ，与其说拒绝不如说是害怕 ，怕什么 ？怕把项目搞砸、被开发甲方怼 、Bug 乱飞 、产品不能如期交付…你不接手可以说是不在职责范围内 ，一旦你接手后再出现问题那就是你的工作失误 ，影响极大 。
既然上了贼船那就好好当个海盗吧 ，万一成功了呢 ？怀着恐惧的心理 ，接手了项目及近 20 人的团队 ，并开始了与甲方第一次沟通（产品经理生涯正式开始） 。
相信大家对产品的流程也倒背如流了吧，产品前期要进行需求沟通 、需求分析 、需求挖掘 、产品原型设计 、需求评审 、开发 、测试、验收等一系列的环节 。接下来分别从上述环节一一详述并举例说明 。
1. 了解产品背景 、业务流程
知己知彼 ，百战不殆 。这一环节主要是要与甲方沟通项目的背景 、目标、方向 ，了解业务和流程 ，说通俗点就是为什么要做这个产品 ，要解决什么问题 ，怎么解决 ？业务流程是怎样的？这里至关重要，一定要搞清楚业务流程 、甲方要做的事情 ，切合现实场景帮助甲方去把需求说清楚 、更具象化 ，并落实到文档中 ，抄送所有相关人员知晓。
这里要注意一点 ：你所对接的干系人是否具有话语权或者决策权 ，是否代表领导或者用户（往往对接人和使用产品的不是一拨人）如果以上都不是就要注意了 ，这时候如果不制定策略那产品开发完成后 ，你大概率就会听到：
"这不是我想要的"
"为什么要这么做 ？"
"这样不合理需要改一下"
……
不仅会导致需求延期还会影响整个团队的情绪 。
1. 分析需求 ，将原始需求转换为产品功能点
为什么要将原始需求转换成产品需求 ？一是要梳理产品逻辑和层级 、二是要将语言翻译成开发团队可以看的懂的内容 ，这样才可以进行后续的工作量评估、迭代计划的制定等 。
通过我们上一轮儿沟通后，已经对产品的背景 、方向 、目标 、业务都已深入了解 。这时心中大概也有了一个产品雏形 ，对接下来要做的事情也逐渐清晰 。
第一步 ：我们将甲方提供的原始需求文档 ，分析需求后转换成产品功能点 。这里通过第一轮的沟通和深入了解业务，对于用户要做的事情已经清楚，所以转换成功能点难度不是很大。举个例子 ，如下：
我们在对原始需求分析的时候 ，要先从产品的一级开始 ，也就是业务的第一步开始 。这样的好处是逻辑 、层级不会混乱 ，是按照业务逻辑一步一步的深入产品功能；如果我们上来就对照原始需求一条条拆分 ，接下来你很可能就迷失在产品中 ，非常混乱 。
原始需求分析完成后 ，基本上产品的逻辑 、方向 、功能都清晰了 ，这时不要急于开始产品设计、开发 ，切记 ！哪怕你已经和甲方看过了需求内容 ，甲方也觉得没有问题 ，也请不要暗自窃喜 ，急于进行下一流程 。
有一点需要注意 ：在和甲方过产品功能文档之前 ，最好先给内部开发团队的同学讲一遍 ，让团队知晓我们即将要做的事情 ，心理上有个准备（或者是哪些方案的成本较大 ，在给甲方看时，内部先消化掉 ，避免一些不必要的麻烦） 。
1. 继续明确需求、发现隐藏需求（真伪需求）
相信大家都知道那匹马的故事 ，这里在赘述一下 ：
100 多年前 ，福特公司的创始人亨利·福特先生到处跑去问客户："您需要一个什么样的更好的交通工具 ？"
几乎所有人的答案都是："我要一匹更快的马" 。很多人听到这个答案 ，于是立马跑到马场去选马配种，以满足客户的需求 。但是福特先生却没有立马往马场跑，而是接着往下问。
福特 ："你为什么需要一匹更快的马 ？"
客户 ："因为可以跑得更快 ！"
福特 ："你为什么需要跑得更快 ？"
客户 ："因为这样我就可以更早的到达目的地。"
福特 ："所以 ，你要一匹更快的马的真正用意是 ？"
客户 ："用更短的时间 、更快地到达目的地 ！"
我们需要对产品需求文档结合多方用户、业务 、多角度进行深度挖掘，以此来发现还有哪些我们未知的 、隐藏的需求 。包括现在的功能点是否真的是用户想要的 ？这些功能的实现能给用户带来什么价值 ？还有没有更好的方案 ？
（不要觉得他们对业务了如指掌 ，流程极其完美，其实他们只是没有发现问题而已 ，或者已经发现问题 ，没有更好的解决方案 ，一旦有了更好方案即将面临需求变更 。）
我们在前期就需要把这些可能会发生的事情 ，尽量扼杀在摇篮里 ，将风险降低到最小值 。举个例子 ，如下 ：
甲方："一条光缆会通过多个井 、杆 、塔等等一些物体 ，我需要批量添加光缆 ，以关联放置在不同要素中 ，避免我们机械化的操作，提高工作效率"
产品 ："为什么要做批量添加的功能 ？同一条光缆穿过不同的要素，光缆信息都是一样的 ，而不同的光缆信息是不一样的；现实场景中也不存在突然要添加一批光缆的情况 ，即使小概率出现 ，为满足这一场景 ，很容易造成数据出错 ，程序没办法控制。"
甲方 ："我想先创建一批光缆 ，再去建立关联 ，这样就省去了一条条的创建时间 ，而且我们作业员都是专业的 。"
产品 ："我们在要素关联表中 ，支持搜索功能 ，只要未被当前要素所关联的光缆都可以搜索出来并建立关联；创建光缆时 ，自动赋值共有字段既可以规避脏数据 ，又可以保证数据的正确性，同时也提高了效率，这个方案可以吗 ？"
甲方 ："可以。"
Ps ：需求刚开始看起来似乎是合理的 ，那如果不进行分析、挖掘就将功能接下 ，那极有可能会要求在加一条"批量删除光缆"的功能 ，既然都支持批量添加了 ，那批量删除也一定会提出来 。一旦用户在实际使用时 ，发现不好用或者有更好的方案 ，那等待的只有需求变更 ，而且甲方还能够说出为什么要变更 ，导致你哑口无言 。
实际上一种场景，会有多种解决方案 ，这个时候就需要尽可能的把所有方案都罗列出来 ，从用户 、项目 、商业的角度去选择合适的方案 ，这样在跟甲方阐述时也会更容易被接受 。
在明确需求后 ，接下来就需要组织开发团队进行需求讲解 ，让大家知晓我们要做的事情（在前期也需要将一些专业术语 、相关业务资料给到大家）要注意一定要将情况实时同步给开发同学 ，这样你就会发现合作顺畅很多 。
接下来就是开发团队工作量的评估，排需求优先级 ，制定迭代计划。（如一个月拆分 4 周，每周的开发内容 ，每周四发版验收）等等 。
1. 原型文档
在经过我们需求分析、需求挖掘环节后，一定要将结果 ，以书面形式抄送各相关干系人 ，让大家知晓 ，切记（一定要抄送到位，不容小觑） ！
接下来就开始我们的原型设计环节了 ，除了从商业 、用户 、甲方 、项目的维度去考虑产品框架，还要注意项目周期 、开发成本 、资源的问题。这些因素都将直接影响你的产品形态 。而原型设计也要注意后续的可扩展性 ，具备快速响应需求变更的框架 。
这一环节不要急着动手画原型 ，而是要先思考；准备好纸 、笔，将你的想法快速的留在纸张上，尽可能多的去思考方案 ，逐一去分析每个方案的利弊 ，最终得到结果，再去画原型进行细节补充优化 。切记 ！不要只考虑当前功能的展现，要结合整个产品流程 ，进行原型设计 。
根据迭代计划 ，我们将需求原型设计完成后 ，先内部过方案 ，内部达成一致后再去跟甲方过方案 ，切记 ！在跟甲方过完方案无误后 ，一定要将结果抄送相关干系人，再进行开发阶段，切记！ ！不要急于开发。
由于团队的技术负责人前期一直强调，要注意开发成本 ，尽量降低开发同学难度的同时要满足业务诉求……所以导致我接下来满脑子都是怎样的设计方案开发成本最低 ，复用率更高 。
当你被一些外来因素干扰你决策时 ，不要急着去排斥 ，要去分析这些建设性的意见是否是合理的 ，如果是合理的我们就采纳 ，去想办法解决掉 。如果一开始就带有极强的排斥心里 ，那将会影响你后续的工作进展 ，心态一定要放平 。
2. 交互文档
交互文档具体写哪些内容 ？要怎么写 ？以什么形式展现 ？
注意原型文档一定要有变更记录 ，不同时间节点备份迭代内容 ，切记在一个文档中从开始改到结束 。如下图：
由于我们在与甲方过方案之前 ，已经与内部沟通过了 ，所以接下来的评审相对会比较顺利。召集相关开发人员 ，进行需求评审就可以了 。前面说到要将进展 、方案同步给开发 ，并不是以开发成本为中心设计需求，而是要让开发同学有参与感 、责任感；更重要的是整个团队都要熟悉了解业务 ，前期做好充足准备 ，避免大家出现为了做需求而做需求的现象 。
会议开始之前不必过于担心会出现反对声音 ，因为你的方案是在众多方案中推演决策而来的 ，所以这个时候你也有充足的依据去进行讨论 ，当然如果有更好的方案也要虚心采纳 。
需求评审结束后 ，将最终的结果整理好 ，告知各个相关人员 ，接下来就是开发阶段了 。切记 ！如果出现需求变更 ，或者原型内容的改动 ，一定要第一时间告诉团队内所有成员 。
当大的功能开发 、测试完成后 ，可以将产品成果给甲方进行验收 。主要形式为拉会议 ，召集甲方干系人 ，将产品进行演示 、确认。这里目的就是再一次确认，因为开发之前已经给甲方做了心里建设，这里在通过平台化继续确认 。
项目交付后 ，如果出现需求变更 ，这里基本上都是大领导级别的了 ，一般都是当面会谈 ，将变更内容落在纸面上，各方领导进行签字确认后 ，再回到产品研发部 。
机会是留给有所准备的人 ，希望大家能永远保持积极的心态 ，一路披荆斩棘 ，升职加薪 。
