第十二章 里程碑及期限.docx

第十二章 里程碑及期限.docx

《第十二章 里程碑及期限.docx》由会员分享，可在线阅读，更多相关《第十二章 里程碑及期限.docx（29页珍藏版）》请在冰豆网上搜索。

第十二章里程碑及期限

第十二章　里程碑及期限

＊企划的时程安排

＊避免独断的期限

＊破除模糊的里程碑

＊企划的开始

不管我们多喜欢在自由而且没有压力的情况下撰写软体，一些里程碑与期限这是有必要的。

是的，它们是所有［不琐碎软体企划］的常见要素，而且也是许多研发者生命中的祸根。

在看看所有的里程碑和期限后，很令人惊讶的是，大部分的里程碑规格都是设定在一个独断的风格之中：

而且在大部份的情况下，期限则是定义在一个［期限］的基础上，而非实际的预估。

这个特点来自不同要素的作用，包括市场的影响、没有经验的软体管理者，而且在某些情况下，包括了极为固执的人。

当然了，大部份的人们只是不知道如何针对软体的研发来预估时程。

想要维持公平是一个困难的过程，而且它包括了许多的分析与计算，才能产生有用的结果。

在游戏产业之外，软体公司使用一个比较严密的方式，而不是［选一天并期望那天做完］。

即使如此，贵重的训练以及指导方针，还是有助于在合理的态度下，定义出里程碑。

里程碑的作用是把企划分解成可以管理的厚块。

最不应该采用的作法，就是列出一长串想用的功能列表，让研发者一个个查看是不是统统完成：

当然了，事实上也不应该建议这种方式。

您可以想象到，在一个企划持续了18个月的时间后，每个星期只能在几个要件上面打勾，会让士气低落到什么样子？

这种做事的方式有可能成功吗？

小组要怎样去集中精神并保持热忱？

如同它的荒谬之处，有些企划仍然使用这样的系统来进研发，而它们的过程可能是软体研发中最无趣的。

在这边呈现的方式可以运用在各种类型的软体上，不管是试算表、资料库或是大型电玩中的射击游戏。

这个章节将告诉您一组以［良好经验］为基础的指导方针，以更实际的方法来定义里程碑和期限。

在本书的后面，我们会解释这些预测是如何进展，并随着企划的延续而越来越精确。

这个越来越精确的现象，可以视为集中性的规则。

在讨论企划的全面结构时，这个章节也可以做为本书未来章节的地图。

所以，如果您正在寻找研发过程的相关资讯，这个章节可以说是您的第一站。

里程碑如何运作

您有多少次，非要用一个［模糊］的里程碑当做目标来工作？

对没有经验的人而言（而且数量不能太多！

），一个模糊里程碑是一个有很多解释且具备X种可能完成它的方式，而这个X代表您想要的任何数字，只要比1大就行。

而且您要怎么样才知道您抵达了一个模糊里程碑？

如果这个里程碑的目标十分模糊，在预想的情况下，它们就是开放性的解释。

那谁的解释才算数？

当然了，这通常要靠您的老板才能做出［正确］的解释，而且很可能出现的情况是，他与您的看法完全不同。

试试这个简单的测试。

想象您的老板给您一张纸，上面画了五角形的五个点，标示出A、B、C、D和E，如同图12.1所示。

现在，想象您的老板说：

［我今天很忙，而且我需要在一个小时中完成这个工作。

我有很多人要见，所以我只能简要的告诉你我需要你做些什么事。

我要你在A和B之间画一条线，在我从生意上的午餐回来之前做好。

三个小时之后，您的老板蹒跚的回到办公室，并向您要完成的文件。

如果您直接在A与B之间画一条线（如同图12.2），我很抱歉，但您输了。

不过，如果您先在A与E之间画一条线，然后确定这条线延伸绕着五角形穿过D、E和B，（如同图12.3），而且在A与B之间留下空白，那您就成功的达民了里程碑。

好吧，您的老板不会叫您做这些琐碎的事，这边的重点是：

含糊的里程碑是没用的。

要走到您的解答，它可能代表您作了太多或是太少的事情；而大部份的情况下，程式设计师的基本心理一定会倾向后者。

这并不表示良好的程式设计师都是懒虫；这只是表示在普通的原则下，二点之间的最短距离是直线（大部份的良好程式设计师，喜欢以最小的工作量，产生出规定的结果）。

