초기에 처리해야 하는 데이터양이 적었을적에는 제조업처럼 업무를 계획하는게 가능했었던거 같다. 그래서 폭포수모델 같은게 사용이 되었던거고. 업무범위가 좁다보니 이해하기도 쉽고 입출력데이터도 명확하게 정의할 수 있었으니까. 일정산정도 소숫점자리로 딱떨어지게 할 수 있고, 물론 간단한 일의 경우에도 소숫점자리까지 딱떨어지게 일정을 맞추는건 쉬운일은 아니었겠지만 뭐 그럭저럭 예상범위 내에 있었지.

근데, 일이 존나 복잡해 지면서 대단히 경험많은 사람들도 업무를 완전히 이해하고 입출력데이터를 명확하게 정의하는게 불가능해졌지. 20년을 현장에서 굴러먹은 개발자들 조차 폭포수모델을 포기하고 스크럼같은 개발모델을 따르는 이유지.

근데, 업무에 잡음이 존나 많아졌다는걸 이해못하는 사람들이 많다. 정보가 많으면 판단하기가 어려워지는데, 여전히 많은 사람들이 모든 잡음을 컨트롤할 수 있고 그래서 소숫점 단위의 완벽한 일정을 만들어 낼 수 있다라는 착각에 빠져있다. 그냥 어느 선에서 포기하고 반올림을 해야 하는데, 그게 용납이 안되는거야. 이러한 착각하에서 일정을 짜다보니, 애초에 제대로된 일정은 불가능이다. 그걸 경험적으로 아는 개발자들은 꼼수로 "산출된 일정 X 1.5" 하는 식으로 내부일정을 새로 만들게 되는거고. 일정을 역산 하게 된다. 아놔 일정을 역산하다니.. 쩝.

그러니 뭐 결국에는 막판야근을 하게 되는거고.

근데 막판야근 정도는 그럭저럭 양호하다. 웹같은 경우에는 잘못하면 상시야근을 각오해야 한다. 웹에는 얼렁뚱땅 애자일틱한 짧은 주기 확인이라는걸 사람들이 요구하기 때문인데, 문제는 애자일에서의 해당 주기내에 하기로 정의한 기능만을 보여주는 개념이 아니란 거지. 애자일에서는 이러한 단주기 제품출시를 보장하기 위해서, 외부로부터의 개입을 완전차단하는 등의 장치를 가지게 되는데, 이사람들은 그렇지 않지 말이지.

일단 모든 기능을 포함한 풀패키지를 보여주길 원하는 경우가 많기 때문이고 중간중간에 팀밖의 사람드르이 요구에 따라서 스팩이 변경되는 것은 말할 것도 없고. 결국 "야근문화"가 만들어진다.  일단 한번 야근문화에 발을 담그게 되면, 그거 고치기 존나 빡친다.