많은 회사에서 경영자, 개발자들이 소프웨어를 좀더 효과적으로 개발하기 위해서 다양한 시도를 한다.
문서를 작성하고 소스코드를 관리하고 이슈를 관리하고 프로젝트 관리 기법을 도입한다. 이런 외형적인 시도를 해도 생각은 쉽게 바뀌지 않는다. 특히 경영자들의 마인드가 잘 바뀌지 않는다. 소프트웨어 개발을 제대로 이해하지 못했기 때문이다.
실리콘 밸리와 우리나라에서 소프트웨어를 개발할 때 가장 큰 차이를 보이는 것이 있다.
스펙을 바꾸는 것이 얼마나 큰 일인지에 대한 생각이다. 실리콘밸리에서는 스펙을 바꾸는 일이 개발팀에 엄청나게 큰 부담을 주고 일정과 비용이 영향을 주는지 경영진을 비롯한 모든 직원들이 알고 있기 때문에 스펙을 쉽게 바꾸려고 하지 않는다. 그렇기 때문에 스펙을 작성할 때 철저히 리뷰를 한다. 리뷰를 소홀히 하다가 나중에 빠진 거나 잘못된 것을 바꾸기가 쉽지 않기 때문이다. 그래서 스펙이 제대로 적히고 잘 검토가 되고 프로젝트에서 매우 중요한 역할을 한다.
그런데 우리나라에서는 스펙을 바꾸는 것이 얼마나 큰일인지 잘 인식하지 못한다. 경영자뿐만 아니라 개발자도 그런 경우가 많다. 어차피 주먹구구식으로 개발하기 때문에 스펙 변경을 대수롭지 않게 생각하거나 자포자기식 개발자도 많다. 그래서 스펙을 작성하기 않기도 하거나 대충 작성하다 마는 경우가 많다.
교육을 하고 설득을 하고 귀가 아프도록 얘기를 해도 피부로 느끼기 전에는 생각이 잘 바뀌지 않는다. 이는 방법론에 따라서 다른 얘기는 아니다. 이미 스펙이 결정된 후에는 어떠한 방법론에서도 스펙 변경은 큰 일이다.
물론 스펙 변경이 불가능한 것이 아니다. 비용 증가를 감수하고도 변경해야 할 이유가 있으면 합리적이고 적절한 절치를 통해서 변경해야 한다.
보통의 경영진은 프로젝트 진행 도중에 이런 저런 요구를 하고 싶게 마련이다. 프로젝트에 관여해서 영향력을 행사하고 싶은 욕구가 있는 경우도 있다. 이럴 때 요구사항을 잘 받아주는 개발자가 우리나라에서는 더 높은 평가를 받곤하지만 회사 전체적으로는 손해가 되는 일이다. 정말 급한 요구사항이 아니라면 다음 버전으로 미루면 되는 일이다.
소프트웨어 개발에서 스펙을 함부로 바꾸면 안된다는 것만 깨달으면 소프트웨어 공학의 80%는 터득한 것이다. 거의 대부분의 다른 문화는 다 여기서 파생된다. 안타까운 것은 외워서 되는 것이 아니라는 것이다.
image by sirwiseowl