不过，在前者的情况下（作了太多事）也通常代表错误的工作方式，这表示程式设计师在解答方面太过热心，提供了不需要或是没有必要的复杂功能。

在完美的情况下，里程碑不应该有这些大的活动空间，但很不幸的是，这一类状况正是大部分安排时程的问题核心所在。

在一个比率公平的企划中，里程碑之间的距离放得太远，它们之间就可以容许一定程度的偏移；象是进行不必要的工作，或是缺乏集中注意力的焦点。

一个里程碑应该十分明确而简洁。

它应该也很明显，足以一眼就看出这个里程碑是否已经到达：

黑与白、失败与成功。

它不应该迎合或是鼓励任何野心的结果或是灰暗的阴影。

没有人可以说一个里程碑完成了90%；一个完成90%的里程碑给人的感觉，好象是一个灯泡的亮度为90%；这个灯泡只有亮与不亮，里程碑也是如此。

这个要点十分重要。

模糊里程碑是在企划中最常见的单一问题。

您老板的五角形工作，应该以下列的方式来说明。

1．必备工具：

尺以及一只黑笔，可以划出连续的细线。

2．在点A到点E之间，以粗细均匀的黑线相连。

3．在点E到点D之间，以粗细均匀的黑线相连。

4．在点D到点C之间，以粗细均匀的黑线相连。

5．在点C到点B之间，以粗细均匀的黑线相连。

注意：

不要连接点A到点B之间。

这个列表是一份更详细的分析文件。

这个分析应该详细到没有产生怀疑或是问题的空间。

告诉您如何去解决问题。

在这个例子中，还有一个更好的解决方式，而且产生出来的解答刚好可以想连的点连起来（一语双关）。

您可能觉得这样的作法会将程式的创意抹杀，对这一点，我的回答是［程式并不是发挥创意的空间］，换句话说［有创意性的程式设计］叫做胡闹。

适合发挥创意的地方叫做设计与结构，在我们开始进行系统的程式撰写时，游戏与结果设计者已经完成了所有创意的部份。

这一点可能会削弱自尊，但是一个程式设计师的工作就是很简单的翻译：

拿到详细的设计，把它转换成可以在电脑上面执行的东西。

我可能已经听到程式设计师的坚决声明，说他们是创意上的天才，我怎么有这种胆子把他们贬低成只会写程式码的猴子？

嗯，只写程式的程式设计师是程式码猴子。

一个真正设计工作中的程式设计，在一个漫长而复杂的过程中，真的只是一个小小的阶段。

它是一个结束的修正，一个微小但重要的详细过程。

不过，程式设计师通常有更大的责任，而不只是写程式码。

在大部份的状况下，他们也要为详细的模组设计以及相关的执行工作负责。

这可以让他们把创意移到该去的地方，把创意放入附有详细说明的程式码设计文件，而不只是在写程式码。

对那些还看不懂上述争论的人，请回头看看第11章，将更详细的讨论了上述的重点，并提供了我的看法。

我曾经参与过的每一个良好企划，都有意把程式设计的等级降到简单的翻译。

这些企划都平顺的进行，也统统在时间与预算的要求下完工。

相反的，所有我曾经参与的不良企划，都直接从整体的结构设计进入程式码的编写。

在没有例外的情况下，这些企划都超出了原先的预算，而且完成时间向后拉长――如果他们真的完成的话。

如同在案例研究12.1所示，模糊里程碑会导致企划的延期，而且结果是让那些守着里程碑的利益团体，出现迷惑以及大量的猜疑。

如果没有指出一个明确的中止点与进度，您就降低了企划的可见度，这表示没有人真正知道这个企划的进度在哪里。

所以，延期与问题成为疾病，在没有人想出一套解决这种问题的方案下，它就这样发生、不受注意，一天又一天直到它大到无法忽略为止。

在统计学上，大部份的企划损失时间导致没能及时完工：

就是因为延期又造成了延期。

这样的问题必须及早解决，而且这个状况明明可以及早矫正。

案例研究12.1　为何模糊里程碑可以做一个企划

在我很早以专业身份担任第一个游戏的企划时，我刚刚从学校出来，被指派一个看来很简单的任务：

为我们正在进行的游戏，以微软的VisualBasic4写一个关卡编辑器。

这对一个企划的标题或是任务说明都是好事，但不幸的是，它也成为我的企划里程碑。

再也没有更难让人看到里程碑的情况了。

不过，在那个时候，我并没有什么经验，所以也看不到问题的所在。

