大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题,从操作层面细细进行讲解和分析,为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”,让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
该内容已经被标记书签!
标记书签错误,请重试!

作者 Roman Pichler 译者 郑柯 发布于 2008年7月10日
Scrum中,产品负责人这个角色具有很大的影响力,但要想运用得当,可没那么轻而易举:如能成功应用,就可以在客户/产品管理和开发者之间建立起全新而融洽的关系,企业也将因此而受益,甚至有可能增加竞争优势。不过天下没有免费的午餐:为了发挥其作用,组织要经常要做出有针对性的调整。这篇文章揭示了成功发挥产品负责人角色作用的奥秘。阅读之后,读者就可以明白:成功的产品负责人需要具备哪些素质。
在Scrum中,产品负责人扮演着重要的角色。它根本不是为老职位设置的新名称,而是重新定义了业务和开发/IT之间的关系。需求的处理方式也在改变,不必再像过去那样,在项目一开始就必须完整描述,冻结之后再转交给开发团队。将管理项目的责任单独指派给项目经理,整个过程中没有客户代表的参与,这种项目管理的方式也变了。取而代之的是,产品负责人通过沟通了解客户的需求,指导产品的发布,并根据眼前的实际情况,不断在团队和项目干系人之间协调。可以这样说,产品负责人扮演了粘合剂的角色,他需要帮助最终客户、产品管理负责人、开发人员和项目干系人达成一致,确保大家都在朝着同一个方向前进。
这个角色通常是由客户或者产品经理承担的,所以业务层面也要开始了解Scrum,并做一些必要的变化与之相适应。虽然实际操作上有不少难度,但产生的结果物超所值。不仅能在业务人员和开发/IT人员之间建立起更融洽的关系,而且能给企业增加竞争优势:用户需求得到顺畅沟通;有专人负责版本目标的定义和发布;决策流程得以提速;误会和工作方向不一致的情况也得以避免。
产品负责人的详细职责包括三个主要领域:客户需求,项目成功和团队合作。
在Scrum中,产品负责人要与客户沟通需求并理解这些需求。不妨将产品负责人想象成企业家:他们从业务价值的角度来制定软件产品的未来发展规划,并与别人沟通自己的想法。产品负责人要填写产品 backlog,并根据实际情况随时修改这些内容:可能要增加新需求,修改已有需求,这通常都是实时性的,而且这些修改都要在下一次sprint 计划会议之前完成。另外,产品负责人要对产品backlog上的条目排定优先级,确保团队总是在处理最重要的需求。
保证项目成功是产品负责人的第二个职责。这包括满足项目目标以及财务目标,如投资回报率(ROI)。产品负责人决定功能、发布时间,从使客户满意度最高和获得最高ROI的角度出发安排预算。产品负责人还要创建并更新发布计划及发布报告。
最后一条也很重要:产品负责人要与整个团队进行沟通协作,在整个过程中与利益相关者保持一致。产品负责人要和团队一起确认详细的需求。在产生疑问的时候,产品负责人解释需求,并根据当初就“完成”标准达成的共识对工作结果进行评估。最后,产品负责人要针对sprint计划会议做准备工作。在会前需要逐步分解需求,让会议可以顺利进行。
担当产品负责人的角色应该是全职工作,特别是涉及到需要大量创新或者很复杂的项目。根据项目的特性和规模,这项工作可以由最终客户、产品经理、市场人员或者客户来担任。
老实说:产品负责人这个角色可不是那么好做的。这些年来,我见过许多产品负责人所犯的常见错误。下面这些是我想告诉大家的。
有些组织认为仅由一个人来担任这个职位很困难。为解决这个问题,他们会让多个人分担产品负责人的角色,例如产品经理负责用户需求,ScrumMaster负责项目成功和团队协作。我把这个问题称作“虚拟产品负责人综合症”。一旦陷入其中,公司将失去产品负责人所带来的很多好处,而且还丧失了本可以因此变得更好的机会。多人执行产品负责人的职责,只适用于多个团队参与同一个项目的状况。在这种情况下,我愿意与一组产品负责人工作,而且其中有一位负责整个项目(有时此人被称为产品总负责人)。
让IT人员或者程序员担任产品负责人,这是另外一个常见的陷阱。这意味着产品管理人员或者最终客户不愿意进行改变,不想担当起产品负责人的职责。“IT 产品负责人” 仅仅是技术和业务的中间人。这个角色将不再具备原本的影响力,也没有人来理解和沟通客户需求。业务人员和开发/IT人员不再为了合作而进行必要的改变,关系无法得到改善。跟以前一样,业务人员将需求交给开发部门之后就不再过问。(话虽这么说,也有特殊情况:如果是涉及多个团队的项目,其中有一个组件开发团队,那么让架构师充当这个团队的产品负责人,盯着他们的工作,这还是挺不错的。)
最后的问题是“蹦极产品负责人”(当然,这个名字来自Dilbert漫画):一个几乎没什么作用的产品负责人,只参加sprint计划会议和复查会议。这类型的产品负责人很难主动控制和指导项目。许多没有答案的问题只能通过ScrumMaster简单的猜想或推测来回答。另外一些产品负责人还会妨碍项目取得进展。无论是什么原因,工作过度还是有其他更重要的工作——不能正常发挥作用的产品负责人会对产品发布起负面作用。
如何能够避免上述陷阱,并成功发挥产品负责人的作用?我发现了三个关键因素:
过去的经验证明,这几个因素非常关键。我发现:一个被授权的、能够全心投入的、称职的产品负责人,和Scrum项目的健康和成功之间,有着密不可分的关系。
“授权” 的意思是指:产品负责人有权力做决定,能为决定所产生的结果负责。这要求产品负责人能够快速做出相关决定,不需每次都要得到管理层的批准。我常常遇到这样一些公司,他们低估产品负责人的重要性,因此而使得产品负责人得不到足够的授权。如果产品负责人被任命领导重要的项目,那么高层管理人员应该为其提供直接支持。另外,产品负责人应该积极参与到发布目标的设定中,这样他就会完全负起达成目标的责任。
“缺乏参与” 最后将影响到项目的产出效率。必要的准备工作无法完成,决策延迟。正如前面提到过的,“蹦极产品负责人”只参加sprint计划会议和复查会议,因此很难迅速、全面地解决项目中出现的问题。他们无法与团队形成持续的协作,导致自己控制和指导项目的能力被削弱。
“称职”包括两个意思:完全了解客户的需求,具备敏捷和Scrum的实用知识。第二点包括能够实行相关的实践,例如准确填写和修改产品的backlog,或以用户故事的形式描述需求。在Scrum里,产品负责人需要接受适当的培训,这样他们才能很好地完成工作,就像ScrumMaster一样。一般说来,将 “Scrum认证产品负责人™”课程和上岗培训/指导结合起来,会产生最好的效果。
为了让产品负责人顺利发挥作用,你可以试试下面的方法:保证管理层都了解这个角色的重要性,并小心选择产品负责人的人选。此外,还可以让这个人投入尽量多的时间以胜任该职位,并远离其它工作的干扰。最后,要从长远发展的角度出发:培养产品负责人——要注意培养现有的员工,让他们准备好担任产品负责人的角色。这要求建立起内部的培训和指导能力。
产品负责人能够为组织带来很好的作用,当想做好却不容易。要培养员工成为好的产品负责人同样面临不少困难。有意思的是,丰田、本田以及其他一些精益企业,在很长时间内成功实施了产品负责人的机制。事实上,这种机制在丰田已经实施了差不多一个世纪。丰田公司的产品负责人被称作“首席工程师”,只有为人称道的资深工程师才能担任这个职位。首席工程师承担了产品负责人职责中的一大部分,同时还要承担首席架构师在开发项目中的工作。虽然首席工程师的工作要比 Scrum中产品负责人更有难度,丰田仍然成功实施了这个角色,并让它成为了强大的精益系统中的基石。丰田的例子说明,如果企业愿意作出必要的改变,产品负责人能够增强企业的竞争优势。
毫无疑问:要发挥产品负责人角色的作用非常困难,但是适当的应用是成功Scrum的必要因素。削弱这个角色的权力也许可以让其更容易发挥作用,可是带来的好处也因此而减少了,所以要抵抗改造这个角色的诱惑。相反,要利用发现的问题和障碍,使之驱动组织进行必要的调整,这将对整个企业起到改善作用。企业可以利用这个角色来增强竞争优势。做出必要的改变是很艰难的工作,也需要花费一些时间。不幸的是,我没有发现Scrum有什么神奇的魔力可以让变化轻而易举地发生。如果我找到了,一定会让你们知道。我保证。
James M. Morgan, Jeffrey K. Liker. The Toyota Product Development System: Integrating People, Process and Technology. Productivity Press. 2006
Roman Pichler. Scrum - Agiles Projektmanagement erfolgreich einsetzen. dpunkt. 2007
Ken Schwaber. Agile Project Management with Scrum. Microsoft Press. 2004
Allen C. Ward. Lean Product and Process Development. Lean Enterprise Institute. 2007
Roman Pichler,管理顾问,精益思想和Scrum专家。《Scrum - Agiles Projektmanagement richtig einsetzen》(dpunkt 2007)的作者。Roman曾与产品负责人一起工作多年。他提供针对产品负责人的训练和指导,包括Scrum认证产品负责人的课程。想了解更多信息,请看www.romanpichler.com。
查看英文原文:Creating Product Owner Success
本次分享将会就大规模视频网站的计费与流量管理这个话题,从操作层面细细进行讲解和分析,为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”,让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
Jeffrey Richter以其多本Windows核心技术的经典著作而闻名,同时,他深入掌握微软的.NET等一系列核心技术,2012年1月,Jeffrey Richter在北京接受了InfoQ中文站的专访,谈到Windows 8和WinRT编程,并就异步编程、Windows编程中的可扩展性、性能和安全性方面给出自己的建议。
云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。
淘宝高度重视Java平台的健康发展,组建了一个团队专注于Java平台的底层部分的性能、功能与稳定性改进;工作主要基于OpenJDK中的HotSpot VM开展,其中一些通用的功能随后也会逐渐反馈给OpenJDK社区。希望能与使用Java平台开发应用的大家交流经验。
本次演讲视频录制于QCon杭州2011。
2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障,导致许多商业网站的服务中断,影响非常严重。作为云计算用户,我们需要思考的是,如何保证即便在云服务不可用的情况,我们的应用架构仍然能够屹立不倒?本文正是站在云计算用户的角度试图探讨这一问题。
12人的技术团队,4组刀片服务器,每月20亿的访问量,每日1次准时部署,99.9%的可用性。这可能吗?当然。想知道如何做的吗?百姓网将与您分享他们在DevOps实践过程中的经验和技巧。
本次演讲视频录制于QCon杭州2011。
篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011。
本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。
1 条回复
关注此讨论 回复