계획은 변경하기 위해 존재한다.

계획은 변경하기 위해 존재한다.

어떤 일을 시작하기 전에 항상 계획을 하는 것이 일반적이다.
하지만 아무리 완벽한 계획도 항상 바뀌기 마련이다.
완벽한 계획이 없다면 완벽한 실행도 없다.(?)
그렇다고 해서 계획이 전혀 무의미 하다는 것은 아니다.

계획을 할때는 최대한 많은 변수와 상황을 가정해 최대한 실현 가능하도록 만들어야 한다.
그러나 더 중요한 것은 계획은 바뀔수 있으며 또 그렇게 되어야 한다는 점이다.
관리자는 계획 변경을 극히 싫어한다.
위로 올라가면 올라갈 수록 변경은 나쁜것이 된다.

하지만 실무자의 입장에서 보면 주어진 상황은 언제나 바뀌기 마련이다.
미처 생각하지 못한 변수들이 발생할 수 있으며, 모든 변수의 조합을 계획에 녹여 넣는것도 현실적으로 불가능 하다.
하물며 소프트웨어 개발은 어떠한가? 조건문 하나만 추가해도 실행이 나누어진다.
두개가 추가되면 실행 경로는 2의 배수가 될 수 있다.
코드가 길어지면 그만큼 더 많은 변수들이 작용한다. 버그도 일상적으로 마주치는 결과물일 뿐이다.
계획은 그런 모든 상황을 포함하려고 노력해야 하지만 계획 그 자체로 결과를 보증하는 것은 결코 아니다.

하루가 정말 길게 느껴지는 날은 뭔가를 한 날이다.
어김없이 예외 상황은 발생하고 새로운 해결방안을 찾아 시간이 어떻게 지나가는 지도 모른채 저녁이 찾아온다.
퇴근해야겠다는 생각보다 해답을 찾고자 하는 마음이 앞서고 위장의 빈틈을 탄산으로 때운다.
그런것은 계획한 것이 아니다.
하고 싶어 하는 것이지 누군가의 강요로 하는 것은 결코 아니다.
계획은 필요하지만 계획대로 살지는 않는다.

우린 계획을 변경의 기준점으로 생각해야 한다.
실행 가능한 계획은 계획일 수 없으며 실행하면 계획이 바뀐다.
현실적인 계획은 매일매일 실행하면서 변경되기 마련이다.
변경을 최소화 하는 방법은 변경 자체보다 결과물의 품질이 되어야 한다.

품질을 계획에 맞추는 것은 어리석은 생각이며 품질을 유지할 수 있는 계획을 세우는 일을 먼저 해야한다.
우린 품질이 나쁘더라도 납기를 해야 하는 생명의 위협에 시달릴때도 있지만 그래도 품질이 계획에 앞서야 한다.

다만 소위 말하는 ‘합의’가 필요하면 그때 필요한 것은 기능 구현의 유무가 되어야 한다.
계획은 품질 자체가 아니며 품질이 계획을 지배할 수 있을 때 제대로 된 개발을 할 수 있다.

• 실행하고 계획도 그에 맞추어 변경해라.
• 품질 수준을 정하고 그에 맞는 계획을 설정하자.

운영 환경의 품질은 그에 맞는 체크 리스트를 만들어서 대비하면 된다.