我接到的期限是二个星期，来完成这个特别的企划。

在基于上一版VisualBasic的良好知识下，我开始工作。

第一个障碍，在于我对问题领域没有足够的知识：

我不知道它要的是什么，即使我的老板和我认为，我们二个脑子中的游戏完成产品想象图是一模一样的。

我在思考的企划（而且我知道我可以在二个星期内完工）是一个用方格为基础的地形编辑器，可以产生出棋盘式的方块，然后用这些方块拚出有高度的地图。

而在我的老板脑中的企划，需要的是一个地形编辑器，不但有拥有上述的能力，还要能够自动用乱数或是输入一张代表高度的地图，让从VistaPro（一种地形产生套装软体）载入的资料来产生出地形，并启动更换地形上面的游戏物件（包括让先前安置的部队自动产生阵形），自动输入并在输出给美术师时进行分类，而且产生一组完整的关卡档案，其中所用的色盘将视每个关卡来最佳化。

这二份上述的说明，都是关卡编辑器的描述，但只有一个有可能在二个星期中完成，而且只有一个（在我老板的意见中）才是对的。

不幸的是，我们二个看到的并不是同一个。

结果，在二个星期后，我以每一个规格完成了地形编辑器，所以达到我的企划目标（这是我所见到的）。

没有人告诉我其他的东西，而且只有一个时间很紧的期限，我在写程式时没有办法加入任何东西，当然我也不可能提供一个选择，让这些东西在日后再加进来（换句话说，我在进行软体创造时，用的是［地狱程式码］的方式）。

最后的结果，是要再花十个星期的时间，才能达到里程碑，而且这个程式最后执行起来慢得让人受不了，因为它用了VisualBasic4，去尝试做太多色盘有关的处理。

模糊里程碑

就象登山者会被人警告不要去吃黄色的雪，您得到的警告则是不要容忍模糊里程碑，这是一个常识。

为什么要在规定的期限内，朝一个您甚至不清楚在哪边的目标前进，而且在您抵达目标之后，还有可能和别人争执这个目标立在什么地方？

模糊正是软体时程安排上的敌人。

模糊里程碑也会导致在企划进行全面的规格定义之前，先完成里程碑与时程表。

因于这个时候还不清楚问题的领域在那边，里程碑是以概略的通则来定义，而期限则是以独断的行为，将可用时间予以切割，以直觉般的本能来安置。

通常在单一的里程碑中会包括太多的工作，这代表在到达这个里程碑之前，必须完成所有分散的工作。

这就会形成一个模糊里程碑，而且可以合法的描述成一个（举例来说）半完成的东西（象是要完成这个东西要二股力量，但只完成了一项）。

在单一的里程碑中填入了太多的东西，会招致反效果。

除了很明显让人迷惑的要素外，它也会导致其他的次要问题。

小组会觉得他们要做的事情是达成一个里程碑，但是要到达这个里程碑之前所花的额外时间，将会影响到士气，而且整个小组的态度也会转换成一场壕沟战：

我们每天都在对抗他们，并在不断的磨擦中降低了前进的速度。

一个小组，应该知道要花掉多少时间，所造成的进展在整个企划中占了多少百分比。

这并不是一个不可能的工作，但是它的确需要更多的规划，通常也是一位游戏企划的工作。

里程碑与迷你里程碑

如同定理一样，要踏上一个里程碑所花的最好时间，应该是四到八周。

这将提供有限的目标，可以让里程碑在合理的情况下受到所有人的重视。

另一个问题是庞大的模糊里程碑很难让人专注于其中：

有谁会在意四个月之后的期限？

这个状况通常会造成前三个月的时间都没有人在写程式，而最后一个月大家都在地狱中工作。

要解决这种现象（除了把里程碑之间的距离缩短）可以把每一个里程碑分散成迷你里程碑，或是查核点，大约每星期一次。

很明显的，想要做到这一点，您必须把结构规划的相当好。

如果，您发现在目前的处境中，无法公平的定出里程碑和迷你里程碑，那么在结构的设计上就不够完整到足以开始写程式。

在这种情况下，我们可以先确定企划开始之后的重要阶段中，是否进行着良好的运作，再来解决这些问题。

如果一切进行的很好，要让它们保持运作就比一开始要先修理问题，并勉强运作来得容易得多。

一个在里程碑和迷你里和碑之中良好的工作分配方式，是把迷你里程碑指定成完成特定模组，而把模组的整合当铸主要的里程碑（有时候把迷你里程碑再加以分割是必要的，但是这将视您小组以及手中的工作而定）。

