我在微博上抛出了一个问题：敏捷开发，在没有项目经理的前提下，如何协调产品经理、交互设计师、开发工程师在一个需求或交互上的不同看法？得到了好友们的关注，现在在这里做一个小结。
移动应用开发团队，共有以下五种角色：
- 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 ——