[翻譯] 遊戲專案為何成功系列之三

[NDark (溺於黑暗)]

The Game Outcomes Project, Part 3: Game Development Factors
遊戲專案為何成功系列之三：遊戲產業的獨特要素
網誌版：http://wp.me/pBAPd-qp
原文網址：
http://www.gamasutra.com/blogs/PaulTozour/20150113/233922/The_Game_Outcomes_Project_Part_3_Game_Development_Factors.php
縮網址：http://tinyurl.com/m7kmuzf
撰文：Paul Tozour
繁體中文翻譯：NDark
20150113

譯按：本文是一篇統計學專業文章，若有翻譯不正確的文句，請以原文為主。






This article is the third in a 5-part series.

    Part 1: The Best and the Rest is also available here: (Gamasutra)
(BlogSpot) (in Chinese)
    Part 2: Building Effective Teams is available here: (Gamasutra)
(BlogSpot) (in Chinese)
    This article is part 3, and will soon be updated on BlogSpot and
translated to Chinese.
    Parts 4-5 will be published in late January 2015.
    For extended notes on our survey methodology, see our Methodology blog
page.
    Our raw survey data (minus confidential info) is now available here if
you'd like to verify our results or perform your own analysis.

The Game Outcomes Project team includes Paul Tozour, David Wegbreit, Lucien
Parsons, Zhenghua “Z” Yang, NDark Teng, Eric Byron, Julianna Pillemer, Ben
Weber, and Karen Buro.






本文是系列五篇中的第三篇。
第一篇請連以下文章 (Gamasutra) (BlogSpot) (in Chinese 繁體中文)

第二篇請連以下文章 (Gamasutra) (BlogSpot) (in Chinese 繁體中文)

第四，第五篇將在2015年一月下旬釋出。

想要知道問卷的方法論，請參閱部落格頁面 "Game Outcomes Project
Methodology":http://intelligenceengine.blogspot.com/2014/11/game-outcomes-project-methodology-in.html

我們問卷的原始資料在此，有興趣的朋友可以拿去分析。



 "遊戲專案為何成功"團隊成員包含Paul Tozour，David Wegbreit，Lucien Parsons，
Zhenghua “Z” Yang，NDark Teng，Eric Byron，Julianna Pillemer，Ben Weber，及
Karen Buro。




The Game Outcomes Project, Part 3: Game Development Factors

遊戲專案為何成功系列之三：遊戲產業的獨特要素

The Game Outcomes Project was a large-scale study of teamwork, culture,
production, and leadership in game development conducted in October 2014.  It
was based on a 120-question survey of several hundred game developers, and it
correlated all of those factors against a set of four quantifiable project
outcomes (project delays, return on investment (ROI), aggregate reviews /
MetaCritic ratings, and the team’s own sense of satisfaction with how the
project achieved its internal goals).  Our team then built all of these four
outcome questions into an aggregate “score” value representing the overall
outcome of the game project, as described on our Methodology page.

遊戲專案為何成功的問卷計畫是在2014年十月開始，針對於團隊合作，文化，製作，以及
領導方面大範圍的研究。問卷是基於一百二十個問題項目對數百位遊戲開發者的調查，我
們透過一連串的要素與量化的專案產出分數（包含專案延遲，專案利潤，網頁分數，內部
滿意度）相對應做出的關聯性分析。我們問卷團隊把四個產出分數總和為一個產出分數，
代表遊戲專案的總和產出，如我們方法論部落格所提。






Previous articles in this series (Part 1, Part 2) introduced the Game
Outcomes Project and showed very surprising results.  While many factors that
one would expect to contribute to differences in project outcomes – such as
team size, project duration, production methodology, and most forms of
financial incentives – had no meaningful correlations, we also saw
remarkable and very clear results for three different team effectiveness
models that we investigated.

此系列先前的文章（第一篇，第二篇）介紹了"遊戲專案為何成功"此計畫目前驚人的成果
。許多我們所預期的要素會影響遊戲產出。其中團隊大小，開發時程，製程方法論，許多
種獎勵都沒有顯著的關聯性。我們也看到許多值得一提的數種團隊效率模型對我們產出的
影響。






Our analysis uncovered major differences in team effectiveness, which
translate directly into large and unmistakable differences in project
outcomes.

Every game is a reflection of the team that made it, and the best way to
raise your game is to raise your team.

我們的分析揭露了團隊效率模型之間的差異，以及對團隊產出造成的差異。

每個遊戲都是團隊獨一無二的成果，要提高遊戲品質，就先從提高團隊品質做起。

In this article, we look at additional factors in our survey which were not
covered by the three team effectiveness models we analyzed in Part 2,
including several in areas specific to game development.  We included these
questions in our survey on the suspicion that they were likely to contribute
in some way to differences in project outcomes.  We were not disappointed.

在本文中，我們關注問卷中沒有在團隊效率篇章提及的額外要素項目，特別是遊戲開發相
關的項目。由於我們認為這些問題可能對我們問卷有貢獻，所以把這些問題納入我們的問
卷中，它們並沒有讓我們失望。




Design Risk Management

First, we looked at the management of design risk.  It’s well-known in the
industry that design thrashing is a major cost of cost and schedule overruns.
 We’ve personally witnessed many projects where a game’s design was unclear
