求是设计会

       （接前文，《一场优质的变乱（上）》，前15章为上半部分，主要介绍了敏捷开发的现状，设计与开发中的术语，跨专业合作中的问题，技术与管理间的矛盾。这20章为下半部分，深入讲述了这场变乱的本质，这是一场提高产品质量的辩论；下半部分也介绍了如何将交互设计与敏捷开发流程融合，交互设计师和敏捷开发者如何交替的接管项目，如何以好产品人人有责的方式，自发性的实现让用户满意的产品，而非通过传统管理手段那种权力传递的方式来完成产品。）

16.IxDA conference in Savannah  塞瓦纳IxDA大会

       In February 2008 I was honored to give the very first keynote speech on the first day of the first annual conference of the IxDA, the Interaction Design Association, in Savannah Georgia. That talk was brand new, different from this one, but I also called it “An Insurgency of Quality”. In it, I exhorted the audience of 450 practicing interaction designers to cease trying to convince managers to respect, support, and adequately fund software design and development. Instead I encouraged them to directly seek out developers for some indigenous, unsanctioned, under-the-radar, yet highly-effective collaboration. As yet ignorant of the term, I was encouraging them to be agile.

       2008年2月，我有幸做在塞尔瓦乔治亚，在IxDA（交互设计协会，Interaction Design Association）第一届年会第一天做开场演讲。那次演讲是全新的，不同于这次，但我还是称之为“一场优质的变乱”。在那次会议上，听众中有450多位交互设计从业者，我劝他们放弃去说服他们的经理，放弃让经理们去尊重、支持并适当的给软件设计和开发拨款。取而代之的，我鼓励他们直接去搜寻开发者，鼓励他们去寻找那些本土的，未被发掘的，并且高效的合作者。在这个懵懂的时期，我建议大家“敏捷”。

17.The essence of insurgency  变乱的本质

       While there are many enlightened executives who clearly see that agile, collaborative teams are the blueprint of the future, there remain many more executives who don’t. The war is still in progress, and it is fought by teams of agile practitioners who believe that by caring exclusively about the quality of the product and the success and satisfaction of the user, their career standing will take care of itself. To me, that selfless commitment is the purest essence of insurgency.

       当然，有很多开明的管理者已经明显的了解了敏捷开发，团队协作才是未来的蓝图，但仍然有更多的管理者没有认识到这一点。战争仍在继续，这是敏捷开发参与者们发起的战争。敏捷开发参与者们专门花费精力关注产品的质量和成功，关心用户满意度。因为他们相信，他们将把让用户满意这件事本身作为他们的事业。对我而言，这种无私奉献是这场变乱最纯粹的本质。

       Shortly after that talk in Savannah, I began to investigate the burgeoning agile movement. To my immense pleasure, I saw many parallels between the disciplines of interaction design and agile development. I saw a hunger in agilist’s eyes for collaborative assistance on the part of designers (and I also saw frustration in the eyes of developers who had been handed pretty pictures by old-skool graphic designers and told to implement them without argument).

       在塞瓦纳大会后不久，我开始调查敏捷运动的快速发展。我看到交互设计和敏捷开发之间有很多共性的准则，这让我惊喜万分。我在敏捷开发者的目光中看到了一种渴望，一种希望某些设计师来协作支援的渴望（我也在开发者的眼中看到了一种挫败感。开发者们总是收到来自老派平面设计师的漂亮图片，并被要求无条件的去完成）。

       I’m a big fan of cross-skilling, but the practical limits are real. Any programming of release quality is beyond the ken of most non-professional programmers. Likewise, any form and behavior synthesis of release quality is beyond the interest level of most non-interaction designers.

       我非常热衷于跨领域技能的学习，但隔行如隔山。就发布质量而言，编程方面，程序员的发布质量总是要好于非专业编程人员；同样的，在形式和交互行为的综合考虑上，交互设计师的发布质量总是要好于那些处于感兴趣水准的非专业设计师。

