优界网

首页 > 产品经理 > 我的产品协作经验

我的产品协作经验

46

0

0

2015-05-14 13:31:23

江大可

分享一下,又不会怀孕!

本作品为转载作品,版权为作品原作者所有,感谢上传者的分享!

小芒果导读:产品经理的日常少不了和各个部门的同事打交道,那么该如何与工程师、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设计师出图。这样当版本完成后,下一个版本的视觉稿已经准备好了,我跟工程师当面讲一遍需求,研发开始,无缝衔接。

已有0人赞过

+1赞

认真评论的都成大咖了

还可输入1000个字

我要评论 我要评论
  • 刚刚
  • 登录优界网 ×