from the outset, where preproduction was absent or was inadequate to define
the gameplay, or where a game in development underwent multiple disruptive
re-designs that negated the team’s progress, causing enormous amounts of
work to be discarded and progress to be lost.

設計上的風險管理

首先，我們先探討設計上的風險管理。與這篇"用一個影片來說明那些被取消的專案"相同
，我們親眼目睹很多專案在開始時的設計不明確，前置作業不足以解釋遊戲玩法，或是開
發過程中不斷打掉重練，造成工時的浪費。






It seemed clear to us that the best teams carefully manage the risks around
game design, both by working to mitigate the repercussions of design changes
in development, and by reducing the need for disruptive design changes in the
first place (by having a better design to begin with).

明顯地，優秀的團隊都很小心地處理設計面的風險，試圖減輕開發中規格變動帶來的影響
，或是在開始時就直接捨棄不良的設計（直到找出真正好的企劃案才開案）。

We came up with a set of 5 related questions, shown in Figure 1 below.  These
turned out to have some of the strongest correlations of any questions we
asked in our survey.  With the exception of the two peach-colored
correlations for the last question (related to the return-on-investment
outcome and the critical reception outcome for design documents), all of
these correlations are statistically significant (p-value under 0.05).

我們設計了五個相關的問題，在下面的圖一顯示。它們對我們問的其他問題都有強烈的關
聯性。除了最後一個問題兩個粉紅色的區塊之外（針對開始的文件與專案利潤的關聯），
其他的關聯性都有強烈的統計表徵（小於0.05的p值）。









Figure 1. Questions around design risk management and their correlations with
project outcomes.  The “category score” on the right is the highest
absolute value of the aggregate outcome correlations, as an indication of the
overall value of this category.  “Not S.S.” indicates correlations that are
not statistically significant (p-value over 0.05).設計面的風險管理及專案產出分
數的關聯性。最右邊的欄位代表四欄中最高的絕對值關聯性。Not S.S.代表沒有統計表徵
（大於0.05的p值）。













Clearly, changes to the design during development, and the way those design
changes were handled, made enormous differences in the outcomes of many of
the development efforts we surveyed.

顯然，根據我們的問卷指出，開發中改變規格，或是如何改變規則，會對團隊產出造成重
大影響。

However, when they did occur, participation of all stakeholders in the
decision to make changes, and clear communication and justification of those
changes and the reasons for them, clearly mitigated the damage.

然而，假如規格真的改變，團隊成員的參與討論，清楚的溝通，及改變的原因，都會減輕
傷害。







[We remind readers who may have missed Part 2 that negative correlations (in
red/orange) should not be viewed a bad thing; on the contrary, questions
asked in a “negative frame,” i.e., asking about a bad thing that may have
occurred on the project, should have a negative correlation with project
outcomes, indicating that a lower answer (stronger disagreement with the
statement) correlated with better project outcomes (better ROI, fewer delays,
higher critical reviews, and so on).  What really matters is the absolute
value of a correlation: the farther a correlation is from 0, the more
strongly it relates to differences in project outcomes, and you can then look
at the sign to see whether it contributes positively or negatively.]

請記得在第二篇中我們提到，負向的關聯性並非壞事；相反地，那是因為問題是以反向的
方式設計，例如：詢問對專案可能發生的問題是不被允許的，這問題就應該對專案產出有
負面的相關。也就是回答偏向於比較低方向，其實是對專案的產出更好（更好的利潤，更
少的延遲，更高的分數等）。真的重要的是專案產出的絕對值，而讀者應能明顯看出那些
問題的方向。






Somewhat surprisingly, our question about a design document clearly
specifying the game to be developed had a very low correlation – below 0.2.
 It also had no statistically significant correlation (p-value > 0.05) with
ROI or critical reception / MetaCritic scores.  This is quite surprising, as
it suggests design documents are far less useful than generally realized.
 The only area where they show a truly meaningful correlation is with project
timeliness.  This seems to suggest that while design documents may make a
positive contribution to the schedule, anyone who believes that they will
contribute much to product success from a critical or ROI standpoint by
themselves is quite mistaken.

意外地，我們關於設計文件的問題只有非常低的關聯性，少於0.2。甚至還有幾個關聯性
（利潤與分數）沒有統計表徵（p值大於0.05）。這結果真是令人意外，也就是設計文件
其實比我們期待的還要不重要。此項目真正影響的其實只有專案時程，若有人認為專案文
件應該會帶給我們巨大利潤或網站分數就是犯了大錯。










We should be clear that our 2014 survey did not ask any questions related to
the project’s level of design innovation.  Certainly, it’s much easier to
limit design risk if you stick to less ambitious one-off games and direct
sequels.  We don’t want to sound as if we are recommending that course of
action.

我們必須坦承本次的問卷並沒有問到關於專案突破或是新穎設計相關的問題。假設我們執
行續作專案或相同類型的專案時，當然很容易就會限制設計風險。此處我們也必須強調我
們並非透過上述問卷得到的結果來鼓吹不需創新。











For the record, we do believe that design innovation is enormously important,
and quite often, a game’s design needs to evolve significantly in production
in order to achieve that level of innovation.  Our own subjective experience
is that a desire for innovation needs to be balanced against cautious
management of the enormous risks that design changes can introduce.  We plan
to ask more questions in the area of design innovation in the next version of
the survey.

