知行合一: 实现价值驱动的敏捷和精益开发(txt+pdf+epub+mobi电子书下载)


发布时间:2020-11-26 16:54:26

点击下载

作者:丛斌

出版社:人民邮电出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

知行合一: 实现价值驱动的敏捷和精益开发

知行合一: 实现价值驱动的敏捷和精益开发试读:

前言

从1968年第一次提出软件工程的概念,软件产品和系统改变了人类的生活方式,它们已经渗透到了社会的各个角落。巨大的新系统开发以及现有系统的维护需求都保证了计算机在相当长的时间内都会是个容易找工作的热门专业。令人遗憾的是,和其他工程(如电子工程、土木工程、机械工程等)相比,软件工程的开发是效率最低、浪费最大一个领域。Frederick Brooks(1987)在30年前就清楚地阐述了软件系统开发的特殊性及困难点,也建议了一些可能的突破点。软件从业者也在实践中不断尝试,可惜几十年来都没有真正突破参照制造业形成的计划驱动、接力开发、按预定过程执行的软件开发模式。越来越多的人意识到这种模式不能有效支持解决软件开发中存在的需求不确定性、技术创新要求的问题。

这几十年来我一直从事软件工程的教学、咨询和研究工作。在这个过程中,我深深体会到学校教的软件工程方法和企业实际用的开发模式都有不少不合理的地方。我们用来度量项目好坏的指标,很多时候并不能体现企业领导者真正关注的点,同时软件过程改进的一些误区也给企业、团队及个人带来了不同程度的危害,如盲目僵化地使用六西格玛方法指导软件过程改进;在不理解CMMI模型实践希望解决的问题的前提下,进行评估驱动的CMMI导入。这些做法使得过程改进对组织的质量文化起了负面作用,对企业商业目标的实现没有起到真正的支持作用。

老实说,我也发表过一些研究性的论文,在不少软件工程会议上也做过一些案例分享,却一直没有触发写书的念头,因为写书真的是一个重体力活。最近十几年来以敏捷和精益开发为代表的软件工程革命性变革,让我感觉到我们比以往任何时候都更加接近软件方法开发之匙。从大的框架角度,从开发管理原则角度,从具体实践角度,从企业实施效果角度,已经形成了一套相对完整、具备指导意义、具备系统性的新一代软件开发方法。

摸索出一些有效软件开发模式是我这些年投入很大精力在做的事情。如果有一本能够充分反映这几方面成果的书显然具有重要意义,这极大地促使了我忽略肩周炎、腰椎间盘突出的痛苦,下决心开始码字写书。本书不追求所谓纯粹的敏捷或精益,而是希望找到解决软件开发中长期没有很好解决问题的钥匙。我一贯相信存在必有其合理性,所以这把钥匙一定是各种模式中好的实践的结合物。

软件组织的管理人员、技术人员、质量人员和过程改进人员都可以从本书中获得他们需要的知识点。本书的一个特点是希望把原因讲清楚,回答好“为什么”的问题,因为理解“为什么”比知道“如何做”更重要。理解了“为什么”才能从“形似神不似”中走出第一步。贯穿本书的一个主题是如何通过敏捷、精益实践,用低成本实现软件产品的高价值点,时刻把握住软件开发中的核心经济指标,避免盲目追求可能没有真正价值的替代度量指标。

我在近几年做敏捷、精益培训及实施指导中发现,大部分Scrum、极限编程、看板(Kanban)实践者虽然接受过敏捷培训,阅读过一些敏捷和看板书籍,也有些实施经验,都会提一些类似的问题:什么是正确实施方法?如何在自己特定的企业让敏捷、精益在组织、团队、项目中落地,使其价值最大化?许多在CMMI框架下建立了开发体系的读者,都面临着和CMMI模型有效结合的挑战。希望本书能对持有类似疑问的读者有所帮助。

