您的位置: 首页 > 技术文档 > 网站建设 > 互联网运营期产品评审杂思
社区初建十四条 回到列表 产品经理是炮灰
 互联网运营期产品评审杂思

作者:yeeach.com 时间: 2011-03-29 文档类型:转载 来自:yeeach.com

评审制度是互联网产品管理的重要手段,评审制度贯穿于产品管理的战略规划、产品设计、技术实现、产品运营、产品营销等各个环节。可以说高效的评审制度是一个公司产品管理能力的重要度量标准。简单列举一下评审制度的一些价值所在:
  • 通过评审制度可以帮助利益相关方达成对产品建设目标的一致理解;
  • 通过评审制度可以对产品规划方案、产品需求方案、技术方案、运营方案、营销方案等的质量进行把关,提升产品品质;
  • 通过评审制度可以对产品规划建设过程中的关键点、风险点等进行把关,降低项目实施的风险
  • 通过评审制度可以有效提升参评人员的能力;
  • 通过评审制度来对方案进行把关,保证系统产品架构、架构设计的精神始终如一地贯彻下去

尽管产品评审如此重要,但似乎没有哪家公司的评审制度是高效的,大家都在抱怨评审制度的万千罪恶,评审会议或是演变成了过形式,或是演变成了各大阵营的PK大会。关于评审制度,在各种软件工程的图书及方法论都有所涉及,这里的重点不是讨论评审制度的通用准则(例如 产品评审那点事  ),这里主要讨论一下一个平台型的产品在运营过程中怎样通过评审制度来把关。

1、建设期项目 VS. 运营期项目

对于诸如支付平台、开放平台这类采用了产品平台理念的互联网产品(产品平台),其处于建设期的产品的项目管理与处于运营期的产品的项目管理所面对的挑战不尽相同。

之所以强调这些产品平台,主要在于对于很多互联网产品而言,主要逻辑就是网站前端,因此这些网站的评审相对容易,只需要采用原型驱动的方式。但对于这些平台化产品,不单纯只是一个简单的网站页面开发工作,这些系统最复杂的逻辑一般在于后端的业务规则、业务逻辑,而这些并不是一个原型就能够说明清楚的。

  1)、建设期项目特征

  • 项目周期相对长,例如1个月以上
  • 项目资源相对于充裕,可以以单独项目组形式运作
  • 项目管理可采用传统项目管理方式或者敏捷项目管理方式
  • 项目前期准备工作相对充裕,例如产品文档相对完整、完整的原型、完整的项目计划、项目立项讨论会/需求讨论会等、市场调研/竞争对手产品分析等等
  • 项目相对独立,受到其他项目的约束较小

  2)、运营期项目特征

  • 周期较短,大部分为2周以下
  • 资源有限,项目组成员可能还要并发维护其他产品

由于随着公司业务的扩张,熟悉产品及技术架构的人员始终稀缺,这些人一般都去负责一些重点新项目,必须在工作中帮助新人熟悉系统

  • 项目管理一般采用诸如Scrum、XP这样的敏捷项目管理方式,甚至是裁减过的敏捷开发
  • 项目准备并不是很充裕,也不可能准备充足后再做
  • 项目需要在现有产品基础上进行优化、重构,不能影响现有系统。对于运营型产品,产品架构、系统架构的就是在一点一滴的修改中失控、变形的,必须有机制来控制这些因素

这里重点讨论运营期的产品评审、技术评审的方法。

2、运营期产品评审的原则

  • 不管再紧急的项目都必须做产品评审、技术评审
  • 评审必须保持敏捷性
  • 评审的形式不重要,评审!=开会,评审的形式可以正式评审、也可以为非正式评审。评审最核心的是需要有熟悉系统、有能力的人对方案进行把关
  • 评审的目的不是找到最优的方案,而是在现有资源约束下最合理的方案
  • 没有完美的评审制度,关键在实践中持续优化评审制度,建立适合自己公司情况的评审制度及跟进措施

3、运营期产品评审的方法

对于运营期的产品评审而言,并没有最佳的实践方案可供参考,每一家公司都有自己现实的业务状况,不同的业务模式有不同的评审方式。可以说对运营期的产品进行高效评审是门平衡的艺术,必须均衡管理规范性、敏捷性、业务现实的要求。只不过整体而言,运营期产品评审的方法核心都是相同的:基于团队协作前提下的持续完善。

  • 运营期的评审制度需要运营期的产品研发流程支撑。应当制定针对运营期产品研发的简化流程(相对于建设期的产品研发流程而言),以便从其他流程环节的收集暴露评审制度的问题,来保证产品评审制度的持续优化。例如通过质量测试、运营、销售、营销等环节的反馈,发现评审制度失效的项目,纳入到案例库,持续优化研发流程、评审制度
  • 建立必须进行评审的硬性标准,细化成可量化的checklist形式(简单为第一准则)