我們強調，我們相信創新是很重要的，遊戲的設計需要在製程上不斷進化來達到設計上的
創新。我們主觀的看法是設計的創新是需要小心管理非常多設計可能帶來的風險。我們希
望在下一版本的問卷中能夠帶入這些設計創新方面的問題。










Team Focus

Managing the risks to the design itself is one thing, but to what extent does
the team’s level of focus – being on the same page about the game in
development, and sharing a single, common, vision – impact outcomes?

團隊專注力

管理設計上的風險之外，在同一頁針對遊戲開發的問題中，接下來我們談團隊的專注力，
及團隊有單一共通的信念，是否會影響產出。




Figure 2. Questions around team focus and their correlations.團隊專注力關聯性
的問題







The strong correlations here are not too surprising; these tie in closely
with the design risk management topic above, as well as our questions about “
Compelling Direction,” the second element of Hackman’s team effectiveness
model from Part 2.  As a result, the correlations here are very similar.  It’
s clear that successful teams have a strong shared vision, care deeply about
the product vision, and are careful to resolve disagreements about the game’
s design quickly and professionally.

強烈的關聯性就如同設計風險管理的段落，及第二篇我們提到哈克曼團隊效率模型的"明
確的方向"一樣並不令人意外。也就是得到一樣的結果。顯然成功的團隊內都有強烈單一
共通的信仰，關心產品的方向，小心但迅速又專業地解決對於遊戲設計面的歧見。











It’s interesting to note that the question “most team members cared deeply
about the vision of this game” showed a wide disparity of correlations.  It
shows a strong positive correlation with critical reviews and internal goal
achievement, but only a very weak correlation with project timeliness.  This
seems to indicate that while passion for the project makes for a more
satisfied team and a game that gets better review scores, it has little to do
with hitting schedules.

值得一提的是這個問題"大多數的團隊成員都關心遊戲的方向"，在不同欄位中得到了不同
的關聯性。在內部滿意度與網頁評分中關聯性很高，但對專案時程的關聯性很低。這似乎
指出團隊對專案的熱忱會造成滿意度高的團隊，也會獲得比較高的網頁分數，但對時程沒
有影響。









Crunch (Extended Overtime)


Our industry is legendary (or perhaps “infamous” is a better word) for its
frequent use of extended overtime, i.e. “crunch.”  But how does crunch
actually correlate with project outcomes?

加班

對這個產業來說，加班文化頗獲盛名（或說是惡名昭彰）。到底加班對產出的關聯性如何
？

Figure 3. Questions around crunch, and related correlations.加班的關聯性








As you can see, all five of our questions around crunch were significantly
correlated with outcomes – some of them very strongly so.  The one and only
question that showed a positive correlation was the question asking if
overtime was purely voluntary, indicating the absence of mandatory crunch.

如你所見，五個圍繞在加班的問題都與產出有負面的關聯性。唯一有正面關聯性的問題是
在自願也就是沒有強制規定下的加班。

Even in the area where you might expect crunch would improve things –
 project delays – crunch still showed a significant negative correlation,
indicating that it did not actually save projects from delays.

當我們預期加班會解決問題，也就是減少專案延遲。結果反而有負向相關，也就是加班並
不能幫助專案趕上進度。

This suggests that not only does crunch not produce better outcomes, but it
may actually make games worse where it is used.

同樣地加班也不能幫助產出更好的結果，反而可能更糟。





Crunch is an important topic, and one that is far too often passionately
debated without reference to any facts or data whatsoever.  In order to do
the topic justice – and hopefully lay the entire “debate” to rest once and
for all – we will dedicate the entirety of our next article to further
exploring these results, and we’ll don our scuba gear and perform a “
deep-dive” into the data to ferret out exactly what our data can tell us
about crunch and its effects.

At the very least, we hope to provide enough data that future discussions of
crunch will rest far less on opinion and far more on actual evidence.

加班是一個值得探討的問題，複雜到我們不能跟只用數據來探討它。因此為了揭露它的真
相，希望能夠一勞永逸的講清楚這個問題，我們決定把它留到下一篇來深入探討。我們會
準備好面對這個敵人，從背後找到它所帶來的影響。






Team Stability

A great deal of validated management research shows clearly that teams with
stable membership are far more effective than teams whose membership changes
frequently, or those whose members must be shared with other teams.  Studies
of surgical teams and airline crews show that they are far more likely to
make mistakes in their first few weeks of working together, but grow
continuously more effective year after year as they work together.  We were
curious how team stability affects outcomes in game development.

團隊穩定度

大量的管理研究都說有穩定成員的團隊會比頻繁調動或互相支援的團隊來的有效率。對外
科團隊或空服團隊的研究也說合作的第一個禮拜會容易犯錯，但逐漸會越來越有效率。對
於遊戲製作團隊穩定度與產出是否相關我們產生了好奇。

Figure 4. Questions around team stability and their correlations to project
outcomes.團隊穩定度與專案產出的效率






Surprisingly, our question on team members being exclusively dedicated to the
project showed no statistically significant correlations with project
outcomes.  As far as we can tell, this just doesn’t matter one way or the
other.

