与开发沟通虽然不是我们设计组的核心工作，但沟通不顺畅会直接影响工作效率和成果。
沟通不是一件容易的事。因为以开发的视角，看见我们可能就像瘟神一样自带不详的阴影，每次过来不是改页面改需求就是催进度。一个沟通不好再遇到火爆脾气的开发还有被打的风险。
其实，有效的沟通比肌肉更有力量。沟通和其他技能一样，是可以通过学习和练习提高的。
如何与开发沟通最有效？
一、让开发了解需求的愿景
我们在之前的很多设计中都非常在意交互的全面和具体，而往往忽略背景和产品目标这部分内容的沟通。相应的，有的开发只关注自己负责的开发任务，就像盲人摸象对项目的整体并没有清楚完整的认识。
需求的背景和产品目标，我将它们统称为愿景。愿景看似虚无缥缈可有可无，实际非常的重要。让开发充分了解需求的愿景，有以下几点好处：
- 实现同一个目标，开发可能有更高明的解决方案。
开发长期奋斗在写代码的一线，比我们更加了解前沿的技术。条条大路通罗马，实现同一个功能，开发可能有更成熟、更先进，或更低成本的解决方式。我们应该听取开发的建议，选择最优的方案。
- 对未来变化有所预判，开发在设计架构时会更加注重兼容性和扩展性。
因为市场的变化或领导的要求等各种各种的原因，改更或增加需求的情况时有发生。如果开发能够提前了解需求的愿景，把未来可能出现的变化考虑在内，可以减少后期改动的难度，万一真的要改不至于完全推倒重来。
- 共同的目标让团队更有凝聚力。
愿景是工作的目标也是意义所在。每个开发的心中怀着“让世界变得更美好”的愿望，希望自己的成果可以改变世界。工作有意义对开发是一种无形的鼓励。
拥有共同的目标也会增加整个项目组的归属感，让大家统一战线，成为相互支持共同奋斗的战友。可以通过这种方式，在情感上获得开发小伙伴的支持。
二、小事钉钉说，大事当面说。
开发在工作时会进行大量的逻辑复杂的思考，如果突然被打断，有可能几个小时思考的成果就前功尽弃了。而且重新进入心流也需要启动时间。普通的小问题，像一些特别的小的变动啦，补充的提醒啦，咨询一些不急的小问题啦，可以在线上问，等开发忙完了会看的。
重要的事情，例如比较大的、紧急的需求变动，一定要当面说。不要因为害怕冲突而选择线上沟通。
有研究发现，只有小部分信息是由语言文字传递的。语调、眼神、表情和肢体动作等非语言沟通可以传递更丰富的信息。文字沟通虽然能减轻产品经理的心理压力，却为冲突埋下了更大的隐患。
网络上干巴巴的文字很容易脑补出生硬的语气和铁板一样的脸。相信好多人有过这样的经历，本来是正常的工作交流，微信上越说越生气，觉得屏幕对面那个人没礼貌好讨厌。但是当面聊天时，又觉得对方人还不错，最起码可以维持的礼貌和客气。
当遇到潜在的矛盾，积极主动的面对面沟通，加上真诚、礼貌、解决问题的态度，是避免产生的激烈冲突的良好开始。
三、复盘每一次不良的沟通。
在沟通前做功课，提前梳理需要沟通的内容和逻辑，准备好技术可能质疑的点。预习是提高沟通效果的好方式，不过大部分人往往忽略沟通后的复盘。其实对于提高沟通力，复盘更加有效。
什么情况需要复盘呢？复盘每一次触发双方不良情绪的对话。各位小伙伴一定要对自己和对方的情绪有所察觉。这个就像我们小时候的错题本，记录下每一次失败的沟通，找到原因，持续改进。
记录的多了你会发现，很多分歧并不是真的观点相悖，而且双方讨论的侧重点并没有在一个层面上。设计与开发的知识背景、项目经历和岗位立场天然差异，很多时候对于同一个问题，大家的理解角度各不相同。
出现分歧不可怕，怕的是鸡同鸭讲，双方不知道误解的存在。每次出现误解，正是我们弥补思维盲区的好机会。深入理解开发的想法，学着站在开发的角度看待问题，可无限接近“技术思维”。
有的同学可能会说，很多时候不是理解的分歧，纯粹是技术那个人不好沟通哇！对于这种情况，复盘依然有效。是哪句话触发了对方的情绪机关枪？又是哪句话让对方很受用？复盘可以给我们很多的反馈，让我们找到最适合这个人的沟通方式。
与开发沟通的三大技能
与开发沟通中最常见的三大终极问题：
▍这个可不可以改一下？
这个XX的问题一看就是要改需求了，改需求的理由千万种你可以说老板要改的，用户想要的，但都显得很low。让开发觉得“~%?…,# *'☆&℃$︿★? ，就知道找借口！”
适度的认怂可以安抚一下开发受伤的心灵，但想要长久持续稳定的合作这里需要第一个技能——产品思维的专业度。
对于任何需求的变更产品首先要拿话出来，而这里的说法不应该是推脱。需要的是你的专业度，举个栗子：为什么购物车按钮要改成红色或黄色？为什么购物车的文字用“放入购物车”而不推荐“立即购买”？ 更具说服力的方式是红色和黄色的按钮更具视觉冲击力，而放入购物车的文案会更轻松如同超市购物一样轻轻一放，不会像立即购买那样造成用户的心理压力。慢慢的你高大威猛的形象即可树立起来了！
PS : 这里推荐一本书，大前研一的《专业主义》。期望我们都能用专业的思维方式来解决问题，达到目的。
▍这个可不可以实现？
一看就是又开始脑洞大开，想了一个稀奇古怪的玩意找开发来实现了。对于这个问题的解决之道我觉得有千万种，最好的方式当然是具备一定的技术背景。但我认为解决此类问题还有一个方法和技巧就是——产品见识的广度。
对于我们设计组是否要懂技术也一直是个争论不休的话题，我个人认为需要懂一些。对于很多常识可以自己平时多了解多学习。 但是对于没技术背景的设计怎么办呢？开发说不能实现就不能实现嘛？这时我会建议用自己产品见识的广度来弥补，俗话说的好“没吃过猪肉也见过猪跑”。能拿出案例来给开发演示讲解，让开发明白你到底想要的是什么”
记得看过很多类似的文章，讨论的是我们到底要不要懂技术。有的人觉得不要懂技术，这样不会被技术所限制，可以更好的发挥自己创意；有的人觉得要懂技术，这样更有利于和研发人员沟通。
而目前我们设计组也处于转型阶段，逐步的在了解开发知识，日常与技术人员的沟通向来是没有太大障碍的。同时也喜欢与技术同事们一起研究一些新的工具，讨论一些比较浅显的问题等。但是这不代表与研发人员沟通就完全没有问题，还需要继续学习。
我们目前接触到的开发人员各个年龄阶段的都有，开发人员大部分性格都属于比较谦虚好沟通的。每次有些棘手的问题或无从下手的问题给到开发人员，多数情况下都会得到的回答是“我等下调研一下，看能不能解决。”所以不管我们懂不懂技术，只要需求合理，一般开发人员都是会尽力配合的。与开发沟通需求过程当中，一定不要说：“XXXX功能很简单啊，你看，XXX产品都实现了。”这种话既不会给开发人员增加自信，也不会降低问题在他心中复杂程度，除了引发争吵，毫无作用。
▍这个开发周期要多久？
这是最难以解决的一个问题，特别是对于没技术背景的我们。设计和开发是两个不同的事业部，利益诉求点也不一样。有时一个需求的开发周期评估完全无法接受，但又不知如何反驳。这时需要跟开发相处的终极大招了，那就是——搞基！
实在没有比搞基更高效的沟通方式，跟开发一起吃饭，下班陪开发ＬＯＬ，单身程序猿给人家介绍几个女朋友……
最终达到的效果是开发耽误了一点上线周期都觉得愧对了咱们的兄弟情！
晓之以情动之以理，希望我们设计组的小哥哥们能用自己人格魅力走进程序猿的世界，收获满满的基情(.ﾟーﾟ)。
怎么才能激发开发人员的能动性呢?
一，知道这个开发人员在乎的是什么
他是一个刚毕业不久、满腔激情、想赶快升职加薪的人?还是一个想解决最高难度的技术问题，哪怕产品没人用，只要解决的问题难度足够高就高兴的人?还是一个满肚子主意，极其讨厌产品经理告诉他该做什么的“点子大王”?还是一个有些害羞、很多想法都憋在心里，但其实特别希望自己有存在感的人?知道了他在乎什么，你才能知道怎么激发他的能动性，以及该让什么人做什么样的项目。
- 想升职的开发人员肯定喜欢做老板能看得见的项目，哪怕这些项目没有多高的难度，帮助这些开发人员在老板面前"出出风头”，他们肯定对你死心塌地。
- 技术宅？那你就给他们强调一下，这个项目的哪些技术问题是其他开发人员想想就头疼、根本解决不了的，满足他们的虚荣心。
- “点子大王”?那就找机会表扬他的点子又多又好，就算这个想法是你先想出来的，你也可以在和他交流时循循善诱，引导他说出你的想法，然后赞叹他的想法真厉害。比如，如果你认为应该在视频平台上做一个让用户发弹幕的功能，不要直接和”点子大王”说:”你负责做弹幕”，而是要从问题出发，你可以说”我们的视频互动性太差，用户都不喜欢发评论”，然后引导他说出做弹幕的主意。
- 至于害羞的开发人员，你可以在开会的时候刻意给他们表达自己的机会，他们绝对对你感激涕零，期待和你继续合作。知道开发人员要什么，想办法在现有的项目里给他们相应的机会，会让你们之间的合作事半功倍。
至于怎么知道开发人员要什么，你不如和他约个时间喝杯咖啡私聊一下，了解他的个人情况，你甚至可以直接问他:”你是如何决定自己做的事情有没有价值的，你在乎的是什么?”
二，应该知道怎么和开发人员沟通最有效率
很多开发人员最讨厌的就是开会，因为30分钟的会议打断了他们的思考时间，拖慢了他们写代码的进度。所以要考虑一下这个会到底有没有必要让开发人员参加，可不可以安排到这个开发人员其他会议之前或者之后的时间，这样尽量少地打断他们的思考，以便于他们有效率地编程。你还需要思考，除了开会之外，还有没有其他可以高效做决定的方式，比如罗列出要点发个有道云笔记的链接o(￣▽￣)ゞ 。
怎么催开发人员加快进度?
让开发人员先自己估计需要的工期,然后再设定截止日期。
如果他们预估的工期太长，就需要提出一些问题，弄清楚为什么需要这么长时间，看看哪些部分可以砍掉，到底值不值得为截止日期砍掉这些功能。
开发人员估计完自己需要的时间后，和开发人员说明我们的发布计划，比如某月某日营销团队会开始宣传产品功能、某月某日我们需要开始运营工作等等，这样可以让开发人员了解其他部门的进度,增强他们的归属感。
刚入行不久的开发人员估计工期的能力比较差，如果他们的工期估计得太长，想方设法让他们告诉我工期是怎么估计出来的，然后跟他一起讨论，哪些部分可以用现成的API（Application Programming Interface,应用程序编程接口），哪些部分可以少花些时间。
如果遇到确实要将截止日期提前的情况,告诉开发人员需要提前的详细原因。这样做的目的是，让开发人员觉得你和他是一起的，让他感觉到你的信任、你在思考如何一起解决工期提前的问题。看看有没有什么方式能够重新组合一些计划，以加快工期。
在这里，一定要让开发人员觉得自己是有掌控权的，就算这个截止日期是领导要求的，在表达日期的时候也要尽量体现出对开发人员的尊重,用问问题的形式表达自己的看法，积极地和开发人员一起寻求提前工期的方式。
需要改需求怎么办?
改产品需求是一个非常常见的过程，有些时候前期计划做得很好，开始测试时却发现，用户对某个功能根本不理解，还是需要改动。开发本来就是一个不断迭代的过程，这里就说说有哪些方式能够避免在开发后期改需求，如果真的要改需求，如何和开发人员有效沟通？
- 1.尽早和开发进行产品功能设计的讨论，让他们提前了解各种背景信息。先在产品需求文档中写明需要解决的问题、如何判断成功，并写几个产品方案的初稿，和开发人员进行讨论，回答他们的问题，让他们一开始就参与进来。通过这个讨论过程，知道有什么技术上的局限性，然后根据大家的反馈修改设计。这样可以避免在开发人员花费大量时间后才发现问题，然后重新来过，导致开发人员做无用功。
- 2.如果确实需要让开发们重新写已经写好的东西，或者砍掉他们已经写好的东西，一定要积极承担责任。这种情况，可能是因为你少考虑了某些情况，也可能是突然发生了一些变故，比如公司改变了策略、竞争对手突然"搞事情”。虽然这并一定是你的责任，但是这时你还是应该积极和开发人员交流，主动承担责任，告诉他们:"这个赖我，辛苦你了”。其实很多时候，就算你主动承担责任，开发也不会“顺杆爬”埋怨你，他们反而觉得你靠得住，甚至会过来安慰你。积极承担责任，说句”抱歉，辛苦了”，虽然对你来说就是一句话的事儿，但这可以很好地安抚已经努力工作了一个月、每天加班加点儿的工程师。很多时候，给开发们一些鼓励和温暖，虽然看上去微不足道，但却能让他们干劲儿百倍。
作业：你的一个工程师鄙视你没有工程背景，在做决定的时候并不信任你提出的建议，你该怎么取得他的信任?