例如开发时间1周以上或少于1周但涉及重点业务模块的都必须过评审。之所以要采用工期及影响1刀切的方法而非采用接口人来评估是否需要评审,主要是避免太多的人为因素导致评审制度流于形式。

对少于1周且不涉及重点业务模式改动的,由负责人来自行判断。

  • 评审必须有利益相关者参与,不能单纯让产品人员、技术人员自己评。例如:产品方案必须有技术人员、运营人员、财务人员等;技术方案必须有产品人员、架构师、业务专家等。参与评审的利益相关者有权将方案打回重做。当然这有涉及到另外一个更大话题:团队协作问题,如果一个团队无法建立信任关系,那再完美的制度都会变成PK会。
  • 评审人不需要做全面评审,只对需求关键点、关键业务规则、风险点的方案做评审,以保证评审的高效性。评审结果需要记录相关的流程表单中。
  • 建立评审案例库,定期(每月)过评审案例库,持续优化评审制度。评审案例的总结对事而非对人,不要让评审人有必须对结果全面负责的负担。

一个制度的执行不在于制度最初定义得多么的完美,关键在于制度能否持续不断地优化。持续优化/持续改进/持续完善 是各种管理方法众所周知且行之有效的核心秘密之一,但也是最难贯彻执行的,尤其是相对于那些管理时尚流行语,提持续改进太没新意、太没高度了,于是乎我们都指望有“银弹”来解决面临的各种问题。

本文链接:http://www.blueidea.com/tech/site/2011/8370.asp 

出处:yeeach.com
责任编辑:bluehearts

◎进入论坛网站综合网页制作版块参加讨论

关键字搜索 常规搜索 推荐文档
热门搜索:CSS Fireworks 设计比赛 网页制作 web标准 用户体验 UE photoshop Dreamweaver Studio8 Flash 手绘 CG
站点最新 站点最新列表
周大福“敬•自然”设计大赛开启
国际体验设计大会7月将在京举行
中国国防科技信息中心标志征集
云计算如何让安全问题可控
云计算是多数企业唯一拥抱互联网的机会
阿里行云
云手机年终巨献,送礼标配299起
阿里巴巴CTO王坚的"云和互联网观"
1499元买真八核 云OS双蛋大促
首届COCO桌面手机主题设计大赛
栏目最新 栏目最新列表
浅谈JavaScript编程语言的编码规范
如何在illustrator中绘制台历
Ps简单绘制一个可爱的铅笔图标
数据同步算法研究
用ps作简单的作品展示页面
CSS定位机制之一:普通流
25个最佳最闪亮的Eclipse开发项目
Illustrator中制作针线缝制文字效果
Photoshop制作印刷凹凸字体
VS2010中创建自定义SQL Rule

蓝色理想版权申明:除部分特别声明不要转载,或者授权我站独家播发的文章外,大家可以自由转载我站点的原创文章,但原作者和来自我站的链接必须保留(非我站原创的,按照原来自一节,自行链接)。文章版权归我站和作者共有。

转载要求:转载之图片、文件,链接请不要盗链到本站,且不准打上各自站点的水印,亦不能抹去我站点水印。

特别注意:本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有,文章若有侵犯作者版权,请与我们联系,我们将立即删除修改。

您的评论
用户名:  口令:
说明:输入正确的用户名和密码才能参与评论。如果您不是本站会员,你可以注册 为本站会员。
注意:文章中的链接、内容等需要修改的错误,请用报告错误,以利文档及时修改。
不评分 1 2 3 4 5
注意:请不要在评论中含与内容无关的广告链接,违者封ID
请您注意:
·不良评论请用报告管理员,以利管理员及时删除。
·尊重网上道德,遵守中华人民共和国的各项有关法律法规
·承担一切因您的行为而直接或间接导致的民事或刑事法律责任
·本站评论管理人员有权保留或删除其管辖评论中的任意内容
·您在本站发表的作品,本站有权在网站内转载或引用
·参与本评论即表明您已经阅读并接受上述条款
推荐文档 | 打印文档 | 评论文档 | 报告错误  
专业书推荐 更多内容
网站可用性测试及优化指南
《写给大家看的色彩书1》
《跟我去香港》
众妙之门—网站UI 设计之道
《Flex 4.0 RIA开发宝典》
《赢在设计》
犀利开发—jQuery内核详解与实践
作品集 更多内容

杂⑦杂⑧ Gold NORMANA V2