篱笆网结婚频道 项目制产品开发经验分享 沈洁琼 篱笆网产品经理 2010-9-11  PMCamp PM 会议
什么是 CPO ? After: 在家、在公司、在咖啡厅、在…任何地方 上网就能 Before: 向老板请假 和家人、 JMS 约时间 换衣服打扮出门 乘车 / 搭地铁 / 自己开车 到门店等待 在接待人员的“注视下” .. 赶回去 往复如上行为至少 3 次 ?
 
开发流程 & 启示 2010-9-11 PMcamp  上海产品经理会议
产品经理 运营人员、设计师、项目经理 / 核心开发人员 项目 经理 开发 、 前端、测试、 设计师 产品经理、运营人员 决策委员会, owner 开发流程、人员配备 2010-9-11 PMcamp  上海产品经理会议
专业均衡的团队, 商人 + 艺术家 + 工程 师 更好的专业互补 更好的资源调动 更多的火花碰撞 4 月  /   5 、 6 月  / 7 、 8 月  / 9 月 立项、团队组建、调研分析
磨合期,以退为进 花些心思了解成员背景及对项目的期望 留意大伙们的“吸收能力”,适度调整计划 全体出动做调研 4 月  \  5 、 6 月  \ 7 、 8 月  \ 9 月 立项、团队组建、调研分析
为产品做一份“体检表”,并将指标渗透到后续开发、测试、评估的环节中去 产品设计的依归 评估质量的标准 4 月  \  5 、 6 月   \ 7 、 8 月  \ 9 月 策划、设计、技术预研 分类 评估指标 第一部分:全局目标  功能 稳定性 系统响应 体验流畅性 界面设计 内容与界面元素表达准确,结构清晰   文案及界面视觉元素的亲和力   设计规范实施达到率 第二部分:各功能模块目标 相册 上传效率   照片质量   功能易用性 选片 引导系统有效性(订单选,自选,帮选)   归类系统符合用户心理模型
守住子系统的功能边界 谨记功能的需求初衷 允许“不完美”的存在 4 月  \  5 、 6 月   \ 7 、 8 月  \ 9 月 策划、设计、技术预研
把技术 开发部分尽早“包 ”出去 技术资源的协调越早越好 把项目切分成若干子项目,分别迭代 可以感知“开发进度” 可以提早做真实的用户测试 4 月  \ 5 、 6 月  \  7 、 8 月   \ 9 月 相册开发、选片开发、外围功能
每一种文档的用意和用法需要高度对齐 4 月  \ 5 、 6 月  \  7 、 8 月   \ 9 月 相册开发、选片开发、外围功能
产品经理每周亲自做至少 1 次“回归测试” 4 月  \ 5 、 6 月  \ 7 、 8 月  \  9 月 测试、 bug-fix 、公测发布、客照开发
Q&A 更多思考…
谢谢大家! Email: shenjieqiong@liba.com 微博: t.sina.com.cn/dyshen

篱笆网结婚频道项目制产品开发经验分享-PMCamp2