本书主要包含4部分内容,相互之间有一定的独立性。本书读者并不一定需要有敏捷和精益的背景知识,他们可以根据自己的需求获得有价值的帮助。前三部分的重点是讨论以Scrum和极限编程为代表的敏捷实施,第四部分则是深入探讨看板及新一代精益软件开发方法。在探讨Scrum、极限编程、看板、新一代精益的核心理念、架构、实践时,我会提出具体实施的建议。这些建议包含实践层面及理念层面的东西,体现了近年来业界对敏捷及精益的最新理解。有些建议也许会是有争议的,这些争议可能源于作者坚持敏捷、精益核心实践的完整执行以保证价值最大化,也可能源于对灵活度的把握的理解不一。

由于各种原因,本书的撰写耗时很久,未能按计划交付,在此向一直耐心等候的编辑致谢,向一直期待此书完成的读者致歉。作为延期的代价,我有必要将近几年软件开发模式及方法的新实践追加进去,同时将一些因时间推移而价值变低的内容做些删减。例如,新一代精益软件开发的内容本不在本书最初计划范围内,但今天它已经成为不可忽略的内容,因为新一代精益模式将敏捷革命带入了一个新的境界,它在方法论、原则、具体实践等方面大大丰富了软件工程的内容。

建议读者从第1章评价项目成功标准入手,真正理解传统开发方法和软件产品的不匹配之处,以及造成的低效后果。在这个基础上,读者可以从第2章和第3章中了解到敏捷方法价值观、框架、原则以及为何它能够在很大程度上解决传统开发模式的不匹配问题,并明确为什么从“先知后行”到“知行合一”是软件开发的必然之路。从传统的瀑布开发模式转向敏捷主导的模式是一件痛苦的事,如何管理这个转型也是第3章讨论的问题之一。例如,导入Scrum不能保证解决企业软件开发中的所有问题,但它会让这些问题突出地暴露出来。实施敏捷的企业有两种选择:一是面对问题,努力将敏捷中对应问题的实践作为解决方案的一部分;二是为了避免变革的痛苦,将问题埋在地毯下,仅仅引入容易在企业内部实施的实践。令人遗憾的是,许多引入敏捷的企业选择了第二种方式。它们也能取得一定效果的改进,但那些被忽略的实践,往往很可能是对它们最有价值的实践,敏捷的一些重要价值没有得到真正的实现。

本书第二部分重点讨论如何建立以Scrum为框架的软件开发管理体系,并从有效管控技术债务角度出发,形成和Scrum框架匹配的工程实践。我最近将业界常用的技术债务扩展成质量债务的概念(Cong,2017),这是一个非常重要的课题,是对敏捷、精益环境下的质量管理的一个新尝试。如何有效管理技术、质量债务,做到健康迭代而不是带病迭代,其实也是贯穿本书的一个主题。国内许多软件组织已经引入了Scrum开发模式,从第4章到第6章,我在Scrum布局准备、管理方法的落地以及和极限编程的结合等方面中做了比较系统的整理。不论是否具备敏捷实践经验,读者都可以通过一些实施案例及作者观察到的优秀实践,进一步理解这些章节中的内容。

本书第三部分详细描述了CMMI和敏捷开发模式结合的有效方法,其内容是许多软件企业非常关注的,因为目前许多国内的软件组织都引入了CMMI开发模型。许多政府、企业项目招标时,把CMMI资质作为一个重要的评分项。当这些组织实施敏捷时,就面临如何在CMMI框架下实施敏捷的挑战。第7章澄清了一些敏捷和CMMI的偏见,通过实例解释了二者的互补性。我也把CMMI研究院在敏捷和CMMI结合方面获得的最新成果纳入了相关章节中。读者在读第8章时,可以详细了解到如何在敏捷环境下实施CMMI开发模型中的所有过程域,做到在合理平衡稳定度与敏捷度的前提下,不断提升开发过程的能力。本书第三部分不仅能让读者对敏捷的不足之处有更深入的了解,也可以纠正一些业界常见的CMMI的价值及使用方法的偏见。为了保证让对CMMI开发模型不了解的读者也能看懂相关内容,我尽我的能力对模型做了通俗易懂的解释。

