时间： 17:57 来源： 作者：Online
　　当大家都在讲产品经理的必备素质、必备工作技能、必备能力的时候，我们来看看产品经理的工作心态，心态和能力关系不大，而与个人的临场情绪有较大关系。保持良好的工作心态，能帮助产品经理合理分配精力，更好的投入到产品工作当中。但心态这个东西是很虚的，没法很好的进行描述，只能结合一些场景或者问题来顺带说明，下面是常见的一些会对产品经理的工作心态有影响的场景。
　　这里要说明一下的是，下面所提到的需求都是指最终确定的需求，而不是原始需求。这篇文章可能会让你觉得是在说废话，只是希望看后能静下心来稍微体会一下。
　　平衡用户的需求、想做的需求和能做的需求
　　产品经理每天都会淹没在一大堆需求里面，有业务部门提过来的需求，有通过用户研究、市场调查、数据分析提炼出来的需求，还有一些产品经理自身对产品的规划需求，理论上三种需求都是要做的，但总归人的精力是有限的，这时就要学会调整心态，让自身保持平和，平衡各方需求，按照优先级、工作量等衡量指标去协调安排各个需求。实际工作当中是很难去维持这种平衡的，这意味着在有限的时间段内必须得做出取舍。这种时候切不可急躁，否则会觉得被需求的大山压住了，更加施展不开。
　　我们要了解业务方的出发点，去发现深层次的需求，进而更好的衡量需求的急迫性和优先级。业务部门的需求往往都是结合了产品运营、后台管理或者客户服务的要求，因此从根本上说，这部分需求是为了保证产品能正常运作而提出的。从这个基础点来看，这部分需求我们一般都绕不过去，迟早都是要做的，可以见缝插针，每个迭代安排一部分。
　　要了解用户的需求，深挖某个需求实现的意义和价值。对于这类需求来说，小需求可能影响不大，大需求基本上都会动到产品的根本，有可能会导致产品的模式都变了。与业务部门需求不一样的地方在于，这部分需求的实现直接面向终端用户，这就要求我们在做的时候要稍微谨慎一些，尽量多一些数据支持。但往往发现的用户需求都是需要尽快实现的，属于要做且急迫的类型，因此要有一些资源上的倾斜。
　　要平衡自我实现诉求。产品经理的风格有时候会影响产品的风格，很多时候我们都会加一些自己的想法到产品当中去。这是无可厚非的，每个人都有自己的一套做产品的方式，都会有自己的产品发展规划。这种规划是一种长期的过程，可以慢慢实现，属于要做但不急迫的类型。可能规划还需要汇报，还需要再推敲和打磨，不用急在一时，按照一定的计划逐步去走就可以了。
　　基于上面的三个分类，再提炼出各部分中优先级最高的需求，排入最近的迭代，然后每个迭代再接下去做第二高优先级的需求，如果中间有需求加入，只要评估新需求的所属分类和优先级就可以了，就知道什么时候去做，这样就不太会影响到工作心态。
　　不盲目创新，乐于微创新，抄袭不可耻
　　创新是一个恒久的命题，说创新永无止境，一点也不为过。但真正的创新总是极少出现，那些疯狂的点子，绝妙的创意基本都是可遇而不可求的，所以我们没有必要去太过追求创新，只要保持足够的创新敏锐度就可以了。这种敏锐度因人而异，要看你对新事物、新观念、新潮流的嗅觉是否足够灵敏，指不定哪天你也能发现真正的创新。
　　而现在我们讲的最多的还是微创新，说白了就是站在巨人的肩膀上，把现有的功能或者别人的东西拿过来改改，改成适合产品风格或体系的功能，反正就是改的和原来不太一样了。这种微创新无处不在，很多人认为这也是抄袭，只不过抄的不一样摆了。重点就在于&不一样&，所以不能称为&抄袭&，只能称为&模仿&。如果你也能做到&一直在模仿，从未被超越&，那也是极好的。
　　说到抄袭，可能很多人会嗤之以鼻，其实我们自身虽然不主动抄袭，但很多时候都在被动或者间接抄袭，为什么这么说?当大家开始凭经验去设计产品的时候，脑海中最容易闪现的肯定是在哪看到过的某种设计，或者是曾经用过的某种设计，会直接拿出来使用。殊不知这时可能就已经抄袭了某位前辈的设计方式，抄袭并不可耻，适当的拿来主义能节省不少成本，当然最好是能抄出新意来，使之变为&模仿&。
　　平衡各方利益，放弃完美主义，懂得短期/长期目的平衡
　　每个产品经理都会给自己的产品打上印记，投入很大的精力去呵护和建设，自然而然的就会朝着较为完美的方向去规划和设计产品，这时就会发现，理想和现实总是很矛盾。规划的很美好，现实当中去做却有各种困难，不是资源有问题，就是业务规则老变。这些都是正常的情况，个人觉得产品经理在日常工作过程当中还是要务实一些，业务规则一直在变，完美的规划几乎不存在，不过后台产品另说，相对来讲后台产品要稍微稳定一点。
　　在产品研发过程当中，固执的完美主义会引发各方冲突，特别是影响了相互利益的时候。比如运营说要增加某个功能，但实际上这个功能并不在你的规划中，可能同时还有别的业务方在向你提需求，这种时候就需要去平衡各方利益，而平衡的结果，往往都是放弃原先的规划。所以我们说要放弃完美主义，特别是在做互联网产品，因为互联网发展的日新月异，很可能这周排好的需求，过了两个星期就已经不适合再排入开发了，所以需求池是要经常更新的。
　　长期和短期目标的平衡，相信大家自己都有判断标准，需要结合实际的工作情况来看，这里就不多说了。
　　唯快不破，持续迭代优化
　　天下武功无坚不破，唯快不破。意思是天下任何武功，都有自己的不足，防守的再好，也有破解方法，只要意识、攻、守、临机变化等速度远远高于对方，势必游刃有余!互联网上的信息较为透明，产品模式重叠化严重，导致市场竞争非常激烈，好的产品概念一出现，就会有N个团队在设计研发，可以在一夜之间从零变成群雄争霸的局面。这样的情况下，产品经理不必懊恼，主动权都在手上，如何合理的安排需求进行快速迭代才是重点。要快到什么样的地步呢，就是你出了一个新功能，人家还没来得及抄袭模仿呢，下一个新功能又已经出来了。所以说一个微创新是不够的，要持续的进行微创新。
　　产品上线，事情才做了一半，好产品要运营
　　好的产品是运营出来的。如果哪位产品经理不认同这句话，那么接下去的就可以不用看了。产品和运营都很重要，可以说是相辅相成的，好的产品设计出来不运营出去，就会砸在手里。所以说产品上线了，工作才做了一半。另一半更为关键的是要把产品推销出去，让用户去使用它。再好的产品，如果没有用户使用，最终也只会成为产品设计教科书上的一个例子，很有可能还是个反面的例子，那是多么杯具的一件事
　　运营的时候没有一个好产品握在手里，就感觉底气不足。运营是需要产品支持的，好的产品运营的也有动力，不好的产品会让运营觉得无所谓，反正只能这样了。况且运营过程中能收集回来很多用户反馈，对完善产品是很有帮助的。所以运营很重要，切不可认为产品做完了就结束了，产品经理还要跟进运营的过程。
　　工作心态和我们平时讲的工作情绪有点像，良好的工作心态对压力山大的产品经理工作大有助益，会让你hold住一切。一切尽在掌握的感觉肯定是很爽。另外要注意不要让生活中的情绪影响到工作，尽量把生活和工作分开。相关描述工作过程中要有好心态的书很多，如《工作中要有超好心态》，《无法选择工作但可选择态度》等等，这些只是单从心态层面来讲，这里是结合了产品经理工作过程中的实际场景来说明，算是理论结合实际，大家也可以看看类似的书籍。最后引用一句话，&好心态决定好出路&，祝愿各位同行都有好出路。
围观: 9999次 | 责任编辑：坐怀不乱
您可以分享到:
12120 人浏览
25375 人浏览
11121 人浏览
10103 人浏览
41564 人浏览
本站由七牛提供云存储想成为优秀产品经理？别忽视这十本好书
[摘要]作者精心挑选出了十本好书，从技术、商业到社会学、信息史均有涉及。
那群活跃在互联网的优秀产品经理，都喜欢读书。我曾和同为产品经理的A讨论某个功能，最后一直讨论到需求，讨论到人类进化史，甚至讨论了风险意识对于人类的影响，最后双方各执一词，回归到需求，选择了一个相对完美的方案。这种感觉好比黑夜中，刀光凌厉，却又带点惺惺相惜。换句话说，不读书，你连据理力争的机会都没有。这算是产品经理行业内的一种残酷。做产品，其实谈的还是对人性、对商业市场、甚至是对整个社会的理解。小到“情感化设计”，大到“商业模式”，什么都不懂的话，似乎就变成别人口中那个：“要产品经理干嘛”的故事主角。一个合格，优秀的产品经理必然需要读书，而且不仅限于那些“实用主义”的畅销书，更要多维度地阅读，对多领域有所涉猎。对世界的好奇心越重，你越容易发现需求的所在；对世界的理解越深，你越容易知道怎么样才能改变生活。因此，我避开一些热门畅销书，精心挑选出了十本好书，从技术、商业到社会学、信息史均有涉及，可以让希望成为产品经理的初学者、创业者，甚至优秀的产品经理都能从中探索到新的阅读乐趣，并触动人心。《理性乐观派：一部人类经济进步史》(The Rational Optimist:How Prosperity Evolves)这本书是我读过一系列讲述“科技如何推动社会进步”中最好且最有诚意的著作。与之类似的还有另一本书叫做《富足》。两本书都讲到一个有趣的事情：如何解决资源紧缺的情况？比如水资源紧缺，并非是因为真的缺乏这种资源。其实地球70%的面积都富含水资源，如果可以把海水淡化，水资源紧缺将不是影响世界发展的难题。当然，解决问题的前提是“如果可以”，这种“如果可以”并不是靠悲观和节省就能解决的问题，而应该依赖新技术，利用新技术降低海水淡化的成本，这的确是一种思路。此外还有许多有趣的案例让人从宏观的历史看到更多未来发展的可能，对于互联网从业者来说，这是一种启发式的新观点，对于“想改变世界”的人来说，亦有价值。《总开关: 信息帝国的兴衰变迁》全书阐述了AT&T的发展、拆分和再次崛起，谈及美国政府对待通信产业、好莱坞、有线电视及互联网等传媒的态度。其中颇有一些值得揣摩的“分与合”故事：阿道夫·朱克与其他人挑战爱迪生电影托拉斯。当托拉斯被限制的时候，朱克则想着让所有电影院接受他打包购买的计划。戴维·萨诺夫是美国无线电公司总裁，他从贝尔公司手中获得了无线电的业务，并影响整个国家的无线电广播，但他却有意阻碍了调频技术的使用。联邦通信委员会一开始阻碍新技术发展，后来又为反托拉斯，分解垄断产业做出了行动。乔布斯曾在iPhone首发的现场，邀请Google的总裁施密特。可两家公司最后却分道扬镳，各自为阵。《总开关》一书，Tim虽然谈的是产业整合和分解的历史，但最终想说的却是这样一个观点：对于信息的控制。他在书中曾写道这样一段话：“赫胥黎在写作《美丽新世界》6年前，已然窥察到集中管理并机械化生产的文化产业将产生的严重后果。他写道：从堪萨斯到北京旅行必定只需要花上几个小时，不过，要是两地风貌无别，这样的旅行将不再具有任何意义。”大批量生产且被限制的信息，最终会有什么样的效果呢？大概就是赫胥黎说的“毫无意义”。《黑客：计算机革命的英雄》（Hackers: Heroes of the Computer Revolution）如果说互联网需要有一本有足够多历史的书，那么看这本《黑客》是第一首选。相比《浪潮之巅》等书讲商业故事，《黑客》这本书是真正从第三方的视角出发，讲那些改变历史的英雄，讲那些一波三折的故事。我常常思考有些企业和个人为什么会成为业界名人，而有些人则默默无闻；一些巨头惺惺相惜，而另一些巨头则对抗激烈。这些故事的背后无非是各种人生际遇作祟。如果你只知道iPhone和乔布斯，那还不够，这本书会告诉你最早期有一个叫做“家酿俱乐部”的组织，它影响了许多产品的发展。如果要追溯到更早之前，你会看到早期黑客如何利用智慧改变世界——正是如此，所以我们才能享用他们的科技成果。《群体的智慧：如何做出最聪明的决策》最近随着一系列的网络事件，粉丝经济和社群经济等观点开始成为“街货”，似乎都可以谈一谈社群的意义和发展。但社群的影响和发展早在之前就已经有大量学者在研究。人本身就是群居动物，所以社群难的不是聚在一起，而是如何壮大并拥有独特的调性。因此，我推荐《群体的智慧》是希望更多人看到群体在社会各个领域可以发挥的价值和影响。尤其是对于做社区产品的人来说，研究好群体内的决策和在不同场景下的走向，是非常有价值的。本书讲述了大量的案例，涉及多个领域和经典场景的分析，可以认为是极佳的科普作品。我觉得最重要的事情是，这本书让读者拥有了一个全新的世界观，可以更好地观察世界。《自私的基因》（The Selfish Gene）如果你能看到这本书，至少应该庆幸：因为你基因的“自私”，所以你才在重重阻碍下获得了。当然需要提及这样一个前提：自私的基因，谈的是基因，而不是个体，与日常所谓的“自私”有相当大的差别。本书的内容和写作风格非常适合阅读，尤其是一些形象的案例，让人读了欲罢不能，恨不能每一页都认真地琢磨。大部分人对于人类自身的存在和整个世界的存在，视野局限于进化论，但又不知道进化论的本质和衍生的一些现象。如果你好奇自我的存在，除了通读弗洛伊德，还应该看下理查德·道金斯的《自私的基因》。或许在一些聚会上，你可以故作深沉地这样开场：在座的各位都应该为此感到庆幸，因为我们的自私。《跨越鸿沟》（Crossing the chasm）如果说要有一本书既能运用于传统行业，又对互联网行业有所启示，还能真正地运用方法论获得成功，我首推看这本书。《跨越鸿沟》是我从事产品经理以来经常阅读的一本书。全书从产品生命周期的角度，细细阐述了在产品的每个阶段会遇到的机会和风险，跳板和鸿沟。为什么要提及这些问题呢？因为对于市场人员，甚至是产品经理来说，了解用户是第一要务，也是非常难的事情。假想一下你无法通过产品接触到用户群，你甚至不知道他们心里真正在想什么，这是多么可怕？在历史上又太多的产品无法跨越鸿沟，走到下一个生命周期，而杰佛里·摩尔用自己的经验，搭建了一个基本的框架，可以帮助许多从业人员获得启发。通俗地说，他在做一件好人才做的事情：站在大坑边上，提醒每个经过的人，不要掉进坑里。信任他的人可能因此成功，不相信他的人，大部分都在坑里。《大教堂与市集》（The Cathedral and the Bazaar）互联网从业人员不了解“开源”和“软件工程”是一件很丢人的事情。想要了解这两点，不如从这本书开始。薄薄的书本只需要花费两个小时就可以读完，但我相信你还会回头再看一遍。本书主要讨论两种不同的自由软件开发模式︰大教堂模式（The Cathedral model）︰原始码在本模式是公开的，但软件的每个版本开发过程是由一个专属的团队所控管。市集模式（The Bazaar model）︰原始码在本模式也是公开的，不过却是放在因特网上供人检视及开发。软件开发模式或许太枯燥，但更吸引我的是这本书其实讲了另一件事情：如何利用开放的力量把一件事情做好。例如最经典的维基百科和Linux其实是市集模式的最佳代表。如何把一群互不认识的人聚在一起贡献自己的力量，如何把这部分力量聚合起来，让所有人都可以使用。回想前面谈的关于社群的一系列介绍，这本书给出了一种可执行的模式。这种模式真正让人意识到了社群的力量。能在人类社会发展过程中，出现这样一些共享且有价值的东西，是非常值得琢磨的故事。《精益创业》（The Lean Startup）创业是一件听起来非常酷，做起来却非常难的事情——资金首先是难题；其次是人才；最后是商业模式。其实最奇怪的是，整个创业流程中竟然没有一个团队提到了“用户”或者是“用户价值”这样的说法。埃里克在《精益创业》（The Lean Startup）中想要告诉这群充满创业理想，希望像乔布斯一样改变世界的人们，不要进入这样一种创业的误区。这套“精益创业”的理论中涵盖了创业前期、创业初期和创业转型期等整个过程，他提倡的方法论为互联网创业者们带来了一套可以践行的理论框架，也为投资者如何有效地保证自己的投资回报，选择一个优秀的团队提供了一种思路。《我在通用汽车的岁月》（My Years with General Motors）任何对于管理感兴趣的人，都至少应该知道这样两个人物：德鲁克和斯隆。斯隆在通用汽车的日子展示了一名合格的职业经理人应该有素质，他的经历让人时常回味许久。如果说德鲁克的一系列著作略显温和，斯隆则显得更专业化和强硬，他所提倡的一系列准则，都非常震撼而实用。《免费》（Free）信不信由你，克里斯·安德森这本书最佳的实践应该在中国。对于大多数人来说，免费是一种难以想象的商业模式：都免费了，还怎么赚钱呢？《免费》一书将会解答困惑。对于互联网从业者来说，免费的模式并不陌生，其实这个模式有一个大前提：边际效益正向增加。在国外曾激烈讨论过这样一个话题：免费使用产品的人，不是用户，而是商品。为什么这样说呢？因为免费并不是真正地免费，而是一开始把核心服务的使用成本转移到其他业务上。比如早期游戏是收费模式，后续也改成了免费模式，而维持游戏运营甚至盈利的业务来自于哪儿呢？那就是虚拟道具。相信读者也会联想到许多国内产品的玩法似曾相似，这就是我说的观点，免费的最佳实践应该在中国。（本文作者现任职腾讯手机QQ产品经理。长期在个人博客huchao.me上分享对产品世界的思考。由其本人写作的新书《缔造企鹅：产品经理是这样炼成的》现在网站上预售。）
[责任编辑：jasongwang]
您认为这篇文章与"新一网（08008.HK）"相关度高吗？
Copyright & 1998 - 2015 Tencent. All Rights Reserved
还能输入140字交互设计师与产品经理如何更好协同？
交互设计师与产品经理如何更好协同？
摘要：最近遇到的问题和听到的话：
和别的公司UED团队的朋友聊天，聊到与产品经理的合作，该同仁叹息说：PD当道，UED缺乏理论基础，很难搞定他们……
在腾讯一位设计师的培训文档中，醒目地写道：“产品经理很强势，我们的话语权在哪里？”
——为什么设计师和PD在很多人看来是PK，搞定与被搞定的关系？
在最近的项目中，由于对一位PD的BRD中的某些商业需求有点疑 ...
最近遇到的问题和听到的话：
和别的公司UED团队的朋友聊天，聊到与产品经理的合作，该同仁叹息说：PD当道，UED缺乏理论基础，很难搞定他们……
在腾讯一位设计师的培训文档中，醒目地写道：“产品经理很强势，我们的话语权在哪里？”
——为什么设计师和PD在很多人看来是PK，搞定与被搞定的关系？
在最近的项目中，由于对一位PD的BRD中的某些商业需求有点疑问，去和他质疑，话不投机时，被说到“到底谁是PD啊？”
——交互应该做什么，不能做什么？产品经理呢？
在BRD里写到“每页多少条产品，分两栏排放”，设计师怀疑：“这难道也是商业需求？”那还要设计做什么？
——到底什么是商业需求？BRD是指路灯还是限制？
好像，产品经理与UED，尤其是UED团队的交互设计师这样的角色之间的关系是很多人在探讨的话题，以前，还看到一句呐喊：
如果用三个关键词描述这些文章以及这些话语，我倾向于使用：交织，冲突与迷茫。
在有UED与产品经理设置的公司里，每天都在发生这样的故事。由于以前我并非从事交互，而是从事产品策划的（名字不同，其实做的事情类似于pd在做的），尽管有足够的心理准备，可是在最近的项目合作中，也和产品经理红过脸，也迷茫过，这位产品经理还是我比较欣赏的一位，激情，也有良好的用户体验意识，也比较主动。在争执中，我发现，有时是因为流程，有时是因为文档和工具，有时是因为态度——不知道该如何更好沟通和合作。现在冲突随着项目进展已经尘埃落定，而我们经过磨合也逐渐找到了更好的合作方式。
但是感谢这件事情，让我这段时间除了工作之外，一直在为“交互设计师与PD如何更好协同”而思考。同时，一些有经验的同事，给了我一些很好的建议与引导。写下来，一为记录，二为继续探讨。毕竟，现在没有完美的解决之道。
为什么两者的合作会出现问题？
1. 职责的交集与交织
从原则上讲，产品经理是为产品整体成功而负责的，要考虑的是what and why的问题，而UED要考虑的是How的层次，即在接受到商业需求后，考虑如何去实现并最大化保障用户体验良好。用一张图来表示：
概念中的合作流程
先从商业需求，其次有设计。先明白产品是什么，然后研究如何去做，先有目标，其次有方案。
但是，如果真的是这样，那么就像一对永远都不红脸都不吵架的夫妻一样不正常，也许这两个人要么其中一个都没主见，要么两个人都没主见，或者在混日子。真正负责的产品经理和UED都会越过边界（也许根本都不是边界）去挑战原本“应该”属于对方职责范围内的东西：
现实中的相互挑战
现实中，UED会挑战PD的商业需求，他认为这个需求不合理，不但无助于商业目标，还会损害用户利益。
或者，UED会认为PD单纯考虑本产品线的利益，而没有站在全局的眼光看问题。
PD当然也会挑战UED的设计，他认为UED没有正确理解他的需求的意图，或者只实现了他想要的效果的60%，PD觉得他的解决方案才是最合理的，并且对用户体验影响不大。PD没有时间过多解释需求背后的why，又担心UED理解不了，甚至会直接将线框图写到需求文档里，直接将solution就给出来的pd貌似是越来越多了，反过来，UED也会抱怨，PD的线框图和过细的需求描述会限制他们的设计……
而，从两者的职位设计上，本来就是要求有交集的.
一则招聘产品经理的描述：
岗位职责：
1. 基于目标和产品生命周期下的产品推动；
2. 以产品设计为主要的工作，并提供具有前瞻性的产品设计建议。
职位要求：
1. 有互联网平台级产品的设计经验，对Web2.0网站有深入的了解；
2. 对互联网产品有良好的抽象能力和结构化的能力；
3. 具有推动事情发展的内在冲动和获得解决办法的能力；
4. 熟练掌握Axuerp等原型设计软件；
5. 可以在压力下工作；
6. 从事产品经理工作一年以上，三年以上工作经验；
7. 研究生或者重点大学本科以上学历。
交互设计师的描述：
职位描述：
1.参与网站产品前期的规划构思，完善产品概念。
2.归纳网站产品界面的人机交互需求。
3.设计网站产品界面的信息架构、用户操作流程等，给出产品原型。
4.可用性测试，持续改进产品。
职位要求：
1 2年互联网产品设计经验。人机交互／心理学／软件工程／工业设计或相关设计学科的学历。
2 熟悉网站产品开发流程。熟练运用用户访谈，角色定义，故事版，概念图，网站地图，线框图等交互设计方法，有日志分析能力者优先考虑。
3 基本的视觉语言表达能力。手绘／草图，Photoshop，Dreamweaver等原形设计工具熟练运用。懂CSS，DIV或 Javascript，ActionScript 者优先。
4 良好的沟通与语言表达能力。具有责任心，工作目标感与计划性；良好的团队协作，执行力与学习能力。
5 对互联网有强烈兴趣并具有一定的商业灵敏度。富有创造力和激情，具备一定的眼界。
在很多小的公司，两者的角色是完全可以合二为一的。
2. 都不属于成熟的行业，没有较成熟的工作方法、流程与工具
除了职责的冲突，交付物也会有冲突。最明显的就是BRD与线框图的冲突：
BRD:business requirement docoment，商业需求文档，是由pd产出的。
wireframe：线框图，是由交互设计师产出的。
产生的冲突有：
1）. BRD不是写抽象的商业需求，而写的是具体的解决方案，从一开始就细致到：页面左栏增加一个新栏目，右边的产品列表区域提供tab切换，每页显示32条……而且,BRD里甚至都已经有了线框图。交互设计师拿到手中，由于职业的敏感性，会与PD先就具体形式展开讨论，双方纠结于纠结于具体的设计方案，忘记了项目还停留在讨论原始需求的层次上。
2）. 对什么是商业需求，什么是功能性的需求以及设计方案的需求？双方理解不一致，有时都很迷惑。
设计师拿到一份需求文档后，首先得清楚什么是可变的，什么是已经确定的不可变的。设计师认为“使用下拉方式”还是“radio button”，抑或是tab方式，有没有二次确认页，有没有步骤提示是可变的，属于体验设计的范畴，而PD有时也会认为这是商业需求，UED不能够随便处理，因为他已经在BRD里描述得很清楚，一旦改变了，会影响到商业逻辑（不可否认，有时看似只是形式的变化，确实会影响到功能需求和开发量，但是是不是商业需求呢？）
带着迷惑，我在互联网上搜索资料，邂逅了一些不错的老外的博客，老外做事一向很认真，有一个叫michael的产品经理写了一份文章详细说明BRD,MRD,PRD,FSD……等等应该写什么。
但是老外的东西未必适合中国国情，况且每个公司都不一样。
再想一下，产品经理明明可以只写简单的几条商业需求就解决的问题，为什么会多费一些事，将solution和how的层次，甚至界面元素都写到brd里呢？
站在他们的位置思考，似乎是合情合理的：
第一，为了更好说明商业需求。他们需要向高层汇报，为了让高层在短时间就明白产品，不得不用更加形象的方式。我在以前的公司做策划，本来也是只写策划方案的，结果每次给老板宣讲，都会被问到一个问题：“你讲的不错，可是它到底是个什么东西呢”，于是我只好做线框图，下次展示线框图的时候，老板又问：“难道我们真实的产品就是这个样子吗?”为了让他们更加确信产品的形象和价值，我又只好上了色，做了质感效果给他们看，于是不小心就全做完了。
第二，直接表达解决方案比更加抽象去定义产品要简单得多。
第三，对设计师的缺乏信心。其实我在交付线框的时候，也会担心视觉设计师会发挥到改变了我原先定义的信息的优先级定位，也会不时跑过去看，甚至在线框里加了一些视觉的要素，证明我的想法。同样，产品经理也会担心交互设计师不能够正确理解他的商业需求。干脆将DEMO给出来了事。
3. 人本位的思想——本性
不可否认，人的本性就是喜欢被赞同被认可，不喜欢被挑战被质疑。虽然我们已经都怀抱开放的心态，对事不对人，但是在具体的案例中，稍不留神，就会从对项目需求的争执与意见不合，上升到对对方本人以及工作合作态度的质疑层次上。这就比较危险了。有色眼镜会为日后的合作不畅埋下伏笔。因此，双方需要及时坦诚沟通。
双方就是如来佛绑在一起的灯芯，注定要纠缠不休。不求完美协同，如何更好协同工作呢？
很多文章在探讨“PD”与“UED”的双赢，我倒持怀疑观点。双赢是建立在各自有不同的目标，彼此折中或者妥协以求得各自目标的实现。而PD与UED的目标是相同的，那就是成功的产品。成功的产品是要能够达致商业目标的，同时也必须是用户体验良好的（否则也不利于长远的商业目标），所谓商业需求与用户体验之争的论述本身就是一个悖论。
那，怎么做呢？在此，继续半瓶子水晃荡，抛砖引玉：
对于双方：
1.承认冲突的必要性：完美协同的前提就是双方要承认冲突的必须性和合理性，建立对事不对人的原则。
2.目标一致性：双方多就需求的原因以及目标进行沟通，尤其在就具体的设计方案纠结不清时。不要受别的文章影响，而将彼此放到pk的角度上，记住，你们是guys，是伙伴。
3.尊重彼此的专业领域：沟通，沟通，再强调也不为过。双方虽然有交集但是由于侧重点不同而形成了自己的专业领域。在自己的专业领域，有主见，但是要认真听取对方的意见和建议并合理吸收，在对方的专业领域，有问题就提出（立足点是对项目有利），有建议就抛出，但是要注意沟通方式，不能够因为自己看到了对方没有考虑到的东西而沾沾自喜，以为自己有多高明。自己的建议要抱着“仅供参考”的态度。
1. 在BRD阶段不要太多关注细节：将精力放到产品的战略层上而不是具体的解决方案。产品的核心竞争力不是某个控件，某个排版方式。
2. 告诉我你要做一个什么样的功能以及为什么要有这个功能，它的重要等级如何，而不是直接告诉我这个功能要怎么去做（放哪儿，什么方式等）。
3. 脑子里可以勾勒解决方案，但是尽量不要写在文档里——因为要实现一个目标，解决方案会多种，而且会变化的，写到需求文档里只会让日后反复修改的几率上升，而且一旦需求分析人员和工程师参考你的文档，又看到不一样的线框，他们会迷惑。
1. 尊重你的PD，再尊重一些。
UED有时会把PD看成急功近利的一群人（不代表全部），说实话，受一些观点的影响，我刚开始也觉得PD就是这样的人，他们由于背负了具体的考核指标而急功近利，“不择手段”添加入口引流量，引会员。后来我越来越感觉到做pd不容易呀。一个身负全责而没有任何权利的人，一个PD要协调多方面的资源来保证项目的实施，同时还要保持清醒的大脑来写各种文档。说真的，我宁愿一门心思去搞线框……
2. 多问为什么，多了解需求背后的原因和限制，并一起实现。
若遇到你觉得不合理的需求时，先别急着就反驳，先问为什么。也许产品经理真的是平衡了各方面因素的结果。在上一个合作项目中，我发现一个非常不合理也非常影响用户体验的需求点，并且在偌大个互联网上找不到可参考的范本。去问产品经理，没想到他其实也是无可奈何，因为那是来自法务部门的要求，有法律方面的考虑。如果真的是这样，作为UED就要去考虑如何减少这种需求在体验上的负面影响了。
更多的，需要在实践中不断总结，也希望同行多多交流.本文仅代表一家之言。
参考文章：
本文来源：
版权所有:非特殊声明均为本站原创文章，转载请注明出处：
订阅更新:您可以通过
您可能感兴趣的文章