在良好的小组之中，迷你里程碑不一定有存在的必要。

举例来说，如果小组的经验丰富到知道解决问题的最好方式，而且成熟到时时留意期限的逼近时，就没有设立的必要。

不过，对新的小组或是一个全新而不熟悉的企划来说，迷你里程碑就可以做为二种用途：

＊让小组专注于他们手中的工作。

＊在重要的时间，提供大家已经增加的企划可见度。

第一点中很重要的是不要把里程碑的间隔安置得太远，才能避免人员在企划中漫无目标的漂流。

一个很类似的情况，是想象您手中有一份指示，叫您前往一个您从来没去过的地方，但是您对这个地区有个模糊的印象。

现在有人请您沿途画出一张路线图，并在有限的时间中抵达。

在您上路时，您最花时间的工作是画地图，从现在开始，您会不断的走走停停，四处看看您的前进方向。

在这个例子中，里程碑就是您走走停停的动作，而企划就是地图。

您走走仿停停的次数越频繁，您在地图上面走错路的可能性就越低。

很明显的，这个方式正是［报酬递减法则］：

如果您每走二步就停下来，不只会花更久的时间到达，而且您无法专注于绘制地图。

如何找出这方面的平衡就是关键，这个里程碑不应该如此频繁，导致有效的工作进行受到损失；但是也不能一次冲刺得太远，然后看到整个企划迷失方向。

一个良好的定则是把迷你里程碑的数量，以小组对这个主题的经验高低来调整；而这个迷你里程碑少要保持在一或二天。

任何比这个数值更小的时段，将需要更频繁的管理，而且在可见度方面会让坏处多于益处。

何时要使用里程碑

在一般的情况下，每一个程式或模组都是一个独立的企划；而且对大部份的程式而言，这都该被视为本质相同，而且提供相关规格与说明文件。

是什么东西导致程式琐碎并没有定论，但是在这边的建议，是只有在您能够断言没有其他用途之下，才考虑写一个要丢弃的程式（即原型程式），这可以减少程式琐碎化的机率。

如果您用这个程式继续研发下去，只会产生一个荒废谬的庞大企划。

一个可以做为例子，并符合上述标准的程式，是那些生产出对照表的程式。

它会产生出预先计算的数值档案，以减少执行时所需的计算（在处理器越来越快的现在，对照表已经不再受到青睐，但是它们在速度有限的系统上面仍然十分有用）。

要研发这一类的产生方式，将包括撰写常式分析器，可以读取使用者定义的公式来产生表格。

在这个特定的状况下，很明显的要比把计算公式写死在程式中的好。

让您的里程碑正确

为了增加时程表的正确性，我们需要尽可能的把不确定的东西移除掉。

这并不表示您可以移除所有的东西，但是只要您能把不确定的数字降到最低，就等于避开了里程碑的模糊性。

在案例研究12.1中，问题源自于一个共通性的误解，以及对正确的需求缺乏深度的说明。

之所以没有附上说明用文件的原因，是因为在这个问题领域中没有进行相关的研究。

在给予了严格的期限后，很明显的并没有提供任何相关需求与想法。

老板只是假设他想要的知识会［自动］的从他的脑袋传到我的脑袋中。

在混合了这样的想法后，他假定其他的组员可以在数分钟之内，把他们所需的东西说得一清二楚。

这实在一点道理也没有，但是您会很惊讶而且吓一跳的，是有好几个企划的确就是以这样的基础来进行。

大量的金钱都花在这种预期上，而不把所有可能影响到企划进度的要素列入计算之中。

在一些案例中，期限的设定基础是由市场部门要求的，这可能只有最没品质的小组才能同意这样的要求。

发行日期很显然是源自市场方面的压力，但它绝对不应该成为时程主题的决定要素。

尝试让小组去尊重市场部门设定的期限是不可能的，尤其是当这些期限设定在独断而不合理的前提之下，再加上完全不把研发方面的技术要素考虑在内。

如果出现了一个市场决定的期限（象声名狼藉的圣诞佳节大冲突），那就得把功能加以调整，才能让企划符合规定的期限。

这个减少的功能必须在各方面都十分的清楚，碰上这一类情况最有效的回答，就是要求修整时程表的时间，但是要完成的工作量还是一样（这边的假定是，反正所有的研发人员都在时程表上面填了一些空间，来让他们的生活轻松点。