本书第四部分首先重新深入探讨了软件工程和其他工程的差异,特别是其“软”“易变”“非线性增长复杂度”“创新”等特点,读者可以更加深入理解为什么我们遵循几十年的,借鉴制造业的开发模式并不能高效匹配软件系统的开发。这有助于读者理解敏捷、精益存在的基础,同时读者也可以看到以Scrum和极限编程为代表的敏捷方法的一些不足之处。国内一些软件组织已经开始引入初级精益方法—看板,我在第10章首先澄清了一些看板实施的误区,然后重点阐述了如何把Don Reinertsen(2009)提出的支持创新的新一代精益开发方法移植到软件产品开发中,将其原则、实践作为精益软件工程的核心内容。软件的实践者其实已经用了其中不少原则,但他们只是凭直觉,只是支零破碎地在用些皮毛。第10章从系统角度全面探讨了软件开发应该遵循的原则,这对软件组织的管理者、工程人员、过程改进人员都会有很大的帮助。

本书不是纯学术著作,而是一本结合实例讲解操作方法的书。我同时希望将操作步骤背后的方法论、存在的价值解释清楚。引入敏捷、精益是一场变革,我想清楚地告诉读者:为什么要变?需要变什么?如何管理这些变化?如何实现价值?本书的续篇应该通过读者的实践来完成,如果阅读本书能让一些读者受到些启发,并开始在自己工作范围内做一些改进的尝试,我想,这也就达到了我写此书的初衷。

最后我特别感谢人民邮电出版社的编辑杨海玲女士,她对本书的编写给出了很多好的建议,付出了大量心血。再次谢谢我服务过的众多软件企业,这本书算是对你们的信任的一个小小回报。第一部分神形兼备的敏捷开发模式第1章 从“先知后行”到“知行合一”——从传统开发模式到敏捷开发模式第2章 敏捷开发方法——摸着石头过河的智慧第3章 形神兼具——实现敏捷的核心价值第1章从“先知后行”到“知行合一”——从传统开发模式到敏捷开发模式

北大西洋公约组织的科技委员会在1968年10月组织了一次会议,在那次会议上,出现了“软件工程”这个词。50位来自11个国家的软件用户、软件生产者和高校从事软件教学的教授一起讨论了下列一些软件工程中碰到的突出问题。● 随着数据系统不断渗透到现代社会日常活动中,如何保证这些系

统的可靠性成了一个日益突出的问题。● 大的软件项目的进度及特性需求难以控制。● 软件工程师的再教育。● 软件的定价是否要和硬件分开。

除了第4个问题外(今天软件的价格常常已经超过了硬件的价格),其他3个问题在今天依然是让我们头痛的问题。随着互联网变成公众生活中不可缺少的部分,软件系统的应用比当年多出了百倍,而质量成本依然是软件项目的杀手。软件产品的需求比以往更加难于控制,需求蔓延(requirement creep)是软件开发中最常见的风险之一。IT行业技术变化之快远超其他行业,学习新的技术、方法是软件工程师常态工作的一部分。

根据这些问题,在这次会议上首次提出了“软件危机”的问题。会后不久,Winston Royce(1970)博士根据制造业的实践,提出了一个至今依然影响软件业的开发模式—瀑布式软件开发生命周期,希望能够借鉴其他行业的经验,解决软件开发中的问题。但40多年后,危机并没有消失,依然威胁着软件公司的生存发展。

近20年来,越来越多的软件工程实践者开始了深层次的反思:问题出在哪里?解决问题的方向又在哪里?在反思的同时,一些有勇气的软件工作者开始了新的探索。他们在软件开发过程中,尝试了新的实践,并不断总结交流,形成了我们今天看到的敏捷宣言、敏捷原则、敏捷实践以及敏捷方法与传统方法结合的实践。今天我们比以往任何时候都更接近找到解决软件危机之匙。

我们首先审视下列4个问题。(1)什么是成功的项目?项目中的决策应该由什么来驱动?(2)Royce博士提出的瀑布开发模式真的适用于复杂软件产品开发吗?(3)复杂软件项目的特点是什么?(4)根据复杂软件项目特点,我们需要建立一个什么样的开发模式?

