NASA의 프로젝트 매니저를 위한 100가지 룰

The Project Manager 프로젝트관리자 Rule #1: A project manager should visit everyone who is building anything for his project at least once, should know all the managers on his project (both government and contractor), and know the integration team members. People like to know that the project manager is interested in their work and the best proof is for the manager to visit them and see first hand what they are doing. Rule #1:프로젝트 관리자는 최소한 한번은 그가 담당하고 있는, 프로젝트를 수행하고 있는 모든 사람들을 찾아가 봐야 하고, 그 프로젝트에 관련된 모든 관리자들을 알아야 하며 (집행 부 및 계약자들 모두), 통합 팀 멤버들도 알아야만 한다. 사람들은 프로젝트 관리자가 그들의 일에 관심을 가지 고 있다는 것을 좋아하고, 그것을 잘 증명하는 것은 관리자가 그들을 방문하고 그들이 무엇을 하고 있는 가를 직접적으로 보는 것이다. Rule #2: A project manager must know what motivates the project contractors (i.e., their award system, their fiscal system, their policies, and their company culture). Rule #2: 프로젝트 관리자는 그 프로젝트 계약자들을 동기부여 시키는 것이 무엇인지를 반드시 알아야 한다( 그들의 보상 시스템, 재무시스템, 정책, 그리고 회사문화 와 같은). Rule #3: Management principles still are the same. It is just that the tools have changed. You still find the right people to do the work and get out of the way so they can do it. Rule #3: 관리 원칙은 아직 같다. 단지 도구만 바뀐다. 당신은 여전히 일을 수행할 적절한 사람들과 그 일을 수행 하기 위해 사라져 줘야 할 사람을 발견한다. Rule #4: Whoever you deal with, deal fairly. Space is not a big playing field. You may be surprised how often you have to work with the same people. Better they respect you than carry a grudge. Rule #4: 당신이 누굴 상대하든, 공정하게 하라. 공간이라는 건 생각만큼 크지 않다(세상은 좁다). 얼마나 종종 같은 사람들과 당신이 일해야 하는지 아마 놀라게 될 것이다. 그들이 원한을 품기 보단 당신을 존경하게 하는게 낫다. Rule #5: Vicious, despicable, or thoroughly disliked persons, gentlemen, and ladies can be project managers. Lost souls, procrastinators, and wishy-washies cannot. Rule #5: 부도덕하거나, 비열하거나, 혹은 철저히 싫어하는 사람이 프로젝트 관리자가 될 수 있다. 멍하거나, 일을 질질 끌거나, 흐리멍텅한 사람은 프로젝트 관리자가 될 수 없다 Rule #6: A comfortable project manager is one waiting for his next assignment or one on the verge of failure. Security is not normal to project management. Rule #6: 안락한 프로젝트 관리자는 다음 임무를 기다리는 사람이거나, 실패의 직전에 있는 사람이다. 안도감은 프로젝트 관리에 통상적인 것이 아니다. Rule #7: One problem new managers face is that everyone wants to solve their problems. Old managers were told by senior management?quot;solve your own darn problems, that is what we hired you to do." Rule #7: 새로운 관리자들이 부딪치는 하나의 문제점은 모든 이들이 그들 자신들의 문제를 풀기 원한다는 것이다. 오래된 관리자들은 선임 경영진들에게 이런 소리를 듣는다. "그런 빌어먹을 문제점들을 해결해! 우리가 당신을 그래서 고용 한 거야." Rule #8: Running fast does not take the place of thinking for yourself. You must take time to smell the roses. For your work, you must take time to understand the consequences of your actions. Rule #8: 일을 빨리 하는 것은 당신 자신을 위한 생각의 시간을 주지 못한다. 당신은 장미 냄새를 맡을 만한 시간을 반드시 가져야 한다(여유를 가져라). 당신의 일을 위해, 당신은 당신 활동의 결과를 이해 할 수 있는 시간을 반드시 가져야 한다. Rule #9: The boss may not know how to do the work but he has to know what he wants. The boss had better find out what he expects and wants if he doesn't know. A blind leader tends to go in circles. Rule #9: 보스는 작업을 수행 하는 것에 대해 아마 모를 것이다, 그러나 그는 반드시 그가 원하는 것이 무엇인지를 알아야 한다. 만약 모르고 있다면, 보스는 그 자신이 무엇을 기대하고 원하는지를 발견해야 할 것이다. 눈먼 리더는 애만 쓰고 소득이 없는 경향이 있다. Rule #10: Not all successful managers are competent and not all failed managers are incompetent. Luck still plays a part in success or failure but luck favors the competent hard working manager. Rule #10: 모든 성공적인 관리자들은 능력 있고, 모든 실패한 관리자들은 능력이 없는 건 아니다. 운은 여전히 성공하느냐 실패하느냐에 한 부분을 차지한다. 그러나 운은 열심히 일하는 능력 있는 관리자를 선호한다. Rule #11: Never try to get even for some slight by anyone on the project. It is not good form and it puts you on the same level as the other person and, besides, probably ends up hurting the project getting done. Rule #11: 결단코 프로젝트에 관련된 어떤 이에게도 경시 받지 말도록 노력해야 한다. 그건 별로 좋지 않다. 그리고 그것이 당신을 다른 사람과 같은 레벨에 두게 한다. 게다가, 프로젝트 수행에 상처를 남기고 끝내게 만들 수 있다. Rule #12: Don't get too egotistical so that you can't change your position, especially if your personnel tell you that you are wrong. You should cultivate an attitude on the project where your personnel know they can tell you of wrong decisions. Rule #12: 너무 자기 중심적이어서 자기 자신의 맘을 바꿀 수 없는 경우는 만들지 마라, 특별히 당신의 인력이 당신에게 당신이 잘못됐다라고 말한다면 더욱. 당신은 그 프로젝트에서 당신의 인력들이 당신의 잘못된 결정을 말할 수 있도록 하기 위한 태도를 길러야 한다. Rule #13: A manager who is his own systems engineer or financial manager is one who will probably try to do open heart surgery on himself. Rule #13: 그 자신이 시스템 관리자 이거나 혹은 재정 관리자인 관리자는 아마도 마음을 열수 있도록 하기위한 시도를 해야 할 사람일 것이다. Rule #14: Most managers succeed on the strength and skill of their staff. Rule #14: 대부분의 관리자들은 그들 스텝의 능력과 기술에 힘입어 성공한다 Initial Work 초기작업 Rule #15: The seeds of problems are laid down early. Initial planning is the most vital part of a project. The review of most failed projects or project problems indicate the disasters were well planned to happen from the start. Rule #15: 문제의 싹은 일찍부터 나타난다. 개시 계획은 프로젝트의 가장 중요한 부분이다. 대부분의 실패한 프로젝트, 혹은 프로젝트 문제들을 검토해 보면 처음부터 그런 재앙은 발생하도록 잘 계획되어져 있었다는 것을 가르쳐 준다. Communications 의사소통 Rule #16: Cooperative efforts require good communications and early warning systems. A project manager should try to keep his partners aware of what is going on and should be the one who tells them first of any rumor or actual changes in plan. The partners should be consulted before things are put in final form, even if they only have a small piece of the action. A project manager who blindsides his partners will be treated in kind and will be considered a person of no integrity. Rule #16: 협력은 좋은 의사소통과, 초기 경고 시스템을 요구한다. 프로젝트 관리자는 그의 파트너들이 도대체 무슨 일이 벌어지고 있는지 알 수 있도록 노력 해야 하며, 어떤 루머에 대해서, 혹은 계획의 실제적 변화에 대해서 첫째로 그들에게 말할 수 있어야 한다.파트너들에게 모든일이 최종 마무리가 되기 전에 상의 되어져야 한다. 설혹 그들 활동 분량이 조금 이라 하더라도. 파트너를 앞 못 보게 하는 프로젝트 관리자는 친절히 다루어 지겠지만, 또한 진실치 않은 사람으로 간주 될 것이다. Rule #17: Talk is not cheap; but the best way to understand a personnel or technical problem is to talk to the right people. Lack of talk at the right levels is deadly. Rule #17: 대화 하는 것이 그렇게 값싼 것이 아니다(많은 투자가 필요하다); 그러나 인력을 이해하고, 기술적 문제를 이해하는 최고의 방법은 그 부분에 적절한 사람과 이야기 하는 것이다. 정확히 필요한 단계에서 대화의 부족은 치명적이다. Rule #18: Most international meetings are held in English. This is a foreign language to most participants such as Americans, Germans, Italians, etc. It is important to have adequate discussions so that there are no misinterpretations of what is said. Rule #18: 대부분의 국제 미팅은 영어로 진행된다. 이것은 대부분의 아메리칸, 독일인, 이탈리아인 등과 같은 대부분의 참가자들에게 외국어인 셈이다. 무엇이 말해졌는지에 대한 잘못된 해석이 생기지 않도록 적당한 토의를 가지는 것은 중요하다. Rule #19: You cannot be ignorant of the language of the area you manage or with that of areas with which you interface. Education is a must for the modern manager. There are simple courses available to learn computerese, communicationese and all the rest of the modern "ese's" of the world. You can't manage if you don't understand what is being said or written. Rule #19: 당신은 당신이 관리하는 지역의 언어를 무시하거나, 당신이 접촉하고 있는 지역에 대한 것을 무시할 수 없다. 현대 관리자들에게 교육은 필수다. 컴퓨터 언어나 커뮤니케이션 언어, 그리고 세상의 나머지 현대적 'ese's(언어; 풍)'에 대해 배울 수 있는 길들은 이용 가능하다. 당신이 만약 무엇이 말해졌고 쓰여졌는지를 이해 못한다면 당신은 관리 라는 걸 할 수 없다. People 인적자원 Rule #20: You cannot watch everything. What you can watch is the people. They have to know you will not accept a poor job. Rule #20: 당신은 모든걸 다 지켜볼 수 없다. 당신이 지켜볼 수 있는 건 사람들이다. 그들은 당신이 빈약한 작업은 받아들이지 않을 거란 걸 알아야 한다. Rule #21: We have developed a set of people whose self interest is more paramount than the work or at least it appears so to older managers. It appears to the older managers that the newer ones are more interested in form than in substance. The question is are old managers right or just old? Consider both viewpoints. Rule #21: 우리는 자신들의 관심이 수행하는 일 보다는 더 장대한 것에 있는 부류의 사람들을 면밀히 생각해 왔다. 혹은 적어도 이것이 오래된 관리자들에게 나타나곤 한다. 새로운 것들에 대해 개체보다는 틀에 더 관심을 가지고 있다는 것이 오래된 관리자들에게 나타난다. 문제는 오래된 관리자들이 옳으냐 아니면 그냥 오래돼서 그런 것이냐 하는 것이다. 두 관점에 다 관심을 가져라. Rule #22: A good technician, quality inspector, and straw boss are more important in obtaining a good product than all the paper and reviews. Rule #22: 좋은 기술자, 고급 인스펙터, 그리고 지푸라기 보스에게 모든 보고서나 검토보다는 좋은 생산물을 획득하는 것이 더 중요하다. Rule #23: The source of most problems is people, but darned if they will admit it. Know the people working on your project to know what the real weak spots are. Rule #23: 대부분 문제의 원천은 사람이다. 그러나 만약 그들이 그걸 인정한다면 쓸데 없는 것이다. 정말 약한 부분이 어디인지 알려거든, 당신의 프로젝트에서 일하고 있는 사람들을 알아라. Rule #24: One must pay close attention to workaholics뾦f they get going in the wrong direction, they can do a lot of damage in a short time. It is possible to overload them and cause premature burnout but hard to determine if the load is too much, since much of it is self generated. It is important to make sure such people take enough time off and that the workload does not exceed 1 1/4 to 1 1/2 times what is normal. Rule #24: 일 중독에 대해 반드시 관심을 가져야 한다. 그것으로 인해 만약 사람들이 잘못된 방향으로 간다면, 짧은 시간안에 상당한 손해를 입힐 수 있다. 그들을 부담시키고, 때이른 에너지 소모를 발생 시킬 수 도 있다, 그러나 그런 것들의 많은 부분이 자연 발생적(자기 본연의)이기에, 그들이 그 짐이 너무 많은 것 이라는 걸 판단 하는 것은 어렵다. 그런 사람들이 충분히 쉴 수 있도록 만들고. 작업 과부하가 통상적으로 받아들여지는 1 1/4에서 1 1/2배를 초과하지 않도록 하는 것이 중요하다. Rule #25: Always try to negotiate your internal support at the lowest level. What you want is the support of the person doing the work, and the closer you can get to him in negotiations the better. Rule #25: 항상 하위 레벨에 당신의 내부 지원자와 교섭하도록 하라. 당신이 원하는 것은 일을 하고 있는 사람의 지원이고, 당신이 교섭으로 그와 더 가까이 할 수 있으면 더 좋다. Rule #26: If you have someone who doesn't look, ask, and analyze; ask them to transfer. Rule #26: 만약 당신이 보지않고 묻지 않고 분석하지도 않는 사람을 가지고 있다면, 그들을 (다른곳으로)옮기도록 요구하라. Rule #27: Personal time is very important. You must be careful as a manager that you realize the value of other people's time (i.e., the work you hand out and meetings should be necessary). You must, where possible, shield your staff from unnecessary work (i.e., some requests should be ignored or a refusal sent to the requestor). Rule #27: 개인적인 시간은 상당히 중요하다. 당신은 관리자로서, 다른 사람들 시간의 가치를 깨닫는 것에 대해 반드시 주의해야 한다( 당신이 제공한 작업과 미팅은 필요한 것이다 와 같은..) 당신은 반드시, 가능한 상황에서, 불필요한 일로부터 당신의 스탭을 보호해야 한다( 몇몇 무시될 수 있는 요구사항 들, 혹은 요구자에게 거절을 표시하는 것 같은 …) Rule #28: People who monitor work and don't help get it done never seem to know exactly what is going on (being involved is the key to excellence). Rule #28: 작업을 모니터 하고, 그것을 마치는데 도움을 주지 못하는 사람들은 무엇이 어떻게 돌아가는지 결코 알지 못할 것이다( 포함(관계)되는 것은 더할 나위 없이 중요한 것이다). Rule #29: There is no greater motivation than giving a good person his piece of the puzzle to control, but a pat on the back or an award helps. Rule #29: 뛰어난 사람에게 조정할 필요가 있는 그의 퍼즐의 한 조각을 주는 것보다 더 나은 동기부여는 없다. 그러나 등을 두드려 주거나, 보상하는 것 같은 것도 중요하다. Rule #30: It is mainly the incompetent that don't like to show off their work. Rule #30: 자신들의 작업 보이길 좋아하지 않는 것은 주요한 무능력이다. Rule #31: There are rare times when only one man can do the job. These are in technical areas that are more art and skill than normal. Cherish these people, but get their work done as soon as possible. Getting the work done by someone else takes two or three times longer and the product is normally below standard. Rule #31: 오직 한사람이 할 수 있는 일이 있는 때는 드물다. 보통 보단 좀더 나은 기능이나 기술이 있는 기술적인 분야가 있다. 이런 사람들을 잘 돌봐야 한다. 그러나 가능한 그들의 일을 빨리 마치도록 하라. 그 일을 다른 사람이 한다는 것은 두배 혹은 세배더 길게 지연 시키게 한다. 그리고 생산물은 보통 표준 이하가 된다. Rule #32: People have reasons for doing things the way they do them. Most people want to do a good job and, if they don't, the problem is they probably don't know how or exactly what is expected. Rule #32: 사람들은 그들 자신만의 방법대로 일들을 하는 이유가 있기 마련이다. 대부분의 사람들은 만족할 만한 작업을 하길 원한다. 만약 그러지 못하다면, 어떻게 해야 하며, 혹은 정확히 무엇이 기대되어지는지를 모르는 문제가 생기게 된다. Rule #33: If you have a problem that requires additional people to solve, you should approach putting people on like a cook who has under-salted the food. Rule #33: 만약 당신이 문제를 풀기 위해 추가적인 사람 동원이 요구되는 문제를 가지고 있다면 당신은 요리하는데 경험이 적은 요리사처럼 사람들을 배치시키는 것에 접근해야 한다. Reviews and Reports 검토 및 보고 Rule #34: NASA has established a set of reviewers and a set of reviews. Once firmly established, the system will fight to stay alive, so make the most of it. Try to find a way for the reviews to work for you. Rule #34: NASA 는 검토자 팀과 검토 팀을 설립했다. 한번 단단히 설립되면, 시스템은 생존하기 위해 열심히 싸울 것이다. 그러니 대부분의 것들을 그렇게 하라. 검토자들이, 당신을 위해 일 할 방법을 발견하도록 노력하라. Rule #35: The number of reviews is increasing but the knowledge transfer remains the same; therefore, all your charts and presentation material should be constructed with this fact in mind. This means you should be able to construct a set of slides that only needs to be shuffled from presentation to presentation. Rule #35: 검토의 횟수는 증가하지만 지식 전가는 같다; 그러므로 당신의 모든 챠트와 프로젠테이션 자료는 이 사실과 함께 맘속에 구성되어야 한다. 이것은 당신이 프레젠테이션들간에 뒤섞일 필요가 있는 슬라이드들을 구성할 능력이 있어야 한다는 의미이다. Rule #36: Hide nothing from the reviewers. Their reputation and yours is on the line. Expose all the warts and pimples. Don't offer excuses뾧ust state facts. Rule #36: 검토자들로부터 어떤 것도 숨기지 마라. 그들의 명성과 당신의 명성은 같은 선에 존재한다. 모든 약점이나 오점들을 노출 시켜라. 변명하지 말고 사실대로 얘기해라. Rule #37: External reviews are scheduled at the worst possible time, therefore, keep an up-to-date set of business and technical data so that you can rapidly respond. Not having up-to-date data should be cause for dismissal. Rule #37: 외부 검토는 제일 좋지 않은 시간에 스케쥴 되어 있다; 그러므로 비즈니스와 기술적 자료의 최근 세트를 지켜라. 당신이 빠르게 응답할 수 있게 하기 위해. 최근 자료를 가지고 있지 않다면 그건 해고 통지의 원인이 될 것이다. Rule #38: Never undercut your staff in public (i.e., In public meetings, don't reverse decisions on work that you have given them to do). Even if you direct a change, never take the responsibility for implementing away from your staff. Rule #38: 공적인 자리에서 당신의 스텝을 깎아 내리지 마라(공적인 미팅에서, 당신이 그들에게 하도록 주었던 일에 대한 결정을 번복하지 말아야 하는 것과 같은..) 만약 당신이 변화를 관리하게 될 때, 그때 조차도, 결코 당신의 스텝들을 그 수행에 대한 책임으로부터 멀리 하지 말아라. Rule #39: Reviews are for the reviewed an not the reviewer. The review is a failure if the reviewed learn nothing from it. Rule #39: 검토는 검토를 수행한 사람을 위한 것이 아니고 그걸 검토할 사람을 위한 것이다. 만약 검토할 사람이 그것으로부터 아무것도 배우지 못한다면 그 검토는 실패한 것이다. Rule #40: A working meeting has about six people attending. Meetings larger than this are for information transfer (management science has shown that, in a group greater than twelve, some are wasting their time). Rule #40: 작업 미팅은 약 6명의 참관자를 가진다. 이것보다 큰 미팅은 정보 전달을 위한 것이다( 관리 학에서 12명보다 더 큰 그룹에서는 몇몇이 그들의 시간을 낭비하는 경우가 발생한다는걸 말해주고 있다.) Rule #41: The amount of reviews and reports are proportional to management's understanding (i.e., the less management knows or understands the activities, the more they require reviews and reports). It is necessary in this type of environment to make sure that data is presented so that the average person, slightly familiar with activities, can understand it. Keeping the data simple and clear never insults anyone's intelligence. Rule #41: 검토와 보고 횟수는 경영진의 이해와 상대적 이다(경영진이 활동을 적게 알거나 이해할수록, 그들은 더 많은 검토와 보고서를 요구 한다.) 이런 환경 하에서, 활동들에 약간 친숙한 일반적인 사람이 이것을 이해하게 끔 자료가 제공 되도록 확실히 할 필요가 있다. 자료를 간단하고 분명하게 하는 것은 사람의 지적능력을 모욕하는 것이 결코 아니다. Rule #42: Managers who rely only on the paperwork to do the reporting of activities are known failures. Rule #42: 활동 보고를 문서 작업에만 의존하는 관리자들은 실패자로 알려져 있다. Rule #43: Documentation does not take the place of knowledge. There is a great difference in what is supposed to be, what is thought to have happened, and reality. Documents are normally a static picture in time that get outdated rapidly. Rule #43: 문서는 지식을 대체하지 못한다. 무엇으로 존재 할 것인가 하는 것에는 굉장한 차이점이 있다. 무엇이 발생할 것으로 생각되나, 실제는 어떤가? 문서는 일반적으로 , 서둘러서 진부한 사실을 늦지 않게 제공 하는 정적인 그림인 것이다. Rule #44: Just because you give monthly reports, don't think that you can abbreviate anything in a yearly report. If management understood the monthlies, they wouldn't need a yearly. Rule #44: 단지 당신이 매달 보고서를 제출한 것 때문에, 당신이 매년 보고에서 무엇이든 간단히 마칠 수 있을 것이라고 생각하지 말아라. 만약 경영진이 월별 보고를 이해 했다면, 그들은 매년 보고가 필요 없을 것이다. Rule #45: Abbreviations are getting to be a pain. Each project now has a few thousand. This calls on senior management to know hundreds. Use them sparingly in presentations unless your objective is to confuse. Rule #45: 단축(간단히 함)은 고통이 될 수 있다. 각 프로젝트는 지금 몇 천개를 가지고 있다. 이것은 선임 경영진에게 수백개를 알도록 요구하는 것이다. 당신의 목적이 그들에게 혼동을 주는 것이 아니라면, 그것 들을 프레젠테이션에서 알뜰하게 사용해라. Rule #46: Remember, it is often easier to do foolish paperwork that to fight the need for it. Fight only if it is a global issue which will save much future work. Rule #46: 기억하라, 필요와 싸우기 위해서(필요로 인해) 어리석은(필요없는) 문서 작업을 하기 쉽다는걸. 만약 미래 작업에 더 많은 이득을 줄 수 있는 글로벌한 이슈인 경우에만 그렇게 하라. Contractors and Contracting 계약관리 Rule #47: A project manager is not the monitor of the contractor's work but is to be the driver. In award fee situations, the government personnel should be making every effort possible to make sure the contractor gets a high score (i.e., be on schedule and produce good work). Contractors don't fail, NASA does and that is why one must be proactive in support. This is also why a low score damages the government project manager as much as the contractor's manager because it means that he is not getting the job done. Rule #47: 프로젝트 관리자는 계약자 작업에 대한 감독자가 아니다, 그러나 운영자라 할 수 있다. 보상비에 대한 상황에서, 집행부 인력은 계약자가 높은 스코어를 획득할 수 있도록 하기위해 가능한 모든 노력을 들여야 한다( 스케쥴을 잘 맞추거나 좋은 작업을 하게 하는 것 같은..). 그로인해 계약자들은 실패하지 않는다. NASA가 그랬고 그것이 왜 반드시 지원에 있어서 이전 것에 영향을 받아야 하는지 이유 인 것이다. 이것은 또한 왜 낮은 스코어가 집행부 프로젝트 관리자에게, 계약자의 관리자 만큼 손해를 입히는지의 이유이다. 왜냐하면 이것은 그가 그 작업 수행을 마치지 않았다는걸 의미하기 때문이다. Rule #48: Award fee is a good tool that puts discipline both on the contractor and the government. The score given represents the status of the project as well as the management skills of both parties. The project management measurement system (PMS) should be used to verify the scores. Consistent poor scores require senior management intervention to determine the reason. Consistent good scores which are consistent with PMS reflect a well-run project, but if these scores are not consistent with the PMS, senior management must take action to find out why. Rule #48: 보상비는 계약자와 집행부 두쪽 모두에게 훈련 시키기에 좋은 툴이다. 주어진 이 스코어는 프로젝트의 상태뿐만 아니라 양쪽의 관리 기술들도 나타낸다. 프로젝트 관리 측정 시스템은 그 스코어들을 증명하는데 사용되어야 한다. 일관된 나쁜 스코어는 그 이유를 결정하기 위해서 선임 경영진의 중재를 요구한다. Pms와 일치하는 일관된 좋은 스코어는 잘 수행 되고 있는 프로젝트를 나타낸다. 그러나 만약 이들 스코어가 pms와 일치하지 않는다면 선임 경영진은 반드시 왜 그런지를 밝히기 위한 action을 취해야 한다. Rule #49: Morale of the contractor's personnel is important to a government manager. Just as you don't want to buy a car built by disgruntled employees, you don't want to buy flight hardware developed by under- motivated people. You should take an active role in motivating all personnel on the project. Rule #49: 계약자측 인력의 사기는 정부측 관리자에게 중요하다. 당신이 언짢은 사원에 의해 만들어진 차를 사기 원하지 않는 것과 같이, 동기 부여가 되지 않은 사람들에 의해 개발된 비행 하드웨어를 사기 원하지 않는다. 당신은 프로젝트에 관련된 모든 인력들에게 동기 부여할 적극적인 역할을 수행시켜야 할 것이다. Rule #50: Being friendly with a contractor is fine뾟eing a friend of a contractor is dangerous to your objectivity. Rule #50: 계약자와 친하게 지내는 것은 좋지만 계약자와 친구로 존재하는 것은 당신이 객관적으로 존재하는데 위험 요소가 된다 Rule #51: Remember, your contractor has a tendency to have a one-on-one interface with your staff. Every member of your staff costs you at least one person on the contract per year. Rule #51: 기억하라, 당신의 계약자는 당신의 스텝들과 일대일 접촉을 원하는 경향이 있다는 걸 당신 스텝의 모든 멤버들은 매년 그 계약에 대해 당신에게 적어도 한사람의 희생을 치르게 한다. Rule #52: Contractors tend to size up the government counterparts and staff their part of the project accordingly. If they think yours are clunkers, they will take their poorer people to put on your project. Rule #52: 계약자들은 집행부쪽 상대를 평가하고 그것에 알맞게 프로젝트에 그들 쪽 편을 배치하는 경향이 있다. 만약 그들이 당신쪽은 시시하다라고 생각한다면, 그들은 당신의 프로젝트에 일을 더 못하는 그들쪽 사람들을 배치 시킬 것이다. Rule #53: Contractors respond well to the customer that pays attention to what they are doing but not too well to the customer that continually second-guesses their activity. The basic rule is a customer is always right but the cost will escalate if a customer always has things done his way instead of how the contractor planned on doing it. The ground rule is: never change a contractor's plans unless they are flawed or too costly (i.e., the old saying that better is the enemy of good). Rule #53: 계약자들은 그들이 무엇을 하고 있는지에 관심을 기울이고 있는 고객에게 응답을 잘한다. 그러나 계속적으로 그들의 활동을 내다보는 고객들에게는 그렇게 잘하지 않는다. 기본적인 규칙은, 고객이 항상 옳지만 만약 고객이 항상 계약자가 일을 수행하기 위해 어떻게 계획을 했는가 대신, 고객이 자신만의 방법으로 일들을 수행 한다면 비용은 증가 될 것이라는 것이다. 행동 기본 원칙은 : 계획들이 결함이 있거나 너무 비용이 많이 드는 경우를 제외하고는 결단코 계약자의 계획을 바꾸지 마라( 옛말에 보다 더 나은 것은 나은 것의 적이다). Rule #54: There is only one solution to a weak project manager in industry뾤et rid of him fast. The main job of a project manager in industry is to keep the customer happy. Make sure the one working with you knows that it is not flattery but on-schedule, on-cost, and a good product that makes you happy. Rule #54: 산업분야에서, 능력 없는 프로젝트 관리자에 대해 필요한 오직 한가지 해결책이 있다. 빨리 그 관리자를 해고하는 것이다. 산업분야에서 프로젝트 관리자의 주요 업무는 고객을 행복하게 만드는 것이다. 아첨 하는거 좋은데 당신을 행복하게 만드는 일은 제시간에 알맞은 비용에, 좋은 생산물이 만들어 내는 것이라는 걸 당신과 함께 일하고 있는 이가 알게 확실히 하라.   Engineers and Scientists 엔지니어와 과학자 Rule #55: Over-engineering is common. Engineers like puzzles and mazes. Try to make them keep their designs simple. Rule #55: 초과 엔지니어링 은 일반 적인 것이다. 엔지니어들은 퍼즐과 미로를 좋아한다. 그들이 그들의 디자인을 간단하게 만들도록 노력하라. Rule #56: The first sign of trouble comes from the schedule or the cost curve. Engineers are the last to know they are in trouble. Engineers are born optimists. Rule #56: 문제가 발생할 것 같은 첫번째 신호는 스케줄 혹은 비용 곡선에서부터 온다. 엔지니어들은 그들이 문제점을 가지고 있다는 것을 마지막으로 알게 된다. 엔지니어들은 타고난 낙천가 들이다. Rule #57: The project has many resources within itself. There probably are five or ten system engineers considering all the contractors and instrument developers. This is a powerful resource that can be used to attack problems. Rule #57: 프로젝트는 많은 자원들을 가지고 있다. 모든 계약자들과 기계 개발자들을 간주한다면, 아마도 5내지 10개의 시스템 엔지니어들이 있다. 이것은 문제점들을 공격하는데 사용할 수 있는 강력한 자원인 것이다. Rule #58: Many managers, just because they have the scientists under contract on their project, forget that the scientists are their customers and many times have easier access to top management than the managers do. Rule #58: 많은 관리자들은, 그들이 프로젝트의 계약 하에 있는 과학자들을 데리고 있기 때문에, 과학자들이 그들의 고객이고, 관리자들 보다 많은 시간을 좀더 쉽게 최고 경영진들에게 접근 할 수 있다는 걸 잊는다. Rule #59: Most scientists are rational unless you endanger their chance to do their experiment. They will work with you if they believe you are telling them the truth. This includes reducing their own plans. Rule #59: 대부분의 과학자들은, 당신이 그들 실험을 위한 기회를 위태롭게 하지 않는 한 이성적이다. 그들은 만약 당신이 그들에게 진실을 말한다고 믿는다면 당신과 함께 일 할 것이다. 이것은 그들 자신의 계획을 감소 시키는 것을 포함한다. Hardware 하드웨어 Rule #60: In the space business, there is no such thing as previously flown hardware. The people who build the next unit probably never saw the previous unit. There are probably minor changes (perhaps even major changes); the operational environment has probably changed; the people who check the unit out in most cases will not understand the unit or the test equipment. Rule #60: 스페이스 산업에, 이전 항공 하드웨어 같은 것들은 없다. 다음 단계를 세울 사람들은 아마도 이전 단계는 결코 보지 않았을 것이다. 아마도 작은 변화가 있을 것이다(어쩜 좀 큰 변화가 있을지도); 운영 환경은 아마 변화 되어 왔을 것이다; 단계를 체크 하는 사람들은 대부분이 경우에 그 단계 혹은 테스트 장비를 잘 알고 있지 못할 것이다. Rule #61: Most equipment works as built, not as the designer planned. This is due to layout of the design, poor understanding on the designer's part, or poor understanding of component specifications. Rule #61: 대부분의 장비는 디자이너들이 계획한 대로 작업되지 않고, 건설 되는대로 작업되어진다. 이것은 디자인, 디자이너 부분에 대한 잘못된 이해, 혹은 구성 명세 사항의 잘못된 이해의 구조에 기인한 것이다. Computers and Software 컴퓨터와 소프트웨어 Rule #62: Not using modern techniques, like computer systems, is a great mistake, but forgetting that the computer simulates thinking is a still greater mistake. Rule #62: 컴퓨터 시스템과 같은 현대 기술을 사용하지 않는 건 엄청난 실수다. 그러나 컴퓨터 관련 생각들을 잊는 것 또한 여전히 엄청난 실수이다. Rule #63: Software has now taken on all the parameters of hardware (i.e., requirement creep, high percentage of flight mission cost, need for quality control, need for validation procedures, etc.). It has the added feature that it is hard as blazes to determine it is not flawed. Get the basic system working first and then add the bells and whistles. Never throw away a version that works even if you have all the confidence in the world that the newer version works. It is necessary to have contingency plans for software. Rule #63: 소프트웨어는 지금껏 하드웨어의 모든 매개변수들을 나타내 왔다(요구사항 지체, 비행 미션 비용의 높은 퍼센트 비율, 품질 조절의 필요, 정당성 입증 과정 필요 등) 손상되지 않았다는 걸 측정하는 것은 상당히 어렵다는 것이 첨가된 특징이다. 첫 째로 기본적인 작업 수행 시스템을 획득 하라, 그리고 나서 방울과 피리를 첨가해라. 당신이 새로운 버전이 제대로 작업한다는 것에 대한 강한 자신감을 가지고 있다 할지라도 지금 수행하고 있는 버전을 절대 버리지 마라. 소프트웨어에 대해서 우연한 사건 발생에 대한 계획을 가지는 것이 필요하다. Rule #64: Knowledge is often revised by simulations or testing, but computer models have hidden flaws not the least of which is poor input data. Rule #64: 지식은 종종 시뮬레이션이나 테스트에 의해 다시 만들어 진다. 그러나 컴퓨터 모델은 나쁜 입력 자료에 대한 것이 아닌, 숨겨진 결함을 가지고 있다. Rule #65: In olden times, engineers had hands-on experience, technicians understood how the electronics worked and what it was supposed to do, and layout technicians knew too뾟ut today only the computer knows for sure and it's not talking. Rule #65: 옛날엔, 엔지니어들이 실지 훈련 경험을 가졌었고, 기술자들은 어떻게 전자 공학이 작업하고 무엇을 할것인지, 그리고 기술자들이 알고 있었던 구조들을 이해하고 있었다. 그러나 오늘날은 오직 컴퓨터만이 확실히 알고 있고, 이것이 이야기 되어지지 않는다. Senior Management, Program Offices, and Above 경영층과 프로젝트 사무국 Rule #66: Don't assume you know why senior management has done something. If you feel you need to know, ask. You get some amazing answers that will astonish you. Rule #66: 당신은 선임 경영진이 어떤 일을 왜 했는지를 알고 있다고 가정하지 마라. 만약 당신이 알 필요가 있다면 물어봐라. 당신을 깜짝 놀라게 할 만한 놀라운 대답을 들을 것이다. Rule #67: Know your management뾱ome like a good joke, others only like a joke if they tell it. Rule #67: 농담하듯이 다른이에게 당신 경영진에 대해 알게 하라. 만약 다른이들이 이 얘기를 한다면 그들은 오직 농담만을 좋아 한다. Rule #68: Remember the boss has the right to make decisions. Even if you think they are wrong, tell the boss what you think but if he still wants it done his way; do it his way and do your best to make sure the outcome is successful. Rule #68: 보스가 결정권한을 가졌다는 걸 기억하라. 당신이 그들이 잘못됐다고 생각하고 있을 때, 보스에게 당신이 생각하는걸 말하라 그러나 만약 그가 여전히 그 자신의 방법으로 수행하길 원한다면 그의 방식대로 수행하라, 그리고 당신은 출력물이 성공적일 수 있도록 최선을 다하라. Rule #69: Never ask management to make a decision that you can make. Assume you have the authority to make decisions unless you know there is a document that states unequivocally that you can't. Rule #69: 당신이 만들 수 있는 결정은 경영진에게 절대로 요구하지 마라. 당신은 당신이 할 수 없는 걸 헷갈리지 않게 설명 하는 문서가 있다는 걸 알지 않는 한, 당신이 결정을 내릴 권한을 가지고 있다고 가정하라. Rule #70: You and the Program Manager should work as a team. The Program Manager is your advocate at NASA HQ and must be tied into the decision makers and should aid your efforts to be tied in also. Rule #70: 당신과 프로그램 관리자가 한 팀으로 일해야 한다. 프로그램 관리자는 NASA HQ에서 당신의 옹호자이고, 의사결정자에 연관되어 있어야 하고, 또한 당신이 연관 되도록 하기 위한 당신의 노력을 도와 줄 수 있어야 한다. Rule #71: Know who the decision makers on the program are. It may be someone outside who has the ear of Congress or the Administrator, or the Associate Administrator, or one of the scientists뾱omeone in the chain of command뾵hoever they are. Try to get a line of communication to them on a formal or informal basis. Rule #71: 프로그램에 대한 의사결정자가 누구인지 알아라. 아마 위원회 혹은 행정부를 이해 시킬수 있는 외부 누군가 이거나, 협력 관리자, 혹은 과학자들 중의 하나, 혹은 지휘 체인아래 있는 사람, 혹은 그들이 누구든지 그들이 누구인지 알아라. 정식적인 혹은 비정식적인 토대에서 그들에 대한 의사소통의 라인을 얻도록 노력하라. Program Planning, Budgeting, and Estimating 계획수립과 예산, 평가 Rule #72: Today one must push the state of the art, be within budget, take risks, not fail, and be on time. Strangely, all these are consistent as long as the ground rules such as funding profile and schedule are established up front and maintained. Rule #72: 오늘날엔 최신 기술을 밀고 나가야 한다, 예산 한도내에서, 위험을 수반하고, 실패하지 않도록,그리고 제시간에. 묘하게도, 도표와 스케쥴 축적하는 것과 같은 행동 기본 원칙이 먼저 확립되고 유지되는한 모든 이런 사항들은 일치해야 한다. Rule #73: Most of yesteryear's projects overran because of poor estimates and not because of mistakes. Getting better estimates will not lower costs but will improve NASA's business reputation. Actually, there is a high probability that getting better estimates will increase costs and assure a higher profit to industry unless the fee is reduced to reflect lower risk on the part of industry. A better reputation is necessary in the present environment. Rule #73: 대부분 이전 해의 프로젝트들은 실수 때문이 아니라 나쁜 평가 때문에 한도를 넘어섰다. 좀 더 나은 평가물을 획득하는 것은 비용을 낮추지 않지만, NASA의 비즈니스 명성을 개선 시킬 것이다. 실제적으로, 비용이 산업 부분에 낮은 위험을 반영해 줄어들지 않는 한은, 좀더 나은 평가물이 비용을 증가시키고, 높은 산업 이익을 확실히 할 가능성이 높은 것 이다. 좀 더 나은 명성은 현재 산업 환경에서 필요한 것이다. Rule #74: All problems are solvable in time, so make sure you have enough schedule contingency뾦f you don't, the next project manager that takes your place will. Rule #74: 늦지 않게 모든 문제들은 풀릴 수 있다. 그러니 당신은 우발적 사건에 대한 충분한 스케쥴을 갖도록 확실히 하라. 만약 당신이 그러지 않으면, 당신의 자리를 가로챌 다음 프로젝트 관리자가 생길 것이다. Rule #75: The old NASA pushed the limits of technology and science; therefore, it did not worry about requirements creep or overruns. The new NASA has to work as if all projects are fixed price; therefore, requirement creep has become a deadly sin. Rule #75: 예전 NASA 는 기술과 과학의 한계(한도; 제한점)를 추진했다; 그러므로, 요구사항 지연이나 초과에 대해 걱정할 필요가 없었다. 새로운 NASA는 마치 모든 프로젝트들이 고정된 가격을 가지고 있는 것처럼 작업을 해야 한다; 그러므로 요구사항 지연은 치명적인 과실이 되어 왔다. Rule #76: Know the resources of your center and, if possible, other centers. Other centers, if they have the resources , are normally happy to help. It is always surprising how much good help one can get by just asking. Rule #76: 당신 센터의 자원들을 알아라, 그리고 만약 가능하다면, 다른 센터의 자원들도 알아라. 다른 센터에서 만약 그들이 자원을 가지고 있다면 그들은 일반적으로 돕는 것을 좋아 할 것이다. 얼마나 많은 괜찮은 도움들이 그렇게 단지 물어봄으로 인해서 획득될 수 있는지 항상 놀라게 될 것이다. Rule #77: Other than budget information prior to the President's submittal to Congress, there is probably no secret information on a project뾱o don't treat anything like it is secret. Everyone does better if they can see the whole picture so don't hide any of it from anyone. Rule #77: 의회에 사장 제안서 보다 우위의, 예산 정보보다 더한 비밀 정보는 프로젝트에선 아마 없을 것이다. 그러니 어떤 것도 비밀로 다루지 말어라. 모든이는 만약 그들이 전체 그림을 볼 수 있다면 좀더 나은 일을 한다. 그러니 어느 누구한테든 어떤 것도 숨기지마라. Rule #78: NASA programs compete for budget funds뾲hey do not compete with each other (i.e., you never attack any other program or NASA work with the idea that you should get their funding). Sell what you have on its own merit. Rule #78: NASA 프로그램은 예산 기금에 따라 완료된다. 그래서 그들은 다른 사람들과 함께 일을 마치지 않는다( 당신은 결코 다른 프로그램을 공격하지 않는다. 혹은 NASA는 그들의 기금을 얻을 수 있는 당신의 아이디어와 함께 일을 한다). 당신이 가진 것의 장점을 팔아라. Rule #79: Next year is always the year with adequate funding and schedule. Next year arrives on the 50th year of your career. Rule #79: 다음해는 항상 적당한 기금과 스케줄을 가지고 있는 해가 된다. 다음해는 당신 경력의 50번째 해가 되는 때에 온다. The Customer 고객 Rule #80: Remember who the customer is and what his objectives are (i.e., check with him when you go to change anything of significance). Rule #80: 누가 고객인지 그리고 그의 목적이 무엇인지 기억하라( 중요한 어떤 것에 변화를 주고자 할 때 그와 함께 체크하라..) NASA Management Instructions 관리 지침서 Rule #81: NASA Management Instructions were written by another NASA employee like you; therefore, challenge them if they don't make sense. It is possible another NASA employee will rewrite them or waive them for you. Rule #81: NASA 관리 지침은 당신과 같은 다른 NASA고용인에 의해 작성되었다; 그러므로 만약 그들의 말이 일리가 있지 않으면 이의를 제기 하라. 다른 NASA고용인이 그것들을다시 쓰거나 당신한테 그것을 적용하지 않을 가능성이 다분히 있다. Decision Making 의사결정 Rule #82: Wrong decisions made early can be recovered from. Right decisions made late cannot correct them. Rule #82: 초기에 만들어진 잘못된 결정들은 회복 될 수 있다. 후기에 만들어진 옳은 결정은 잘못된 결정들을 고칠 수 없다. Rule #83: Sometimes the best thing to do is nothing. It is also occasionally the best help you can give. Just listening is all that is needed on many occasions. You may be the boss, but if you constantly have to solve someone's problems, you are working for him. Rule #83: 때때로 무언가를 수행하는데 있어 최고의 것은 아무것도 없다. 이것은 이따금 당신이 제공 할 수 있는 최고의 도움이 될 수 있다. 많은 경우에 필요한 것은 단지 듣는 것이 다인 경우가 있다. 당신은 보스가 될 수 도 있다.그러나 만약 당신이 계속 어떤 이의 문제들을 풀어야 한다면, 당신은 그를 위해 일하고 있는 것이다. Rule #84: Never make a decision from a cartoon. Look at the actual hardware or what real information is available such as layouts. Too much time is wasted by people trying to cure a cartoon whose function is to explain the principle. Rule #84: 절대로 밑그림에서 어떤 결정을 만들어 내지 마라. 실제 하드웨어 혹은 구조(layout)와 같은 이용 가능한 실제 정보를 보아라. 원칙을 설명하는 기능을 가지고 있는 밑그림을 교정하려고 노력하는 사람들은 상당히 많은 시간을 낭비한다. Professional Ethics and Integrity 직업윤리 Rule #85: Integrity means your subordinates trust you. Rule #85: 성실이란 말은 당신의 하급자가 당신을 신뢰한다는걸 의미한다. Rule #86: In the rush to get things done, it's always important to remember who you work for. Blindsiding the boss will not be to your benefit in the long run. Rule #86: 일을 급히 마무리 지을 경우, 누가 당신을 위해 일을 하는지를 기억하는 건 항상 중요하다. 보스가 알 수 없게 하는 것은 장기적으로 봤을 때 당신에게 유익을 주지 못한다. Project Management and Teamwork 팀웍 Rule #87: Projects require teamwork to succeed. Remember, most teams have a coach and not a boss, but the coach still has to call some of the plays. Rule #87: 프로젝트는 성공을 위해 팀웍을 요구한다. 기억하라, 대부분의 팀은 코치를 가지고 있지 보스를 가지고 있지는 않는다는 걸, 그러나 코치는 여전히 약간의 움직임을 이끌어 내야 한다. Rule #88: Never assume someone knows something or has done something unless you have asked them; even the obvious is overlooked or ignored on occasion, especially in a high stress activity. Rule #88: 당신이 물어 보지 않는 한, 어떤 이는 어떤 것을 알고 있다거나 혹은 어떤 것을 이미 수행 했다고 절대 가정하지 마라; 분명한 어떤 것을 눈 감아 주거나 무시하고 넘어가는 것 조차도. 특별히 스트레스를 많이 받는 활동에서. Rule #89: Whoever said beggars can't be choosers doesn't understand project management, although many times it is better to trust to luck than to get poor support. Rule #89: 빌어 먹는 놈이 콩밥을 마다할까 라고 말한 누구든지 프로젝트 관리를 이해 못하는 것이다. 비록 나쁜 지원을 획득 하는 것보다 행운을 신뢰하는 것이 나은 경우들이 많을 지언정. Rule #90: A puzzle is hard to discern from just one piece; so don't be surprised if team members deprived of information reach the wrong conclusion. Rule #90: 퍼즐은 단지 하나의 조각으로 그것이 무엇인지 알아내는 것은 어렵다; 그러니 만약 정보를 주지 않았던 팀 멤버가 잘못된 결론에 도달 했다고 해서 놀라지 말아라. Rule #91: Remember, the President, Congress, OMB, NASA HQ, senior center management, and your customers all have jobs to do. All you have to do is keep them all happy. Rule #91: 기억해라, 사장, 의회, OMB, NASA HQ, 선임 센터 경영진, 그리고 당신의 고객들 모두는 해야 할 일이 있다는 걸. 당신이 해야 할 건 결국 모든 이를 행복하게 하는 것이다. Treating and Avoiding Failures 실패의 수용과 회피 Rule #92: In case of a failure: a) Make a timeline of events and include everything that is known. b) Put down known facts. Check every theory against them. c) Don't beat the data until it confesses (i.e., know when to stop trying to force-fit a scenario). d) Do not arrive at a conclusion too fast. Make sure any deviation from normal is explained. Remember the wrong conclusion is prologue to the next failure. e) Know when to stop. Rule #92: 실패의 경우 a) 이벤트의 타임 라인을 만들고 알려진 것 모두를 포함하라 b) 사실들을 기록하라. 그들에 대한 모든 이론들을 체크 하라. c) 드러나기 전까지 자료를 두드리지 말아라(시나리오에 적합하게 맞도록 노력하면서 언제 멈출지를 알아야 한다.). d) 너무 빨리 결론에 도달하지 마라. 정상적인 것으로 부터의 어떤 일탈도 밝혀지지 않도록 확실히 하라. 기억하라, 잘못된 결론은 다음 실패의 전주곡 이라는 걸. e) 언제 멈춰야 할지를 알아라. Rule #93: Things that fail are lessons learned for the future. Occasionally things go right: these are also lessons learned. Try to duplicate that which works. Rule #93: 실패한 일들은 미래를 위해 배워야 할 교훈들이다. 경우에 따라서는 일이 잘 돌아가기도 한다: 이것들 또한 배워야 할 교훈이다. 잘 수행되어진 것들을 또 만들도록 노력하라. Rule #94: Mistakes are all right but failure is not. Failure is just a mistake you can't recover from; therefore, try to create contingency plans and alternate approaches for the items or plans that have high risk. Rule #94: 실수는 다 괜찮다. 그러나 실패는 아니다. 실패는 당신이 회복 시킬 수 없는 실수이다. 그러므로, 높은 위험을 가지고 있는 아이템이나 계획들을 위한 우연 발생(돌발 상황)에 대한 계획을 만들고 대체할 접근법을 만들도록 노력하라. Rule #95: History is prologue. There has not been a project yet that has not had a parts problem despite all the qualification and testing done on parts. Time and being prepared to react are the only safeguards. Rule #95: 과거의 역사는 전주곡이다. 모든 필요 조건이나 테스트가 각 부분별로 마무리되어진 상태임에도 불구하고 부분적 문제점들이 발생하지 않았던 프로젝트는 여지껏 없었다. 시간 그리고 반응할 수 있도록 준비되어져 있는 것이 유일 하게 할 수 있는 안전 보증이다. Rule #96: Experience may be fine but testing is better. Knowing something will work never takes the place of proving that it will. Rule #96: 경험적 지식은 괜찮다. 그러나 테스트가 더 났다. 어떤 것이 행해질 것 이라는 것을 아는 것은 결코 그것이 그렇게 행해질 것 이라는 걸 증명하는 것보다 낫지는 못할 것 이다. Rule #97: Don't be afraid to fail or you will not succeed, but always work at your skill to recover. Part of that skill is knowing who can help. Rule #97: 실패나 성공 못할 것을 두려워 말라. 그러나 회복시키기 위해 항상 당신의 기술을 사용하라. 그 기술이 누가 당신에게 도움을 줄 수 있는지를 알고 있다(알게 한다). Rule #98: One of the advantages of NASA in the early days was the fact that everyone knew that the facts we were absolutely sure of could be wrong. Rule #98: 초창기 NASA의 장점들 중 하나는 우리가 절대적으로 확신 하는 사실들이 잘못될 수도 있다라는 것을, 모든 이들이 알고 있었다는 사실 이었다. Rule #99: Redundancy in hardware can be a fiction. We are adept at building things to be identical so that if one fails, the other will also fail. Make sure all hardware is treated in a build as if it were one of a kind and needed for mission success. Rule #99: 하드웨어에서 중복은 거짓일 수도 있다. 우리는 작업들이 동일하게 형성 되도록 숙달 되어졌다. 그래서 만약 실패하면 다른 것들도 또한 실패한다. 모든 하드웨어가 마치 각각의 것이 그것을 형성하는데 어떤 개별적인 한 종류인 것처럼 다루어 지도록 확실히 하라. 임무 성공을 위해 필요한 것이다. Rule #100: Never make excuses; instead, present plans of actions to be taken. Rule #100: 변명하지 마라; 대신 수행되어져야 할 활동에 대한 계획을 세워라