标签：www 流程 data- 参与 理由 指标 应该 字体 get
1.2019/12/16
“无法实现”有几种可能：研发明确知道无法实现、研发不知道能实现、研发不知道是否能实现、研发明确知道可以实现却说无法实现
这是比较常见的情况，研发用自己的专业能力评估了方案，确实不能实现并诚实地做了反馈。这种情况不用多说废话，赶紧改方案，一定是我们设计方案过程中缺少了必要的技术可行性研究，这个锅咱得自觉背起来。
研发评估之后以为不能实现，然而实际上是可以实现的。出现这种误判一般不会是故意，原因很可能是能力、视野的限制。这时候产品经理可以协助寻求上级或技术专家帮助或给予现成案例参考等等，去帮研发正确地评估。
在不知道能否实现的情况下却告知我们“无法实现”，不管是因为没有时间去评估、根本不想评估、还是评估无结论，都不是健康的现象。说明研发主观上可能不太想做这个方案。
明确知道可以实现却告知无法实现，很明显，这方案研发极度不想做。当然，正常情况下，这种情况比较少出现。
从上面的分析中可以看出，有些情况下并不是真的“无法实现”，而是判断失误、评估能力不足、非有效评估、无评估等情况下给出的错误结论。产品经理作为团队的一份子，应尽力和研发一起去解决这些问题，技术评估不是研发一个人的事，可以考虑从以下几个角度去得到真实评估：
评估方案往往也需要花大量的时间，并不是读一遍PRD或看一遍原型就能给出结论的。研发不愿意评估可能因为评估工作的性价比低（比如有的公司评估不计工作量）、没有足够时间（比如有些团队的迭代流程中没有规划评估阶段）、个人意愿等。产品经理要做的是在项目周期中合理安排时间，让研发有足够的时候去做评估；提供方案时也要讲述项目背景、目的、价格，当做一件事有价值的时候，才有更大的动力去做好，切不可把研发只当作资源方，把方案一扔就完事了。
正确评估一下方案需要技术、经验、视野缺一不可。产品经理在提供方案时可以同时提供现有案例、相似产品给研发；在必要的时候，协助研发寻求更高一级的技术支持。从侧面帮助提高研发的评估能力。
评估后给出不真实的结论，俗称“忽悠你不懂技术”，不考虑人品问题的话，说明产品经理已经失去了研发的信任，他已经不愿跟我们说真话。
经过技术评估后，产品设计方案确实无法实现时，应明确无法实现的原因，以寻找对应的解决方案。技术无法实现的原因一般由以下几种：
方案不合理、异想天开，当前没有技术可以做到，比如“让手机壳根据UI自动换色”。
方案需要的技术能力当前团队达不到。有的产品经理看到别的产品的功能很厉害，就想自己也做一个，却忽略了团队能力的差异。比如芯片、5G等，不是谁都能复制的。
不同技术框架有不同的特点，也有不同的不足之处，一款产品的技术框架一般不会更改，有时候会遇到技术框架限制而无法实现的功能方案。
方案合理、能力够、也没有技术限制，但没有足够的人来做。
当我们设计好的产品方案被评估为无法实现后，当务之急就是根据实际原因来修改这个方案：
1.不合理方案是产品经理的工作失误，应好好反省自己，重新梳理需求，多请教研发技术知识，重新设计方案以达到合理。
2.能力原因短期内无法解决，产品经理应有看菜下饭的能力，根据团队的能力水平去设计合理的替代方案。
3.技术原因也需要产品经理妥协，可适当了解当前产品的技术特点，扬长避短。
4.人力原因本质是研发难度问题，也是成本问题。达到需求目标的方案往往不止一个，并不一定要选效果最好的，而应尽量选择效果较好成本较低的。
产品设计方案因无法实现而不得不重新修改，耗时耗力，在如今飞速发展的时代，浪费时间很可以会耽误产品的商业机会，同时也会降低自己在团队中能力信任。我们应长远地解决这类问题
1.懂点技术。虽然产品经理不需要写代码，但不能不懂技术，至少要了解技术的原理、自己产品的技术框架、团队的技术能力水平等等。产品设计要建立在技术可行性基础上，但也不要被自己有限的技术能力限制（自己觉得不能实现就不做了）。
2.产品设计过程要考虑研发可行性，不可随意发挥。我给团队制定的SOP中，有一步是“初步方案”，目的是在进入详细之前先确认掉技术疑点；设计过程中有不确定的也需要随时与研发沟通。
3.默契与信任。产品经理要用自己的专业能力和职业态度建立起团队中的信任，在一次次的项目过程 中建立起默契。信任和默契是事情推进最好的润滑剂。有时候我们苦思冥想得不出的好方案，也许研发从技术角度很轻易地就给出了答案。
2.2019/12/17
设计师在产品设计过程中的角色处在表现层，但产品经理需要对整个产品负责，所以产生一些争论也情有可原。
我们先来看看争论产生的原因，从如下5个维度分析产生分歧的原因。
产品经理：产品做的好与不好都需要有人来背锅的，产品经理往往背负着KPI的压力指标商业广告的收益、各入口所能产生的转换率、数据（UV、PV、DAU）、次日留存/周留存、投入产出的比例、项目怎么能推进等。
设计师：设计反应在视觉层面，加广告太难看了、入口太多了没有留白、文字能不能去了、不用那么多图标，加这么多信息都不考虑用户的感受，影响用户体验，留不住用户。
产品经理和设计师面对同一个需求所处的视角根本不在一个频道，产品经理看的大面，设计师看到可能只是表现层的体验，双方转换一下视角可能又是另一番景象。
产品经理：目前大学里还没有产品经理这个专业的课程，企业在招聘产品经理这个职位的时候，往往看中的是面试者的逻辑思维能力、表达能力、抗压能力、沟通能力。所以你会发现做产品经理一职的，技术出生的偏多，理性思维，逻辑能力很强。
设计师：设计是专业技能，没几把刷子还真就干不了这活。设计师大都是美院毕业的居多、相关的设计专业、在培训机构练就一身本领的全能设计师、也有非本专业的完全凭借个人喜好干出一番伟业的，这样占据的比例相对少点。
为什么很多公司要求产品懂设计、技术，不然只有逻辑怎么往下开展工作，设计师也需要理解产品中的逻辑，不然互相思路都不在一条线上，工作还怎么开展。
产品经理：产品经理最喜欢说的三句话就是这个需求很简单、这个需求很着急、这个需求很重要。这三句话本身就很招人烦。再就是提出具体的设计问题，这块的字能不能再大点、Logo 再变大一点、按钮再大点、反正就是都变大点、空白的地方都填满；颜色能不能再明显点、蓝色是不是科技感更强点、红绿搭配会不会更好点等。
设计师：对设计师而言，设计师想通过层次引导设计来引导用户，不是只有大；对比强烈、互补的色彩搭配不是只有红绿，甚至是留白可能更显气质。
这样的沟通成本能不高吗？
相互视角都不在一个方向上，一个说东，一个说西，背道而驰，怎么能形成共鸣呢？
产品经理：为什么就不能按照我设计原型来做呢？明明是这么画的，出来的效果却是这样的，怎么能随便改人家的劳动成果呢？
设计师：设计师都不喜欢照着原型设计，感觉没有融入自己创意思路，所以会觉的原型设计的不符合用户体验需求，就想着发挥一下特长了。
产品原型体现的是产品的逻辑，设计师从用户体验的角度去理解产品原型？其实设计不一定非得跟原型一模一样，关键是合理性。
产品经理：很多需求设计都是直接发给产品经理，评审也是产品经理来拍板，这就造就了产品经理的强权地位。只要是最后拍板的，看待设计多少都会带有主观色彩，确实可能存在偏离预期的设计方向。
设计师：设计本来就是推陈出新的立异过程，才能体现出设计的价值，而设计师需要将自己的设计思路传达出去，往往会遭遇不测。面对不理解，又不甘心作品被PASS掉，潜意识中产生了一种较量。
这种较量往往是在潜意识中形成的，来源于一种叫“不理解”的套路。其实真不是不理解，只是我们没有正确的对待这件事。
看到产品经理和设计师经常会争论细节的原因，那怎么沟通的姿势才正确呢，如下6个姿势可能会解决。
波克定理：只有在争辩中，才可能诞生最好的主意和最好的决定。提出者是美国庄臣公司总经理詹姆士·波克，就是说没有摩擦就没有磨合，有争论才有高论。
到目前为止，我们没有一次评审会能安静度过，这都成了很多设计师的魔咒。
咱们试想一下，如果每次大家都没意见，说明什么问题？
没有人认真用心对待产品了，是不是更可怕？
周鸿祎在《互联网自述》那本书中不是也说过，他就喜欢看到有不同的声音，为工作争论起来。看看《乔布斯自传》那本书中，乔布斯跟团队吵了多少次。
轻需求：很多需求设计都是一种市场需求，比如迎合节日、重大事件、悼念等做的一些情感化设计，刚过完的周年活动，很多产品都按照设计规范融入了庆典的设计元素。咱们能说这样的设计需求一定能带来多大收入吗？能带来多少新用户的增长吗？我估计谁也不敢这么说，用户也不能因为产品没做这些就弃用了。
重需求：颜色的优化、操作习惯的优化、引导设计的优化就能提高用户转化，这些直接影响到用户感受去留的设计，对产品的杀伤力太大。这些需求优先级应该提至最高，刻不容缓。
厘清需求的杀伤力，促使我们理性对待的态度会发生很大的转变。
其实产生纷争的很多需求，都可能是由于我们看待问题的视角产生了差异。产生争议以后，说明真的有问题出现，各自说出的理由没有很好的说服力，这样僵持着就会影响到整个项目的进度。
这个时候，如果大家都觉得这个需求非常重要的情况下，往往会向上一级求助，好多公司的大BOSS就要出场了。这样得出的结果即使是偏离了一方的预期，但大家还是会去执行。
设计规范从在宏观层面，方便了团队高效协作，建立统一的设计文化，视觉形象和品牌统一保持一种调性，保证多人参与同一项目视觉的一致性。
优秀设计规范的建立本身就是对设计团队的考验，传达到用户层面的体验设计也得到了统一。
设计规范涵盖范围很广，字体、动效、交互、色彩、控件、间距、图标、列表、弹出层、文案语气、调性等等模块。
设计规范不仅可以塑造整个产品形象的统一，同时产品的迭代与交接更加高效。因为规范本身就具备很强的说服力，可以减少很多不必要的争论。
很多问题涉及到交互，微动效，体验层面，感官地争论结果，缺少客观的说服力。这时候我们可做个简单的Demo，让更多的人未参与讨论的用户来体验，这些用户的反馈没有偏向性，反倒是更接近我们想要呈现的结果。
产品设计的好与坏，不是通过我们争论来决定的，而是真实用户使用的感受来评判的，这就是我们俗称灰度测试。验证产品的测试方法，通用的灰度测试就是A/B Test，多维度分析测试数据带来的变化，带来提升的点需要分析。反之下降的也要分析，不能说数据下降了，用户就没有需求。具体的还要结合产品解决用户的问题来考量。
验证用户就是要仔细分析用户的行为和功能设计之间是不是存在偏差。转化率的提升是个关键指标，埋点的位置尽量可以清晰看到用户的使用轨迹，这样可以更好判断出问题所在。
只有在讨论中，才可能诞生最好的主意和最好的决定。
理性对待这些争论，谁都想把产品做好，更何况产品经理是需要对整个产品数据负责，背负KPI考核的。那可不是开玩笑的，领导问责也是直接责任人。
多一点理解，转换一下视角，权衡一下利弊。针对不同的需求的争论，采用不同的应对方案，让项目更加高效。
标签：www 流程 data- 参与 理由 指标 应该 字体 get
原文地址：https://www.cnblogs.com/laurarararararara/p/12055260.html
