QSM: Volume 3.2: Managing Teams Congruently

Part I. 일치적인 관리 달성하기 (Achieving Congruent Management)

Chapter 1. 비일치성 중독을 치료하기 (Curing the Addiction to Incongruence)

Summary

1. 중독은 치료가 어렵기로 악명이 높은데, 대부분의 사람들이 중독을 인지하지 못하는 것이 첫번째 이유이고, 두 번째로는 중독의 역학을 이해하기 못하기 때문이다. 이러한 실패는 중독을 치료하는 몇 가지 효율적이지 않은 방법들에 대한 믿음으로 이어진다. Addictions are notoriously difficult to cure because most people don't recognize an addiction in the first place, and don't understand its dynamic in the second. These failures lead to the belief in several ineffective methods of curing the addiction.

2. X에 대한 중독을 치료하는 가장 간단한 아이디어는, X가 중독을 야기시킨다는 믿음에 따라, X의 사용을 금지하는 것이다. 하지만 X는 그 중독의 이유가 아니다; 중독의 역학(dynamics)이 중독의 원인이다. 단순한 금지가 효과가 있다는 근거는 없다. 그리고 그것이 동작하지 않는다는 증거는 많다. The simplest idea for curing an addiction to X is to prohibit the use of X, under the belief that X causes the addiction. But X does not cause the addiction; the addiction dynamic "causes" the addiction. There's no evidence that simple prohibition works, and lots of evidence that it doesn't.

3. 업무 상황에서, 우리는 사람들이 행동을 실천할 수 없을 정도로 중독에 너무 오래 머무르는지 신경쓰지 않을 수도 있다. 예를 들면, 코드 패치를 금지하는 것은 적절한 형상관리 시스템을 통해 절대적으로 강제될 수 있다. 중독자들은 그 시스템을 우회할 방법을 찾으려고 애쓰겠지만, 새 사람들은 중독자가 될 기회를 결코 갖지 않을 것이다. In a work situation, we may not care if people stay addicted as long as they cannot practice the behavior. For example, the prohibition of code patching can be absolutely enforced with an appropriate configuration management system. The addicts may struggle to find a way around the system, but new people never have the opportunity to become addicted.

4. 부정적 강화 모델은 X가 사용될 때마다 중독자를 처벌함으로써 중독을 치료할 수 있다고 제안한다. 완벽하게 이루어진다면, 부정적 강화는 중독을 치료하지 않고, 결국은 무언가 파괴하게 만들고, 그것은 항상 중독자만 파괴하지는 않는다. The negative reinforcement model suggests that you can cure an addiction by punishing the addict each time X is used. If done perfectly, negative reinforcement doesn't cure the addiction, but eventually leads to something breaking down, and not always the addict.

5. 어떤 사람은 통증을 완화함으로써 - 달래거나, 구조하는 전략 - 중독을 치료할 수 있는다고 믿는다. 대부분의 경우, 구조 시도는 잠깐동안 고통 증상을 억제할 뿐이다. 반면에 결국 뭔가가 파괴될 때까지 점점 더 큰 노력이 필요해진다. Some people believe you can cure addiction by relieving the pain—a placating, or rescue strategy. In most cases, the rescue attempts only hold down the painful symptoms in the short run, but require greater and greater efforts until something eventually breaks down.

6. 다른 경우에는 구조자가 X에 대한 중독을 구조자에 대한 중독으로 대체하도록 유도한다. 그렇게 되면 구조자는 구조하는 것에 중독된 상태에 빠져들게 된다. 이것은 때로 공동-의존이라고 부른다. In other cases, the rescue attempt leads the addict to replace the addiction to X with an addiction to the rescuer. The rescuer then becomes locked into an addiction to rescuing, sometimes called co-dependency.

7. 효과가 있는 치료법은, 덧셈의 원칙을 사용하는 것이다: X보다 우월한 대안적인 솔루션 Z를 제공한다. 중독자에게 그 대안이 받아들여지게 하기 위해, 다음의 세 가지를 해야 한다: X를 금지하라; 정말로 효과가 있는 대안 Z를 제공하라; 그리고 필요하다면 단기 통증을 부드럽게 하되, X를 사용하지 않는다. A cure that works is to use the Principle of Addition: Offer an alternative solution (Z) that's superior to X. In order to have the alternative way accepted by an addict, you must do three things: prohibit X; provide an alternative (Z) that truly works; and soften the short-term pain, if necessary, but not with X.

Chapter 2. 회유 중독 끝내기 (Ending the Placating Addiction)

Summary

1. 대부분의 비효과적인 패턴1 (가변) 문화는 관리자가 질문하기를 두려워하거나 자리를 차지하는(?) 것을 두려워하는, 꾹 눌러참는 문화이다. Most of the ineffective Pattern 1 (Variable) cultures are placating cultures in which managers are afraid to ask questions or take positions.

2. 이 가변하는 달래는 패턴은 컴퓨팅 초기 시절의 잔재인데, 기계들이 비싸고 융통성이 없어서 기술자들의 고용 안전이 보장되고, 고객과 관리자들은 기계를 복종시킬 수 있을 것 같은 기술자들을 두려워하는 시절이었다. This Variable placating pattern is a remnant of the earliest days of computing, when expensive, inflexible machines gave technicians job security and customers and managers were afraid of any technician who seemed to be able to make the machine obey.

3. 이러한 유형의 달래는 조직은 낮은 품질을 생산한다. 왜냐하면 고객들은 자칫 프로그래머나 IT 조직 전체에 불쾌감을 줄까봐 자기들이 원하는 것을 묻기를(요청하기를) 두려워하기 때문이다. 이런 환경에 있는 프로그래머의 힘은 많은 프로그래머를 오염시켰고, 그들에게 오만하다는 (받아 마땅한) 명성을 주었다. Placating organizations of this type produced low quality because customers were afraid to ask for what they wanted, for fear of offending the programmer or the entire IT organization. The power of the programmer in this environment corrupted many programmers and gave them a (deserved) reputation for arrogance.

4. 몇 가지 저렴한 대안이 현장에 도착하자마자, 고객들은 그들의 IT 조직의 오만함에 반기를 들었다. 하지만 그들은 종종 그들의 비즈니스 전체가 몇 명의 유지보수 프로그래머들의 어깨 위에 달려 있다는 것을 발견했고, 그 외에는 아무도 그들을 위협할 수도 있는 life-critical한 시스템에 대해 거의 아는 바가 없었다. As soon as a few cheap alternatives arrived on the scene, customers rebelled against the arrogance of their IT organizations. But they often found their entire business balanced on the shoulders of one or a few maintenance programmers, and nobody else knew enough about a few life-critical systems to risk offending them.

5. 달래기는 자아존중감이 낮을 때 발생한다. 자아존중감을 높이는 것은 달래기를 막는데 도움은 되지만, 그것 자체만으로는 막을 수 없다. 달래기를 금지하려면, 고객에게 대안적인 서비스 통로를 제공해야 한다. Placating occurs when self-esteem is low. Raising self-esteem will help to block placating, but in itself cannot prevent it. To prohibit placating, you must give customers alternative sources of services.

6. 내부 IT 관리자들은 아웃소싱을 두려워하지만, 이러한 불안과는 다르게 아웃소싱은 최고의 것이 될 수 있고, 이러한 고객 대안은 꼭 아웃소싱에 한정되지는 않는다. Internal IT managers dread outsourcing, but, contrary to these trepidations, outsourcing may be the best thing that ever happened and customer alternatives need not be limited to outsourcing.

7. 아웃소싱은 당신이 달래는 고객이 되는 것을 의미하지는 않는다. 당신이 고객에게 선택권을 주게 되면, 고객은 비난할 필요가 적어지고, IT 조직은 달랠(자기를 꾹 눌러참을) 필요가 적어진다. Outsourcing does not mean you need to placate customers. When you give a customer choices, the customer has less need to blame, so the IT organization has less need to placate.