18.A symbiotic partnership  共生的合作关系

       Some but not all of the interaction design process fits directly into the agile framework. In particular, the activity frequently referred to as “requirements gathering” doesn’t fit well into the agile framework. The foundation of agile is the rhythm and tempo of the iterative loop. Coincidentally, the same is true of much of interaction design, however, not all of interaction design is generative; much of it is empirical and analytical.

       部分（并非全部）交互设计流程适合直接加入到敏捷开发的框架中。特别是那些频繁出现的活动就不适合直接加入到敏捷开发的框架中来，比如“需求收集”。敏捷开发的基础在于节奏和迭代的步调。巧合的是，很多交互设计活动也在同一个节奏和频率中，很多交互设计的东西靠得是经验（实验和观察）和分析。

19.Empirical and analytical  经验型和分析型

       This empirical and analytical work, while also iterative, rarely fits into the rhythm and tempo of software development.

       这些经验性和分析性的工作也是不断重复的，很少能适合软件开发的节奏和步调。

       In particular, the universe doesn’t begin at scrum zero. The work necessary to understand and identify the user, to understand and aim the business objectives, and the work necessary to imagine the product’s end-state doesn’t fit into regular time boxes and therefore should best be performed before programming begins.

       尤其是这个体系并非从归零开始。这些工作必须要了解和识别用户，了解并且明确业务目的，并且要能想象出产品的最终状态。这些工作并不算在正规开发时间里，所以必须在编程开始前实施。

       The empirical part consists mostly of what is called ethnographic research. This typically involves lots of travel and coordination with users and stakeholders scattered around the world. The analytical part consists mostly of skull-work, organizing and reviewing the research results, and developing personas from the material. Once this real-world insight is in-hand, it needs to be written-up for further reference, and the team can do some basic sanity checking on their initial assumptions.

       经验型的部分主要由人种志研究（也称作人类学研究或民族志研究）组成。这通常需要很多的旅行，与散落在世界各地的用户和涉众（也译作干系人）协作。分析型的部分主要由这些部分组成：分析骨架、组织、检查研究成果、从材料中创建任务角色模型。当这些真实世界的观点收集在案（为了以后的引用参考，还需要进行进一步整理），团队可以对初始的假设做一些基本的核对检查。

       Most agile developers would agree that this work has to get done, but many mistakenly think that this “requirements” stuff is handed to the designer by some outsider, like marketers or business analysts. On the contrary, synthesizing the “requirements” is the interaction designer’s most important job.

       大部分敏捷开发者认为这部分事情应该自己做。但也有很多人错误的认为“需求”工作应该由外部人员交由设计师接手，比如市场营销人员或者业务分析师这些外部人员。恰恰相反，综合“需求”是交互设计师最最重要的工作。

20.“Requirements” aren’t wine  “需求”不是酒

       Outsiders will certainly present the team with long lists of demands, but satisfying “requirements” isn’t the same as satisfying users.

       外部人员会向团队呈递一长串的需求清单，但满足“需求”并不等同于满足用户。

       What’s more, not all “requirements” are actually required. “Requirements” handed in from various stakeholders have to be regarded as raw data to be factored into the larger vision. Converting “requirements” into design is akin to converting grapes into wine. In order to do it well, interaction designers need to wrap their heads around the big vision early in the process, and this critical work is rarely seen by developers.

       而且，并非所有的“需求”都是需要的。从更高的层面来看待这些因素，各种涉众递交的“需求”都该被看作原始数据。将“需求”转化为设计就像将葡萄变成酒。为了将其做好，交互设计师需要在流程的早期介入，以便有宏观的认识，开发者很少注意到这个重要的工作。

       Agilists have found that trying to imagine a complete, finished program is not just a waste of time and effort for them, but can often lead them into project-killing featuritis, second-system-effect, and terminal bloat. They know that “you aren’t gonna need it” and worrying about it or coding for it now is a dangerous trap.

       敏捷开发者发现，试着去想象一个完整的、完成后的项目并不是在浪费时间和精力；这样做能引导他们识别什么是最核心的功能，什么是次优先级的特点，这能有效的控制范围蔓延。他们知道“你并不需要这个”，知道担心这个，或者知道现在开发这个为时尚早。

       That’s certainly true for developers, but an integral part of designing the form and behavior of a software solution for end users is imagining the end-state of the product. One of the core competencies of interaction designers is this ability to visualize software behavior without having to code it.

       在开发一个软件解决方案的过程中，想象产品的最终状态，对于开发者来说过于实际了，但这是为用户设计形式和行为不可或缺的环节。不用去编程就能预想出软件的行为，这就是交互设计师的一个核心能力。

