大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
数字是有效沟通的要素之一但不是全部
作者 霍泰稳 发布于 2008年8月18日
8月12日InfoQ中文站发布的“用数字沟通——来自敏捷精灵的忠告”一文，在敏捷中国社区里引起热烈讨论，发言者大多认为数字很重要，但是单纯地强调数字对敏捷开发并没有太多用处。
讨论由熊节首先发难，对“用数字沟通——来自敏捷精灵的忠告”文中所述的观点，他不甚赞同。原因在于他认为一个对敏捷没有深入理解的开发人员，在敏捷项目中如果依然沿袭传统的开发方法，结果会让自己更加辛苦。随后，讨论针对精确的数字是否有益于软件开发继续进行，来自ThoughtWorks的钱安川认为：
要求精确的数字，确实很扯淡。但是，[很]明显，数字最有说服力。特别是业务人员和管理者，有了数据就可以放心大胆地做所谓的决策。当然，也明显是把责任推卸给了开发人员。
项目管理中，项目的估算和进度的统计数据都很重要。但是，如果只是一味追求数据，那么这样的数据就会不停的偏离真实的轨道。
起步停车对钱安川的关于数据会让项目不停地偏离真实轨道的说法表示赞同，同时以自己的实际情况进行解释：
在我们实际的项目开发过程中， 可以说我们积攒了无数个项目的信息（包括计划、任务、时间估算、规模估算、各类文档，以及他们说需要的估算时间和实际时间，还有代码行数……，可以说要啥有啥）。可是，我们在不断的重复着“昨天的故事”，用历史积累的数据来考量现在的项目……，[并且]美其名曰：用数据说话……
[结果是]开发人员极度痛苦ing……，对这些数据很不屑……
而来自ThoughtWorks的另外一位业务分析师，也是InfoQ中文站敏捷社区的编辑乔梁则认为，管理或者决策不是可量化的，领导也不会简单地通过数据就做决定，问题的实质还是在于沟通：
做为项目开发团队的成员，团队至少要有一个人可以用业务语言和其他项目干系人沟通。 频繁沟通。让项目干系人知道项目的真正进展（他们所关心的方面），你不能到无法完成目标的最后时刻才告诉他。 高质量的沟通。沟通不是啰嗦一大堆，却没有目标，只是让他们知道项目的情况，而是有目标的沟通，并得到有益的反馈。
在InfoQ中文站上针对本文的评论中，读者徐绪雄从业务语言的角度，解释了如何让软件开发团队的沟通更加有效：
在软件开发过程中，开发人员往往只关注与开发相关的技术内容的学习，而忽略指导开发进行的实际业务知识。从而出现因与实际业务不符的重复性还工。对于参于其中的各方都是一个很大的打击。开发人员掌握足够的业务语言是高效完成开发任务有力保障。
讨论仍在继续，如果您对项目开发是否需要用数字衡量，如何衡量等有自己的观点，欢迎在“用数字沟通——来自敏捷精灵的忠告”文章或者敏捷中国相关讨论贴参与讨论！
霍泰稳 是InfoQ中文站的联合创始人兼总编辑，有多年的软件开发经验和媒体从业经历。
乔梁编辑的结论是错误的，而且偏题了
发表人
Zhang Charlie
发表于
看不懂 TW 钱安川的逻辑
发表人
Zhang Charlie
发表于
数据真的会让项目不停地偏离真实轨道？
发表人
Zhang Charlie
发表于
这是我在Agile China上的回复，东西都在下面呢。
发表人
anchuan qian
发表于
数字是有效沟通的要素之一但不是全部
发表人
徐 绪雄
发表于
Re: 数字是有效沟通的要素之一但不是全部
发表人
霍 泰稳
发表于
关键在于能否预测未来的行为
发表人
cai dehui
发表于
-
而来自ThoughtWorks的另外一位业务分析师，也是InfoQ中文站编辑乔梁则认为，管理或者决策不是可量化的，领导也不会简单地通过数据就做决定，问题的实质还是在于沟通：
做为项目开发团队的成员，团队至少要有一个人可以用业务语言和其他项目干系人沟通。 频繁沟通。让项目干系人知道项目的真正进展（他们所关心的方面），你不能到无法完成目标的最后时刻才告诉他。 高质量的沟通。沟通不是啰嗦一大堆，却没有目标，只是让他们知道项目的情况，而是有目标的沟通，并得到有益的反馈。
<strong>管理或决策当然是可以量化的！</strong>而且，定性和定量分析结合的管理决策才更科学、更先进、更成熟。打个比方，如果您会打桥牌，就会知道每一手牌，每一次决策，都可以量化，算算外面还有几张牌，您赢得这一墩的成功概率是多少 ...
我不知道乔梁所说的“管理或者决策不是可量化的”，依据何在。
本次讨论的主题是：数字是有效沟通的要素之一但不是全部。这当然是正确的。
也就是说，<strong>问题的实质根本不是要不要沟通（所有人都知道沟通的重要性），而是如何沟通，怎么沟通，拿什么去沟通</strong>。所以，后面乔梁说了一大堆，“频繁的沟通，高质量的沟通，有目标的沟通”，我看是偏题了，没讲到点子上。
如何沟通？有数字和数据支持的沟通，当然是更高质量的沟通。这是受过科学训练的职业软件工程师应该具备的常识。
敏捷 OO 教练 张恂
www.zhangxun.com -
来自ThoughtWorks的钱安川认为：
但是，[很]明显，数字最有说服力。特别是业务人员和管理者，有了数据就可以放心大胆地做所谓的决策。当然，也明显是把责任推卸给了开发人员。
为什么业务人员和管理者利用最有说服力的数字进行决策（感觉很正常），“明显是把责任推卸给了开发人员”？
看不出两者之间有什么必然的联系。
难道钱安川有这方面的不愉快遭遇？ -
起步停车对钱安川的关于数据会让项目不停地偏离真实轨道的说法表示赞同，同时以自己的实际情况进行解释：
在我们实际的项目开发过程中， 可以说我们积攒了无数个项目的信息（包括计划、任务、时间估算、规模估算、各类文档，以及他们说需要的估算时间和实际时间，还有代码行数……，可以说要啥有啥）。
可是，我们在不断的重复着“昨天的故事”，用历史积累的数据来考量现在的项目……，[并且]美其名曰：用数据说话……
[结果是]开发人员极度痛苦ing……，对这些数据很不屑……
以上引用是一个用错误的论证来证明错误的论点的实例。
数据本身是没有生命的，真正让项目不停地偏离真实轨道的其实是：
无能（不作为）的管理者 ...
我建议，作为屡次的受害者，从今以后程序员们应该努力掌握因果分析、root-cause 分析、逻辑推理等等重要专业技能，这样才有可能获得真正的改变。
敏捷 OO 教练 张恂
www.zhangxun.com -
这是我在Agile China上的回复，东西都在下面呢。
数字"要尽可能一致。不同意Anchuan这儿说的"明显是将责任推卸给了开发人员"
我的这句话是对应文章中的： "但是什么，Rick？"Sam打断了他，"把数据拿出来再跟我谈！我可没有时间听你说这些'但是'，我要尽快告诉客户没有问题。"Sam转身走开了。
要数据可以，先要弄明白是什么数据？是代码行吗？是人月吗？这些估算单位，很不够准确。
那又怎么估算？把需求分解成一张张的Story，然后一张张按照理想天评估？问题还是单位，理想天怎么说？一对Pair在没有任何干扰的情况下工作8个小时。那又拿哪一对Pair作为标准呢？一个团队每个人技术和对项目的了解情况都不一样，工作激情更不一样？那也许有人说要取平均水平的Pair 作为估算。
就算理想天的单位问题解决了，最重要的部分，每张Story大小又如何评估呢？由团队中的一个技术leader评估？还是民主的方式让整个团队技术人员一起评估？先得掂量一下自己的Team。然后评估吧，评估有一个非常重要都前提，就是在Story要写的合适。
只有在上面的假设条件都成立了，那么我们就开始评估吧。我们Team使用：1、2、4、8、16的数字，技术人员一起评估，喊123，然后每个人给出数字，如果有不一致，就互相说服对方，如果无法说服对方，就取平均值。当然，我现在是做产品，没有太多进度的压力（PM扛着呢），所以大家不会有太大的偏见，相对比较客观。在我们眼力，这些数据只是项目经理用来管理，评估和计划时使用的。就是这样，我个人感觉估算的准确度差不多是80%左右。
明显，这个80%的前提大家对技术和业务都熟悉，并且有丰富的开发经验，而且评估的时候不带个人情绪。
而且，我这里的评估只是在迭代或发布计划的时候做的。只是2周-4个月左右的计划。如果再远，误差就会更大。
所谓的评估模型，一般是招标报价和财务预算的时候使用，适合专业的评估部门采用，也只能算是一个工具。我见过一帮人评估了好几天，把100百万不到的项目评估成了1000万。 -
在InfoQ中文站上针对本文的评论中，读者徐续雄从业务语言的角度，解释了如何让软件开发团队的沟通更加有效：
在软件开发过程中，开发人员往往只关注与开发相关的技术内容的学习，而忽略指导开发进行的实际业务知识。从而出现因与实际业务不符的重复性还工。对于参于其中的各方都是一个很大的打击。开发人员掌握足够的业务语言是高效完成开发任务有力保障。
更正一下编辑将徐绪雄写成了徐续雄，请改正。 -
已经更改，谢谢指正，也为给徐兄带来的不便表示歉意。
-
数字的收集与使用关键是要看能不能预测3个月以后的情况。如果一个数据只能反应现在的情况，无法对未来进行预测分析，那么这个数据本身没有太大的意义。
预测当然涉及到很多问题，例如使用EV来分析进度，很多人不愿意做，可EV是最成熟的进度分析、成本分析的工具，关键是能够做出预测，那么进度管理使用该工具就是非常重要的。
质量，目前发现的Bug是多少，只能反应当前的Bug情况，如果使用评审时间与创建时间的比例，从进度就能分析出来将来的质量。这是PSP和TSP中很重要的内容。
成本，基于估算进行预测，根据当前实际情况决定EAC，根据趋势来分析EAC的变化这也是很重要的。
再加上风险管理、范围控制、生产性度量，将所有的软件工程中的活动利用转义方式折算成代码行或者功能点，就能够知道生产力。
范围、风险、质量、成本、进度、生产力这几个指标对一个项目的度量是很重要的，关键是要在这个基础上做出预测。
越大的项目，做的越细致，就算是一个50人月的项目也可以得到很好的效果。
沟通是管理中的很重要的环节，没有数字的沟通，只有定性的沟通是解决不了问题的。
7 条回复
关注此讨论 回复