用非正式沟通减少需求和交互的矛盾

我在微博上抛出了一个问题：敏捷开发，在没有项目经理的前提下，如何协调产品经理、交互设计师、开发工程师在一个需求或交互上的不同看法？得到了好友们的关注，现在在这里做一个小结。

移动应用开发团队，共有以下五种角色：

PM：产品经理，负责规划产品方向，确定产品需求；
UE：交互设计师，负责设计某项功能的交互方案；
UI：视觉设计师，负责设计界面元素的视觉产现；
RD：开发工程师，负责软件开发；
QA：测试工程师，负责测试；

在这样的团队中，经常会遇到如下情况：

PM定义了产品需求，出发点自然是满足用户在特定场景下的功能需要，希望功能明确，操作方便，简捷易用。

然后UE进行了互设计，作为设计的产物，虽然也会本着简单清晰的思路，但往往又会加入一些纯的“设计”因素，比如一个滑动的操作，一个漂亮的动效等等。

当PM和UE在一起碰设计方案时，PM会意识到额外添加的设计元素不太符合当初的设想，但又没有充分的理由能说服UE，毕竟UE在这方面是专家，是经过“设计”的，会有一堆颜色理论、用户心理、体验数据来支撑他的观点，所以经过PM和UE的讨论以后形成的结论，实际上是二者平衡后的产物，某些设计元素还是会被保留下来。

然后，正式的评审会开始了，参会的有PM、UE、RD、UI、QA。PM和UE要把需求和交互给大家讲清楚，然后大家反馈问题，最后确定一个可供RD编码、UI构图和QA测试的依据。在这个会上，PM和UE之前平衡后的方案往往还是会被大家提出各种意见。显然，与PM和UE的讨论如出一辙，RD、UI、QA这三个角色也无力削减或过多的调整UE的方案，原来PM可能还会寄希望于大家一起评审时能把不太理想的地方加以修正，或者寄望于RD能说出某某交互不能实现。但现实情况是RD会说“那就这样吧，实现是能实现，等到分配迭代任务时看具体的排期吧！”这样下来，评审会的结果只是大家对方案达成了共识，但方案中一些没想到的和不合适的地方还是会存在。如此下去，每一个迭代中的那一点不和谐，最后就会被累积起来，对产品的整体一致性带来不好的影响。

就这样的案例来看，有一些不同的处理方法。

微博用户@快乐的满神_odi说：交互问题，还是产品经理的工作。

微博用户@从武-说：看公司文化和谁更强势,在腾讯是PM拍，在苹果肯定是UE拍了在百度...。

微博用户@YangYuan的微博说：老大说了算。

也有人说这要看哪个角色的承载人强势，如果是UE强势，那PM只好委曲求全，如果是RD强势，没准只看哪种方式的编码成本低就用哪种，其他的点缀可能都免谈了。

微博用户@elya妞提到了另一个方案：解决方法是PM头、RD头和UE头三个人拍，10分钟还无定论的，需求和交互由PM拍，UI由UE拍。

这些方法都可以解决问题，下面我也说说我的想法。

在这种无项目经理的团队中，我的想法是将沟通前置，即多用非正式沟通。当PM提出需求时，先与UE沟通，UE不用急于画正式的交互图，而是用最快速的手绘稿来解决问题，看看主线流程是否能满足PM的需求，经过二者的初步沟通，在主线流程上尽快达成初步意向。此时RD的负责人可以参与沟通，提出自己的看法，并就程序实现上成本高、难度大的地方进行再讨论。有RD介入了以后，PM和UE都可以获得与编码实现相关的重要信息，便于在初期调整需求和交互，减少空中楼阁的发生概率。

在三者的平衡过程中，交互应该能更好的与PM的需求吻合，也能将高成本的实现方案进行变通处理，在主线上就基本可以保证共识的达成了。这时UE的设计元素往往还不多，而且是手绘的草图，是易于调整的。需求也可以在讨论的过程中进一步细化和完善。RD也可以提前了解到PM、UE的想法，并保障在现有的框架下合理成本的实现。