通过对这4个问题的讨论,希望读者能意识到为什么“先知后行”的传统开发模式会让我们在原地踏步,很难走出软件危机的圈子。走出瀑布模式,拥抱“知行合一”的敏捷方法才可能是解决软件危机的正确思路。在这里我虽然借用了王阳明的核心理念,但要表达的意思远远没有达到王阳明先生表达的深度。在本书中,“先知后行”指的是确定了实现目标要走的路再开始行动,也就是在项目前期,确定产品范围、实施方法后,才开始软件开发活动。“知行合一”指的是明确了愿景后,尽管我们不完全清楚到达目标的路径,但我们先往前走,边走边看边调整,在开发中学习、总结、调整、提高,逐步实现客户需要的产品。1.1 重新审视项目成功的标准

在预算范围内,按期向客户提交需求范围要求的产品是长期以来IT企业判定项目成功以否的标准。这个著名的项目管理铁三角(需求范围、成本、进度)直到今天仍定义着大部分软件项目的实施目标。多年来我一直觉得这个铁三角有一个致命问题:它们到底是项目追求的终极目标,还是项目实施的约束条件?项目的价值似乎没有在这3个度量指标中明确体现。

我看到很多项目为实现不合理的进度目标辛苦努力,其他很多重要的东西被忽略,特别是没有关注项目要获取的价值,似乎价值这个东西随着进度目标的完成自然就会实现。也有些项目沉迷于具体的需求项,而看不见这些需求项到底给用户带来什么价值。一个令软件业同行不得不面对的事实是超过50%的软件产品功能基本没有被用户使用过,换句话说,对软件项目团队辛辛苦苦实现的一半以上的功能,客户并无兴趣使用,它们没有给用户带来什么价值。这就应了一句老话:每条需求都有成本,但并不是每条需求都有价值。推想一下,又有多少没有完成的项目,因为追求一些没有价值的需求,导致了过多延期和预算超支,使得企业只能放弃它们。1.1.1 传统的三要素不一定能客观度量项目的成功与否

图1-1定义了传统项目管理铁三角:需求范围(特性、功能)、成本(资源、预算)和进度(时间)。成功的项目应该依据客户需求(范围),在不超出预算的前提下,按时提交项目。“传统铁三角”定义的项目成功三要素有两个重要隐含假设。● 项目定义的需求范围真正反映了客户的真实需要,通过使用这些

需求功能,用户可以实现其价值目标。● 项目计划是正确的,实际和计划不符意味着错误。

在这两个假设下,和计划不符的都会被视为问题,项目管理工作就是消灭计划的偏差。让我们认真思考一下上面的假设,它真的总是正确吗?按时完成,没有超出预算提交了需求范围的功能,一定就意味着项目是成功的吗?如果这3个目标没有实现,项目就一定是个失败的项目吗?图1-1 项目管理“传统铁三角”

请你回顾一下以前你们公司发布的产品,在这3个目标方面都做得好的产品中,有多少卖得好,为公司带来了价值?有多少用户并不买账,产品并未对扩大市场占有率有任何正面贡献?而在没有按时完成,没有实现所有项目计划阶段定的需求范围,预算有超出的项目中,有没有卖得好、客户喜欢的产品?这其中有没有为公司带来新的机会的项目?

我们看几个例子。如果微软的Vista符合这3个要求,你能认为这是个成功的项目吗?如果你用过这个系统的话,相信你的体验不会很好。另一方面,你很有可能没有机会用过这个系统,因为它的市场寿命很短,Windows 7很快就替代了它。多年前,我开始为一家国际知名企业内部IT部门做过程改进的咨询工作。作为诊断工作的一部分,我列席了内部IT部门的年终管理会议。这个由公司CIO主持的会议只有一个议题:如何向董事会展示IT部门一年的贡献。度量内部IT部门的贡献要稍微复杂一些,因为这个部门不挣钱、只花钱。让我吃惊的是,超过30%项目由于完成后无人用,很快就停止维护了。这些项目就算是按时完成、不超出预算又有什么意义呢?我看到完成的项目中包含了不少重复实现的功能,这些功能的成本又该怎么算呢?虽然在这次会议上,他们做了一个看起来还是不错的部门年度贡献列表(其中包括所有项目),CIO不久以后还是不自愿地离开了这家公司。《泰坦尼克号》是一部国内观众熟悉的电影。也许有些内幕你可能不太清楚,它的预算严重超支(整个电影的制作费用超过2亿美元),进度一再延期,剧情有无数的变化调整。如果按传统三要素来度量的话,这绝对是个非常失败的项目。但面对全球20亿美元左右的票房,导演和演员地位火箭式的蹿升,你能说这是一个失败的电影项目吗?“传统铁三角”的致命问题是前面的两个假设。因为对一个软件项目来说,一开始我们往往不完全清楚用户真正的需求,产品需求的理解有个逐步演化的过程。哪怕在项目结束时,很可能我们还不能完全确定实现用户价值的需求集合,这也是产品需要不断升级的原因之一。