8. 다수의 성공적인 패턴1 조직들은 소프트웨어 엔지니어링 팀에 의한 경쟁 입찰을 기반으로 운영된다. 고객은 그들의 요구사항을 제출하고 다양한 팀들이 마치 외부의 컨설팅 펌처럼, 일거리를 위해서 그 입찰에 응한다. A number of successful Pattern 1 organizations operate on the basis of competitive bidding for jobs by software engineering teams. Customers post their requirements and various teams bid for their jobs, much as if they were external consulting firms.

9. 락인된 유지보수 상황에서 달래게 되는 것을 방지하려면, 관리자는 다음의 하나 혹은 둘 모두를 채택하여, 프로그래머를 괴롭히는 위험을 감수해야 한다: 할당을 회전(rotate)시키거나, 유지보수 팀을 만들거나. 이 두 전략 모두 어느 프로그래머도 어떤 시스템의 유일한 소유자가 되지 않도록 한다. To prevent placating in the locked-in maintenance situation, the manager must risk offending the programmer by adopting one or both of the following tactics: either rotate assignments or create maintenance teams. Both these tactics ensure that no programmer is the sole owner of any system.

Chapter 3. 비난 중독 끝내기 (Ending the Blaming Addiction)

Summary

1. 비난을 정보로 대체하는 것은 소프트웨어 엔지니어링 관리에 상당한 발전을 가져온다. 특히 조직이 비난하는 행동에 중독되어 있을 때는 더욱 그렇다. Substituting information for blame provides a substantial advance for software engineering management, especially in those organizations addicted to blaming behavior.

2. 조직의 비난 행동을 근절하기 위해서는, 소프트웨어 제품을 개선하면서, 그와 동시에, 관리자는 필요한 교정 피드백을 제공하는 일치적인 방법들을 배워야 한다. To eradicate blaming behavior from their organization at the same time they improve the software product, managers must learn congruent ways to provide necessary corrective feedback.

3. 관리자가 비난 행동에 대응하여 잘못을 범하는 가장 쉬운 방법은 아마도 맞 비난하기에 빠져드는 것일 것이다. 비난하기는 사람들이 비난 받는 것을 피할 방법을 찾도록 동기부여한다. Perhaps the easiest way for managers to err in response to blaming behavior is to slip into blaming back. Blaming motivates people to find ways to avoid being blamed.

4. 프로그래머가 자기 프로그램에서 발견된 오류로 인해 두들겨 맞은 경우, 그들은 오류를 숨기거나 오류에 대한 책임을 다른 사람에게 돌리려고 한다. 테스트와 개발 간의 계속되는 충돌의 대부분은 비난의 분위기에 대한 반응으로 발생한다. If programmers get beaten for faults in their programs, they try hard to conceal faults or to direct the blame for the faults onto someone else. Most of the continuing conflict between testing and development arises as a response to a climate of blame.

5. 관리자들이 가져온, 수년 동안 그들의 기술자들로부터 학대받아온 것에 대한 복수의 염원은 종종 패턴2 (반복) 조직으로의 비전으로 표현된다. 이것이 왜 1960년대에 포장된(packages) 방법론들이 그렇게 대중적이었는지에 대한 이유이다. Managers' wish for revenge for years of abuse from their techies was often expressed as a vision of the Pattern 2 (Routine) organization. That's why in the 1960s, packaged methodologies were so popular.

6. 복수에 대한 열망이 같았기 때문에, 많은 조직들이, 모든 사람이 프로그래머를 비난하는 대처 패턴을 가지게 되었다. 어떤 경우에는 프로그래머들이 반격했는데, 대개는 초이성적이거나 연관성 없음(irrelevant)이 되는 방법이었다. 이 두 가지 스타일은 오늘날 패턴2 문화에서 가장 일반적이다. The same desire for revenge resulted in many organizations with a coping pattern in which everybody blamed the programmers. In some cases, the programmers fought back, usually by being either superreasonable or irrelevant. These two styles are the most common Pattern 2 cultures of today.

7. 모든 패턴2 조직이 이런 비일치적 패턴에 부합하는건 아니다. 몇몇 조직은 반복적인 방법으로 잘 동작한다. 관리자는 비난하지 않고, 기술 스탭은 비일치적으로 대응할 필요가 없다. Not all Pattern 2 organizations fit these incongruent patterns. Some organizations work well in a routine fashion. Managers don't blame and the technical staff need not respond incongruently.

8. 패턴2 (반복) 조직 말고 다른 조직들에서는, 소프트웨어 시스템의 설계, 개발, 유지보수는 예민한(sensitive) 작업자를 필요로 하는, 매우 창의적인 작업이 될 수 있다. 그러한 상황에서는, 비난하기는 품질과 생산성에 기여할 수 있는 어떠한 기회도 파괴해버린다. In organizations other than Pattern 2 (Routine) organizations, the design, development, and maintenance of software systems can be highly creative work, requiring sensitive workers. In such situations, blaming destroys any chance at quality and productivity.

9. 우리가 비난받을 때 느낄만한 고통에는 다음의 두 가지가 있다. 비난의 고통은 심판받는 것 같은 고통이고, 부적절하게 발견된다(?). 인식의 고통은 단지 새로운 정보를 얻는 데 드는 비용이다. There are two kinds of pain we may feel when we are blamed. The pain of blame is the pain of feeling judged and found inadequate. The pain of recognition is simply the cost of getting new information.

10. 그 중요성을 잃지 않으면서 일치적으로 비판을 전달하기 위해서, 나는 그 비판을 나 자신에 대한 서술과 맥락에 대한 서술로 단순하게 시작한다. 일치성은 동작한다. 항상 동작하지는 않는다. 하지만 어떠한 비일치적인 전략보다도 더 자주 동작한다. 게다가, 내가 좋아할만큼 빠르게 동작하지는 않지만, 결국에는 많은 시간을 절약해준다. To deliver criticism in a congruent way without losing its significance, I simply preface the criticism with a statement about myself and a statement about the context. Congruence works. It doesn't always work, but it works more often than any incongruent strategy. Moreover, it doesn't always work as fast as I like, but in the end, it saves a lot of time.

11. 비난하지 않는 조직의 핵심은 열려있음(개방성, openness)이다. 왜냐면 비난하기는 어둠 속에서 잘 자라기 때문이다. 열려있음은 오류의 적이고, 비난하기는 열려있음의 적이다. The key to a non-blaming organization is openness, since blame thrives in the dark. Openness is the enemy of error, and blame is the enemy of openness.

12. 비난하기는 상호작용에서 상대방을 배제하는 것에 기반한다. 그래서, 비난하기는 서로를 그들의 인간성 속에서 깊이 바라보는 사람들 사이에서는 살아남을 수 없다. 복종해야 할 상관이 아닌, 인간 대 인간으로 여기고 상호작용하는 사람이 비난하는 행동을 방지하는 경향이 있다. Blaming is based on the exclusion of the other person from the interaction. Thus, blaming cannot survive among people who see each other fully in their humanness. Anything that gets people interacting on a person-to-person basis rather than as boss to subordinate tends to prevent blaming behavior.

Chapter 4. 다른 사람들과 마주하기 (Engaging the Other)

Summary

1. 달래거나 비난하는 조직에서는, 관리자는 아마도 관리받는 사람들을 대면(engage)하지 않고 관리하려고 시도할 것이다. 그들이 대면하는 것을 회피하는 구체적인 방법은 그들이 선호하는 대처 스타일에 따라 다르다. In placating and blaming organizations, managers attempt to manage without engaging the people supposedly being managed. The particular way they avoid engaging depends upon their favored coping style.

2. 달래는 조직에는, 대면의 부재가 깊이 뿌리박혀 있고, 많은 모습으로 나타난다. 이를테면, 많은 달래기는 타협이라는 이름 아래 숨겨져 있다. In a placating organization, the lack of engagement is deeply rooted and appears in many guises. For instance, much placating is hidden under the label of compromise.