在最后的评审会上，如果能用手绘稿评审也可以用手绘稿，便于修改。人都有这样的心理：我好不容易绘制出来的交互设计方案不能说改就改，所以会上用正式的交互稿的时候，大家就很难说服UE。对PM也是同样，会上发现需求有问题时PM也不太会改正式稿。

如果再极端一点，真的是PM、UE、RD争论不休，倒是可以采用@elya妞的建议：10分钟还无定论的，需求和交互由PM拍，UI由UE拍。武断是武断了点，但至少按照这个结论可以先开发了。

总之，解决的方法肯定还有很多种，而且在不同的条件下可能都有比较好的效果，但是无论如何，强调早期的、及时的非正式沟通我觉得都是很有帮助的，便于在早期讨论清楚问题，也便于相互了解对方的思想。手绘稿也是不错的方法，使用非正式的输出物可以降低修改的门槛儿，使工作更敏捷的进行下去。

抛砖了，希望大家能就这一问题多加讨论，并感谢在微博中给我提供意见的各位好友。

——欢迎转载，请注明出处： http://blog.csdn.net/caowenbin ——

用非正式沟通减少需求和交互的矛盾相关推荐

IT团队之非正式沟通
沟通能力是一种能证明和让对方发现你具有社会工作能力的能力.从表面上看来,它只是一种能说会道的能力,可实际上它却包罗了一个人从穿衣打扮到言谈举止等一切行为的能力. 从大体上,我将沟通分为正式沟通 ...
招聘工作第一步：和业务部门沟通招聘需求关键谈的内容是什么？
招聘工作者要招到最匹配的候选人,首先需要与业务部门负责人hiring manager要保持良好的关系.那么关键要谈的内容是什么?需求和责任.同时招聘工作的HR和招聘需求部门负责人开启在岗位雇佣中的合作 ...
Java豆瓣电影爬虫——减少与数据库交互实现批量插入
节前一个误操作把mysql中record表和movie表都清空了,显然我是没有做什么mysql备份的.所以,索性我把所有的表数据都清空的,一夜回到解放前-- 项目地址:https://github.c ...
非功能性需求_更好的开卡，来聊聊非功能性需求
工作这么几年来,见得最多的场景是 QA 小伙伴满办公室追着开发报 bug,有时候开发会不乐意,"当时可没说要 XXX,要做 XXX." 好像 QA 小伙伴永远比开发多一点心眼,即使 ...
京东-如何让需求沟通不再痛苦
转自本人运营的微信公众号" 携程技术中心PMO"(ID:cso_pmo) 作者简介李国柱,京东敏捷教练.精益-敏捷咨询和培训师,团队创新和成长教练.多个成功产品的创新孵化辅导者. ...
非正式的沟通往往比正式的沟通更有效，更重要
非正式的沟通往往比正式的沟通更有效,更重要作者: 杨争 | 可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息网址: http://blog.csdn.net/yzhz/archive/ ...
项目沟通管理——考点（个人笔记）
28.1 沟通是指有意或无意的信息交换.交换的信息可以是想法.指示或情绪. 信息交换的方法及沟通分类: 书面形式和口头形式正式(报告.备忘录.简报)和非正式(电子邮件.即兴讨论) 有效的沟通三要素沟 ...
java项目经理也就那么回事_网易PM | 我们之前在需求评审环节踩过的坑...
原本觉得需求评审也就那么回事儿,大家应该都差不多这么做的,没啥好说的.不过前不久有一位同学问起来我们是怎么做需求评审的,然后发现有一些团队的做法可能还不大一样,他们也还踩着我们之前踩过的坑,他们还在探 ...
业务方的一堆需求，被我一句话怼回去了！CTO笑而不语，晋升有望了
先思考一个问题,中大型技术团队的研发效能提升,哪个环节最重要? 下图是敏捷方法专家ScottW.Ambler,关于"反馈与耗费成本比较"的图,表达的思想是:需求反馈越晚,浪费的成本 ...

用非正式沟通减少需求和交互的矛盾

用非正式沟通减少需求和交互的矛盾相关推荐

最新文章

热门文章