另一方面我们如何看项目初期制订的计划呢?我们能假设它的正确性吗?几乎无一例外,答案是否定的。在做计划时,你要面对很多不确定的东西,如需求范围、实施技术、团队能力、外在制约等。虽然你参考了组织提供的团队效率数据,但考虑到影响效率的各种因素及具体团队的特殊性,估算出的进度计划的准确性是让人质疑的。更让人头疼的是,在开发过程中,很多影响项目进度的因子(如需求、人员、环境等)会发生变化。把符合一个不靠谱的计划作为项目的主要目标之一,恐怕不是一件很明智的事。

明确成功项目的标准意义十分重要,它是软件开发方法的纲。借用一句老话,“纲举目张”,这是理解敏捷方法的一个很好的切入点。在本章里,我们一起重新审视项目成功要素,对旧的项目管理铁三角做必要的修正。1.1.2 新的项目管理铁三角

那么究竟什么应该是衡量项目成功的终极标准呢?我们在前面已经提到了它—价值。

Jim Highsmith(2011)提出了敏捷铁三角的概念,他提出了3个新目标。● 价值目标:开发出可发布的产品。● 质量目标:开发出可靠、易更改的产品。● 约束目标:在特定的约束条件下实现价值目标和质量目标。

我十分认同敏捷铁三角的核心理念,这和我多年在咨询、教学中推荐的原则高度一致。对其略做修改,图1-2显示了新的项目管理铁三角。考虑到不同的软件企业的差异性(例如,并不是每个软件企业都是在开发产品)这里有必要对3个目标做深入说明。图1-2 新的项目铁三角1.价值+能力目标

将项目的价值最大化是项目管理的主导因素,不同类型的项目追求的价值目标会有差异。其度量指标可能是:● 销售额及市场占有率的增加;● 公司品牌及竞争力的提升;● 客户忠诚度的提升;● 技术创新带来的新机会。

不同类型的项目会有不同的价值目标,但它们有一个共同点,就是项目价值是站在组织而不是项目的角度来看的。

另一方面,在考核项目时不能忽略人的能力的提升。这也应该是一个项目后评价中的重要指标。在项目结束后,软件工程师设计、开发、测试各环节的能力是否得到了提升?需求架构人员是否对产品的价值、合理的架构有了更好的理解?管理人员对团队能力是否更加了解?客户或用户是否对后续产品方向更加清晰?过程人员,如质量保证(quality assurance,QA)人员,是否对过程的适用及执行难处有了更好的认识?对于许多软件应用服务开发商来讲,人会是企业的最重要财富,人的能力成长对公司的发展至关重要。2.质量目标

我们不应忽视敏捷对质量管理的贡献,它从实践上强调质量不仅是清除缺陷,不仅是功能正确。它提出了技术债务(technical debt)的概念,将其作为后期软件维护隐患的指标,并作为迭代开发的重要质量评估项。敏捷领军人物也提出了许多经过验证的有效实践来管理技术债务,所以敏捷质量目标不仅是可发布(功能正确),同时也是可维护的!3.约束目标

约束目标主要是进度和成本,约束不应该是目标,它是前提。例如,刚性的进度要求,应该理解成在按期交付的前提下,团队将尽可能实现最大的价值。

我对新的项目管理铁三角的解读是:在特定约束条件下,控制产品遗留隐患对交付产品的使用及维护的影响,关注人员能力提升,尽可能将项目/产品价值最大化。