3. 훌륭한 직원들과 상호작용하는 작고 잦은 체크포인트를 만드는 것을 통해, 관리자는 프로젝트 목표와 불일치하는 것에 너무 빠져들기 전에 훌륭한 아이디어의 유용성을 확인할 기회를 가진다. 하지만 달래는 관리자는 이러한 접근법을 약화시킬 것이다. By building small, frequent checkpoints into interactions with brilliant employees, a manager has a chance to verify the usability of brilliant ideas before becoming overcommitted to something inconsistent with the project's goals. Placating managers, however, will undermine this approach.

4. 달래는 행동을 끝내기 위해서는, 당신은 달래는 사람의 자아를 수식으로 다시 가져와야 한다. (달래는 사람이 자신의 자아를 고려하기 시작하도록 해야 한다). 때로 이것은 이중 바인드를 만들어서 이루어질 수 있다. 만약 당신이 한 방향으로 달래면, 다른 방향으로는 달랠 수 없을 것이다. 반대로도 마찬가지다. 때문에 당신은 완벽히 달랠 수 없다. 또 다른 형태의 이중 바인드는, "나를 달래기 위해서는, 나를 달래기를 멈춰야 해!". To end placating behavior, you must bring the placater's self back into the equation. This can sometimes be done by creating a double bind: If you placate in one direction, you won't be able to placate in the other, so in either case, you'll be unable to be the perfect placater. Another form of double bind is, "If you want to placate me, you have to stop placating me!"

5. 비난하기는 몇 가지 방법으로 대면하기를 회피하기 위해 사용될 수 있다. 한 방법은, 규칙을 작성하거나 심지어 구현하는데 있어서, 자동화된 도구를 사용하는 것이다. 그러한 도구 안에 구현된 일반화된 비난은 종종 관련없는(irrelevant) 응답과 마주친다. Blaming can also be used to avoid engagement in a number of ways. One way is to create rules and even to implement them in automated tools. The generalized blaming implemented in such tools is often met with an irrelevant response.

6. 비난하지 않으면서 규칙과 표준을 정착시키는 일치적인 접근 중 하나는, 스텝들의 지능과 전문성(professionalism)을 존중하면서 그들에게 선택지를 주는 것이다. A congruent approach to setting rules and standards avoids blaming, respects the intelligence and professionalism of the staff, and gives them choices.

7. 비난에 대한 한 가지 처방은, 사람들이 인적 자원(human resource) 이상의 무언가로서 서로를 알 수 있는 환경을 마련하는 것이다. 또 다른 처방은 아이키도(aikido)의 접근법인데, 비난하는 에너지를 반대하지 않고, 그것을 따라 흐르고, 조금 더 생산적인 방향으로 부드럽게 선회시키는 것이다. One prescription for blaming is to arrange circumstances in which people can come to know one another as something more than human resources. Another prescription is the Aikido approach of never opposing blaming energy head to head, but flowing with it, then diverting it gently in a more productive direction.

8. 초이성형 관리자는 종종 프로젝트나 조직에 대한 맥락을 그들이 감동적인 연설을 하거나, 비전을 작성하거나, 전략 계획을 발표할 때 한 번에 설정하려고 시도한다. 더 효과적이 되기 위해서는, 커뮤니케이션을 좀 더 작고 연관성 있는 피드백으로 쪼개야 한다. Superreasonable managers often attempt to set the context for a project or organization once and for all when they give an inspiring speech, issue a vision paper, or publish a strategic plan. If they wish to be effective, they must break their communications into small, relevant feedback.

9. 이메일은 누군가와 의사소통하기 원하는 초이성형 관리자에게 완벽한 매체이다. (그러한 관리자는 "누군가에게 의사소통하다"라고 말하기를 즐여할 것이다. "함께"라는 것을 무시하고. 단방향만이 충분하다고 믿는다.) 일치적인 관리자는 의사소통 방법에 다양한 선택지를 가진다. 그 선택은 일치성을 위한 self-other-context 판단을 적용함으로써 간단하게 이루어진다. 발신자와 수신자 사이의 성향의 차이를 충분히 고려하면서. E-mail is the perfect medium for the superreasonable manager who wants to communicate with someone. (Such a manager would likely say "communicate to someone," ignoring the "comm," believing that only one direction is necessary.) The congruent manager has many choices of communication methods. The choice is easily made by applying the self-other-context test for congruence, as well as taking note of personality differences between the sender and the recipient.

10. 문맥과 접점이 없는 대처 스타일 (사랑하기, 증오하기, 무관심)은 조직 환경에서 스스로 교정되는 경향이 있다. 이러한 대처 스타일은 항상 비싼 오류를 만든다. 어떤 조직 문화도, 더 큰 조직의 부에 의존하지 않으면, 맥락에 대한 고려가 없이는 오래 견디지 못한다. Coping styles out of touch with the context (loving, hating, and irrelevant) have a tendency to be self-correcting in an organizational environment. These coping styles invariably lead to costly errors. No organizational culture based on being out of touch with the context can long endure, unless subsidized by the wealth of a larger organization.

11. 비일치적인 관리자는 관련이 없거나 중요하지 않은 일들, 혹은 다른 사람들에게 위임해야 하는 일들로 항상 바쁘다. 예를 들어, 성과 평가를 할 때, 관리자는 관리 작업을 하는 것처럼 보이지만, 그냥 문제를 일으키고 있는 것이다. Irrelevant managers keep busy doing irrelevant or unimportant things, or things they should be delegating to others. For instance, when giving performance appraisals, managers appear to be doing management work, but are simply making trouble.

12. 연인들은 자연스럽게 흘러가도록 홀로 남겨두는 것이 가장 좋다. 사랑은 지속되지 않는다. 하지만 증오는 오랫동안 조직의 내장을 갉아먹을 수 있다. 피의 불화를 다루는 실마리는 참여자들과 함께 사라진(고려되지 않고 있는) 맥락을, 달래지 않으면서, 직면하게 하는 것이다. Lovers are best left alone, to let nature take its course. Love doesn't last, but hate can gnaw the entrails of an organization for a long, long time. The clue to handling blood feuds is to confront the participants with the missing context, but without placating.

Chapter 5. 맥락에 대한 관점을 새롭게 하기 (Reframing the Context)

Summary

1. 관리자의 기본 업무 중 하나는, - 말로건 행동으로건 - 상호작용이 발생되고 작업이 완료되는 맥락을 설정하는 것이다. 실제 환경에서는, 같은 맥락을 바라보는 너무 많은 가능한 방법들이 있고, 따라서 상황을 재구성할 수 있는 무한한 수의 방법들이 있을 수 있다. One of the manager's primary jobs is to set—either by words or actions—the context in which interactions take place and work is accomplished. In real-world situations, there are so many possible ways of looking at the same context that there are probably an infinite number of ways to reframe the situation.

2. 프레임은 공간일 수도 있고 시간일 수도 있다. 그것들은 규모가 변하면서, 또는, 다시 공간이나 시간이 변함에 따라 변화할 수 있다. 프레임은 유형이 될 수도 있다: 그것은 사물인가? 사물의 모델인가? 사물의 모델의 모델인가? Frames can be in space or time. They can be changed by changing scale, again, in space or time. Frames can also be in type: Is it a thing or a model of a thing or a model of a model of a thing?

3. 소프트웨어 엔지니어링 관리자의 또 다른 중요한 업무는 조직의 모든 사람이 같은 관점(프레임)에서, 최소한 호환 가능한 프레임에서 일하도록 하는 것이다. 이것은 거의 대부분 언어, 기호의 시스템을 사용하여 이루어진다. 설정 맥락에서 관리 행동의 대부분은 기호적 커뮤니케이션을 재구성하는 방향으로 유도해야 한다. 그리하여 기호의 비선형성을 변환하거나 활용하여 안정성을 달성한다. Another important job of the software engineering manager is to keep everybody in the organization working in the same frame, or at least compatible frames. This is done almost exclusively through the use of language, a system of symbols. Much of management action in the setting context must be directed toward reframing symbolic communication, to achieve stability by converting or harnessing the nonlinearity of symbols.

