팀을 운영하고 제품을 만들다 보면, 

제일 먼저 나오는 질문이 있어요.

"그래서 이거 언제까지 돼요?"

"이번 주 안에 가능해요?"

"다음 배포 때 넣을 수 있나요?"

일정은 중요합니다.

팀이 같은 약속을 바라보고 움직이려면, 언제까지 무엇을 할지 정해야 하니까요.

그런데 일정이 중요하다는 이유로 일정 자체가 목표가 되기 시작하면, 조금 다른 문제가 생깁니다.

프로젝트가 끝난 뒤 가장 먼저 확인하는 것이 '일정을 지켰는가'가 됩니다.

일정 안에 끝냈다면 잘한 일이고, 늦어졌다면 문제가 있는 일로 평가하죠.

정작 그 일정이 끝난 뒤 무엇이 달라졌는지는 나중으로 밀려납니다.

사용자가 더 편해졌는지, 제품이 실제로 더 나아졌는지, 

팀의 운영 비용이 줄었는지보다 약속한 날짜를 지켰는지가 더 중요해지는 거죠.

일정은 원래 계획입니다. 목표가 아닙니다.

특히 프로젝트 초기에 정한 일정은 현실을 완벽하게 반영하기는 어렵습니다.

기술적으로 예상하지 못한 문제가 생길 수도 있고, 고객의 요구사항이 달라질 수도 있고,

 외부 환경이 바뀔 수도 있죠.

그런데도 처음 정한 일정을 확정된 약속처럼 다루면 팀은 다른 선택을 하게 됩니다.

테스트를 줄이고, 설계를 뒤로 미루고, 기술 부채를 쌓고, 당장 눈앞의 문제만 덮는 방식입니다.

이렇게 하면 일정은 지킬 수 있습니다.

하지만 팀의 진짜 성과를 의미하지는 않습니다.

일정 안에 기능을 배포했지만 아무도 사용하지 않을 수 있습니다.

기능은 작동하지만 유지보수 비용만 커질 수도 있고, 

출시 이후 문제가 반복되어 팀이 계속 같은 일을 처리하게 될 수도 있죠.

이런 결과를 두고

“일정을 지켰으니 잘했다.” 고 말하긴 어려울 겁니다.

문제는 팀이 열심히 하지 않는 것이 아닙니다.

오히려 모두가 열심히 움직였기 때문에 더 늦게 발견됩니다.

팀의 판단 기준이 일정에 맞춰져 있기 때문입니다.

일정을 목표로 삼는 순간, 팀은 자연스럽게 생각합니다.

"왜 이 일을 하는가?"보다

"어떻게든 맞출 수 있는가?"를 먼저 보게 되죠.

"사용자에게 어떤 변화가 생기는가?"보다

"이번 스프린트 안에 끝낼 수 있을까?"를 먼저 보게 됩니다.

이런 선택이 반복되면 팀은 점점 방어적으로 움직입니다.

문제가 생겨도 공유하기보다 숨기고,

목표를 다시 확인하기보다 일정을 맞추는 것에 집중합니다.

결국 바쁘게 움직여도, 팀이 어디로 가고 있는지 설명하기 어려워집니다.

정리하면

일정이 흔들릴 때는 일정만 바라보면 안 됩니다.

이 일정이 끝났을 때 사용자와 제품은 무엇이 달라지는가?

그 변화가 실제로 일어났는지 무엇으로 확인할 수 있을까?

일정이 늦어진다면 무엇을 줄이고, 무엇을 끝까지 지켜야 할까?

기능을 만들었다는 사실만으로는 부족합니다.

품질, 사용성, 성능, 고객의 반응처럼 결과를 확인할 수 있는 기준이 필요합니다.

일정은 바뀔 수 있습니다.

하지만 목표는 쉽게 바뀌지 않아야 합니다.

목표가 바뀐다면 왜 바뀌었는지 설명할 수 있어야 하고요.

일정은 목표를 향해 가기 위한 계획입니다.

계획이 현실과 맞지 않으면 바꿀 수 있어야 합니다.

반대로 목표가 분명하면, 일정이 흔들리는 순간에도 무엇을 포기하고 무엇을 지킬지 판단할 수 있습니다.

좋은 팀은 항상 일정을 지키는 팀이 아니라,

일정이 바뀌어도 중요한 것을 놓치지 않는 팀이라고 생각합니다.