21.Agilists fear BDUF  敏捷开发者害怕大的设计方案阵线

       Agilists fear that interaction designers imagine the end-state so they can freeze it into massive Big Design Up Front documents that will forever after force the project down some obsolete blind alley to eventual failure (and this fear is quite justified, as many of our business manager clients do just that). But that is just an echo of the bad-old-days. Enlightened collaborating peers simply don’t do that crap.

       敏捷开发者害怕交互设计师想到产品的最终形态，然后那大块的预想的设计文档就固定了下来。再接着项目按照这些文档一成不变的进行，将大家带入细枝末节的死胡同（这样的担心合情合理，许多业务经理和客户就是这么做的）。不过这只是旧时代的回音了。有见识的合作者不会再干那样的蠢事儿了。

22.Who is the end user?  谁是最终用户

       Interaction designers imagine the end-state so that they can know with certainty who the end user will actually be. The end user imagined by marketers or analysts is often incorrect or inadequately representative. And if you don’t know who your user is, your software is virtually guaranteed to fail to satisfy them.

       交互设计师去想象产品的最终状态，是为了去寻找真正的最终用户。市场营销人员或分析师想象出来的最终用户，往往是不正确的，或者是非典型的。如果你不知道谁是你的最终用户，你的软件必定无法满足他们。

23.What is the actual business case?  哪个是真实用例？

       Interaction designers imagine the end-state so they can determine what actual business case the product will address. Just because business executives and marketing professionals identify an unfulfilled market need, doesn’t mean that their vision of the product to fill it is effective, efficient, or even correct. That’s what interaction designers do better than any other.

       交互设计师去想象产品的最终形态，是为了决定我们的产品要设法实现哪些真实用例（这里把Business Case业务案例翻译为了用例，一般把User Case翻译为用例）。因为当业务管理者和市场营销专家发现一个空白的市场需求，并不意味着他们考虑的产品能有效、高效甚至正确的填补市场空白。而这是交互设计师的优势所在。

24.How can we judge functionality?  我们如何判断最终功能？

       Interaction designers imagine the end-state so that they can establish a performance metric of the necessary tradeoffs that development demands. They construct a functional vocabulary of the product’s capabilities and behaviors and the benefits that the user can gain from them. This is the cauldron where “requirements” are rendered into something useful. It is also the raw material for the product roadmap, showing what should bubble to the top of the backlog.

       交互设计师去想象产品的最终形态，是为了建立一个绩效基准去权衡开发需求中的功能的必要性。他们建立一套产品功能词汇表，建立一组交互行为，以及绘制用户需求相关的功能收益表。这是一个将“需求”渲染成各种有用的东西的大熔炉。这些也是产品路线图的原材料，这能直观的呈现出应该把什么事情从后面提到前面来做。