意外地，只做一個案子的團隊並沒有顯示出對專案產出有關聯性。

However, our more general questions around project turnover and
reorganization showed strong and unequivocal correlations with inferior
project outcomes.

相反地，對於換人或重組的專案卻對專案產出有負面的關聯性。










At the same time, it’s difficult to say for sure to what extent each of
these is a cause or an effect of problems on a project.  In the case of
turnover, there are plenty of industry stories that illustrate both: there
have been plenty of staff departures and layoffs due to troubled projects,
but also quite a few stories of key staff departures that left their studios
scrambling to recover – in addition to stories of spiraling problems where
project problems caused key staff departures, which caused more
morale/productivity problems, which led to the departure of even more staff.

因此，很難說任何一點直接造成了專案的助力或阻力。以換人來說，業界已經有很多案例
告訴我們在困難專案會遇到的裁員與離職，更有關鍵的團隊成員離開工作室，這造成了連
鎖效應：士氣更低，更多人離職。











We hope to analyze this factor more deeply in future versions of the survey
(and we’d like to break down voluntary vs involuntary staff departures in
particular).  But for now, we’ll have to split the difference in our
interpretation.  As far as we can tell from here, turnover and
reorganizations are both generally harmful, and wise leaders should do
everything in their power to minimize them.

我們希望能在未來的版本更進一步分析這個要素（把自願離職與非自願離職的要素分清楚
）。但目前來說，我們只能解釋，換人或重組造成傷害，明智地來說應該減少這種現象。












Communication & Feedback

We included several questions about the extent to which communication and
feedback play a role in team effectiveness:

溝通與回饋

我們列了幾個關於溝通與回饋在團隊效率方面的問題：

Figure 5. Questions around communication and their correlations.溝通與產出的關
聯性








Clearly, regular feedback from project leads and managers (our third question
in this category) is key – our third question ties in very closely with
factor #11 in the Gallup team effectiveness model from Part 2, with virtually
identical correlations with project outcomes.  Easy access to senior
leadership (the second question) is also clearly quite important.

從專案領導者與管理層來的定期回饋（第三個問題，與第二篇蓋洛普團隊效率模型的第十
一個問題雷同）很清楚地與專案產出有關聯性。能夠與管理層溝通是很重要的。

Regular communication between the entire team (the first question) is
somewhat less important but still shows significant positive correlations
across the board.  Meanwhile, our final question revealed no significant
differences between cultures that preferred e-mail vs face-to-face
communication.

團隊中持續的溝通（第一個問題）雖沒那麼重要，但仍有正面的相關性。順帶一提，最後
一個問題，也就是是否面對面工作卻完全沒有顯示任何相關聯性。




Organizational Perceptions of Failure

組織對於失敗的態度
A 2012 Gamasutra interview with Finnish game developer Supercell explained
that company’s attitude toward failure:
在2012年Gamasutra對芬蘭遊戲開發者Supercell的訪問中說到關於公司對於失敗的態度：

"We think that the biggest advantage we have in this company is culture.  […
]  We have this culture of celebrating failure.   When a game does well, of
course we have a party. But when we really screw up, for example when we need
to kill a product – and that happens often by the way, this year we've
launched two products globally, and killed three – when we really screw up,
we celebrate with champagne. We organize events that are sort of postmortems,
and we can discuss it very openly with the team, asking what went wrong, what
went right. What did we learn, most importantly, and what are we going to do
differently next time?"

我們認為在這間公司中最大的優勢是文化... 我們鼓勵失敗。當遊戲做得好的時候我們慶
功，但當我們砸鍋，譬如要取消專案的時候我們更開香檳慶祝。我們用某種解頗的儀式來
透明的探討那些潛在問題，我們在哪些地方犯錯了，而哪些地方做對了，我們學到了甚麼
，下次我們該怎麼做？




It seems safe to say that most game studios don’t share this attitude.  But
is Supercell a unique outlier, or would this attitude work in game
development in general if applied more broadly?

Our developer survey asked six questions about how the team perceived failure
on a cultural level:

似乎大多數的工作室並沒有相同的做法，Supercell是否這麼特別？如果我們將這樣的態
度推廣出去有用嗎？

我們的問卷中就問了六個關於團隊文化是否接受失敗的問題。

Figure 6. Questions around organizational perceptions of failure and their
correlations.組織如何看待失敗的關聯性









These correlations are quite significant, and nearly all of them are quite
strong.  More successful game projects are much more likely encourage
creative risk-taking and open discussion of failure, and ensure that team
members feel comfortable and supported when taking creative risks.

These results tie in very closely with the concept of “psychological safety”
 explained Part 2, under the “Supportive Context” section of Hackman’s
team effectiveness model.

這些關聯性很顯著，幾乎全部都很重要。成功的團隊都能在創造時鼓勵承擔失敗與談論失
敗，這樣確保團度成員有安全感，感覺創造時有後援。

這些結論與第二篇哈克曼團隊效率模型的支持信仰所提的心理層面的安全感十分雷同。









Respect

Extensive management research indicates that respect is a terrifically
important driver of employee engagement, and therefore of productivity.   A
recent HBR study of nearly 20,000 employees around the world found that no
other leader behavior had a greater effect on outcomes.  Employees who
receive more respect exhibit massive improvements in engagement, retention,
satisfaction, focus, and many other factors.