旧的项目管理铁三角有时会让团队追求错误的目标,如片面追求按时交付,而忽略了是否交付了客户需要的产品。Donald Reinertsen(1997)指出很少有人考虑延期成本,他认为这是个非常重要的度量项,每个组织都应该考虑。在某一特定时间提交产品固然很重要,但提交的产品是可以发布的,也就是说它已经实现的功能特性对客户和用户是有价值的,这一点应该是更重要的。顾名思义,延期成本度量的是产品不能按期提交的代价。如果它小于通过延时实现的功能带来的价值的话,项目延期应该是顺理成章的事。如果延时带来的后果是组织不能承受的,在规定时间发布一个新的版本就是必须要做到的事了。当然在这种情况下,需求范围往往是可调整的变量了。

至于将需求范围作为项目的主导目标就更不合适,项目前期用户很难对需求有全面、充分的理解。如果项目开发周期较长,用户的想法在开发期间发生变化也是一件很正常的事情。在美国IT行业有个说法:有生就有死,工作就要交税;做软件,需求一定会变。

如何衡量项目价值呢?应该看它对自身企业的贡献、对客户的贡献,以及对开发的产品用户的贡献。如何度量价值不是件容易的事,我们可以从这几个方面来考虑:产品的销售额、对品牌及竞争力的影响、对客户忠诚度的影响、通过创新给企业带来的新的机会等。实现价值目标一定意味着你发布了一版为客户解决问题、实现了用户一定需求的软件产品。价值必须是项目管理的主导因素,如果值得,为什么不能延时提交?如果不会增加价值,一分钱也不应该投入。

IT业对人的要求比制造业高得多。学校教的东西和业界需要的技能有很大的差距,这个问题估计在相当长时间不可能解决。同时IT技术的生命周期比其他行业更短。持续更新提升软件管理人员、工程人员的能力是每一个IT企业面临的挑战。对一个软件人员来讲,在工作中学习是最主要的能力提升方式。每个项目结束后,相关人员能力的提升也应该是考核一个项目的指标:开发人员的编程能力、工具使用能力是否有提升?设计人员的设计能力是否有提升?管理人员对自身团队的能力是否更清晰?对项目的风险点是否更加清楚?产品经理、客户、用户代表对产品的理解是否更清晰?关注团队能力的提升是每一个管理者的责任,而每一个软件工程师都有学习提高的义务。项目相关人员能力的提升应该是项目评价的因子之一,它也应该是项目价值的考虑因素之一。

新的项目管理铁三角的质量目标明确了更高的软件质量要求。仅仅将通过验收测试作为目标的话是不能接受的。质量更应该关注的是项目遗留的技术隐患对客户使用和后期维护的负面影响。如果开发团队为追求速度,走了很多捷径,由此植入的隐患有时是不能通过测试发现的。但随着代码的增长,这些隐患会对产品的使用特别是维护有很大的负面影响。有时借一些技术债是必需的,但这些债是需要及时偿还的,不然它们会严重损害产品的价值。在产品开发过程中有效管理这些技术债务,应该是团队的一个重要责任。技术债务也可以是一个变量,可接受的债务多少和项目的质量目标应该是一致的。

需求范围、成本和进度要求可以作为项目约束条件,项目的实施一定是在一个鸟笼子里面进行的,我们需要逐步了解这个笼子的空间、自由度。一般来讲约束条件可以有3个度的度量:刚性、部分灵活、灵活。刚性就是绝对的约束条件,部分灵活意味着有一定的自由度,而灵活则表示更大的自由度。把握了解这个鸟笼子的自用空间是项目管理的一个关键活动。

新的项目管理铁三角要求我们用投资回报分析(return on investment,ROI)作为管理者的决策方式。如果追加了投入,回报是什么?回报大于投入吗?如果延时,延期成本是什么?追加时间完成的工作价值大于延期成本吗?追求价值最大化应该是每一个项目的管理目标,也是所有重要决策的依据。在整个开发过程中,管理决策都应该围绕着价值目标的实现来进行。