4. 상황은 전제의 사용을 통해 정해질 수 있다. 그것이 긍정적인 전제이든 부정적인 것이든. 가장 강력한 전제는 은밀하다. 자신의 연설에서 전제를 알아채지 못하는 관리자는 겉으로 보기에 비일치적인 반응으로 인해 계속해서 신비화딜 것이다...? The context may be set through the use of presuppositions, either positively or negatively. The strongest presuppositions are covert. Managers who don't notice the presuppositions in their speech will continue to be mystified by seemingly incongruent reactions.

5. 우리가 의미를 부여하는 암묵적 멘탈 모델들은 사람마다 다를 수 있는 숨겨진 맥락을 설정한다. 이러한 모델들은 종종 상호작용의 놀라운 특징을 결정하는데, 각 사람은 서로 다른, 다른 사람에게 알려지지 않은, 프레임에서 동작하기 때문이다. The implicit mental models from which we make meaning set a hidden context that may differ from person to person. These models often determine the surprising character of an interaction because each person is operating in a different frame, unknown to the others.

6. '도움이 되는 모델'은 보이기에는 어떠하던지, 모든 사람들은 도움이 되도록 노력한다고 말한다. 심지어 당신이 너무나 명백하게 도움이 되지 않는 사람들을 대할 때조차도, 마치 그들이 도움이 되는 존재처럼 상황을 재구성하는 것은 상황을 개선할 수 있다. The Helpful Model says that no matter how it looks, everyone is trying to be helpful. Even if you're dealing with people who are quite obviously being unhelpful, reframing the situation as if they were being helpful can improve the situation.

7. '악의적 모델'이나 '편집증 모델'은 누군가가 나를 해치려고 하기 때문에 상황이 잘못 흘러간다고 말한다. 상화을 재구성하는데 있어 이러한 방식들의 가장 나쁜 점은, '괴물 만들기 역동'을 통해 자기 충족(self-fullfilment)이 되는 경향이 있다는 것이다. The Malice Model or Paranoid Model says things are going wrong because somebody is trying to hurt me. The worst thing about this way of reframing the situation is that it tends to become self-fulfilling, through the Monsterizing Dynamic.

8. '멍청이 모델'은 당신이 절대 악의에 기여해서는 안된다고 - 그렇지 않으면 어리석음에 기여할 수도 있었을 - 말한다-즉, 조금 더 젠틀한 리프레임이지만, '도움이 되는 모델'보다는 무언가 약간 부족하다. The Stupid Model says you should never attribute to maliciousness that which can otherwise be attributed to stupidity—a gentler reframe, but somewhat short of the Helpful Model.

9. 문화는 언어를 만들고, 언어는 문화를 만든다. 소프트웨어 엔지니어링 문화에서는 확실히 그렇다. 버그 언어를 사용하는 조직은 결함 언어를 사용하는 조직과는 다른 방식으로 소프트웨어를 개발하고 유지한다. Culture makes language, then language makes culture, which is certainly true in software engineering cultures. Organizations using bug language develop and maintain software in a different way than those using fault language.

10. 누군가가 비일치적으로 말할 때, 누락된 self-other-context 요소를 삽입하여 상호작용이 일치적이 되도록 나아갈 수 있다. When someone speaks incongruently, you can move the interaction toward congruence by inserting missing self-other-context elements.

11. 재구성(reframing)은 자신이 비판을 받고 있고 어떻게 응답해야 할지 모르는 경우에 강력한 도구를 제공한다. 핵심은, 제3자 위치에서 먼 거리로 상황을 구성하는 것이다. 누군가가 화를 낼 때 비슷한 기술이 유용하다. Reframing gives you a powerful tool when you find yourself being criticized and don't know how to respond. The key is to frame the situation from a distance—from the third observer position. A similar technique is useful when someone is throwing a temper tantrum.

12. 재구성(reframing)은 완벽한 신념(perfrection beliefs)을 다루는데 특히 도움이 되고, 특히 자신의 신념인 경우에는 더 도움이 된다. Reframing is especially helpful in handling perfection beliefs, especially your own.

Chapter 6. 정보 피드백 (Informative Feedback)

Summary

1. 관리자가 일치적으로 관리하려면, 각 상호작용은 반드시 self, other, context가 균형을 이뤄야 한다. 이러한 이상적인 결과를 달성하는 가장 좋은 방법은 정보 흐름을 개선하는데 집중하고, 각 상호작용에서 정확한 정보를 조금씩 증가시키는 노력을 기울이는 것이다. If a manager is to manage congruently, each interaction must balance the self, other, and context. The best way to do accomplish this ideal result is to concentrate on improving the flow of information, making the effort to create a small increment of correct information out of each interaction.

2. 나의 칭찬과 비난 둘 모두, 내가 그렇게 할 자격이 있는 사람이고, 내가 보스라는 것을 전제하고 있다. 그들은 겁에 질린 자아가 숨을 수 있는 위장된 맥락을 제공한다. Both my praising and my blaming presuppose that I am someone entitled to do so, that I am the boss. They supply a disguised context behind which a frightened self can hide.

3. 매니지먼트 교과서에서 사용되는 "피드백"이라는 것에는 몇 가지 서로 다른 정의가 있다. 가장 일반적인 것 중 하나는, "내가 보스야. 나는 너에 대해 옳고 그른 것(대부분은 그른 것)을 말함으로써 너에 대한 나의 지배력을 보여줄거야"라는 것이다. (피드백을) 주는 사람이 사람들을 직접 다루는 것을 두려워할 때, 피드백은 "나는 당신을 조종하고 있다"라는 의미를 가질 수 있다. 때로 피드백은 수신자(피드백 받는 사람)를 태워버리려는 분명한 의도를 가진다. "Feedback," as used in management texts, has several different definitions. One of the most common is "I am the boss, and I'm going to demonstrate my dominance over you by telling you what is right and wrong about you (mostly wrong)." When the giver is afraid to deal with people directly, the feedback may take on the meaning "I am manipulating you." Sometimes, the feedback is clearly intended to burn the receiver.

4. 이러한 모든 형식은 미래의 행동에 영향을 줄 수도 있고 그렇지 않을 수도 있는 현재에 전달된 과거 행동에 대한 정보로서 피드백의 정의에 적합하다. 그러나, 일치적인 피드백은 당신이 가지고 있지 않은 정보일 수 있으며, 유용하다고 느낄만한 것일 수 있고, 당신에게 적합한 방법으로 자유롭게 사용할 수 있다. 일치적인 피드백은 관계나 조직을 개선할 수 있는 최고의 기회를 제공한다. All of these forms fit the definition of feedback as information about past behavior delivered in the present which may or may not influence future behavior. Congruent feedback, however, is information you may not have, you may find useful, and you are free to use in any way that fits for you. Congruent feedback offers the best chance to improve a relationship or an organization.

5. 피드백은 언제나 The Giver's Fact를 따른다: 어떤 모습을 띄던지, 피드백 정보는 거의 대부분, 받는 사람이 아니라, 주는 사람에 대한 정보이다. 실제로 다른 정보가 포함된 피드백을 제공하려면 기술과 힘든 노력이 필요하다. Feedback always follows The Giver's Fact: No matter what it appears to be, feedback information is almost totally about the giver, not the receiver. It takes skill and hard work to provide feedback that actually contains other information.

6. 피드백은 여러 모양으로 온다: 말로 된 문장으로, 신뢰를 보여줌으로, 도전 기회를 제공함으로, 자유를 허용함으로, 감정을 표시함으로, 공감적으로 들음으로, 특히, 원하는 행동을 모델링함으로. Feedback comes in many forms: offering verbal statements, showing trust, offering a challenge, allowing freedom, showing feelings, listening empathically, and especially modeling desired behavior.