We were curious whether this also applied to the game industry, and whether a
respectful working environment contributed to differences between failed and
successful game project outcomes as well.  We were not disappointed.











尊嚴

廣泛的管理研究指出在對員工相處上尊嚴起了一個很重要的角色，還因此可以增加產出。
最近一篇哈佛商業文摘對兩萬名全球員工作的研究指出，除了尊嚴之外沒有更有用的領導
行為。有尊嚴的員工在工作，滿足，專注，及其他方面會有巨大的進步。

我們很好奇這是否對遊戲產業適用，是否一個有尊嚴工作環境可以影響專案的產出？這沒
讓我們失望？


Figure 7. Questions around respect, and related correlations.尊嚴的關聯性










All three of our questions in this category showed significant correlations
with outcomes, especially the question about respectful relationships between
team leads/managers and developers.

三個問題都顯示正面的關聯性，特別是團隊管理者及開發者的關係。

Clearly, all team members -- and leads/managers in particular -- should think
twice before treating team members with disrespect: they are not only hurting
their team, but hurting their own game project and their own bottom line.

顯然，團隊成員，特別是管理者，在鞭策成員時應該謹慎避免使用不尊重的方式，那不只
傷害團隊，也傷害專案，甚至損及自己的底線。










Project Planning

We asked a number of questions around the ways different aspects of project
planning affected outcomes:

專案規劃

我們問了關於專案規劃的問題試圖找出與產出的關聯性：


Figure 8. Questions around project planning and their correlations.專案規劃的
關聯性









Clearly, deadlines and accountability are important, as the positive
correlation of the last question shows.  Accountability is obviously a net
positive.