从简单常识来讲,价值驱动不光应该是企业层面和部门层面的决策方式,也应该是项目层面决策方式。所有的管理者应该习惯这种管理思路:不论项目中需要做什么大小决策,都应该做投资回报分析,可是传统开发模式常常不能有效支持价值驱动管理模式。1.1.3 敏捷让我们实现价值驱动管理

实现价值驱动管理不是一件容易的事,我们通过下面这个简单的例子来说明其难度。

收视率是每部电视剧追求的目标。高收视率对投资人意味着高额广告费,对导演意味着在影视圈中的地位,对演员意味着职业生涯的飞跃。所以电视剧在制作过程中,每个重要的决策都是价值(收视率)驱动的,如剧情、演员的选择、布景等。

每个电视剧的预算都不完全一样,这应该是最大的约束条件。如果预算的限制使得导演不能请到他认为合适的演员,而导演认为请到合适的演员是成败的关键因素之一,那么是否追加预算请出导演心仪的演员,制片人必须做个对收视率的影响分析。如果被考虑的演员有几千万的粉丝,请到他就是收视率的保障,只要追加的预算不是很离谱,相信预算会被调高。如果制片人选的演员和导演喜欢的演员对收视率的影响没有明显的差别,而换演员的代价超过数千万,估计预算追加的可能性会很小。

在前期规划阶段,剧组会估算出电视剧的大概播出时间。如果在制作后期,剧组发现某些剧情有明显不合理的地方,而如果重拍将导致播出时间的延迟,相信大部分制片人会通过延期成本分析做出决定。如果重拍投入不大,延时几个月不会对收视率有很大的影响,延时重拍就是顺理成章的事。但如果制片人了解到有一个类似题材的电视剧也在拍摄中,很快要杀青。如果电视剧播出时间落在它的后面,收视率就会受很大影响,这时延期成本会大于重拍带来的效益,重拍就不是一个好的选择。

什么剧情能打动观众?什么样的演员能塑造出深入人心的角色?在电视剧播放之前,谁也没有完全的把握,谁也无法准确预测能够达到的收视率,这是应用新的项目管理铁三角(价值驱动管理)面临的最大挑战。中国电视剧制作模式就不能有效地支持这种管理模式,一部80集的电视集,要全部拍完开始播放后,才会第一次得到大众的反馈。那时的反馈已经太晚了,因为钱已经都花出去了。2013年年初推出的《楚汉传奇》是一部80集的电视剧,制作成本接近2.5亿元人民币,号称有史以来最昂贵的电视剧。它的导演演员阵容都是国内一流的,请来了国内最好的男演员(我个人认为陈道明是国内最好的男演员),制作团队也是一流的。但是播出后,收视率大大低于期望,远远没有实现预期的价值。

美国电视剧的制作模式就能够有效支持价值驱动管理。一部几百集的电视剧,是一集一集地拍,一集一集地播。他们电视剧的播放是每周在固定时间播放一集,第二天就能看到收视率的数据。如果电视剧播出后,收视率达到或超过预期,那么投资人会继续投资下去。如果收视率没有达到目标,制片人有两个选择:一是分析原因,在拍下一集时做出调整,等下周播放时再看调整是否有效果;二是取消这个电视剧的制作,有时放弃很可能是最好的选择。不做任何变动不是一个可选项。哪怕我们选了个错误题材,损失还是很有限(也就是几集的成本)。

国产电视剧模式就类似于以瀑布模式为代表的传统软件开发模式,它要求我们“先知后行”。需要有明确的计划,只有整个电视剧杀青后,才会第一次收集到观众的反馈及收视率的数据。很明显,这种模式是很难支持价值驱动的管理模式的。因为在实际场景下,价值的判断是需要用户的使用反馈的。

而美国电视剧模式则是“知行合一”的方式,这也是本书讨论的敏捷开发模式。它能通过不断收集反馈,支持价值驱动管理的开发模式,这个例子也告诉我们知行合一的敏捷模式能够有效支持新的项目

试读结束[说明:试读内容隐藏了图片]

下载完整电子书


相关推荐

最新文章


© 2020 txtepub下载