之前写过一篇《我的产品设计流程》，很受欢迎，这是它的续篇，讲一些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和运营过来讨论确认。于是我会有漫长的时间，对原型设计进行反刍，在开发之前发现各种改进的可能，同时也将每个版本设计分解到碎片时间来逐一解决。
既然需求与原型都已经搞掂，在一个版本，比如1.2版本研发的开始阶段，我只需要花10分钟，把Tower上的未完成任务看一遍，给其中一部分标记下一个版本号，比如#1.3，再请UI设计师出图。这样当1.2版本完成后，1.3版本的视觉稿已经准备好了，我跟工程师当面讲一遍1.3的需求，研发开始，无缝衔接。
6、
我就知道，这篇经验总结到最后会写得跟Tower的软文一样。虽然我跟Tower的老沈很熟……但确实没收他的钱，不仅没收钱，我还往Tower账户上汇了2000多元买付费服务。以我现在对Tower的依赖性之强，他家的服务一旦挂了，简直天崩地裂如丧考妣。蝉小队除了产品协作之外，运营管理，编辑管理，行政管理，甚至包括团建，全部通过Tower来进行。我最近空降到一个项目组，就连“空降过渡”这种事情也用Tower来润滑，效果奇佳。这时你一定很好奇，空降就空降，和Tower有毛关系啊？很久很久以后，我再写文章来讲这个故事吧。