25.Some things don’t fit  不合拍的事情

       Of course, not all of the empirical work can or should be done in advance; to keep pace with business fluctuations and to test our hypotheses against the real world must be an ongoing part of the design process, and it is best done in concert with the programming.

       当然，并非所有的经验型工作需要提前来做。跟着商业起伏的节奏，不断的核对猜想与现实世界是否一致，是设计流程中持续改进的过程，这最好与编程活动结合起来做。

       While interaction designers are willing, nay eager, to fit their work into the agile rhythm, it would be inappropriate to try to squeeze every aspect of interaction design into the procrustean bed of agile time boxes.

       交互设计师极度渴望把工作与敏捷开发的节奏相匹配，此时，想要把交互设计的每个方面都嵌入到敏捷开发的时间表上，这么做是不合时宜的。

       Just as interaction designers must respect the iterative tempo of the agile programmers, those programmers need to respect the portion of the interaction designers work that falls outside of that cadence.

       当交互设计师尊重敏捷开发者的迭代式节奏的时候，开发者也需要尊重交互设计中，那些有自身节奏的部分。

26.Interface design fits well 非常适合界面设计

       As you can see, much of what interaction designers concern themselves with is strategic vision and product conceptualization. But at least half of the interaction designer’ job is tactical, focused on screen design and behavioral problem solving. This work dovetails well with the agilists time boxed iterations.

       如你所见，大部分交互设计师关心的是策略层面的或者产品概念化的事情。但交互设计师至少有一半以上的工作是花在战术层面的，关注于界面设计和交互行为问题的解决方案。这部分的工作与敏捷开发的迭代周期非常吻合。

       This time-boxable, tactical part of interaction design goes by many names, such as “user centered design” or “user experience design”. I have always called it “interface design”. Dave Hussman calls it “visual design”. Regardless of what it’s called, it gives him tremendous value every single day.

       这些可以时间规划的，战术层面的交互设计工作有许多名称，比如“以用户为中心的设计”或“用户体验设计”。而我则一直称之为“交互设计”。Dave Hussman将这些称作“视觉设计”。不过不管它叫什么，它每天都在产出巨大的价值。

       Some developers think that this tactical design is the only thing that interaction designers do, and many junior practitioners are satisfied with this role, and the resulting collaboration can be very smooth. The only downside is that it doesn’t—by itself—result in satisfied users or successful products.

       有些开发者认为交互设计师只做这些战术层面的设计工作，而很多新人从业者也满足于这样的角色，这让协作变得异常轻松了。这带来的唯一问题只是产品无法满足用户或无法产出成功的产品了。

       What makes such tactical design so valuable to developers is that it is effectively supported by the strategic empirical and analytical work done previously and that is usually invisible to developers.

       开发者通常看不到那些策略性的经验型和分析型的工作，但只有这些工作的有效支持，那些战术层面的设计才能对开发者产生巨大的价值。

27.Bricklaying  砌砖

       When a mason, following a line on an architect’s blueprint, builds a brick wall, he lays one brick after another, repeating the same process a thousand times. Whenever a programmer finds him or herself writing the same line of code more than once or twice, he or she will abstract it into a subroutine or method. In this way, programming differs from all other crafts: repetition is rare; each line of code is unique, bespoke, custom-made, and each one brings to the surface a new set of questions, problems, opportunities, and trade-offs between effort, commitment, and investment on the developer’s part and power, usability, and appropriateness on the user’s part.

       当一个石匠根据建筑师的蓝图砌一堵砖墙，他把砖一块块的垒上去，成千上万次的重复同一工作。每当程序员发现自己在重复同一段代码一到两次时，他可能就会将这段代码提取出来，抽象为一个子程序或一种方法。从这个角度说，程序员不同于任何一种技术工人：重复性很少；每一行代码都是独特的，定制的，自定义的；每个人都给界面带来新的问题，麻烦和机会；每个人都会权衡程序员和用户之间的平衡，在程序员付出的努力、承诺和投资，和用户满意度之间做取舍。

