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!