However, teams that took deadlines too seriously, and treated them as matters
of life and death (question #4) experienced a negative correlation with
project outcomes, while having no statistically significant correlation with
project timeliness.  This clearly indicates that treating deadlines as
matters of life and death not only fails to make a positive contribution to
the schedule, it is actually counterproductive in the long run.

顯然，能趕上時程的責任感很重要，這從最後一個問題可看出。

然而，若團隊太關心期限，把它視為生死交迫的議題時卻對產出有負面相關。而且對時程
沒有統計上的顯露出來的甚麼幫助。






This seems to be telling us that taking deadlines too seriously can be
harmful, and high-pressure management tactics are likely to backfire.  We
speculate that successful teams balance their goals for each milestone
against the realities of production, the need for team cohesion, and the
pragmatism to sometimes sacrifice or adjust individual milestone goals for
the good of the overall project.

這告訴我們，太在意期限有時反而有傷害，高壓的管理策略有時候會有反效果。我們認為
優秀的團隊會在目標與現實，團隊向心力，犧牲個體的福祉來換取專案的成就之間取得平
衡。

Surprisingly, daily task re-estimation (question #5) also shows no
significant correlation with timeliness, although it does have a weak
positive correlation with all the other outcome factors.

令人驚訝地，每日對工作的重新評估（第五個問題）對時程的關聯性也沒有統計表徵。即
便對其他的產出分數都有微弱的正相關。




Furthermore, detailed planning (question #1), while positively correlated
with both ROI and timeliness, seems to have no statistically significant
correlation with critical reception or internal goal achievement: this is
clearly useful for project timeliness, but we speculate that this can also
lock the team into a fixed, brittle development plan that can tempt teams to
focus on the lesser good of schedule integrity over the greater good of
product quality, and can sometimes stifle opportunities for improving the
game in development.

再來，詳細的計畫（第一個問題），雖然與時程及利潤都有正相關，但是對網頁分數或內
部滿意度的關聯性沒有統計表徵：那意思是對專案時程有用，但卻常會把團隊帶入一個僵
化，破碎的開發計畫，也就導致團隊只關注細節，沒有巨觀地看整體遊戲的品質，有時會
將遊戲開發的機會扼殺。

The most unambiguous findings here are that accurate estimation (question #2)
and a reasonable level of accountability (question #6) both contribute
positively to all outcome factors.

這部分最清楚的現象是準確的預估（第二個問題），及理性地看待時程（第六個問題）都
對產出有正面幫助。



Technology Risk Management

We were also curious about risks around technology.  How did major technology
changes and the management of those changes affect outcomes, and did the team
participate in any sort of code reviews or pair programming?  The game
industry has countless stories to tell of engine changes or major technology
overhauls that either caused project delays or even contributed to outright
project failure or cancellation.

技術風險管理

我們對於技術方面的風險也很好奇。技術方面的變動及如何處理是否影響著產出？團隊中
是否互相審核程式碼或是配對程式撰寫是否又有影響？遊戲產業常聽過那些故事說引擎的
更迭造成專案的延遲甚至專案取消。

Figure 9. Questions around technology risk management, and their correlations
with project outcomes.技術風險的管理的關聯性









Here, too, we see some very strong correlations.  Question #1 shows that
major technology revamps in development can introduce a great deal of project
risk, while question #3 seems to indicate that the communication of those
technology changes is even more important.

這裡我們也看到很多強烈的關聯性。第一個問題顯示技術的更迭確實造成專案的巨大風險
，同時第三個問題指出對於技術的決定在團隊中充分溝通也異常重要。










However, whether these decisions are driven by internal or external changes
does not appear to be relevant, and while code reviews and pair programming
are clearly positively correlated and statistically significant, the
correlation is a relatively weak one, at under 0.2, and shows no
statistically significant correlation with the project’s critical reception
or achievement of its internal goals.  Although there is significant evidence
that code reviews reduce defects and improve a team’s programming skills, we
were surprised that these correlations are not higher, and we suspect it may
be related to the way the reviews are carried out in addition to the team’s
experience level -- deeper analysis reveals this factor is much more
significant with more experienced teams.  We plan to investigate these more
thoroughly in the next version of the study.

然而，不管改變使用技術的這些決定是否來自於內部的因素，對專案產出似乎不會造成影
響。同時審核程式碼及配對程式撰寫雖然對專案有正面關聯性，但關聯性並不高，小於
0.2，在網頁分數與內部滿意度上更是沒有統計表徵。即便有強烈的證據告訴我們審核程
式碼降低錯誤，增進團隊程式能力，我們很意外得到這麼低的關聯性，我們懷疑是因為審
核與程式人員的經驗有關，更進一步看數據發現有經驗的團隊在這項目的相關聯性會比較
高。我們希望能在下一版本的研究中更深入研究。




Production Methodologies

In Part 1, we revealed the rather shocking discovery that the specific
production methodology a team uses – waterfall, agile, scrum, or ad-hoc –
 seems to make no statistically significant difference in project outcomes.
 However, we also asked a number of additional questions on the topic of
production methodologies:

製程方法論

在第一篇中，我們已經揭露了關於團隊使用的製程方法，也就是瀑布式，敏捷式，或其他
隨意的方法，似乎都沒辦法對專案產出產生有統計性的差異。然而，我們還是在這個項目
中問了額外的問題。

Figure 10. Questions around production methodologies and their correlations.製
程方法論的關聯性





Here, we can see clearly that training in production methodologies, efforts
to improve them, and involving the entire team in prioritizing the work for
each milestone are all significantly correlated (>0.2) with positive project
outcomes.  However, our questions about daily production meetings and
re-prioritization for each milestone showed relatively low correlations.

這裡我們可以清楚地看到，在製程方法上有明確的訓練，改進，每次里程碑團隊都能自己
決定工作優先度對專案產出有正向相關。然而每日製程會議及隨著專案進度調整工作的優
先度，關聯性卻不高。

We see no statistically significant correlation of the last question
(regarding re-prioritization in each milestone) with project delays, but a
small positive correlation with the other three outcomes.  It seems
reasonable to assume that this indicates that while re-prioritization at each
milestone increases product quality, it sometimes does so at the expense of
the schedule.

在最後一個問題（隨著專案進度調整工作的優先度，而非依照原本的規劃），我們看到對
專案的延遲是沒有關聯性，但對其他三者卻有微量正面相關。這似乎很有道理，在每次里
程碑中重新調整優先度就代表專案為了提高品質，接受延遲的現況。


We also further attempted to verify our controversial finding that production
methodology used makes no difference by re-evaluating production
methodologies only for respondents that replied that their teams were
well-trained in their studio’s production methodology (i.e. they answered “
Agree Strongly” or “Agree Completely” to the first question in this
category).  Here, too, we found no statistically significant differences
between waterfall, agile, and agile using Scrum.

This analysis appears to reinforce our earlier finding that the particular
production methodology being used matters very little; what matters is having
one, stick to it, and properly training your team to use it.

我們更進一步想要釐清這個令人爭議的發現，就是使用方法論與否似乎只對那些會精進方
法技巧的團隊有用（那些對第一個問題會回答正面的團隊）。同樣地，我們無法在各種方
法論中找到統計差異。

這個分析顯然支持我們早先的論點，也就是說特定的方法論影響並不巨大，更重要的是堅
定專注於使用的方法，訓練新進的員工適應它。





Collaboration & Helpfulness

We’ve personally experienced many different types of team cultures where
helpfulness was treated as a virtue or a vice.  Some encourage a “sink or
swim” attitude, and deliberately force new hires to learn the ropes on their
own; others go out of their way to encourage and reward collaboration and
helpfulness among team members.  We were curious about the effect of these
cultural differences on project outcomes.

合作與協助

我們了解很多不同的文化在互助協助的看法也正反不一。有些文化鼓勵強者生存的態度，
讓新人自己努力；有些文化則鼓勵同僚之間互助合作。我們對這些文化是否對產出有幫助
產生好奇。

Figure 11. Questions around collaboration and helpfulness and their
correlations.合作與幫助的關聯性







Although the correlations to the individual outcomes here are relatively
weak, the correlations with the aggregate outcome are unambiguously positive.

Note that there is no statistically significant correlation between the
second question and the outcome factor for project timeliness.  We speculate
that some teams may spend too much time and energy obsessing over their
issues and challenges, which can become a time sink or a source of negativity
if carried out to unhealthy extremes.

雖然合作對個別的產出的相關性都很微弱，但基本上還是維持一個正面相關。

注意此處第二個問題與專案延遲並沒有統計表徵，我們懷疑某些團隊可能花了太多時間與
精力在處理互相之間的問題，導致一個不健康的時程結果。










Outsourcing and Cross-Functional Teams

We asked two additional categories of questions.  One category related to the
use of contractors, temporary workers, and outsourcing:

外包與功能性的部門

我們還問了兩個問題，一個關於合約或外包員工。

Figure 12. Questions around outsourcing and their correlations.外包的關聯性








We saw no statistically significant correlations regarding outsourcing, and
as far as our data set can tell, this has no identifiable impact on project
outcomes.  It seems much more likely that any effects of outsourcing have
much more to do with the quality of the contractors or outsourced labor, the
way outsourcing is integrated into the team, its cost, and the quality of the
coordination of the outsourced labor, all of which were outside the scope of
the 2014 survey.

這裡看到都沒有統計的關聯性，也就是說對產出來說是沒有關係的。顯然外包人員都自動
的融入團隊，並沒有在這次的問卷中對產出產生影響。

The other category related to whether sub-teams were divided up by discipline
(art, programming, design) or were organized into cross-functional sub-teams,
each combining several disciplines.

另一個類別是功能性的部門團隊，例如是否分成美術，程式，設計部門，還是將不同的功
能混合在一個團隊中。

Figure 13. Questions around cross-functional teams and their correlations.功能
性部門的關聯性






We also observed no correlations for cross-functional or per-discipline
teams, leading us to conclude that there is probably no “right” answer
here.  If there is any utility in adopting one team structure or the other,
the factors involved were outside the scope of the questions asked in our
study.

我們在分部門或混合團隊都沒看到有關聯性，可能這裡我們問的問題並不正確。也許我們
的問卷應該針對團隊結構進行更進一步的分析。











Conclusions: Best Practices

結論：最佳化團隊

The previous article illustrated that three very different team effectiveness
models all correlate strongly with game project outcomes.  We found that team
effectiveness is tied to having a compelling direction and a shared vision,
an enabling structure and supportive context, a connection with the mission
of the organization, regular feedback, a deep level of trust and commitment
within the team, belief in the mission of the organization, and the essential
element of “psychological safety” that allows team members to feel
comfortable taking interpersonal risks.

我們的前一篇文章中已經談到三種不同的團隊效率模型都與遊戲專案產出分數相關。我們
發現明確的方向與清楚的目標，明確的架構，團隊的支持信仰，與公司的目標與任務一致
，持續回饋意見，深度的信任及團隊承諾，以及心理安全感會讓團隊感覺能承擔更多風險
。







In addition to those factors, all but the last two of the factors outlined in
this article showed significant correlations as well.  Those that showed no
correlations are just as noteworthy as those that did.

在這些要素之中，最後兩者在這篇文章中顯示了顯著地關聯性。其他的部分都沒有這麼強
烈。

For convenience, we deliberately ordered the section descriptions listed in
this article in order from strongest to weakest correlation.  To summarize:

為了方便起見，我們把這篇文章提到由強到弱的關聯性總結如下：







# Design risk management showed the strongest correlations, with a
correlation over 0.57.
# Team focus came in a close second, at 0.50.
# Avoidance of crunch was in third place, at 0.44.
# After that, team stability, communication, organizational perceptions of
failure, respect, project planning, and technology risk management were also
very important, all with correlations between 0.36 and 0.39.
# Production methodologies and collaboration/helpfulness came in last but
were still significant, at 0.29 and 0.20, respectively.
# Outsourcing and the use of cross-functional teams showed no statistical
significance.  These do not seem to impact project outcomes in any general
sense as far as our survey was able to detect.

# 設計的風險管理有最強的關聯性0.57。
# 團隊專注則次之0.50。
# 避免加班第三0.44。
# 團隊穩定，溝通，組織看待失敗，尊嚴，計畫，技術風險管理都很重要，從0.36到0.39
# 製程及合作則只有0.29與0.20。
# 外包與功能性部門則沒有顯著的統計表徵。至少我們的問卷都沒能偵測出他們與產出
  有關。









Finally, in order to help teams make the best use of these results, we’ve
created an interactive self-reflection tool to help teams conduct systematic
post-mortems and identify their best opportunities for growth.

最後，為了幫助團隊能夠使用我們的結果，我們做了一個自我檢查的工具來幫助團隊提早
診斷成功的機會










Self-Reflection Tool

The Self-Reflection Tool is an interactive Excel spreadsheet that includes
the 38 most relevant questions from our survey, along with five linear
regression models (and one for each individual outcome factor and one for the
aggregate outcome score).  To use it, you can simply open it and answer the
38 questions highlighted in yellow on the primary worksheet.  It will then
forecast your team’s likely ROI, critical success, chance of project delays,
and chance to achieve the project’s internal goals.  It will also suggest
your team’s most likely avenues for improving its odds of a positive outcome.

自我檢測工具

這個工具是一個互動式的Excel試算表，包含了38個我們問卷中提到的相關問題，同時有
著五個線性回歸模型（分別都對到我們不同產出的分數）。使用的時候只需開啟這個檔案
，然後回答38個黃色的問題。他就會指出團隊的可能利潤，明顯成功，延遲，滿足內部目
標。他也會建議團隊應該採取來加強之處。










For an even better analysis, print out the questions, ask your fellow team
members to take the survey anonymously, and then average the results.

更好的是，把問題印出來跟團隊成員匿名調查，看看綜合結果。

You can download the self-reflection tool here.

你可以下載自我檢測工具在這個連結。










Conclusion

By comparing hundreds of game projects side-by-side, the Game Outcomes
Project has given us a unique perspective on game development.  In the
process, it has uncovered quite a few surprises.  The study has shown clearly
which factors contribute to success or failure in game projects and pointed
the way toward many future avenues of research, which are listed on our
Methodology page.

結論

把幾百個遊戲專案比較之後，遊戲專案為何成功計畫給了一個遊戲製作上的洞見。內容中
也揭露了一些驚喜。研究結果清楚指出哪一個要素對遊戲專案有幫助，也指出未來研究的
方向，這些列在我們的部落格頁面中。






We believe that this kind of systematic, objective, data-driven approach to
identifying the links between common practices on game development teams and
discrete project outcomes points the way toward a new approach to defining
industry standards and best practices, and hopefully helps lay some
persistent fallacies and popular misapprehensions to rest.  In the future, we
hope to extend the study with a larger number of participants and continue to
refine and evolve it annually.

我們相信這種有系統，有目標，透過數據在遊戲開發團隊的日常差異及專案產出之間來找
到關聯的做法能為遊戲產業指出一條全新的最佳化路線。希望也能幫助導正一些謬論或誤
解。未來，我們希望能透過更大數量的參與者來繼續這個研究，每年調整結果。

More than anything else, we hope that this project will help teams and their
leadership see more clearly that the differences in teamwork and culture
across teams are simply massive, and we have demonstrated that these
differences have an overwhelming impact on the games we make and our success
or failure as organizations.

我們希望這個計畫能幫助團隊與領導者看清團隊與文化的差異，並且我們已經證明這些差
異會對遊戲成功與失敗帶來巨大影響。






Although there is always an element of risk involved, the lion’s share of
your own destiny remains within your own control.

雖然路程上總是充滿風險，出發之路還是由我們所掌舵。

If you want to improve your team's odds of success, the factors we examined
in this study are probably a very good starting point.

假如你希望增加你的團隊的成功機率，這些我們提到的要素都可能是一個契機。









Future Work

Stay tuned for our fourth article, due in one week, in which we will tackle
the tricky and pervasive topic of crunch.  We will analyze the data from a
number of angles and we will see that it makes a clear and unambiguous case
with regard to extended overtime.  Anyone considering subjecting their team
to “crunch” in the hope of raising product quality or making up for lost
time would be well-advised to read it carefully.

By popular demand, we will also be releasing an ordered summary of our
findings as Part 5 one week after that.

未來計畫

請期待我們的第四篇文章，在一周之後會釋出，在其中我們會解析這個棘手且長久以來的
問題：加班。我們會用不同的角度來分析資料，清楚地用一個案例顯示出超時工作的問題
。若有人對加班會提高品質，趕上進度抱持期待的話，千萬要仔細閱讀這篇文章。

在那之後我們還會繼續把總結在第五篇文章釋出。

The Game Outcomes Project team would like to thank the hundreds of current
and former game developers who made this study possible through their
participation in the survey.  We would also like to thank IGDA Production SIG
members Clinton Keith and Chuck Hoover for their assistance with survey
design; Kate Edwards, Tristin Hightower, and the IGDA for assistance with
promotion; and Christian Nutt and the Gamasutra editorial team for their
assistance in promoting the survey.

For further announcements regarding our project, follow us on Twitter at
@GameOutcomes

"遊戲專案為何成功"團隊希望能感謝數百名現任開發者及前輩，讓這個問卷研究能順利進
行。我們也同時感謝IGDA生產力同好會的成員Clinton Keith與Chuck Hoover在問題設計
方面的協助；感謝Kate Edward，Tristin Hightower及IGDA協助推廣此專案；感謝
Christian Nutt及Gamasutra編輯群對我們問卷的支持。對我們的進度有興趣的話，不妨
追蹤我們在Twitter上的帳號@GameOutcomes。

--
"May the Balance be with U"(願平衡與你同在)

視窗介面遊戲設計教學，討論，分享。歡迎來信。
視窗程式設計（Windows CLR Form）遊戲架構設計（Game Application Framework）
遊戲工具設計（Game App. Tool Design ）
電腦圖學架構及研究（Computer Graphics）

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.135.205.117
※ 文章網址: https://www.ptt.cc/bbs/GameDesign/M.1421402262.A.05B.html
※ 編輯: NDark (220.135.205.117), 01/16/2015 17:59:38
※ 編輯: NDark (220.135.205.117), 01/16/2015 17:59:50
※ 編輯: NDark (220.135.205.117), 01/16/2015 17:59:57
※ 編輯: NDark (220.135.205.117), 01/16/2015 18:00:25
推 wangm4a1: 推
推 wulouise: Crunch.這一篇不只是遊戲業，對很多軟體業都有效XD
→ wulouise: 加班實在是負向回饋..
→ wulouise: 只是那個Project Delay其實是Project not delay?
→ wulouise: 就這個是負向寫法，讓我一開始看得時候有點迷惑..
推 akilight: 推~
→ cowbaying: 差不多該收精華了