https://www.youtube.com/watch?v=t705r8ICkRw&t=831s
1. Make the requirements less dumb. Requirements are always dumb and lacking. It is especially dangerous if a smart person made the requirements, as they might not be questioned enough. Everyone is wrong some of the time. All requirements and constraint must be linked to a person who takes responsibility for the requirement (not a department). You must always be able to track down the author and someone who will defend it.
-> 1단계: 요구사항을 덜 멍청하게 만들어라. 특히 똑똑한 사람들이 만든 요구사항이라면, 충분히 질문받지 못했기에 더 위험하다. 모든 사람은 때때로 틀린다. 모든 요구사항과 제약은 요구사항을 책임지는 (한 부서가 아니라) 한 사람에게 연결되어야 한다. 항상 작성자를 추적할 수 있어야 하고, 왜 그렇게 작성했는지 방어할 수 있는 사람을 찾아야 한다.
2. Try very hard to delete the part or process. If you are not occasionally adding things back in you are not deleting enough. There is a strong bias towards "let's add this in case we need it", but you can make just in case arguments for so many things. When doing something difficult you need to run tight margins. Because if you don't run tight margins you won't have a chance of achieving your goals. You can't hedge your bets
-> 2단계: 일부 혹은 프로세스를 지우도록 열심히 시도하라. 가끔 무언가를 다시 추가하는 일이 일어나지 않는다면, 당신은 충분히 지우고 있지 않은 것이다. "필요할 때를 대비해 추가해보자" 라는 강한 성향이 있지만, '만일'이라는 이유로 너무 많은 것들을 추가할 수 있다. 어려운 일을 할 때는 아슬아슬하게 진행하게 될것이다. 아슬아슬하게 진행하지 않는다면, 목표를 달성할 기회가 없을 것이기 때문이다. 양쪽 모두에 배팅할 수는 없다.
3. Simplify or optimize
-> 3단계: 간소화하고 최적화하라. 그러나 반드시 3단계여야 한다. 가끔 똑똑한 엔지니어들은 존재않는 것이 나은것을 최적화한다.
4. Accelerate cycle time. You are moving too slowly. Move faster. Don't work on going faster before you have worked on the previous 3 steps.
-> 4단계: 사이클을 빠르게 돌려라. 더 빠르게 움직여라. 그러나 앞의 3단계를 진행하기 전에는 더 빠르게 진행하지 마라.
5. Automate. This is the final step for a reason.
-> 5단계: 자동화하라. 이것이 마지막 단계인데는 이유가 있다.
설계
일론머스크의 설계 5단계 법칙
반응형