28.Fractals  分形

       Like fractals, this pattern of trade-off-decisions is identical to those made in the board room, just made more frequently and on a somewhat smaller scale. Sometimes, these trade-offs can be just as important in the long term as those made in mahogany-paneled offices. Because these questions arise endlessly on a day-to-day basis at the lowest level of implementation, it’s really easy for business managers to imagine that they are insignificant and only of interest on a technical level. This is not true.

       这种做取舍的决定和董事会做决定很像，只是范围更小，更为频繁，像分形（数学术语，像雪花那样的，小的形状不断重复大的形状）一样。从长远来看，有时这些取舍的决定和在高级办公室里的那些决定一样意义深远。因为这些问题在每天最基础的开发过程中无休止的出现，而业务经理很容易忽视这些，把这些视为技术细节上的小问题。事实并非如此。

29.Battlefield choices  临阵决定

       These myriad, tiny, yet often vital trade-off-decisions are unique to software, and I’ve come to think of them as “battlefield choices”. Much of the impetus for the development of agile methods comes from a desire to better address such battlefield choices. And this is exactly where the interaction design discipline excels. Interaction designers can work side-by-side as an integral part of the agile team, providing informed guidance for each battlefield choice, helping to keep the implementation details true to the bigger product vision.

       这些无数的，细小的，还时常是十分重要的取舍决定是软件特有的，我想把它们称之为“临阵决定”。为了更好的完成这些临阵决定，催生了很多敏捷开发的方法。而这些正是交互设计准则所擅长的。交互设计师可以和敏捷开发团队并肩作战，成为不可分割的一个整体，可以为每个临阵决定提供非官方的指导，可以帮助保持实施细节不偏离整体上的产品愿景。

       In particular, each one of these battlefield choices usually has a technical component and a user-facing component. The technical issues typically can be vanquished with logic and deduction; however, these most effective technical tools are frequently ineffective at solving the human-interaction side of the problem.

       而且，每个临阵决定通常都有技术和面向用户两个层面。技术问题通常能通过修改逻辑或删除来解决；然而那些高效的技术工具往往对解决人机交互方面的问题无效。

30.Cognitive illusions  认知错觉

       There is a large and rapidly-growing body of scientific evidence proving that all humans are subject to a plethora of cognitive illusions and perceptual distortions. Applying logic or deduction may seem a logical approach, but the illusions that bedevil Homo sapiens doom such logical design to a tragically bad user experience. Interaction designers are trained in the craft of unraveling and extracting the underlying goals that drive a user’s sense of satisfaction. They can then design software behavior to satisfy these goals rather than the stakeholder’s firmly-stated but equally firmly distorted “requirements.”

       现在有越来越多的科学证据表明，人类受大量的受到认知错觉和感知扭曲的影响。应用逻辑或者推演可能看上去是种很有逻辑性的方法，但认知错觉是长期折磨现代人的噩梦，它把充满逻辑性的设计变成了用户体验的悲剧。交互设计师会被训练出这样一种技能，挖掘和萃取出用户的潜在目的来满足用户。他们能设计软件的交互行为来满足这些用户的目标，而不是去满足涉众们自己坚信的带有有色眼镜的“需求”。

