之前写过一篇《我的产品设计流程》,很受欢迎,这是它的续篇,讲一些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设计师出图。这样当1.2版本完成后,下一个版本的视觉稿已经准备好了,我跟工程师当面讲一遍需求,研发开始,无缝衔接。

6、
我就知道,这篇经验总结到最后会写得跟Tower的软文一样。虽然我跟Tower的老沈很熟……但确实没收他的钱,不仅没收钱,我还往Tower账户上汇了2000多元买付费服务。以我现在对Tower的依赖性之强,他家的服务一旦挂了,简直天崩地裂如丧考妣。蝉小队除了产品协作之外,运营管理,编辑管理,行政管理,甚至包括团建,全部通过Tower来进行。我最近空降到一个项目组,就连“空降过渡”这种事情也用Tower来润滑,效果奇佳。这时你一定很好奇,空降就空降,和Tower有毛关系啊?很久很久以后,我再写文章来讲这个故事吧。