7. 간단하고 정보적인 피드백은 때로 고통의 원인이 될 수 있고, 그래서 많은 관리자가 피드백 주기를 두려워한다. 종종, 관리자 스스로가 피드백에 대해 고통스러운 경험을 해왔다. 그들은 그것을 원한다는 것을 부끄러워하고, 그 안에 숨겨져 있는 갈고리를 두려워하고, 피드백을 주는 사람을 보면서 부러워하거나, 단지 연습 부족으로 기술이 부족하다. Simple, informative feedback can sometimes be a source of pain, which many managers fear to give. Often, the managers themselves have had painful experiences with feedback. They are ashamed to want it, afraid of a hook concealed within it, envious of the people to whom they're giving it, or merely unskilled from lack of practice.

Part II. 팀 맥락을 관리하기 (Managing the Team Context)

Chapter 7. 왜 팀인가? (Why Teams?)

Summary

1. 각 기질마다 팀웍에 만족해할 수 있지만, 각기 다른 이유를 가진다. 예를 들어 NT들은, 팀이 생산할 수 있는 품질에 큰 만족을 얻는다. SJ들은 특히 잘 동작하는(well-functioning) 팀의 효율성을 좋아하는 반면, SP들은 위기 관리 도구로서의 팀을 정말로 좋아한다. Each temperament finds teamwork satisfying, but each for a different reason. The NTs, for instance, find great satisfaction in the quality that a team can produce. The SJs especially like the efficiency of well-functioning teams, while the SPs really enjoy the team as a crisis management tool.

2. NF는 특히 팀을 좋아한다. 그들은 팀웍이 만들어내는 커뮤니케이션, 흥분(excitement), 희망을 좋아한다. 그들은 특히 팀이 구성원의 성장을 촉진하는 방식을 좋아한다. The NFs particularly like teams. They like the communication, excitement, and hope generated by teamwork. They especially like the way the team fosters the growth of its members.

3. 오류 위치 팀(?)은 두 사람이 놓치는 오류가 한 사람이 놓치는 것보다 훨씬 적기 때문에, 쉽게 형성되고, 쉽게 생산적인 상태로 빠르게 전환할 수 있다. Fault location teams are easy to form and easy to bring quickly to a productive state because the errors missed by two people will be much fewer than missed by either one.

4. 경쟁적 협력을 위한 경쟁은 일반적인 팀의 모드이다. 한 가지 예를, 누가 먼저 문제를 찾을 수 있는지 알아보기 위한 온화하고 우호적인 경쟁이다. 슈퍼 팀은, 각 팀들의 대표자들로 구성된, 또 다른 형태의 경쟁이 될 수 있다. 슈퍼팀은 가장 심각한 문제를 해결하기 위해 만나고, 슈퍼팀 구성원은 해결된 문제를 일상 회의에 다시 가져와서 모두가 해결 방법을 공유할 수 있도록 한다. Comperation, for competitive cooperation, is a normal team mode. One example is a mild, friendly competition to see who can locate a problem first. Super-teams, composed of representatives from other teams, can be another form of comperation. The super-team meets to tackle the most serious problems, and super-team members bring solved problems back to their daily meetings, so that everyone shares their solution methods.

5. 팀은 또한 결합된 솔루션 아이디어 셋트가 한 구성원이 제공할 수 있는 것보다 클 때 문제에 탁월하다. 제안된 오류 해결에 대한 기술 검토는 예기치 못한 부작용을 예방한다. 적절하게 구성된 팀은 어느 개인보다 부작용을 예상하는데 더 뛰어나다. 이러한 아이디어의 결합 때문에. Teams also excel at problems when the combined set of solution ideas is bigger than any one member could provide. Technical reviews of proposed fault resolutions prevent surprising side effects. A properly structured team is better at anticipating side effects than any individual can be because of this combining of ideas.

6. 테스트와 리뷰는 모두 제품 개선에 쓰이지만, 리뷰는 프로세스 개선에도 쓰인다. 기술 리뷰는 대개 패턴 1과 패턴 2 조직에 프로세스 개선을 가져오기 위해 첫번째로 시도할 수 있는 가장 쉬운 방법이다. Both tests and reviews work on product improvement, but reviews also work on process improvement. Technical reviews are usually the first and easiest method of process improvement to introduce into Pattern 1 and Pattern 2 organizations.

7. 매니저는 가능한 한 일찍 리뷰를 스케쥴한다는 아이디어를 설득하여 제품 및 프로세스 품질에 영향을 미칠 수 있다. 어떤 리뷰는 제품을 버리게 만들 수도 있을지라도, 프로세스에 대한 훌륭한 정보를 제공한다. The manager can influence both product and process quality by selling the idea of scheduling the reviews as early as possible. Although some reviews may lead to throwing away the product, they yield great information about the process.

8. 기술 리뷰의 가장 놀라운 효과(잘 설계된 온라인 테스팅과 함께 사용된다면)는, 변동성을 줄이는 그 방법에 있다. 일반적으로 리뷰 및 기계 테스트는 품질을 개선하곤 하고, 결과적으로 후속으로 이어지는 테스트 시간을 줄이게 된다. A most striking effect of technical reviews (when used in combination with well-designed on-line testing) is the way they reduce variability. More conventionally, reviews and machine tests are used to improve quality and consequently reduce subsequent testing time.

9. 매니저에게 더욱 중요한 것은, 리뷰가 품질 및 후속 테스트 시간의 변동성을 줄여준다는 것이다. 시스템 테스트에 전달되는 결함의 수에 변동이 적다는 것은, 시스템 테스트 시간이 더 예측가능하게 된다는 것이고, 그것은 더 좋은 관리가능성을 의미한다. Even more important for managers, reviews reduce variability in quality and subsequent testing time. Less variation in the number of faults shipped to system test mean more predictable system test time, which again means better manageability.

10. 패턴3 (조정) 조직에서, 매니저는 프로세스 관리에 잡중하기 시작하고, 팀을 만들고 제어하는데 굉장히 많은 시간을 사용한다. 팀의 종류는 관리자와 인력(워크포스)의 상상만이 제약이다. In Pattern 3 (Steering) Organizations, managers begin concentrating on process management, and spend a great deal of time creating and controlling teams. The types of teams are limited only by the imagination of the manager and the work force.

Chapter 8. 성장하는 팀 (Growing Teams)

Summary

1. 조직이 팀워크의 힘을 경험하면, 소프트웨어 유지 관리 및 개발을 처리하는 영속적인 팀을 도입하는데 유리할 수 있다. Once an organization experiences some of the power of teamwork, the climate may be favorable for introducing more permanent teams to deal with software maintenance and development.

2. 팀에는 시작 비용(startup cost)이 필요하고, 많은 프로젝트에서 이 시작 과정이 너무 길어서 프로젝트 동안 손실이 복구되지 않는다. 이 주장은 팀 구성(formation)의 더 나은 관리를 선호한다. Teams require a startup cost, and in many projects this startup process is so long the loss is never recovered during the life of the project. This argument favors better management of team formation.

3. 관리가 형편없을지라도, 일련의 프로젝트에서 팀을 재사용하여 팀 시작 비용을 회수할 수도 있다. 불행히도 더 나은 소프트웨어 조직만이 팀을 재사용하는 것 같다. 부주의한 관리자는 잘 동작하는 팀을 해체하는 경향이 있다. Even if management were poor, the cost of team startup could be recovered by reusing the teams over a series of projects. Unfortunately, only the better software organizations seem to reuse their teams. Insecure managers tend to dissolve well-functioning teams.

4. 재사용 가능한 구성 요소는 하드웨어 및 소프트웨어 개발의 기본 단위이고, 소프트웨어 팀은 소프트웨어 엔지니어링 프로세스의 기본 설계 단위이다. 관리자의 업무는, 팀을 만들고, 육성하고, 유지하여, 안정적이고 예측 가능한 프로젝트로 구성 및 재구성할 수 있게 하는 것이다. Reusable components are the basic units in hardware and software development, and the software team is the basic design unit for software engineering processes. The manager's job is to create, nurture, and maintain the teams that can be configured and reconfigured into reliable, predictable projects.

