개발자에게 일정 관리는 언제나 쉽지 않은 과제입니다. 여유로운 일정은 그저 꿈같은 이야기일 뿐, 현실에서는 찾아보기 힘듭니다. 기획자로부터 "이 기능도 추가해서 기한 내에 만들어주세요"라는 요청을 자주 받지만, 이미 여러 작업으로 바쁜 개발자로서는 "그건 불가능합니다"라고 대답할 수밖에 없습니다. 그러면 돌아오는 답변은 늘 "무조건 되어야 해요"뿐입니다. 이러한 상황들이 야근을 일상화시키고, 개발자들의 스트레스를 가중시킵니다. 무리한 일정 때문에 버그는 끊이지 않고, 개발자는 점점 지쳐만 갑니다.
하지만 이 문제를 기획자의 탓으로만 돌릴 수는 없습니다. 기획자 역시 윗사람의 지시를 따를 뿐이며, 개발자와 기획자 모두 상황의 피해자라고 볼 수 있습니다. 그러니 서로 감정적으로 대립할 일은 아닙니다. 오히려 기획자와 힘을 합쳐 지혜로운 해결책을 모색하는 것이 더 생산적일 것입니다. 이 악순환의 고리를 끊기 위해서는 일정을 현명하게 분배하는 것이 관건입니다.
꼭 필요한 기능은 아니지만 개발 시간이 오래 걸리는 것들이 있습니다. 이런 기능들을 2차 스펙으로 분리하여 별도의 일정을 잡는 것이 좋습니다. 핵심적인 1차 스펙을 먼저 개발한 뒤, 2차 스펙을 다루는 식으로 일정을 나누는 것입니다. 경험상 이러한 2차 스펙들은 대부분 사라지곤 합니다. 막상 서비스를 오픈하고 나면, 그런 기능들이 활용되지 않거나 큰 의미가 없어지는 경우가 많기 때문입니다. "이 기능을 만드는 데 시간이 오래 걸리지만, 대신 이런 기능은 빠르게 개발할 수 있습니다."라고 제안하는 것입니다. 즉, 우선순위가 낮은 기능을 제외하는 대신, 더 가치 있는 기능을 포함시키자는 것입니다.
빡빡하게 잡은 한 달 일정인데도 계속해서 추가 스펙이 요구되는 상황이 발생할 때가 있습니다. 기존 일정에 새로운 작업들이 계속 끼어드는 상황인 셈입니다. 이럴 때는 스트레스를 받고 논쟁하고 싶은 마음이 들지만, 그게 현명한 대응은 아닙니다. 대신 어떤 부분을 2차 스펙으로 미룰 수 있을지 기획자와 함께 고민해 보는 것이 더 나은 방법입니다. 물론 이러한 협상이 항상 쉬운 것은 아닙니다. 하지만 우리는 개발자로서 현실적인 목소리를 내야 합니다. 무리한 일정은 결국 품질 저하와 더 많은 지연으로 이어질 뿐이기 때문입니다.
훌륭한 개발자라면 코딩 실력만큼이나 의사소통 능력도 갖춰야 합니다. 의사소통을 위해서는 기획에서 원하는 것이 무엇인지 정확히 이해하고, 현재 프로젝트에서 무엇이 더 가능한지를 아는 것이 핵심입니다. 지금 당장 하는 일도 벅차더라도 더 많은 상황을 파악해야 합니다. 내가 더 알아야 내가 편한 방향으로 일을 조율하는 것이 가능하기 때문입니다.