31.Collaboration leadership over time  随时间变化的协作型领导

       I visualize the leadership role in a project changing over time. This graphic shows what I mean.

       我想象中，随着项目推进，项目领导的角色会不断发生变化。这张图表达了我的意思。

       On the left side of the chart, at the very beginning, the interaction designer drives the project by determining the contextual issues of who the user is and what the business purpose will be. While stakeholders may desire, or even “require” many features and behaviors, the team relies on the interaction designer to assess the tradeoffs involved. He must seek out and assess the potential market advantage and weigh it against the cost of development. The interaction designer leads the team to decide with confidence on the strategic issues facing the product. This keeps the big, conceptual iterations front-loaded in time, where they are far cheaper to make. This means that the developers must be available to consult with the designer to assess the relative cost of each potential feature.

       在图表的最左端是项目的最早期，此时交互设计师驱动整个项目，他们确定谁是用户，业务目的是什么，确定这些大方向上的问题。虽然很多涉众可能希望，甚至“需求”很多功能和交互行为，但此时团队依赖交互设计师的判断，交互设计师负责评估和权衡这些需求。他必须探求和评估潜在的市场优势，并且根据开发成本分析这些优势的权重。交互设计师引导团队在面对产品时，自信的去做策略性决策。这保证了大的概念上的迭代能及时的瞬间载入（原文可直译为前向载入，ajax上的术语，数据一瞬间发送到客户端）。这意味着开发者必须能和交互设计师一起评估每个潜在功能的相关成本。

       As the project proceeds, the agile developer begins to assume more of the leadership role simply because the project’s focus shifts from the user and market to the growing code base. The tempo of time-boxing now drives the content and pacing of battlefield choices. The developers and the interaction designers are working shoulder-to-shoulder in full and constant communication solving the complex problems that emerge. All team members work to assure that there are no unforeseen effects.

       随着项目的推进，敏捷开发者开始更多的扮演领导者的角色，因为项目的重心从用户和市场转向了代码基础。此时，时间表上的节奏驱动着内容和临阵决定的步调。开发者和交互设计师要合而为一，持续沟通，肩并肩的的去解决浮现出来的复杂问题。所有团队成员都要确保不会出现意外状况。

       Soon, the agile developers have taken over the leadership role. Every day the team’s efforts reveal dozens of new, unforeseeable battlefield choices. If the choice regards user-facing behavior, then the interaction designer must be instantly available to consult with the developer to assess the relative benefit of each potential solution.

       很快的，敏捷开发者接手了团队领袖的角色。每天团队付出的努力，都会带来很多新的意料之外的临时决定。假如这些决定与用户交互行为相关，交互设计师必须快速和开发者评估探讨各种相关解决方案的优缺点，并作出结论。

32.The small company Product Owner  小公司的产品拥有者

       One of the reasons that agile is so successful in small projects is that the person who actually owns the product, the entrepreneur, plays the role of “product owner”.

       敏捷开发在小型项目中非常成功，原因之一就是创业者确实的拥有产品，创业者自己扮演“产品拥有者”的角色。

       One of the reasons why agile is often less effective on large projects is because the person who plays the role of “product owner” doesn’t know how to own the product.

       敏捷开发在大型项目中往往无效，原因之一就是扮演“产品拥有者”角色的人往往不懂产品。

       The Scrum Alliance defines “product owner” as the “single person with the final authority representing the customer’s interest in backlog prioritization and requirements questions. This person must be available to the team at any time.”

       Scrum联盟将“产品拥有者”定义为，“拥有最终解释权的个人，这人拥有表达客户需求、规划需求优先级的权力。这人必须随时能出现在团队的任何地方。”

       There are two inherent weaknesses in this approach. First, the “final authority” concept is much weaker than the self-organizing team concept. Wouldn’t it be better to have the team itself have the information and perspective it needs to make such prioritization decisions within its own group?

       这种说法有两个内在的缺陷。首先，“最终解释权”的概念远不如自组织团队的概念。团队自己拥有信息和观点去做优化决定，这是否更好一些？

       The second weakness of this approach is that, in the real-world, the nominal product owner is simply not going to be “available to the team at any time”. The product owner is undoubtedly very busy with other product and project management duties that keep him or her sufficiently out of the loop so that their attention is never fully focused on the particular battlefield choices that bedevil the team.

       另一个缺点是，在现实世界中，名义上的产品拥有者是不可能“随时能出现在团队的任何地方”。产品拥有者必然是非常忙的，忙于其他产品或项目管理的工作。这使得他完全在循环之外，以致于他们的注意力从来没有放在特别的临阵决定上，而这些决定往往对团队至关重要。

       In small start-ups, the single-minded focus of the successful entrepreneur is always on customer satisfaction. What’s more, he or she will be, of necessity, hands-on and participatory. All of this is obviously compatible with the beliefs, values, and practices of agile.

       在小型初创团队，成功的创始人往往一心关注于用户满意度。此外，必要情况下，他还会亲自动手，参与并分享。这些都与敏捷开发的信仰、价值观、实践非常匹配。

       In larger companies, however, the product owner is likely just a salaried employee who has other demands on his or her time, is pulled by outside commitments, and typically lacks the skills to make critical decisions regarding how a product should behave. What’s more, any middle manager on a large, established product line is constrained by convention, by the sheer magnitude of the existing code base, by the inertia of the existing team, and by his own lack of self-confidence in the face of a proven product.

       然而在大企业，产品拥有者往往像是领工资将时间花在其他事情上的人，他们总是被对外承诺拽着鼻子走，他们缺乏决定产品如何行为的能力。而且，在大型公司做产品的中层管理者往往被惯性束缚，他们在已有代码的基础上创建产品，被已有团队的惯性推动，也被他们自己的不自信（他们不敢证明自己的产品）驱动。

       When the agile development team demands tough, decisive action from the “owner”, they are most likely to get prevarication, procrastination, trepidation, and tradition.

       当敏捷开发者需要“拥有者”做粗略决定的时候，他们总是搪塞、推托、害怕、保守。

       Being a skilled and effective product owner is a much more difficult job than most people think.

       作为一个有技能的有效的产品拥有者比大多数人想的都要困难的多。