5. 많은 관리자가 성과가 좋은 유지보수 팀을 알아채지 못한다. 그러나 이들은 가장 재사용 가능한 팀이다. 유지보수 엔지니어들은 살아있는 시스템을 관리할 때 발생할 수 있는 높은 실수 위험을 줄이기 때문에 팀에 끌린다. 유지보수 팀은 또한 유지보수 커리어 함정 - 가장 크리티컬한 시스템을 관리하는 엔지니어들이, 형편없는 관리로 인해, 가장 잘 떠나곤 하는 - 을 제거한다. Many managers don't notice well-performing maintenance teams, yet these are precisely the teams that are most reusable. Maintenance engineers gravitate to teams because they reduce the high risk of mistakes in maintaining living systems. Maintenance teams also remove the maintenance career trap, a situation created by poor management in which the engineers who maintain the most critical systems are the engineers most likely to leave.

6. 비효과적인 관리자가 종종 동기부여와 팀워크라고 부르는 것은 그 용어들의 실제 의미와 동일하지는 않다. 그들에게 "팀워크"는, "내 말을 의문 없이 따르는 모든 사람"을 의미하고, "동기부여"는 "모든 사람들이 열악한 상황에서 열심히 일하도록 압력을 가하는 것"과 같다. What ineffective managers often call motivation and teamwork is not the same as the real meaning of those terms. To them, "teamwork" equals "everybody doing what I say, without question," and "motivation" equals "pressuring everybody to work hard under poor conditions."

7. 프로세스 개선에 의한 관리는 팀 프로세스 개선에 의한 관리로 확장될 수 있다. 이 접근법은 팀을 수립하고 각 구성원의 최선을 사용하는 기술을 훈련한다; 최고의 팀과 개인의 성과를 분석하여 그들이 잘하고 있는 이유를 파악한다; 이러한 최상의 프로세스를 전달하기 위한 훈련 및 기술 리뷰 시스템을 개발한다. Management by process improvement can be extended to management by team process improvement. This approach establishes teams and trains them in techniques for using the best from each member; analyzes the performance of the best teams and individuals to determine why they are doing so well; and develops systems of training and technical reviews for passing on these best processes.

Chapter 9. 팀 맥락에서 관리하기 (Managing in a Team Environment)

Summary

1. 많은 관리자가 그들의 높고-위대한 태도로 팀 스피릿을 훼손한다. 다른 관리자들은 무의식적으로 효과적인 팀의 혜택을 누리려는 자신의 노력을 약화시킨다. 첫번째 그룹은 절망적이지만, 두번째 그룹은 더 일치적이 되는 방법을 배움으로써 나아질 수 있다. Many managers undermine team spirit by their high-and-mighty attitudes. Other managers unconsciously undermine their own efforts to reap the benefits of effective teams. The first group is hopeless, but the second can be helped by learning to become more congruent.

2. 팀 기반 조직에서 관리자의 역할에 대한 가장 빈번한 혼동은 관리자와 팀 리더 사이에 대한 것이다. 팀 리더는 팀의 기술적 작업을 담당한다. 관리자는 둘 혹은 그 이상의 팀에 대한 비기술적인 방향을 담당한다. Perhaps the most frequent confusion about the manager's role in a team-based organization is between the manager and the team leader. The team leader is responsible for the technical task of the team. The manager is responsible for the nontechnical direction of two or more teams.

3. 팀 내부 관점에서는, 관리자의 역할은 어떤 비기술적인 업무를 처리하여 팀 리더의 부담을 덜어주는 것이다. 외부 관점에서는, 관리자의 역할은 조직의 더 높은 목표 측면에서 팀을 제어하는 것이다. Seen from inside the team, the manager's role is to unburden the team leader by handling certain nontechnical tasks. Seen from the manager on the outside, the manager's role is to control the team in terms of the higher goals of the organization.

4. 팀을 빌드하는 가장 좋은 방법은 도전적인 작업을 위임하는 것이다. 도전은 감성적인 반응으로, 과제 자체만큼 과제가 할당되는 방식에 영향을 받는다. 예를 들어, 각 기질은 다른 방식으로 도전을 받기 때문에, 효과적인 리더는 각 기질에 대해 도전을 재구성해야 한다. The number one way to build teams is to delegate challenging work. Challenge is an emotional reaction, influenced as much by the way the task is assigned as by the task itself. Each temperament, for instance, is challenged in a different way, so an effective leader has to reframe a challenge for each temperament.

5. 위임은 여러가지 이유로, 비관리자가 생각하는 것처럼 쉽지는 않다. 오해가 일어나기 쉽고, 잘못된 의사소통 수단을 사용하고, 실수를 저지르고, 일이 잘 풀리지 않고 사람들이 당신이 한 일에 대해 불평할 때 방어적이 되기 쉽다. Delegating is not as easy as it seems to non-managers, for several reasons. It's easy to be misunderstood, to use the wrong communication medium, to make mistakes, and to become defensive when things don't work out and people complain about what you did.

6. 관리자는 내부 팀 업무에 대한 통제의 정도에 대해 두 가지 실수를 한다: 너무 많거나, 너무 적다. 패턴1 관리자는 너무 적게 개입하여 팀을 회유하는 경향이 있다. 패턴2 관리자는 너무 많이 개입하여 과도하게 교정하는 경향이 있고, 팀을 비난하는 경향이 있다. 종종 그것은 종종 사람들 각자가 일을 더 잘 할 수 있었다고 주장하는 형태로 이루어진다. 회유와 비난은 일반적으로 팀이 아닌 관리자의 내부 요구에서 비롯된다. Managers make two mistakes concerning the amount of control they exert over internal team affairs: too much or too little. Pattern 1 managers tend to intervene too little, placating the team. Pattern 2 managers tend to overcorrect by intervening too much, blaming the team, often in the form of claiming to be better able to do the job themselves. Both placating and blaming usually stem from the manager's internal needs rather than the team's.

7. 잘 기능하는 팀은 그 구성원들의 행동으로 알 수 있다. 그들은 모든 사람들이 결정에 참여하도록 한다. 그들은 서로와 연락을 유지하고, 모두가 기여할 기회를 느낀다. 그들은 하나가 되어 '우리'라는 말을 사용하여 말한다. 그들은 재미있다. 그들은 각자 서로의 개발적인 강점에 의지하고, 모두 팀을 위해 최선을 다하고 있다. 그들이 말할 때, 그들은 모든 사람이 이해하도록 주의를 기울인다. 그들은 각각 강하고 유용하다고 느끼지만, 팀으로서의 그들의 역량을 벗어나면서까지 그렇지는 않는다. 마지막으로, 그들은 진정으로 어떻게 느끼는지 모여주기 때문에, 그들을 모니터링하기가 쉽다. Well-functioning teams can be recognized by the behavior of their members. They make sure that everybody participates in decisions. They stay in touch with one another, and everyone feels the chance to contribute. They are united, and talk in terms of "we." They have fun. They rely on each others' individual strengths, and all do what they can that's best for the team. When they speak, they take care to be sure that everyone understands. They each feel strong and useful, but not out of proportion to their competence as a team. Finally, it's easy to monitor them, because they show how they are truly feeling.

8. 당신은 다른 징후에 대한 경보 상태를 트리거하기 위해서만 단일 사전을 사용하여 팀을 젠틀하게 관리한다. 개입을 할 때는, 팀빌딩을 하고 팀 문제 해결을 할 수 있는 기회로 사용한다. You manage a team gently, using single incidents only to trigger a state of alertness for other signs. When you do make interventions, you use them as opportunities for team building and team problem solving.

9. 관리자가 잘 기능하는 팀을 부러워하기 쉽다. 그에 대한 치료법은, 성공적인 관리의 즐거움과, 팀의 성공에 성공적인 관리가 기여하는 부분을 강조하는 것이다. It's easy for a manager to envy a well-functioning team. The cure is to emphasize the joys of successful management, and the part successful management plays in the team's success.

