QSM: Volume 1.1: How Software is Built
Contents
Part 1. 품질의 패턴들 (Patterns of Quality)
Chapter 1: 품질이란 무엇인가? 그것이 왜 중요한가? (What Is Quality? Why Is It Important?)
Summary
[V] 품질은 상대적이다. 한 사람에게 좋은 품질은 다른 사람에게 낮은 품질일 수도 있다. Quality is relative. What is quality to one person may even be lack of quality to another.
[V] 상대성을 찾는 것은 "품질에 관한 그 진술의 뒤에 있는 그 사람이 누구냐"라고 물음으로써, 품질에 관한 진술 속에서 암묵적인 사람이나 사람들을 탐지하는 것을 포함한다. Finding the relativity involves detecting the implicit person or persons in the statement about quality, by asking, "Who is the person behind that statement about quality."
[V] 어떤 사람이나 사람들에게 있어서 품질은 가치보다 크거나 작지 않다. 이러한 관점은 우리가 이러한 문장들을 조화시킬 수 있도록 해준다: "결함을 0으로 하는 것이 고품질이다.", "기능이 많은 것이 고품질이다.", "우수한 코딩이 고품질이다.", "고성능이 고품질이다.", "적은 개발 비용이 고품질이다.", "쾌속 개발이 고품질이다.", "사용자 친화성이 고품질이다.". 모든 진술이 동시에 사실일 수 있다. Quality is neither more nor less than value to some person or persons. This view allows us to reconcile such statements as,"Zero defects is high quality." , "Lots of features is high quality." , "Elegant coding is high quality." , "High performance is high quality." , "Low development cost is high quality." , "Rapid development is high quality." , "User-friendliness is high quality." All of the statements can be true at the same time.
[V] 품질은 거의 항상 정치적/감정적인 문제이다. 비록 우리가 그것이 합리적으로 해결될 수 있는 것처럼 행동하기를 좋아한다고 해도. Quality is almost always a political/emotional issue, though we like to pretend it can be settled rationally.
[V] 품질은 오류로부터의 자유와 동일하지 않다. 공식적인 요구 조건에도 부합하지 않는 소프트웨어 제품이 어떤 사용자들에게는 높은 품질로 간주될 수도 있다. Quality is not identical with freedom from errors. A software product that does not even conform to its formal requirements could be considered of high quality by some of its users.
[V] 품질을 향상시키는 것은 매우 어렵다. 조직들은 일을 하는 특정한 패턴을 고수하는 경향이 있기 때문이다. 그들은 현재 수준의 품질에 적응하고, 새로운 수준으로 변화하는데 무엇이 필요한지 알지 못하며, 실제로 알아내려고 노력하지 않는다. Improving quality is so difficult because organizations tend to lock on to a specific pattern of doing things. They adapt to the present level of quality, they don't know what is needed to change to new level, and they don't really try to find out.
[V] 소프트웨어 조직에서 채택한 패턴은 몇 개의 클러스터, 하위문화에 속하는 경향이 있는데, 각각은 그 특징적인 결과를 낳는다. The patterns adopted by software organizations tend to fall into a few clusters, or subcultures, each of which produces characteristic results.
[V] 문화는 본질적으로 보수적이다. 이 보수주의는 기본적으로 다음과 같은 것들에 나타나 있다 Cultures are inherently conservative. This conservatism is manifested primarily in
특정 수준의 품질에 대한 만족도 the satisfaction with a particular level of quality
훨씬 더 잘하려고 하는 시도로 그 수준을 잃는 것에 대한 두려움 the fear of losing that level in an attempt to do even better
타문화들에 대한 이해의 부족 the lack of understanding of other cultures
그들 자신 문화의 불투명성 the invisibility of their own culture
V
Chapter 2. 소프트웨어 하위 문화들 (Software Subcultures)
Summary
[V] PhilipCrosby의 "품질은 공짜다" 아이디어는 아마도 몇 가지 손보면 소프트웨어에 적용될 수 있다. Philip Crosby's "Quality is Free" ideas can be applied to software, though perhaps with several modifications.
[V] 소프트웨어에서, 요구사항을 준수하는 것은 제조 작업에서처럼 요구사항이 확실할 수 없기 때문에 품질을 정의하기에 충분하지 않다. In software, conformance to requirements is not enough to define quality, because requirements cannot be as certain as in a manufacturing operation.
[V] 소프트웨어에 대한 우리의 경험에 따르면 "결함 0"은 대부분의 프로젝트에서 현실적이지 않다. 왜냐하면 마지막 몇 가지 결함에 대한 가치가 감소하기 때문이다. 더욱이, 다른 결점이 줄어들면 지배적이 되는 경향이 있는 요구사항 결점들이 있다. Our experience with software tells us that "zero defects" is not realistic in most projects, because there is diminishing value for the last few defects. Moreover, there are requirements defects that tend to dominate once the other defects are diminished.
[V] 크로스비의 주장과는 다르게, 소프트웨어에서는 "품질의 경제학"이 있다. 우리는 완벽을 추구하는 것이 아니라, 가치를 찾는 것이다, 가치로 정당화되지 않은 완벽에 대한 심리적 욕구가 없는 한. Contrary to Crosby's claim, there is an "economics of quality" for software. We are not searching for perfection, but for value, unless we have a psychological need for perfection not justified by value.
[V] 어떠한 소프트웨어 문화 패턴도 성공적일 수 있다. 올바른 고객이 주어진다면. Any software cultural pattern can be a success, given the right customer.
[V] "성숙도"는 하위문화 패턴에 대한 올바른 단어가 아니다. 추론될 수 없는 우월성을 내포하고 있기 때문이다. "Maturity" is not the right word for sub-cultural patterns, because it implies superiority where none can be inferred.
[V] 우리는 최소 6가지 소프트웨어 하위 문화 패턴을 확인할 수 있다: We can identify at least six software sub-cultural patterns:
패턴0: 무의식 Pattern 0: oblivious
패턴1: 가변적 Pattern 1: variable
패턴2: 루틴 (그러나 불안정) Pattern 2: routine (but unstable)
패턴3: 조정하는 Pattern 3: steering
패턴4: 예상하는 Pattern 4: anticipating
패턴5: 일치적인 Pattern 5: congruent
[V] 거의 모든 소프트웨어 조직이 다른 패턴에서 발견되기 때문에, 패턴 4,5에 대한 관찰은 거의 존재하지 않는다. Hardly any observations exist on Patterns 4 and 5, as almost all software organizations are found in other patterns.
[V] 이 책에서 우리는 주로 패턴 1~3을 살펴볼 것이다 - 어떻게 하면 만족스러운 패턴을 유지하거나 더 만족스러운 패턴으로 이동할 수 있는지 In this book, we shall be concerned primarily with Patterns 1-3—how to hold onto a satisfactory pattern or move to a more satisfactory one.
Chapter 3. 패턴을 변화시키기 위해서는 무엇이 필요한가? (What Is Needed To Change Patterns?)
Summary
[V] 각 패턴은 독특한 사고방식과 의사소통 방식을 가지고 있다. Each pattern has its characteristic way of thinking and communicating.
[V] 패턴을 바꾸는데 있어 가장 먼저 필수적인 것은 그 패턴의 특징적인 사고 패턴을 바꾸는 것이다. The first essential to changing a pattern is changing thought patterns that are characteristic of that pattern.
[V] 사고 패턴은 모델로 구성되며, 새로운 모델을 사용하여 사고 패턴을 바꿀 수 있다. Thinking patterns consist of models, and new models can be used to change thinking patterns
[V] 안정성이 떨어지는 패턴에서 모델은 정밀할 필요가 없고, 단지 설득력만 있으면 된다. 사실, 정확한 모델은 안정성을 먼저 확립하지 않으면 말이 안될 것이다. In the less stable patterns, models need not be precise, but merely convincing. Indeed, precise models wouldn't make any sense without first establishing stability.
[V] 모델은 우리에게 이러한 점을 도와준다: Models help us to:
사고의 차이를 발견한다. 그것이 큰 결과를 낳기 전에 discover differences in thinking, before they have big consequences
아이디어를 함께 연구한다. 팀 빌딩을 촉진하기 위해 work on ideas together, to facilitate team-building
다양한 프로젝트 프랙티스가 필요한 이유를 이해하는데 understand the reasons for various project practices
새로운 사람이 훨씬 빨리 생산적이 될 수 있도록 커뮤니케이션을 기록 record communication so newcomers can get productive much faster
다음번에 프로세스를 개선하는데 사용할 수 있는 기록을 유지 maintain a record we can use to improve our processes for the next time
창의적이 되기, 왜냐하면 프로젝트는 결코 루틴하지 않을 것이기 때문에 be creative, because projects will never be routine.
[V] 더 좋은 패턴을 고를 준비를 하기 전에, 항상 "현재 우리의 패턴은 충분히 좋은가?"라고 물어봐야 한다. Before you set about choosing a better pattern, you should always ask, "Is our present pattern good enough?"
[V] 당신이 선택하는 패턴은 조직적 요구, 고객 요구, 문제 요구 사이의 트레이드 오프에 달려 있다. 이러한 트레이드오프들은 "패턴 공간"에서 한 점을 선택함으로써 나타낼 수 있다. The pattern you choose depends on a tradeoff among organizational demands, customer demands, and problem demands. These tradeoffs can be represented by choosing a point in "pattern space."
[V] 소프트웨어 조직에게는, 새로운 패턴을 선택하지 않고 그 대신 고객의 요구나 문제 요구를 줄임으로써, 정체되려는 유혹이 항상 존재한다. There is always a temptation for a software organization to stagnate by not choosing a new pattern, but instead reducing customer demands or problem demands.
[V] 새로운 패턴이 필요하다고 인식하는 프로세스는, 필요로 하는 정보로부터 조직을 폐쇄하는 순환적 논쟁에 의해 방해된다. The process of recognizing that a new pattern is needed is hindered by circular arguments that close the organization to the information it needs.
[V] 폐쇄적인 서클들을 여는 열쇠는 이 질문이다, "당신의 성공률은 괜찮은가?". 그러나, 폐쇄적인 서클은, 이 질문을 하지 못하게 하는 경향이 있다. The key to opening closed circles is the question, "Is your rate of success okay?" Closed circles, however, tend to prevent this question from being asked.
[V] 신뢰의 부족은 이 핵심 질문에 진실하게 대답하지 못하게 하는 경향이 있으므로, 조직의 변화는 종종 신뢰를 발전시키기 위한 행동들로부터 시작된다. Lack of trust tends to keep this key question from being answered truthfully, so organizational change often begins with actions for developing trust.
Part II. 관리의 패턴들 (Patterns Of Managing)
Chapter 4: 관리를 위한 제어 패턴들 (Control Patterns for Management)
Summary
[V] Aggregate Control Model(제어 총합 모델)은, 중복되는 해법들에 충분한 비용을 지출할 의향이 있다면, 결국 원하는 시스템을 얻게 될 것이라고 알려준다. 때로 이것이 가장 실용적인 방법이거나 우리가 생각할 수 있는 유일한 방법이다. The Aggregate Control Model tells us that if we're willing to spend enough on redundant solutions, we'll eventually get the system we want. Sometimes this is the most practical way, or the only way we can think of.
[V] 피드백 제어 모델(Feedback Control Model)은 우리가 원하는 것을 얻는 보다 효율적인 방법을 시도한다. 컨트롤러는 시스템이 현재 무엇을 하고 있는지에 대한 정보를 기반으로 시스템을 제어한다. 이 정보와 시스템을 위해 계획된 정보를 서로 비교하여, 컨트롤러는 시스템의 동작을 계획에 보다 더 가깝게 하기 위해 설계된 행동을 한다. The Feedback Control Model tries for a more efficient way of getting what we want. A controller controls a system based on information about what the system is currently doing. Comparing this information with what is planned for the system, the controller takes actions designed to bring the system's behavior closer to plan.
[V] 엔지니어링 관리(Engineering Management)의 업무는 엔지니어링 프로젝트에서 컨트롤러 역할을 하는 것이다. 엔지니어링 관리의 실패는 피드백 제어 모델 측면(Feedback Control Model)에서 이해할 수 있다. 패턴2 관리자는 종종 이러한 이해가 부족하며, 이는 종종 왜 그들이 그렇게 많은 낮은 품질의 프로젝트나 실패한 프로젝트를 경험하는지 설명해준다. The job of Engineering Management is to act as controller in engineering projects. Failures of engineering management can be understood in terms of the Feedback Control Model. Pattern 2 managers often lack this understanding, which often explains why they experience so many low quality, or failed, projects.
[V] 무슨 일이 일어나야 할지에 대한 계획이 없으면 프로젝트가 실패할 수 있다. Projects can fail when there is no plan for what should happen.
[V] 컨트롤러가 어떤 중요한 일이 실제로 일어나고 있는지 관찰하는데 실패하면 프로젝트가 실패할 수 있다. Projects can fail when the controller fails to observe what significant things are really happening.
[V] 컨트롤러가 관찰된 것과 계획된 것을 비교하는데 실패하면 프로젝트가 실패할 수 있다. Projects can fail when the controller fails to compare the observed with the planned.
[V] 컨트롤러가 실제 계획에 근접하기 위한 조치를 취할 수 없거나 하지 않으면 프로젝트가 실패할 수 있다. Projects can fail when the controller cannot or will not take action to bring actual closer to planned.
Chapter 5 명시적인 관리 모델들 만들기 (Making Explicit Management Models)
Summary
[V] 모든 관리자와 프로그래머는 그들의 소프트웨어 패턴에서 사물들이 어떻게 작용하는지에 대한 모델들을 가지고 있다. 비록 많은 모델이 명시적으로 언급되기보다는 그들의 행동에 내포되어 있지만 말이다. 사람들이 현실을 직시하지 못하고 잘못된 시스템 모델들을 사용하기 때문에 소프트웨어 프로젝트들에서 일이 꼬이곤 한다. Every manager and programmer has models of how things work in their software pattern, though many models are implicit in their behavior, rather than stated explicitly. Things go awry in software projects because people are unable to face reality and because they use incorrect system models.
[V] 선형 모델(Linear model)들은 가산성1 때문에 매력적이다. 선형 시스템들 모델링하기 쉽고, 예측하기 쉽고, 제어하기 쉽다. 관리자들은 보통 선형 모델이 매우 매력적이기 때문에 규모의 오류2를 범한다. Linear models are attractive because of additivity. Linear systems are easier to model, easier to predict, and easier to control. Managers often commit scaling fallacies because linear models are so attractive.
[V] 효과 다이어그램은 모델 시스템 역동이 비선형성을 드러내도록 돕는 도구다. 2차원 그림인 만큼, 그것은 비선형 시스템을 설명하는 데에 말로 된 설명보다 더 적합하다. The diagram of effects is a tool for helping model system dynamics to reveal non-linearities. Being a two-dimensional picture, it is more suited than verbal descriptions to the job of describing non-linear systems.
[V] 효과 다이어그램을 그리는 한 가지 방법은 출력, 즉 통제하고자 하는 행동을 하는 변수부터 시작하는 것이다. 그런 다음, 그 변수에 역으로 영향을 미칠 수 있는 다른 변수들을 브레인스토밍하고 차트화하라. 이것들로부터, 이 차트를 한 번 더 거슬러가면서, 2차 효과들을 밝혀내라. 그것들을 사용해 원초 효과들로부터 관심 변수까지 추적할 수 있다. 중요한 것들은 승수 효과를 명시적으로 표시할 수도 있다. One way of developing a diagram of effects is to start with the output—the variable whose behavior you wish to control. You then brainstorm and chart backwards effects from that variable—other variables that could affect it. From these, you chart backwards again, unveiling secondary effects, which you can trace through the primary effects to the variable of interest. You may want to explicitly indicate multiplicative effects because of their importance.
[V] 비선형성이 일이 꼬이는 이유이다. 그래서 비선형성을 찾는 것이 시스템 모델링의 주요 작업이다. Non-linearity is the reason things go awry, so searching for non-linearity is a major task of system modeling.
Chapter 6: 피드백 효과 (Feedback Effects)
Summary
[V] 험프티 덤프티 신드롬은 프로젝트 매니저들이 그들의 매니저에게 예의바르게 고집을 부릴 수 없는 한 가지 이유와, 그 결과로 어떤 일들이 일어나지를 설명한다. The Humpty Dumpty Syndrome explains one reason why project managers are unable to be courteously stubborn to their managers, and what happens as a result.
[V] 프로젝트는 탈주한다 - 폭발하거나 붕괴한다 - 관리자들이 다음과 같은 두 가지 오류를 믿기 때문이다: 가역성 오류 (액션들은 항상 되돌릴 수 있다)와 인과 오류 (모든 원인이 하나의 효과를 가지고, 어떤 것이 원인이고 어떤 것이 효과인지 알 수 있다는 것.)가 그것이다. Projects run away—explode or collapse—because managers believe two fallacies: The Reversible Fallacy (that actions can always be undone) and The Causation Fallacy (that every cause has one effect, and you can tell which is cause and which is effect.)
[V] 브룩스의 법칙의 효과는 관리 행동에 의해 더욱 악화될 수 있다. 더욱이, 같은 형태의 관리 행위가 일반화된 브룩스의 법칙(Generalized Brooks's Law)으로 이어질 수 있는데, 이는 관리 행위가 어떻게 종종 프로젝트 붕괴의 주요 원인이 되는지 보여준다. The effect of Brooks's Law can be made worse by management action. Moreover, the same pattern of management action can lead to a Generalized Brooks's Law, which shows how management action is often the leading cause of project collapse.
- [V] 관리 행동이 탈주에 기여하는 한 가지 이유는 일탈에 너무 늦게 대응하는 경향이다. 이는 관리를 그 자체가 비선형적 결과를 가지는 커다란 액션들로 내몬다. 그래서 "일찍 행동하라; 작게 행동하라"가 필요한 것이다. One reason management action contributes to runaway is the tendency to respond too late to deviations, which then forces management to big actions which themselves have non-linear consequences. That's why it's necessary to "act early; act small."
[V] 네거티브 피드백은 시스템에서 포지티브 피드백 루프로 인한 탈주를 방지할 수 있는 속도와 힘을 가진 유일한 메커니즘이다. 패턴3 컨트롤러에는 두 가지 주요한 네거티브 피드백 루프가 있는데, 하나는 자원들을 포함하고 다른 하나는 요구사항들을 포함한다. Negative feedback is the only mechanism that has the speed and power to prevent runaway due to positive feedback loops in a system. The Pattern 3 controller has two major negative feedback loops with which to exercise control—one involving resources and one involving requirements.
Chapter 7: 소프트웨어 조정하기 (Steering Software)
Summary
[V] 다른 여러 좋고 이상적인 방법론들은 붕괴를 방지하는데 도움이 되지 못하는데, 그것들은 프로젝트가 이상적인 모델에서 벗어날 때 취해야 할 부정적인 피드백 행동들을 규정하지 않기 때문이다. Many otherwise good ideal methodologies fail to help prevent collapse because they don't prescribe negative feedback actions to be taken when the project deviates from the ideal model.
[V] 방법론이 피드백을 규정할 때, 그들은 종종 제품 레벨, 또는 너무 큰 피드백 단계들에 대해서만 말한다. 통제에 효과적이 되려면, 피드백은 모든 레벨, 즉 개인, 제품, 프로세스 및 문화적 수준에서 작은 증분으로3 작동해야 한다. When the methodologies do prescribe feedback, they often speak only of the product level, or feedback steps that are too large. To be effective for control, feedback must operate in small increments, at all levels, personal, product, process, and cultural.
- [V] 소프트웨어 전문가는 종종 효과 모델에서 인간의 의사결정 지점을 간과한다. 한 가지 이유는 상태를 시각화할 수 있는 능력이 전혀 없기 때문이며, 종종 그것들은 프로세스의 "기타 출력물"이지, 제품과 직접 연결되지는 않기 때문이다.
Software professionals often overlook the human decision point in models of effects. One reason is their inability to visualize certain states at all, often because they are "other outputs" of the process, and not directly connected with the product.
[V] 프로젝트를 성공적으로 제어하기 위해서는, 역동의 피해자가 될 필요가 없다는 것을 배워야 한다. 인간의 의사결정 요소가 관련되었을 때, 중요한 것은 사건이 아니라 그 사건에 대한 당신의 반응이다. To control a project successfully, you have to learn that you need not be a victim of the dynamics. When human decision points are involved, it's not the event that counts, it's your reaction to the event.
Chapter 8: 조정에 실패하기 (Failing to Steer)
Summary
[V] 많은 프로젝트 매니저들은 자신들이, 프로젝트의 운명을 통제할 수 없는, 피해자라고 믿기 때문에 잘 조정하지 못한다. 그러한 매니저들은 "피해자 언어"를 사용하기 때문에 쉽게 구분할 수 있다. Many project managers fail to steer well because they believe they are victims, with no control over the destiny of their project. You can easily identify these managers by their use of "victim language."
[V] 관리자가 관리적인 통제가 어디에 있는지 인식하고, 이 통제권이 다른 형태를 취할 수 있다면, 브룩스의 법칙(Brooks's Law)은 피해자의 법칙이 될 필요가 없다. Brooks's Law doesn't have to be a victim law if the manager recognizes where the managerial control is, and that this control can take different forms.
[V] 일반적인 역동에서는, 프로젝트 진행에 대해 정확하지만 나쁜 소식을 전하는 메신저를 처벌하곤 한다. 이러한 개입은 "부정적인 대화"는 피하지만, 반면에 매니저가 프로젝트가 정상적으로 진행되게 하는 효과적인 개입을 할 가능성을 약화시킨다. A common dynamic is punishing the messenger who brings accurate but bad news about project progress. This intervention avoids "negative talk," but also diminishes the chance of the manager's making effective interventions needed to keep a project on the road.
[V] 그리스 시대부터, 사람들은 개입을 잘못해왔을 뿐 아니라, 반대로 개입해왔다. 효과 다이어그램을 명확하게 짜는 것은 두 당사자가 서로에게 돌진하며 파멸로 몰고 가는 상황을 정리하는 데 도움이 될 수 있고, 동시에 스스로가 상황을 나아지게 하고 있다고 생각할 수도 있다. Since the time of the Greeks, people have not only gotten their interventions wrong, they've gotten them backwards. Laying out a clear diagram of effects can help you sort out a situation in which two parties are driving each other to destruction, all the while thinking they are helping the situation.
Part III. Demands That Stress Patterns
Chapter 9: 왜 조정하는 것은 항상 어려운가 (Why It's Always Hard to Steer)
Summary
[V] 인간 개입 역동은 우리가 잠재적으로 통제할 수 있는 것이지만, 컨트롤러가 얼마나 훌륭하게 일을 할 수 있는지를 제한하는 일련의 "자연적인" 역학이 항상 존재한다. 컨트롤러의 업무 중 큰 부분은 그 자연적인 역동을 가능한 한 최상의 제어 하에 유지할 수 있는 개입 역동을 고안하는 것인데, 이것은 결코 완벽할 수 없다. Human intervention dynamics are those over which we potentially have control, but there is always a set of "natural" dynamics which put a limit on how good a job any controller can do. A large part of the controller's job is devising intervention dynamics that can keep the natural dynamics under the best control possible, which can never be perfect.
[V] 계산의 제곱 법칙(The Square Law of Computation)에 따르면 계산의 복잡성은 계산할 요소의 수가 증가함에 따라 비선형적으로 증가한다. The Square Law of Computation says that computational complexity grows non-linearly as the number of factors in the computation grows.
[V] 제어는 컨트롤러들이 "자연"을 상대로 하는 게임이라고 생각할 수 있다. 틱택토, 체스 같은 '완벽한 정보'의 게임조차도, 완벽하게 플레이하기 위해서는 '보드'의 크기가 커질수록 두뇌 파워가 비선형으로 증가해야 한다. Control can be thought of as a game that the controller plays against "Nature." Even games of "perfect information," such as Tic-Tac-Toe and Chess, require non-linear increases in brainpower to play perfectly as the size of the "board" increases.
[V] 단순화가 항상 필요하다. 컨트롤러들은 언제나 그들의 정신 용량4을 넘어서는 "게임"을 잘 플레이하고 있기 때문이다. 단순화는 러프한 동적 모델과 대략적(approximate)인 규칙 - "항상 프로젝트를 모듈로 분해하라"와 같은 - 의 형태를 취한다. Simplification is always needed, because controllers are always playing a "game" well outside their mental capacity. Simplification takes the form of rough dynamic models and approximate rules such as "Always break a project down into modules."
[V] 소프트웨어 엔지니어링 관리는 체스보다 어렵다. 프로젝트를 제어하는 것은 "불완전 정보"의 게임이고, "보드"의 크기도 고정되어 있지 않기 때문이다. Software engineering management is harder than Chess, because controlling a project is a game of "imperfect information," and the size of the "board" is not fixed.
[V] 규모/복잡성 역동(Size/Complexity Dynamic)은 소프트웨어 엔지니어링 전반에 걸쳐 결함 위치 역동(Fault Location Dynamic) 및 그룹 상호 작용 역동(Group Interaction Dynamic)과 같은 여러 형태로 나타난다. The Size/Complexity Dynamic appears in many forms throughout software engineering, forms such as the Fault Location Dynamic and the Group Interaction Dynamic.
Chapter 10: What It Takes To Be Helpful
Summary
[V] 우리의 뇌는 결코 우리의 야망에 비해서 충분히 크지 않을 것이기 때문에, 우리는 항상 사고 도구가 필요할 것이다. 이를테면 규모/노력 그래프와 같은. Our brains will never be big enough for our ambitions, so we'll always need thinking tools, such as size/effort graphs.
[V] 규모/노력 그래프는 규모/복잡성 역동에 대해 추론하는데 사용될 수 있다. 이를테면 프로젝트를 추정하거나 두 가지 다른 기술의 영향을 비교할 때처럼 말이다. 그러나 그래프는, 로그-로그 그래프와 같은, 역동의 비선형적 성질을 왜곡하거나 숨길 수도 있다. 우리는 데이터와 표현 방법의 변형을 통해 안정된 의미를 보는 것을 반드시 배워야 한다. Size/effort graphs can be used to reason about the Size/Complexity Dynamic, such as when estimating a project or comparing the impact of two different technologies. Graphs, however—such as log-log graphs—can also distort or conceal the non-linear nature of the dynamic. We must learn to see the stable meaning through the variations in the data and the method of presentation.
[V] 규모/복잡성 역동 때문에, 가장 유능한 프로그래머조차도 충족시킬 수 없는 요구 사항을 작성하는 것은 쉬운 일이다. Because of the Size/Complexity Dynamic, it's easy to write requirements that the most competent programmers cannot satisfy.
[V] 어느 하나의 방법이나 도구가 문제 규모의 전체 범위에서 최고인 경우는 드물다. 규모/노력 그래프는 관리자가 두 가지 방법을 결합하여 복합 패턴으로 만들어 각 방법에 대해 가장 적합한 범위를 채택하는데 도움이 될 수 있다. A single method or tool is seldom the best over the entire range of problem sizes. Size/effort graphs can help managers combine two methods into a composite pattern that adopts the best range for each one.
[V] "최저선"이 모든 기술 선택을 좌우하는 것은 아니다. 관리자들은 종종 실패의 위험을 줄이기 위해 최저선에 많은 돈을 지불하려고 한다. 크기/위험 그래프는, 특히 크기/눈금 그래프와 함께 사용할 때, 이러한 선택에 대해 추론하는 데 도움이 될 수 있다. "The bottom line" doesn't dictate all technology choices. Managers are often willing to pay a lot on the bottom line to reduce the risk of failure. The size/risk graph can help in reasoning about these choices, especially when used in conjunction with the size/effort graph.
[V] 만약 당신이 조직을 바꾸려고 한다면, 첫 번째 규칙은, 히포크라테스가 의사들에게 주는, "해치지 말라"가 되어야 한다. If you set out to change an organization, the first rule should be the one given to physicians by Hippocrates" "Do no harm."
[V] 우리는 모두 크기/복잡성 역동(Size/Complexity Dynamic)의 영향을 받기 때문에, 도움이 되려고 의도된 상호작용은 종종 관련성이 없거나, 실제론 파괴적으로 끝나기도 한다. 어떻게 보이건, 어떻게 들리건, 모두가 도움이 되려고 노력하고 있다고 가정하는 것은 좋은 생각이다. We are all subject to the Size/Complexity Dynamic, so interactions intended to be helpful often wind up being irrelevant, or actually destructive. It's a good idea to assume that regardless of how it looks or sounds, everyone is trying to be helpful.
[V] 우리는 <추가의 원리>를 적용하여 사람의 레퍼토리에 더욱 효과적인 모델을 추가할 때 가장 많은 도움을 줄 수 있다. We can help most when we apply the The Principle of Addition to add more effective models to a person's repertoire.
Chapter 11: 고객 요청에 대한 응답들 (Responses to Customer Demands)
Summary
[V] 고객과의 관계는 조직들을 특정 소프트웨어 문화 패턴으로 이끄는 두 번째 중요한 요인이다. The relationship with customers is the second important factor driving organizations to particular software cultural patterns.
[V] 단순히 고객의 수를 늘리는 것은 다음과 같이 조직에 엄청난 변화로 피해를 입힐 수 있다: Simply increasing the number of customers can wreak vast changes on an organization, such as
개발 부하 증가 increasing the development load
유지보수 부하 증가 increasing the maintenance load
개발 작업의 패턴 방해 disrupting the pattern of development work
[V] 다른 한편으로, 소프트웨어 개발 조직은 고객들에게 심각하게 파괴적이 될 수 있다. 이것이 고객이 소프트웨어 개발 조직의 컨트롤러가 되려고 노력하는 이유이며, 여러 컨트롤러들이 존재하는 상황으로 이끈다. 컨트롤러 수가 많을수록, 다른 컨트롤러에 "무작위성"이 더 많이 나타난다. On the other hand, a software development organization can be extremely disruptive to its customers. That's why customers try to be controllers of the software development organization, leading to a situation of multiple controllers. The more controllers, the more "randomness" there appears to the other controllers.
[V] 소프트웨어 개발에 영향을 미칠 수 있는 외부인의 배역은 어마어마하다. 다음과 같은 역할을 포함하여: The cast of outsiders who may influence software development is enormous, including such roles as
고객 및 사용자 customers and users
마케팅 부서 the marketing department
다른 대리인들 other surrogates
프로그래머들, 스스로 사용자 대리인으로 임명한 programmers as self-appointed user surrogates
테스터, 공식 및 비공식 대리인으로서 testers as official and unofficial surrogates
기타 계획되지 않은 대리인들 other unplanned surrogates
[V] 이러한 아웃사이더 역할의 상당수는 유효한 고객의 수를 줄이기 위한 시도로 계획되어 있다. Many of these outsider roles are planned as attempts to reduce the effective number of customers.
[V] 일부 대리인은 개발 시스템과 훨씬 더 친밀하기 때문에, 그들의 상호 작용의 힘과 빈도를 사용하여 그들의 유효 고객 수의 감소를 부정할 수 있다. Because some of the surrogates are much more intimate with the development system, they may negate their reduction of the effective number of customers with the force and frequency of their interactions.
[V] 고객과의 상호작용은 고객의 수가 증가함에 따라 위험 투성이다. 인터럽트들이 증가한다. 회의의 규모와 빈도가 증가한다. 인터럽트된 회의들로 인한 시간 손실이 증가한다. 이 모든 증가는 비선형이다. Interactions with customers are fraught with peril as the number of customers grows. Interruptions increase. Meetings increase in size and frequency. Time lost because of interrupted meetings increases. All of these increases are non-linear.
[V] 더 많은 고객이 오면, 지원해야 할 구성들이 더 많아진다. 구성들이 많아진다는 것은, 추가적인 코딩, 더 복잡한 테스트, 덜 효과적인 테스트 적용 범위, 더 긴 수리 시간을 의미한다. With more customers comes more configurations to support. More configurations means additional coding, more complex testing, less effective test coverage, and longer repair times.
[V] 고객이 여러 명일 때마다 출시들이 필요하다. 고객에게 제품이 출시되자마자, 개발 조직의 그늘에 있을 때와는 전혀 다른 역동을 가정한다. Releases are needed whenever there are multiple customers. As soon as a product is released to customers, it assumes an entirely different dynamic than when it was held in the shadow of the development organization.
[V] 소프트웨어 제품의 여러 버전들은 유지보수를 엄청나게 복잡하게 하지만, 공식적이든 비공식적이든, 더 많은 고객은 더 많은 버전을 의미한다. 빈번한 릴리즈는 개발/유지보수 과정을 복잡하게 만들지만, 빈번하지 않은 릴리스도 그러하다. 그래서 거의 모든 소프트웨어 문화는 매년 2회 정도로 릴리즈를 안정시키는 경향이 있다. Multiple versions of a software product complicate maintenance enormously, but more customers means more versions, whether official or unofficial. Frequent releases complicate the development/maintenance process, but so do infrequent releases, so that almost all software cultures tend to stabilize releases at around two per year.
QSM: Volume 1.2: Why Software Gets In Trouble
Contents
Part IV. Fault Patterns
Chapter 1: Observing and Reasoning About Errors
Summary
[V] 조직이 소프트웨어 오류를 처리하는 데 어려움을 겪는 이유 중 하나는 오류와 관련하여 발생하는 많은 개념적 오류 때문이다. One of the reasons organizations have trouble dealing with software errors is the many conceptual errors they make concerning errors.
[V] 어떤 사람들은 오류를 도덕적인 문제로 만들고, 그것들이 처리되는 방식으로 인해 사업적 정당성을 잃어버린다. Some people make errors into a moral issue, losing track of the business justification for the way in which they are handled.
[V] 품질은 오류의 부재가 아니지만, 많은 오류의 존재는 제품의 품질의 다른 척도를 파괴할 수 있다. Quality is not the same thing as absence of errors, but the presence of many errors can destroy any other measures of quality in a product.
[V] 오류를 잘 처리하지 못하는 조직은 오류에 대해서도 명확하게 말하지 않는다. 예를 들어, 그들은 종종 결함(faults)과 실패(failures)를 구분하지 못하거나, 결함(faults)을 이용하여 조직 내의 사람들을 비난한다. Organizations that don't handle error very well also don't talk very clearly about error. For instance, they frequently fail to distinguish faults from failures, or use faults to blame people in the organization.
[V] 잘 기능하는 조직은, 그들이 결함과 실패를 자신의 프로세스를 제어하기 위한 정보로 사용하는 조직된 방법을 보면 알아볼 수 있다. 시스템 고장 사고(STI: System Trouble Incident)와 시스템 결함 분석(SFA: System Fault Analysis)은 실패(failures)와 결함(faults)에 대한 정보의 근본적인 소스이다. Well functioning organizations can be recognized by the organized way they use faults and failures as information to control their process. The System Trouble Incident (STI) and the System Fault Analysis(SFA) are the fundamental sources of information about failures and faults.
[V] 오류-처리 프로세스는 최소한 다섯 종류로 구분된다: 탐지(detection), 문제 지점 찾기(location), 해결(resolution), 예방(prevention), 배포(distribution). Error-handling processes come in at least five varieties: detection, location, resolution, prevention, and distribution.
[V] 개념적 오류 외에도, 사람들이 오류에 대해 저지르는 여러 가지 일반적인 관찰 오류가 있다. 선택 오류(Selection Fallacies), 관찰을 거꾸로(backwards) 하는 오류, 컨트롤러 오류(Controller Fallacy) 등. In addition to conceptual errors, there are a number of common observational errors people make about errors, including Selection Fallacies, getting observations backwards, and the Controller Fallacy
Chapter 2: The Failure Detection Curve
Summary
[V] 실패 탐지는 탐지하기 가장 쉬운 실패가 가장 먼저 검출되는 실패라는 동어 반복에 의해 지배되었기 때문에, 탐지가 진행될수록, 작업이 더 어려워지고, 꼬리가 긴(long tail) 특징적인 실패 탐지 곡선(Failure Detection Curve)을 만들어 낸다. Failure detection is dominated by the tautology that the easiest failures to detect are the first failures to detect, so that as detection proceeds, the work gets harder, producing a characteristic Failure Detection Curve with a long tail.
[V] 실패 탐지 곡선의 긴 꼬리(long tail)는 관리자가 실패 탐지 작업을 잘못 추정하는 주요 원인 중 하나이다. The long tail of the Failure Detection Curve is one of the principal reasons managers misestimate failure detection tasks.
[V] 실패 탐지 곡선은 자연적인 역동을 나타내기 때문에, 그것이 말하는 것보다 더 좋은 성과를 내기 위해 우리가 할 수 있는 일은 없다. 그러나, 우리는 더 나쁜 성과를 낼 수도 있다. 만약 우리가 어떻게 실패 감지 프로세스를 관리하는지에 주의하지 않으면 말이다. Because the Failure Detection Curve represents a natural dynamic, there is nothing we can do to perform better than it says. We can, however, perform much worse, if we're not careful of how we manage the failure detection process.
[V] 실패 탐지 곡선이 모두 나쁜 소식은 아니다. 시간에 흐름에 따라 검출된 고장의 패턴은 특정 수준의 실패 탐지에 도달하는 시간을 예측하는 데 사용할 수 있다. 테스트 커버리지를 저해하는 일이 발생하지 않는 한. The Failure Detection Curve is not all bad news. The pattern of detected failures over time can be used as a predictor of the time to reach any specified level of failure detection, as long as nothing is happening to undermine test coverage.
[V] 테스트 커버리지를 저해할 수 있는 것 중 일부는, 결함을 차단하기, 결함을 마스킹하기, 테스트하기에는 늦은 릴리즈 등이다. Some of the things that can undermine test coverage are blocking faults, masking faults, and late releases to test.
[V] 늦게 완성되는 모듈들은 부실한 코딩의 사이클에서 발생할 수 있는데, 이는 고장 가능성이 높은 모듈일 가능성이 더 높다는 것을 의미한다. 늦게 완료되는 모듈의 테스트 속도를 높이기 위해 고안된 관리 정책은 실제로는 문제를 더 악화시킬 수 있으며, 소위 "불운(bad luck)" 추정의 이유를 설명할 수 있다. Late finishing modules may arise from a cycle of poor coding, which means that they are more likely to be fault-prone modules. Management policies designed to speed testing of late finishing modules may actually make the problem worse, and may account for much so-called "bad luck" estimating.
Chapter 3: Locating The Faults Behind The Failures
Summary
[V] 시스템 크기는 결함 위치의 역동에 직접적인 영향을 미치지만, 간접적인 영향도 있다. 우리는 크기/복잡성 역동을 이기기 위해 분할과 정복(device and conquer)을 사용하며, 배달 시간을 맞추기 위해 노동력을 나누기도 한다. 그러나, 이러한 노력은 시스템 크기가 결함 발견에 걸리는 시간에 미치는 여러 가지 간접적인 영향을 일으킨다. System size has a direct effect on the dynamics of fault location, but there are indirect effects as well. We use divide and conquer to beat the Size/Complexity Dynamic, and we also divide the labor to beat delivery time. These efforts, however, lead to a number of indirect effects of system size on fault location time.
[V] 어느 조직이 자신의 STI들을 어떻게 처리하는지를 관찰하면 그 조직의 문화에 대해 많은 것을 파악할 수 있다. 특히, 당신은 그 조직의 문화적 패턴이 증가하는 고객이나 문제 수요에 대해 어느 정도로 스트레스를 받고 있는지 파악할 수 있다. You can learn a great deal about its culture by observing how an organization handles its STIs. In particular, you can learn to what degree its cultural pattern is under stress of increased customer or problem demands.
[V] 중요한 역동은 STI의 순환을 묘사하는데, 더 많은 STI들이 순환에 있을수록 비선형적으로 증가한다. An important dynamic describes the circulation of STIs, which grows non-linearly the more STIs are in circulation.
[V] STI를 잃는 것과 같은 프로세스 오류도 결함 지점을 찾는 시간을 증가시킨다. Process errors such as losing STIs also increase location time.
[V] 정치적 문제도, 지위의 경계와 같은, 결함 지점을 찾는 시간의 연장에 비선형적으로 기여할 수 있다. STI 보유자를 처벌해 순환 시간을 줄이려는 관리 행위가 오히려 역효과를 낳을 수 있다. Political issues, such as status boundaries, can also contribute non-linearly to extending location time. Management action to reduce circulation time by punishing those who hold STIs can lead to the opposite effect.
[V] 일반적으로, STI를 허술하게 취급하면 관리 부담이 증대되고, 결국에는 STI의 허술한 취급으로 이어진다. STI가 통제 불능이 되면, 경영진은 그들의 문화 패턴에 대해 어떤 정보를 주고 있는지 연구한 뒤, 단순한 증상이 아니라 근본 원인(root cause)을 파악하는 조치를 취해야 한다. In general, poorly controlled handling of STIs leads to an enlarged administrative burden, which in turn leads to less poorly controlled handling of STIs. When STIs get out of hand, management needs to study what information that gives them about their cultural pattern, then take action to get at the root causes, not merely the symptoms.
Chapter 4: Fault Resolution Dynamics
Summary
기본 결함 해소 역학은 크기/복잡성 역학의 또 다른 사례로, 결함이 많아질수록, 또한 결함당 복잡성이 클수록, 시스템이 커질수록 고장의 해결 시간이 비선형적으로 증가한다. Basic fault resolution dynamics are another case of Size/Complexity Dynamics, with more faults and more complexity per fault leading to a non-linear increase in fault resolution time as systems grow larger.
부작용은 고장해결에 비선형성을 더한다. 부작용을 고려하는 데 더 많은 시간이 걸리거나, 한 가지를 바꾸고 무심코 다른 것을 바꿀 때 부작용을 일으키기도 한다. Side effects add more non-linearity to fault resolution. Either we take more time to consider side effects, or we create side effects when we change one thing and inadvertently change another.
가장 분명한 부작용의 유형은 고장 피드백이며, 고장 피드백은 고장 피드백 비율(FFR)으로 측정할 수 있다. 결함 피드백은 다른 결함을 해결하는 동안 결함을 생성하는 것이다. 고장은 기능적 또는 성능적 결함일 수 있다. The most obvious type of side effect is fault feedback, which can be measured by the Fault Feedback Ration (FFR). Fault feedback is the creation of faults while resolving other faults. Faults can be either functional or performance faults.
FFR은 프로젝트 제어 붕괴에 대한 민감한 척도다. 잘 통제된 프로젝트에서 FFR은 프로젝트가 예정된 종료에 가까워질수록 감소해야 한다. The FFR is a sensitive measure of project control breakdown. In a well-controlled project, FFR should decline as the project approaches its scheduled end.
FFR을 제어하는 한 가지 방법은 고장 해결 방법이 "단 한 줄의 코드"라 하더라도 신중한 검토를 실시하는 것이다. 작은 변화가 문제를 일으킬 수 없다는 가정은 작은 변화로 이어져 큰 변화보다 더 큰 문제를 일으킨다. One way to keep the FFR under control is to institute careful reviewing of fault resolutions, even if they are "only one line of code." The assumption that small changes can't cause trouble leads to small changes causing more trouble than bigger changes.
결함 및 성능 비효율의 추가 외에도 시스템이 악화되는 여러 가지 방법이 있으며, 이러한 방법은 일반적인 프로젝트 측정에 나타나지 않는다. 예를 들어, 설계 무결성이 파괴되고, 문서가 최신 상태로 유지되지 않으며, 코딩 스타일이 복잡해진다. 이 모든 것이 시스템의 유지 보수성의 저하로 이어진다. There are a number of ways in which a system deteriorates besides the addition of faults and performance inefficiencies, and these ways do not show up in ordinary project measurements. For instance, design integrity breaks down, documentation is not kept current, and coding style becomes patchy. All of these lead to a decrease in the system's maintainability.
모듈형, 즉 "블랙박스"의 무결성이 깨졌을 때, 시스템은 각각의 변화로부터 증가하는 "리플 효과"를 보여준다. 즉, 한 가지 변화가 많은 다른 변화를 일으키기 위해 파급되는 것이다. When the integrity of a modular, or "black box," design breaks down, the system shows a growing "ripple effect" from each change. That is, one change ripples through to cause many other changes.
시스템의 악화를 피하려면, 시스템뿐만 아니라 유지관리성 또한 유지되어야 한다. If we are to avoid deterioration of systems, they must not only be maintained, but their maintainability must also be maintained.
관리자와 개발자는 정비 난관에 대한 보호로서 초기 설계에 대한 과신력을 보이는 경우가 많다. 이런 종류의 과신감은 쉽게 타이타닉 효과로 이어질 수 있는데, 왜냐하면 코드에 문제가 있을 수 없다는 생각은 코드를 모든 종류의 잘못된 방법에 노출시키기 때문이다. Managers and developers often show overconfidence in the initial design as protection against maintenance difficulties. This kind of overconfidence can easily lead to a Titanic Effect, because the thought that nothing can go wrong with the code exposes the code to all sorts of ways of going wrong.
Part V. Pressure Patterns
Chapter 5: Power, Pressure, and Performance
Summary
압력/성능 관계에 따르면 압력이 가해질 경우 잠시 성능을 끌어올린 다음 반응이 없어지기 시작하다가 붕괴로 이어질 수 있다고 한다. The Pressure/Performance Relationship says that added pressure can boost performance for a while, then starts to get no response, then leads to collapse.
마지막 결함을 찾도록 압력을 가하면 마지막 결함을 찾는 시간이 쉽게, 어쩌면 무한정 길어질 수 있다. Pressure to find the last fault can easily prolong the time to find the last fault, perhaps indefinitely.
스트레스/컨트롤 다이나믹은 우리가 외부 압력에 반응할 뿐만 아니라, 우리가 통제력을 상실하고 있다고 생각할 때 자신에게 가하는 내부 압력에 반응한다고 설명한다. 이 동적 특성은 압력/성능 관계를 더욱 비선형적으로 만든다. The Stress/Control Dynamic explains that we not only respond to the external pressures, but to internal pressures we place on ourselves when we think we are losing control. This dynamic makes the Pressure/Performance Relationship even more non-linear.
압력에 의한 고장은 여러 가지 형태로 나타난다. 특히 사물을 자기 뜻대로 보라는 동료들의 압력에 대응하여 판단력이 가장 먼저 갈지도 모른다. Breakdown under pressure comes in many forms. Judgment may be the first thing to go, especially in response to peer pressure to see things their way.
사람들이 육체적으로든 정신적으로든 프로젝트를 떠나면, 그것은 그들 자신을 떠날 가능성이 더 높은 나머지 사람들에게 압력을 가한다. As people leave a project, either physically or mentally, it adds pressures to the remaining people, who are then more likely to leave themselves.
관리자는 이미 군림하고 있는 전문가에게만 새로운 과제를 부여하는 것을 선택함으로써 '말뚝이 다이나믹'을 만들어 낼 수 있다. 이것은 그들의 부하와 전문성을 더해주기 때문에 그들은 다음 과제를 받을 가능성이 더 높다. Managers may create a Pile-On Dynamic by choosing to give new assignments only to those people who are already the reigning experts. This adds to their load, and their expertise, which makes it more likely they'll get the next assignment.
생명을 위협하는 상황이 아닌데도 '공황 반응'으로 스트레스에 반응하는 사람도 있다. 그런 사람들은 스트레스를 많이 받는 프로젝트에 참여해서는 안 되며, 그렇지 않으면 스트레스를 가중시킬 뿐이다. Some people respond to stress with a Panic Reaction, even though the situation is not anything like life-threatening. Such people must not be in high-stress projects, or they will only add to the stress.
압력을 관리할 수 있다. 노동자들이 자율규제하고, 경영자들이 힘을 실어주고, 더 많은 압박에 대한 대비태세를 측정하기 위해 성과보다는 대응력을 발휘하는 것이 도움이 된다. Pressure can be managed. It helps if the workers are self-regulating, the managers are empowering, and that responsiveness, rather than performance, is used to measure readiness for more pressure.
Chapter 6: Handling Breakdown Pressure
Summary
소프트웨어 프로젝트는 시간의 현실이 마침내 그들이 실제로 어디에 있는지 깨닫게 할 때 일반적으로 무너진다. 그러나 이렇게 되면 표시되는 증상은 각 프로젝트와 개인마다 고유하게 나타난다. Software projects commonly break down when the reality of time finally forces them to realize where they actually are. When this happens, however, the symptoms displayed are unique to each project and each individual.
많은 증상들은 일을 이리저리 뒤척이며, 아무것도 이루지 못하거나 심지어 실제로 프로젝트를 거꾸로 보내는 것과 같다. 이러한 역학관계 중 하나는 기존 근로자들 간의 업무 분담을 통해 브룩스의 법칙을 물리치려는 시도다. Many symptoms are equivalent to shuffling work around, accomplishing nothing or, even worse, actually sending the project backwards. One such backwards dynamic is the attempt to beat Brooks's Law through splitting tasks among existing workers.
비효율적인 우선 계획은 아무것도 하지 않는 일반적인 방법이다. 여기에는 모든 것을 최우선 순위로 설정하거나, 프로젝트 우선 순위에 관계 없이 자신의 우선 순위를 선택하거나, 가장 쉬운 작업을 먼저 수행하는 것 등이 포함된다. Ineffective priority schemes are common ways of doing nothing. These including setting everything to number one priority, choosing your own priority independent of project priority, or simply doing the easiest task first.
아무것도 하지 않는 최종적인 방법은 '뜨거운 감자'를 순환시키는 것인데, '측정' 시간이 되면 경영진이 책상 위에 있으면 자신에게 불리하게 작용한다. A final way of doing nothing is to circulate "hot potatoes," which are tasks that management counts against you if they are on your desk when "measurement" time comes.
관리자들이 실제로 아무것도 하지 않고 있다는 것을 관찰할 수 있는 여러 가지 방법이 있다. 그들은 그럴지도 모른다. There are a number of ways to observe that managers are actually doing nothing. They may
품질이 나쁜 제품을 받아들이고 있다. be accepting poor quality products
일정 미끄러짐을 수용하지 않음 not be accepting schedule slippage
리소스 오버런을 수용하고 있음 be accepting of resource overruns
작업자가 사용할 수 없음 be unavailable to their workers
프로젝트를 제대로 수행할 시간이 없다고 주장 assert that they have no time to do the project right
시간의 압박에 의해 프로젝트가 무너지고 있다는 확실한 신호는 관리자와 노동자가 합선 절차를 시작하는 것이다. 이러한 불변성은 관리자가 개선하고자 했던 바로 그 품질이 단락 작용에 의해 악화되는 부메랑 효과를 만들어낸다. A sure sign that a project is breaking down under time pressure is when managers and workers start short-circuiting procedures. This invariable creates a boomerang effect in which the very quality the manager intended to improve is made worse by the short-circuiting action.
시간과 자원을 절약하기 위해 열악한 품질을 선적하기로 한 결정은 항상 부메랑 효과를 낳는다. 우회 품질보증도 비슷하다. 이 두 가지 전술은 무엇보다도 개발 과정의 파괴, 더 많은 비상 사태와 방해, 그리고 사기의 파괴로 이어진다. The decision to ship poor quality to save time and resources always creates a boomerang effect. Bypassing quality assurance is similar. Both of these tactics lead, among other things, to destruction of the development process, more emergencies and interruptions, and devastation of morale.
사기가 저하되어 프로젝트 불경기로 접어들면 개선은커녕 공정의 질도 유지되지 않는다. 위기 이전에 구축된 신뢰는 조직이 더 빨리 회복하는 데 도움이 되겠지만, 위기 동안 신뢰를 구축하려는 시도는 역효과를 낳을 것이다. 특히 "나를 믿어!" When morale deteriorates into project depression, process quality will not be maintained, let alone improved. Trust built before the crisis will help an organization recover more quickly, but attempts to build trust during the crisis will probably backfire—especially if they are in the form of telling: "Trust me!"
다수의 고객이 부메랑 사이클에 대한 압력을 증가시켜 결과적으로 품질이 저하되어 고객이 멀어지게 되고, 따라서 조직이 안정화되거나 조직이 사망하게 된다. Multiple customers increase the pressure on the boomerang cycle, up to the point that the resultant poor quality drives away customers, thus stabilizing the organization—or killing it.
Chapter 7: What We've Managed To Accomplish
Summary
우리의 실패를 연구함으로써 얻을 수 있는 인상에도 불구하고, 우리는 소프트웨어 산업의 지난 40년 동안 많은 것을 해냈다. In spite of the impression we might get from studying our failures, we've managed to accomplish a great deal in the past 4 decades of the software industry.
우리가 많은 것을 성취한 이유 중 하나는 우리들 중 많은 이들이 가지고 있는 가장 강력한 자산인 사고의 질이다. One of the reasons we've accomplished a great deal is the quality of our thinking, which is the strongest asset many of us have, when we use it.
관리자를 선발하는 과정 때문에 우리 산업은 아마 어려움을 겪었을 것이다. 프로그래밍 업무에 자신을 선택하는 사람들은 아마도 관리직에 가장 적합한 "자연인"은 아닐 것이다. 그럼에도 불구하고 훈련을 받으면 관리를 잘 하는 법을 배울 수 있었다. 하지만 우리가 관리자을 존중하지 않는 한, 그들은 그들이 필요로 하는 관리 교육을 10분의 1도 받지 못할 것 같다. Our industry has probably suffered because of the process by which we select our managers. People who select themselves into programming work probably are not the best "naturals" for management jobs. Nevertheless, they could learn to do a good job of managing, if they were given the training. As long as we don't honor management, however, they're not likely to receive one-tenth the management training they need.
소프트웨어와 하드웨어 도구의 공급자에게 귀를 기울인다면 소프트웨어 산업의 성과는 당신이 믿을 수 있는 것보다 훨씬 더 크다. 우리가 잘 하고 있지 않지만, 그들의 도구가 우리가 필요로 하는 마법의 총알이 될 것이라고 믿게 만드는 것이 그들의 이익이다. The accomplishments of the software industry are much greater than you would believe if you listened to the purveyors of software and hardware tools. It is in their interest to make us believe that we're not doing very well, but that their tool will be the magic bullet we need.
우리는 위대한 일을 성취하고 싶기 때문에 마법의 총알에 어리버리들이 되는 경향이 있지만, 위대한 일은 보통 대중적인 이미지와는 달리 일련의 작은 단계를 통해 성취된다. We tend to be suckers for magic bullets because we want to accomplish great things, but great things are usually accomplished through a series of small steps, contrary to the popular image.
야심이 너무 강해서 생산성이 얼마나 높아졌는지 인식하지 못할 수도 있다. 우리가 어떤 것을 잘 해내는데 성공하면, 우리는 즉시 우리의 성과를 평가하기 위해 멈추지 않고 좀더 웅장한 것을 시도한다. We may fail to recognize how much our productivity has increased because we are so ambitious. Once we succeed in doing something well, we immediately attempt something more grand, without stopping to take stock of our accomplishments.
각각의 패턴이 우리 산업의 발전에 기여했다. 패턴 0은 일반 대중들에게 컴퓨터를 덜 무섭게 만들었다. 패턴 1은 우리의 생산성에 기여하는 많은 혁신을 이루었다. 패턴 2는 이러한 기술 혁신을 일상적인 방법으로 많은 대형 프로젝트를 완료할 수 있도록 하는 방법론으로 묶어 왔다. 패턴 3은 우리에게 더 큰 프로젝트를 통제하는 데 필요한 것을 가르쳐 주었다. 패턴4와 5의 기여는 여전히 가능성의 비전 측면에서 더 많지만, 그것은 실제 성취만큼 진척에 중요하다. Each pattern has contributed to the development of our industry. Pattern 0 has made computers less frightening to the general public. Pattern 1 has made many innovations that have contributed to our productivity. Pattern 2 has strung these innovations together into methodologies that make it possible to complete many larger projects in routine ways. Pattern 3 has taught us what is needed to keep even larger projects under control. The contributions of Patterns 4 and 5 are still more in terms of visions of possibilities, but that's as important to progress as actual accomplishments.
메타패턴은 산업 전반의 문화의 발전 패턴이다. 다시 한 번 각 패턴이 메타패턴의 발전에 기여했고, 우리는 소프트웨어 취급법을 배울 뿐만 아니라 소프트웨어 취급법을 배우고 있다. Meta-patterns are the development patterns of the culture of the industry as a whole. Once again, each pattern has contributed to the development of meta-patterns, and we are not only learning to handle software, but are learning how to learn to handle software.
QSM: Volumn 2.1: How to Observe Software Systems
Contents
Part I. 받아들이기 (Intake)
Chapter 1. 관찰이 왜 중요한가 (Why Observation is Important)
Summary
소프트웨어 엔지니어링 관리가 거의 실패할 때마다 제품 뿐만 아니라 공정의 품질 문제 때문에 실패한다. Almost any time software engineering management fails, it fails because of quality problems in the process as well as the product.
관리가 효과적인 관찰을 하지 않고 있기 때문에 품질 문제가 관리를 "깜짝 놀라게" 한다. Quality problems "surprise" management because management is not making effective observations.
관리자들이 관찰하지 못하는 것 중 하나는 그들 자신의 소프트웨어 엔지니어링 문화인데, 이것은 놀랍지 않다. 왜냐하면 문화는 "당신이 알고 있다는 것을 모르고 있는 무언가"이기 때문이다. One of the things managers fail to observe is their own software engineering culture, which is not surprising, because culture is "what you know that you don't know you know."
크로스비는 문화 패턴의 아이디어를 산업 프로세스 연구에 적용하고, 크게 각각에서 발견되는 관리 태도를 바탕으로 5가지 패턴을 관찰했다. Crosby applied the idea of cultural patterns to the study of industrial processes and observed five patterns based largely on the management attitudes to be found in each.
소프트웨어 엔지니어링 연구소(SEI)는 크로스비의 작업을 소프트웨어와 연관시키고, 각 패턴에서 발견되는 프로세스의 종류와 관련된 5가지 수준의 "프로세스 성숙도"를 식별했다. The Software Engineering Institute (SEI) related Crosby's work to software and identified five levels of "process maturity" related to the types of processes found in each pattern.
(조직 내) 사람들이 행동한다고 말하는 것에 따라 조직을 분류하면, 다음과 같은 수의패턴의 시스템과 매치할 수 있다: Classifying organizations by what people in them say they're doing, we can match them to the numbers of other systems of patterns as follows,
무자각 Oblivious: "우리는 우리가 프로세스를 수행하고 있는지도 모르고 있다." "We don't even know that we're performing a process."
가변 Variable: "우리는 지금 이 순간 우리가 느끼는대로 무엇이든 한다." "We do whatever we feel like at the moment."
루틴 Routine: "우리는 우리의 루틴을 따른다 (패닉에 빠졌을 때를 제외하고)" "We follow our routines (except when we panic)."
조정하는 Steering: "우리는 우리의 루틴이 만들어내는 결과들에 따라 우리의 루틴을 선택한다." "We choose among our routines by the results they produce."
예측하는 Anticipating: "우리는 루틴의 과거 경험을 바탕으로 루틴을 수립한다." "We establish routines based on our past experience with them."
일치적인 Congruent: "우리 모두는 언제나 모든 것을 개선하는데 관여한다." "We all are involved in improving everything all of the time."
소프트웨어 문화 패턴을 결정하는 SEI 방법은 설문조사를 실시하고 인터뷰와 관찰로 이를 추적하는 것으로 시작한다. 인터뷰와 관찰이 생략되면, 설문은 무용지물보다 더욱 나쁜 것이 될 수 있다. The SEI method of determining software cultural pattern starts by conducting a survey and following it up with interviews and observations. If the interviews and observations are omitted, the survey can prove worse than useless.
각각의 문화는 각각의 독특한 관찰 스타일을 가지고 있다. Each culture has its own characteristic observation style.
무의식 (패턴0)과 가변 (패턴1) 문화는 일반적으로 약간의 문제가 발생한 후에만 관찰하며, 이는 비용과 위험을 크게 증가시킨다. The Oblivious (Pattern 0) and Variable (Pattern 1) cultures typically observe only after there is some trouble, which greatly increases their costs and risks.
루틴 (패턴2) 조직은 소프트웨어에 대한 접근법과 관찰에 있어 훨씬 더 체계적이 되려고 노력한다. 그들은 실패 정보에 초점을 맞추는 경향이 있다. 루틴 패턴은 위기로 인해 놀라기 전까지 많은 것들을 잘 처리한다. Routine (Pattern 2) organizations try to be much more systematic in their approach to software and thus to observation as well. They tend to focus on failure information. The Routine pattern handles a lot of things well, until they are surprised by a crisis.
조정하는 (패턴3) 조직은 종종 루틴 조직의 신생 "측정치" 프로그램을 변형시키고 인간의 행동을 보다 직접적으로 관찰하려고 한다. Steering (Pattern 3) organizations often transform the fledgling "metrics" programs of the Routine organization and try to observe human behavior more directly.
조정하는 관리자들은 어떻게 적절하게 따라야 할지 알고 있다, 비난하는 것이 아니라, 정보를 수집하는 것을 통해 Steering managers know how to follow through appropriately, not by blaming but by gathering information.
실패 감지의 다중 소스는 라이프 사이클의 어느 특정 순간에 탐지 가능성이 더 크다는 것을 의미한다. 조기 발견은 개발 및 사용 비용 절감을 의미한다. Multiple sources of failure detection means greater likelihood of detection at any particular moment in the life cycle. Early detection means reduced development and usage costs.
예상하는 (패턴4) 조직은 측정을 사용하여 문제 예방에 초점을 맞추고 있으며, 관리자가 이용할 수 있는 정보의 출처를 지속적으로 개선하고 있다. Anticipating (Pattern 4) organizations use measurement to focus on prevention of problems, and are continually improving the sources of information available to managers.
일치적 (패턴5) 조직은 더 미묘한점에 주목함으로써 더 일찍 관찰하는 법을 배운다. 그들은 또한 메타 관찰, 즉 그들 자신의 관찰 방법에 대한 관찰에 대해서도 연구한다. 그리고 그들이 배우는 모든 것은 그들의 조직 전체에 적용된다. Congruent (Pattern 5) organizations learn to observe earlier, by taking note of more subtle things. They also work on meta-observation—the observation of their own ways of observing. And everything they learn is applied throughout their organization.
Chapter 2: 무엇을 관찰할지 고르기 (Selecting What to Observe)
Summary
그들이 체계적으로 관찰하고 관찰하지 못하는 것에 의해 당신은 관리 뿐만 아니라 문화적 패턴도 특징지을 수 있다. You can characterize management as well as cultural patterns by what they systematically observe and fail to observe.
상호작용 모델(SatirInteractionModel)의 첫번째 주요 단계는 수용이다. 나는 세상으로부터 데이터를 얻기로 결심하고, 어떤 데이터를 얻어야 할지를 선택하며, 충분할 때 결정한다. The first major step in the Interaction Model is intake. I decide to obtain data from the world, I select which data to obtain, and I decide when I have enough.
입력 단계에서, 우리는 우리가 세상에 존재하는 것, 심지어 의도적으로 보내지는 것조차 정확히 얻지 못하고 있을 가능성을 알아야 한다. In the input step, we need to be aware of the possibility that we aren't getting exactly what is out there in the world, even what is intentionally sent.
세상으로부터 오는 데이터는 어느 누구도 특정한 방식으로 반응하게 하지 않는다. Data coming from the world doesn't make anyone react in a certain way.
모든 상황은 관찰의 가능성을 제시하지만, 나는 어떤 가능성을 받아들일지 선택해야 한다. 모든 것을 관찰하는 것은 인간적으로 가능하지도 않고 경제적으로도 가능하지도 않다. 한 가지를 관찰하려면 다른 것을 관찰하는 것을 생략해야 한다. Every situation offers possibilities for observation, but I must choose which possibilities to accept. Observing everything is neither humanly possible nor economically feasible. To observe one thing, I must omit observing something else.
명시적인 보상과 처벌이 없더라도 어떤 것을 암묵적으로 관찰하는 것만으로도 그것을 더욱 강화시킨다. Even without explicit rewards and punishments, the mere fact of observing something implicitly reinforces it.
측정의 의미에 대한 개인적 모델이 없다면 측정은 위험하다. 개인적인 관찰 모형은 우리의 관찰 노력을 인도하여 내가 통제하려고 하는 바로 그 프로젝트에 의미 있고, 효율적이며, 최소한의 방해만 될 것이다. 측정 모델은 무엇을 측정해야 하는지, 어떻게 데이터를 해석해야 하는지, 왜 측정하는지, 얼마나 정밀하게 측정해야 하는지 알려준다. Measurement is dangerous without a personal model of what the measurements might mean. A personal model of observation guides our observation efforts so they will be meaningful, efficient, and minimally disturbing to the very project I'm trying to control. The measurement model tells me what to measure, how to interpret those data, why I'm measuring, how much precision I need to measure.
많은 예들은 잘못된 모형을 사용하는 것 또한 문제를 일으킬 것이며, 어쩌면 전혀 모델이 없는 것보다 더 나쁜 것일 수도 있다는 것을 암시한다. Many examples imply that using a wrong model will also cause problems, perhaps even worse than no model at all.
시스템의 상태를 알때만 오직 그 행태를 조절할 수 있는 분별 있는 개입을 할 수 있다. Only when I know the state of the system can I make sensible interventions to control its behavior.
동일한 관찰에 다른 의미를 부여하는 능력은 아마도 패턴2(루틴) 조직의 특징인 소프트웨어 재난의 많은 부분을 설명할 것이다. The ability to put different meanings on the same observation probably accounts for many of the software disasters that are so characteristic of Pattern 2 (Routine) organizations.
가능한 통제 개입의 관점에서 해석할 수 없는 관찰은 유용하지 않다. 우리가 이런 식으로 해석할 수 있는 관측은, 그것이 "측정"처럼 보이지 않는 경우에도 유용하다. Observations that we can't interpret in terms of possible control interventions are not useful. Observations that we can interpret in this way are useful, even if they don't seem to be "measurements."
조직의 중요한 척도 중 하나는 관리자들이 동작하는 모델이 없는 지나치게 정밀한 측정에 얼마나 몰두하는가이다. One important measure of an organization is how preoccupied the managers are with overly precise measurements for which they have no working models.
두 가지 주요한 관리상의 실수는 시스템 사고력 부족과 의미있는 관찰을 생성하지 못한 것이다. 어느 정도는, 한 사람에게 더 잘해주는 것이 다른 사람에게 나쁜 짓을 한 것에 대한 보상에 도움이 된다. Two major management mistakes are lack of systems thinking and failure to generate meaningful observations. To some extent, doing better on one helps compensate for doing badly on the other.
Chapter 3: 제품을 시각화하기 (Visualizing the Product)
Summary
품질에 대한 데밍과 크로스비의 아이디어는 모두 제조 조직에서의 경험에서 파생된 것이다. 그러나 소프트웨어 개발은 일차적으로 제조가 아닌 엔지니어링 프로젝트 관리 운영이다. Both Deming's and Crosby's ideas on quality are derived from experience with manufacturing organizations. Software development, however, is not primarily a manufacturing operation, but an engineering project management operation.
제조 관리와 프로젝트 관리 모두 제어의 사이버네틱스 모델을 공유한다. 사이버네틱 모델을 적용하려면 출력이 가시적ㄱ이어야 한다. 즉, 소프트웨어에 의해 자동으로 충족되지 않는 조건이다. Both manufacturing management and project management share the cybernetic model of control. For the cybernetic model to be applicable, outputs must be visible—a condition that is not automatically met by software.
관찰자로서 행동할 때, 사람들은 일반적으로 시각, 청각, 운동, 후각, 그리고 미각, 등 이러한 감각들에 의존한다. 우리는 각자 좋아하는 감각이 있지만, 우리가 좋아하는 감각의 사용이 박탈되었을 때, 우리는 다른 감각으로 적응할 수 있다. When acting as observers, people ordinarily have these sensory modalities to draw upon—visual, auditory, kinesthetic, olfactory, and gustatory. We each have our favorite modalities, but when deprived of the use of our favorite modality, we can adapt by using the others.
우리는 소프트웨어를 간접적으로밖에 경험할 수 없다. 그것은 어떤 번역 과정 (프로그래머가 소프트웨어와 집적 접촉하는 것처럼 말하는 경우가 많지만)을 거치기는 하지만. 수많은 친숙한 소프트웨어 도구들이 소프트웨어를 더 잘 보이게 하기 위해 고안되었다. 이러한 관측 가능성 도구는 레이더가 어떤 전쟁을 해야 하는지를 소프트웨어로 만드는 것이다.: 그들은 "어둠 속에서" 조종하는 것을 가능하게 한다. We can only experience software indirectly, though some translation process (although programmers often talk as if they are in direct contact with software). An enormous number of familiar software tools have been designed to make software more visible. These observability tools are to software what radar was to warfare: they make it possible to steer "in the dark."
같은 정보를 전달하는 서브 모달리티일수록 메세지가 강해진다. 반면에, 복수의 모달리티는 특정 관찰자에게는 정보를 왜곡할 수 있다. 이러한 왜곡은 과학을 위한 것은 아니지만 관리를 위해 완벽하게 정당화될 수 있다. The more sub-modalities that carry the same information, the stronger the message. On other hand, multiple modalities may distort the information for certain observers. Such distortion may be perfectly justified for managing, though not for science.
우리의 뇌 용량은 제한적이기 때문에, 우리는 같은 측정에 대해 두 개 이상의 사진이 필요하다. 그 사진들의 왜곡은 우리의 제한된 정신력을 극복하기 위해 우리가 지불하는 대가이다. Because our brain capacity is limited, we need more than one picture of the same measurement. The distortions in those pictures are the price we pay for overcoming our limited mental capacity.
소프트웨어의 모든 사진은 지도인데, 그 지도는 영역이 아니다. 효과적인 다른 모달리티의 표현 뿐 만 아니라 많은 시각화 지도가 동일한 영역에 필요하다. Every picture of software is a map, and the map is not the territory. For effective software management, many maps—many visualizations as well as representations in other modalities—are needed of the same territory.
제품의 관찰을 방해하는 것은 어떤 것이든 조직이 더 높은 수준의 생산성과 품질을 달성하지 못하게 한다. 가시성이 없이는, 우리는 어떤 프로젝트에 대한 통제권을 보장할 수 있는 능력을 상실한다. Anything that prevents observation of the product also prevents the organization from achieving higher levels of productivity and quality. Without visibility, we lose the ability to guarantee control over any project.
완료된 제품은 사람들이 가장 먼저 시각화할 수 있어야 하는 것이다. Deming은 자신이 작업하고 있는 것을 시각화할 수 없는 사람들은 분명히 그것의 품질에 대한 실질적인 기여를 하는데 어려움을 겪을 것이라고 관찰했다. The finished product is the first thing that people should be able to visualize. Deming observed that people who can't visualize what they're working on will certainly have a hard time coming up with real contributions to its quality.
가시성이 매우 중요하기 때문에 우리는 다음 세 가지 질문을 함으로써 조직이 패턴3 혹은 조정하는 문화에 도달했는지 여부를 신속하게 평가할 수 있다: 모든 것을 볼 수 있는가? 시각화할 수 있는가? 일그러지지 않은 채로? Visibility is so important we can make a quick assessment of whether or not an organization has reached a Pattern 3, or Steering, culture by asking three questions: Is everything available to view? visualizable? undistorted?
Chapter 4: 절차(프로세스)를 시각화하기 (Visualizing the Process)
Summary
예측하는 (패턴4) 관리자들은 각 제품의 품질을 단순히 조절하는 것이 아니라, 모든 제품의 품질을 동시에 조절하는 방식으로 관리한다. Anticipating (Pattern 4) managers are not just steering the quality of each product, they are steering the quality of all products at the same time by steering the process.
프로세스가 여러분의 제품인 경우, 당신은 소프트웨어를 볼 수 있고, 시각화할 수 있으며, 왜곡되지 않은 상태에서 사용했던 것과 동일한 기준을 사용하여 프로세스를 시각화할 수 있어야 한다. When processes are your products, you must be able to visualize your processes, using the same criteria you used when software was the product: available to view, visualizable, and undistorted.
프로세스 정보는 반드시 인간 감각 시스템이 사용할 수 있는 형식으로 제시되어야 한다. 데밍의 작업은 프로세스 데이터를 시각 시스템에 사용할 수 있도록 하기 위해 다양한 그림의 중요성을 강하게 강조해 왔다. Process information must be presented in formats that the human sensory system can use. Deming's work has strongly emphasized the importance of a variety of pictures to make process data available to the visual system.
프로세스 정보의 피드백은 제품 정보와 같은 모든 왜곡의 희생물이며, 몇 가지 더 있다. Feedback of process information is prey to all the same distortions as product information—and a few more.
제품 가시성보다는 프로세스 가시성에 대한 질문을 가지고 조직이 패턴4 또는 예상하는 문화에 도달했는지 여부를 신속하게 평가할 수 있다. 패턴4 관리자는 다른 어떤 것이든 모든 것이 정보라는 견해를 가지고 있다. We can make a quick assessment of whether or not an organization has reached a Pattern 4, or Anticipating, culture, with questions about process visibility rather than product visibility. Pattern 4 managers take the view that no matter what else it is, everything is information.
모든 사람이 공유된 시각화 기법을 배운다면, 그들은 프로세스 개선을 논의할 때 공통의 어휘를 공유하게 된다. 이것은 데밍 접근법의 필수적인 부분이다. If everyone is taught a shared set of visualization techniques, they will share a common vocabulary when discussing process improvement. This is an essential part of the Deming approach.
시각화는 흐름, 원인과 효과, 분포, 추세를 설명하는데 사용할 수 있다. Visualizations can be used to describe flow, cause and effect, distributions, and trends.
프로젝트 제어판은 프로젝트의 모든 활력 징후를 보여주기 위해 하나의 작은 영역에 다수의 시각화를 결합한다. 관리자는 프로젝트 제어판을 모니터링하여 프로젝트의 일부 측면에 주의가 필요한 시점을 신속하게 알 수 있다. A project control panel combines a number of visualizations in one small area to show all the vital signs of the project. By monitoring the project control panel, a manager can know quickly when some aspect of the project requires attention.
Part II. 의미 (Meaning)
Chapter 5: 해석에 대한 한 케이스 스터디 (A Case Study of Interpretation)
Summary
SatirInteractionModel은 사람들이 항상 그들이 가지고 있는 데이터로부터 의미를 부여하려고 노력한다고 말한다. The Satir Interaction Model says that people always attempt to make meaning from the data they take in.
소프트웨어 문화는 시간이 지남에 따라 지속되는 무의식적인 패턴을 통해 그 존재를 알려준다. 그들의 무늬는 여러 가지 방법으로 볼 수 있다. 슬립차트는 조직의 약속과 전달의 차이를 해석하는데 도움을 주는 데이터의 시각화로서, 조직의 문화를 잘 특징짓는 것이다. Software culture makes its presence known through unconscious patterns that persist over time. Their patterns can be seen in many ways. The slip chart is a visualization of data that helps us interpret the differences between an organization's promise and delivery—a good characterization of its culture.
슬립차트는 이미 이용 가능한 정보와 공개 정보를 이용하여 어떤 프로젝트에서든 저렴하게 얻을 수 있는 측정을 묘사하고 있다. 정보는 예정된 전달 날짜, 해당 전달 날짜의 변경 사항 및 해당 변경이 발표된 날짜로 구성된다. The slip chart depicts a measurement that can be obtained cheaply on any project using information already available and public. The information consists of scheduled delivery dates, changes in those delivery dates, and the dates on which those changes are announced.
슬립은 전달 예정일의 변경사항이다. 공고일은 새로운 예정 전달일이 공개된 날이다. 슬립에는 새로운 전달 날짜와 다음 새로운 전달 날짜의 발표 날짜를 표시하여 문화적 패턴을 보여준다. A slip is a change in the scheduled delivery date. The announcement date is the date on which a new scheduled delivery date is made public. The slip chart reveals cultural patterns by plotting the new delivery date versus the announcement date for that next new delivery date.
공고 일자와 옛날 전달 일자의 차이가 리드이다. 슬립-리드 차트는 슬립과 리드에 관련된 스캐터 다이어그램이다. The difference between the announcement date and the old delivery date is the lead. The slip-lead chart is a scatter diagram relating slips and leads.
건강한 프로젝트에서는, 슬립을 발표하기 전에 예정된 날짜에 프로젝트가 가까워질수록 슬립은 작아진다. In a healthy project, the closer the project is to the scheduled date before announcing a slip, the smaller that slip will be.
각 슬립은 오버헤드 지연을 추가하는데, 그것은 "작은 슬립은 받지 말라"라는 조언의 하나의 이유이다. Each slip adds an overhead delay, which is one reason for the advice, "Take no small slips."
일관된 측정 패턴은 조직 문화의 많은 측면을 드러낸다. 슬립 차트, 슬립-리드 차트, 램프 차트 등 다양한 시각화를 통해 데이터에서 의미를 추출할 수 있다. Consistent patterns of measurement reveal many aspects of an organization's culture; the meaning can be extracted from the data with a variety of visualizations, such as slip charts, slip-lead charts, and ramp charts.
시각화에 대한 사람들의 반응도 의미를 나타내는 데이터를 제공한다. People's reactions to visualizations also provide data that suggest meaning.
가장 중요한 문화적 의미는 데이터 해석이 소프트웨어 엔지니어링 관행의 개선을 가져올 수 있는 학습을 차단하기 때문에 데이터 해석을 차단하는 태도다. The most important cultural meanings to unearth are attitudes that block interpretations of data because they block the learning that could lead to improvement in software engineering practices.
이러한 더 깊은 의미를 밝혀내는 열쇠는 스스로에게 이렇게 묻는 것이다. "이러한 측정을 생성했던 행동을 발생시킨 모델은 무엇인가?" The key to uncovering these deeper meanings is to ask yourself, "What are the models that generated the behavior that produced those measurements?"
램프 차트는 단순히 기준선에 대한 선이 고정된 슬립차트일 뿐이다. 이 차트는 어떤 조직이 압력을 받아 발표하는 일정을 무시한다는 것을 드러낼 수 있다. A ramp chart is simply a slip chart with lines to the baseline filled in. This chart may reveal that an organization ignores the schedules it announces under pressure.
Chapter 6: 관찰로부터 의미를 만들 때 자주 하는 실수들 (Pitfalls When Making Meaning from Observations)
Summary
SatirModel은, 자료를 받은 후, 내 내적 단계는 내가 취한 것을 해석하는 것이라고 말한다. 나는 나의 과거 경험에 따라 해석하는데, 그것은 같은 관찰에 대해 다른 해석을 할 수도 있다. The Satir Model says that after receiving data, my next internal step is to interpret what I have taken in. I interpret according to my past experience, which may be different from the past experience of others, so we may have different interpretations of the same observation.
두 가지 이상의 해석이 가능하다는 것을 항상 명심해야 한다. 만약 당신이 받은 것에 대해 적어도 세 가지의 다른 해석을 생각할 수 없다면, 당신은 그것이 무엇을 의미할지에 대해 충분히 생각하지 못했다. It's always important to remember that more than one interpretation is possible. If you can't think of at least three different interpretations of what you received, you haven't thought enough about what it might mean.
해석은 관찰이 아니다. 차이점을 명확히 하기 위해, 우리는 데이터 질문을 한다: "무엇을 보거나 들어서 그러한 결론을 내리게 되었나요?" Interpretation is not observation. To keep the difference clear, we ask the Data Question: "What did you see or hear that led you to that conclusion?"
해석하기 위한 다소 체계적인 과정은 다음과 같다: Here is a somewhat systematic process for making interpretations:
데이터를 받아들인다. 데이터 질문을 사용하라. Take in data. Use the Data Question.
의미에 대한 가설을 세운다. Form hypotheses about meaning.
가설을 하나로 줄인다. 가장 가능성이 높은 것을 골라라. Reduce hypotheses to one. Choose the most likely.
그것이 중요한지 판단해라. Decide if it's important.
그에 대해 무엇인가 행한다. 가설을 무효화할 수 있는 검정을 수행하라. Do something about it. Perform a test that could invalidate the hypothesis.
가설이 무효화되었는지 확인하기 위해 데이터를 취한다. 그렇다면 1단계, 2단계 또는 3단계로 돌아가라. Take in data to see if the hypothesis is invalidated. If it is, return to step 1, or 2, or 3.
값비싼 측정 프로그램을 시작하기 전에 시도할 수 있는 싸고 쉬운 방법들이 많이 있다. 갇낳나 것부터 시작해서 해석 과정을 적용하라. There are many cheap and easy measures you can try before embarking on an expensive measurement program. Start with something simple and apply the interpretation process.
메타 관찰은 관찰에 관한 관찰이며, 종종 관찰 자체보다 더 많은 것을 우리에게 말해준다. 원하는 데이터를 얻을 수 없더라도 조직에서 데이터를 얻고 보관하는 문제에 대한 데이터를 항상 얻는다. Meta-observations are observations about observations, and often tell us more than the observations themselves. Even if you can't get the data you want, you always get data about the problems of getting and keeping data in an organization.
가설을 무효화하려는 시도는 다음과 같은 함정으로 인해 중요하다: The attempt to invalidate hypotheses is important because of the following pitfalls:
검증이 없으면 보이는 것과 다를 수 있다. Something may not be what it seems, if there is no verification.
데이터는 무의식적으로 선택되었을 수 있다. Data may have been unconsciously selected.
데이터는 의식적으로 선택되었을 수 있다. Data may have been consciously selected.
오해로 인해 측정이 잘못될 수 있다. Measurements may be wrong because of misunderstanding.
변조로 인해 측정이 잘못될 수 있다. Measurements may be wrong because of falsification.
Chapter 7: 품질에 대한 직접적인 관찰 (Direct Observation of Quality)
Summary
품질 좋은 소프트웨어를 생산하기 위해서는 이걸 알아야 한다: "이 제품의 품질은 무엇인가, 지금 당장?" 이 질문에 답하는 데는 두 가지 다른 접근법이 있다 - 즉, 직접 접근법과 간접 접근법이다. To produce quality software you need to know: "What is the quality of this product, right now?" There are two different approaches to answering this question—the direct approach and the indirect approach.
많은 사람들에게, "품질"은 누구도 반대할 수 없을 정도로 모호한 용어다. 궁극적으로, 모든 사람은 품질에 대한 동일한 정의를 가지고 있으며, 이와 같은 것이 된다: "품질이란 내가 좋아하는 것은 어떤 것이든지" For many people, "quality" is such an ambiguous term that nobody could be against it. Ultimately, everyone has the same definition of quality, and it goes something like this: "Quality is whatever I like."
품질은 상대적이다. 어떤 사람에게는 품질이 가치 있는 것이다. 가치란 자신의 요구 사항을 충족시키기 위해 기꺼이 돈을 지불하는 것이다. 한가지 올바른 방법을 찾는 것이 가장 강력한 욕구를 가진 완벽주의자들은 품질에 대한 이 상대적인 정의에 만족하지 못할 것이다. 하지만, 그렇다면 완벽주의자들은 어떤 것에도 만족하지 않을테니, 그것들을 잊어라. Quality is relative. Quality is value to some person. Value is what are people willing to pay to have their requirements met. Perfectionists whose strongest desire is to find the one right way will not be satisfied with this relative definition of quality. But, then, perfectionists won't be satisfied with anything, so forget them.
오늘날 소프트웨어 조직은 품질 문제로 과부화되어 더 이상 소프트웨어 개발 사업에 효과적으로 대처하지 못하고 있다. 그러나 많은 관리자들은 이 과부하와 품질 문제 사이의 관계를 인식하지 못한다. Many software organizations today are so overloaded with quality problems that they are no longer coping effectively with their business of developing software. Yet many managers fail to recognize the relationship between this overload and quality problems.
관리자들은 또한 그들 자신의 행동과 그들이 얻고 있는 결과 사이의 관계를 인식하지 못한다. Managers also fail to recognize the relationship between their own actions and the results they're getting.
모든 소프트웨어 문제는 품질 문제다. 품질의 0번째 법칙에 따르면, 만약 당신이 품질에 관심이 없다면, 당신은 다른 어떤 요구조건도 충족시킬 수 있다. 품질을 조절할 필요가 없다면 다른 어떤 것도 조절할 수 있다. Every software problem is a quality problem. The Zeroth Law of Quality says, If you don't care about quality then you can meet any other requirement. If you don't have to control quality, you can control anything else.
품질은 우리가 찾을 수 있는 가장 직접적인 소프트웨어 측정 방법이며, 품질을 측정하는 유일한 직접적인 방법은 아이디어가 중요한 사람들과 함께 하는 것이다. 궁극적인 정치적 질문은, 그러므로, 누가 품질의 정의를 통제할 수 있는가이다. Quality is the most direct software measure we can find, and the only direct way to measure quality is with the people whose ideas count. The ultimate political question is, therefore, Who gets to control the definition of quality?
권력은 부패한다. 그리고 구너력이 가장 철저하게 부패하는 것은 관찰의 의미를 부여하는 능력이다. 소프트웨어 개발자들이 품질의 정의를 통제할 때, 그들은 단기적으로는 잘 할 수 있지만, 궁극적으로 고객들을 그들이 찾을 수 있는 첫 번째 경쟁자로 몰아갈 것이다. Power corrupts. And what power corrupts most thoroughly is the ability to make meaning of observations. When software developers control the definition of quality, they may do well in the short run, but they will ultimately drive their customers to the first competitor they can find.
오차의 부재의 측정은 품질의 직접 측정과 같지 않다. 진정한 품질 향상은 항상 고객이 원하는 것을 아는 것에서 시작된다. 그것은 품질을 직접적으로 측정하는 유일한 방법이다. The measurement of the absence of errors is not the same as direct measurement of quality. Real quality improvement always starts with knowing what your customers want. That's the only direct measure of quality.
Chapter 8: 비용과 가치 측정하기 (Measuring Cost and Value)
Summary
품질을 향상시키는 동기는 항상 품질의 가치에 대한 연구로 시작하지만, 많은 관리자들이 비용과 가치를 혼동하는 것 같다. The motivation for improving quality always starts with a study of the value of quality, but many managers seem to confuse cost and value.
그 존재를 정당화하라는 압력을 받았을 때, 조직은 비용측면을 강조할지 가치측면을 강조할지를 결정해야 한다. 비용 관찰에서 가치 관찰로의 전환은 조직이 패턴2에서 패턴3으로 전환했음을 보여주는 가장 강력한 지표다. When under pressure to justify its existence, an organization has to decide whether to emphasize the cost side or the value side. The switch from cost observation to value observation is the strongest indication that an organization has made the transition from Pattern 2 to Pattern 3.
"노력은 계산된 것으로 이동한다." 비용 계산은 비용 절감으로 이어진다. 값 계산은 가치 향상으로 이어진다. 비용 절감은 연간 예산에 의해 제한된다. 가치 향상은 무제한이다. "Effort moves to what is counted." Cost counting leads to cost reduction. Value counting leads to value enhancement. Cost reduction is limited by the annual budget. Value enhancement is unlimited.
누군가가 "소프트웨어의 가격이 너무 바씨다"고 말할 때, 그것은 항상 "소프트웨어는 (나에게) 충분한 가치가 없다"는 의미의 암호화된 메시지라고 할 수 있다. 가치는 항상 인식된 가치이기 때문에 우리는 누가 인지하고 있는지 알아야 한다. When someone says, "Software costs too much," it's always a coded message meaning, "Software isn't worth enough (to me)." Value is always perceived value, so we must know who is doing the perceiving.
소프트웨어 프로젝트가 간단히 무너질 때, 품질 질문은 대답하기 쉽다. 품질은 0이다. 모든 품질 붕괴의 밑바탕은 소프트웨어에서 우리가 이전에 인간이 시도했던 것보다 더 높은 정밀도를 통해 품질을 달성하려고 시도하고 있다는 단순한 사실이다. When a software project simply collapses, the quality question is easy to answer—quality is zero. Underlying all quality collapses is the simple fact that in software we are attempting to achieve quality through precision higher than human beings have ever attempted before.
소프트웨어는 젊고 성숙된 사업이다. 초기 시스템에서 품질을 생산하기 위해 수용할 수 있는 프로세스였던 것이 그것의 더 크고 더 복잡한 후계자에서는 받아들일 수 없게 된다. 따라서 소프트웨어 가치가 붕괴되지 않을 때도 소멸한다. Software is a young, maturing business. What was an acceptable process for producing quality in the earlier system becomes unacceptable in its larger, more complex successors. Thus, even when software value doesn't collapse, it decays.
열역학 제2법칙에는 품질을 얻기 위해서는 대가를 치워야 하며, 원하는 품질이 높을수록 더 많은 대가를 치뤄야 한다고 되어 있다. 인간 본성의 제1법칙은 아무도 열역할 제2법칙이 그들에게 적용된다고 믿고 싶어하지 않는다고 말한다. The Second Law of Thermodynamics says that you have to pay to get quality, and the higher quality you want, the more you have to pay. The First Law of Human Nature says that nobody wants to believe the Second Law of Thermodynamics applies to them.
품질에 대한 투자는 돈과 노력 이상의 것이어야 한다. 지속적으로 품질을 생산하기 위해, 관리자들은 새로운 사고방식을 배워야 한다. The investment in quality must be more than money and hard work. To produce quality consistently, managers must learn new ways of thinking.
시스템 사고방식은 품질을 생산하기 위해서는 요구사항이 변화할 때, 또는 요구사항의 이해도가 변화할 때 그 요구사항을 감시해야 한다고 말한다. 그러면 우리는 필요한 것과 생산되는 것 사이의 편차에 기초하여 프로세스에서 조정을 해야 한다. 그것은 관리자의 일이다. Systems thinking tells us that to produce quality, we must monitor requirements as they change, or as our understanding of them changes. Then we must make adjustments in the process on the basis of deviations between what is required and what is produced. That's the manager's job.
2차 요건을 통한 품질 측정은 간접적인 측정으로, 측정과 품질을 연관시키기 위해서는 추가 단계가 필요하며, 그 추가 단계가 잘못될 수 있기 때문이다. 잘못 해석될 가능성이 있다는 것은 관찰을 간접적으로 할수록 세심하게 관리해야 한다는 것을 의미한다. Measurement of quality through secondary requirements is indirect measurement, because it requires an extra step to relate the measurements to quality, and that extra step could go wrong. The possibility of misinterpretation means that the more indirect the observation, the more carefully it must be managed.
표준에 대한 불만은 표준에 부합해야 하는 사람이 표준과 표준의 가치 사이에 인과 관계를 맺지 못할 때 발생한다. 세부적인 영향 사례 방법과 단일 최대 유익성 방법을 통해 우리는 이러한 연결을 만들어 품질을 측정할 수 있다. Discontent over standards arises when people who must conform to the standards cannot make the cause-effect connection between the standard and the value of the standard. The detailed impact case method and the single greatest benefit method allow us to make this connection and thus measure quality.
상세 영향 사례 방법은 변화의 가치 영향에 대한 철저한 연구다. 그것은 효과 다이어그램을 통해 요구사항을 추적하는 아이디어에 기초한다. The detailed impact case method is an exhaustive study of the value impacts of a change. It is based on the idea of tracing requirements through a diagram of effects.
가장 큰 편익 방법은 추정 방법의 비용과 시간을 실제 수준으로 낮추면서 바닥 추정치를 가치에 넣는 한 가지 접근법이다. 가장 큰 단일 유익성 방법의 기본 질문은 "이 변화에 귀속시킬 수 있는 가장 큰 유익성은 무엇인가?"이다. The single greatest benefit method is one approach to putting a floor estimate on value, while keeping the cost and time of the estimating method down to practical levels. The basic question of the greatest single benefit method is "What is the one greatest benefit that you can attribute to this change?"
Chapter 9: 메타 측정 (Meta-Measurement)
Summary
메타 측정은 측정 시스템의 측정이다. 메타 측정은 제어 시스템 고장에서는 측정 시스템이 가장 먼저 분해되는 것 중 하나이기 때문에 중요하다. Meta-measurement is the measurement of the measurement system. Meta-measurement is important because in control system failures, the measurement system is one of the first things to break down.
인식 부족은 제어 시스템 고장을 관찰하는 가장 확실한 방법이다. 품질 위기 동안, 아무도 그들에게 실제로 무슨 일이 일어나고 있는지 모른다. Lack of awareness is the surest way to observe a control system failure. During a quality crisis, nobody knows what's really happening to them.
품질 위기의 소프트웨어 조직은 그 문제의 특수성은 말할 것도 없고, 얼마나 많은 문제를 겪고 있는지에 대한 정확한 정보를 산출할 수 없다. Software organizations in quality crises cannot produce accurate information about how many problems they are experiencing, let alone the specific nature of those problems.
품질 위기의 또 다른 신뢰할 수 있는 메타 측정 증상은 프로젝트 관리 보고서를 갱신하지 않는 것이다. Another reliable meta-measurement symptom of a quality crisis is failure to update the project management reports.
스펙(명세)과 같은 필수 아이템을 무시할 수 없을 때는 단순히 잊어버리는 경우가 많다. 따라서, 당신은 사람들에게 스펙과 같이 그들이 해야 할 일에 필요한 것들을 찾도록 한 다음, 그것들이 어디에 있는지 또는 그것들이 존재하는지 기억하는데 얼마나 오래 걸리는지 관찰함으로써 꽤 쉽게 품질 문제의 수준을 진단할 수 있다. When essential work items such as specifications can't be ignored, they are often simply forgotten. Thus, you can diagnose the level of quality problems quite easily by asking people to find things that they need to do their work—like the specifications—then observing how long it takes to remember where they are, or if they even exist.
우리의 지적 통제 시스템이 무너지고 있을 때, 우리가 찾고 있는 것에 대한 정확한 설명이나 이름조차 줄 수 없다. 그러한 부정확한 언어는 지적 통제의 상실을 말해주는 신호다. When our intellectual control system is breaking down, we cannot even give you an accurate description or name of what we are looking for. Such imprecise language is a tell-tale sign of loss of intellectual control.
위기에 처했을 때 상황을 단순화하는 것이 이치에 맞는다. 우리가 이것을 하는 한 가지 방법은 어려운 사실을 무시하는 것이다. 우리는 문제가 발생하는대로 처리하지 않고, 다른 사람이 문제를 처리할 수 있도록 기록하지 못하며, 최악의 경우 의도적으로 문제를 기록하지 못한다. When we're in crisis, it makes sense to simplify the situation. One way we do this is by trying to ignore difficult facts. We don't handle problems as they arise, we fail to record problems so that others can handle them, and in the worst case, we intentionally fail to record problems.
성공적인 제어 시스템은 제어되는 시스템의 동작에 대한 정보 뿐만 아니라 그 성능을 측정하기 위해 어떤 표준을 사용하는지에 대한 외부 정보도 가지고 있어야 한다. 따라서 외부 성능 표준에 대한 지식 부족은 우리가 품질 문제에 처해 있다는 확실한 신호다. A successful control system must not only have information on the behavior of the system being controlled, but also external information about what standards are to be used for measuring that performance. Lack of knowledge of external standards of performance is thus a sure sign we're in quality trouble.
문제가 있는 조직은 전반적인 성과에 대한 표준을 가지고 있지 않지만, 적어도 현재의 작품, 즉 사양에 대한 표준을 가지고 있어야 한다. 우리 조직이 심각한 품질 문제를 겪고 있을 때 규격을 포기하는 것은 유혹적인 "해결책"이다. The troubled organization doesn't have standards of overall performance, but at least it should have standards for the present piece of work—in other words, specifications. Letting go of specifications is a tempting "solution" when our organization is experiencing serious quality problems.
서면 명세서는 명세서를 충족시키는 척하려는 조직에 위험하기 때문에, 문서화되지 않은 구두계약에 대한 많은 언급을 듣게 된다. Written specifications are a danger to the organization that's trying to pretend that they're meeting specifications, so you hear many references to undocumented verbal agreements.
우리 조직이 문제에 잠겼을 때도 한 발짝 물러서서 우리 자신을 살펴서 그들이 올바른 일에 그들의 창조성을 적용할 수 있게 한다면 그것은 회복될 수 있다. Even when our organization is submerged in problems, it can recover if we are able to step back and get a look at ourselves so they can apply their creativity to the right things.
때때로 우리는 우리가 무슨 일이 일어나고 있는지 파악하고 있다고 믿지만, 실제로 확인하기에는 너무 과부화되어 있다. 우리가 결국 틀렸다는 것이 밝혀졌을 때 우리의 지나친 자신감은 훨씬 더 큰 문제를 일으킬 수 있다. 우리의 인상적인 많은 "측정"들은 사실 우리의 의사소통 패턴을 제대로 파악하지 못하게 하는 연기 스크린이다. Sometimes we believe we have a grip on what's happening, but are too overloaded to actually check. Our overconfidence can cause even more trouble when we're eventually proved wrong. Many of our impressive "measurements" are actually a smoke screen that keeps us from getting a true picture of our communication patterns.
다른 연기 스크린은 의사-리뷰다. 우리의 기술적 검토가 의사-검토가 되었다는 어떤 징후도 적색 깃발을 불러올 것이다. Other smoke screens are pseudo-reviews. Any indication that our technical reviews have become pseudo-reviews should raise a red flag.
상황이 충분히 나빠지면, 우리는 상황을 통제할 수 있도록 돕기 위해 통신선을 끊기 시작한다. 그러나 이 절단은 결국 모든 선이 절단되는 자기 보강 피드백 역동성을 만들어냄으로써 상황을 악화시킨다. 일부 통신회선이 폐쇄되기 시작하면 개방된 상태로 남아있는 통신회선은 품질이 저하될 수 있다. When things grow bad enough, we start cutting communication lines to help us keep things within our control. This cutting, however, worsens the situation by creating a self-reinforcing feedback dynamic in which all lines are eventually cut. When some communication lines start to shut down, those lines that do remain open may deteriorate in quality.
우리의 의사소통 채널은 우리가 서로 문제에 대해 직접적으로 이야기하지 않거나 할 수 없을 때 악화되지만 침묵하거나 험담하거나 소문을 퍼뜨리거나 간접적으로 행동한다. Our communication channels deteriorate when we don't or can't talk directly to one another about problems, but remain silent, gossip, pass rumors, or act indirectly.
중복작업은 품질위기의 전형이다. 우리는 종종 치수를 복제하거나, 치수를 더 좋게 보이려고 하거나, 우리 자신의 기분을 좋게 하기 위해 치수를 목제한다. Duplicated work is typical of the quality crisis. We often duplicate measurements, to try to make them look better, or to make ourselves feel better.
점점 더 많은 회의들이 점점 더 적게 성취한다. 무엇이든 알아낼 수 있는 유일한 방법이 회의에 참석하는 것이라고 느낄 때 회의는 더 커지기 때문에, 우리는 그 상황에서 우리가 할 수 있는 최선의 일을 하기 위해 노력해야 한다. More and more meetings accomplish less and less. Meetings grow larger when we feel that the only way to find out anything is to be at a meeting, so we have to go in an attempt to do the best job we can, under the circumstances.
우리는 종종 동료들로부터 자신을 고립시킴으로써 과부하를 줄이려고 노력한다. 고립이 육체적이든 감정적이든, 우리는 실제로 우리의 가장 큰 원조를 제거함으로써 좋은 일을 할 수 있는 능력을 해친다. We often try to reduce our overload by isolating ourselves from our co-workers. Whether the isolation is physical or emotional, we actually hurt our ability to do a good job by removing our greatest source of assistance.
사태가 정말 나빠지면, 우리는 위기가 얼마나 나쁜지 더 잘 알게 할 수 있는 정보의 출처로부터 우리 자신을 차단할 수도 있따. 어떤 새로운 정보에 대한 즉각적인 반응은 그것을 부인하는 것이다. "사실화된 사실이 없다"고 말한다. 그리고, 종종, 어떤 사실들도 만들어낼 수 없다. If things become really bad, we may cut ourselves off from any source of information that might make us more aware of how bad the crisis really is. The instant reaction to any new piece of information is to deny it, saying there are no substantiating facts. And, frequently, no facts can be produced.
우리 모두는 기꺼이 나쁜 소식을 전달하는 시스템의 일부가 되기 전에 두 번 생각한다. 우리가 유용한 측정값을 산출할 수 있는 정보시스템을 구축하거나 유지하지 않을 때, 우리는 측정 없이 관리하려고 노력해야 하고, 그 결과 위기의 불씨를 부채질해야 한다. All of us think twice before we willingly become part of the system for delivering bad news. When we don't build or maintain information systems that could produce useful measurements, we then have to try to manage without measurements—and as a result fan the flames of crisis.
QSM: Volume 2.2: Responding to Significant Software Events
Contents
Part III. 중요성 (Significance)
Chapter 1: 감정적인 중요성을 측정하기 (Measuring Emotional Significance)
Summary
관찰의 세 번째 단계는 의미를 발견하는 것이다 - 즉, 현실 세계의 복잡성을 우리의 뇌가 다룰 수 있는 크기로 줄일 수 있는 필터를 제공하는 것이다. The third step in observation is discovering significance—providing a filter to reduce the complexity of the real world to a size our brain can handle.
인간은 우리가 받아들이는 데이터에 귀속되는 의미에 대해 어떤 감정적인 반응을 함으로써 반응한다. 그것이 우리가 그 의미의 의의를 아는 방법이다. Human beings respond to the meaning we ascribe to the data we take in by having some emotional reaction. That's how we know the significance of the meaning.
측정 사업에 감정이 들어오면 우리들 중 많은 이들이 길을 잃기 시작한다. 생각이나 감정은 사물을 아는 방식에 따라 다르다. 생각은 과정이지만, 느낌은 직접적이고, 궁극적이며, 아는 경향이 있다. When feelings come into the measurement business, many of us start to get lost. Thoughts and feelings differ in the way you know each thing. Thinking is a process, while feeling tends to be direct, ultimate, knowing.
비록 추리의 과정에 의해 감정이 생긴다는 것을 알지 못하지만, 생각은 감정을 불러일으킬 수 있다. 그리고 나서, 다시, 감정은 생각을 불러일으킬 수 있다. 이 두 과정은 관찰의 세계와 가장 혼란스러운 상호작용의 내부 처리를 특징으로 한다. Although we don't know we have a feeling by a process of reasoning, thoughts can give rise to feelings. And then, in turn, feelings can give rise to thoughts. These two processes characterize the internal processing of the most confusing interactions with the world of observations.
감정을 의식하고, 다른 감정과 구별하는 것은, 당신의 감정, 오직 당신의 감정만이 궁극적으로 어떤 측정의 중요성을 결정하므로, 당신의 관찰로 올바른 일을 하는데 도움을 줄 수 있다. Being aware of a feeling, and differentiating it from other feelings, can help you do the right things with your observations, because your feelings, and only your feelings, ultimately determine the significance of any measurement.
사람들이 소중하게 여긴다고 하는 것이 행동 방식과 일치하지 않을 때도 있다. 그들의 행동이 그들이 가치있다고 말하는 것의 논리적 결과와 일치하지 않을 때, 우리는 그들의 행동을 "비일치적이다"라고 부른다. 비일침적 행동은 사람들이 진정으로 소중하게 여기는 것을 위장하기 때문에 품질의 제 1의 적이다. Sometimes what people say they value doesn't match the way they behave. When their actions don't jibe with the logical consequences of what they say they value, we call their behavior "incongruent." Incongruent behavior is the number one enemy of quality, because it disguises what people truly value.
감정 - 곧 중요성 - 은 종종 미래의 결과의 이미지에 의해 결정된다. 래칫 라인은 만료일로, 만약 놓치면 회복 불가능한 비용이 발생한다. 습관적으로, 래칫 라인을 넘는 것은 지지되는 가치와 행동 사이의 불일치를 보여주는 명백한 예다. Feelings—and thus significance—are often determined by the image of consequences in the future. A ratchet line is a due date that, if missed, will incur non-recoverable costs. Habitually crossing ratchet lines is a clear example of incongruence between espoused values and behavior.
또 다른 강력한 미래 이미지는 만료일을 놓치고 무언가 가치 있는 것을 창조할 기회를 놓치는 이미지다. 우리는 그러한 날짜를 "기회의 라인"이라고 무른다. Another strong future image is the image of missing a due date and losing a chance to create something of value. We call such a date an "opportunity line."
비일치적인 조직이 기회 라인에 접근할 때, 슬립은 "생각할 수 없는" 것이 된다. 정서적 압박감 속에서 사람들은 말 그대로 생각을 멈춘다. When an incongruent organization approaches an opportunity line, a slip become "unthinkable." Under the emotional pressure, the people literally stop thinking.
주관적 영향 방식은 고객에게 중요한 것이 무엇인가라는 질문에 답하는 과정이다. 품질은 객관적으로 측정할 수 있는 것이라는 모든 가식을 포기함으로써 성공한다. The subjective impact method is a process of answering the question of what is significant to the customers. It succeeds by giving up all pretense that quality is something that can be measured objectively.
주관적 영향 방식은 청중들이 새로운 것을 평가하는 기준을 사용한다. 그것은 청중들로부터 중요한 질문들이 무엇인지, 그리고 누가 믿을 수 있는 대답을 가지고 있는지를 알아내므로, 당신은 올바른 질문으로 적합한 사람들을 인터뷰할 수 있다. The subjective impact method uses that audience's criteria for evaluating something new. It finds out from your audience what the significant questions are, and also who has believable answers, so you can interview the right people with the right questions.
Chapter 2: 실제로 일어나기 전에 실패를 측정하기 (Measuring Failures Before They Happen)
Summary
대부분의 조직들이 어느 정도 자기성찰에 착수하는 방아쇠는 실패다. 컴퓨터 사용의 모든 골치 아픈 측면들 중에서, 실패는 대부분의 사람들에게 단연코 가장 짜증나는 것이다. 우리가 실패의 비용을 신중하게 측정했을 때, 우리는 일반적으로 더 신뢰할 수 있는 소프트웨어를 생산함으로써 큰 가치를 더할 수 있다는 것을 발견한다. The trigger for most organizations to embark on some self-examination is failure. Of all the troublesome aspects of using computers, failures are by far the most annoying to the most people. When we measure the cost of failure carefully, we generally find that great value can be added by producing more reliable software.
소프트웨어 고장으로 막대한 손실이 발생한 경우를 많이 인용할 수 있다. 이러한 거대한 손실의 대부분은 보편적인 패턴을 따른다. 일반적인 소프트웨어 엔지니어링 안전장치 없이 운영체제로 신속하게 "다양한" 변경이 이루어진다. 그 변화는 정상적인 운영에 직접 투입된다. 작은 실패는 많은 용도에 곱하여 큰 결과를 낳는다. Many cases can be cited where huge losses resulted from software failures. Most of these huge losses follow a universal pattern. A quick, "trivial" change is made to an operational system, without any of the usual software engineering safeguards. The change is put directly into the normal operations. A small failure is multiplied by many uses, producing a large consequence.
그러한 실패에 대한 경영진의 반응도 패턴을 따른다. 먼저 손실을 줄인 다음 프로그래머를 해고하고, 감독자를 프로그래머로 강등시키고, 지배인을 직원 자리에 앉히고, 상급 관리자들을 손대지 않게 한다. Management reaction to such a failure also follows a pattern. First play down the loss, then fire the programmer, demote the supervisor to programmer, put the manager in a staff position, and leave higher managers untouched.
실패 예방의 제1규칙, "관찰할만한 가치가 없는 것은 없다." 누군가가 어떤 것이 너무 작아서 관찰할 가치가 없다는 생각을 표현하는 것을 들을 때, 항상 살펴봐라. The First Rule of Failure Prevention says, "Nothing is too small to be worth observing." When you hear someone express the idea that something is too small to be worth observing, always take a look.
제2차 실패 방지 규칙인, 제1차 재무관리 원칙은, "X달러의 손실은 항상 재정적 책임이 X달러를 초과하는 임원의 책임"이라고 말한다. 그러므로 소프트웨어 장애에 대한 통제에 대한 책임은 조직의 최고 수준에 있다. The First Principle of Financial Management, which is also the Second Rule of Failure Prevention says, "A loss of X dollars is always the responsibility of an executive whose financial responsibility exceeds X dollars." Thus, the responsibility for controls on software failures rests at the highest levels of the organization.
실패를 관찰할 때는 생각보다 훨씬 늦는다. 실패를 예방하는 방법을 찾는 것이 더 좋지만, 우리 자신의 실패는 우리가 보기 가장 어렵다. 다른 사람의 실패를 통해 배우도록 해라. By the time you observe failures, it's much later than you think. Better to find ways of preventing failures, but our own failures are hardest for us to see. Try learning from the failures of others.
실패는 연약함, 어리석음, 뚱뚱함, 재미, 사기, 광신, (하드웨어의) 실패, 그리고 운명, 이렇게 8F에서 올 수 있다. Failures may come from the following eight F's: frailty, folly, fatuousness, fun, fraud, fanaticism, failure (of hardware), and fate.
실수에 대한 직접적인 관찰은 의미가 없지만, 사람들이 실수에 어떻게 대비하는가에 대한 메타관찰은 의미가 있다. 실패 예방을 위한 절차를 설계하고, 자연의 사실을 인정하고, 절차가 진행되는 것을 보는 것이 관리직이다. The direct observation of a mistake has no significance, but the meta-observation of how people prepare for mistakes does. It's a management job is to design procedures for failure prevention, acknowledging facts of nature and seeing that the procedures are carried out.
실수하지 말라고 애원하거나 협박했다가 나무라는 것은 패턴1과 패턴2 조직의 특징이다. 작동하지 않는다. Imploring or threatening people not to make mistakes, then blaming them if they do, is characteristic of Pattern 1 and Pattern 2 organizations. It doesn't work.
교육, 멘토링, 기술검토 프로그램을 구축하고 지원하는 것이 관리자의 일이다. 만약 이것이 실행되지 않거나 효과적으로 수행되지 않는다면, 당신은 실패의 관리에 대해 상당한 메타관찰을 갖게 될 것이다. It's management's job to establish and support training, mentoring, and technical review programs. If these aren't done, or aren't done effectively, then you have a significant meta-observation about the management of failure.
관리자는 자신이 고용하고 보유하는 사람에 대해서도 책임을 진다. 뚱뚱한 직원을 식별하고 그것에 대해 아무것도 하지 않는 관리자들은 이중으로 뚱뚱하다. Managers are also responsible for whom they hire, and retain. Managers who identify a fatuous employee and don't do anything about it are doubly fatuous.
사람들이 시스템을 가지고 재미를 느끼는 방법의 목록은 끝이 없고 예측할 수 없다. 그래서 재미는 실패의 모든 원천 중에서 가장 위험한 것이다. 단 두 가지 예방책이 있다: 개방적이고 눈에 보이는 시스템과 그 자체로 충분히 재미있는 일. The list of ways people have fun with a system is endless and unpredictable, which is why fun is the most dangerous of all sources of failure. There are only two preventives: open, visible systems and work that is sufficiently fun in and of itself.
사기나 광신도의 위협은 관리자가 체계적인 기술적 검토와 기타 실패 예방 활동을 도입하도록 동기를 부여할 수 있다. The threat of fraud or fanaticism can motivate managers to introduce systematic technical reviews and other failure prevention activities.
하드웨어 고장은 발생하지만, 하드웨어 고장의 원인을 자신의 문제로 돌리는 관리자들은 자신의 관리 능력에 대해 중요한 것을 말하고 있다. Hardware failures happen, but managers who blame hardware failures for their problems are telling you something important about their management ability.
나쁜 관리자는 불운을 믿는다. 관리자가 "불운"에 대해 말하는 것을 들으면, 관리자라는 단어를 "운"으로 대체한다. Bad managers believe in bad luck. When you hear a manager talking about "bad luck," substitute the word "manager" for "luck."
Chapter 3: 정확하게 듣기 (Precision Listening)
Summary
사람들은 자신이 말하는 것을 들을 수 없어서 자신의 부정확한 추리에 귀를 기울일 수 없기 때문에 어리석은 짓을 한다. 정확하게 경청하는 법을 배우면 조직 문화의 평균적인 어리석음을 관찰할 수 있다. People do foolish things because they can't hear themselves talking, so they can't listen to their own imprecise reasoning. By learning to listen with precision, you can observe the average foolishness of an organization's culture.
인과응보의 왜곡은 한 가지가 다른 것을 발생시킨다고 거짓으로 주장한다. 한 가지 형태의 인과 왜곡은 단순한 선형적 사고, 즉 한 가지 원안/한 가지 효과, 그 반대다. "존슨은 이 프로젝트를 늦게 만들었다." A cause-effect distortion falsely claims that one thing makes another happen. One form of cause-effect distortion is simple linear thinking—one cause/one effect, and vice versa. It often takes the form of blaming, as in, "Johnson made this project late."
또 다른 형태의 인과 왜곡은 "존슨이 망치지 않았더라면 우리가 그 일자리를 얻었을텐데"에서처럼 종종 비난의 형태로 왜 그 일이 일어나지 않았는지에 대한 추측이다. Another form of cause-effect distortion is a speculation about why things didn't happen, again, often in the form of blaming, as in, "We would have gotten the job if Johnson hadn't messed up."
전능한 가정에 따르면, 나는 단순히 내가 믿거나 믿지 않는 것에 의해서 다른 사람에게 일이 일어나게 할 힘을 가지고 있다. 아무도 다른 사람에게 어떤 것을 느끼게 할 수 없다. 당신이 사람들에게 어떤 감정을 느끼게 할 수 있다고 믿기 시작할 때, 당신은 명확하게 생각하지 않는다. 당신이 다른 사람들이 당신을 어떤 식으로 느끼게 할 수 있다고 믿기 시작할 때, 당신은 훨씬 더 혼란스러워진다. According to the omnipotence assumption, I have the power, simply by what I believe or don't believe, to make things happen to other people. Nobody can make anybody else feel anything. When you start to believe you can make people feel a certain way, you're not thinking clearly. When you start to believe other people can make you feel a certain way, you're even more muddled.
데이터 질문 - "무엇을 보거나 들은 것이 당신을 그 믿음으로 이끌었는가?" - 전능적 가정, 마음을 읽는 가정 및 기타 인과관계 왜곡을 해소하는 효과적인 방법이다. The Data Question—"What did you see or hear that led you to that belief?"—is an effective way clear up the omnipotence assumption, the mind-reading assumption, and other cause-and-effect distortions.
일반화는 소수의 관찰된 사례에서 다수의 관찰되지 않은 사례로 이성을 부여한다. 일반화는 필수적이지만, 종종 너무 지나치다. 보통, 그러한 과잉 일반화는 "전부", "모든", "모두", "항상", "절대로", "아무도", 또는 "아무것도"와 같은 보편적인 양자들에 의해 언어로 표현된다. Generalizations reason from a few observed cases to a large number of unobserved cases. Generalizations are essential, but are often carried too far. Usually, such over-generalizations are represented in speech by universal quantifiers, such as "all," "every," "everybody," "always," "never," "nobody," or "none."
일반화를 취소하기 위한 첫 번째 단계는 내포된 일반화를 세부사항으로 대체하는 것이다. 다음 단계는 데이터 질문을 적용하는 것이다. The first step for undoing generalizations is to replace the implied generalizations with specifics. The next step is to apply the Data Question.
또 다른 왜곡 범주는 "반드시", "필수", "해야 한다"의 사용에서와 같이 일반화와 인과관계를 결합한다. 이러한 일반화의 진실이나 거짓을 발견하는 방법은 끊임없이 "왜?"를 묻고 데이터 질문을 적용하는 것이다. Another distortion category combines generalization with cause and effect, as in the use of "must," "should," "have to," or "ought to." The way to discover the truth or falsity of these generalizations is to endlessly ask "Why?" and also to apply the Data Question.
가치관은 종종 허공에서 끌어낸다 - 의견 제시자가 없는 의견. 가치 평가의 숨겨진 원천을 다루는 방법은 "누구?"를 계속 물어봄으로써 그 사람에게 의견을 돌려주는 것이다. Values are often pulled out of the air—opinions without an opinionator. The way to deal with hidden sources of valuation is to bring opinions back to the person by continuing to ask, "Who?"
삭제는 말씨에서 흔히 볼 수 있고 유용한 속기이지만, 혼란스러운 사고를 초래할 수 있다. 삭제에는 다음이 포함된다. Deletions are a common and useful shorthand in speech, but can lead to confused thinking. Deletions include
명목화 (활동 집합을 하나의 보편적 명사로 구분) nominalization (converting a set of activities into a single universal noun)
참조지수 부족 (사람, 장소 또는 사물은 문장에서 제외) lack of referential index (people, places, or things are left out of a sentence)
지정되지 않은 명사 또는 동사 (특정하게 들리지만 어떤 의미라도 가질 수 있는 단어) unspecified nouns or verbs (words that sound specific but could mean anything)
구문 삭제 (누락된 문장의 삭제, 바로가기) syntactic deletions (portions of sentences that are omitted, as a shortcut)
모든 삭제를 명확히 하는 방법은 당사자에게 구체적인 내용을 요구하는 것이다. The way to clarify all deletions is to ask the person to get specific.
모든 실패가 고객의 눈에 같은 (부정적인) 가치를 갖는 것은 아니다. 더구나 같은 실패는 눈마다 다른 가치관을 가질 수 있다. 사람들의 말을 주의 깊게 듣는 것은 그들이 잠재적 실패에 어떤 중요성을 부여하는지 아는데 도움이 될 것이다. 만약 그들이 낮은 의미를 갖는다면, 그들은 적절한 예방조치를 취할 것 같지 않다. Not all failures have equal (negative) value in the customer's eyes. Moreover, the same failure can have different values in different eyes. Listening carefully to people will help you know what significance they place on potential failures. If they place low significance, then they're unlikely to take proper precautions.
사람들이 잠재적 오류 (예상 비용, 실패에 부수되는 개인적 중요성, 실패 확률과 그 결과에 대한 주관적 평가, 그리고 개인적 통제의식)를 방지하기 위해 조치를 취하는지 여부를 결정하는 몇 가지 요인은 있다. Several factors determine whether people take action to prevent a potential error—expected cost , the personal significance attached to failure, subjective evaluation of the probability of a failure and its consequences, and the sense of personal control.
귀 기울이는 법을 배우면 사람들이 시스템, 조직, 마술, 작품의 특정 부분을 건너뛰는 이유 등 수십 가지 방법으로 위기를 예측하는 소리를 들을 수 있다. 아마도 무엇보다도, 당신은 실제적인 불안감을 감추려는 시도의 확실한 신호인 잘못된 낙관주의의 허세를 들을 수 있을 것이다. If you learn to listen, you can hear people predicting a crisis in dozens of ways—how they talk about the system, about the organization, about magic, and about reasons for skipping certain parts of the work. Perhaps most of all, you can listen for the bravado of false optimism, a sure sign of an attempt to cover real feelings of insecurity.
Part IV: 반응 (Response)
Chapter 4: 관찰을 행동으로 번역하기 (Translating Observation Into Action)
Summary
중요한 것은 관찰이 아니라 관찰에 대한 반응이다. 많은 모델들이 관찰과 측정에 대해 이야기한다. SatirInteractionModel은 반응이 사건과 어떻게 연결되는지 보여주는데 있어 독특하다. It's not the observation that counts, it's the response to the observation. Many models talk about observation and measurement. The Satir Interaction Model is unique in showing how responses are connected to events.
생각이 생각을 촉발시킬 수 있듯이, 생각은 감정을 촉발시킬 수 있고, 감정은 생각을 촉발시킬 수 있으며, 감정은 다른 감정을 촉발시킬 수 있다. 내 느낌은 그 순간의 내 전반적인 자기 가치관에 달려 있다. Just as thoughts can trigger thoughts, thoughts can trigger feelings, and feelings can trigger thoughts, so can feelings trigger other feelings. My feeling-about-the-feeling depends on my general sense of self-worth at that moment.
감정에 대한 강한 감정은 인생에서 일찍 획득한 어떤 생존 규칙과 관련이 있다. 대부분 작은 관찰 하나하나가 내 생존을 위협한다고 느끼지 않는다. 만약 내가 한다면, 이건 당신이 나에 대해 말할 수 있는 중요한 메타관찰이다. Strong feelings about feelings are related to some survival rule acquired early in life. Most of the time, I don't feel that my survival is threatened by every little observation. If I do, then this is an important meta-observation that you can make about me.
대부분의 경우인 나의 생존이 위협받지 않을 때, 나는 논리적인 대응을 간단하게 준비하는데, 이것은 통상적으로 어떤 방어적인 대응보다 해석하기 쉽다. When my survival isn't threatened, which is most of the time, I simply prepare a logical response, which is usually easier to interpret than some defensive response.
감정을 숨기려 할 때 사용하는 방어적인 반응이 아주 많다. 나는 문제를 다른 곳에 투영하거나, 주의를 산만하게 할 수도 있다. 나는 내가 정말로 그런 감정을 가지고 있다는 것을 부정할 수도 있고, 내 관찰을 왜곡할 수도 있다. There are a great many defensive responses that I use when I attempt to hide my feelings. I may project the problem somewhere else, or create a distraction. I may deny that I really having that feeling, or distort my observations.
"생존" 반응은 사상의 부정확함을 초래하고, 사상의 부정확함은 품질을 파괴한다. 그렇기 때문에 소프트웨어 엔지니어링 관리자는 개인이나 조직 전체의 감정 상태를 측정할 수 있어야 한다. "Survival" responses lead to imprecision in thought; imprecision in thought destroys quality. That's why software engineering managers must be able to measure the emotional state of a person or of their entire organization.
우리는 어떤 사람이 다른 시간에, 다른 사람들과 다른 상황에 있는 것처럼 반응할 때 "비일치적" 대응이라고 말한다. 비일치적 반응은 문제 해결에 기여하지 않는다.방어적인 반응을 관찰함으로써 관찰 시스템이 실패하는 것을 관찰할 수 있다. We say that a response is "incongruent" when someone responds as if they were in a different situation, with different people, at a different time. Incongruent responses don't contribute to problem-solving. By watching the defensive responses, you can observe the observation system failing.
문제는 아무것도 아니다. 그 문제에 대처하는 것이 모든 것이다. The problem is nothing. The coping with the problem is everything.
사람들은 다양한 방법으로 그들의 말을 검열한다. 우리는 검열관을 이용하여 실제로 말한 것 뒤에 숨겨진 의미를 훨씬 더 많이 발견할 수 있다. 사람들은 명시적으로나 무의식적으로 은폐하고 있는지도 모른다. People censor what they say in a variety of ways. We can use the censoring to discover far more hidden meanings behind what is actually said. The people may be covering up explicitly or unconsciously.
코멘트의 규칙은 특별한 종류의 생존 규칙으로, 내 입에서 나오는 것을 지켜 "위험한" 말은 하지 않는다. A rule for commenting is a special kind of survival rule, one that guards what comes out of my mouth so I don't say anything "dangerous."
비언어적 반응은 두 부류로 나뉜다, 통제 가능한 것과 통제 불가능한 것이다. 이 두 가지를 나의 언어적 반응과 결합하면 결과가 나온다. 즉 내가 받아들이는 ㅁ것에 대한 반응으로 말하고 하는 것이다. Non-verbal responses fall into two categories, controllable and uncontrollable. Combining these two with my verbal response gives the outcome—what I say and do in response to what I take in.
상호작용 과정은 복잡하지만, 상호작용 모델의 도움으로 우리가 보고 듣는 것을 풀 수 있어, 사람들에게 실제로 일어나고 있는 일의 유용한 측정치로 바꿀 수 있다. The interaction process is complex, but with the help of the Interaction Model, we can unravel what we see and hear, transforming it into useful measurements of what's really happening with people.
스트레스에 대처할 수 있는 부조리한 방법 중 하나는 내적 반응을 내적으로 유도하고, 다시 내 자신의 수용으로 되돌아가고, 루프에 갇히게 됨으로써 생기는 "래칭"이다. One of the incongruent ways that I can cope with stress is "ratcheting," which is caused by directing my response internally, back to my own intake, and becoming locked in a loop.
Chapter 5: 동감적인 위치에서의 관찰들 (Observations from the Empathic Position)
Summary
위기상황에서 가장 효과적인 개입 중 하나는 다른 관점에서 취해진 정보를 제공하는 것이다. 관찰자 역할을 할 때마다 "self" 위치, other" 위치, "context" 위치를 선택할 수 있다. One of the most effective interventions in a crisis is to provide information taken from a different point of view. Whenever you act as observer, you have a choice of the "self" position, the "other" position, or the "context" position.
내가 비일치적일 때, 나는 한 명의 관찰자 자리에만 몸을 가두는 경향이 있다. 이것은 나를 비난하고, 달래고, 지나치게 합리적이거나, 무관한 행동으로 이끌지도 모른다. When I'm being incongruent, I tend to lock myself into one and only one observer position. This may lead me to blaming, placating, superreasonable, or irrelevant behavior.
인류학 현장학은 공감적 관찰의 원형이다. 어떤 인류학자들은 숙주 문화에 너무 몰입해서 "원래로 간다." (어떤 소프트웨어 컨설턴트도 같은 일을 한다.) Anthropological fieldwork is the archetype of empathic observation. Some anthropologists become so immersed in their host cultures that they "go native." (Some software consultants do the same thing.)
조사(survey) 위치는 사회학의 위치로서, 인류학자의 참여자 관찰 위치와 대비되는 외부 관찰자 위치다. 조사 위치는 많은 데이터를 관리 가능한 형태로 압축하지만, 중요한 세부 정보를 잃을 수 있다. The survey position is the position of sociology, an outside observer position as contrasted with the participant observation position of the anthropologist. The survey position compresses a great deal of data into manageable form, but may lose crucial detail.
숙련된 참가자 관찰자는 각 개인의 데이터에 접근하는 방법, 특히 다른 기법 중, "에믹 인터뷰"를 사용하여, 즉 상대방을 "내부화"시키는 방법을 알고 있다. The skilled participant observer knows how to access the data in each individual using, among other techniques, "emic interviewing"—a way of getting "inside" the other person.
에믹 인터뷰는 데이터 수집 이상의 것이다. 그것은 항상 정보를 주는 사람과 종종 수신자를 변화시킨다. Emic interviewing is more than data gathering. It always changes the person who gives information—and often the receiver as well.
에믹 인터뷰는 조사 데이터와 연계하여 표 뒤에 숨은 의미와 중요성을 잘 파악할 수 있다. Emic interviewing can be used nicely in conjunction with survey data to uncover the meaning and significance behind the tabulations.
숙련된 관찰자는 루머 방앗간에서, 루머 방앗간을 가동하지 못하게 하는 방법에 관한 정보를 포함하여, 유용한 정보를 추출할 수 있다. 루머 방앗간은 그들의 루머를 체크아웃으로부터 보호하는 "봉투"에 싸서 보존한다. Skilled observers can extract useful information from the rumor mill, including information about how to put the rumor mill out of operation. Rumor mills preserve themselves by enclosing their rumors in "envelopes" that protect them from being checked out.
공감하는 입장은 퍼즐링 관찰을 이해하는 강력한 도구다. 예를 들어 다음과 같은 휴리스틱을 적용할 수 있다. 누군가가 "미친척" 행동을 할 때, 공감하는 위치로 가서 미친척의 논리적인 이유를 찾아라. The empathic position is a powerful tool for understanding puzzling observations. For instance, you can apply this heuristic: When somebody is acting "crazy," go to the empathic position and find a logical reason for the craziness.
삼각 상호작용(또는 삼자 상호작용)은 상호작용과 관찰이 모두 있는 첫 번째 그룹이기 때문에 관찰에 특별한 의미를 갖는다. 상호작용에 대한 관찰은 그것이 우리가 프로세스를 개선하기 위한 피드백을 얻는 방법이기 때문에 중요하다. 조직이 패턴1 또는 패턴2에서 패턴3으로 이동함에 따라, 관리 도구들 사이에서 적절한 위치를 고려하여 상호 작용에 대한 이러한 관찰을 보기 시작한다. The triad—or three-party interaction—has special significance for observation, because it is the first grouping in which there is both interaction and observation of interaction. Observation of interaction is important because that's how we get the feedback to improve processes. As an organization moves from Pattern 1 or 2 to Pattern 3, we begin to see this observation of interaction given its proper place among the management tools.
상호작용의 관찰이 직접, 또는 정기적으로 피드백되지 않을 때, 우리는 그 조직이 "가십"에 빠져 있음을 발견할 수 있다. 공감하는 입장은 가십과 그것의 해로운 영향을 다루는데 도움을 줄 수 있다. When observation of interaction is not fed back directly, or regularly, we may find the organization enmeshed in "gossip." The empathic position can help you deal with gossip and its damaging effects.
사람들이 말하지 않는 것이 그들이 하는 말보다 더 중요한 경우가 많으며, 그 역시 공감하는 입장에서 가장 잘 이해할 수 있다. 공감하는 입장은 부조리를 발견하는데 특히 유용하다. What people don't talk about is often more important than what they do talk about, and that too can be understood best from the empathic position. The empathic position is especially useful for spotting incongruity.
공감하는 입장에서 자신도 모르게 관찰하는 사람이 많다. 그들은 그들이 정말로 다른 사람들의 감정에 공감할 때, 종종 전체 조직과 공감할 때, 뭔가를 느끼고 있다고 믿는다. 이 능력은 강력한 측정 도구를 제공할 수 있다. Many people observe from the empathic position without realizing it. They believe that they are feeling something, when they are really empathizing with the feelings of other people—often with the entire organization. This ability can provide a powerful measurement tool.
Chapter 6: 실패의 무리들을 다루기 (Dealing With Swarms of Failures)
Summary
많은 패턴2 조직들은 실패의 무리에 시달려 장기간의 상황을 개선하려는 시도는 순간의 비상사태에 의해 오락가락한다. 군집 탈출에 필요한 정보를 얻으려면 패턴2 관리자가 상황별 위치에서 관찰할 수 있는 방법이 필요하다. Many Pattern 2 organizations are so plagued with swarms of failures that attempts to improve the long-term situation are diverted by the emergencies of the moment. To get information to start escaping the swarms, Pattern 2 managers need ways to observe from the context position.
오류의 떼를 제어하는 것은 정확한 언어로부터 시작된다. 실패(증상)와 결함(질병)을 구분하는 것이 득이 된다. 실패는 "프로그램 운용의 외부 결과가 요건에서 벗어나는 것"이다. 결함은 "특정 조건에서 실행될 때 고장을 일으키는 프로그램의 결함"이다. Getting control of swarms of errors starts with precise language. It pays to distinguish between failures (the symptoms) and faults (the diseases). A failure "is the departure of the external results of program operation from requirements." A fault "is the defect in the program that, when executed under particular conditions, causes a failure."
- 보관해야 할 첫 번째 필수 통계는 시스템 문제 사고에 대한 STIs (System Trouble Incidents)라고 불리는 실패의 데이터베이스이다. 두 번째 필수 통계량은 시스템 결함 분석을 위한 SFAs(System Fault Analysis)라고 불리는 결함의 데이터베이스이다. The first essential statistic to keep is a database of failures, called STIs, for System Trouble Incidents. The second essential statistic is a database of faults, called SFAs, for System Fault Analysis.
통계에 주의해야 구별할 수 있다 We must be careful in our statistics to distinguish
원점: 우리 프로세스의 어느 단계에서 결함이 발생했는가 origin: at what stage in our process the fault originated
해결: 결함을 수리하기 위해 시스템의 어떤 부분을 변경할지 resolution: what part(s) of the system will be changed to remedy the fault
STI를 분류하기 위한 심각도 코드는 분석에서 어떤 의미를 만들어낼 수 있는 SFA에 넣는 경우에 유용할 수 있다. 또 다른 가능성은 고객에게 가치(예를 들어 돈)를 기준으로 심각도 코드를 설정하는 것이다. Severity codes for classifying the STIs can be useful if they are put in SFAs, where the analysis may create some meaning. Another possibility is to base severity codes on value (e.g., money) to the customers.
오류 처리를 감지, 위치(격리 또는 추적이라고도 함), 해결, 예방의 네 가지 활동으로 나눌 수 있다. 각자 자기만의 역동성을 가지고 있다. We can divide error-handling into four activities—detection, location (sometimes called isolation or tracing), resolution, and prevention. Each has its own dynamic.
소프트웨어 개발 조직에서의 오류 작업의 대부분은 실제로 예방 작업이지만, 사람들은 종종 오류를 예방하기 위해 대부분의 활동을 하는 것을 볼 수 있는 관점이 부족하다. Most of the error work in a software development organization is actually prevention work, though the people often lack the perspective to see that most of their activities are in place to prevent error.
어떤 조직이든 문화 패턴의 가장 민감한 척도 중 하나는 얼마나 빨리 문제를 찾아내고 제거하는가 하는 것이다. 고장 위치 파악 및 해결에는 네 가지 주요 요인이 있다: One of the most sensitive measures of the cultural pattern of any organization is how quickly it finds and removes problems. There are four major factors in the time to locate and resolve faults:
STI 순환 횟수 the number of circulating STIs
가장 쉬운 문제를 먼저 고쳐서 선택하는 것 selection by fixing the easiest problems first
고장 해결을 위한 지속적인 변경으로 유지 보수성 상실 loss of maintainability with continued changing to resolve faults
기존 고장을 해결하는 동안 새로운 결함 도입 introduction of new faults while resolving the old
효과적인 관리자들은 STI가 몇 개나 정리됐는지에는 별로 관심이 없고, 정리할 것이 얼마나 남았는지에 관심이 있다. 불행히도 프로젝트 매니저는 제품에 얼마나 많은 결함이 남아 있는지 측정할 방법이 없을 것이다. 단, 얼마ㅏ 많은 STI를 생산할지는 말할 것도 없다. Effective managers are not really interested in how many STIs have been cleared up, but how many remain to be cleared up. Unfortunately, a project manager would have no way to measure directly how many faults remain in a product, let alone how many STIs they would produce.
고장 제거의 둔화가 프로젝트 시간을 과소평가하는 주요 원인이다. STI가 많을 때는 이같은 둔화가 막바지에 이른 데서 오는 것이 아니며, 곧 완료될 것으로 예측하는 데도 사용할 수 없다. 어설픈 관리자들은 어쨌든 그것을 사용한다. The slowdown of fault removal is a major reason why project times are underestimated. When there are large numbers of STIs, this slowdown doesn't result from nearing the end, and cannot be used to predict an imminent completion. Poor managers use it anyway.
위의 네 가지 비선형 요인에 의해 속도가 느려진다. 그들의 행동이 합리적이고 경제적이 되려면 관리자들은 그들의 환상을 버리고 어떤 요소가 과정을 늦추는데 가장 중요한지를 발견해야 한다. The slowdown results from the four nonlinear factors listed above. For their actions to be sensible and economical, managers must shed their illusions and discover which factor is most important in slowing the process.
STI 순환 시간을 밝히기 위한 한 가지 핵심 측정은 STI를 수령하는 시간과 최종 해결자가 이를 수령하는 시간 사이의 시간이며, 이를 "복제 위치 시간" 또는 RLT라고 부를 수 있다. 또 다른 척도는 STI를 제거하는 평균 시간이다. One key measurement to reveal STI circulation time is the time between receipt of an STI and the time the eventual solver receives it, which we may call the "resolver location time," or RLT. Another measure is the average time to remove an STI.
측정은 네 가지 핵심 요인을 분리하는 데 도움이 될 수 있다. 순환 STI는 STI가 최종 해결사에 도달하는 데 걸리는 시간을 표로 작성함으로써 탐지할 수 있다. Measurements can help to keep the four key factors separate. Circulating STIs can be detected by tabulating the time it takes for an STI to reach its eventual solver.
가장 쉬운 문제를 먼저 고쳐서 선택하는 것은 각각의 문제를 고치는 시간을 표시한 후에 그 문제를 고치는 방법을 찾아낼 수 있다. Selection by fixing the easiest problems first can be detected by plotting the time to fix each problem, after it has been located.
과거 결함을 해결하는 동안 새로운 결함의 도입은 "수정된 결함에 대해 코드가 생성된 날짜"의 히스토그램을 표시함으로써 감지할 수 있다. Introduction of new faults while resolving the old can be detected by plotting a histogram of the "date the code was created for faults that were corrected."
지속적인 고정을 통한 유지관리성 상실은 해결 시간 대 변경된 코드 라인 수 대 변경된 코드 라인당 평균 시간으로 표시하여 측정할 수 있다. 또한 각 변경에 영향을 받는 모듈의 평균 개수를 기준으로 변경사항의 평균 크기를 측정할 수 있다. Loss of maintainability with continued fixing can be measured by the time to resolve versus the number of lines of code changed, plotted as the average time per line of code changed. We can also measure the average size of changes, in terms of the average number of modules affected by each change.
그 난이도가 (일반적으로 더 어려운) 제도의 악화에서 오는 것인지, 선택 효과에서 오는 것인지는 알 수 없다. 다른 많은 간단한 측정도 가능하며, 각 조직들은 그들 자신의 실패의 무리와 싸우는데 무엇이 효과가 있는지 선택해야 할 것이다. It can be hard to know whether the difficulty is coming from the deterioration of the system (generally harder to work with) or selection effects (fewer, but more difficult, errors). Many other simple measurements are possible, and each organization will have to choose what works for them in combatting their own swarms of failures.
Part V: 0차원 측정 (Zeroth-Order Measurement)
Chapter 7: 측정 가능한 작업들로 이루어진 프로젝트들 (Projects Composed of Measurable Tasks)
Summary
0차원 측정은 고품질 소프트웨어의 품질 관리를 위한 확실한 경로에서 당신을 시작하는데 필요한 최소 활동 세트다. 그것들은 다른 측정 시스템이 구축되어야 하는 기초를 형성한다. 이 베이스가 없다면 대부분의 다른 측정은 무의미하거나 오해의 소지가 있을 것이다. Zeroth-order measurements are the minimum set of activities you need to start you on a sure path to quality management of quality software. They form the base on which any other measurement system must be built. Without this base, most other measurements will be meaningless or misleading.
0차원 측정의 기본은 These basics of zeroth-order measurement are
측정 가능한 과제의 프로젝트를 구성하여 양질의 제품을 생산하는 방법에 대한 지식 knowledge of how to compose a project of measurable tasks to produce a quality product
프로젝트의 품질에 대한 진행에 대한 공공의 관점을 만들고 유지하는 시스템 a system of creating and maintaining a public view of progress on the project's quality
품질에 대한 우리의 의미를 문서화하는 요구사항의 시스템 a system of requirements that document what we mean by quality
품질을 향한 진행의 모든 부분을 측정하기 위한 일관된 검토 시스템 a consistent system of reviews to measure every part of the progress towards quality
소프트웨어 측정을 시작하기 가장 좋은 시기는 다른 것을 하기 전이다. 측정은 초기 계획에 포함되어야 하며 계획이 변경될 때 유지되어야 한다. 효과적인 측정은 사후 고려로서 "덧칠할" 수 없지만, 반드시 설계되어야 한다. The best time to start measuring software is before you do anything else. Measurement must be built into the initial plan and maintained as the plan changes. Effective measurement cannot be "painted on" as an afterthought, but must be designed.
어떤 종류의 노력이라도 관찰하는데 있어 필수적인 첫 단계는 그것을 측정 가능한 프로젝트로 바꾸는 것이다. 이것은 어떤 종류의 작업으로도 할 수 있다. The essential first step in observing any kind of effort is to transform it into a measurable project. This can be done with any kind of task.
프로젝트는 변화를 이루기 위한 노력이다. 그런 변화는 인식이나 욕망, 현실에 힘써서 이루어질 수 있다. A project is an effort directed towards accomplishing some change. Such a change can be accomplished by working on perceptions, desires, or realities.
측정 가능한 프로젝트를 계획하기 위한 하나의 접근방식은 다음과 같은 단계로 구성된다: One approach to planning for a measurable project consists of these steps:
반복주기 프로세스를 준비한다. Prepare for an iterative process.
고객이 누구인지 파악한다. Establish who the customers are.
무엇이 보존되어야 하는가? What should be preserved?
목표를 선택한다. Select a goal
측정 가능한 방법으로 목표를 진술하라. State the goal in an measurable way.
과하게 프로젝트를 구속하지 않는 방식으로 목표를 진술한다. State the goal in a way that does not overly constrain the project.
장애물이 없는지 확인한다. Check for obstacles.
자원을 확인한다. Check for resources.
계획을 시작하라. 거꾸로. Start to plan, backward.
목표 진술은 다양한 시험을 거쳐야 한다. 그들은 무엇을 원하는지에 관한 것이지 원하지 않는 것에 관한 것이 아니다. 가용 자원으로 달성할 수 있는 방식으로 이들을 구성한다. "당신의 목표가 달성되었다는 것을 확인할 수 있는 어떤 것을 보고 느낄 것인가?"라는 질문으로 그들을 확인한다. 또한 각 단어의 의미 범위를 탐색하여 확인하라. Goal statements should be subjected to a variety of tests. They should be in terms of what is wanted, not in terms of what is not wanted. Frame them in ways that are achievable with available resources. Check them with the question, "What will you see, hear, or feel that will confirm that your goal has been achieved?" Also check by exploring the range of meaning of each word.
어떤 계획이라도 계획 - 미래가 어떻게 될 것인가에 대한 일련의 추측 - 일 뿐이다. 당신의 일련의 예측에는 잘못될 수 있는 많은 것들이 있다. 따라서 점진적인 목표 측면에서 큰 프로젝트를 계획하는 것이 현명하다. 각 목표에 도달하거나 근사치를 계산한 후에, 프로젝트는 재계획된다. Any plan is just a plan—a series of guesses about how the future will work out. There are many things that can go wrong in your series of predictions. Therefore, it is wise to plan big projects in terms of incremental goals. After each goal is reached or approximated, the project is replanned.
Chapter 8: 계획들과 진척에 대해 커뮤니케이션하기 (Communicating About Plans and Progress)
Summary
프로젝트의 각 부분이 잠재적으로 측정할 수 있다고 해서 실제로 측정되거나 측정치가 적시에 적절한 사람에게 도달하는 것은 아니다. Just because each part of a project is potentially measurable doesn't mean it will actually be measured, or that the measurements will reach the right people at the right time.
사람들이 전체 프로젝트와 그들의 작업이 어떻게 연관되어 있는지 파악하지 못할 때, 그들은 제품의 질을 떨어뜨리거나 심지어 프로젝트의 완성을 위협하는 일을 할 것이 확실하다. 그러므로 계획은 의사소통할 수 있는 동시에 의사소통할 수 있는 역할을 가진 모든 사람이 이해할 수 있어야 한다. When people lack a grasp of the entire project and how their work relates to it, they're sure to do something that unknowingly undermines the quality of the product, or even threatens the very completion of the project. Therefore, a plan must be understandable to everyone who has a part in it—both communicable and communicated.
향상된 의사소통 체계는 인간 조직에서의 의사소통에 관한 몇 가지 기본적인 규칙의 이해에 달려 있다: An improved communication system rests on an understanding of some basic rules about communication in human organizations:
아무리 좁은 채널이라도 사람들 사이에는 항상 소통이 있다. There's always communication among people, even with the narrowest channel.
비밀 통신 채널은 항상 발전한다. Secret communication channels always develop.
항상 미스 커뮤니케이션이 존재한다. There's always miscommunication.
의사소통은 항상 당신이 생각하는 것보다 어렵다. Communication is always harder than you think it's going to be.
한 곳에서 의사소통을 개선하면 다른 곳에서는 더 어려워질 것이다. Improving communication in one place will make it harder in another place.
0차원 측정 시스템을 위해서는 조직이 개방되어야 한다. 조직이 많이 열리면 열릴수록 두 번째 조건인 정직에 맞추기 쉽다. 세 번째 조건은 사람들이 다른 사람들로부터 배우는 것이다. For a zeroth-order measurement system, the organization must be open. The more open an organization, the easier it is to meet the second condition: honesty. The third condition is people learning from other people.
첫번째 0차원 주문 측정 도구는 계획 상태를 달성하기 위해 어떤 작업을 수행해야 하는지, 그리고 지금까지 어떤 진척이 이루어졌는지를 보여주는 인과관계 다이어그램 형식의 공공 프로젝트 진행률 포스터(PPPP: Public Project Progress Poster)이다. The first zeroth-order measurement tool is the Public Project Progress Poster, which is a form of cause-and-effect diagram showing what tasks must be accomplished to achieve the planned states, and what progress has been made so far.
PPPP는 업무 뿐만 아니라 업무 산출물을 측정하는 역할을 하는 검토를 보여주는 표준 업무 단위로 구성된다. 또한 검토를 위한 측정 기준이 되는 요건을 포함한 전제조건이 포함되어 있다. The PPPP is built of standard task units, which show not only the task, but the review that serves to measure the product of the task. It also includes the prerequisites, including the requirements that serve as the standard of measurement for the review.
마지막에 검토하지 않으면 과제는 제품을 생산하는 것이 아니라 제품 후보자에게만 생산된다. 지원자는 검토에 의해 제품이 측정될 때까지만 제품이 되며, 그러한 측정은 요구 사항에 비해 유리하다. Without the review at the end the task doesn't produce a product, but only a product candidate. A candidate only becomes a product until it has been measured by a review and those measurements compared favorably to the requirements.
프로젝트 포스터를 게시하면 모든 사람이 보고 이해할 수 있는 성취해야 할 것을 시각화한 공공 프로젝트 포스터가 된다. 주간 업데이트는 Public Project Poster를 Public Project Progress Poster로 변환한다. Posting the Project Poster makes it a Public Project Poster—a visualization of what is to be accomplished that all can see and understand. Weekly updating converts the Public Project Poster into a Public Project Progress Poster.
포스터에는 오늘의 날짜를 나타내는 타임 라인이 배치되어 있어, 모든 사람이 어떤 작업이 예정대로 진행되고 있는지, 어떤 것은 그렇지 않은지 알 수 있다. A time line is placed on the Poster to represent today's date, so everyone can see which tasks are on schedule, and which are not.
포스터를 통과하면 누구나 작업 단위의 품질과 상태를 즉시 알아볼 수 있다. 시간선 왼쪽은 과거 시간을 나타내기 때문에 아무것도 바꿀 수 없다. 그 프로젝트를 재개하는 사람은 반드시 오늘의 선 오른쪽에 있어야 하므로, 우리는 "과거를 다시 쓰지" 않는다. The quality and status of the work unit can be recognized instantly by anyone passing the Poster. Nothing to the left of the time line can be changed, because it represents past time. Any replanning the project must be to the right of the today line, so we don't "rewrite the past."
일단 PPPP가 가동되면 트러블을 감출 수 없고 해석하기 쉽기 때문에 조직에 놀라운 변화가 나타나기 시작한다. 관리자는 자체적인 성과 측정치를 게시함으로써 측정에 대한 일치된 메세지를 전달한다. 그리고 사람들은 프로세스 개선이나 퇴화를 쉽게 볼 수 있기 때문에 동기부여가 된다. Once the PPPP goes into operation, amazing changes start to appear in the organization, because trouble can't be hidden and is easy to interpret. By posting a measure of their own performance, management sends a congruent message about measurement. And people are motivated because it's easy to see process improvement or degeneration.
Chapter 9: 측정 도구로서의 리뷰 (Reviews as Measurement Tools)
Summary
기술적 검토는 불쾌한 진실을 감히 직면할 수 있기 때문에 0차원 측정의 핵심 요소인 동시에 모든 상위 수준도 마찬가지다. PPPP는 프로젝트 관리에 있어 기술 검토의 역할을 명확히 한다. Technical reviews are key elements of zeroth-level measurement—and all higher levels as well—because they dare to face unpleasant truths. The PPPP makes clear the role of the technical review in project management.
비록 테스팅이 모든 결함을 제거했다 하더라도, 리뷰는 기계 시험보다 일찍 많은 결함을 제거하기 때문에 일정 성능을 개선하는데 도움이 될 것이다. 검토된 프로젝트는 더 느리게 시작되는 것처럼 보이지만, 기계 테스트를 불균형하게 단축시키기 때문에 실제로 더 빨리 마무리된다. 또한 코딩이 수행되기 전에 설계 결함이 발견될 경우 많은 코딩이 제거된다. Even if testing did remove all faults, reviews would be helpful at improving schedule performance because reviews remove many of the faults earlier than machine testing. Reviewed projects do seem to start slower, but actually finish faster because they shorten machine testing disproportionately. Reviews also eliminate a great deal of recoding when they find design faults before coding is done
검토는 테스팅의 대안이 아니라, 단순히 특수한 성질을 가진 테스트의 또 다른 형태일 뿐이다. 리뷰는 기계 테스트보다 더 일찍 사용할 수 있다. 리뷰는 기계 테스트와 다른 결함의 프로필을 찾아낸다. 리뷰는 시간이나 자원에 있어서 준비에 대한 투자를 거의 필요로 하지 않는다. Reviews are not an alternative to testing, but simply another form of testing that has special properties. Reviews can be used earlier than machine tests. Reviews find a different profile of faults than machine tests. Reviews require little investment in setup, either in time or resources.
테스트로서의 모든 이점 외에도, 리뷰는 테스팅하는 동안 가르친다. 리뷰 참가자는 리뷰에서 기술적 문제, 자신에 대한 정보 및 기타 정보에 대해 배운다. 따라서, 리뷰가 제품을 향한 것처럼 보이지만, 장기적으로는 그것의 주요 효과가 과정에 있다. In addition to all their benefits as tests, reviews teach while testing. Review participants learn about technical issues, about themselves, and about others in the review. Thus, although the review seems to be directed at the product, its major effect in the long run is on the process.
매 리뷰에 대한 기술 검토 요약 보고서는 프로젝트 이력 파일에 보관되며, 제품 후보 측정에 대해 알아야 할 사항을 관리자들에게 알려준다. 요약 양식은 측정이 어떻게 이루어졌는지, 즉 측정 뒤에 있는 "스토리"와 프로젝트를 관리하는데 필요한 정확한 정보를 모호하지 않게 문서화한다. The Technical Review Summary Report for every review is kept in the project history file and tells managers what they need to know about the measurement of a product candidate. The summary form documents how the measurements were done—the "story" behind the measurement and precisely the information needed to manage a project, in unambiguous terms.
리뷰어들은 제품 후보자의 품질에 대해 다음과 같은 가능한 판단을 하도록 제한된다: The reviewers are constrained to the following possible judgments of the quality of the product candidate:
현재대로 승인됨 accepted as is
사소한 개정으로 승인됨 accepted with minor revisions
주요한 개정이 필요함 major revisions required
재구축이 필요함 rebuild required
리뷰가 완료되지 않음 review not completed.
프로젝트를 통제하는데 필요한 보수적인 판단을 보장하기 위해 결론을 도출하는데 있어 몇 가지 핵심 원칙을 고려한다: To ensure the kind of conservative judgment needed to control a project, consider several key principles in arriving at a conclusion:
항상 가장 보수적인 선택을 하라. Always take the most conservative choice.
의견 차이를 들어보라. Listen for differences of opinion.
서명에 대한 반응을 확인하라. Notice the reaction to signing.
문제를 다시 열려는 시도를 주의하라. Watch for attempts to reopen issues.
강한 감정을 눈치채고 확인하라. Notice and check out strong feelings.
이러한 원칙을 준수함으로써 전체 프로젝트 실패의 위험을 줄일 수 있는 신뢰성 있는 측정치를 확보한다. By following these principles, the organization obtains reliable measurements that reduce the risk of total project failure.
어떤 작업에서든 제품 후보를 검토할 수 있다. 그렇지 않다면 그것은 과제가 아니다. 아마도 가장 중요한 제품 후보는 다른 어떤 측정치일 것이다. 왜냐하면 궁극적으로는 모든 측정치는 어떤 사람이나 사람의 의견에 달려 있기 때문이다. 기술적 검토는 모든 측정이 알려진 신뢰성을 갖도록 의존성을 공식화하는 방법이다. "검토하기 전까지는 측정이 아니다"라는 점을 기억하라. The product candidate from any task can be reviewed. If not, it's not a task. Perhaps the most important product candidate is any other measurement because ultimately every measurement rests on the opinions of some person or persons. The technical review is a way of formalizing that dependency, so that all measurements are of known reliability. Remember: "It's not a measurement until it's been reviewed."
기술 검토는 또한 다른 제안된 측정의 효율성이나 효과성을 시험할 수 있는 표준이다. The technical review is also a standard against which any other proposed measurement can be tested for efficiency or effectiveness.
Chapter 10: 요구사항: 측정의 기반 (Requirements: The Foundation of Measurement)
Summary
기술적 검토는 절대적 측정은 아니지만, 항상 요구조건에 상대적이다. Technical reviews are never absolute measurements, but are always relative to the requirements.
비신뢰성의 제0법칙은 소프트웨어 엔지니어링의 제0법칙의 특정한 한 가지 사례에 지나지 않는다: "품질에 신경을 쓰지 않으면 다른 목적을 달성할 수 있다." The Zeroth Law of Unreliability is merely one particular case of the Zeroth Law of Software Engineering: "If you don't care about quality, you can meet any other objective."
요구사항 프로세스의 목적은 막연한 요구를 고객이 원하는 바를 명시적이고 모호하지 않은 진술로 바꾸는 것이다. 우리는 이 진술들을 무엇이 원하는지, 즉 피드백 제어 프로세스의 근본적인 측정에 사용할 수 있다. The purpose of any requirements process is to change vague desires into explicit and unambiguous statements of what customers want. We can use these statements for comparison of what was built with what was desired—the fundamental measurement of any feedback controlled process.
음의 차원 측정은 아예 측정하지 않는 것보다 나쁜 측정이다. 요구사항 추측은 음의 차원 측정의 한 예다. A negative-order measurement is one that is worse than not measuring at all. Guessing requirements is one example of a negative-order measurement.
세계는 폭포수 모델과 다른 선형 프로세스 모델이 요구하는 방식으로 작동하는 경우는 거의 없지만, 프로젝트가 진행됨에 따라 새로운 요구사항을 창출하고 있다. 요구사항 개발 프로세스는 소프트웨어 개발 프로세스와 제품의 모든 사용자와 지속적으로 대화한다. The world seldom works the way the Waterfall Model and other linear process models require, but goes on generating new requirements as the project proceeds. The requirements development process is in constant dialogue with both the software development process and all users of the product.
요구사항의 상태를 관찰할 수 없는 경우, 프로젝트는 그 추이를 아무도 알지 못하는 사이에 요구사항에서 벗어날 수 있다. 아무도 눈치채지 못한 채 측정 기준이 바뀌었기 때문에 검토 과정에 의한 측정은 무의미해진다. If the status of requirements is not observable, the project can drift away from its requirements without anyone being aware of the drift. Measurements made by the review process then become meaningless, because the standard of measurement has changed without anyone noticing.
요구사항 정의 프로세스는 항상 소프트웨어 개발 프로세스와 병행하여 실행되지만, 그 과정은 서로 다른 문화적 패턴에서 상당히 다르게 보인다. A requirements definition process is always running in parallel with the software development process, but the process looks quite different in the different cultural patterns.
패턴2(루틴) 문화는 소프트웨어 구축 프로세스보다 요구사항 프로세스가 덜 중요하다는 것을 전달할 수 있는데, 이 경우 계획 수립에 거의 노력을 기울이지 않고, 자원이 투입되지 않으며, 누구도 전임 책임을 지지 않으며, 훈련이 경박해 보이며, 도구가 불필요해 보일 것이다. 실질적인 요구사항 절차는 없을 것이고, 개발은 통제되지 않을 것이다. Pattern 2 (Routine) cultures may communicate that the requirements process is less important than the software-building process, in which case little effort will be devoted to planning, resources will not be committed, nobody will take full-time responsibility, training will seem frivolous, and tools will seem superfluous. There will be no real requirements process, and development will be uncontrolled.
패턴3(조정하는) 요구사항 프로세스는 그 자체로 통제된 피드백 프로세스로서, 소프트웨어 제품과 동등하게 중요하며, 다른 프로세스와 마찬가지로 경영진의 지원을 받는다. A Pattern 3 (Steering) requirements process is a controlled feedback process in its own right—with its own products equal in importance to the software products, and supported by management just like any other process.
요구사항이 심각하게 받아들여져도 프로세스를 파괴하는 누설이 있을 수 있다. 누출 연구는 요구사항이 변경되는 통제되지 않은 수십 가지 방법을 찾을 수 있다. Even when requirements are taken seriously, there may be leakage that destroys the process. A leakage study may turn up dozens of uncontrolled ways in which requirements change.
요구사항의 잠재적 원천이 매우 많기 때문에, 0차원 측정은 누출을 통제된 요구사항으로 변환해야 한다. 이 프로세스를 시작하는 한 가지 방법은 서명된 시작 작업 수락 보고서(Startup Task Acceptance Report: STARt)를 사용하는 것이다. Because there are so many potential sources of requirements, zeroth-order measurement must convert leaks to controlled requirements. One way to begin this process is through the use of a signed Startup Task Acceptance Report (STARt).
STARt와 함께라면, 건설업자가 그 일을 수행하는데 필수적인 요소들을 가지고 있다는 것에 대해 전문적인 명성을 걸었다는 것을 알 것이다. 이 서명은 이 중요한 순간에 모든 관련자들이 주의 깊은 상태에 있도록 강요하기 때문에, 의사소통은 높은 수준의 품질을 유지한다. With STARt, you know that the builder has staked a professional reputation on having the essentials for performing the task. The signature forces everyone involved to be in an attentive state at this crucial moment, so that communication remains at a high level of quality.
Chapter 11: The Wayfinder
하와이의 태평양 부근은 우리 행성의 3분의 1을 차지하고 있으며 모든 대륙을 합친 것보다 더 크다. 그것은 995 부분의 물과 5 부분의 땅이지만, 그것의 거의 모든 10,000개 이상의 섬들이 몇 세기 전에 유럽 탐험가들이 이 지역에 도착하기 훨씬 전에 발견되었다. 광범위한 오픈 오션 항해는 광활하고 외딴 폴리네시안 삼각지대를 정착시켰고, 쿡 선장이 "지구상에서 가장 넓은 국가"라고 부르는 것을 발견했을 때 놀라움을 자아냈다. 이 폴리네시아 "국가"의 사람들은 언어, 문화, 유전적 유산을 공유했다. 그러나 그들은 문맹자였고, "절약자"였으며, 서구 문명의 지도와 도구가 부족했다. 서양인들은 원주민들이 외해를 안정적으로 여행하고 있다고 믿는데 어려움을 겪었고, 반면 그들의 조상들은 해안선에 매달리고 있다. Hawaii's Pacific Ocean neighborhood engulfs a third of our planet and is larger than all our continents combined. It is 995 parts water and 5 parts land, yet almost all of its more than 10,000 islands had been discovered long before European explorers arrived in the region a few centuries ago. Extensive open-ocean voyaging settled the vast, remote Polynesian Triangle of islands and made possible the astonishment of Captain Cook at coming upon what he called "the most extensive nation on Earth." The people of this Polynesian "nation" shared a language, culture, and genetic inheritance. But they were illiterate, "savage" and lacked the maps and instruments of Western civilization. Westerners had difficulty believing that native wayfinders had been reliably traveling the open sea while their own forebears—afraid of falling over the edge—were clinging to their coastlines.
2000마일 이상의 공해로 항해하는 일은 많은 면에서 대형 소프트웨어 시스템을 구축하거나 유지하는 것과 견줄 만하다. 미개척자들에게는 우선 간단해보인다. 그리고 나서, 더 생각해 보면, 그것은 불가능할 정도로 복잡해지고 위험해진다. 그러나 길잡이에게 각각의 일은 같은 종류의 관찰력을 요구한다. The task of navigating to a tiny atoll over 2,000 miles of open ocean is in many ways comparable to building or maintaining a large software system. To the uninitiated, it first seems simple. Then, on further thought, it becomes impossibly complex and dangerous. To the wayfinder, however, each task requires the same kind of observational powers.
광활한 태평양에 홀로 육지가 보이지 않는 곳에서 폴리네시아 길찾기들은 놀라운 정확성을 가지고 항해했다. 이와 유사하게, 소수의 소프트웨어 엔지니어링 관리자는 놀랄만한 품질의 (관찰력이 적은) 결과로 프로젝트를 지휘할 수 있다. Alone on the vast Pacific, out of sight of land, the Polynesian wayfinders navigated with (to Europeans) astonishing accuracy. Similarly, a few software engineering managers are able to steer projects with (to less observant managers) results of astonishing quality.
폴리네시안 웨이파인더는 약간의 바다 부풀기, 구름 형성, 밝기, 색깔, 태양, 달, 별의 위치, 수류와 온도의 변화, 선상 돼지에 의해 감지되는 향기, 표류하는 파편과 해초, 새 종과 비행 패턴, 카누의 투구와 롤, 그리고 서구인들이 여전히 이해하지 못하는 다른 미묘한 측정들을 사용한다. The Polynesian wayfinder uses slight ocean swells; cloud formations, brightness, and color; the position of the sun, moon, and stars; shifts in water currents and temperature; the scents detected by an on-board pig; drifting debris and seaweed; bird species and flight patterns; the pitch and roll of the canoe; and other subtle measurements that Westerners still do not comprehend.
소프트웨어 엔지니어링 웨이파인더는 양식에 서명할 때 약간의 망설임과 호흡 변화, 진행률 포스터의 색과 패턴, 사람들이 회의에 앉아 있는 위치, 실패에 대응하기 위한 시간 이동, 긴장된 땀과 탄 커피 냄새, 배달 날짜의 표류, 활동과 불활성의 패턴, 음성의 피치와 rate; 그리고 다른 더 적은 관리자들은 절대 이해할 수 없는 다른 미묘한 측정들을 사용한다. The software engineering wayfinder uses slight hesitations and changes in breathing on signing a form; the color and pattern of a Progress Poster; the positions people sit in meetings; shifts in time to respond to failures; the odor of nervous sweat and burnt coffee; drifting of delivery dates; patterns of activity and inactivity; the pitch and rate of voices; and other subtle measurements that lesser managers may never comprehend.
이 책을 다 읽었으면 소프트웨어 길잡이가 되기 위한 큰 항해에서 작은 부분을 완성한 것이다. 당신의 다음 단계는 당신의 아웃리거에 올라타서 항해하는 것이다. 모든 감각을 열어놓고, 당신의 마음을 해석하고 배우라. If you've finished this book, you've completed one small part of your grand voyage toward becoming a software wayfinder. Your next stage is to climb into your outrigger and set sail, keeping all your senses open and your mind clear to interpret and learn.
그리고 안심하라. 해변에 평지인들이 떼지어 서서 지구 가장자리에서 떨어질 거라고 외칠테니, 당신의 감정을 잘 알고 올바른 방향을 잡으라. And rest assured, there will be a horde of flatlanders standing on the beach shouting that you're going to fall off the edge of the Earth, so stay aware of your feelings and steer the right course.
즐거운 여행이 되기를! Bon voyage!
QSM: Volume 3.1: Managing Yourself and Others
Contents
Part I. 나 자신을 관리하기
Chapter 1. 왜 일치성이 관리에 핵심적인가 (Why Congruence is Essential for Managing)
Summary
이 책은 어떻게 고품질의 소프트웨어를 만드는데 필요한, 고품질의 효과적인 소프트웨어 엔지니어링 관리자가 될 것인가에 대한 책이다. 그러한 관리자에게 요구되는 가장 우선적이면서 가장 중요한 것은 당신의 신념과 일치적으로 행동할 수 있는 능력이다. This book is about how to become the kind of high-quality, effective software engineering manager needed to produce high-quality software. First and foremost among the requirements for such a manager is the ability to act in congruence with your beliefs.
사이버네틱스는 관리자를 피드백 시스템에서의 제어기로 볼 수 있다고 말한다. 피드백 제어로 엔지니어링 시스템을 관리하기 위해서는, 제어기로서의 관리자는 다음과 같은 것들을 해야한다: Cybernetics says managers can be seen as controllers of feedback systems. To manage an engineering system by feedback control, a manager as controller needs to
무엇이 일어나야하는지 계획하기 plan what should happen
실제로 어떠한 중요한 사건들이 일어나는지 관찰하기 observe what significant things are really happening
계획된 것과 관찰한 것을 비교하기 compare the observed with the planned
실제를 계획된 것과 가까워지도록 필요한 행동을 취하기 take actions needed to bring the actual closer to the planned
효과적인 관리자는 무엇을 해야 하는지 알아야 한다. 하지만 그들은 또한 그 지식에 따라서 행동할 수 있는 능력이 있어야 한다. Effective managers must know what to do, but they must also be able to act in accordance with that knowledge.
애쉬비의 필수 다양성의 법칙은, 제어기에 의해 취해지는 행동은 상황에 일치적이어야 한다고 말한다. 사람들이 그들의 잠재적으로 최대한 다양한 행동들을 추구하지 않는다면, 그들은 비일치적으로 대응하는 것이다. Ashby's Law of Requisite Variety says the action taken by the controller must be congruent with the situation. When people are not tapping their full variety of potential actions, they are coping incongruently.
제어의 목적으로 보면, 관리자가 왜 행동의 필요 다양성을 보이지 못하는지는 중요하지 않다. 비일치적으로 행동하는 관리자는 아마도 그들이 제어하려고 하는 시스템을 제어할 능력이 없을 것이다. 만약 그렇다면, 그들이 왜 비일치적인가와는 관계없이, 그들이 관리하는 조직은 고품질의 소프트웨어를 생산해낼 수 없을 것이다. For control purposes, it doesn't matter why managers are unable to exhibit the requisite variety of action. Managers acting incongruently may not be capable of controlling the system they are trying to control. If so, the organization they manage will be unlikely to produce high-quality software, regardless of the reasons for their incongruence.
분명히 기술은 고품질의 소프트웨어와 소프트웨어 서비스를 지속적으로 전달하는데 있어 중요하다, 하지만 현대의 소프트웨어 조직에서는, 관리가 가장 큰 랜덤 프로세스 요소이다. 그 뿐만 아니라, 비일치적인 관리는 모든 다른 랜덤 프로세스 요소들을 향상시키는 효과를 낸다. Technology is obviously important to the consistent delivery of high-quality software and software services, but in today's software organizations, management is the number one random process element. Not only that, but incongruent management stands in the way of improving all the other random process elements.
사람들의 개인적인 효과성은 소프트웨어 엔지니어링 관리의 모든 다른 요소들을 통합하는 요인이다. 패턴2 관리자들을 데리고 패턴3 조직을 절대 이룰 수 없을 것이다. 반면, 효과적인 관리자를 데리고 시작하면, 그들이 다른 이들을 이끈다. The personal effectiveness of people is what integrates all the other components of software engineering management. You'll never get a Pattern 3 organization with Pattern 2 managers. Instead, you start by getting the effective managers, then they lead the others.
이 권의 역할은, 관리자들이 그들의 행동에서 최대의, 그리고 적절한 다양성을 도모하는데 있어서 직면하는 주요한 장애물들을 드러내는 것이다. The task of this volume is to address the major obstacles managers face in attempting to use full and appropriate variety in their actions.
Chapter 2. 관리를 선택하기 (Choosing Management)
Summary
소프트웨어 엔지니어링 분야에서는 일치적인 관리자를 찾는게 매우 힘들다. 아마도 그 이유 중 하나는 조직이 관리자를 선택하고 개발시키는 방법일 것이다. Congruent managers are hard to find in software engineering, partly because of the way our organizations choose and develop their managers.
보헴이 말하길, "형편없는 관리는 다른 어떤 요소보다도 더 빠르게 소프트웨어 비용을 증가시킬 수 있다."고 했다. 64배나 되는 수치는 관리에 있어 보수적인 예측일 것이다. 형편없는 관리는 비용을 증가시키고, 심지어는 프로젝트 전체를 실패하게 만들기 때문이다. Boehm says, "Poor management can increase software costs more rapidly than any other factor." A cost driver of 64 would be a conservative estimate for management, because of the many ways poor management can increase costs—or even create total project failure.
관리자들은 종종 비용 유발 요인 순서와는 반대 순서로 개선 노력을 기울이는 것 같다. 가장 중요한 유발 요인인 관리 그 자체에는 가장 적은 노력을 기울인다. Managers often seem to allocate improvement efforts in reverse order of cost-driver impact, putting least effort into the most important driver, management itself.
관리자들을 위한 '1차원 선택 모델'은 세 가지 잘못된 가정에 근거하고 있다: The One-Dimensional Selection Model for managers is based on three faulty assumptions, namely:
관리자는 만들어지는게 아니라 태생적인 것이다. Managers are born, not made.
사람들은 한 가지 기준으로 줄세울 수 있다. People can be ranked on a one-dimensional scale.
프로그래밍을 잘 하는 사람은 관리도 잘 한다. (프로그래밍 잘 하는 기준은 관리 잘 하는 기준과 같다) The scale for programming is the same as the scale for management.
이 모델의 결과로, 우리는 가장 기술 능력이 뛰어난 사람을 관리 분야로 이동시키는 경향이 있고, 그러면 관리와 기술 스텝 모두가 약화된다. As a result of this model, we tend to move the strongest technical people to management, a practice that weakens both management and the technical staff.
팀 리더는 소프트웨어 품질을 향상시키는데 효과적일 수 있다. 하지만 팀 리더의 역할은 관리자의 역할과 같지 않다. 최고의 팀 리더가 반드시 최고의 관리자인 것은 아니다. Team leaders can be effective at improving software quality, but the job of team leader is not the same as the job of manager. Nor will the best team leaders necessarily make the best managers.
관리자가 되기를 원하지 않는데도 관리 커리어를 시작하는 사람은 비일치적으로 시작하는 것이다. 그것은 시간이 지나도 나아지기가 어렵다. People who don't want to be managers in the first place are starting their management careers in an incongruent position, one that will be difficult to improve over time.
가치없는 비전을 추구하기 위해서 관리자가 되려는 사람은 가치없는 관리자가 된다. 나는 이 책이 그런 사람들을 돕기 원하지 않는다. People who go into management to pursue an unworthy vision will be unworthy managers. I hope this book won't help them.
Chapter 3. 대처의 유형들 (Styles of Coping)
Summary
조직 내의 모든 사람은 무언가를 제어하는 것을 담당한다. 그리고 비일치적 대처는 효과적인 제어를 위한 다양성을 감소시킨다. 그래서 사람들의 특징적인 대처 유형을 통해 조직의 건강도를 측정하는 것이 가능하다. Since everybody in an organization is responsible for controlling something, and since incongruent coping reduces the variety needed for effective control, it's possible to measure an organization's health through the people's characteristic coping styles.
자아존중감이 낮을 때, 사람들은 비일치적 대처 유형의 특징을 잘 보여준다: 비난하기, 회유하기, 초이성적이 되기, 사랑하기/증오하기, 또는 연관성 없이 행동하기. When feelings of self-esteem are low, they are manifest in characteristic incongruent coping styles: blaming, placating, being superreasonable, loving/hating, or acting irrelevant.
세상에 효과적으로 대응하기 위해서, 우리는 세 가지 분야에 주의를 기울일 수 있어야 한다 - 자아, 다른 사람, 맥락 - 그리고 동시에 그 모두의 요구사항의 균형을 맞춰야 한다. 그러기 위해서는 일치적으로 행동해야 한다. In order to cope effectively with the world, we must be able to take into account three areas—self, other, and context—and balance their requirements all at the same time. To do this is to behave congruently.
사람들이 다른 이들을 고려하는데 실패할 때, 그들은 비난하는 태도가 된다. 비난할 때, 그 사람은 이렇게 말하는 것이다, "내가 제일 중요해. 너는 아무 것도 아니야" When people fail to take other people into account, they fall into a blaming posture. When blaming, a person is saying, in effect, "I am everything, you are nothing."
사람들이 그들 자신을 고려하는데 실패할 때, 그들은 회유하는 태도가 된다. 그리고 결과적으로 이렇게 말하는 것이다, "나는 하나도 안중요해, 네가 제일 중요해." When people forget to take themselves into account, they fall into a placating posture, and are effectively saying "I am nothing, you are everything."
가장 흔한 유형은, 비난형인 상사와 회유형인 직원 사이에 무한루프가 형성되어 고착되는 것이다. A very common pattern is a blaming boss locked in a never-ending cycle with a placating employee.
다른 보편적인 비난-회유 역동의 변종은, 회유자가 학대를 너무 많이 당한 다음에, 갑자기 역할이 바뀌어서, 그것(학대를) 비난자에게 모두 던져버리는 것이다. Another common variation of the blaming-placating dynamic is the sudden switch in roles when the placater has swallowed enough abuse, and suddenly throws it all up onto the blamer.
초이성 유형에서는, 사람들이 전혀 고려되지 않는다. 초이성형은, 결과적으로 이렇게 말하는 것이다, "상황(it)이 제일 중요해; 너나 나는 전혀 중요하지 않아." In the superreasonable style of coping, people are entirely excluded from consideration. The superreasonable stance says, in effect, "It is everything; you and I are nothing."
일치성의 관점에서는, 사랑과 증오 관계는 같은 구조이다 - 맥락을 완전히 배재하는 것이다. 사랑/증오 유형은 결과적으로 이렇게 말하는 것이다. "상황은 전혀 중요하지 않아; 너랑 내가 제일 중요해" From the viewpoint of congruence, love and hate relationships have the same structure—the total exclusion of context. The loving/hating stance says, in effect, "It is nothing; you and I are everything."
'연관성 없음' 유형에서는, 모든 것이 사라진다 (고려되지 않는다), 그래서 전혀 예측 불가능한 행동으로 흘러간다. 이 행동은 순수한 부정적 힘을 가지고 있다 - 일이 끝나게 하지도 않고, 일이 끝나는 것을 방해한다. 결과적으로 '연관성 없음' 유형에서는 이렇게 말한다, "아무 것도 중요하지 않아" In the irrelevant style of coping, everything is missing, which leads to entirely unpredictable behavior. This behavior has a purely negative power—not to get things done, but to prevent things from getting done. In effect, the irrelevant behavior says, "Nothing counts for anything."
비일치적인 대응 유형 각각은 잘 동작할 때 얻을 수 있는 것보다 적더라도 (효과성이 낮더라도? 그다지 잘 작동하지 않더라도?) 그 정도에 만족한다. 그것들은 가끔 다소의 보호를 제공하기 때문에 계속 사용된다. 그래서 그것들은 자존감이 낮을 때 사용된다.(?) Incongruent coping styles each settle for less than they could get if they worked well. They do "work" to the extent they sometimes give some protection, so they are used when self-esteem is low.
비일치적으로 행동하는 관리자는 그들의 스탠스 안으로 갇히게 될텐데, 비효과성과 낮은 자존감을 연결하는 피드백 고리 때문에 그렇게 된다. Managers acting incongruently may get locked into their stance by a positive feedback loop connecting ineffectiveness and low-self esteem.
Chapter 4. 비일치성에서 일치성으로 (From Incongruence to Congruence)
Summary
일치적인 행동은 전형적인 행동이 아니라 (어떤 정해진 행동들이 아니라), - 맥락과, 다른 사람들과, 자아에 - 부합하는 행동이다. 그래서 하나의 상황에 대해서 여러 가지 일치적인 행동들이 존재한다. Congruent behavior is not stereotyped behavior, but behavior that fits—the context, the others, and the self—so many congruent behaviors exist for any one situation.
일치적인지 알기 위해서는 완전한 상호작용 (total interaction)을 경험해야만 한다. 완전한 상호작용이라는게 들리는 것처럼 그렇게 어려운건 아니다. 사람들이 완전한 상호작용을 경험하면, 비일치적인 메세지인지 알아차릴 수 있다. You must experience the total interaction to know if it's congruent, which is not as hard as it sounds. When people experience the total interaction, they know when the message is not congruent.
일치성은 효과적인 관리에 핵심적으로 중요(critically important)하다. 관리자는 그것을 어떻게 인식할 수 있는지 알아야 할 뿐만 아니라, 그들이 인식한 것에 확신을 가져야 한다. 그러한 확신을 가질 수 있는 한 가지 방법은 언어적(verbal) 응답과 비언어적(nonverbal) 응답 사이의 미묘한 비일치를 관찰하는 것이다. 또 다른 방법은 내용을 특정한 특징 패턴으로 듣는 것이다. Congruence is critically important to effective management. Managers must not only know how to recognize it, but also have confidence in their recognition. One way to gain such confidence is to watch for subtle incongruence between verbal and nonverbal response. Another is by listening to the content for certain characteristic patterns.
소프트웨어 엔지니어링의 고품질 관리자가 되기 위해서는 어떻게 비일치적 대처에서의 에너지가 조금 더 유용한 형태로 변화할 수 있는지 배우는 것이다. To become a higher-quality manager of software engineering, learn how the energy in incongruent coping can be transformed into something more useful.
각 비일치적 행동들은 사실 어떠한 생존 환경에서는 효과적으로 동작하는 행동에 기반해 있다. 그리고 심지어는 유전적 구성요소이기도 하다. 그것이 비일치적이 되는 이유는, 생존이 목적이 아닌 경우에도 그것을 사용하기 때문이다. Each incongruent behavior is based on a behavior actually effective in some survival situations, and may even have a genetic component. What makes it incongruent is its application when survival is not at stake.
비난하기는 공격이라는 생존 행동에 기반한다. 비난하기는, 결국, "네가 그것을 계속한다면, 나는 너를 멈추기 위해서 필요한 것은 무엇이든지 할거야. 네게 어떤 결과가 생기든 상관 없이 말이야." 비난하고자 하는 충동은 더 효과적인 대응 전략으로 변환될 수 있는데 - 단호해지기, 지시적이기, 정직하기, 가식 없기, 솔직하기, 담백하기, 열려있기. Blaming is based on the survival behavior of attack. Blaming says, in effect, "If you continue to do that, I'm going to do what is necessary to stop you, no matter what the consequences to you." The impulse to blame can be transformed into an effective coping strategy—becoming assertive, direct, honest, frank, candid, forthright, or open.
억누르려는(회유하려는) 충동은 다음과 같이 일치적으로 변모할 수 있다 - 돌보기, 필수적이 되기, 우아하게 건네주기, 훌륭한 실패자 되기. 이러한 행동들은 미래의 맥락을 고려할 때에 일치적이다. The urge to placate can be congruently transformed into caring, yielding to the inevitable, giving in gracefully, or being a good loser. These behaviors are congruent when they take the future context into account.
초이성형의 일치적인 변형은 다음과 같은 관리적인 행동에 상응한다 - 침착하기, 초점을 유지하기, 이성적이기, 특히 비상 상황에서. The congruent transformation of the superreasonable style corresponds to the managerial behavior of staying cool, focused, and reasonable, especially in an emergency.
사랑 자세의 일치적인 변형은 호혜적인 동맹을 구축하는 능력이다. 증오 자세의 일치적인 변형은 친한 경쟁 구도에 참여하는 능력이다. The congruent transformation of a loving posture is the ability to form beneficial alliances. The congruent transformation of a hating posture is the ability to participate in friendly rivalries.
산만형과 유사한 일치적인 변형은 모든 이성(적인 수단)이 시도되었을 때, 절박함의 표현으로 사용될 수 있다. 주의 환기, 즐기기, 창의적인, 또는 셋 모두. Congruent behavior resembling irrelevance may be used as a desperate measure when everything rational has been tried. It may be diversionary, amusing, creative, or all three.
Chapter 5. 일치성을 향해 가기 (Moving Toward Congruence)
Summary
신규 관리자의 업무 중 중요한 부분은 그들 자신의 정서를, 비일치적이 되지 않으면서 관리하기를 배우는 것이다. An important part of the task of new managers is learning to manage their own emotions, without becoming incongruent.
모든 비일치적 대처 아래에는, 생존 규칙이 있다, 그렇게 부르는 이유는 우리가 마치 생존의 위험에 있는 것처럼 대응하기 때문이다. 이러한 규칙은 우리 행동을 제어하는 무의식적인 프로그램처럼 기능한다. Beneath every incongruent coping, there is a survival rule, so-called because we respond as if our very survival were at stake. These rules function as unconscious programs controlling our behavior.
우리 자신의 불일치를 알아챌 수 있는 신뢰할만한 신호는 우리가 스스로에게 보내는 내부 메세지에서 찾을 수 있다. 특히 그 신호가 강한 정서적인 상자로 감싸여 있으면 더욱 그렇다. A reliable signal of our own incongruence is found in the internal messages we send ourselves, especially those messages wrapped in strong emotional packages.
우리 스스로의 내부 메세지를 들음으로서, 그것을 높은 자아존중감의 밝은 빛으로 변환하게 되고, 비일치적인 행동들이 실제로 일어나기 전에 미리 방지할 수 있다. By listening to your own internal messages, then transforming them in the light of high self-esteem, you can thwart incongruent actions before they happen.
감정은 무엇이 중요하고 무엇이 덜 중요한지 당신에게 알려주는 자연의 수단이다. 당신에 관한 이 정보는 당신이 스스로 다른 사람들에게 말하지 않는다면 다른 사람들은 잘 모른다. (내가 그들에게 말하기 전에는 그들이 그 정보를 신뢰하고 사용하기 어렵다.) Feelings are nature's way of telling you what's important and what's not so important. This information about you is not reliably available to other people unless you tell them.
일치적이 되기 위해, 당신은 "말하기 임계치"를 정해야 한다. 그 임계치는 당신 자신에 대한 것인데 다른 사람들에 대한 당신 스스로의 감정과 맥락에 영향을 주는 것이다(?). 스스로에 대해 일치적으로 말하는 것은 당신이 살아가면서 계속 적용할 수 있는 해결책을 찾을 기회를 높인다. To be congruent, you must set a "speak-up threshold" that measures your own feelings against those of others and the dictates of the context. Speaking congruently for yourself increases your chances of finding a solution you can live with.
당신이 말하는 맥락은 부분적으로(특히? 특정한 경우에?) 중요하다. 그 단어가 다시 돌아오기를 바라면서 제3자를 사용(지칭?)하지 말아라. 제3자를 위해서 주장하지 말아라 - 당신이 이슈를 가지고 있다면, 당신 스스로를 위해 말하라. 제3자에 대한 가십을 이야기하지 말아라. 관련된 사람들에게 직접적으로 이슈를 제기해라. 특정한 케이스에 대해 비밀스럽게 말하는 일반적인 메모를 남기지 말아라. 그런 메세지는 아무도 바보로 만들지 않고 - 당신을 비겁한 바보처럼 보이게 할 것이다. The context in which you speak up is particularly important. Don't use third parties, hoping the word will get back. Don't claim to speak for third parties—if you have an issue, speak for yourself. Don't gossip about third parties. Raise any issue directly with the people involved. Don't issue general memos that secretly address individual cases. Such messages fool nobody—and make you look like a cowardly fool.
항상 다른 사람을 당신 스스로에 대해 하는 것처럼 정직과 기품과 존중을 가지고 대하라. 만약 당신이 너무 긴장해서 당신이 사용하는 전술들을 제어하기 어렵다면, 당신 스스로에 대한 제어권을 다시 얻을 때까지 미뤄라. Always treat the other person with the honesty, dignity, and respect you would like for yourself. If you are too overwrought to control the tactics you use, then pull away until you regain control of yourself.
당신의 잃어버린 일치성을 회복하기 위해 사용할 수 있는 단계들이 있다. 개략적으로, 처음으로는 비일치성을 알아채야 하고, 숨을 고르고, 자세를 조정하고, 몸짓을 조정한다. 마지막으로, 상대방과 접촉할 필요가 있는데, '나-전달법 (I-statement)'으로 말하고, 상대방이 응답할 수 있도록 기다린다. 필요할만큼 이 과정을 반복해서, 일치적이 되던지, 지금은 그게 가능하지 않다는 것을 발견한다. There is a step-by-step process you can use to recover your lost congruence. Roughly, you must first notice the incongruence, then make adjustments to your breathing, posture, and movement. Finally, you need to make contact with the other person, speaking in "I-statements," and wait for the other person to respond. You repeat this process as often as necessary either to get congruent or to discover it's not possible at the moment.
일치성은 당신의 행동의 가능성들의 최대 다양성을 사용하기 충분할 만큼 좋게 느끼는 것을, 그래서 전문적인 소프트웨어 엔지니어링 관리자가 될 훌륭한 기회를 얻게 되는 것을 의미한다. Congruence means feeling good enough to use the full variety of your action possibilities, so you have an excellent chance to be a professional software engineering manager.
Part II. 다른 사람을 관리하기 (Managing Others)
Chapter 6. The Manager's Job
Summary
효과적인 소프트웨어 조직에서는, 관리자의 역할은 더 많은 사람들이 무엇이 되어야 하는지를 결정하고, 그것을 수행하는데에 참여하도록 (그리고 그 사람들이 더욱 참여하도록) 하는 것이다. In an effective software organization, the manager's job is getting more people involved (and getting people more involved) in decisions about what is to be done, and in doing it.
예를 들어, 위기에서 복구하기 위해서, 관리자는 배가 가라앉지 않도록 유지하기 위한 자원을 마련하기 위해 대기 인력들을 동원해야 한다. For example, to recover from a crisis, a manager has to mobilize sidelined people in order to have the resources to keep the ship afloat.
조직이 위기로 더 깊이 들어가게 되면, 소식통인 사람들이 과부화가 되는 경향이 있다. 관리자는 알지 못하는 사이에 그것을 촉진하는데 기여할 수 있고, 일치적인 관리 행동을 통해 그것을 방지하는 역할을 할 수 있다. As an organization moves deeper into crisis, the best-informed people tend to become overloaded. Managers may unknowingly contribute to this piling on, and can counteract it by congruent management action.
패턴2 (반복) 조직에서는 관리자들은 해야 하는 일들을 (그걸 하는 방법을?) 규정한다. 원하는 결과물을 묘사하기(이게 조금 더 패턴3스러운 것이다)보다는. 규정하는 관리자는 직원들로부터 듣기보다는 초이성적이거나 비난적인 방식으로 듣는 경향이 있다. In Pattern 2 (Routine) organizations, managers prescribe the way things should be done, rather than describe what outcomes are desired (a more Pattern 3 behavior). Managers who prescribe tend to listen to employees in a superreasonable or blaming way, without hearing them.
소프트웨어 엔지니어링 관리자의 주요한 역할은 성공적인 소프트웨어 활동들에 기여하는 모든 작업자들 사이에 열린 마음(개방성)과 신뢰를 구축하는 것이다. 이것에는 정직과 진정한 듣기가 필요하다. A major job of the software engineering manager is to develop openness and trust among all the workers who are contributing to successful software activities. This requires honesty and true listening.
그 말이 맞든 틀리든, 직원들이 말하는 이유(변명)은 항상 효과적인 관리자가 그 조직을 조정(steer)하는데 필요한 정보를 담고 있다. Right or wrong, the reasons given by employees always contain the information an effective manager needs to steer the organization.
패턴3(조정) 관리자는 품질을 일반적으로 평가하지 않는다. 대신에 사람이 아니라 품질을 평가하기 위해서프로세스를 구축한다. 하지만 관리자가 작업의 품질을 평가할 때에는, 평가의 주요 목적은 직원들이 그들의 스킬을 개발하도록 돕기 위한 것이다. The Pattern 3 (Steering) manager does not generally evaluate quality, but establishes the processes, not people, to evaluate quality. But when the manager does evaluate the quality of work, the main purpose of the evaluation is to help the employees develop their own skills.
1차원 선택 모델을 신봉하는 관리자는, 코칭이나 티칭, 훈련을 하기가 어렵다. (...할 마음의 자리가 없다) Managers who believe the One-Dimensional Selection Model have no room in their repertoire for coaching, teaching, or training.
일치적인 관리자는 비난하기에 고착되지 않는다. 그 이유 중 하나는 그들은 스스로가 직원들에 대한, 상사에 대한, 또는 소프트웨어 품질의 역동에 대한 수동적인 희생자가 아니라는 것을 알기 때문이다. 대신에, 그들은 지능적으로 이 모든 요소들을 자원으로 사용한다. Congruent managers are not locked into blaming, partly because they know they are not passive victims of their employees, their bosses, or the dynamics of software quality. Instead, they use all of these factors intelligently as resources.
리더십은 모든 사람들이 문제를 해결하는데 창의적으로 기여할 수 있도록 북돋는(임파워링) 환경을 조성할 수 있는 능력이다. 이 모델에서, 관리자의 역할은 하나의, 오직 하나의 측정치로 평가될 수 있다: 관리받는 사람들의 성공. Leadership is the ability to create an environment in which everyone is empowered to contribute creatively to solving the problems. In this model, the manager's job may be evaluated by one and only one measure: the success of the people being managed.
Chapter 7. 선호 차이 (Preference Differences)
Summary
형편없는 관리자는 사람들 간의 다양성을, 마치 그것이 존재하지 않는 것처럼 여기곤 한다. 효과적인 관리자는 차이점을 인식하고 그들을 어떻게 일치적으로 다뤄야 할지 안다. Poor managers tend to deal with variations among people by pretending they don't exist. Effective managers recognize differences and know how to deal with them congruently.
모두를 똑같이 대하는 것이 모두를 동등하게 대하는 것을 의미하지는 않는다. 영악한(?) 관리자는 사람들간의 차이점을 알아채고, 효과적으로 - 동등하게, 하지만 불공평하지 않게 관리하기 위해서 그것을 어떻게 사용할지 안다. Treating everyone the same does not mean treating everyone equally. The astute manager notices the differences among people and knows how to use them to manage effectively—equally, but not unfairly.
우리는 모든 소프트웨어 작업을 논리적으로 생각하는 경향이 있지만, 많은 행동들은 정서(emotion)에 기반해서 선택된다. 가장 연하면서도 가장 중요한 정서 중 하나는 선호이다. Although we tend to think of all software work as logical, many actions are chosen on the basis of emotion. One of the mildest yet most important emotions is preference.
무의식적인 선호가 선택의 범위를 줄일 때, 우리는 애쉬비의 필수 다양성의 법칙에 따라 힘든 시간을 보내게 된다. 하지만 그것은 단지 선호이기 때문에, 그러한 다양성의 감소는 피할 수 있다 - 왜냐면 반드시 선호에 따라 행동할 필요는 없기 때문이다. When an unconscious preference reduces choices, we have a tougher time with Ashby's Law of Requisite Variety. Just because there is a preference, however, such a loss of variety need not occur—because we need not act on our preferences.
MBTI의 네 가지 차원은 직장에서 중요하다. 왜냐면 이 네 요소가 개인의 업무 스타일의 많은 부분이 어떻게 결정되는지 설명해주기 때문이다. The four dimensions of the Myers-Briggs Type Indicator (MBTI) are significant in the workplace because they describe how four elements determine much of a person's working style.
MBTI의 각 차원은 아래 각 글자 쌍을 가진다: For each dimension of the MBTI, there is a pair of letters to choose from:
I 또는 E. 내가 어떻게(어떤 방법으로) 에너지를 얻는걸 선호하는지에 따라 I or E according to how I prefer to get energy
S 또는 N. 내가 어떻게 정보를 얻는걸 선호하는지에 따라 S or N according to how I prefer to obtain information
T 또는 F. 내가 어떻게 결정을 내리기를 선호하는지에 따라 T or F according to how I prefer to make decisions
J 또는 P. 내가 어떻게 행동을 취하기를 선호하는지에 따라 J or P according to how I prefer to take action
I와 E의 차이를 고려하는데 실패하면 하나의 그룹 또는 그들을 제외한 이들에 의해서 퍼포먼스 저하가 일어난다. 관리자의 역할 중 하나는 내향성 외향성 둘 모두의 환경적인 선호를 고려하여 회의를 설계하는 것이다. Failure to take the I/E difference into account leads to underperformance by one group or the other. One of the manager's jobs is to design meetings to accommodate the environmental preferences of both Internals and Externals.
감각형은 사실을 원한다. 많은 사실들을 원한다. 반면에 직관형은 빅 픽처를 원한다. 직원과 의사소통 문제가 있는 관리자는 핵심 원인으로 이 차이를 가장 중요한 후보로 탐색해봐야 한다. Sensors want the facts, lots of facts, while Intuitives want the big picture. A manager who has communication problems with employees should explore this difference as a prime candidate for the root cause.
사고형과 감정형은 종종 상대의 선호 유형을 참을 수 없어한다. 조직 내에서 당신은 의사결정이 이루어질 때마다 T/F 선호를 실제로 목격할 수 있을 것이다. 양쪽 유형 모두 좋은 의사결정을 원한다. 하지만 무엇이 좋은 의사결정인지에 대해서는 다르게 생각한다. 많은 T/F 문제는 의사 결정의 올바른 환경을 설계하는 것으로 해결될 수 있다. Thinkers and Feelers are often intolerant of each others' preferred style. In an organization, you can see the T/F preference in action whenever decisions are to be made. Both types want good decisions, but they differ in what attributes make a decision good. Many T/F problems can be solved by designing the correct environment for decision making.
판단형은 상황이 확정되는 것을 선호한다. 반면에 인식형은 선택지가 열려있어서 더 많은 정보가 선택에 영향을 주는 것을 선호한다. J/P 차이는 종종 엄청 큰 충돌의 원인이 된다. 엄청 큰 끌림의 원인이 되기도 한다. 그들은 서로가 필요하기 때문이다. The Judging (J) preference is to have things settled, while the Perceiving (P) preference is to keep options open on the chance more information will affect the choice. Judging/Perceiving differences are often the source of great conflict, as well as the source of great attraction, because each needs the other.
Chapter 8. 기질 차이 (Temperament Differences)
Summary
MBTI 각 차원의 조합은 16개의 유형을 만들어낸다. 하위의 조합은 개인 성향을 보는 유용한 관점을 제공해준다. 커시와 베이트의 4가지 기질도 그 중 하나이다. The combination of MBTI dimensions produces 16 identifiable personality types. Sub-combinations produce other useful views of personality, such as the four temperaments of Kiersey and Bates.
우리는 편의상 제어의 네 가지 다른 종류를 식별할 수 있다: 지성의, 물리적인, 응급 대처, 정서적인. 이것들은 4가지 기질과 연관시킬 수 있다. We can conveniently identify four different kinds of control: intellectual, physical, emergency control, and emotional, which we can relate to the four temperaments.
소프트웨어 분야에서 대부분의 주요한 혁신은 지성적 제어를 향상시키는 것에서 이루어졌다; 최소한, 그들은 가장 주목받는 종류의 혁신이기는 하다. Most of the major innovations in software have been in the area of improving intellectual control; at least, they were the innovations receiving the most attention.
물리적 제어는 소프트웨어의 순수한 지성적 모델로부터 파생된 실제 세계를 방지나 탐지, 교정을 통해 다루기 위해 소프트웨어에 도입되었다. Physical control is introduced into software to deal with real world deviations from the pure intellect model of software, either by prevention or detection and correction.
우리가 지성적이고 물리적인 문제를 다루기 위해 루틴을 개발하면, 잘 관리하는 우리의 능력을 발견하게 될텐데, 그것은 반복적인 상황을 다루는 능력에 의존하는 것이 아니라 예외적인 상황을 다루는 능력에 의존한다. As we develop routines to handle intellectual and physical problems, we find our ability to manage well depends not on our ability to handle routine situations, but on our ability to handle exceptional situations.
때로는 상황이 물리적으로나 지적으로 간단해서 응급 상황이 아닌 경우가 있다. 하지만 사람들은 여전히 완벽하게 행동하는 것에는 실패한다. 사람들이 개입되는 한, 제어를 위한 다른 세 가지 유형은 정서 제어를 빼면 의미가 없게 된다. Sometimes, the situation is physically and intellectually simple with no emergency conditions, yet people still fail to perform perfectly. As long as people are involved, the other three types of control become meaningless without emotional control.
강한 정서는 전형적인 행동을 만들어낸다. 다시 말해, 행동의 다양성이 감소된다. 다양성을 감소시키는 어떤 것이든 관리자의 제어 능력을 감소시킨다. Strong emotions produce stereotyped behavior, which means behavioral variety is reduced. Anything that reduces variety reduces the manager's ability to control.
비저너리 (NT)는 아이디어를 가지고 일하는 것을 좋아한다. 촉진자 (NF)는 사람들이 성장하도록, 하지만 사람들이 고통받지는 않도록 주의하면서, 돕는 것을 좋아한다. 조직자 (SJ)는 질서와 시스템을 좋아한다. 트러블 슈터 (SP)는 일을 끝내는 것을 좋아한다. The Visionary (NT) likes working with ideas. The Catalyst (NF) likes working with people to help them grow, but is concerned that people not suffer. The Organizer (SJ) likes order and system. The Trouble-shooter (SP) likes getting the job done.
각 소프트웨어 문화 패턴은 다른 종류의 제어를 선호하기 때문에, 각 기질은 각 패턴에 대해 다르게 행동한다. 확인되지 않은 각 기질은 각자 특징적인 방법으로 overrun하는데 기여할 것이다. Because each software cultural pattern favors different kinds of control, each temperament reacts differently to each pattern. Each temperament if unchecked will contribute to overruns in characteristic ways.
모든 기질의 사람들은 오류에 반응하는데, 다른 방식으로 대응하곤 한다. 관리자들은 이러한 반응들을 사용하여 사람들이 오류를 방지하도록 동기부여할 수 있다. People of all temperaments react to errors, but they tend to react in different ways. Managers can use these reactions to motivate people to prevent errors.
관찰할 때, SJ와 SP는 '자기(self)' 위치를 취하기가 쉽다. NF는 '다른 이(other)' 위치를 취하기 쉽고, NT는 '맥락 (context)' 위치를 취하기 쉽다. When observing, the SJs and SPs easily take the "self" position; the NFs easily take the "other" Position; and the NTs favor the "context" Position.
다른 사람들과 상호작용할 때, NT는 (정보)수용(intake) 단계를 건너뛰고 곧바로 의미로 가는 경향이 있다. 반면, NF는 곧바로 중요성으로 건너뛰는 경향이 있다. SJ는 수용(intake)에서 너무 오래 머물면서 너무 많은 사실(fact)을 수집하는 경향이 있고, SP는 실제로 전체 프로세스를 사용하기는 하지만, 그게 너무 빨라서 다른 사람들이 보기에 즉시 응답하는 것처럼 보일 수 있다. In interactions with other people, the NTs tend to bypass the Intake step and go instantly to meaning, while the NFs tend to jump immediately to significance. The SJs tend to stay in Intake too long, gathering too many facts; while the SPs actually use the whole process rather well, but tend to go so fast it looks to others as if they leap instantly to Response.
Chapter 9. 차이를 자산으로 여기기 (Differences as Assets)
Summary
이해되거나, 수용되거나, 잘 다뤄지지 않으면 어떠한 차이도 중요해지지 않는다. Any difference can become important when it is not understood, accepted, or handled well.
소프트웨어 비즈니스는 한 사람의 관리자가 많은 기술자들에게 그들이 무엇을 해야할지 정확히 이야기해주는 방식으로는 효과적으로 제어되지 않는다. 제어는 모든 사람이 관여하는 가운데 있어야 하고, 그것은 그 과정에 있는 매우 많은 개인들의 차이점들이 다루어진다는 것을 위미한다. The software business is unlikely to be controlled effectively by one manager telling a whole lot of technical people exactly what to do. Control must reside within every person involved, meaning a great many individual differences in the way things are handled.
MBTI 연구들의 한 가지 교훈은 "이 작업에 어떤 유형이 적합할까"라는 질문에 일반적인 경우 완벽한 대답은 없다는 것이다. 일반적으로 이런 연구들은 모든 유형의 사람들이 어떤 역할이든 할 수 있다는 것을 보여준다. 물론 어떤 종류의 작업에는 특정한 유형의 선호가 존재하기도 한다. One lesson of the MBTI studies is there is generally no perfect answer to the question "Which type is right for this job?" Generally these studies show people of all types can do almost any job, although there are preferences for certain types in certain kinds of work.
소프트웨어 작업은 다양한 작업들로 구성되기 때문에, 어느 하나의 성향도, 어떤 하나의 스킬 셋도, 하나의 관점도 전체 소프트웨어 작업의 모든 부분에 최고로 적합한 것은 없다. 이것이 소프트웨어 인력 중에 차이점이 필요한 이유이다. Because software work consists of so many varied tasks, it's unlikely any one personality type, one set of skills, or one point of view would be best suited to all parts of the total software job. That's why we need differences among software people.
선택에 의한 관리 접근법은 기술 스텝에 대한 1차원 선택 모델에 기반을 두고 있다. 이 접근법은 '나쁜' 프로그래머를 식별하고 (또는 어떠한 다른 기술 포지션이든), 그 중 가장 나쁜 것을 제거하고, 평균 능력치가 상승할 때까지 이 과정을 반복한다. The Management by Selection approach is based on the One-Dimensional Selection Model applied to the technical staff. This approach identifies the "bad" programmers (or any other technical position), gets rid of the worst ones, and repeats this process so the average ability rises.
이 접근법은 향상을 보여주기에는 느리다. 그리고 중소형 결과만을 냈다. 이 방법은 계속적으로 새 프로그래머가 고용되어야 하고, 지원자들 사이에서 당신 조직의 평판에 흠집을 낼 것이다. 이 방법이 정말로 그들의 퍼포먼스에 초점을 우지 않고 있기 때문에 당신의 최고의 성과자들은 떠날 것이다. This approach is slow to show improvement, and produces only mediocre results. The approach requires a continuing supply of new programmers, and may damage your organization's reputation among job applicants. Your best performers may leave because this method doesn't really focus on their performance.
시스템적인 개선 접근법은 다차원 사고를 기반으로 한다. 이 모델은 "훌륭한" 프로그래머(또는 다른 기술적인 역할)를 식별하고, 최고 성과자의 퍼포먼스를 분석해서 그들이 왜 그렇게 잘하는지 파악하고, 그들의 베스트 프로세스를 더 많은 수의 사람들에게 전파하는 시스템(훈련하기, 테크니컬 리뷰, 팀, 멘토링, 모델링)을 개발한다. The systematic improvement approach is based on multi-dimensional thinking. The model is applied by identifying the "good" programmers (or any other technical position), analyzing the performance of the best to determine why they are doing so well, and developing systems (training, technical reviews, teams, mentoring, and modeling) for passing these best processes on to large numbers of people.
이런 시스템적인 개선 접근법은 이렇게 말한다, 프로세스에 대한 관심이 무엇이 효과적인지에 대한 자각을 높일 것이다; 훈련은 현존하는 효과적인 프로세스들에 대한 통찰을 증가시키고; 효과적인 프로세스를 식별하는 것은 비효과성을 폐기하도록 만든다. The systematic improvement approach says attention to process will increase awareness of what's effective; training increases penetration of existing effective processes; and identifying effective processes leads to abandoning the ineffective.
기술적인, 관리적인 스텝들을 다른 문화로부터 수입해오는 조직들은 그들의 업무 환경에 매우 큰 풍요를 더하는 것이다. 이러한 문화의 풍부함은, 하지만, 그것을 다루기 위한 훈련이나 경험이 거의 없는 관리자에게는 항상 장점만 있는 것은 아니다. Organizations importing technical and managerial staff from other cultures add greatly to the richness of their working environment. This cultural richness, however, doesn't always seem like an advantage to the managers, who seldom have the training or experience to deal with it.
어떤 이유에서건, 대부분 문화에서의 남자와 여자는 - 평균적으로 - 어떤 분야에서는 다르게 행동한다(다뤄진다?). 남자를, 혹은 여자를 선호하는 관리자는 그들이 얻을 수 있었을 굉장한 정보와 아이디어의 절반을 못얻는다는 것을 알게 될 것이다. For whatever reason, men and women of most cultures operate—on average—differently in some areas. Managers who favor "male" or "female" values may find themselves cut off from half the best information and ideas available to them.
사람들은 NLP에서 전략이라고 부르는 부분에서 매우 큰 차이를 보인다. 그것은 사람들이 문제를 해결할 때 정보를 수용하는 방법 - 그들의 내부의, 외부의 그림, 소리, 냄새, 취향(tastes), 느낌 등 - 을 정리하는 프로그램이다. 서로 다른 전략의 도구(toolkit)는 소프트웨어 작업의 어려운 국면들에서 훌륭한 자산이 될 수 있다. People differ greatly in what neurolinguistic programming calls their strategies. These are the programs by which people order the ways they take in information—their internal and external pictures, sounds, smells, tastes, and feelings—when they solve a problem. A toolkit of different strategies can be great assets in many difficult aspects of software work.
대부분의 소프트웨어 사람들은 그들이 다른 능력을 가졌다면 다르게 대우해도 좋다고 믿는다. 하지만 그들은 능력을 인식하는 방법은 모른다. 대부분은 그들이 각자 다른 부분에 뛰어나다면 사람들을 다르게 대우해도 좋다고 믿지는 않는다. 하지만 그들로부터 배울 수 있는 것을 사용하는데는 실패한다. 마지막으로 나이에 기반한 차이 (젊은걸 선호하던 나이든걸 선호하던)는 우리는 잘 알아채지 못하지만 소프트웨어에서, 나이 차이로부터 얻을 수 있는 배움으로 장점을 취하기는 커녕, 보편적이다. Most software people believe it's okay to treat people differently if they have different abilities, but they don't know how to recognize ability. Most don't believe it's okay to treat people differently if they are differently advantaged, but fail to use what they could learn from them. Finally, discrimination based on age (either favoring young or old) is so universal in software we seldom notice it, let alone take advantage of what learnings age differences can provide.
Chapter 10. 비일치성의 패턴들 (Patterns of Incongruence)
Summary
많은 조직에서 관리자는 시간이 부족한데, 다른 사람들의 비일치를 일치적으로 대응하는 능력이 부족하기 때문이다. 서로 다른 문화 패턴은 각자의 특징적인 비일치 패턴이 있다. 그래서 각 패턴은 관리자에게 서로 다른 짐을 부과한다. In many organizations, managers lack time because they lack the ability to deal congruently with incongruence in others. Different cultural patterns have their characteristic patterns of incongruence, so each pattern puts a different load on its managers.
비효과적인 행동은 문제를 해결되지 않은 채로 남겨둔다. 그래서 하나의 비일치는 다른 누군가가 풀어야 할 문제의 양을, 원래 발원자가 다뤄야 할 양보다 증가시킨다. 그래서, 불일치할수록 더 많은 문제해결 시간, 불 끄는 시간이 필요해진다. Ineffective actions leave problems unresolved, so one effect of incongruence is an increase in the number of problems someone other than the originator must deal with. Thus, more incongruence means more problem-solving or fire-fighting time.
소프트웨어 관리자의 주요 업무는 조직 안의 사람들이 그들의 소셜 스킬을 개발하도록 돕는 것이다. 사람들이 나이스한게 더 좋아서가 아니라, 기술적인 성공의 기반으로서 소셜 스킬이 점점 더 중요해지고 있기 때문이다. A major task of the software manager is to help people in the organization develop their social skills, not just because it's better when people are nice, but because social skills are becoming more and more important as a basis for technical success.
조직은 비일치적인 행동의 패턴이거나 일치적인 패턴의 행동 둘 중 하나에 고정(lock on)되는 경향이 있다. 이러한 차이를 만드는 것은 관리자의 결정 - 그들의 행동에 영향을 주고 다른 사람들에게 예시가 되는 결정들 - 이다. Organizations tend to lock on to either a pattern of incongruent behavior or a pattern of congruence. What makes the difference is the decisions of the managers—decisions which influence their behavior and become an example for others.
품질과 일정 사이에서 트레이드오프할 수 없다는 것을 느끼면서, 소프트웨어 관리자는 인간 상호작용의 품질을 희생시키고자 하는 유혹을 꽤 많이 받는다. 만약 그들이 그 유혹에 굴복하게 되면, 그들은 곧 품질과 일정 모두가 결핍되는 대가를 치르게 될 것이다. Feeling unable to trade-off either quality or schedule, software managers are too often tempted to sacrifice the quality of human interaction. If they yield to that temptation, they soon pay the price in both quality and schedule deficiencies.
회유하는(꾹 눌러참는) 패턴은 특히 패턴1 문화에서 보편적이다. 이것은 왜 그 문화를 임의(Variable) 문화라고 부르는지 잘 설명해준다. 하나의 예를 들자면, 리뷰 시스템이 없는 프로젝트는 결함을 마지막에 발견한다. 프로젝트에서 비용이 가장 큰 단계이다. 그리고 스케쥴에도 가장 큰 충격을 준다. 그러면 관리자는 이러한 일정의 지연을 그 이후에 리뷰와 테스트를 빼먹는 것을 정당화하는데 사용한다. The placating pattern is especially common in Pattern 1 cultures, which largely explains why they are called Variable cultures. To take one example, a project having no review system finds faults at the latest, most costly stage of the project, with maximum impact on schedule. Managers then use this delay in schedule to justify the omission of further reviews and tests.
비난하는 문화에서는, 특히 패턴2 (반복) 조직에서 - 실패를 일으킨 사람을 처벌하려는 유혹에 굴복하는 것은 곧 학대에서 벗어나기 위한 추가적인 노력으로 이끌 것이다. 반면에, 작업자들은 점점 더 학대적인 관리자에 대해 분개하고, 점점 반응하지 않는 더 많은 방법을 찾아내거나, 심지어는 관리자를 훼방(sabotage)하기도 한다. 그리고 이것은 더 많은 실패로 이끈다. In blaming cultures, especially in Pattern 2 (Routine) organizations, yielding to the temptation to punish the offenders for failures soon leads to extra effort to escape the abuse. On the other hand, the workers increasingly resent the abusive manager and find more ways to be unresponsive or even to sabotage the manager, which then leads to more failures.
중독 사이클은 이렇게 동작한다: X를 하면 징후를 완화시키는 짧은 사이클이 있다. X를 하면 같은 징후를 악화시키는 더 긴 사이클이 있다. 중복의 짧은 사이클은 X에 대한 믿음의 강도를 높인다. 그래서 X에 대한 믿음의 강도는 X를 하면 할수록 더 성장한다. 하지만 긴 사이클에 의해, X는 더 나쁜 상황으로 인도한다. The addiction cycle works like this: There is a short cycle in which doing X relieves symptoms. There is a longer cycle in which doing X makes those same symptoms worse. The short cycle of addiction contains the strength of belief in X, so the strength of belief in X grows the more X is used, although in the long cycle, X leads to a worse situation.
중독은, 그 기저에서는, 어떤 것을 하는데는 오직 하나의 길만 존재한다는 믿음이고, 그 방법으로만 되어야 한다는 믿음이다. Addiction is, at bottom, the belief there is only one way to do something and it must be done that way.
Chapter 11. 인간 행동에 대한 기술 (The Technology of Human Behavior)
Summary
사람들과 실용적인 수준에서 함께 일하기 위해서는, 일하는 관리자는 더 일치적인 관리를 성취하기 위해 매일 매일의 가이드로 사용할 수 있는 모델이 필요하다. In order to work with people on a practical level, the working manager needs a model usable as a day-to-day guide to achieving more congruent management.
사티어 상호작용 모델에서는, 응답은 반드시 모델의 마지막 단계에서만 해야 하는건 아니다. 예를 들어, 수용하는 과정에서, 나는 어떤 데이터를 입수한다, 그리고 더 많은 것을 열어두고 데이터를 필터링하여 줄이거나, 이미 가진 것에 대해 의미를 부여하는 것을 진행하거나 하는 것을 결정함으로써 응답을 한다. In the Satir interaction model, Response is not actually limited to the last step in the model. During Intake, for instance, I take in some data, then respond by deciding whether to open up for more, reduce the data by filtering, or proceed with making meaning of what I already have.
의미 단계 또한 응답을 포함한다. 데이터를 주요한 카테고리들로 쪼갠 다음에, 나는 내 개인적인 스타일에 따라 인식한 의미와 부합하도록 수용 단계를 열거나, 닫거나, 수정한다. The Meaning step contains a response as well. After breaking the data down into major categories, I open, close, or modify the Intake process to fit the perceived meaning according to my personal style.
각 가능한 의미들의 중요성은 내게 일어날 수 있는 가능한 결과들이라는 측면으로 생각할 수 있다. 그리고 선택된 가능성은 내 응답의 일반적인 패턴을 결정한다. The significance of each possible meaning can be considered in terms of the possible consequences to me, and the possibility chosen determines the general pattern of my response.
인간의 두뇌는 하나의 (일치된) 마음처럼 동작하지 않는 것 같다. 그보다는 마음들의 팀으로 동작하는 것 같다. 만약 내가 잘 대처한다면, 나는 서로 다른 상황에 대처할 수 있는 많은 마음들을 가지고 있는 것이다. 애쉬비의 필수 다양성의 법칙이 말하는 것처럼, 복잡한 시스템의 효과적인 제어기가 되기 원한다면 그렇게 해야 한다. The human brain seems to operate not as one mind, but as a team of minds. If I am coping well, I have many different minds to put in charge of different situations, as Ashby's Law of Requisite Variety says I must do if am to be an effective controller of complex systems.
내 내면의 "팀"의 많은 멤버들은 구분된 인격으로 생각할 수 있다. 그리고 (반은 진담으로) 잘 알려진 캐릭터와 동일시된다(?). 모든 캐릭터들은, 좋은 것이든 나쁜 것이든, 온전한 나의 일부분들이다. 그리고 당신이 나와 충분히 오랫동안 같이 일을 한다면, 당신은 결국 대부분의 등장인물을 보게 될 것이다. The many members of my internal "team" can be thought of as distinct personalities, and (half seriously) identified with well-known characters. All characters, good and bad, are parts of the whole me, and if you work with me long enough, you'll eventually see most of the cast.
사티어 상호작용 모델의 기저에, 우리는 하나의 나무를 상상할 수 있다. 그 가지들은 주어진 상황에서 내가 만들어낼 수 있는 다양한 의미들을 향해 뻗어있다. 그 나무의 뿌리는 나의 자아이다. 나무 기둥은 나의 열망으로 이루어져 있고, 그 각 가지들은 하나 혹은 그 이상의 기대들이 된다.(?) Underlying the Satir interaction model, we can imagine a tree whose branches lead to the various meanings I might make in a given situation. The root of the tree is my self. The main trunk is formed by my yearnings, each of which branches into one or more expectations.
기대는 보편적인 열망이 구체적인 아이디어로 번역된 것이다. 그 아이디어는 열망하던 것을 이뤄내거나 유보하도록 세상이 어떻게 동작하는지에 대한 것이다. 기대는 종종 내가 원하는 세상의 동작 방식을 나타내는 규칙의 형태로 나타나곤 한다. 심지어 그 규칙이 현재 상황에 부합하지 않을지라도, 나는 선뜻 그것을 포기하지 못한다. 왜냐하면 그것은 내 깊은 열망들을 달성하기 위해서 어떻게 생존할지에 대한 인생 초기의 경험들로부터 얻은 값진 정보들을 포함하기 때문이다. Expectations are the translation of universal yearnings into specific ideas about how the world works to produce or withhold what is yearned for. Expectations are often held in the form of rules that express the way I expect the world to work. Even though a rule may not apply to the present situation, I do not easily relinquish it, because it contains valuable information from my earliest experiences about how to survive in order to achieve my deepest yearnings.
상호작용에서 당신이 나의 의도를 인식하는 것을 방해하는 것은 내 개인적인 스타일이다. 내 대처 자세, 선호들, 배움들, 습관들, 중독들, 그리고 문화에 의해 형성된 표면이다. 내 의도에 도달하기 위해서는, 당신은 그 스타일에 침투하기 위해 인간 행동 모델을 사용해야 하고, 그것 기저에 있는 것을 발견해야 한다. Standing in the way of your recognizing my intent in an interaction is my personal style, the surface formed by my coping posture, preferences, learnings, habits, addictions, and culture. To reach my intent, you need to use a model of human behavior to penetrate that style and find what lies beneath it.
인간 행동의 기술은 소프트웨어 기술보다 몇 배나 더 복잡하다. 이 복잡성을 더 깊이 있게 볼 수 있게 되면, 나는 더 완전한 관계를 성취하고, 최소한의 에너지와 혼란만으로 사람들 (나 자신, 그리고 다른 사람들)을 관리할 수 있다. 이것이 내가 말하는 인간 행동의 숙련된 기술자가 된다는 것이다. The technology of human behavior is many times more complex than the technology of software. When I am able to see through this complexity to deeper levels, I am able to achieve a more complete rapport, and to manage people (myself and others) with minimal energy and disruption. This is what I mean by becoming a skilled technologist of human behavior.
QSM: Volume 3.2: Managing Teams Congruently
Contents
-
QSM: Volume 3.2: Managing Teams Congruently
-
Part I. 일치적인 관리 달성하기 (Achieving Congruent Management)
- Chapter 1. 비일치성 중독을 치료하기 (Curing the Addiction to Incongruence)
- Chapter 2. 회유 중독 끝내기 (Ending the Placating Addiction)
- Chapter 3. 비난 중독 끝내기 (Ending the Blaming Addiction)
- Chapter 4. 다른 사람들과 마주하기 (Engaging the Other)
- Chapter 5. 맥락에 대한 관점을 새롭게 하기 (Reframing the Context)
- Chapter 6. 정보 피드백 (Informative Feedback)
- Part II. 팀 맥락을 관리하기 (Managing the Team Context)
- Part III. Epilogue
-
Part I. 일치적인 관리 달성하기 (Achieving Congruent Management)
Part I. 일치적인 관리 달성하기 (Achieving Congruent Management)
Chapter 1. 비일치성 중독을 치료하기 (Curing the Addiction to Incongruence)
Summary
중독은 치료가 어렵기로 악명이 높은데, 대부분의 사람들이 중독을 인지하지 못하는 것이 첫번째 이유이고, 두 번째로는 중독의 역학을 이해하기 못하기 때문이다. 이러한 실패는 중독을 치료하는 몇 가지 효율적이지 않은 방법들에 대한 믿음으로 이어진다. 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.
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.
업무 상황에서, 우리는 사람들이 행동을 실천할 수 없을 정도로 중독에 너무 오래 머무르는지 신경쓰지 않을 수도 있다. 예를 들면, 코드 패치를 금지하는 것은 적절한 형상관리 시스템을 통해 절대적으로 강제될 수 있다. 중독자들은 그 시스템을 우회할 방법을 찾으려고 애쓰겠지만, 새 사람들은 중독자가 될 기회를 결코 갖지 않을 것이다. 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.
부정적 강화 모델은 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.
어떤 사람은 통증을 완화함으로써 - 달래거나, 구조하는 전략 - 중독을 치료할 수 있는다고 믿는다. 대부분의 경우, 구조 시도는 잠깐동안 고통 증상을 억제할 뿐이다. 반면에 결국 뭔가가 파괴될 때까지 점점 더 큰 노력이 필요해진다. 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.
다른 경우에는 구조자가 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.
효과가 있는 치료법은, 덧셈의 원칙을 사용하는 것이다: 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 (가변) 문화는 관리자가 질문하기를 두려워하거나 자리를 차지하는(?) 것을 두려워하는, 꾹 눌러참는 문화이다. Most of the ineffective Pattern 1 (Variable) cultures are placating cultures in which managers are afraid to ask questions or take positions.
이 가변하는 달래는 패턴은 컴퓨팅 초기 시절의 잔재인데, 기계들이 비싸고 융통성이 없어서 기술자들의 고용 안전이 보장되고, 고객과 관리자들은 기계를 복종시킬 수 있을 것 같은 기술자들을 두려워하는 시절이었다. 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.
이러한 유형의 달래는 조직은 낮은 품질을 생산한다. 왜냐하면 고객들은 자칫 프로그래머나 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.
몇 가지 저렴한 대안이 현장에 도착하자마자, 고객들은 그들의 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.
달래기는 자아존중감이 낮을 때 발생한다. 자아존중감을 높이는 것은 달래기를 막는데 도움은 되지만, 그것 자체만으로는 막을 수 없다. 달래기를 금지하려면, 고객에게 대안적인 서비스 통로를 제공해야 한다. 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.
내부 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.
아웃소싱은 당신이 달래는 고객이 되는 것을 의미하지는 않는다. 당신이 고객에게 선택권을 주게 되면, 고객은 비난할 필요가 적어지고, 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.
다수의 성공적인 패턴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.
락인된 유지보수 상황에서 달래게 되는 것을 방지하려면, 관리자는 다음의 하나 혹은 둘 모두를 채택하여, 프로그래머를 괴롭히는 위험을 감수해야 한다: 할당을 회전(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
비난을 정보로 대체하는 것은 소프트웨어 엔지니어링 관리에 상당한 발전을 가져온다. 특히 조직이 비난하는 행동에 중독되어 있을 때는 더욱 그렇다. Substituting information for blame provides a substantial advance for software engineering management, especially in those organizations addicted to blaming behavior.
조직의 비난 행동을 근절하기 위해서는, 소프트웨어 제품을 개선하면서, 그와 동시에, 관리자는 필요한 교정 피드백을 제공하는 일치적인 방법들을 배워야 한다. 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.
관리자가 비난 행동에 대응하여 잘못을 범하는 가장 쉬운 방법은 아마도 맞 비난하기에 빠져드는 것일 것이다. 비난하기는 사람들이 비난 받는 것을 피할 방법을 찾도록 동기부여한다. 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.
프로그래머가 자기 프로그램에서 발견된 오류로 인해 두들겨 맞은 경우, 그들은 오류를 숨기거나 오류에 대한 책임을 다른 사람에게 돌리려고 한다. 테스트와 개발 간의 계속되는 충돌의 대부분은 비난의 분위기에 대한 반응으로 발생한다. 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.
관리자들이 가져온, 수년 동안 그들의 기술자들로부터 학대받아온 것에 대한 복수의 염원은 종종 패턴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.
복수에 대한 열망이 같았기 때문에, 많은 조직들이, 모든 사람이 프로그래머를 비난하는 대처 패턴을 가지게 되었다. 어떤 경우에는 프로그래머들이 반격했는데, 대개는 초이성적이거나 연관성 없음(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.
모든 패턴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.
패턴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.
우리가 비난받을 때 느낄만한 고통에는 다음의 두 가지가 있다. 비난의 고통은 심판받는 것 같은 고통이고, 부적절하게 발견된다(?). 인식의 고통은 단지 새로운 정보를 얻는 데 드는 비용이다. 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.
그 중요성을 잃지 않으면서 일치적으로 비판을 전달하기 위해서, 나는 그 비판을 나 자신에 대한 서술과 맥락에 대한 서술로 단순하게 시작한다. 일치성은 동작한다. 항상 동작하지는 않는다. 하지만 어떠한 비일치적인 전략보다도 더 자주 동작한다. 게다가, 내가 좋아할만큼 빠르게 동작하지는 않지만, 결국에는 많은 시간을 절약해준다. 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.
비난하지 않는 조직의 핵심은 열려있음(개방성, 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.
비난하기는 상호작용에서 상대방을 배제하는 것에 기반한다. 그래서, 비난하기는 서로를 그들의 인간성 속에서 깊이 바라보는 사람들 사이에서는 살아남을 수 없다. 복종해야 할 상관이 아닌, 인간 대 인간으로 여기고 상호작용하는 사람이 비난하는 행동을 방지하는 경향이 있다. 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
달래거나 비난하는 조직에서는, 관리자는 아마도 관리받는 사람들을 대면(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.
달래는 조직에는, 대면의 부재가 깊이 뿌리박혀 있고, 많은 모습으로 나타난다. 이를테면, 많은 달래기는 타협이라는 이름 아래 숨겨져 있다. 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.
훌륭한 직원들과 상호작용하는 작고 잦은 체크포인트를 만드는 것을 통해, 관리자는 프로젝트 목표와 불일치하는 것에 너무 빠져들기 전에 훌륭한 아이디어의 유용성을 확인할 기회를 가진다. 하지만 달래는 관리자는 이러한 접근법을 약화시킬 것이다. 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.
달래는 행동을 끝내기 위해서는, 당신은 달래는 사람의 자아를 수식으로 다시 가져와야 한다. (달래는 사람이 자신의 자아를 고려하기 시작하도록 해야 한다). 때로 이것은 이중 바인드를 만들어서 이루어질 수 있다. 만약 당신이 한 방향으로 달래면, 다른 방향으로는 달랠 수 없을 것이다. 반대로도 마찬가지다. 때문에 당신은 완벽히 달랠 수 없다. 또 다른 형태의 이중 바인드는, "나를 달래기 위해서는, 나를 달래기를 멈춰야 해!". 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!"
비난하기는 몇 가지 방법으로 대면하기를 회피하기 위해 사용될 수 있다. 한 방법은, 규칙을 작성하거나 심지어 구현하는데 있어서, 자동화된 도구를 사용하는 것이다. 그러한 도구 안에 구현된 일반화된 비난은 종종 관련없는(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.
비난하지 않으면서 규칙과 표준을 정착시키는 일치적인 접근 중 하나는, 스텝들의 지능과 전문성(professionalism)을 존중하면서 그들에게 선택지를 주는 것이다. A congruent approach to setting rules and standards avoids blaming, respects the intelligence and professionalism of the staff, and gives them choices.
비난에 대한 한 가지 처방은, 사람들이 인적 자원(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.
초이성형 관리자는 종종 프로젝트나 조직에 대한 맥락을 그들이 감동적인 연설을 하거나, 비전을 작성하거나, 전략 계획을 발표할 때 한 번에 설정하려고 시도한다. 더 효과적이 되기 위해서는, 커뮤니케이션을 좀 더 작고 연관성 있는 피드백으로 쪼개야 한다. 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.
이메일은 누군가와 의사소통하기 원하는 초이성형 관리자에게 완벽한 매체이다. (그러한 관리자는 "누군가에게 의사소통하다"라고 말하기를 즐여할 것이다. "함께"라는 것을 무시하고. 단방향만이 충분하다고 믿는다.) 일치적인 관리자는 의사소통 방법에 다양한 선택지를 가진다. 그 선택은 일치성을 위한 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.
문맥과 접점이 없는 대처 스타일 (사랑하기, 증오하기, 무관심)은 조직 환경에서 스스로 교정되는 경향이 있다. 이러한 대처 스타일은 항상 비싼 오류를 만든다. 어떤 조직 문화도, 더 큰 조직의 부에 의존하지 않으면, 맥락에 대한 고려가 없이는 오래 견디지 못한다. 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.
비일치적인 관리자는 관련이 없거나 중요하지 않은 일들, 혹은 다른 사람들에게 위임해야 하는 일들로 항상 바쁘다. 예를 들어, 성과 평가를 할 때, 관리자는 관리 작업을 하는 것처럼 보이지만, 그냥 문제를 일으키고 있는 것이다. 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.
연인들은 자연스럽게 흘러가도록 홀로 남겨두는 것이 가장 좋다. 사랑은 지속되지 않는다. 하지만 증오는 오랫동안 조직의 내장을 갉아먹을 수 있다. 피의 불화를 다루는 실마리는 참여자들과 함께 사라진(고려되지 않고 있는) 맥락을, 달래지 않으면서, 직면하게 하는 것이다. 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
관리자의 기본 업무 중 하나는, - 말로건 행동으로건 - 상호작용이 발생되고 작업이 완료되는 맥락을 설정하는 것이다. 실제 환경에서는, 같은 맥락을 바라보는 너무 많은 가능한 방법들이 있고, 따라서 상황을 재구성할 수 있는 무한한 수의 방법들이 있을 수 있다. 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.
프레임은 공간일 수도 있고 시간일 수도 있다. 그것들은 규모가 변하면서, 또는, 다시 공간이나 시간이 변함에 따라 변화할 수 있다. 프레임은 유형이 될 수도 있다: 그것은 사물인가? 사물의 모델인가? 사물의 모델의 모델인가? 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?
소프트웨어 엔지니어링 관리자의 또 다른 중요한 업무는 조직의 모든 사람이 같은 관점(프레임)에서, 최소한 호환 가능한 프레임에서 일하도록 하는 것이다. 이것은 거의 대부분 언어, 기호의 시스템을 사용하여 이루어진다. 설정 맥락에서 관리 행동의 대부분은 기호적 커뮤니케이션을 재구성하는 방향으로 유도해야 한다. 그리하여 기호의 비선형성을 변환하거나 활용하여 안정성을 달성한다. 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.
상황은 전제의 사용을 통해 정해질 수 있다. 그것이 긍정적인 전제이든 부정적인 것이든. 가장 강력한 전제는 은밀하다. 자신의 연설에서 전제를 알아채지 못하는 관리자는 겉으로 보기에 비일치적인 반응으로 인해 계속해서 신비화딜 것이다...? 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.
우리가 의미를 부여하는 암묵적 멘탈 모델들은 사람마다 다를 수 있는 숨겨진 맥락을 설정한다. 이러한 모델들은 종종 상호작용의 놀라운 특징을 결정하는데, 각 사람은 서로 다른, 다른 사람에게 알려지지 않은, 프레임에서 동작하기 때문이다. 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.
'도움이 되는 모델'은 보이기에는 어떠하던지, 모든 사람들은 도움이 되도록 노력한다고 말한다. 심지어 당신이 너무나 명백하게 도움이 되지 않는 사람들을 대할 때조차도, 마치 그들이 도움이 되는 존재처럼 상황을 재구성하는 것은 상황을 개선할 수 있다. 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.
'악의적 모델'이나 '편집증 모델'은 누군가가 나를 해치려고 하기 때문에 상황이 잘못 흘러간다고 말한다. 상화을 재구성하는데 있어 이러한 방식들의 가장 나쁜 점은, '괴물 만들기 역동'을 통해 자기 충족(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.
'멍청이 모델'은 당신이 절대 악의에 기여해서는 안된다고 - 그렇지 않으면 어리석음에 기여할 수도 있었을 - 말한다-즉, 조금 더 젠틀한 리프레임이지만, '도움이 되는 모델'보다는 무언가 약간 부족하다. 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.
문화는 언어를 만들고, 언어는 문화를 만든다. 소프트웨어 엔지니어링 문화에서는 확실히 그렇다. 버그 언어를 사용하는 조직은 결함 언어를 사용하는 조직과는 다른 방식으로 소프트웨어를 개발하고 유지한다. 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.
누군가가 비일치적으로 말할 때, 누락된 self-other-context 요소를 삽입하여 상호작용이 일치적이 되도록 나아갈 수 있다. When someone speaks incongruently, you can move the interaction toward congruence by inserting missing self-other-context elements.
재구성(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.
재구성(reframing)은 완벽한 신념(perfrection beliefs)을 다루는데 특히 도움이 되고, 특히 자신의 신념인 경우에는 더 도움이 된다. Reframing is especially helpful in handling perfection beliefs, especially your own.
Chapter 6. 정보 피드백 (Informative Feedback)
Summary
관리자가 일치적으로 관리하려면, 각 상호작용은 반드시 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.
나의 칭찬과 비난 둘 모두, 내가 그렇게 할 자격이 있는 사람이고, 내가 보스라는 것을 전제하고 있다. 그들은 겁에 질린 자아가 숨을 수 있는 위장된 맥락을 제공한다. 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.
매니지먼트 교과서에서 사용되는 "피드백"이라는 것에는 몇 가지 서로 다른 정의가 있다. 가장 일반적인 것 중 하나는, "내가 보스야. 나는 너에 대해 옳고 그른 것(대부분은 그른 것)을 말함으로써 너에 대한 나의 지배력을 보여줄거야"라는 것이다. (피드백을) 주는 사람이 사람들을 직접 다루는 것을 두려워할 때, 피드백은 "나는 당신을 조종하고 있다"라는 의미를 가질 수 있다. 때로 피드백은 수신자(피드백 받는 사람)를 태워버리려는 분명한 의도를 가진다. "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.
이러한 모든 형식은 미래의 행동에 영향을 줄 수도 있고 그렇지 않을 수도 있는 현재에 전달된 과거 행동에 대한 정보로서 피드백의 정의에 적합하다. 그러나, 일치적인 피드백은 당신이 가지고 있지 않은 정보일 수 있으며, 유용하다고 느낄만한 것일 수 있고, 당신에게 적합한 방법으로 자유롭게 사용할 수 있다. 일치적인 피드백은 관계나 조직을 개선할 수 있는 최고의 기회를 제공한다. 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.
피드백은 언제나 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.
피드백은 여러 모양으로 온다: 말로 된 문장으로, 신뢰를 보여줌으로, 도전 기회를 제공함으로, 자유를 허용함으로, 감정을 표시함으로, 공감적으로 들음으로, 특히, 원하는 행동을 모델링함으로. Feedback comes in many forms: offering verbal statements, showing trust, offering a challenge, allowing freedom, showing feelings, listening empathically, and especially modeling desired behavior.
간단하고 정보적인 피드백은 때로 고통의 원인이 될 수 있고, 그래서 많은 관리자가 피드백 주기를 두려워한다. 종종, 관리자 스스로가 피드백에 대해 고통스러운 경험을 해왔다. 그들은 그것을 원한다는 것을 부끄러워하고, 그 안에 숨겨져 있는 갈고리를 두려워하고, 피드백을 주는 사람을 보면서 부러워하거나, 단지 연습 부족으로 기술이 부족하다. 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
각 기질마다 팀웍에 만족해할 수 있지만, 각기 다른 이유를 가진다. 예를 들어 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.
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.
오류 위치 팀(?)은 두 사람이 놓치는 오류가 한 사람이 놓치는 것보다 훨씬 적기 때문에, 쉽게 형성되고, 쉽게 생산적인 상태로 빠르게 전환할 수 있다. 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.
경쟁적 협력을 위한 경쟁은 일반적인 팀의 모드이다. 한 가지 예를, 누가 먼저 문제를 찾을 수 있는지 알아보기 위한 온화하고 우호적인 경쟁이다. 슈퍼 팀은, 각 팀들의 대표자들로 구성된, 또 다른 형태의 경쟁이 될 수 있다. 슈퍼팀은 가장 심각한 문제를 해결하기 위해 만나고, 슈퍼팀 구성원은 해결된 문제를 일상 회의에 다시 가져와서 모두가 해결 방법을 공유할 수 있도록 한다. 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.
팀은 또한 결합된 솔루션 아이디어 셋트가 한 구성원이 제공할 수 있는 것보다 클 때 문제에 탁월하다. 제안된 오류 해결에 대한 기술 검토는 예기치 못한 부작용을 예방한다. 적절하게 구성된 팀은 어느 개인보다 부작용을 예상하는데 더 뛰어나다. 이러한 아이디어의 결합 때문에. 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.
테스트와 리뷰는 모두 제품 개선에 쓰이지만, 리뷰는 프로세스 개선에도 쓰인다. 기술 리뷰는 대개 패턴 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.
매니저는 가능한 한 일찍 리뷰를 스케쥴한다는 아이디어를 설득하여 제품 및 프로세스 품질에 영향을 미칠 수 있다. 어떤 리뷰는 제품을 버리게 만들 수도 있을지라도, 프로세스에 대한 훌륭한 정보를 제공한다. 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.
기술 리뷰의 가장 놀라운 효과(잘 설계된 온라인 테스팅과 함께 사용된다면)는, 변동성을 줄이는 그 방법에 있다. 일반적으로 리뷰 및 기계 테스트는 품질을 개선하곤 하고, 결과적으로 후속으로 이어지는 테스트 시간을 줄이게 된다. 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.
매니저에게 더욱 중요한 것은, 리뷰가 품질 및 후속 테스트 시간의 변동성을 줄여준다는 것이다. 시스템 테스트에 전달되는 결함의 수에 변동이 적다는 것은, 시스템 테스트 시간이 더 예측가능하게 된다는 것이고, 그것은 더 좋은 관리가능성을 의미한다. 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.
패턴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
조직이 팀워크의 힘을 경험하면, 소프트웨어 유지 관리 및 개발을 처리하는 영속적인 팀을 도입하는데 유리할 수 있다. 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.
팀에는 시작 비용(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.
관리가 형편없을지라도, 일련의 프로젝트에서 팀을 재사용하여 팀 시작 비용을 회수할 수도 있다. 불행히도 더 나은 소프트웨어 조직만이 팀을 재사용하는 것 같다. 부주의한 관리자는 잘 동작하는 팀을 해체하는 경향이 있다. 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.
재사용 가능한 구성 요소는 하드웨어 및 소프트웨어 개발의 기본 단위이고, 소프트웨어 팀은 소프트웨어 엔지니어링 프로세스의 기본 설계 단위이다. 관리자의 업무는, 팀을 만들고, 육성하고, 유지하여, 안정적이고 예측 가능한 프로젝트로 구성 및 재구성할 수 있게 하는 것이다. 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.
많은 관리자가 성과가 좋은 유지보수 팀을 알아채지 못한다. 그러나 이들은 가장 재사용 가능한 팀이다. 유지보수 엔지니어들은 살아있는 시스템을 관리할 때 발생할 수 있는 높은 실수 위험을 줄이기 때문에 팀에 끌린다. 유지보수 팀은 또한 유지보수 커리어 함정 - 가장 크리티컬한 시스템을 관리하는 엔지니어들이, 형편없는 관리로 인해, 가장 잘 떠나곤 하는 - 을 제거한다. 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.
비효과적인 관리자가 종종 동기부여와 팀워크라고 부르는 것은 그 용어들의 실제 의미와 동일하지는 않다. 그들에게 "팀워크"는, "내 말을 의문 없이 따르는 모든 사람"을 의미하고, "동기부여"는 "모든 사람들이 열악한 상황에서 열심히 일하도록 압력을 가하는 것"과 같다. 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."
프로세스 개선에 의한 관리는 팀 프로세스 개선에 의한 관리로 확장될 수 있다. 이 접근법은 팀을 수립하고 각 구성원의 최선을 사용하는 기술을 훈련한다; 최고의 팀과 개인의 성과를 분석하여 그들이 잘하고 있는 이유를 파악한다; 이러한 최상의 프로세스를 전달하기 위한 훈련 및 기술 리뷰 시스템을 개발한다. 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
많은 관리자가 그들의 높고-위대한 태도로 팀 스피릿을 훼손한다. 다른 관리자들은 무의식적으로 효과적인 팀의 혜택을 누리려는 자신의 노력을 약화시킨다. 첫번째 그룹은 절망적이지만, 두번째 그룹은 더 일치적이 되는 방법을 배움으로써 나아질 수 있다. 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.
팀 기반 조직에서 관리자의 역할에 대한 가장 빈번한 혼동은 관리자와 팀 리더 사이에 대한 것이다. 팀 리더는 팀의 기술적 작업을 담당한다. 관리자는 둘 혹은 그 이상의 팀에 대한 비기술적인 방향을 담당한다. 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.
팀 내부 관점에서는, 관리자의 역할은 어떤 비기술적인 업무를 처리하여 팀 리더의 부담을 덜어주는 것이다. 외부 관점에서는, 관리자의 역할은 조직의 더 높은 목표 측면에서 팀을 제어하는 것이다. 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.
팀을 빌드하는 가장 좋은 방법은 도전적인 작업을 위임하는 것이다. 도전은 감성적인 반응으로, 과제 자체만큼 과제가 할당되는 방식에 영향을 받는다. 예를 들어, 각 기질은 다른 방식으로 도전을 받기 때문에, 효과적인 리더는 각 기질에 대해 도전을 재구성해야 한다. 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.
위임은 여러가지 이유로, 비관리자가 생각하는 것처럼 쉽지는 않다. 오해가 일어나기 쉽고, 잘못된 의사소통 수단을 사용하고, 실수를 저지르고, 일이 잘 풀리지 않고 사람들이 당신이 한 일에 대해 불평할 때 방어적이 되기 쉽다. 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.
관리자는 내부 팀 업무에 대한 통제의 정도에 대해 두 가지 실수를 한다: 너무 많거나, 너무 적다. 패턴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.
잘 기능하는 팀은 그 구성원들의 행동으로 알 수 있다. 그들은 모든 사람들이 결정에 참여하도록 한다. 그들은 서로와 연락을 유지하고, 모두가 기여할 기회를 느낀다. 그들은 하나가 되어 '우리'라는 말을 사용하여 말한다. 그들은 재미있다. 그들은 각자 서로의 개발적인 강점에 의지하고, 모두 팀을 위해 최선을 다하고 있다. 그들이 말할 때, 그들은 모든 사람이 이해하도록 주의를 기울인다. 그들은 각각 강하고 유용하다고 느끼지만, 팀으로서의 그들의 역량을 벗어나면서까지 그렇지는 않는다. 마지막으로, 그들은 진정으로 어떻게 느끼는지 모여주기 때문에, 그들을 모니터링하기가 쉽다. 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.
당신은 다른 징후에 대한 경보 상태를 트리거하기 위해서만 단일 사전을 사용하여 팀을 젠틀하게 관리한다. 개입을 할 때는, 팀빌딩을 하고 팀 문제 해결을 할 수 있는 기회로 사용한다. 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.
관리자가 잘 기능하는 팀을 부러워하기 쉽다. 그에 대한 치료법은, 성공적인 관리의 즐거움과, 팀의 성공에 성공적인 관리가 기여하는 부분을 강조하는 것이다. 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.
팀을 보상하려는 시도는 종종 역효과를 낼 수 있다. 무엇이 팀에게 진정으로 보상할 수 있는지 찾아내기 위해 팀과 같이 논의해보라. 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.
사람들을 처벌하는 것은 관리자의 일이 아니다. 사람들이 배울 수 있는 기회를 마련하는 것이 관리자의 일이다. 그것을 하기 위해서, 관리자는 엄마 오리(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.
퍼포먼스 평가는 팀 정신을 파괴할 수 있다. 가능하면 피하라. 만약 불가피하다면, 팀에게 요청해서 서로의 퍼포먼스를 평가하도록 하는게 더 효과적인 방법이다. 외부 퍼포먼스 점수는 팀의 전체 점수에 팀이 부여한 개인 점수를 곱하여 얻을 수 있다. 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
팀에 대한 관리자의 임무는 팀이 필요로 할 때 시작하고, 효과적으로 일할 때 그대로 내버려 두고, 그렇지 않을 때 중지하는 것이다. 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.
위기 가운데서 팀을 구성하는 것은 사소한 관리 업무가 안디ㅏ. 만약 조직이 심하게 우울해져 있다면, 새 팀의 첫 번째 미팅에서 숙련된 퍼실리테이터가 필요할 수 있다. 팀의 구성은 모든 사람이 고유한 기여를 할 수 있도록 해야 한다. 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.
수명이 긴 팀의 위기보다 더 나은 출발점은 유지관리 또는 개발에서 자연스럽게 형성된 팀을 사용하는 것이다. 비결은, 그들의 프로젝트가 성공적으로 완료되었다고 해서 그냥 그것들을 해체하지 않는 것이다. 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.
조직의 기존 팀도 변화의 장애물이 될 수 있다. 그들은 연대의 고리를 깨뜨리거나, 더 나은 일을 하지 못한 것에 대해 팀을 비난하는 방법으로 특별한 문제 해결 팀을 만들려는 시도를 볼 수 있다... (?) 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.
잘 기능하는 팀은 바쁜 관리자의 가장 큰 잠재적 자산이다. 관리자가 팀이 그들의 작업을 수행하도록 허용한다면. 진짜 팀은 전형적인 관리자보다 훨씬 강하며, 최고 경영진에 의해 위협받지 않곤 한다. 진짜 팀의 의견은 대개 훨씬 더 많은 무게를 가진다. 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.
팀은 프로젝트가 늦어지면 패닉에 덜 빠진다. 비일치적인 관리자는 스스로가 패닉에 빠질 때 다른 사람들이 침착한 상태로 남아있는걸 보기 좋아하지 않고, 종종 자신의 패닉을 다른 사람들에게 퍼뜨리려고 한다. 그러나 숙련된 팀은, 그냥 관리자의 비일치를 흡수하고, 대부분의 경우 진정 효과가 있다. 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.
외부에서 주입된 관리되지 않은 작업의 한 조각이 계획된 작업의 양을 붕괴시킬 수 있다. 팀은 고객 및 경영진의 시연과 같은 그러한 방해를 처리하기 위해 전문가 역할을 설정할 수 있다. 일반적으로, 팀은 현실적인 우선순위를 설정하고 충족하는 작업을 더 잘 수행할 수 있다. 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.
팀이 모든 문제를 스스로 처리할 수는 없다. 팀원이 다른 사람과 함께 일할 수 없어서 팀을 떠나야만 하는 경우들이 있다. 관리자의 업무는, 그럴 때 개입하여 팀의 구성을 변경하는 것이다. 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.
아마도 성공적인 팀워크의 주된 장애물은, "이건 내꺼야. 그러니까 다른 사람들이 건드리거나, 심지어 보지도 못하게 할거야", 또는, "그건 내 아이디어가 아니니까, 최소의 아이디어일 수 없어." 같은 개인의 태도일 것이다. 이러한 폐쇄적인 태도는 변함없이 소프트웨어의 재앙으로 이어지며, 반드시 지속되지 말아야 한다. 그 사람이 이러한 태도를 바꾸기로 결심할 수도 있다. 하지만 전형적으로는, 이 사람을 다른 사람과 교환해야 한다. 모든 사람이 소프트웨어 비즈니스에 적합하지는 않다. 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.
때때로 팀은 당신이 파악할 수 있는 이유 없이 역기능 상태가 되거나, 여러 사람들의 참여로 인해 역기능 상태가 된다. 그런 경우, 관리자는 상황에 개입해서 팀을 해체해야 한다. 이것은 보통 그런 멤버들에게 경고를 준 이후에 일어난다. 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.
관리자가 일단 사람들을 임명하면, 위기 상황이 닥쳤을지라도, 그 팀은 생명을 유지하고, 변화가 필요할 때 해산하기 어려울 수도 있다. 따라서, 팀이 작동하지 않는다면, 종료시킬 수 없는 팀을 만들지 말아야 한다. 임시 그룹을 만들 때는, 명확한 수명을 부여하고, 그 후에 그들은 스스로 존재 이유를 정당화해야 한다. 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.
역기능적으로 보이는 그룹은 당신이 단순히 의도한 것과 다른 기능을 제공할 수 있다. 그룹을 해체하기 전에, 그것이 어떤 기능을 제공하고 있는지 파악하려고 해봐라. 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.
QSM: Volume 4.1: Becoming a Change Artist
Contents
Part I. 변화가 실제로 어떻게 일어나는지 모델링하기 (Modeling How Change Really Happens)
Chapter 1. 몇몇 익숙한 변화 모델들 (Some Familiar Change Models)
Summary
소프트웨어 조직을 변경하려는 시도는 대개 부적절한 변화 다이나믹스 모델로 인해 실패한다. Attempts to change software organizations commonly fail because of inadequate models of change dynamics.
확산 모델은 모든 변화 모델 중 가장 단순하며 염료가 용액으로 확산되는 것처럼 조직으로 확산됨으로써 변화가 발생한다는 믿음을 기반으로 한다. The Diffusion Model is the simplest of all the change models and is based on the belief that change just happens by diffusing into the organization like dye diffuses into solution.
확산 모델에 대한 약간 더 정교한 관점은 변화의 확산이 구조를 가지고 있음을 인식한다. 이 구조에서 변수를 제어하면 확산을 제한적으로 관리할 수 있다. A slightly more sophisticated view of the Diffusion Model recognizes that the diffusion of a change does have structure. If we control the variables in this structure, we can manage diffusion to a limited extent.
확산 모델의 강점은 그것의 프로세스로서의 변화에 대한 관심이다. (반면에) 약점은, 자연의 힘에 대한 그 과정에 대한 통제권을 포기하는 것이다. The strength of the Diffusion Model is its attention to change as a process. The weakness is the abdication of control over that process to forces of nature.
'바닥에 구멍 모델' 또는 '엔지니어링 모델'은 변경 프로세스에 대한 제어를 추가하여 확산 모델의 약점을 교정하려고 한다. 이 제어에는 세 단계가 포함된다. The Hole-in-the-Floor, or Engineering, Model attempts to correct the weakness of the Diffusion Model by adding control of the change process. This control involves three steps:
위층에서 일하면서, 엔지니어들은 완벽한 시스템을 개발한다. Working upstairs, the engineers develop the perfect system.
변경 계획은 바닥에 구멍을 뚫는 것으로 구성된다. The change plan consists of drilling a hole in the floor.
시스템은 구멍을 통해 떨어지고 작업자들은 그것을 행복하게 사용한다 - 그것이 즉시 확산된 이후에. The system is dropped through the hole and the workers use it happily ever after—instant diffusion.
'바닥에 구멍 모델'은 사람의 본질에 대한 여러 가지 잘못된 가정을 하지만, 충분히 높은 수준에서 보면 변화에 대한 데이터에 적합하다. 도로의 측면을 변경해야 하는 그러한 몇 번의 경우, 가능한 한 '바닥에 구멍 모델'에 가깝게 변경하도록 노력해야 한다. The Hole-in-the-Floor Model is based on a number of false assumptions about the nature of people, but often fits the data on change if viewed from a sufficiently high level. Those few times when we must change the side of the road, we need to try to make change approximate the Hole-in-the-Floor Model as closely as possible.
'바닥에 구멍 모델'의 강점은 계획에 대한 강조이다. 이 모델에서 약한 점은 계획에 많은 필수 요소, 특히 인적 요소가 빠져 있다는 것이다. The strength of the Hole-in-the-Floor Model is the emphasis on planning. What's weak in the model is that the planning leaves out so many essential factors, most notably the human factor.
뉴턴 모델 (또는 동기부여 모델)은 변화에 대한 외부 동기의 개념을 소개하고, 다음과 같이 말한다 The Newtonian Model (or Motivational Model) introduces the concept of external motivation to change, and says
변경하려는 시스템이 클수록 더 세게 밀어야 한다. The bigger the system you want to change, the harder you must push.
원하는 변화가 빠를수록 더 세게 밀어야 한다. The faster the change you want, the harder you must push.
특정 방향으로 변경하려면 해당 방향으로 밀어야 한다. To change in a certain direction, you must push in that direction.
뉴턴 모델은 다음과 같이 생각한다: 사람들은 자신이 하는 일에 대한 선택권이 있고, 변화 과정의 일부로서 밀어붙임으로써 그들의 선택에 영향을 줄 수 있다. (그러나) 사람들은 뉴턴 모델이 암시하는 것만큼 단순하지 않기 때문에, 밀어붙이는 것은 종종 부메랑 효과를 만들어낸다. The Newtonian Model does recognize that people have a choice in what they do, and that their choice can be influenced by pushing them as part of the change process. It fails to recognize that people are not nearly as simple as the Newtonian Model implies, so that pushing often produces a boomerang effect.
간단한 뉴턴 모델의 유용한 개선 중 하나는 사회심리학자들이 역장 분석(field analysis)이라고 부르는 것이다. 이 방법은 다이어그램의 한쪽에는 변화에 대한 모든 힘을 나열하고 다른 쪽에는 변화에 반대하는 힘을 나열한 다음, 균형을 이동하는 방법을 찾는 것이다. One useful refinement of the simple Newtonian Model is what social psychologists call force field analysis, a method that is based on listing all forces for change on one side of a diagram and against change on the other, then looking for ways of shifting the balance.
뉴턴 모델의 강점은 동기의 형태로 인간 요소를 명시적으로 도입한 것이다. 그것의 약점은 사용되는 인간 모델이 완전히 부적절하다는 것이다. The strength of the Newtonian Model is the explicit introduction of the human element in the form of motivation. Its weakness is the totally inadequate model of humanity that's used: that people can be pushed around like billiard balls.
학습 곡선 모델은 사람들이 당구공이 아니며, 일반적으로 사람들이 당구공과 같은 변화 시도에 즉각적인 효율ㄹ성으로 반응할 수 없다고 생각한다. 또한 계획자가 희망하는 것만큼 대응하는 법을 배우는데 시간이 걸린다. The Learning Curve Model recognizes that people aren't billiard balls, and that people are usually unable to respond to change attempts like a billiard ball with instant efficiency. Moreover, it takes time to learn to respond as well as the planners would hope.
학습 곡선 모델은 인력 선발과 훈련을 통해 변화 과정에 영향을 미칠 가능성을 제시하며 대규모 계획에 매우 유용하다. 그러나 실제 조직에서 개인별로 문화 변화를 관리하기 위한 실용적인 도구로는 실패한다. The Learning Curve Model suggests the possibility of influencing the course of the change by personnel selection and training and is quite useful for large- scale planning. However, it fails as as a practical tool for managing cultural change person-by-person in a real organization.
학습 곡선 모델의 강점은 적응적인 인간 요소를 변화에 통합하는 것이다. 약점은 개별 인간의 세부 사항을 평균화하는 것이다. The strength of the Learning Curve Model is its incorporation of the adaptive human element in change. The weakness is the averaging out of details of individual human beings.
Chapter 2. 사티어 변화 모델 (The Satir Change Model)
Summary
변화를 효과적으로 관리하려면 감정적 반응을 이해해야 한다. 변화가 어떻게 일어나는지에 대한 VirginiaSatir의 모델은 개인 뿐만 아니라 개인 시스템에도 적용되며, 정서적 요인을 확실히 통합한다. To manage change effectively, you must understand emotional reactions. Virginia Satir's model of how change takes place applies to individuals as well as to systems of individuals, and definitely incorporates the emotional factor.
SatirChangeModel은 변화가 다음과 같은 네 가지 주요 단계로 발생한다고 말한다 The Satir Change Model says that change takes place in four major stages, called:
후기 평형상태, 혹은 오랜 평형상태 Late Status Quo, or Old Status Quo
혼돈 Chaos
통합과 연습 Integration and Practice
새 평형상태 New Status Quo
이 모델은 또한 우리가 변화하려는 방식을 변화하는 더 높은 수준의 변화, 또는 메타 변화를 설명한다. The model also describes a higher level of change, or meta-change, which involves changing the way we change.
후기 평형 상태는 시스템의 모든 출력을 제어하려는 일련의 시도의 논리적 결과물이다. 모든 것이 익숙하고 균형을 이루지만, 시스템의 여러 부분이 균형을 유지하는데 있어 불평등한 역할을 한다. The Late Status Quo is the logical outcome of a series of attempts to get all the outputs of the system under control. Everything is familiar and in balance, but various parts of the system have an unequal role in maintaining that balance.
후기 평형 상태 단계는 소위 위기에 앞서 항상 건강이 좋지 않은 상태이다. SatirChangeModel은 위기가 갑작스런 사건이 아니라, - 위기가 아니라 - 환상의 끝인, 오랫동안 건강이 좋지 않은 상태에 있었다는 것을 갑작스럽게 깨닫는 것이라고 생각한다. The Late Status Quo stage is a state of ill health that always precedes the so-called crisis. The Satir Change Model recognizes that the crisis is not a sudden event, but merely the sudden realization that things have been unhealthy for a long time—not a crisis, but the end of an illusion.
후기 평형 상태에서는, 사람들이 불안, 일반화된 신경증 및 위장 문제를 경험할 수 있다. 변비는 창의성 감각이 없는 혁신의 후기 현상을 특징인 과도한 통제에 대한 완벽한 메타포이다. 시스템이 후기 평형 상태에 있다는 가장 중요한 신호는 거부이다: 다른 모든 증상을 인식하지 못하거나 기꺼워하지 않는 것, 어느 일에도 충분한 중요성을 부여하지 않는 것이다. In the Late Status Quo, people may be experiencing anxiety, generalized nervousness, and gastrointestinal problems. Constipation is a perfect metaphor for the over-control that characterizes the Late Status Quo, where there is no sense of creativity, of innovation. The most important sign that the system is in Late Status Quo is denial: the inability or unwillingness to recognize all the other symptoms, or to attach enough significance to them to do anything.
시스템의 사람들이 더 이상 거부할 수 없는 상황이 발생할 때까지 시스템은 후기 평형 상태에 머무른다 - Satir는 그 상태를 외부 요소라고 부른다. 익숙함이 언제나 편안함보다 강력하기 때문에, 시스템은 일반적으로 외부 요소를 쫓아내고 후기 평형 상태로 돌아가려고 시도하고, 종종 성공한다. Systems stay in Late Status Quo until something happens that the people in the systems can no longer deny—a condition Satir calls the foreign element. The system usually tries—and often succeeds—to expel the foreign element and return to the Late Status Quo because familiarity is always more powerful than comfort.
외부 요소가 도착하면, 사람들은 보호적이고 방어적이 된다. 그러나 여전히, 외부 요소는 모든 종류의 새로운 활동을 불러일으키는 유일한 요소이긴 하지만, 그 대부분은 단순히 외부 요소를 추방하려는 것이다. When a foreign element arrives, people become protective and defensive. Still, the foreign element may be the only thing that arouses any kind of new activity, but most of that is simply trying to expel the foreign element.
결국에는, 일부 요소는 거부되거나 미뤄지거나 피할 수 없으며, 시스템은 이전 예측이 더 이상 작동하지 않는, 혼돈으로 진입한다. 후기 평형 상태 시스템은 붕괴된 것이다. Eventually, some foreign element cannot be denied or deferred or deflected, and the system goes into Chaos, where old predictions no longer work. The Old Status Quo system has been disrupted.
사람들은 임의의 행동을 시도하고 기존 평형 상태로 돌아가기 위해 필사적으로 포괄적이고 마법적인 해결책을 찾는다. 혼돈에 있는 사람들이 그들에게 일어나는 것을 인식하는 것은 쉽지 않을 수 있다. 그들은 미치겠고, 두렵고, 취약하다고 느낀다; 그리고 그들은 극도로 방어적이 되고 소원해진다. People try random behavior and desperately seek sweeping, magical solutions, to restore the Old Status Quo. It may not be easy for people in Chaos to acknowledge it's happening to them. They feel crazy, afraid, and vulnerable; and they become extremely defensive and alienated.
혼돈에서, 사람들은 이전에 본 적 없는 사람들과 마주치고, 존재한다는 것도 알지 못했던 기능들과 마주친다. 놀랄만한 몇몇 새로운 아이디어가 떠오를 수도 있지만, 어쨌든 그게 작동해도, 아주 잠깐동안만 동작한다. When in Chaos, people encounter people they've never seen before, and functions they never knew existed. Some startling new ideas may emerge, but if they work at all, they only work for a short time.
결국에는, 이러한 새로운 아이디어 중 하나가 실제로 가능한 것으로 보인다. 이것이 바로 변혁적 아이디어이다 - 통합과 연습 단계가 시작되는 바로 그 '아하!'이다. 혼란스러운 감정이 사라지고, 명백한 순간에, 모든 것들이 해결될 것처럼 보인다. 그러나, 명확성의 순간은 종종 감정이 앞뒤로 흔들리면서, 오래된 의심의 감정으로 대체된다. Eventually, one of these new ideas seems a real possibility. This is the transforming idea—the "AHA!" that starts the Integration and Practice phase. Chaotic feelings disappear, and at moments of apparent clarity, everything looks like it will be solved. However, the moments of clarity are often replaced by old feelings of doubt, as feelings swing back and forth.
통합과 연습 단계 동안, 사람들은 기분이 좋아지지만, 그 좋은 느낌을 통제할 수 없다고 느낀다. 그들은 일이 한번에 완벽하게 해결되지 않을 때 쉽게 실망하고, 그들이 명시적으로 찾지는 않지만, 많은 지원을 필요로 한다. During Integration and Practice, people feel good, but feel unable to control the good feeling. They are easily disappointed when things don't work out perfectly the first time, and need much support, though they may not seek it explicitly.
좋은 느낌의 주요 구성 요소는 종종 변혁적 아이디어와 함께 오는 'Aha'가 밀려오는 것이다. 하지만 이러한 밀려옴에 대한 기억은 너무 강렬해서, 그 변혁적 아이디어를 통합하는데 필요한 연습이 종종 잊혀진다. A major component of the good feeling is the "Aha" rush that often comes with the transforming idea. The memory of this rush is so strong, though, that the practice needed to integrate the transforming idea is often forgotten.
성공적인 연습은, 결국에는 새로운 평형 상태 단계로 이어진다. 익숙하지 않은 것이 익숙해지고, 새로운 기대치와 예측들이 진화한다. 사람들은 차분하고 균형잡혀 있으며 성취감이 있다. 그러나 그들이 변화 프로세스를 담당하지 않는 한, 새로운 현상의 새로움은 사라지고, 우리는 새로운 후기 평형 상태 단계로 표류한다. Successful practice eventually leads to a New Status Quo stage. Unfamiliar things become familiar, and a new set of expectations and predictions evolves. People are calm, balanced, and have a sense of accomplishment. But, unless they take charge of the change process, the newness of the New Status Quo wears off, and we drift into another Old Status Quo Stage.
Chapter 3. 변화에 대한 응답들 (Responses to Change)
Summary
SatirChangeModel에 따르면, 변화 프로세스는 여러 가지 선택의 포인트들을 포함한다 - 이 포인트들에서 개인이나 조직은 다음 중 하나의 방법으로 대응할 수 있다: According to the Satir Change Model, the change process contains many choice points—points at which the individual or organization can respond in one of several ways:
외부 요소는 거부될 수도, 거부되지 않을 수도 있다. The foreign element can be rejected, or not rejected.
외부 요소는 현실의 기존 모델에 조정될 수 있다. The foreign element can be accommodated into the old model of reality.
기존 모델은 외부 요소를 받아들이도록 변형될 수 있다. The old model can be transformed to receive the foreign element.
변혁은 그 모델에 통합될 수도, 통합되지 않을 수도 있다. The transformation can be integrated or not integrated into the model.
변혁된 모델은 연습을 통해 숙달될 수도, 숙달되지 않을 수도 있다. The transformed model can be mastered or not mastered through practice.
또한, 새로운 외부 요소를 명시적으로 도입하기 전에 얼마나 많은 시간이 소요되어야 하는지를 선택할 수 있다. In addition, there is the choice of how much time should pass before the explicit introduction of a new foreign element.
경영진이 변화를 발표하면, 많은 직원이 그 발표를 외부 요소로 인식하고 이를 거부하려고 한다. 이러한 거부를 처리하는 첫 번째 단계는 외부 요소에 대한 반대가 개인적인 공격이 아니라 완벽하게 자연스러운 것임을 깨닫는 것이다. 그런 다음 각 논쟁의 의미를 듣고, 더 중요한 것은, 그 뒤에 있는 감정적인 "음악"에 귀를 기울인다. 아마 감정에 대해 대응하는 것이 논쟁에 대응하는 것보다 더 성공적일 것이다. When management announces a change, many employees will perceive the announcement as a foreign element and attempt to reject it. The first step in dealing with these rejections is to realize that opposition to a foreign element is perfectly natural, and not a personal attack. Then listen to the sense of each argument and, more importantly, to the emotional "music" behind it. Responding to the emotions will generally be more successful than trying to counter the arguments.
다른 사람들은 외부 요소를 이전 모델에 적응시키는데 의지할 수 잇으며, 그들이 변화하고 있다고 진정으로 믿는다. 여기서 좋은 전략은 진정으로 이루어져야 할 일을 재치있으면서도 분명하게 하는 것이다. Other people may resort to accommodating the foreign element into their old model, and truly believe they are doing the change. A good strategy here is to be tactful yet explicit in what truly needs to be done to accomplish the change.
변화를 도입할 때 좋은 전략은 변화된 상태가 이미 이루어지고 있는 것과 얼마나 유사한지 강조하는 것이다. 대신, 변화를 도입하는 일부 사람들은 모든 것이 완전히 새롭고 다른다는 것을 강조한다. 변화에 성공하려면, 사람들이 실제로 방대한 양의 지식을 가지고 있음을 보여주어야 한다. 그래서 변화가 단지 그들의 지식 베이스에 조그만, 논리적인 증가에 불과하다는 것을 보여주어야 한다. A good strategy when introducing change is to emphasize how the changed state resembles what is already being done. Instead, some people introducing change emphasize how everything is entirely new and different. To be successful at change, you need to show people that they really have a vast amount of knowledge so that the change is only a small, logical increment to their knowledge base.
변화의 도입은 종종 새로운 방식이 실제로 통합되어야만 하는 시점에서 실패하곤 한다. 훈련에서, 실제 사례는 가장 효과적인 훈련이다. 특히, 환경이 실수를 저질러도, 새로운 자료에 통합하는데 필요한 속도로 가도 안전한 경우에 더욱 그렇다. 그리고 연습은 수업이 끝나도 끝나지 않는다; 실제 업무에 새로운 아이디어를 도입하려면 경험 많은 사람들로부터의 많은 지원과 안전이 필요하다. The introduction of a change often fails at the point where the new way must be integrated into practice. In training, real examples give the most effective practice, especially if the environment makes it safe to make mistakes and to go at whatever speed is needed to integrate the new material. And practice doesn't end when classes end; the introduction of new ideas to the actual job needs lots of safety and support from experienced people.
일단 이 변화가 몇 가지 작업 사례로 통합되면 혼돈으로 되돌아갈 가능성은 훨씬 낮아지지만, 조건이 충분히 나쁘다면 여전히 가능하다. 실제적인 변화를 실현하기 위해서는 사소한 조정이 많이 필요하며, 작은 예에서 스케일업까지 많은 시간이 허용되어야 한다. Once the change has been integrated into a few working examples, a return to Chaos becomes far less likely—but still possible if conditions are bad enough. Lots of petty adjustments are required to make any real change work in practice, and lots of time must be allowed for scaling-up from small examples.
아마도 변화하지 못하는 가장 흔한 원인은 타이밍의 문제, 즉 다른 변화로부터의 간섭일 것이다. 변화는 고립적으로 오지 않으며, LcLyman의 영역 이론은, 구역(zone)을 기반으로 새로운 외부 요소의 도입 시기를 맞추는 훌륭한 지침이다. Perhaps the most common cause of failing to change is the question of timing—the interference from other changes. Changes do not come in isolation, and McLyman's Zone Theory is an excellent guide to timing the introduction of new foreign elements, based on zones.
레드존은 이전의 외부 요소가 변형, 수용 또는 거부되기 전의 시간 간격이다. 시스템이 레드존에 있는 동안 새로운 외부 요소가 도착하면 두 외부 요소의 혼돈은 증가한다. 게다가, 외부 요소들 중 하나에 대한 변혁을 발견할 확률은 감소하고, 거부나 수용 가능성이 높아진다. The Red Zone is the interval of time before a previous foreign element is transformed, accommodated, or rejected. When a new foreign element arrives while the system is in the Red Zone, Chaos from both foreign elements increases. Moreover, the chance of ever finding a transformation for either foreign element decreases, and the likelihood of rejection or accommodation increases.
옐로존은 이전의 변혁이 여전히 통합되고 있는 시간이다. 시스템이 옐로존에 있는 동안 새로운 외부 요소가 도착하면, 성공적인 변화의 가능성은 줄어들지만, 레드존의 외부 요소만큼 심각하지는 않다. 그러나 연이은 옐로존 외부 요소들로 인해 이 시스템은 에너지 부채를 만든다. 성공적인 변화는 점진적으로 가능성이 낮아지고 생산성은 저하된다. The Yellow Zone is the time during which a previous transformation is still being integrated. When a new foreign element arrives while the system is in the Yellow Zone, chances of successful change are reduced, but not as seriously as with Red Zone foreign elements. With successive Yellow Zone foreign elements, however, the system builds an energy debt. Successful change becomes progressively less likely, and productivity drags.
그린존은 늦은 통합과 초기 신규 평형 상태 사이의 시간이다. 외부 요소가 그린존에 도착하면 시스템의 성공적인 변화 가능성이 극대화된다. 에너지 부채가 없을 뿐 아니라, 그린존의 성공적인 변화 하나하나가 다음번을 위한 기회를 증가시킨다. The Green Zone is the time between late Integration and early New Status Quo. When a foreign element arrives in the Green Zone, the system's chances of successful change are maximized. Not only is there no energy debt, but each successful Green Zone change increases the chances for the next.
그레이존은 시스템이 후기 평형 상태에 들어간 이후에 항상 잠시동안 존재한다. 외부 요소가 그레이존에 도착하면 사람들은 메타 변화 기술을 잃는다. 변화에 대한 오래된 학습은 그 유용성을 잃었기 때문이다. 이러한 메타 변화 능력이 없으면 변화는 다시 한번 더 느리고 어려워지고, 성공적인 변화의 가능성은 낮아진다. The Gray Zone is all the time after system has been in Late Status Quo for a while. When a foreign element arrives in the Gray Zone, people have lost some of their meta-change skills, for old learnings about change have lost their usefulness. Without these meta-change skills, change is once again slow and difficult, and the chance of successful change is lowered.
너무 많은 변화들로 인해 너무 급하게 서두르고 조직을 압박하는 관리자들은 그들이 가속하려고 하는 그 변화들을 느리게 할 뿐이다. 마찬가지로, 만약 관리자들이 "많은 변화로 그들을 때리고, 일부는 고착될 것"이라는 전략을 채택한다면, 그들은 결국 그들 중 어느 누구도 고착되지 않을 것이라는 것을 알게 될 것이다. Managers who are in a hurry and press the organization with too many changes too quickly will merely slow down the very changes they are trying to accelerate. Similarly, if managers adopt the strategy of "hit them with a lot of changes, and some will stick," they'll find that in the end, none of them will stick.
시스템의 모든 부분이 동시에 동일한 영역에 있는 것은 아니다. 이것은 개인에 이르기까지 조직의 모든 단계에서 사실이다. 변화는 높은 수준에서 관리되어야 하지만, 우리는 결코 개인에게 미치는 영향을 무시해서는 안된다. Not all parts of the system are in the same zone at the same time. This is true at every level of the organization, right down to the individual. Although change must be managed at a high level, we must never ignore the impact on individuals.
변화는 변화를 관리하는데 필요한 정보 흐름을 방해하는 경향이 있다. 가장 신뢰할 수 있는 정보는 변화를 경험하는 사람들의 감정 신호다. 이러한 신호를 사용하여 적절한 구역 전략 또는 제공해야 할 정보의 종류를 결정하라. Change tends to disrupt information flow needed to manage change. The most reliable information is the emotional signals from the people experiencing the change. Use these signals to determine the appropriate zone strategy, or what kind of information you need to supply.
평형 상태가 지속되는 동안, 오래된 피드백 메커니즘은 천천히 침식되어 간다. 정보가 흐르지 않는다. 행동은 덜 예측가능하며, 사람들은 종종 정보를 통해 얻는 것을 무시한다. 여기서의 개입은 사람들이 그것이 되어야 하는 것이 아니라, 무엇인지 인식하도록 하는 방향으로 이루어져야 한다. During an aging Status Quo, old feedback mechanisms are eroding slowly. Information is not getting through. Behavior is less predictable, and to make it more predictable, people often ignore what information does get through. Interventions here should be in the direction of getting people to recognize what is, rather than what it is supposed to be.
주요 변경사항의 경우, 시스템은 여러번 변화 모델을 거칠 수 있다. 시스템과 개인은 변화 주기 동안 배울 뿐만 아니라, 몇 번의 완전한 변화 주기 후에, 그들은 "배우는 것을 배운다" - 그리고 변화 과정에서 학습의 중요성에 대해서도 배운다. 경험 많은 변화 예술가들은 변화의 전망이 위협적인 사람들과 진정으로 도움이 되는 방식으로 대처할 수 있을 정도로 높은 자기 가치와 무한한 대처 능력을 느낀다. For major changes, the system may go through the change model many times. Not only do systems and individuals learn during the change cycle, but after several complete change cycles, they "learn to learn"—and they also learn about the importance of learning in a change process. Experienced change artists feel such high self-worth and unlimited coping ability that they are able to deal in a truly helpful way with those to whom the prospect of change is a threat.
Part II. 예상하는 조직?에서의 변화 예술가들 (Change Artistry in the Anticipating Organization)
Chapter 4. 변화 예술가 (Change Artistry)
Summary
문화적 변화를 이룬 조직을 들여다볼 때마다 우리는 '변화 예술가(change artist)'라고 부르는 수많은 사람들을 발견한다. 게다가, 우리는 이러한 변화 예술가를 조직의 모든 수준에서, 그리고 모든 단위에서 발견한다. 왜냐하면 문화적 변화가 일어나기 위해서는 모든 수준과 모든 단위에서 일어나야 하기 때문이다. 이러한 변화 예술가들이 존재할 때, 그들은 변화를 위한 개별적인 감정적 반응을 다루며, 따라서 변화 계획의 성공 가능성을 높인다. Whenever we look into organizations that have accomplished cultural changes, we find a large number of people who we call change artists. Moreover, we find these change artists at all levels of an organization, and in all units, because for cultural change to occur, it must occur at all levels and all units. When these change artists are present, they deal with the individual emotional responses to change, and thus increase the chances for success of any change plan.
예상하는(anticipating) 조직에서는, 어느 정도 모든 사람이 변화 예술가가 된 상태이다. 따라서 변화 예술성을 발전시키기 위한 헌신은 이러한 문화적 패턴의 두드러진 특징 중 하나이며, 변화를 위한 주요한 도구는 사물도 절차도 아닌, 사람이다. In the Anticipating organization, to some degree everybody has become a change artist, Thus, the devotion to developing change artistry is one of the distinguishing marks of this cultural pattern, and the primary tool for change is neither things nor procedures, but people.
변화 예술성은 변화를 촉진하는 방법을 알고, 무엇을 변화시켜야 하는지 알고, 언제 변화해야 하는지 알고, 조직 내에서 변화를 도입해야 할 위치를 알고, 변화를 수행함에 있어 누가 어떤 역할을 해야 하는지 아는 것으로 구성된다. 더 나아가, 그것은 큰 스트레스를 받을 때, 그리고 스트레스를 받는 사람들에게 둘러싸일 때 일치적인 행동을 취하는 능력으로 구성된다. Change artistry consists of knowing how to facilitate change, knowing what to change, when to change it, where in the organization the change should be introduced, and who should take what roles in carrying it out. Even more, it consists of the ability to take congruent action when under great stress, and surrounded by people under stress.
변화 예술가가 될 수 있는 방법은 단 한가지가 아니며, 작업마다 다른 것들이 필요하다. 중요한 것은 그랜드 플랜의 작은 조각 하나하나를 용이하게 하기 위해 적당한 시기에 적당한 장소에 변화 예술가를 두는 것이다. There is no single way to be a change artist, and different ones are needed for different jobs. The important thing is to have a change artist in the right place at the right time to facilitate each little piece of the grand plan.
변화의 각 단계는 다르며, 각 단계마다 다른 유형의 개입이 필요하다. 완전히 성숙된 변화 아티스트는 모든 단계에서 잘 운영할 수 있다: 늦은 평형 상태, 혼돈, 통합과 실천, 그리고 신규 평형 상태. 그러나, 어떤 변화 예술가들은 한 단계에서만 주로 효과적인데, 그것이 그들의 기술과 성격과 일치하기 때문이다. Each stage of change is different, and each stage requires different types of intervention. Fully matured change artists are able to operate well in all phases: Old Status Quo, Chaos, Integration and Practice, and New Status Quo. Some change artists, however, are primarily effective at only one stage, simply because it happens to match their skills and personalities.
NT 비저너리는 아이디어로 일하는 것을 좋아하고, 변화를 구현하기보다는 설계하는 것에 가장 관심이 많다. NF 촉진자는 사람들과 함께 일하는 것을 즐기며 그들이 성장할 수 있도록 도와주며, 사람들이 변화 과정의 힘든 부분을 통해 함께 일하도록 하는데 최고다. 질서와 시스템을 좋아하는 SJ 조직자는 선각자들이 지루해진지 한참 지난 후, 실제 실행으로 변화를 옮기는데 가장 뛰어나다. SP 문제해결사는 이 일을 마무리하는 것을 좋아하며 외부 요인을 부정할 가능성이 가장 적다. 왜냐하면 그것은 실행에 옮길 기회를 제공하기 때문이다. The NT Visionary likes working with ideas and is most interested in designing, rather than implementing, change. The NF Catalyst enjoys working with people to help them grow, and is best at keeping people working together through the rough spots of the change process. The SJ Organizer, who likes order and system, is best at carrying the transformation into actual practice, long after the visionaries have gotten bored. The SP Troubleshooter likes getting the job done and is least likely to deny the foreign element, because it offers an opportunity to swing into action.
기질은 단지 경향일 뿐이다: 우리가 생각 없이 행동할 때 본능적으로 할 수 있는 것이다. 좀 더 완전히 발전된 변화 예술가들은 자신의 경향을 인식하고, 그들의 강점을 존중하고, 그들의 약점을 기록하고, 그들이 현재 상황에 적합하지 않다면 그들을 따로 떼어놓는다. The temperaments are merely tendencies: what we may do instinctively when we act without thinking. More fully developed change artists recognize their tendencies, honor them for their strengths, note their weaknesses, and set them aside if they are inappropriate for the current situation.
세심한 관리가 없으면, 장기적 변화는 항상 단기적 편의에 희생된다. 이러한 편의성은 조직 내 어디에서나 본질적으로 고위 경영진의 시야에서 항상 일어난다. 그렇기 때문에 변화 예술가들은 조직의 구석구석에 있어야 한다. Without careful management, long-term change is invariably sacrificed to short-term expedience. Such expedience takes place all the time, everywhere in the organization, essentially out of the view of the high-level management. That's why change artists have to be in every nook and cranny of an organization.
패치 적용(기워입기)은 표준 프로세스를 위반하므로, 시간이 지남에 따라 추가적인 프로세스 위반을 조장한다. 이 패치는 한 지역에서 안정성을 유지하지만, 다른 여러 영역에서는 이질적인 요소다. 예상하는 조직의 변화 아티스트는 이 갈등을 해결하기 위해, 혹은 더 잘 다룰 수 있도록 준비하기 위해 프로세스를 진화시킨다. 마치 당면한 문제를 해결하는데 책임이 있는 해커들, 제품에 위해가 발생하지 않는 것을 확인하는 가디언, 더 이상의 발생을 방지하기 위해 프로세스를 수정하는 힐러 등으로 구성된 QUEST 팀처럼. The act of patching violates standard process, and so encourages further process violations over time. Though the patch maintains stability in one area, it is a foreign element in several others. Change artists in Anticipating organizations evolve a process to resolve this conflict, such as a QUEST team consisting of a hacker responsible for solving the immediate problem, a guardian responsible for seeing that no harm comes to the product, and a healer responsible for amending the process to prevent further occurrences, or to be prepared to handle them better.
아마도 변화 예술가가 배우기에 가장 어려운 기술은 어떤 사람들과 어떤 상황을 혼자 남겨야 하는지 아는 기술일 것이다. 변화 예술가들은 어떤 사람이나 부서가 스스로 일어설 의지가 있는지 알아채고, 개인이 원하는 것과 조직이나 변화 예술가가 원하는 것을 연결하는 방법을 배울 필요가 있다. Perhaps the toughest skill for a change artist to learn is the skill of knowing what people and what situations to leave alone. Change artists need to learn how to recognize whether a person or department is willing to help themselves rise, and to connect what the individuals want with what the organization or the change artist wants.
변화 예술성의 중요한 원칙 중에는 다음과 같은 것들이 있다: Among the important principles of change artistry are
항상 변화를 위한 에너지를 찾아서 함께 진행하라 Always find the energy for change and go with it.
부정적인 에너지에 빠져들지 말라 Don't get hooked into negative energy.
그들의 용어로 대화하며 실제로 문제가 무엇인지 알아보라 Talk in their terms and find out what the issues really are.
준비가 되면, 출처(source)를 찾아가라 Once you're prepared, go to the source.
한동안 아무 것도 하지 않아도 된다 It's perfectly all right to do nothing for a time.
Chapter 5. 대부분의 것을 동일하게 유지하기 (Keeping Most Things the Same)
Summary
변화 예술가의 가장 중요한 책임은 그 장기적이고 넓은 범위의 지식을 사용하여 무수한 실패에도 불구하고 대부분의 것을 동일하게 유지하는 것이다. 조직을 유지하는 방법을 알기 전까지는 조직을 바꾸는 방법을 모를 것이다. A change artist's first and foremost responsibility is to use that longer-term, wider-scope knowledge to keep most things the same even in the face of innumerable failures. Until you know how to maintain an organization, you will not know how to change one.
문화와는 상관없이 모든 조직은 자신을 유지하기 위한 메커니즘이 필요하다. 당신은 그것들을 유지하는 메커니즘을 조사함으로써 무엇이 유지되고 있는지를 발견할 수 있다. Cannon의 원칙은 이러한 정교한 메커니즘이 유지하고 있는 것만을 조사하는 방법을 보여준다. 이는 조직들이 유지하고 있다고 말하는 것과는 다를 수 있다. All organizations, regardless of their culture, need mechanisms to maintain themselves. You can discover what is being maintained by examining the mechanisms that maintain them. Cannon's principle shows you how to investigate just what these elaborate mechanisms are maintaining—which may not be what the organizations say they are maintaining.
일부 '가변적' 문화는 매니지먼트 파워, 특권, 위신의 시스템이 생존할 수 있도록 헌신한다. 그런 문화는 잘 짜여지고 잘 관리된 변화 프로젝트에는 적합하지 않다. Some Variable cultures are devoted to survival of a system of management power, perquisites, and prestige. Such a culture is not a good candidate for a well-planned, well-managed change project.
조직이 어떻게 측정하는지를 관찰하는 것은 Cannon의 원칙을 적용하는 좋은 방법이다. 예를 들어, 뒤쳐진 지표를 사용하는 것은 실패 지향적인 조직, 즉 실패한다고 가정하는 조직을 인식하는 좋은 방법이다. 실패를 막기 위해 노력하는 대신 관심을 끌지 않도록 고장 수준을 충분히 낮게 유지하는 작업을 하고 있다. 그들은 또한 그들이 다른 누군가를 비난하기 위해 사용할 수 있는 증거를 확립하기 위해 노력하고 있다. Observing how an organization measures is a good way to apply Cannon's principle. For example, the use of lagging indicators is a good way to recognize failure-oriented organizations, ones that assume they will fail. Instead of working to prevent failure, they are working to maintain the failure level low enough so they won't attract attention. They're also working to establish evidence they can use to point blame at someone else.
문화가 무엇을 중시하는지, 또 무엇을 유지하려고 하는지를 이해하는 또 다른 방법은, 그것이 무엇을 측정하는지 검토하는 것이다. 가장 흔한 문화 중 두 가지는 소비와 생산의 측정으로 특징지어진다. 회계관리자들은 일반적으로 소비로 측정한다. 기술관리자는 일반적으로 생산에 따라 측정한다. Another way to understand what a culture values, and what it is trying to maintain, is to examine what it measures. Two of the most common cultures are characterized by the measurement of consumption and the measurement of production. Accounting managers typically measure by consumption. Technology managers typically measure by production.
'예상하는' 문화에서 회계심리학이나 기술심리학 모두 소프트웨어 엔지니어링 업무에 적합하지 않다 - 첫째로, 소비나 생산만으로는 충분한 척도가 되지 않기 때문이고, 둘째로, 두 가지 모두를 합치면 조직의 미래 생존 능력을 설명하기에 불충분하기 때문이다. Neither the accounting mentality nor the technology mentality are adequate to the job of software engineering in an Anticipating culture—first, because neither consumption or production alone is a sufficient measure and, second, because both together are inadequate to explain the organization's ability to survive in the future.
실패의 문화나 관리 파워를 유지하는 이러한 시스템은 ChrisArgyris가 옹호하는 표층이론과 사용이론이라고 부르는 것의 사례이다. '예상하는(패턴 4)' 문화를 이루기 위해서는 이러한 숨겨진 목적을 드러낼 필요가 있다. These systems of maintaining cultures of failure and/or management power are examples of what Argyris calls espoused theory versus theory-in-use. To achieve an Anticipating (Pattern 4) culture, you need to lay bare these hidden purposes.
과정을 설정하고 나서 그것이 영원히 계속되리라고 기대하는 것만으로는 충분하지 않다. 지속적인 수정이 없으면, 어떤 공정이든 악화되고, 공정이 악화되면 반드시 제품의 수질이 저하된다. It's not sufficient to set up a process and then expect it to go on forever. Without constant tending, any process will deteriorate, and deterioration of the process invariably leads to deterioration of the product.
설계 열화는 잘 늙지 않은 일련의 설계 결정의 결과물이다. 그러한 근시안적인 설계 결정은 기존 소프트웨어 재고가 가지고 있는 설계 부채를 약간 더한다. 비록 단일 설계 악화가 충분히 크거나 흥분되는 것으로 보이지는 않지만, 그러한 결정을 몇 십 년 동안 내린 후, 그리고 그러한 결정을 수정하려는 노력이 거의 없었던 후, 많은 IS 조직은 '후기 평형 상태'에 빠져 있다. Design deterioration is the result of a set of design decisions that didn't age well. Each such short-sighted design decision adds a little to the design debt carried by the existing software inventory. Although no single design deterioration seems sufficiently large or exciting to fuss about, after a couple of decades of such decisions—and little effort to correct them—many an IS organization finds itself in Late Status Quo.
유지 관리의 악화는 그들의 설계를 완전히 보존하지 않는 방식으로 프로그램을 패치하는 것에서 온다. first-class 설계는 수년간의 성급하게 고려된 패치를 견디면서 결국에는 쓰레기로 변한다. Maintenance deterioration comes from patching programs in a way that does not entirely preserve their designs. A first-class design endures years of hastily considered patches and finally turns to trash.
설계 유지 부채는 설계부채와 유지부채를 합한 것이다. 기능 포인트나 코드 라인의 변경의 '크기'가 아닌, 설계 유지보수 부채는 기존 시스템을 수정하는 비용의 주요 결정 요인이다. 이러한 부채는 종종 소프트웨어 엔지니어링 문화를 변화시키는데 중요한 비용과 복잡 요소다. Design maintenance debt is the sum of design debt and maintenance debt. Design maintenance debt—not the "size" of the modification in function points or lines of code—is the major determining factor in the cost of making a modification to an existing system. This debt is often a major cost and complication factor in changing a software engineering culture.
많은 소프트웨어 엔지니어링 조직에서, 변화 예술성 부채는 코드 산더미에서 숨겨진 부채를 근절하는데 정면으로 방해가 된다. 몇몇 조직들은 그들의 변화 예술성을 은밀한 의사소통, 버디 시스템에 의한 홍보, 명성을 더럽히기 위해 사용되는 소문, 위험 인물에 대한 처벌, 그리고 판매업자들의 특별 호의를 받아들이는 것으로 적극적으로 공격해왔다. In many software engineering organizations, change artistry debt stands squarely in the way of eradicating the hidden debts in mountains of code. Some organizations have actively attacked their change artistry with covert communications, promotion by buddy system, rumors used to tarnish reputations, punishment of risk-takers, and acceptance of special favors from vendors.
MOI 모델은 변화하기 위해서는 동기, 조직, 정보가 필요하다고 말한다. 변화를 위해서, 동기는 많은 원천으로부터 올 수 있지만, 변화에 대한 동기는 위험을 감수하는 두려움 때문에 사라질 수 있다. 조직은 좋은 전략 계획, 신뢰할 수 있는 인프라 (이메일, 회의시설, 전화시스템 등), 합리적인 예산, 일관된 문화 등 다양한 형태로 구성된다. The MOI Model says that in order to change, we need motivation, organization, and information. For change, motivation may come from many sources, but any motivation to change is killed by a fear of taking risks. Organization consists of a variety of forms, such as good strategic planning, a reliable infrastructure (such as e-mail, meeting facilities, and phone system), sensible budgets, and a consistent culture.
변화를 위한 정보는 두 가지 차원에서 필요하다. 첫 번째 종류인 다양한 변화 아티스트 스킬은 조직의 현재 제품 및 프로세스에 대한 두 번째 신뢰할 수 있는 데이터가 없으면 거의 소용이 없다. Information for change is needed at two levels. The first kind—the various change artist skills—are of little use without the second—reliable data on the organization's current product and process.
변화 예술성의 다양한 요소들이 관리 행동과 얽혀 있어, 시간이 지남에 따라 어떤 행동들은 조직의 변화 기술에 엄청난 적자를 낳는다. 이 부채를 극복하기 위해, 조직은 경영진의 주의가 필요하다. 관리자는 '예상하는' 조직으로의 변화를 촉진하면서 현재 조직에서 좋은 것을 보존하려면 자신의 행동을 통제할 수 있는 간단한 규칙이 필요하다. The various components of change artistry are intertwined with management behavior, so that certain behaviors over time create an enormous deficit in an organization's change skills. To overcome this debt, an organization needs management attention. Managers need simple rules to govern their behavior if they are to conserve what's good in the present organization while promoting change to an Anticipating organization.
변화 중에 좋은 것을 보존하기 위한 보자 효과적인 관리 규칙 중 일부는 다음과 같다: Some of the more effective management rules for conserving what's good during change are these:
비난하지 말라. 정보를 주고 받아라. Don't blame. Give and receive information.
회유하지 말라. 믿지 않는 일은 하지 마라. Don't placate. Take no job that you don't believe in.
초이성적 슬로건과 권고들을 배제하라. Cut out the superreasonable slogans and exhortations.
속임수를 쓰지 말라. 수단이 목적이다. No tricks. Means are ends.
신뢰하라, 그리고 ... Trust, and merit trust.
스스로에게 변화 기술을 훈련하는 것을 멈추지 마라. Never stop training yourself in change skills.
바로 주변에서 개선을 추구하는 것을 멈추지 마라. Never stop seeking improvements right around you.
다른 사람들처럼 당신도 어렸을 때 태어났다는 것을 기억하라. 단지 직함이 있다고 해서 인간이 되기를 중단하지 마라. Remember that you were born little, just like everybody else. Just because you have a title, you haven't ceased to be a human being.
당신 스스로가, 다른 사람에게 원하는 그 모범이 되라. Be an example of what you want others to be.
Chapter 6. 변화 아티스트 되기를 연습하기 (Practicing to Become a Change Artist)
이 장의 목표는 변화 아티스트가 구체적으로 무엇을 하며, 그렇게 되기 위해 어떻게 훈련받는지에 대한 아이디어를 주는 것이다. 만약 이런 도전과제들을 당신이 직접 한다면 누가 말리겠는가?
../Going to Work: 일하러 갈 때 평소와 다른 길로 가보기. 변화에 수반하는 혼돈 등의 감정을 스스로 느껴보기.
../Making One Small Change: 스스로 단 하나의 요소만 바꿔보기. 하나만 바꾼다는 것은 힘들다는 것 느껴보기.
- Changing Nothing: 아무 것도 하지 않고, 왜 변화의 필요를 느끼는지 발견해보기.
- Changing a Relationship: 누군가와의 관계를 변화시켜보기. 일치성과 충돌에 대해 배운 것을 직접 경험해보기.
- Being the Catalyst: 다른 사람의 변화 프로젝트를 facilitate해보기.
- Being Fully Present: 적극적 경청해보기.
- Being Fully Absent: 문제를 떠나있어보기. 일주일 동안 휴가를 가보고, 돌아왔을 때 어떤 것이 변해있는지 관찰해보기.
- Applying the Principle of Addition: 반복하면 강화된다. 어떤 사람에게 어떤 affirmation을 정해서, 매일 매일 줘보기.
- Organizing the Grand Tour: 다른 change artist를 사무실에 초대해서, 사무실의 사람들이 그 사람에게 '다른 팀에서 탐낼만한, 우리가 잘 하고 있는 것'을 설명하도록 하기.
- Learning from History: 당신이 비생산적이라고 생각하는 그 실천법의 역사를 발견해보기.
- Putting Theory into Practice: QSM의 아무 쳅터나 리뷰를 해보고, 구체적으로 실천해보기.
- Developing Yourself:
QSM: Volume 4.2: CHANGE: Planned & Unplanned
Contents
-
QSM: Volume 4.2: CHANGE: Planned & Unplanned
- Part I. 미래 조직을 위해 계획하기 (Planning for the Future Organization)
-
Part II. 어떤 변화들이 일어나야 하는가 (What Changes Have to Happen)
- Chapter 5. 안정적인 소프트웨어 엔지니어링의 요소들 (Components of Stable Software Engineering)
- Chapter 6. 프로세스 원칙들 (Process Principles)
- Chapter 7. 문화와 프로세스 (Culture and Process)
- Chapter 8. 프로세스 개선하기 (Improving Process)
- Chapter 9. 요구사항 원칙들과 프로세스 (Requirements Principles and Process)
- Chapter 10. 요구사항 프로세스를 변화시키기 (Changing the Requirements Process)
Part I. 미래 조직을 위해 계획하기 (Planning for the Future Organization)
Chapter 1. 메타-계획하기: Part I. 정보 (Meta-Planning: Part I. Information)
Summary
변화 예술가들은 세 가지 다른 시간 척도와 세 가지 다른 기술을 포함하는 세 가지 레벨에서 그들의 기술을 연습한다. "소규모의" 변화 예술성은 사람과 문제를 직접 대면하고 일상적으로 다룬다 - 우리가 전술(tatics)이라고 부르는 수준이다. Change artists practice their skills on three levels, involving three different times scales and three different sets of skills. Change artistry "in-the-small" deals with people and problems face-to-face and day-to-day—this level is what we call tactics.
전술이 모두 예기치 않은 사건에 대한 반응은 아니다. "중간에서의" 변화 예술성은 우리가 전술적 계획이라고 부르는 것이다: 그러한 사건들을 처리할 준비가 되어 있는 것을 기대하는 것이다. Tactics are not all reactions to unexpected events. Change artistry "in-the-middle" is what we call tactical planning: looking ahead to be ready to handle such events.
"큰 규모에서의" 변화 예술성은 우리가 전략적 플래닝이라고 부르는 것이다: 전술적(tactical) 계획이 이루어지는 풍토를 설정하는 것이다. 전략적 플래닝은 일반적으로 3년에서 5년의 기간에 걸친 두 가지 광범위한 질문을 다룬다: Change artistry "in-the-large" is what we call strategic planning: setting the climate in which tactical planning takes place. The strategic plan addresses two broad questions for a time interval that is typically three to five years in length:
어떤 제품/서비스를 제공할 것인가? What products/services will we supply?
어떤 프로세스/리소스/문화가 그것을 제공하기 위해 필요한가? What processes/resources/culture will we need in order to supply them?
전략적 플래닝 프로세스는 다음과 같은 질문을 통해 일부 비전의 실현 가능성을 추정할 수 있어야 한다: 지금 우리가 가지고 있는 프로세스/리소스/문화로 이러한 제품을 만들 수 있는가? 만약 그에 대한 대답이 '그렇다'라면, 프로세스 비전은 현재의 프로세스를 유지하고 완성하는 것 중 하나이다. 만약 '아니오'라면, 계획자들은 그들의 야망을 줄일 것인지 아니면 그들의 프로세스 비전을 높일 것인지를 결정해야 한다. The strategic planning process has to be able to estimate the feasibility of some of the visions by asking: Can we build these products with the processes/resources/culture we now have? If the answer is yes, then the process vision is one of maintaining and perfecting the present process. If the answer is no, then the planners must decide whether to reduce their ambitions or to raise their process vision.
잘 되었을 때, 변화를 위한 전략적 계획의 전체 과정은 다음과 같은 세 가지 주요 요소를 갖는 것으로 간주할 수 있다: When done well, the entire process of strategic planning for change can be regarded as having three major components:
관찰이나 무시 등을 포함한 정보 수집 information gathering, including observing and ignoring
시스템 사고, 협상 등을 포함한 문제 해결, 그리고 행동-생성 원칙으로 변환하기 problem solving, including systems thinking, negotiating, and translating into action-generating principles
역학(mechanics), 계획 수립 시기, 장소, 방법, 그리고 누가 관여하는지 알기, 전술과 전략의 차이를 이해하기 mechanics, including knowing when, where, and how the planning is done, as well as who is involved, and understanding the difference between tactics and strategy
전략적 의사결정을 위한 정보는 조직 내에서 나올 필요가 있다. 세 가지 유형의 문제는 전략 계획에 사용되는 정보의 품질을 손상시킨다. The information for making strategic decisions needs to come from both inside and outside the organization. Three types of problems plague the quality of the information used in strategic planning:
일부 필수 소스의 누락 omission of some essential source
신뢰할 수 없는 출처에 대한 의존 dependence upon an unreliable source
관련 세부 사항은 무시한 채 과도한 세부 정보 속에서 뒹굴대기 wallowing in excessive detail, while ignoring relevant details
세 가지 유형의 문제가 모두 해결될 때까지 합리적인 변경 계획을 위한 정보를 이용할 수 없다. 그 때까지 계획의 산출물을 메타 플랜으로 제한해야 한다. 계획 과정에 대해 수행해야 나머지 조직에 대해 효과적인 계획을 세울 수 있다. 대부분의 메타 계획들은 정보의 질과 양에 관련될 것이다. The information for sensible change planning is simply not available until all three types of problems are cleared up. Until they are, you need to restrict the output of the plan to meta-plans: plans that need to be carried out concerning the planning process before you can do effective planning on the rest of the organization. Most of these meta-plans will concern the quality and quantity of information.
누락된 정보의 대표적인 문제점은 다음과 같다 There are a number of typical problems of missing information:
계획 과정에서 고객의 바람을 고려하지 않음 failing to consider customers' wishes in the planning process
잠재 고객을 고려하지 않음 failing to consider potential customers
소프트웨어 엔지니어링 전략과 회사의 전반적인 비즈니스 전략 간의 관계를 증명할 수 없음 inability to demonstrate any relationship between the software engineering strategy and the firm's overall business strategy.
조직 내에서 엔지니어링 전략과 회사의 전반적인 비즈니스 전략 간의 관계를 증명할 수 없음 failing to use information of any kind from within the organization
외부 정보 소스 사용 실패 failing to use outside sources of information
조직 개발 가능성에 대한 지식 부족 lack of knowledge of organizational development possibilities
비용이 많이 들고 조직에 장애가 되는 거짓 계획 sham planning that costs a lot and disrupts the organization
신뢰할 수 없는 출처의 정보를 사용하는 데는 여러가지 일반적인 문제가 있다: There are a number of typical problems of using information from unreliable sources:
조직 내에서 발생하는 상황에 대해 관련이 없거나 신뢰할 수 없는 내부 보고서 사용 using internal reports that are irrelevant or are not reliable indicators of what's happening in the organization
프로세스가 불안정하여 측정의 의미가 없으며, 프로세스가 불안정함을 보인다는 점만 제외하고 measuring processes so unstable that measurements have no meaning, except to show the instability
데이터가 아닌 의견을 바탕으로 전략 수립 creating strategies based on opinion, not data
이용 가능한 정보가 신뢰할 수 있는 경우에도, 계획 세션은 잘못된 수준의 세부사항으로 작업하여 문제가 된다: Even when the available information is reliable, planning sessions fall into trouble by working at the wrong level of detail:
관련 없는 세부 사항에 너무 많은 시간을 할애함 spending too much time on irrelevant details
기뵤 가능한 세부 정보가 아닌 다른 소스의 데이터 사용 using data from different sources that are not of comparable detail
중요한 문제를 피상적으로 다루면서 모든 것을 죽을 때까지 일함 working everything to death, while treating important issues superficially
최신 소프트웨어 엔지니어링 유행에 휩쓸려 가정 내 근본 문제를 무시한 채 being swept along by the latest software engineering fad, ignoring the root problems at home
Chapter 2. 메타-계획하기: Part II. 시스템 사고 (Meta-Planning: Part II. Systems Thinking)
Summary
문제 해결은 실천 계획 수준에서 다양한 어려움을 제시한다. 예를 들면, Problem solving presents a variety of difficulties at the level of action planning. For example,
세션 계획 수립은 누구의 문제 해결 접근 방식을 사용해야 하는지에 대한 논쟁으로 변질된다. Planning sessions degenerate into arguments over whose problem solving approach to use.
데이터 공유 및 우선순위 설정을 통해 세션 계획을 원활하게 진행할 수 있지만 조치를 결정할 때가 되면 중단될 수 있음 Planning sessions may move smoothly through data sharing and setting priorities, but bog down when it comes time to decide on actions.
복잡할 필요는 없지만 모든 계획자가 공통적으로 접근해야 하는 접근방법에 대해 계획단이 합의할 필요가 있다. 하나의 간단한 4단계 접근법은 다음과 같다: The planning group needs to agree on an approach, which need not be complex, but must be common to all the planners. One simple four-step approach is as follows:
인식되는 것과 원하는 것, 그리고 언제 인지하는 것의 차이의 관점에서 문제를 정의한다. Define a problem in terms of a difference between what is perceived and what is desired, and when.
인식/욕구 변수와 다른 변수에 관련된 효과 다이어그램을 개발한다. Develop a diagram of effects relating the perceived/desired variables to other variables.
효과 다이어그램을 검토하여 인식된 상황을 제자리에 고정시키는 동적인 것을 발견한다. 만약 당신이 그 역동성을 발견할 수 없다면, 무엇이 당신이 그것을 발견하는 것을 방해하는지 알아내라. Examine the diagram of effects to discover the dynamic holding the perceived situation in place. If you can't discover that dynamic, then find out what is preventing you from discovering it.
동적 특성을 이해한 경우, 인식된 값의 안정성 제어를 중단할 수 있는 선택 지점을 식별하라. 이것들은 당신의 전략적 행동을 정의한다. 동적 정보를 이해하지 못하는 경우 동적 정보를 검색할 수 있는 작업을 식별하라. If you understand the dynamic, identify choice points where you can break the stability control of the perceived values. These define your strategic actions. If you don't understand the dynamic, identify actions that will obtain the information to allow you to discover the dynamic.
개발은 항상 태생적으로 성장과 상관관계가 있는 것처럼 보인다. 이는 전략적 계획으로 적어내려가는 것만으로 이루어져야 할 조직 변화(또는 변화 시도)와는 대조적이다. 조직을 개발하는데 몇 가지 특징적인 계획 문제가 있다: Development seems always correlated in nature with growth. This is in contrast to organizational changes (or change attempts) which are supposed to take place just by writing them down in a strategic plan. Here are some characteristic planning problems in a developing organization:
품질 향상에 따라 비즈니스는 개선된 후 성장한다. 그러나 성장은 규모를 낳고, 그것은 그 품질을 파괴한다. As quality improves, the business improves, then grows. But growth produces bigness, which then destroys its quality.
복잡성은 개발을 제한한다. 품질 관리를 위한 명시적 메커니즘이 추가되면서 조직 구성도 더 어려워보인다. Complexity restricts development. As explicit mechanisms to control quality are added, the organization seems to be harder to organize further.
크기는 자유를 제한한다. 사람들은 과도한 계획 때문에 창의적일 기회를 잃고 있다고 느낀다. Size restricts freedom. People feel that because of overplanning, they are losing their opportunity to be creative.
시스템 크기가 커질수록 도구가 스케일업되지 않고 항상 비선형적이기 때문에 계획 예측이 예전처럼 잘 작동하지 않는 것 같다. Planning projections don't seem to work as well as they used to because tools don't scale up as the system size grows, and growth is always nonlinear.
큰 것은 작은 것과 같지 않다. 조직이 커질수록 내부 생존력을 유지하려다 보니 외부와의 관계가 경색된다. Big isn't the same as small. As the organization grows, its relationship with the outside is strained as it tries to maintain its internal viability.
전략 기획자는 리스크의 관점에서 생각하고 보상할 필요가 있다. 전략적 계획에서 가장 일반적인 절충 결정 중 하나는 부가가치와 성공 확률 사이에 있다. 새로운 기술에 대한 기회를 잡음으로써, 당신은 큰 가치 상승이나 큰 비용 감소를 얻을 수 있다. 하지만 새로운 기술은 위험하고, 만약 실패한다면, 당신의 보상은 아무것도 아닐지도 모른다. Strategic planners need to think in terms of risk and reward trade-offs. One of the most common trade-off decisions in strategic planning is between added value and probability of success. By taking a chance on a new technology, you may get a great increase in value or a great decrease in costs. But new technologies are risky and, if you fail, your payoff may be nothing at all.
조직마다 상이한 절충 선택을 하고, 그러한 선택은 문화에 영향을 미친다: Different organizations make different choices of trade-offs, and those choices influence their culture:
신생 소프트웨어 회사는 리더들이 화려하고 빠른 일을 하지 않으면 많은 손실을 입는다. 그들은 생존할 수 있는 충분한 보상을 받기 위해 높은 위험을 감수해야 할지도 모른다. A start-up software company has much to lose if its leaders don't do something spectacular, and fast. They may need to take a high risk in order to get a high enough reward to stay in existence.
대형 소프트웨어 공급업체의 고위 관리자들은 고위험 계획을 세우면 잃을 것이 많다. 목을 내밀지 않지만 일단 큰 위험이 사라지면 빠르고 확실한 발걸음으로 움직일 준비가 되어 있다. The high-level managers of a large established software provider have much to lose if they make high risk plans. They don't stick their necks out, but once the big risk is gone, they're ready to move in a swift, sure-footed way.
각각의 문화는 몇몇 위험을 조장하고 다른 사람들을 좌절시킨다. 위험 회피 문화에서는 전략 계획의 지시를 따르는 것이 사람들을 위반하는 것보다 더 큰 위험으로 보일 수 있다. Each culture encourages some risks and discourages others. In a risk-averse culture, following the dictates of the strategic plan may seem a greater risk to people than violating them.
리스크 분석을 통해 관리자들은 보다 효과적으로 조종할 수 있는 기회를 제공하지만, 그러한 개선은 리스크를 자유롭고 공개적으로 논의할 수 있는 문화 속에서만 가능하다. 그러나 일부 조직에서는 리스크가 적절한 논의 대상으로 여겨지지 않는다. The analysis of risks gives managers a chance to steer more effectively, but such improvement is possible only in a culture where risks can be discussed freely and openly. In some organizations, however, risk is not considered a proper subject of discussion.
비일치적 대처 행동은 다른 사람이 계획을 세우기 전에 먼저 대처해야 한다. 전략팀은 논의될 수 없는 위험요인에 근거한 어떤 결정도 삼가야 한다. 위험성이 아쥬롭고 공공연하게 논의될 수 있는 문화, 즉 '풍자의 다섯 가지 자유'를 실천할 수 있는 문화를 만들자는 전략 액션 아이템을 만들어야 한다. Incongruent coping behaviors must be dealt with before anyone makes any further attempts to plan. The strategic team should refrain from making any decision based on risk factors that cannot be discussed. The team should create a strategic action item calling for creating a culture in which risk can be discussed freely and openly—that is, a culture where Satir's Five Freedoms are practiced:
존재해야 하는 것, 또는 앞으로 있을 것 대신 여기에 있는 것을 보고 들을 수 있는 자유 The freedom to see and hear what is here, instead of what should be, was, or will be.
자신이 해야할 것 대신 자신이 느끼고 생각하는 것을 말할 자유 The freedom to say what one feels and thinks instead of what one should.
필요한 것 대신 자신이 느끼는 것을 느낄 수 있는 자유 The freedom to feel what one feels, instead of what one ought.
항상 허락을 기다리는 대신 원하는 것을 요구할 수 있는 자유 The freedom to ask for what one wants, instead of always waiting for permission.
"보안"만을 선택하고 보트를 흔들지 않는 대신 스스로 위험을 감수할 수 잇는 자유 The freedom to take risks in one's own behalf, instead of choosing to be only "secure" and not rocking the boat.
불안정한 시스템은 생각하기가 더 어렵다. 즉, 계획하기가 더 어렵다. 고위 경영진은 모든 수준에서 안정적인 시스템이 존재하는지 확인할 책임이 있다. Unstable systems are harder to think about—that is, to plan for. Upper management has the responsibility for assuring that there are stable systems at all levels.
지적으로 관리할 수 있는 안정성을 얻기 위해서는 신뢰할 수 있는 단위로 조직을 구축해야 한다. 각 단위는 업무가 있으며, 각 단위는 블랙박스로서 입력-출력만으로 관리할 수 있다. 이 접근방식은 바닥과 위 사이의 통신 뿐만 아니라 장치 간의 통신의 필요성을 크게 감소시킨다. 기획의 복잡성도 줄인다. To achieve stability that you can manage intellectually, you need to build an organization in trustable units. Each unit has a job, and each unit can be managed through input and output only, as a black box. This approach greatly reduces the need for communication among units, as well as between bottom and top. It also reduces the complexity of planning.
신뢰 부족은 계획자에게 많은 특성 문제를 야기한다 Lack of trust produces a number of characteristic problems for planners:
하위 레벨 사람들은 경영진을 신뢰하지 않으며, 전략 계획의 실천에 대해 "당신이 먼저" 태도를 취할 것이다. Lower-level people don't trust management, and will adopt a "you go first" attitude toward implement actions of the strategic plan.
경영진은 더 낮은 수준에서 올바른 조치를 취하기 위해 끊임없이 노력하며, 이로 인해 사람들이 어떠한 시도도 하지 못하게 된다. Management keeps swooping down to correct actions at lower levels, which demotivates people from attempting anything.
때로는, 변화를 위한 환대 풍토인 것 같은 곳에서도 훌륭한 아이디어는 그저 겉으로 드러나지 않는 것 같다. 네 가지 가능성이 있다: Sometimes, even in what seems to be a hospitable climate for change, great ideas just don't seem to get off the ground. There are four possibilities:
새로운 접근 방식은 효과가 있을 것으로 보이나, 중요한 규모의 참여자는 달성할 수 없는 것으로 보인다. The new approach seems sure to work, but can't seem to achieve a critical mass of participants.
새로운 공정이나 기술을 도입할 때 우리는 종종 닭과 달걀 증후군에 걸린다. 다른 사람이 테스트할 때까지 아무도 사용하지 않을 것이다. When introducing a new process or technology, we often get a chicken-egg syndrome. Nobody will use it until it's tested by someone else.
다른 사람들이 당신을 위해 아이디어를 시도하도록 하는 것은 한계가 있다. 한 문화에 대한 처방은 다른 문화적 패턴에 대해 무의미하거나 뒤로 들린다. Letting others try ideas for you has its limits. Prescriptions for one culture sound meaningless or backward for another cultural pattern.
과도한 기획 에너지는 크고 단호한 목소리로 소수의 반대를 극복하는데 헌신한다. Excessive planning energy is devoted to overcoming the objections of a few people with loud, strident voices.
Chapter 3. 전술적 변화 계획하기 (Tactical Change Planning)
Summary
조직의 변화 예술성은 전략 계획을 전술적 계획으로 번역할 수 있게 하고, 그 계획을 실행에 옮기도록 용이하게 한다. 전술적 변화 계획은 변화 예술가 훈련의 필수적인 부분이다. The change artistry of the organization allows the strategic plan to be translated into tactical plans, and then facilitates putting those plans into action. Tactical change planning is an essential part of change artist training.
세 가지 주요 어려움은 다른 좋은 계획이 쓰레기통에 떨어지는 원인이 된다: Three major difficulties contribute to otherwise good plans falling into the trash:
계획자들은 전략작언 계획 대신 전술적인 계획을 수립하고, 그 방법과 이유를 너무 많이 제시한다. The planners create tactical plans instead of strategic plans, giving too much how and not enough what or why.
계획자들은 실행으로 번역될 수 없는 전략적 계획을 수립하거나, 또는 거의 모든 행동을 정당화할 수 있을 정도로 모호한 계획을 수립한다. The planners create strategic plans that couldn't possibly be translated into action, or are so ambiguous that they could justify almost any action.
소프트웨어 조직은 프로젝트가 주로 소프트웨어가 아닌 경우 전략 및 전술적 계획에 어려움을 겪는 경우가 많다. 프로젝트 계획 변경은 소프트웨어 프로젝트가 아니다. Software organizations often have difficulty with strategic and tactical planning when the project is not primarily software. Change project planning is not a software project.
계획된 변화는 A지점(인식 상태)에서 B지점(원하는 상태)으로 시스템을 가져가는 것이다. 포인트 A와 B는 명시적이든 암시적이든 전략 계획에 의해 제공된다. 이러한 변화는 다음 작업을 통해 달성될 수 있다: Planned change is taking a system from point A (a perceived state) to point B (a desired state). Points A and B are supplied by a strategic plan, explicit or implicit. Such a change can be accomplished by working on
A의 인식 the perceptions of A
B에 대한 욕망 the desires for B
A 또는 B의 현실 the realities of A or B
전술적 계획은 가능한 행동과 그 결과를 미리 고려하고, 개입 모델을 사용하여 성공 가능성을 극대화하는 방식으로 배치하는 것이다. 인식과 욕망이 전체 과정에 걸쳐 고정되어 있다는 가정은 조직 변화를 계획할 때 그다지 유용하지 않다. 대부분의 조직 변화 프로젝트는 인식, 욕망, 현실의 세 가지 수준에 대한 개입을 수반하기 때문이다. Tactical planning is considering possible actions and their outcomes in advance, and arranging them in a way that maximizes your chance of success, using intervention models. The assumption that perceptions and desires remain fixed throughout the entire process is not very useful when planning organizational change, because most organizational change projects involve interventions on all three levels: perceptions, desires, realities.
조직 변화 계획에 성공하기 위해서는 "목표 지향적이기보다는 개방적이고, 진행하면서 편법적이고 실증적으로 자신을 꾸며야 한다"는 계획 방법을 사용할 필요가 있다. To be successful in organizational change planning, you need to use a planning method that is "open-ended rather than goal-oriented, and has to make itself up expediently and empirically as it goes along."
오픈 엔드 변경 계획은 다음 단계로 설명된다: Open-ended change planning is described by the following steps:
목표와 역량에 대한 최신 정보를 사용하여 적절한 세부사항 수준으로 그럴듯한 계획을 작성한다. Use the most current information about goals and capabilities to create a plausible plan to an appropriate level of detail. 2.계획을 실행하기 시작하고, 다음과 같은 정보를 수집한다 Start to execute the plan, gathering information on
계획했던 곳과는 반대로 실제로 가는 곳 where you actually go, as opposed to where you planned to go
조직이 작동할 방식과 반대로, 조직이 실제로 어떻게 작동하는지 how the organization actually acts, as opposed to how you thought it would act
계획에 영향을 받은 사람들의 감정적 반응 (자신을 포함) the emotional reactions of people affected by the plan, including yourself
(2)의 정보에 비추어 정지 여부를 확인한다. 그렇지 않을 경우 새로운 목표를 설정하고 (1)을 반복한다. In the light of the information from (2), check whether you want to stop. If not, set new goals and repeat (1).
메타 변화에 대한 Satir의 설명에 따르면, 관련자들이 일치된 상태를 유지하는 시간이 흐를수록 변화는 더 쉬워져 self, other, context 사이의 균형을 유지하게 된다. 따라서 각 계획 수립 주기 동안 처음부터 끝까지 세 가지를 모두 모니터링해야 한다. According to Satir's description of meta-change, change becomes easier over time when the people involved remain congruent, maintaining a balance among the Self, Other, and Context. Thus, during each planning cycle you must monitor all three from start to finish.
계획이 열린다고 해서 목표가 수반되지 않는 것은 아니다. 실제로 오픈 엔드형 계획자들은 모든 계획 주기에서 목표를 테스트하고 수정해야 하기 때문에 목표에 대해 더 많이 알 필요가 있다. Just because planning is open-ended doesn't mean it won't involve goals. Indeed, open-ended planners need to know more about goals, since they will have to test and revise goals on every planning cycle.
리스크를 관리하는 첫걸음은 리스크 평가다. 안정성은 사실상 리스크의 역효과인데, 이는 안정적 계획이 리스크에 대처할 수 있는 것이기 때문이다. 계획자는 위험(안정에 대한 위협)의 목록을 작성하고, 위험이 어떻게 상호 연관되어 있는지 발견하며, 숨겨진 위험을 밝혀내야 한다. Risk assessment is the first step in managing risks. Stability is, in effect, the inverse of risk, because a stable plan is one that can cope with risk. Planners must create a list of risks (threats to stability), discover how risks are interrelated, and uncover hidden risks.
리스크 평가는 리스크 관리가 아니라 첫 단계일 뿐이다. 두 번째 단계는 예측 불가능한 환경에도 불구하고 예측 가능한 결과를 얻기 위한 계획인 위험 완화 계획이다. 플라스틱 모델, MOI 모델 및 인간 감정성 모델을 사용하여 가능한 한 프로젝트 관리 하에 위험을 배치할 단계를 계획할 수 있다. Risk assessment is not risk management, but only the first step. The second step is risk abatement planning, planning to get a predictable result in spite of an unpredictable environment. The PLASTIC Model, the MOI Model, and models of human emotionality can be used to plan steps that will place risks under project control, to the extent possible.
개방향 계획은 계획의 영향을 받는 각 그룹의 피드백을 사용하여 계획의 일부 또는 그 이하를 지속적으로 수정해야 한다. 어떤 진짜 계획이라도 계획을 수정하기 위한 계획을 포함해야 한다. 이 계획의 개정 계획은 변경 과정 자체를 안정화하는 하나 이상의 부정적(역방향) 피드백 루프로 구성되어 있다. Open-ended planning requires that the plan will have to be revised on a more or less continuing basis, using feedback from each group of people affected by the plan. Any real plan must contain a plan for revising the plan. This plan for revising the plan is comprised of one or more negative feedback loops that stabilize the change process itself.
Chapter 4. 소프트웨어 엔지니어처럼 계획하기 (Planning Like a Software Engineer)
Summary
예상하는(패턴4), 그리고 일치적인(패턴5) 조직은 진정한 엔지니어링 조직으로, 그 안에 있는 사람들이 엔지니어링 용어로 일관되게 생각하기 때문이다. Anticipating (Pattern 4) and Congruent (Pattern 5) organizations are truly engineering organizations, because people in them consistently think in engineering terms.
엔지니어링은 여러 가지 방법으로 행해질 수 있다; 모든 것의 해답이 되는 복음이나 성경은 없다. Engineering can be done in many ways; there is no gospel, no holy book in which you can look for all the answers.
엔지니어링은 자신이 원하는 것을 다 얻을 수 없을 때 하는 것으로, 그 상황에서 얼마든지 얻을 수 있는 기술이기 때문이다. 엔지니어링은 당신이 무엇을 위해 무엇을 얻는지, 그리고 왜 포기하는지 의식적으로 결정한다는 것을 의미한다. Engineering is what you do when you can't get everything you want, because it's the art of getting as much as you can under the circumstances. Engineering does mean you make conscious decisions about what you're getting for what you're giving up, and why.
트레이드오프 곡선은 오늘날의 최고의 엔지니어링 관행과 가능한 것과 불가능한 것의 경계를 나타낸다. A trade-off curve represents the boundary between the possible and the impossible with today's best engineering practice.
좋은 소프트웨어 엔지니어링 관리는 변수들 사이의 가장 바람직한 트레이드오프를 나타내는 지점에서 가능한 최선의 실행의 트레이드오프 곡선을 유지하거나 그 근처에 머무를 수 있는 능력이다. Good software engineering management is the ability to stay on or near the trade-off curve of best possible practice at a point that represents the most desirable trade-off between the variables.
중요한 변수들 사이의 절충 곡선 패밀리를 스케치하는 것은 엔지니어링 관리자가 품질, 경제 및 일정과 같이 잠재적 절충을 논의할 수 있는 근거를 제공한다. Sketching a family of trade-off curves among critical variables gives engineering managers a basis for discussing the potential trade-offs, as among quality, economy, and schedule.
대부분의 기술은 다른 기술의 혼합으로 형성되며, 어떤 기술을 언제 사용할지에 대한 경영진의 결정에 의해 연결된다. Most technologies are formed from a mixture of other technologies, and they are linked by management decisions about when to use which.
엔지니어링 관리 조치의 기본 그래프는 엔지니어링 관리자가 직면하고 있는 많은 중요한 결정을 보여준다. The fundamental graph of engineering management action shows many of the important decisions facing an engineering manager.
소프트웨어 엔지니어링 관리는 그 용어의 넓은 의미에서 기술에 대한 선택과 관련이 있으며, 그러한 선택은 여러 수준에서 이루어진다. 한 레벨에서 제어가 이루어지지 않으면 다른 레벨에서 제어가 더욱 어려워진다. Software engineering management is concerned with choices about technology in a broad sense of that term, and those choices are made at many levels. If control is not in place at one level, it becomes more difficult to control at another.
소프트웨어 엔지니어링 조직이 잘 관리되려면 모든 레벨이 잘 관리되어야 한다. 하지만, 게다가, 그들은 서로 조율되어야 한다. 따라서 소프트웨어 엔지니어링 관리자는 다양한 제어 책임을 어느 수준으로 둘 것인지 결정해야 한다. For a software engineering organization to be well managed, all of the levels have to be well managed. But, in addition, they have to be coordinated with one another. Therefore, software engineering managers have to decide on what level to place various control responsibilities.
우리는 상위 수준에서 의사결정이 하위 수준에서의 의사결정을 통제하는 작용을 한다는 것을 알고 있지만, 하위 수준에서 의사결정이 상위 수준에서 의사결정을 통제할 수도 있다. 우리는 왜 우리가 어떤 수준의 통제 결정을 내리게 되었는지 알아야 한다. We know that decisions at higher levels act to control decisions at lower levels, but decisions at low levels can also control decisions at higher levels. We need to be aware of why we put which control decision on which level.
Part II. 어떤 변화들이 일어나야 하는가 (What Changes Have to Happen)
Chapter 5. 안정적인 소프트웨어 엔지니어링의 요소들 (Components of Stable Software Engineering)
Summary
소프트웨어 공학은 여러 가지 면에서 다른 종류의 공학과는 동일하지만, 소프트웨어의 성격에서 생기는 독특한 특성도 가지고 있다. Although software engineering is in many ways the same as any other kind of engineering, it also has unique properties arising from the nature of software.
Boehm에 따르면, 소프트웨어 비용은 시스템의 크기와 복잡성, 사람 요인, 사용하는 도구, 특히 관리 부실에 의해 영향을 받는다. According to Boehm, software costs are affected by the size and complexity of the system, by people factors, by the tools that are used, and especially by poor management.
소프트웨어 프로젝트는 제어 정보가 누락되거나, 왜곡되거나, 무관하거나, 단지 명백한 잘못일 때, 또는 관리자가 통제자로서 조치를 취할 때, 일치적으로 기능할 수 없을 때 가장 자주 실패한다. Software projects fail most often when control information is missing, distorted, irrelevant, or just plain wrong, or when managers are unable to function congruently when taking actions as controllers.
제어 정보 실패는 다음과 같은 몇 가지 일반적인 형태를 취한다. 마치, Control information failures take several common forms, such as
원하는 제품이 무엇인지 알 수 없음 not knowing what product is wanted
소프트웨어 개발 프로세스의 특성을 이해하지 못함 not understanding the nature of the processes of software development
프로세스가 어떻게 진행되고 있는지에 대한 가시적인 증거 없음 having no visible evidence on how the process is proceeding
의미 있는 측정을 하기에 충분한 안정성이 없음 lacking sufficient stability to make meaningful measurements
설계 무결성 부족 또는 상실 lacking or losing design integrity
시간이 지나면서, 소프트웨어 엔지니어는 다음과 같은 정보 장애에 대한 솔루션을 진화하고 있다. 마치, Over time, software engineers are evolving solutions to information failures, such as
원하는 제품을 식별하기 위한 요구사항 프로세스 requirements processes to identify what product is wanted
소프트웨어 유지보수 및 개발의 특성을 설명하는 프로세스 모델 process models to explain the nature of software maintenance and development
프로젝트 진행 방식에 대한 가시적 증거를 제공하는 프로세스 processes that provide visible evidence on how the project is proceeding
변경사항을 제어하여 안정성을 제공하는 시스템 systems to provide stability by controlling changes
설계 무결성을 유지하기 위한 도구 및 기술 tools and techniques to maintain design integrity
그러나 결국, 소프트웨어 장애의 가장 큰 원인이 되는 것은 관리의 성격과 성격 장애, 즉 부조화 때문이며, 이러한 장애는 지속적인 개인 개발을 통해 해결되어야 한다. In the end, though, it is the character and personality failures—the incongruence—of management that are the biggest cause of software failures, and these must be worked on through ongoing personal development.
Chapter 6. 프로세스 원칙들 (Process Principles)
Summary
모든 효과적인 프로세스 모델이 따라야 하는 원칙이 몇 가지 있다. 이러한 원칙들은 다른 모델의 장단점을 탐구할 때 지침의 역할을 한다. 하나 이상의 프로세스 모델을 구현하는 관리자의 가이드 역할도 한다. There are a number of principles that any effective process model must follow. These principles act as guides when you're exploring the strengths and weaknesses of different models. They also act as guides for managers who are trying to implement one or more process models.
백만장자 테스트는 이렇게 말한다. The Millionaire Test says,
프로세스가 랜덤보다 낫다는 것을 보여줄 수 없다면, 사용하지 마라. If you can't show that your process is better than random, don't use it.
백만장자 테스트는 새로운 프로세스를 제안하는 모든 사람들에게 입증 책임을 지며, 측정 가능한 과정을 개발하도록 장려한다. The Millionaire Test puts the burden of proof on any people who propose a new process, encouraging them to develop a measurable process.
오늘날에는 랜덤보다 명백히 더 나쁜 많은 프로세스가 운영되고 있다. 백만장자 테스트의 요점은 무작위적인 프로세스를 옹호하는 것이 아니라, 그 프로세스의 어리석음을 일깨우는 것이다. Many processes are in operation today that are demonstrably worse than random. The point of the Millionaire Test is not to advocate random processes, but to awaken an organization to the idiocy of some of its processes.
피드백은 연속성에 효과가 있다. 모델의 조각은 너무 클 수 없으며 (아니면 반응이 느릴 것이다), 안정적이어야 한다 (아니면 반응이 예측 불가능할 것이다). 안정성 원칙은 다음과 같은 두 가지 요구사항을 요약한다. 프로세스의 모든 부분은 통제된 시스템이어야 한다. Feedback works on continuity. The pieces in the model cannot be too large (or response will be slow), and they must be stable (or the response will not be predictable). The Stability Principle summarizes these two requirements: Every part of a process must be a controlled system.
안정성 원칙은 테스트가 단계가 아니라, 모든 단계에 내재된 제어 프로세스의 일부임을 보여준다. 흔히 시스템 테스트라고 불리는 것은 전혀 테스트가 아니라 시스템 구축의 또 다른 부분으로서, 아마도 "시스템 통합"이라고 더 잘 명명된 것일 것이다. The Stability Principle shows that testing is not a stage, but part of a control process embedded in every stage. What is often called system test is not a test at all, but another part of system construction, perhaps better named "system integration."
프로젝트 통제에 대해 알고 있는 것에서부터, 그리고 인간의 자연적인 불완전성에 대해 알고 있는 것에서부터, 작업 산출물의 사적 소유의 개념은 어떤 프로세스 모델의 일부가 될 수 없다. 대신 모든 프로세스 모델은 다음과 같은 가시성 원칙을 준수해야 한다: 프로젝트의 모든 것을 항상 볼 수 있어야 한다. From what we know about controlling a project, and from what we know about the natural imperfections of human beings, the concept of private ownership of work products cannot be part of any process model. Instead, every process model must conform to the Visibility Principle: Everything in the project must be visible at all times.
검토를 통과하지 않는 한 실재하는 것은 없고, 보이지 않는 것은 재검토할 수 없으므로, 가시성 원칙의 관점은 다음과 같은 현실 원칙이다: 독립적인 검토를 통과하기 전까지는 진짜가 아무것도 없다. Since nothing is real unless it's passed review, and since invisible things cannot be reviewed, a corollary of the Visibility Principle is the Reality Principle: Nothing is real until it has passed independent review.
프로세스 다이어그램은 각 상자의 작업이 실제로 이루어졌는지를 알려주는 측정을 기술하지 않으면 무의미하고 위험하다. 측정가능성 원칙은 다음과 같이 말한다, Process diagrams are meaningless and dangerous if they don't describe the measurements that will tell you if the work of each box has actually been accomplished. The Measurability Principle says,
측정하지 않는 것은 통제할 수 없다. Anything you don't measure will be out of your control.
측정가능성 원칙에도 "좋은 관리는 측정을 한다"고 되어있지만, 그렇다고 많은 것을 측정한다면 반드시 통제할 수 있어야 한다는 뜻은 아니다. The Measurability Principle also says "Good management takes measurement," but that doesn't mean if you measure lots of things, you must be in control.
소프트웨어 엔지니어링의 0순위 법칙에 따르면, The Zeroth Law of Software Engineering says,
요구사항을 충족하지 않아도 관리에는 문제가 없다. If you don't have to meet requirements, management is no problem.
이 법은 그 자체로 중요한 의미를 지닌다. This law is important enough to deserve its own chapter.
제품 원칙은, The Product Principle says,
제품은 프로그램일 수 있지만 프로그램은 제품이 아니다. Products may be programs, but programs are not products.
이 원칙의 위반은 정보시스템의 필수적인 부분이 프로세스 설계에서 누락되거나 제품에서 누락되는 결과를 초래한다. Violation of this principle leads to essential parts of information systems being omitted from process design, or even omitted from the product.
Chapter 7. 문화와 프로세스 (Culture and Process)
Summary
- This chapter considers three questions all managers must understand if they would change their organization:
- What determines the way ordinary people behave in an organization?
- How do those behaviors affect the organization's formal processes?
- How are ordinary people affected by those processes?
- The Culture/Process Principle illustrates the trade-off between culture and process:
- Whatever you can safely assume in the culture, you don't have to specify in your process description.
- The Culture/Process Principle warns us that the same process description will mean different actions in different cultures. Therefore, before plunging in to a grand farrago of process building, we need to understand the culture for which we are building those processes.
- The level of quality culture is forced by either customer demands or problem demands. This doesn't mean that in the short run, culture is determined by these two parameters. In the long run, however, organizations that don't develop an appropriate cultural pattern will be forced to change or die.
- The consistency of an organization's cultural pattern is striking, and requires no sophisticated measurements to detect. In a culture stemming from the FDA requirement that all work connected with the use and testing of drugs be done under strict process controls, software will be done under strict process controls. If you don't follow them, you go to jail.
- In the culture producing space flight software, there is a consistent understanding of everyone in the organization that human lives are riding on the flawlessness of their software. This vision—"Bring 'em back alive—leading with consistent strength over fifty years, has placed this organization in a very advanced software cultural pattern.
- In a software organization waiting to be bought or go public, the principal objective is not to produce life-critical systems, but to create an attractive company for the auction block. A short time horizon is often an important part of such a culture, and long-range (or even medium-range) planning is not acceptable, though it may be acceptable to put up a sham of planning to make the firm more attractive to potential buyers.
- Not all the themes communicated by management can be considered intentional. A common theme in software organizations these days is the inability to make decisions and stick to them. This theme is communicated not by what management does, but mostly by what it doesn't do: make decisions and follow through on them. The cultural message in such an environment is not to stick with important decisions, so you'll never be caught in a "mistake."
- The number of customers influences an organization's approach to design/debugging. With millions of customers, PC software companies simply don't consider shipping rare bugs a life-and-death problem. Instead, they concentrate their energies on creating a culture of quickly fixing bugs.
- Because of their positions in the regulatory process, each level of management tends to have a different conception of the word "process," and these differences tend to interfere with process improvement efforts.
- Top management is responsible for the future of the business, which will not be prosperous unless present and future customers are satisfied. Thus they are concerned with what could be—the process vision.
- Middle management is concerned with what should be—the process model that translates the vision into specific action steps.
- Supervisory management is concerned with what is—the only thing that can truly be called the process as opposed to the process vision or process model. Models and visions are process descriptions, which may or may not be followed in the actual process. Supervisory managers translate the models into actions, actions that may or may not reflect the original process vision descending from on high.
- The quality of leadership is part of the culture, perhaps the part that is most dangerous to the Old Status Quo. If leadership improves, then the culture must improve.
Chapter 8. 프로세스 개선하기 (Improving Process)
Summary
- Many software organizations have difficulty in improving their process because they mistake the process models and process visions for actual processes. Because these models concentrate on direct work, they omit most of the areas in which process improvement is possible: the management activities.
- There are three distinct types of process improvement, corresponding to the three meanings of process. Cultural changes have much greater potential impact than process changes because one cultural change can affect hundreds of process changes. In order for substantial improvement to take place, the managers' levels must be open to investigation and change.
- One classic process improvement strategy consists of four steps:
- Document the actual process.
- Discover the root cause of the problem.
- Modify the process to reduce variation.
- Test the process improvements.
- If this model is applied at all levels, substantial improvement is possible.
- When you examine the real process, you will discover a number of places where things being done were not part of the process model—called the chicken wire factor.
- Improvement teams often try to address a symptom without really knowing the root cause behind it. Only after understanding the root cause will the teams be able to choose among solution ideas and modify their process model to include previously implicit steps.
- Such process model improvements may not be possible without cultural changes to support them. Such changes will not be possible without explicit modeling of the actions of upper management.
- Monitoring the effects of the improved process is always necessary because real organizational changes never follow simple logical plans, so that the actual process always deviates from the process model in unexpected ways.
- Monitoring and interviewing may be essential to uncovering the invisible factors that are behind the deviations. These factors are often human factors not ordinarily discussable in the culture. Once these factors have been uncovered and handled, it's often necessary to institute cultural changes to prevent repetition of the same pattern in the future.
- Process improvement must involve all levels of the organization. You don't know, when you embark on an improvement process, what you will have to change: the process, the process models, or the culture. In general, you can assume that all three will need some adjustment.
- When you study many process improvement situations, you begin to see a pattern of principles:
- Individual issues often underlie the toughest improvement situations.
- The way short-term solutions are handled will set cultural precedents.
- Unless the culture changes, the same kinds of personal issues will keep recurring.
- Cultural changes will involve upper management; otherwise process improvements will keep being undone by the same culture that created the process issues in the first place.
- You can change the logical process first, but consider this a test to see if the problem is entirely logical.
- To address emotional problems, you'll need to get under the surface to the layers of information protected by the cultural rules governing what's not okay to talk about.
- Be careful changes are not made in a blaming way.
- A policy of not blaming does not mean a policy of placating.
- A common way to avoid learning process principles is to say, "Yes, that's very nice, but our company is different." True, the details always differ, but the principles are the same and the results are similar.
- Another common way to avoid process improvement is to say, "Yes, but it costs too much." The answer to this excuse is that properly done process improvement does cost a lot, but it also pays a great deal more. If it doesn't pay big dividends, then it's not been properly done.
- Don't be tempted to hide the true cost of process improvement from upper management. Better to start with a realistic idea of the commitment in time and resources than to be undermined later when executives are surprised. Be sure to offer a detailed picture of benefits, which will surely justify the true improvement costs.
Chapter 9. 요구사항 원칙들과 프로세스 (Requirements Principles and Process)
Summary
- Software engineering is in the business of building, running, and maintaining things for some customer or customers. Requirements are only part of the process of connecting with your customers and responding to them, but they are an important part.
- Until recently, the computing industry seems to have avoided the subject of requirements. In the light of all this literature, it's easy to understand why so many software engineering managers have made the mistake of believing that they should have unchanging requirements before starting any project—the Assumption of Fixed Requirements.
- Translating requirements into code is an essential part of software engineering, and it is the part that has received the most research attention over the past four decades. But because of that attention, it is no longer the most difficult part of the process, nor is it the process that will yield the most benefit to process improvement efforts.
- The Zeroth Law of Software Quality concerns requirements, and appears in various forms:
- The Zeroth Law of Quality: If you don't care about quality, you can meet any other requirement.
- The Zeroth Law of Software: If the software doesn't have to work, you can meet any other requirement.
- The Zeroth Law of Software Engineering Management: If you don't have to meet requirements, management is no problem.
- The less closely you have to meet requirements and the more your requirements approximate the Assumption of Fixed Requirements, the easier it will be for you to manage.
- Changing to another cultural pattern requires a transformation so that people let go of previously successful models, such as the Assumption of Fixed Requirements. For an organization to improve its cultural pattern, requirements process models need to be revised.
- People in Oblivious cultures tend to be oblivious to process models of any kind, let alone requirements.
- The linear process models of Variable cultures represent a step up in thinking, even though linear process models have no feedback at all.
- Routine organizations may acknowledge the non-linearity of the requirements process, but try to keep exceptions to the linear process as linear as possible. The principal job of Change Control is to filter out as many requirements changes as possible—to keep the process linear.
- The Pattern 2 requirements model works reasonably well when
- projects are small, so development takes place over a small time span
- the underlying business process is very stable
- customer expectations from information systems are low, and decisions are left in the hands of developers
- Much of the time software work involves a constant dialogue between the product's customers and the software developers.
- In Pattern 0, the requirements process runs inside the head of the person who's doing development.
- In Pattern 1, the requirements process generally runs back and forth between one customer and one team or individual developer.
- In Pattern 2, the requirements process runs alongside development, although the developers do their darndest to keep change from happening.
- The key process idea in moving to a Steering culture and beyond is that there are really two processes: one to develop a requirements product and one to develop a software product. In this view, the software development process and the requirements development process are mutually controlling twin processes, each exercising feedback control over the other.
- In mutually controlling processes, the purpose of each requirements stage is to narrow the discrepancy between what is wanted and what is documented, not to eliminate all discrepancy.
- Prototyping, of course, is an explicit way of making the requirements development process and the system development process mutually controlling, but effective prototyping is by no means trivial. If you adopt prototyping in order to avoid facing process issues, you are in for a series of nasty surprises.
- Requirements ideas often emerge from the system development process and flowing upward into the requirements process. A good requirements process authorizes the participation of developers, focuses their efforts and makes them visible, yet keeps them under some sort of control so they can make the very real contributions only they can make.
- A Steering or Anticipating requirements process is a controlled feedback process in its own right. Such a process model is more in keeping with the vision that says getting the requirements right is the most important part of product development.
Chapter 10. 요구사항 프로세스를 변화시키기 (Changing the Requirements Process)
Summary
- For many software organizations, an inadequate requirements process is the principal impediment to higher quality. To move such an organization to a controlled requirements process, managers need to plan and execute four major steps:
- Measure the true cost and value of requirements.
- Gain control of the requirements inputs.
- Gain control of the requirements outputs.
- Gain control of the requirements process itself.
- An improved requirements process pays for itself in a number of ways:
- faults caught early or not created at all
- redundant work eliminated
- better reception by customers
- faster, more manageable development
- improved maintenance
- Requirements come from many places, some of which are official, but many of which simply leak into the process. To gain control, management must create a process to
- identify and plug all leaks
- replace leaks with explicit negotiation
- When half of requirements come from unofficial sources, you cannot possibly control software development. To gain control of this requirements chaos, you must
- recognize that requirements come from many sources
- survey the sources of all leaks and close them tight so they must come through a single channel
- accept these multiple interests as legitimate, but not necessarily guaranteed to have their way with the requirements
- create an explicit negotiation process that will consider anybody's requirements ideas
- Requirements conflicts happen, and if not resolved any other way, they are resolved by the customer. Such customer resolution is not the best way to resolve requirements conflicts, but is needed to back up the system when negotiations fail.
- To prevent leakage and convert it into an explicit requirements capture process, there must be a single path for a requirements idea to be converted to a requirement. Anyone with a requirements idea—managers, engineers, customers, or anyone else—must understand that there is no other path by which this idea has a chance of becoming a requirement.
- Proponents of requirements ideas must clearly understand that they are simply requirements ideas, not requirements, until they pass through this process. Once requirements are gathered, they are considered rough requirements until they have passed through a smoothing process of analysis and clarification. If they pass this step, they are considered to be in reviewable condition, and are called requirements candidates. Only this review process can promote candidates into requirements that are placed in the database. Rejected ideas are turned back to their originators, who may then modify and resubmit them.
- The requirements database is used for building the system, and is also needed when new rough requirements are considered. That is because requirements must not only be clear and correct in themselves, but must be consistent with existing requirements.
- It isn't easy changing from the old back-door way to this new process of explicit negotiation. You can be sure that more than one person will challenge the system and try to return to the Old Status Quo situation.
- A requirements document is much like a software product. Like software, it is an information product, so
- it must be made visible.
- it must be made stable.
- it must be made controllable.
- A requirements document carries only a small part of the requirements communication load. In practice, most of the load is carried by
- individuals who understand the requirements and help other people understand
- teams that work effectively, so that they can communicate with one another about requirements
- To have the kind of understanding that keeps requirements simple, people must learn from participation in the requirements process. Participation alone won't be sufficient unless information is coordinated, open, available, and of known quality.
- If you have a full-time requirements manager with a staff of trained, committed people using appropriate tools and high quality information, you make the requirements task into a real project.
- The requirements process will also be better controlled if supported with appropriate tools, such as
- configuration control of all the relevant databases
- an active requirements database that allows all interested parties to examine any part of the current requirements at any time
- network access to the database, especially if it is seamless with other network use
- electronic mail and voice mail to support person to person communication
- special facilities for requirements meetings
- Management is ultimately responsible for defining what problems the organization is to solve internally, and for its customers. These managers must have the authority to establish and control the processes that make it possible for them to control this definition.
QSM: Volume 4.3: Change Done Well
Contents
-
QSM: Volume 4.3: Change Done Well
- Chapter 1. 프로젝트를 정확하기 시작하기 (Starting Projects Correctly)
- Chapter 2. 프로젝트를 정확하게 유지시키기 (Sustaining Projects Correctly)
- Chapter 3. 프로젝트를 적절하게 종료시키기 (Terminating Projects Properly)
- Chapter 4. 작게 만들어서 빠르게 만들기 (Building Faster By Building Smaller)
- Chapter 5. 정보 자산들을 보호하기 (Protecting Information Assets)
- Chapter 6. 설계 관리하기 (Managing Design)
- Chapter 7. 기술 도입하기 (Introducing Technology)
- Epilogue
Chapter 1. 프로젝트를 정확하기 시작하기 (Starting Projects Correctly)
Summary
- Most unsuccessful projects were under pressure from the moment they started, actually even before the moment that their process models said they started. And, indeed, the primary reason for the pressure was that there were no explicit models of what happens before a project officially starts.
- Preceding every project is a series of high-level negotiations that lead to the decisions that constrain the project. If these negotiations are not both informed and congruent, the project is finished before it starts.
- When a project is in the fuzzy early stages, before official initiation, the first question is, of course, what benefits the organization expects from the successful completion of the project. But infinite potential benefits will have zero value if the project isn't completed.
- When project benefits are large, it's difficult to make a congruent decision about risk. There are a number of relatively formal systems of risk analysis that can aid in making this decision, and any software engineering manager should be steeped in at least one.
- Rough consideration of Boehm's ten factors generally improves the chances for project success by at least a factor of two:
- Personnel shortfalls
- Unrealistic schedules and budgets
- Developing the wrong software functions
- Developing the wrong user interface
- Gold plating
- Continuing stream of requirements changes
- Shortfalls in externally furnished components
- Shortfalls in externally performed tasks
- Real-time performance shortfalls
- Straining computer science capabilities
- The biggest risk of all is that the management team isn't up to the job of performing a congruent risk analysis, let alone leading the project. The planning process, not the plan, is what transforms ridiculous fantasies into real projects.
- For a project to succeed, these early negotiations must produce a congruent agreement, one that balances the Self, Other, and Context. The single most important measure of any development project is, Did we fulfill our agreement? If you negotiate well, you'll be able to use this measure. If not, your project will probably fail.
- One essential for making projects comparable is to be sure they start on the same basis, which implies that all negotiations must be done explicitly, done well, and the agreements recorded, including
- Desired results (not methods) identify what is to be done, and when.
- Guidelines specify the parameters (principles, policies, etc.) within which results are to be accomplished.
- Resources identify the human, financial, technical, or organizational support available to help accomplish the results.
- Accountability sets up the standards of performance and the time of evaluation.
- Consequences specify—good and bad, natural and logical—what does and will happen as a result of the evaluation.
- A culture of fear creates covert collusion to violate good requirements processes. As such, the problem cannot be solved without top management change.
- Guidelines specify the principles and policies within which results are to be accomplished. Guidelines are a way to establish triggers while you are relatively sane, so they will keep you from doing foolish things when the project is driving you insane. Here are a few examples of guidelines:
- Brooks's Law: Adding X per cent to the staff will not generally speed the schedule by X per cent.
- The Square Law of Computation: Adding X per cent to the schedule will not accommodate X per cent increase in functionality.
- Jones's Law: Those parts of the product that don't go through the entire development process will cause 90% of your problems.
- All resources are not created equal. Human, financial, technical, or organizational resources each have their own algebra, so you cannot assume that each party to the beginning of a project knows what the resource commitments mean.
- The most common accountability fallacy in software projects is to mistake effort for results. Lacking any better measure, you have a single standard of performance—the time put into the job, not the product produced.
- Another important part of accountability is the time at which evaluations take place. Reporting deadlines and delays often ensure that all reports will be works of fiction.
- When negotiations at the start of a project are made in an atmosphere of fear and intimidation, the project personnel will agree to everything while simultaneously looking for ways to escape. The same dynamic reappears every time management swoops down to take a look at progress.
- Management reviews are also popular in blaming cultures as a way of punishing any project that fails to provide management with a series of glowing reports. A three-day circus parade of project progress violates the basic principles of cybernetic management: Act early, act small, using more-or-less continuous feedback.
- In most of these large reviews, there is no possibility that the project could be canceled, no matter how bad the material, because of how much has been invested already. Moreover, there is essentially no chance that any major change could be made. The chunk of work is too big.
- There are many other ways to get information for managing projects than by conducting traditional management reviews. The Hudson's Bay Start (or shake-down cruise) is one of the most effective types of small, relevant, timely review.
Chapter 2. 프로젝트를 정확하게 유지시키기 (Sustaining Projects Correctly)
Summary
- The plan you make at the beginning of a project says, "If we can do these things, I will get the result I now want." It doesn't say, "No other way will get it," or "I won't change my mind about what I want."
- To become an Anticipating manager, you also need to anticipate that nobody can anticipate everything. Therefore, you need to examine some of the common process models from a more practical point of view, to determine under which conditions each is applicable.
- The Waterfall Model underlies all other development process models. The essence of all Waterfall Models is that one thing happens after another, that water doesn't run uphill. When one stage is finished, it's finished, and there's no going back.
- The output of each stage of the waterfall defines what the next stage has to do, each being a further translation of the original desires. If there's been nothing lost or added in translation, the final output is what was desired. The Waterfall Model is the simplest class of processes, and to use anything else is to add complication. Therefore, you should always use the Waterfall Model, when it applies.
- The Cascade Model is a collection of waterfalls, one after the other, or at times one beside another. Cascading is effective because of the Square Law of Computation. Decomposing one large problem into two smaller problems may be half the difficulty and also less risky. However, there is always an integration cost to cascading.
- Parallel cascades can be used for speed or to reduce risk by setting up two or more waterfalls to build the same project. The best (or quickest) result can be chosen as the product, and/or the multiple products can be used as reference tests for each other.
- The popular Spiral Model is a type of cascade, but drawn in a spiral to show cumulative cost (by distance from the center) and progress on each cycle (by angular displacement). Perhaps the strongest feature of the Spiral Model is the way it emphasizes that development (or maintenance, for that matter) is a series of cycles, each consisting of the same kinds of processes. The Spiral Model, however, is actually more of a process vision, and may mislead the people who are actually carrying out the process.
- Iterative enhancement is software development based on an existing piece of software as a base. There are a number of variations of iterative enhancement, as when
- the requirements have changed only incrementally, little enough that much of the original system can be preserved
- the functional requirements are preserved but the design may change
- the design is preserved, but the code may change
- Iterative enhancement is a form of reuse. Reusable code is a great idea. Like all great ideas, it must be managed.
- Another way to look at reuse in software development is to consider what is actually the most common method today of obtaining software: the off-the-shelf method. This is the method we use when we buy a software application. Someone else did the development, so we simply need to apply it to our needs.
- People frequently bypass all the early stages of software development and use their existing software in some new way. Some software is designed to encourage this kind of reuse, but some is not. Users don't seem to care, because they reuse the software with which they're most familiar.
- Prototyping is many things under a single term:
- a process to get requirements
- a process to get something working quickly, perhaps to
- relieve pressure from customers or management
- get a feel for a system
- simulate system performance early in the development cycle
- a way to start writing code early, perhaps to smooth the workload, or perhaps just to do something developers like better than requirements work
- a disciplined process of incremental development
- a way to prove a concept or measure something
- a synonym for hacking
- The essence of prototyping is "build-a-little, learn-a-little, build-some-more." We call this hacking when the amount built at each stage is very small. When the increments are intermediate in size, we may call the approach "rapid" prototyping, though calling it that doesn't make it rapid.
- Top-down development (as opposed to top-down design) is one way of prototyping. First you build a skeleton embodying the general structure of the application. As development progresses, you fill in the details by replacing the stubs with code that more and more closely resembles the desired finished product. Unlike top-down design, you don't have to know the detailed requirements when you start the process.
- To be successful, prototyping requires more management discipline than other forms of development, not less as many people believe.
- Regardless of the combination of methods used, they are merely templates to guide you in making a project plan. The plan will elaborate the template in more detail, ideally decomposing everything to a connected network of standard task units. After you follow it for a while, something happens that you didn't anticipate. Now you have more information than you had at the beginning, so you replan, perhaps even switching development models.
- Slack allows you to keep replanning to a minimum. Slack can take the form of resources, time, and quality (requirements). Much of the manager's job in the middle of a project is trading one kind of slack for another, to deal with contingencies. Slack is the principal method for coping with project risks. Anticipating project managers forge all three types of slack in their plans—the amount depends on the amount of uncertainty about the future.
- Operating a project with less slack than appears prudent increases the chance of total project failure. Weigh the cost of slack and the risk of failure against the value of completing the project as planned.
Chapter 3. 프로젝트를 적절하게 종료시키기 (Terminating Projects Properly)
Summary
- In well-managed projects, termination comes more or less as planned, with the delivery of the desired product or modification. Perhaps the greatest challenge and test of a good manager is the ability to terminate projects that should be terminated, when they should be terminated.
- Testing is productive, but not production. In an Anticipating organization, testing is merely part of every standard task unit in which something is built, and putting testing in a separate box may mislead people into thinking that testing is done once, at the end of the entire process.
- Process testing asks, "Where are we in the process?" Product testing asks, "What state is the product in?" The requirements or prerequisites part at the front of a standard task unit is a process test, and so is the review at the end. In the task itself, there may or may not be product testing, but one of the things the review will examine is whatever testing has been done. Using this and other information, the review will determine whether the task of producing the product is finished.
- Most process tests take the form of asking, "Should we terminate?" or "Should we replan the task?" Product tests are different, asking, "What are the faults in this product?" Any evidence that a project is not working earnestly and effectively to expose faults is evidence for a process test that says:
- IF faults are being hidden
- THEN replan project.
- Most software work takes place at the level of the fix, the patch, or the update in some sub-phase called testing—that is, doing construction that was not called construction. Vast resources are consumed by developers who continue to build long after the building phase is finished.
- Adding a line back from one stage to another does not give a true picture of the testing/quick-fix/hacking process. Since the number of iterations is unknown, this kind of shorthand easily creates a Downfall Model. Such unbounded process loops are one of the primary sources of overruns of project estimates because hacking starts as soon as the lid of discipline is removed under the guise of testing.
- You can estimate the number of development cycles based on an estimate of the number of faults left that need fixing after the first iteration and after each subsequent iteration. These estimates of remaining faults tend to be characteristic of each organization's culture, and are among the first measures you should obtain if you wish to stabilize your development processes. By comparing the number of faults removed to the estimate, you get an early indication that you may have more iterations (or fewer) than you'd planned.
- Never use loops in a process description. Never use loops in a plan. If you want your plans and process descriptions to be true to life, use your measurements to unroll the loops.
- Managers without access to appropriate models and measurements tend to do exactly the wrong thing when a project is going sour. Formal measurements may not help you to recognize when your project is starting to fail, because the formal measurement system may be the first thing to start failing. You need to watch and listen for signs outside that system, and STOP the project when they arise.
- The earliest indicator that a project may need terminating is when you're asked to certify that a plan as achievable, when it's not. In answer to a request or demand to certify that the plan is achievable, you can say, "Perhaps it is achievable, but I don't know how to achieve it."
- "Test complete" is often scheduled according to when some senior manager has been promised a demonstration, not when the quality has reached a certain level. Under this kind of pressure, managers are often asked to certify that a product is acceptable, generally when it is not—a sure sign that the project ought to be terminated and rebirthed with a new acceptance criterion
- In the middle of a project, perhaps the most reliable indicator that a project may need terminating is a decline in morale—the overall intuitive assessment of the project's chances by the entire staff.
- A plan is not a process, but a process model for one particular project. It is not a general process model, but an instantiation of one, since it's unlikely that we will ever have two projects with exactly the same plan, even if they follow the same process model.
- Every plan must plan for various kinds of termination. The unanticipated need for another iteration as a signal that your plan has gone sour, that you need a new plan. And, since the plan is the seed of the project, what you really need is a new project.
Chapter 4. 작게 만들어서 빠르게 만들기 (Building Faster By Building Smaller)
Summary
- Futile efforts to change software more quickly often mean that we change our software organizations more slowly. The Satir Change Model suggests a number of principles that show how to respond to pressures to speed up the building process without destroying your plans for long-term improvement of your organization
- There are two fundamental tactics you can use to accelerate building process:
- increase your capacity for building
- decrease the size of what you're building
- Increasing capacity—not just numbers, but skill as well—in the long run helps achieve schedules, high performance, low costs, and just about everything else—and so will be the subject of later chapters. Decreasing size, however, is something that managers can control in the short run.
- System size enters into many of the fundamental dynamic feedback loops of software engineering. For example, in a bigger system, there are
- more faults
- more places to look for faults
- more possibility of faults interacting, which confuses location efforts
- This dynamic suggests that the system in which we are looking for faults should be as small as possible.
- The most important measure of system size is the mental size of the system—the amount of mental effort required to play the game effectively. This size may correlate roughly with lines of code, but there are many ways in which programs L and B with the same number of lines may be very different in this meaning of size.
- In addition, mental size is also relative to whose mentality is involved. Smarter, better trained people working with superior tools will see a smaller system.
- Systems grow in functionality when the software developers placate the customers or their surrogates, the marketers.
- Reducing scope does not necessarily mean giving customers less. If you have an Anticipating process for gathering, analyzing, and ranking requirements, you'll know what customers want and what's most important to them.
- Once you've actually been working with the system, you have data on which functions have shown the most faults. If you choose the worst ones to get rid of, you can have an effect that's out of proportion to size. An order-of-magnitude reduction in location time can easily result from a small reduction in function.
- An Anticipating organization will have foreseen the possibility of late reduction in scope and maintained a good, open relationship with its customer. With such a relationship, it's much more likely that this offer will not be a surprise, and not be confrontational.
- You can avoid de-releasing trouble if you build top down with the most important functions being built and integrated first, because then 90% complete would probably give 99.9% of value. As a variant, you can produce some of the new pieces in prototype form, then offer them to the customer.
- No software product was ever delivered fault-free, so one way to eliminate the worst part is to ask your customers to put faults in priority order:
- F. I cannot use the system with this fault.
- D. I can use the system for a certain time with this fault, at a cost of X.
- C. I can use the system indefinitely with this fault, at a cost of Y.
- B. I can use the system indefinitely with this fault, at no cost.
- A. What fault?
- A++. What a great feature!
- Cutting down system size is a powerful intervention, and the earlier you can do it, the more powerful it is:
- Fewer resources are wasted on things that don't have to be done.
- There's more time and less pressure to get people trained to new tasks
- Project managers will be able to set reasonable expectations
- It's easier on the people in your organization. Overload is like cancer, and feeds on itself.
- Some of the dynamic size effects are relative to the schedule. Therefore, some of the effects of size reduction can be gained by slipping the schedule. Before you negotiate a schedule slippage, however, study the dynamics of your system. Attempts to deliver a system on an impossibly short schedule will only lengthen the actual time you need to deliver.
- Ultimately, what helps you most in managing system size is courage and realism.
- Some late requirements changes are necessary in any organization, but you must never forget that they are increasing the size of the system. The dynamics of system size are nonlinear, so you need to be very generous in estimating the effect of late arriving requirements, and make your side of the business case, too.
- Tell your customer in advance that in the event changes are requested, a specified process will be used to evaluate the request and that it will take X amount of time. Late surprises produce angry customers, diminish trust, and may turn the entire relationship adversarial rather than cooperative.
- Remember the Helpful Model: Most of the time, in spite of appearances, everybody is trying to be helpful. Generally, your customers simply don't understand software quality dynamics—that's your profession, not theirs.
Chapter 5. 정보 자산들을 보호하기 (Protecting Information Assets)
Summary
- In construction projects as in software development, changes can be introduced into translation from design to manufacturing by builders who are trying to improve the product, and problems can arise if those changes aren't subjected to the same rigorous procedure as the initial concept. In the light of experience with software systems, an Anticipating manager will anticipate that unreviewed changes are dangerous and take preventive action.
- Information systems are assets, and a major part of your job as manager is to protect your organization's assets. Many of the organization's assets are in the form of information:
- requirements databases
- code libraries
- data dictionaries
- test libraries
- designs
- standards
- project plans
- process descriptions
- process histories
- measurement libraries
- manuals and documents of all sorts
- Code libraries—particularly object code libraries—are the asset of last resort. A change in the object code library affects the behavior of a system directly, without any further step in which to check for problems. If you want to protect assets, code libraries are the first place to look for improvement.
- Control of other assets need not be as strict as code control, because there are checks and balances that follow certification of data dictionaries, designs, standards, and so forth. Nevertheless, lax asset control tends to produce creeping deterioration, and eventually will lead to the collapse of any software engineering organization, no matter how carefully it controls code.
- As systems grow larger, uncontrolled naming leads to increased error and time to perform engineering tasks. Many organizations operate without any explicit data dictionary and manage to blunder along, but blundering simply won't do if you want your organization to become Anticipating. The most important benefit of names is their consistency. As a manager, your job is to see that naming doesn't get out of hand.
- The value of standards as assets is easy to miss, because their impact is usually through many small savings. Configurations are much easier to manage if you have standards, at the very least because there is much less code to manage.
- A sensible approach to information hiding is to develop a culture, supported by configuration management tools, that encourages builders to play the black box game, and act as if they don't know what's inside all the other black boxes. To do this, manage the design interfaces with all the care given to code management, for these are the only places one person's design changes can affect the correctness of another person's designs.
- Design quality and configuration management quality are in a mutual feedback relationship: Poor design increases errors in code, which produce lots of code changes that increase the load on the code management system. Poor design also makes the code management task more complex, because it's not always clear where things are, and where they're supposed to be.
- A good design acts as a natural index to data stored about a system—such as, code, tests, and maintenance manuals. Often, complaints about the complexity of code management are actually complaints about poor design.
- For some reason, programmers don't consider tests to be assets, perhaps because of the unsystematic way in which many organizations conduct their testing. Sometimes, you can improve this situation by having separate testers do the unit testing.
- Many developers who are quite careful when composing code go into a hacking frenzy when unit testing, destroying whatever design integrity their original version may have possessed. In the process, they also destroy valuable information about the history of the module.
- Error-prone modules are ten to a hundred times more likely than the average module to contain problems. Thus, by noticing the early history of a module, you can predict its future and, if indicated, rebuild it. Because of the universal problem of error-prone modules, a module's history is an essential tool of maintenance.
- Unit testing of modules should create a record of trouble that becomes part of a module process history. This history is a most valuable asset, and should contain
- the complete history of code changes
- the complete history of unit testing
- all test cases, plus expected and actual test results
- issues lists and summary reports from all technical reviews
- the schedule history (which is often an indication of error-proneness)
- To create an Anticipating organization, you must know the past, for there is no other way to anticipate the future. Anything that is developed on a machine can and should be archived, and the archives kept up-to-date and accessible.
- Moving to an improved system of protecting any form of information assets can follow a plan similar to that given for changing the requirements process:
- Measure the true cost and value of protecting the asset.
- Gain control of the changes (inputs) to the asset.
- Gain control of the access (outputs) to the asset.
- Gain control of the entire process of creating and maintaining the asset.
Chapter 6. 설계 관리하기 (Managing Design)
Summary
- As a manager, you may be able to satisfy your passion for design by using it to design organizations and processes, but not information systems. Because designs are assets, there is one point of view that dictates that managers must always stay involved in reviewing designs—the point of view that design is designed for manageability. When a design is too complex to be managed, the manager must insist on simplification.
- When the design debt grows large, management becomes well nigh impossible. The accumulation of design debt can certainly arise from "featuritis," but generally develops from excessive and/or hasty attempts to correct faults.
- The common fallacy is that code is the source of most faults, but most failures found in testing don't come from faults created in coding; they're just found immediately after coding.
- There are many examples of "coding faults" that didn't originate in coding:
- code for which there was no requirement
- code for a wrong design
- code for a wrong requirement
- code not written because we forgot the requirement
- code that's too long because the data structure was clumsy
- code that's wrong because interface was too complex
- code that's wrong because two parts of the design had different ideas
- Most faults originate in requirements and design, though process errors are also significant in poorly managed organizations. Process errors are caused by the development process, such as duplicates, zaps, and failures to update. Many of them can be addressed by improved process design, which is definitely a management responsibility.
- Increased design effort decreases coding effort in developing or maintaining an information system when it results in
- a better-designed data structure
- cleaner interfaces
- fewer switches and flags
- fewer global variables
- a more testable system
- reuse of constructs
- The direct effect of some of these improvements is a reduction in coding effort
- Decreasing direct coding effort is not the only positive effect of good design. Other important reasons for design effort are
- to decrease the number of large-scale errors
- to make the time to build is also less variable, making estimating and control easier for the management
- reducing the total number of faults to be repaired
- reducing the time and effort spent in testing
- making code more understandable, and thus more easily maintained
- The change to an Anticipating organization is a partly a change in emphasis from coding to design. Only poor designers allow themselves to be rushed by poor managers, and vice versa.
- As a manager, you can at least help your organization prevent some of the worst design mistakes, such as
- Using a technology not because it's appropriate, but because it's there.
- Being different at any cost; reinventing whenever possible; copying nothing, not even good ideas.
- Just plain stupidity.
- Too many cooks.
- Oops! Where the hell are we going to put this?
- You need not be a designer to prevent these blunders. You simply need to be the last bulkhead of sanity.
- It's important for an organization to perform some scanning for new technology. But even when something new and apparently useful comes up, it should never become a license to bypass the ordinary design process.
- Designers who can't seem to use anything that anyone else ever thought of before are always fooling themselves. When you think you're being original, you're usually just being unaware of what went before you. Most programs are not, and need not be, masterpieces of original design.
- Whenever possible, watch for and exploit three levels of reuse:
- sharing design ideas, the most productive type of sharing
- sharing copies of source code, but modifying it (not maintaining the connection with the original)
- sharing object code
- Bad design destroys understandability, and anything that destroys understandability destroys design. Doing things in a hurry reduces the quality of thinking.
- Slack is always needed in complex systems to investigate the unknown future, so allow slack in designs and do not push designs to the limit.
- Other things being reasonably equal, favor simple designs over complex designs. Do not, however, mistake the simplistic for the simple.
- It's a good idea to keep the architect involved in the building process—to learn, not to stand over the builders and critique their work.
- Design is supposed to be forethought; afterthoughts are an indication of failure in the design process. As an Anticipating manager, you can help prevent afterthoughts by a few simple policies.
- Insist that all designs be written down so they can be reviewed.
- Apply the Rule of Three.
- Don't accept designs that are described as "the only way."
- Apply the Paradox Rule.
- Don't accept designs from designers who haven't confronted the fundamental trade-offs in the problem and given you a choice of how you would like to make the trades.
- Insist that you understand what problems the design actually addresses, by applying reverse design.
Chapter 7. 기술 도입하기 (Introducing Technology)
Summary
- The choice and use of technologies is always a balance between present and future. We use tools because they help us reduce costs and increase quality, but before we can use a tool, we must learn to use it. The learning takes us through the Satir Change Model, increasing costs and exposing us to serious mistakes. By improving our management of the process of introducing tools, we can lower the costs and reduce these mistakes.
- To change tool use, we need to change the culture, not vice-versa. A good way to start changing tool use is to conduct a tool survey to discover what people are doing with the tools they have. Usually, the survey shows that what is needed is not more tools, but management guidance to get more benefit from the tools we acquired.
- People in an organization use the tools they have (or don't use them) in ways that are characteristic of their organization's cultural processes, and particularly its management style, which determines
- what tools they choose
- how they obtain them
- how they socialize tools
- how they use them
- Oblivious organizations make little use of tools. Variable organizations often use tools quite well, but generally on an individual basis. Routine organizations often use tools more broadly than Pattern 1 organizations, but the use of these tools is both shallow and reluctant.
- Receptor groups identify and evaluate technological opportunities. They ask, "How can I take technology and apply it to how I do business?" These groups understand technology and their organizations, so they make the match between a general technology and a specific context.
- Steering organizations use tools cautiously, but rather well, on the whole, though often without an overall plan or coordination. Anticipating organizations use tools vigorously, but always with a result in mind. They almost always have a specially trained receptor group that proactively searches for generally useful tools, as well as tools to address specific process problems. Because tools are socialized by trained change artists, individuals who need tools, get tools and use them well.
- The First Law of Technology Transfer says that long-range good tends to be sacrificed to short-range good. The battle cries of the First Law are all too familiar:
- We don't have time to do it right… .
- We can't spare him right now… .
- We'll assign her one-eighth time to the task… .
- We'll do it in our spare time… .
- The Second Law of Technology Transfer says that short-range feasibility tends to be sacrificed to long-range perfection. The battle cries of the Second Law are also well known:
- It's not part of the plan… .
- We'll set up a task force… .
- It's not the elegant way… .
- We need to study the implications… .
- When you hear the NT Visionaries arguing over the perfect tool to solve your problems, step in and find something useful and specific for them to do. Don't let them evade crises by irrelevant tool building, though when the crisis is over, they can become your best tool designers.
- Even the organization in Chaos has all the tools it needs, though most people don't know about them. Work first under the hypothesis that your tool problem is not one of manufacturing, but of distribution.
- Use a dual strategy to beat the two Laws of Technology Transfer: Find the long-term solution while using a short-term solution to relieve the pressure.
- The Ten Commandments of Technology Transfer form a useful mnemonic guide to avoiding the sins of technology transfer:
- Thou shalt have a plan to lead thee out of the wilderness.
- Thou shalt not worship thy plan.
- Thou shalt ask for no person in vain.
- Thou shalt not work seven days a week.
- Thou shalt honor thy users and listen to them.
- Thou shalt not kill support for change.
- Thou shalt not adulterate the work.
- Thou shalt not steal resources from the work.
- Thou shalt not bear false witness against thy plan.
- Thou shalt not covet thy neighbor's optimal technology.
- The power of the Ten Commandments is magnified if you remember the Helpful Model:
- No matter how it looks, everyone is trying to be helpful.
- If you forget this commandment, you will begin to counter so-called resistance, which will engender real resistance—not to the technology, but to your anti-resistance efforts.
- Listen for the real information present in all resistance, so that you can use this information to correct your mistakes and enlist everybody's participation in changing your organization.
Epilogue
.