그 이유는 단 하나입니다.

"부실하고 모호한 시스템 기획"


프로그래머 입장에서 일정은 정해져 있는데 작업 시간이 늘어납니다.
(미흡한 시스템 플로우, 명확하지 않은 정의 등)

그리고, 작업 완료 후 수정 사항이 많아집니다.
(예외 처리 부족, 기획서에서 시스템적인 돌발 상황 캐치 못함 등)

그로 인해 야근을 할 확률이 올라갑니다.
(개발 완료한 시스템을 수정하는데 일정을 팍팍 더 주는 천사같은 회사는 흔치 않음)


결국 프로그래머 입장에서 방어적으로 나올 수 밖에 없습니다.

기획서 리뷰가 끝난 후 개발이 들어가는 순간 일정에 대한 책임은 프로그래머에게 주어지거든요.

그러니 부실하고 모호한 시스템 기획서를 보는 순간 방어적으로 나올 수 밖에 없습니다.


결국 프로그래머의 방어적인 성향은 기획자의 책임입니다.

물론 수준 미달의 시스템 기획자 다수에게 오랫동안 당해와서

자동적으로 방어적인 성향이 나오는 프로그래머들이 없는 것은 아닙니다.

아예 함량 미달의 프로그래머들도 있을 수 있습니다. 하지만 제 경험상 굉장히 소수입니다.

하지만 그런 프로그래머에게도 내 기획서에 대한 신뢰를 줄 수 있어야 좋은 기획자가 되는 것입니다.

좋은 시스템 기획서 = 개발하기 편한 시스템 기획서를 몇 번 주다 보면

어느 순간 기획서 리뷰 후 방어적이지 않은 프로그래머의 모습을 볼 수 있을 것입니다.


프로그래머들이 방어적이라고 탓하기 전에

프로그래머 입장에 서서 본인의 기획서를 한 번 되돌아 보세요.

그럼 답이 나올 것입니다.