小芒果导读：产品经理的日常少不了和各个部门的同事打交道，那么该如何与工程师、UI等协作呢？

之前写过一篇《我的产品设计流程》，很受欢迎，这是它的续篇，讲一些PM与其他岗位协作的经验。

1、

在大公司里，往往技术的人坐一起，产品的人坐一起，UED的人坐一起，这很糟糕。首先，PM的座位应该紧靠着工程师，近到有任何问题，工程师只需要喊一嗓子“XX，你过来解释一下”。如果距离遥远，必须依赖文档、邮件、IM沟通，这会大大降低工程师与PM沟通的频度与深度，把工程师的角色从“讨论实施”拉低到“接单执行”。

其次，UI的座位也应该紧靠着工程师。一个视觉效果是否容易在技术上实现，走过去问问就知道了。而工程师研发时找到视觉稿上的问题，只需要喊一嗓子“XX，你过来看看这个”。UI设计师与工程师的紧密沟通，不仅提升了研发效率，也提高了UI的技术敏感性。

归根结底一句话，紧密团结在工程师的身边。

2、

一个有经验的PM，应该能搞清楚哪些产品细节偏界面，需要和UI设计师一起讨论决定；哪些产品细节偏后端，需要和工程师一起讨论决定，而不是大包大揽在自己身上。

蝉游家的产品是这样的，我出主干设计，然后UI设计师会提各种界面修改意见，工程师会提各种功能与算法修改意见。有些甚至会反过来，比如我列举功能清单，工程师来设计后台，然后我提界面与交互修改意见。又或是我提出影响排序的5个要点，我和工程师头碰头地讨论两三个小时，一起把排序算法给定下来。

对PM来说，借力很重要。人家专业就让人家来嘛，让UI设计师和工程师一起设计产品，不仅效果更好，也增加了队友的参与感。但如此简单的一个道理，在拆分成产品部、研发中心、UED这三个部门时，却很不容易实现，被画地为牢所困。你是提单找麻烦的，人家是接单擦屁股的，早点做完这一单再接排队的下一单，谁跟你是队友。

3、

蝉游家基本上没有PRD……我跟工程师是老搭档，我先出Axure原型，UI设计师用Skech转成视觉稿，前端效果对着视觉稿讲一遍，后端功能在Tower上列出来就可以了。工程师不明白的地方，随时吼一声，我随叫随到。这倒不是我懒得写PRD，而是工程师懒得看PRD，反正PM是犬科召唤兽，随时叫过来当面讲解，比看文档轻松多了。

虽然没有PRD，我却要写测试用例。蝉小队没有专业QA，我就是QA。我的测试用例用Mindjet来写，相当之简陋，但覆盖了全部的测试分支，且层次清晰。写用例对于PM整理思路大有益处，经常发现一些漏掉的功能点，又能实现PRD的存档价值。

更重要的事情是PM自己来做测试，通过测试流程，逼着PM反复使用产品，反复把玩每一个细节，反复体会是否达到了设计时的用意，然后快速修改细节，调试到满意的地步。指望设计稿“一步成型”是不现实的，总有设计时考虑不周全的地方，在真实使用中才能找对感觉，而测试就是对“真实使用”的模拟。

我经常会遇到这么一类情况，某个交互细节，测试时第一次通过这里，隐隐觉得不对劲，但又讲不出来。第二次，第三次，第四次，第五次，终于别扭得受不了了，然后才能总结出来，哦，原来是这个原因，改改改。如果我没有兼任QA，仅仅是最终验收，就没有这种“反复把玩”的机会，停留在“隐隐不对”的认知盲点上，无法找到答案。

所以我有一个粗暴的观点，PM不愿意兼任QA就是偷懒。虽然专业的QA能做更细致，更偏僻的测试，也能做PM搞不定的技术向测试，但即便有了这份保险，PM还是应该亲手测试，在产品发布前给自己一个发现与改正错误的机会。

4、

蝉小队在产品调试阶段高度依赖Tower。先开好项目，比如“蝉游攻略iPhone版”，按产品模块创建十几个任务分组，然后在分组里填写功能需求与产品bug。需求和bug不分类，但会用#1.2来作版本号标记，用！来做优先级标记。由于在一个页面上平铺开全部任务，排序整洁，又有分组与标记的索引，看上去十分清爽。

随后工程师筛选出自己名字下的需求，把当前版本的需求全部清掉，有问题就回帖(进入编程状态后他们懒得理我)，最后通知我去验收。我把已完成任务挨个过一遍，发现没达到要求，就备注一下重新打开。整个过程轻盈无比。

每一个大版本，当Tower上的任务从100+减少到0，版本就完成了。我不愿意设置严格的deadline，如果时间卡得太死，会影响工程师的情绪，急着做完，而不是和我一起耐心调试细节。版本发布早两三天，晚两三天很重要吗？我觉得不重要。大致保持一个月一个版本的节奏就好了，为了赶半周时间搞得情绪紧张，很划不来。

5、

有人在微博里问我，如果PM兼任QA，如何有时间准备下一个版本的PRD呢？

不不不，我这边根本没有“准备下一个版本的PRD”这个环节。

刚才讲过，我习惯把需求和bug混合写在Tower上，按产品模块分组，这里的需求既包括当前版本，也包括后续版本。我想到任何值得做的产品点，立刻发到Tower上，把Tower变成一个需求池。而工程师只管当前版本号下的任务，没写版本号的就略过不看，再加上我会按任务优先级拖动排序，并不显得凌乱。

因为我是个急性子，哪怕是很久以后才能排上的需求，只要我有空，就会提前把原型画出来，提前拉工程师、UI和运营过来讨论确认。于是我会有漫长的时间，对原型设计进行反刍，在开发之前发现各种改进的可能，同时也将每个版本设计分解掉，用碎片时间来解决。

既然需求与原型都已经搞掂，在一个版本研发的开始阶段，我只需要花10分钟，把Tower上全部未完成任务看一遍，给其中一部分标记下一个版本号，比如#1.3，再请UI设计师出图。这样当版本完成后，下一个版本的视觉稿已经准备好了，我跟工程师当面讲一遍需求，研发开始，无缝衔接。

#专栏作家#

纯银V，蝉游记创始人，人人都是产品经理专栏作家。前网易网站产品部总监。一个文艺加文笔好的产品经理。

本文系作者授权发布，未经许可，不得转载。