10. 팀을 보상하려는 시도는 종종 역효과를 낼 수 있다. 무엇이 팀에게 진정으로 보상할 수 있는지 찾아내기 위해 팀과 같이 논의해보라. MOI 모델을 사용하여 각 순간에 어떤 종류의 개입이 필요한지 결정하라. Attempts to reward a team can often backfire. Work with the team to find out what would truly reward them. Use the MOI model to determine what kind of intervention a team needs at any moment.

11. 사람들을 처벌하는 것은 관리자의 일이 아니다. 사람들이 배울 수 있는 기회를 마련하는 것이 관리자의 일이다. 그것을 하기 위해서, 관리자는 엄마 오리(Mother Duck) 역할을 해서 팀을 외부의 부적절한 영향으로 팀을 보호해야 할 수도 있다. It's not the manager's job to punish people. It is the manager's job to arrange opportunities for people to learn. To do that, the manager may have to play Mother Duck, protecting the team from inappropriate influences from outside.

12. 퍼포먼스 평가는 팀 정신을 파괴할 수 있다. 가능하면 피하라. 만약 불가피하다면, 팀에게 요청해서 서로의 퍼포먼스를 평가하도록 하는게 더 효과적인 방법이다. 외부 퍼포먼스 점수는 팀의 전체 점수에 팀이 부여한 개인 점수를 곱하여 얻을 수 있다. Performance appraisals can destroy team spirit. Avoid them if you can. If you can't, a more effective way is to ask the team to appraise the performance of each member. An external performance rating is obtained by multiplying the team's overall rating by the individual's rating as given by the team.

Chapter 10. 팀을 시작하고 끝내기 (Starting and Ending Teams)

Summary

1. 팀에 대한 관리자의 임무는 팀이 필요로 할 때 시작하고, 효과적으로 일할 때 그대로 내버려 두고, 그렇지 않을 때 중지하는 것이다. The manager's job with respect to a team is to start it when a team is needed, leave it alone when it's working effectively, and stop it when it's not.

2. 위기 가운데서 팀을 구성하는 것은 사소한 관리 업무가 안디ㅏ. 만약 조직이 심하게 우울해져 있다면, 새 팀의 첫 번째 미팅에서 숙련된 퍼실리테이터가 필요할 수 있다. 팀의 구성은 모든 사람이 고유한 기여를 할 수 있도록 해야 한다. It's not a trivial management task to form a team during a crisis. If the organization is severely depressed, you may need a skilled facilitator in the first meetings of a new team. The composition of the team must ensure that everyone has some unique contribution.

3. 수명이 긴 팀의 위기보다 더 나은 출발점은 유지관리 또는 개발에서 자연스럽게 형성된 팀을 사용하는 것이다. 비결은, 그들의 프로젝트가 성공적으로 완료되었다고 해서 그냥 그것들을 해체하지 않는 것이다. A better starting point than a crisis for long-lived teams is using teams that have formed naturally in maintenance or development. The trick is not to dissolve them just because their project was completed successfully.

4. 조직의 기존 팀도 변화의 장애물이 될 수 있다. 그들은 연대의 고리를 깨뜨리거나, 더 나은 일을 하지 못한 것에 대해 팀을 비난하는 방법으로 특별한 문제 해결 팀을 만들려는 시도를 볼 수 있다... (?) Existing teams in the organization can also be an impediment to change. They may see attempts to create special problem solving teams as a way of breaking up their ring of solidarity, or of placing blame on their team for not doing a better job.

5. 잘 기능하는 팀은 바쁜 관리자의 가장 큰 잠재적 자산이다. 관리자가 팀이 그들의 작업을 수행하도록 허용한다면. 진짜 팀은 전형적인 관리자보다 훨씬 강하며, 최고 경영진에 의해 위협받지 않곤 한다. 진짜 팀의 의견은 대개 훨씬 더 많은 무게를 가진다. A well-functioning team is the busy manager's biggest potential asset, if the manager lets the team do its work. A real team is much stronger than your typical manager, and not as likely to be intimidated by top brass. A real team's opinion is likely to carry a lot more weight.

6. 팀은 프로젝트가 늦어지면 패닉에 덜 빠진다. 비일치적인 관리자는 스스로가 패닉에 빠질 때 다른 사람들이 침착한 상태로 남아있는걸 보기 좋아하지 않고, 종종 자신의 패닉을 다른 사람들에게 퍼뜨리려고 한다. 그러나 숙련된 팀은, 그냥 관리자의 비일치를 흡수하고, 대부분의 경우 진정 효과가 있다. Teams are less likely to panic when the project is late. Incongruent managers don't like to see other people remaining calm when they themselves are panicking, and often try to spread their panic to others. An experienced team, however, simply absorbs the manager's incongruence and most often has a calming effect.

7. 외부에서 주입된 관리되지 않은 작업의 한 조각이 계획된 작업의 양을 붕괴시킬 수 있다. 팀은 고객 및 경영진의 시연과 같은 그러한 방해를 처리하기 위해 전문가 역할을 설정할 수 있다. 일반적으로, 팀은 현실적인 우선순위를 설정하고 충족하는 작업을 더 잘 수행할 수 있다. One piece of unmanaged work injected from the outside can disrupt any amount of planned work. Teams can establish a specialist role to handle such disruptions, such as demonstrations of customers and management. In general, teams can do a better job of setting and meeting realistic priorities.

8. 팀이 모든 문제를 스스로 처리할 수는 없다. 팀원이 다른 사람과 함께 일할 수 없어서 팀을 떠나야만 하는 경우들이 있다. 관리자의 업무는, 그럴 때 개입하여 팀의 구성을 변경하는 것이다. Teams can't handle every problem by themselves. There are times when a team member is unable to work with others and has to leave the team. Then it is the manager's job to intervene and change the composition of the team.

9. 아마도 성공적인 팀워크의 주된 장애물은, "이건 내꺼야. 그러니까 다른 사람들이 건드리거나, 심지어 보지도 못하게 할거야", 또는, "그건 내 아이디어가 아니니까, 최소의 아이디어일 수 없어." 같은 개인의 태도일 것이다. 이러한 폐쇄적인 태도는 변함없이 소프트웨어의 재앙으로 이어지며, 반드시 지속되지 말아야 한다. 그 사람이 이러한 태도를 바꾸기로 결심할 수도 있다. 하지만 전형적으로는, 이 사람을 다른 사람과 교환해야 한다. 모든 사람이 소프트웨어 비즈니스에 적합하지는 않다. Perhaps the main impediment to successful teamwork is an individual's attitude that "Because it's mine, I won't let others touch it, or even see it" or, "If it's not my idea, it can't be the best idea." This closed attitude invariably leads to disaster in software, and must not be allowed to persist. A person may decide to change this attitude, but typically you have to exchange the person for someone else. Not everybody is cut out for the software business.

10. 때때로 팀은 당신이 파악할 수 있는 이유 없이 역기능 상태가 되거나, 여러 사람들의 참여로 인해 역기능 상태가 된다. 그런 경우, 관리자는 상황에 개입해서 팀을 해체해야 한다. 이것은 보통 그런 멤버들에게 경고를 준 이후에 일어난다. Sometimes teams become dysfunctional for no reason you can identify, or because of the involvement of several people. In those cases, the manager has to step in and break up the team, usually after putting the members on warning.

11. 관리자가 일단 사람들을 임명하면, 위기 상황이 닥쳤을지라도, 그 팀은 생명을 유지하고, 변화가 필요할 때 해산하기 어려울 수도 있다. 따라서, 팀이 작동하지 않는다면, 종료시킬 수 없는 팀을 만들지 말아야 한다. 임시 그룹을 만들 때는, 명확한 수명을 부여하고, 그 후에 그들은 스스로 존재 이유를 정당화해야 한다. Once a manager has appointed a group of people, even in a crisis, it takes on a life of its own and may be hard to dissolve when needs change. Thus, you should avoid creating teams you cannot terminate if they become nonfunctional. When you do create temporary groups, give them a definite life span, after which they will have to justify their existence again.