33.Interaction designers play product owner  交互设计师扮演产品拥有者

       Interaction designers, at their strategic best, are superbly equipped to play the role of product owner effectively, efficiently, and collaboratively. They speak tech to the developers, speak business case to the managers, speak user personas to the marketers, and—being responsible craftsmen—are beholden only to the success of the project.

       从最佳战略部署考虑，交互设计师非常适合扮演产品拥有者，他们能有效地、高效地、协作性地扮演这一角色。他们和开发者谈技术，和管理者谈用例，和营销人员谈用户角色模型，他们是富有责任感的技术人员，他们对项目的成功负责。

       Please note that I am not saying that the interaction designer should “own the product.” I simply believe that the demands of the product owner role are too difficult and too important for an amateur or part-timer. What’s more, a weak stick in the product owner role can have a devastating effect on the entire project. It is very much in the development team’s best interest to assure that a skilled and experienced, responsible craftsman play the part. The role is a perfect fit for a senior interaction designer.

34.The pig and chicken  猪和鸡

       Most of you have heard the allegory of the pig and chicken. At their restaurant they serve ham and eggs, which means that the pig is committed but the chicken is merely involved.

       大部分人肯定都听过猪和鸡的寓言。猪和鸡开了餐馆，卖火腿和鸡蛋，这就意味着猪是完全付出的，而鸡只是参与者而已。

       Developers see themselves as fully committed pigs: their professional standing is linked to the project’s  success or failure. Most developers also view designers as chickens: as mere advisors to the developers, and their professional standing is independent of the project’s fate.

       开发者自视为是全情投入的“猪”：他们的专业身份与项目的成败息息相关。大部分开发者也把设计师视为“鸡”：仅仅给开发者提供建议，他们的专业身份与项目命运相互独立。

       But a true interaction designer desires and demands to be a pig; to be committed. They don’t want to merely contribute advice; they want to buy in to the project and be a full, oinking member of the team.

       但一个真正的交互设计师需要也渴望把自己变成“猪”。他们想不仅仅只是提供建议；他们想将自己和项目捆绑在一起，凝结起整个团队。

       I realize that for this to happen, developers must put their trust in interaction designers, and in turn the designers must prove their commitment by making absolutely sure that their decisions are correct.

       我认识到，要让这一切发生，开发者必须信任他们的交互设计师，而与此同时，设计师必须做出肯定而正确的决定，以此来证明自己的承诺。

       I want each developer here to demand pig-quality commitment from their interaction designer teammates, and I want each interaction designer here to take pig-level responsibility to do the necessary homework to make well-researched, defensible, and correct form and behavior design so that they have the courage to stand by their work.

       我希望在座的每个开发者，都对你们的交互设计师战友抱有期望，期望他们能像“猪”那样的尽心尽力。我也希望在座的每个交互设计师能扛起“猪”那样的责任，做好必要的准备，做出有研究基础的，有说服力的，正确的形式和行为的设计，这样你们才能有勇气对你们的工作负责。