Editor's Notes

  • #2 大家好,非常高兴也非常荣幸在这个漫漫细雨的午后和在座这么多同行一起来做一些专业上的分享与交流, 我叫沈洁琼,设计专业背景, 3 年左右的界面设计工作, 2 年的产品设计,现在负责篱笆网的网络产品团队的管理工作,同时也是一名产品经理,我参与过篱笆网近三年来的几乎所有的大型网络产品开发项目,最近半年一直在开发和屏幕上这些照片有关的一个产品,这是一款以项目制的方式去调研 - 分析 - 策划 - 设计 - 开发的产品,我是以产品经理的角色参与在其中,好,下面我们先来看看这款产品到底是什么?
  • #3 了解了 CPO 的四大功能后,我们再来过一组界面效果感受下:
  • #7 团队初建时,专业配备均衡的团队给我们很多尝到不少甜头;我们是将与要做的产品行业知识最贴近的一线运营人员(主管)抽掉过来 fulltime 的加入,另外产品设计师、界面设计师、项目经理或核心开发人员,都会 fulltime 加入进来,名义上由产品经理带领这个团队的工作,实则大家都以各自的专业背景作很开放的沟通;我这里总结了三点好处, xxx , xxx , xxx ,其中第二点,更好的资源调动,这是这次项目做下来我体会很深刻的一点,之前我们也会以项目制的方式去做产品,但团队人员组成专业相对单一,主要是产品人员或技术人员的组合,潜意识里有点怕引入业务端背景的人员一起参与,觉得这样会比较难对齐思路,影响到项目的推进,然而实践下来,我们发现,并非如此——这个项目需要我们前期做很多“跑出去”的工作,我们实地考察了好多家影楼和工作室的工作流程(特别是选片环节),我们还组织过电话调研,打了大概近 100 通的电话去从实际拍摄过照片的用户那端验证我们在商家那边获得的一些信息,这中间需要作好商家联络,有效样本名单的提取等,运营人员和商家非常熟,我们上午讨论萌生了采访商家的想法,还没到中午就联络了 4 、 5 家商家可以出发让我们去采访了,而且接待我们的都是核心人员,我们获得非常翔实的一手“情报”;值得一提的是由于 fulltime 的加入成员对项目是有归属感的,对项目组要做什么需要怎样对应资源,有很深刻的理解,正因为如此调研效果比之前想到了临时找人帮个忙是完全不一样的。然而也不是把这 3 类人简单凑一块事情就 12345678 的顺理成章的自动走下去了,我们看下一点:
  • #8 无需苛求每一步必须踩在时间点上,赶出来的东西总是会存在很多“先天不足” 一起做的调研:实地走访商家,电话调研,焦点小组,所有人都非常有归属感,并且兴致勃勃
  • #11 这句话主要是对设计背景和业务背景的产品经理说的,当然作为有技术背景的产品经理,我觉得也需要考虑这点,产品经理职能本身就牵涉很多,此刻由一名项目经理来接手后续的项目管理工作是可以把你从一个很专业的知识领域以及后续无尽的细节中剥离出来的好办法,还有很多别的事情等待你去完成; 资源总是不够的,而且当同时需要动用这么多资源才能把这台机器转动起来的时候,决非易事,所以,越早敲定越能使得项目走得更稳健些,这点上我们大概是花了整整 2 周的时间买了教训,整个团队一度陷入空转;不要太乐观,资源不会理所当然的在那等着你的时候去认领,面对资源所有人都如狼似虎,这点相信在座各位也都有不少深刻的经历吧,哈哈! 我们把这次的项目分成了 4 部分,第一轮是相册部分,它很独立,当交付测试后,我们几乎可以正常测试这部分所有的功能,这就抢到了非常多的时候去做用户测试,当然这对设计是提出比较高要求的,弄的不好会前后矛盾,需要作出临时的变更,这会导致一些反复的工作量,最可能受牵连的就是前端,我们这次配备三名前端才扛下了我们的“反复无常”,这是里面还有更多的思考
  • #12 文档不仅仅只为写给别人看而写的,写文档的过程就是帮助自己把思路完整梳理一遍的过程,不写你会心里没底;写了之后呢就要想法子使“文档精神”可以更准确的传递到位,这其实是基本功,每个从业人员都能明白,然后在这上面吃过亏的不少;我们这次的过程中要再次被这事给绕进去过,我们看下这三个图片,这个灰色背景的是原型的页面目录,但一开始前面没编号,大概这次的项目牵涉的页面实在是比较多了点,当原型从设计师发到工程师那边去后,工程师完全看不懂,虽然已经集体逐个 review 过了,但归位后需要自己再研究一遍时,发现根本不知道那些是
  • #13 和写文档是一个道理,不真实去体验一遍过程,心里会没底;总会觉得好像还有很多问题需要改进,随便看看都是问题,然而真实测过一遍后,你会发现你本来觉得非常过分的问题,是被放大的,实际上没那么严重。测过一遍后可以让你对整个产品的情况有一个全面的了解,对后续的很多判断都是非常有帮助的,否则就会陷于无的放矢了。