这是很荒唐的事，但如果您屈服在这种假定之下，您就是在自找麻烦）。

在处理所需的工作量上面，这个时程表一定要经过最佳化并极为清楚。

如果这个工作必须在短时间完成，那就非得砍掉一些功能不可。

我已经看过太多的状况，是企划领导者同意这样的状况，并假定他们可以在12个月中完成18个月的工作。

不得不承认的是，只要足够的超量工作，这并不是不可能的。

尝试让一个研发小组在紧密而且加班情况下工作12个月，处理上吨的工作并非容易的事（而且绝对不建议这样做）。

这会伤害原本高昂的士气，而且这个企划结束之后，失去您所有技能高超的研发人员，也不是什么怪事。

在案例研究12.1中的程式期限很明确，但是对这种正式的工作而言太短了。

在这个企划中光是收集资讯至少就要一个星期，而且如果先收集到足够的资料，就可以预测出这个企划需要再花六个星期来撰写。

当然了，就算这个预测是靠着其他组员在这段期间的工作量来判定，您还是要把撰写说明文件的时间，以及说明这个编辑器中所需的功能考虑在内。

这件事可能会得到老板的同意（或是拒绝），但至少这个结果可以让他采取其他的选择，象是指派更多的人加入这个企划、降低要求、延展时程表、给这个企划一些在相关领域中经验丰富的人，或是把您开除掉！

在您想要规划并为整个企划安排时程表之前，您有些动作是一定要先完成的。

一个企划的前三个里程碑（如表12.1所示）一定要实行，这可以让您更详细而且更精确的分析出接下来的每个月，时间要如何运用。

表12.1　前三个里程碑

里程碑

查核点

工作

1

1.0

一般性必备物资收集

1.1

技术性必备物资收集

1.2

资源上必备物资收集

2

2.0

一般可行性研究

2.1

技术可行性研究

2.2

资源可用性研究

3

3.0

结构规格草案

3.1

企划开始

这些里程碑有效的包括早期规划以及可行性的研究。

这些阶段的花费，是企划总成本中最小的一部份，而且它有助于提供良好的资讯，计算出整个企划的总成本、时间以及技术上的可行性。

在第一个里程碑之后的每一步，都让做决策的人有一个很好的地位取消整个企划，或是让它朝下一个里程碑继续前进。

在那三个里程碑完成时表示企划可以开始运行，那企划就应该可以朝完成的方向迈进（除非它掉入汪洋大海）。

如果通过了可行性的研究再把企划取消掉，那应该视为可行性研发过程的失败，并进一步的调查。

一个企划的初始调查阶段的实行优点十分明显，毕竟接下来是为期15个月的研发过程，在所有人的身上投入大量的金钱与努力，并假定每个人都可以把这个企划完成（这个情况有没有让你们听到擂台上的钟敲响了？

）取消一个企划对士气的影响，将会随着企划进行的时间而不断的增大。

不过，如果组员有进行过可行性的研究来查看技术与可玩性方面的需求，那这个伤害就可以降到最低：

每个人都可以了解他们做的是一个企划的研究，看看它是否值得尝试。

如果最后的结果是可行，则所有人都会受到鼓舞。

不过，如果所有人都做了各方面的可行性查核，但最后还是有机会被取消时，效果就没有那么好了。

人们的天性是在舒适安全的位置上时，工作表现会更好。

当然了，一个企划早夭的风险还是无法全面消除，但是它至少可以藉由在进行时，早点解决任何主要的问题把可能性降到最低，而且要在大量的金钱与人力投注到这个企划前完成。

否则，您不只会失去您的金钱与时间，您还会失去人们对您的尊重。

案例研究12.2　取消企划的代价

为了保护无辜与那些不见得如此无辜的人们，下列的人名、公司与产品都已经全面改写。

在一个与热门《Cryptlnvader》系列发行公司，也是Y公司的总裁――司诺先生的会面中，他声称Y公司最近大约中止了十个企划案，这些都是在做了六个月之后　，结果无法达到预期的东西，而这些企划案已经进行各种不同阶段的研发，而且都在上面砸了不少钱。

司诺先生说，这样的作法是为了保证他们推出的软体都具有高度的水准，听起来很有商场上的味道。

据司诺先生表示，这些企划取消的费用（包括《Fatalprisonll》），每一个企划都将近在￥160000到￥720000之间，对他而言这并不算是大问题。