35.There are no chickens in foxholes  散兵坑里没有“鸡”

       There are no chickens in foxholes.

       散兵坑里没有“鸡”。

       I believe that many committed teams of equals, integrating agile development with interaction design, practicing responsible craftsmanship, will be an immense force. The power of our combined efforts will be unstoppable in the war for satisfied users and professionally fulfilled practitioners. This insurgency of quality will show the world how software was meant to be created.

       我相信这样的一种团队，坚信平等，将交互设计整合到敏捷开发中，实践中富有技术责任感。这样的团队会带来巨大的力量。为了满足用户和专业的从业者，我们的努力会不停的聚集起来。这场优质的变乱将展现给世界，优秀的软件是怎么被创造出来的。

       Thank you!

       谢谢！

译后感言

       Alan Cooper提到的这种敏捷开发团队，一直是译者个人比较期待的团队形式，各司其职，人人主动，善于沟通和协作。

       译者感觉，国外敏捷开发的推崇者往往是大牛，他们不满足于在传统团队中完成80分的产品，他们怀着一腔技术理想和产品理想，希望通过自发性的团队来创造满分产品。我想这也是硅谷创新文化的根基。译者在阅读了很多计算机发展的历史，发现那些革命性的满分产品往往不是来自传统团队的管理模式，往往充满了个人英雄主义，从Apple I的沃兹尼亚克，到Dos系统的开发者，到Linux的李纳斯，直到现在最快速的浏览器Chrome令人称道的JS引擎的开发团队——丹麦的“V8团队”。无不在用一种传奇的方式向大家证明，创新源于理想、责任感和协作精神，而非管理。

       也如Alan Cooper所言，其实不论title是什么，最为核心的是提升用户体验，满足用户需求，这是开发者和设计师共同的责任，而不存在谁更高端，更重要这样的说法。Alan Cooper提到的那些总爱把流行的术语挂在嘴边的人往往是装腔作势者，可能触到很多从业人员的痛处。设计师和开发者不断的协作，在产品开发的不同阶段分别接管团队，引导项目走向成功。这里本质上不应该存在静态的领导者的情况，静态的领导者代表的实质上是权力斗争，而动态的交替领导则体现的是合作。有人的地方就有政治，这样理想化的避开权力斗争的团队，也只有怀揣着同样梦想的人才能完成，否则就只能出现单枪匹马，三头六臂的个人英雄来完成产品理想。

       国内的团队，不管是什么样的企业，甚至还远未走到国外完善的传统团队的管理模式，就急于迎头赶上，采用了各种不对称创新来催生产品。国内的敏捷开发也大多出现于这种以boss为中心的赶工项目中，以更少的资源去完成80分产品。这带来的问题是巨大的，企业和项目由于惯性作用，在快速做大后往往转型困难，耗资巨大。这是国内企业难于走上高端的弊病。这是可能高速发展阶段的阵痛，也可能是长久的痛。

       但我们也欣然的看到，搜狗、腾讯、阿里巴巴正在改变这样的现状，逐步在踏实的走出完善的传统团队。这样逐步的积累，更多优秀的开发者和设计师成长起来，教育能力和资源的改进为产品提供更多研究基础，中国的企业也一定能走向自主创新，在这个高科技行业站立起来，从而带动整个国家的经济转型。

译文PDF下载：请猛击这里。

原文PDF下载：请猛击这里。

PS：由于术语和习语过多，又是第一次翻译，翻译中难免有很多错误，希望有心人能跟贴指出，或者发送到我的邮箱gundam215@126.com，我会及时校正更新。

再PS：求是设计会正在筹划翻译《Designing Interactions》，现已有三人愿意协同翻译，一人愿意校对。如有愿意和我们一起翻译此书的，请和我E-mail联系，非常欢迎。