12. 역기능적으로 보이는 그룹은 당신이 단순히 의도한 것과 다른 기능을 제공할 수 있다. 그룹을 해체하기 전에, 그것이 어떤 기능을 제공하고 있는지 파악하려고 해봐라. Groups that seem to be dysfunctional may simply be providing a different function than you intended. Before you break up a group, try to determine what functions it serves.

Part III. Epilogue

지금까지, 이러한 Quality Software 권들은 나에게, 그리고 아마도 당신에게도 긴 여정이었다. 이것을 시작했을 때, 나는 최종 볼륨은 고품질의 소프트웨어 엔지니어링 조직을 위해 정확히 무엇을 해야 하는지에 대한 레시피들 - CASE 도구, 프로젝트 조직, 훈련 프랙티스들, 테스팅 기법들, 형상 관리 접근법과 같은 요소가 포함된 레시피 - 로 구성될 것이라고 생각했다. 그 과정에서 나는 그러한 재료들에 대해 논의했지만, 결코 레시피를 제공하지는 않았다. 이것은 실수가 아니라, 의도적인 누락이었다. 왜냐하면 능력 있는 쉐프가 없다면, 레시피들은 단지 재료들의 엉망에 불과하기 때문이다. Up to now, these Quality Software volumes have been a long journey for me—and perhaps for you. When I started, I imagined that the final volume would consist of a recipe for precisely what to do to create a quality software engineering organization—a recipe with ingredients such as CASE tools, project organization, training practices, testing techniques, and configuration management approaches. Along the way, I've discussed such ingredients, but I've never given the recipe. This was no mistake, but a conscious omission, because without a capable chef, a recipe is merely a mess of ingredients.

나는 이제 전체 레시피와 함께 "변화를 예측하기(Anticipating Change)"라는 일반적인 제목으로, 추가적인 책을 준비하는 중이다. 나는 이미 처음 여섯 권의 책이 유능한 요리사의 수에 영향을 준다는 것을 보았다. 나는 또한 엉망진창을 만드는 많은 요리사가 있다는 것을 알고 있고, 그들에게 잘못된 요리법을 제공했다며 나를 비난한다는 것을 알고 있다. I'm now in the process of preparing additional volumes, under the general title of "Anticipating Change," with the full recipe. I have already seen that these first six volumes have influenced the number of capable chefs out there. I also know there are plenty of chefs who will make a mess, then blame me for giving them the wrong recipe.

나는 확실히 소프트웨어 엔지니어링 성공을 위한 몇 가지의 완변하게 건전한 레시피들을 엉망으로 만들긴 했다. 나 자신에 대해 기분이 별로 좋지 않을 때, 나는 사람들을 괴롭하고, 무시하고, 비난하고, 나 스스로를 비난하고, 어려운 상황에서 도망치고, 내 머리를 추상적인 구름들 속에 파묻었다. 이 모든 과정을 통해, 나는 일치적이 되지 못할 때, 소프트웨어 엔지니어링 문제를 해결하거나 소프트웨어 엔지니어링 조직을 만들려고 하는 것은 의미가 없다는 것을 알게 되었다. 그래서 나는 그 일을 먼저 하고, 당신도 그렇게 하길 원한다. I myself have certainly messed up some perfectly sound recipes for software engineering success. When I haven't felt good about myself, I've bullied people, ignored them, blamed them, blamed myself, run away from difficult situations, or buried my head in clouds of abstraction. Through all this, I've learned that there's simply no sense trying to solve software engineering problems, or create software engineering organizations, when I'm not able to be congruent. So, I work on that first, and that's what I hope you do.

수십년 전에, 나는 컴퓨터가 훨씬 더 나은 세상을 만드는데 중요한 요소가 될 수 있다고 믿었기 때문에 컴퓨팅에 들어갔다. 나는 때로 흔들렸지만, 결코 그 비전을 잃은 적이 없다. 나는 순진한 몽상가일지 모르지만, 비슷한 비전을 가진 사람들이 더 나은 세상을 만들 것이라고 늘 느꼈다. 불행히도 나는 개인적 이득, 다른 사람에 대한 권력, 또는 단순한 비열함과 같은 다른 것에 의해 움직이는 많은 사람들을 만났다. 나는 그런 사람들을 인해하지 못하고, 그들과 잘 대면하지 않으며, 그들이 우리 직업을 해친다고 생각한다. 그러나 설교는 의미가 없다. 왜냐하면 그들은 내가 그들을 위해 글을 쓰지 않았고, 오래 전에 이런 페이지를 떠났다는 것을 분명히 감지할 수 있기 때문이다. Decades ago, I went into computing because I believed that computers could be a major factor in making a far better world. I've wavered at times, but I've never lost that vision. Perhaps I'm a naive dreamer, but I always felt that this better world would be created by people who were driven by similar vision. Unhappily, I've encountered many people who were driven by something else—personal gain, power over others, or perhaps simple meanness. I don't understand such people, I don't deal well with them, and I think they hurt our profession. No sense preaching, though, because they can surely sense that I have not been writing for them, and have left these pages long ago.

나머지 여러분들에게는, 일치성을 통해 달성할 수 있는 일, 또는 원하는 경우, 성격을 통해, 달성할 수 있는 일을 요약한 고대의 이야기가 있다. 욕심쟁이, 힘에 굶주린 사람, 비열한 사람과 같은 다른 사람과 한판 승부를 할 때마다 이 이야기를 떠올린다. 나는 그 영웅인 Hsün Chü-po의 의로움에 다다를 수 없다고 확신하지만, 그 이야기는 내 행동을 개선하려는 나의 시도가 궁극적으로는 변화를 가져올 것이라고 느끼게 한다. For the rest of you, there's an ancient story that sums up what I think you can accomplish through congruence, or, if you like, character. I think of this story whenever I'm a little down from a bout with one of those others—the greedy, the power hungry, or the mean-spirited. I'm sure I can't live up to the righteousness of its hero, Hsün Chü-po, yet it makes me feel that my attempts to improve my behavior will ultimately make a difference.

Hsün Chü-po Visits His Friend

Hsün Chü-po는 병에 걸린 그의 친구를 만나기 위해 먼 거리를 여행했다. 그 때 그 마을이 타타르족의 습격을 받았다. Hsün Chü-po traveled a great distance to see his friend, who was stricken ill. It happened that at this time the prefecture came under attack by the Tartars.

"죽음이 곧 나를 찾아올 거야" 그의 친구가 취포에게 말했다. "떠날 수 있을 때 떠나!" "Death will soon claim me," his friend said to Chü-po. "Please leave while you may!"

"나는 너를 만나기 위해 먼 길을 왔어." 취포가 말했다. "그리고 너는 내게 떠나라고? 훈취포가 의로움의 원칙을 저버리고 도망가는 것이 적절한 행동인가? 친구를 내버려두고?" "I've come a long way to see you," Chü-po replied, "and you ask me to leave? Is this proper conduct for Hsün Chü-po, to cast aside the principle of righteousness and run away, leaving his friend behind?"

그 때 타타르족이 와서 취포에게 말했다. "우리의 위대한 군대가 여기 도착했고, 사람들은 땅을 떠났다. 너는 도대체 뭐길래 여기에 남아있는가?" Then the Tartars came, and they said to Chü-po, "Our great armies are here and the people have fled the land. What manner of man are you that dare to linger?"

"내 친구가 아파서 누워있고, 나는 그를 남겨두고 간다는 것은 견딜 수 없소." 취포가 대답했다. "그의 생명을 남겨두고 내 것을 취하시오!" "My friend lies ill, and I cannot endure the thought of leaving him," Chü-po answered. "Spare his life and take mine in its stead!"

이것에 타타르족은 놀라워했다. "맞다. 우리는 의인의 땅에 온 죄악이다" 그래서 그들은 군대를 모아서 떠났고, 그 마을은 파괴에서 무사할 수 있었다. At this, the Tartars marveled. "Indeed, we are iniquitous men who have come to the land of the righteous." So they gathered their troops and departed, and the prefecture was saved from destruction.

당신도 역시, 변화를 만드는 한 사람이 될 수 있다. You, too, can be one person who makes a difference.