有些人可能会说，如果您有手中这么多Y公司到处投注的钱财，那您也看不到什么东西叫做问题。

不过，如果您考虑到这笔钱可能全部用在资助四个其他的企划（如果早期的原型阶段执行的很好），那这就是完全不同的光景。

这种努力的浪费不只在金钱上面很可观，而且它也不利于研发小组的士气（可能有上百人）。

在案例研究12.2中，企划案中止于不同的研发时程。

幸运的是，其中有些仍然在原型的阶段，所以不会花太多钱；就算如此，￥150000美元花在一系列的原型上面，仍然是一大笔金钱。

在现实中，我在一个原型上面的金额不会超过￥75000，这只是看您如何定义（原型）这个字。

在这些案例中，［原型］并不真的是指传统的字面意义，而是完整研发游戏的部份研发版本。

在大部份的状况下，这个游戏将会以普通的方式开始研发，而且在主要的研发中，分离的原型并没有什么效果（的确如此）。

在这些例子中，原型的程式码是真正游戏所用的程式码。

不过，一个［原型］的意义是这样的：

快速而可丢弃。

这是一个测试点子与概念的动作，所以不要与科技研发搞混了。

原型阶段的用意在于研究出游戏概念的可行性。

在这个阶段的结尾，需要的科技应该已经完工（或是找到可以取代的方式）。

这并不象它听起来那么限制良多，因为这些元件将会在标准的介面中研发，如果（或是有时）一个新的科技在真正的企划过程中研发完成，这个新的元件也可以在后期把它插入正确的位置。

这个原型甚至不需要以编译式语言来撰写。

通常一系列连续的原型――从纸笔进展到高等级、快速研发的语言（象是培基语言）――都足以测试这个粗糙的概念。

不管怎么说，它是一个原型，又不是完成的产品，而且如果它与最后的产品是用不同的语言来撰写，那就可以断绝将［原型］当做［完成产品］的所有可能。

把原型的程式码放入正式产品等于在调制一场灾难，因为通常在定义上面，一个原型并不具有［产品等级程式码］（译注：

真正成品所用的程式码，以下称为［产品程式码］）的特性。

这不只是程式码写得很草率，还包括了写原型时编写程式码的优先程度。

举例来说，游戏执行速度并不是在原型程式码中的第一条件，但是在一些产品程式码中却是最优先的事项。

不要低估把原型程式码放入完整产品的诱惑，那种节省时间的期望相当于一个危险的陷阱，通常导致的结果是显著的时间延迟以及后期产生的大量问题。

所以，把原型的程式码用在产品程式码是一个不值得尝试的举动，这不但是一个不可能完成的工作，而且甚至有可能阻碍原型的研发。

在表12.1中的里程碑时程表试图包括上述的所有要点，并包括企划的初始阶段，一直上溯到可行性的研究。

下列的部份，包括了这些初始里程碑的详细说明。

查核点1.0　一般性必须物资的收集

这个查核点中应该回复下列的问题：

企划是什么？

很明显的，它是一个游戏，游戏的元件，或是一个有助于游戏生产的工作。

但是哪一类的游戏？

目标的客层是什么？

为什么会让他们满足？

游戏的什么地方、以及这个游戏如何与公司的远景契合。

这些问题的答案，有助于集中这个企划的焦点。

什么样的游戏要写出什么东西，应该不会有什么问题。

举例来说，应该探索游戏的外观及感觉，还有在一般层级中，所有其他足以影响游戏的主题和考量。

我个人很讨厌使用［任务说明］这个字眼，但如果我写的任何企划包括了这个字，那这就是需要定义的地方。

［顾客］期待的是什么样的功能？

在这个案例中，顾客可以定义成好几个不同的层级。

第一种顾客是公司的管理部门，第二种是发行公司，第三种是媒体，而最后（希望不是最少的）一种是购买的大众。

每一个群组的顾客必须特别迎合他们的需求，而且很麻烦的是，他们的需求与想要的东西都不见得相同。

每一边都可以证明他们具有同等的重要性，所以要让所有人高兴就很难平衡。

举例来说，管理部门与发行公司可能要示一个正式的展示，以及间歇性的推出先睹为快或是展示。

媒体会需要游戏的远景，而且购买大众要的是完成的产品！

这些需求都要先行预期，并放入您的时程表中（至少最后一个少不了）。

需要的最小功能是什么？

很让人惊讶的是，最小的功能正是最重要的考量。