소프트웨어는 손쉽게 수정할 수 있다고 생각하기 쉽습니다.
특히 고객이나 개발을 잘 이해하지 못하는 Sales part에서는 소프트웨어가 대단히 Soft해서 쉽게 주물떡 주물떡 해서 변경이 가능할 것으로 생각합니다.
하지만 무엇이 언제 수정되냐에 따라서 소프트웨어는 절대로 소프트하지 않습니다.
프로젝트 막바지에 요구사항이 변경되면 요구사항 분석 시 반영된 것에 비하여 수십배의 비용을 지불해야 합니다.
소프트웨어가 소프트하다고 생각하는 것은 비단 고객이나 Sales만이 아닙니다.
개발자들도 그런 생각을 하는 것을 종종 볼 수 있습니다.
개발자들은 자신이 뚝딱뚝딱 만들어 보고는 수정이 쉽다고 생각할 수 있습니다.
하지만 이는 간단한 프로토타입에 불과하고 실제 프로젝트나 제품을 만들 때는 사정이 달라집니다.
요구사항이 바뀌면 아키텍처가 바뀌어서 전체를 다 뜯어 고쳐야 할 수도 있습니다.
빌딩을 지을 때는 뼈대를 다 올리고 나서 이거 저거 뜯어 고쳐달라고 하지를 않습니다. 하지만 소프트웨어를 개발할 때는 다 개발해 놓고도, 부담없이 고쳐달라고 하는 경우가 비일비재합니다.
SW분리발주법이 이러한 부작용을 줄여 줄 수 있는 좋은 제도이나 아직 형식적인 가이드에만 그치고 있고 기업들은 얼마든지 이를 피해갈 준비가 되어 있습니다. 이렇게 후진적인 마인드가 결국 소프트웨어 업계를 공멸하게 만들어가고 있는데, 이 기형적인 소프트웨어 산업 구조는 쉽게 바뀌기가 어려운 상황입니다.
소프트웨어가 소프트하지 않다는 것을 우리 모두 인식할 때 조금씩 희망이 보이지 않을까요?
SI만 했던 개발자들은 SM의 중요성을 잘 모르더군요.
답글삭제SI땐 금방 뜯어 고칠 수 있지만 SM 할땐 뭐 하나 수정할려면 쉽지 않죠.
제대로 돌아 가고 있는걸 수정하기란 여간 꼼꼼해서 되지 않습니다. ^^;
묘재님 안녕하세요.
답글삭제SM은 Legacy System을 잘 이해하고 있어야 하니 더욱 수정이 어렵죠. 게다가 담당자가 여러번 바뀌고 문서도 충분하지 않으면 곤란한 상황이죠. 팩키지 소프트웨어나 대부분의 소프트웨어는 뒤늦은 스펙변경은 대단히 비싼 비용을 치뤄야 합니다.
사진이 멋지네요 ^^
답글삭제좋은 지적입니다. 가장 큰 문제는 그 요구사항 변경에 따른 비용을 단지 "개발자가 좀 고생하면 된다"라고 인식하는데 있는 것 같습니다. 그리고 수정이 잘 되지 않으면 "능력없는 개발자 탓"이 되는게 현실인것 같습니다.
답글삭제ks님 안녕하세요. 반갑습니다.
답글삭제사진은 그냥 골라본 겁니다. :)
Jake님 안녕하세요.
답글삭제바로 그런 비전문적인, S/W개발에 대해서 이해하지 못하는 고객이 문제죠. 개발자는 이들을 이해시키는 역할도 해야 하지만, 고객도 요구사항에 대한 의무가 있는데, 이를 잘 모르는 것이 일반적입니다. 요구사항을 잘 분석해서 줘도 고객은 잘 읽어보지도 않는 것이 흔하죠. 읽는 방법도 잘 모르기도 합니다.
제 생각에는 고객은 충분히 그럴 수가 있다고 봅니다. 어차피 고객들은 비용을 지불하고 구매하는 사용자에 불과하니까요. 문제는 그러한 무리한 요구사항을 무리하다는 것을 알면서도 무조건 맞춰주는 개발회사가 더 문제라고 봅니다. 어떻게든 매출은 올려야겠으니 개발자만 좀 고생시켜 요구사항 맞춰주면 된다는 생각을 바꿔야 하지 않을까 싶습니다. 한 회사가 안된다고 했을 때 다른 회사가 된다는 회사가 있으면 고객은 당연히 된다는 회사와 거래를 하겠죠. 문제는 고객에게 변경이 어렵다는 것을 인식시키기 보다는 변경에 따른 비용을 인식시키는 것이 중요할 것 같습니다. 사실 소프트웨어가 하드웨어보다 변경이 쉽죠. 그래서 소프트웨어라고 불리는 것이구요. 그 비용인식은 소프트웨어 업계만의 문제가 아닌 사회 전반적인 문제가 아닌가도 생각합니다.
답글삭제Jake님 안녕하세요. 새해 복 많이 받으세요.
답글삭제그렇습니다. 현재의 현상은 시장의 원리에 의해서 형성된 것이지요. 그렇게 시장에만 맡겨 놓으면 문제이니 S/W관련된 법도 자꾸 만들어내고 있지만 또 피해가는 방법들을 만들어내지요.
제대로 하려면 요구사항을 Fix하고 ATP(Acceptance Test Plan)을 만들어서 계약시 포함을 시켜야지요. 그리고 요구사항이 바뀌면 원칙적으로 계약이 변경되는 것이지요. 그렇게 하면 갑도 전문적이어야 하고 계약시 신경도 많이 써야 하거든요. 하지만 우리나라에는 언제든지 마음대로 할 수 있는 개발사가 많으니 그렇게 노력을 하려고 하지 않죠.
소프트웨어가 확실히 Soft하죠. 하지만 너무 Soft하게 생각하는 것이 문제입니다. 이런 불합리한 인식을 모두 바꾸는 것은 단시간에 불가능하겠죠. 결국 제도적으로 문화적으로 조금씩 바꿔나가야 할 것 같습니다.
"소프트웨어는 소프트하지 않다"를 읽고 씁니다. 1. 소프트웨어 변경 비용 모델들 소프트웨어의 기능을 변경하고자 할 때 비용이 적게 들면 이를 두고 "소프트"하다고 표현합니다. 전통적으로는 프로젝트가 시작되고 시간이 흐를수록 변경 비용이 기하급수적으로 증가한다고 말합니다. 즉, 프로젝트 초창기에는 소프트하지만 시간이 지날수록 점점 소프트하지 않게 된다는 얘기입니다. 그림으로는 보통 이렇게 그립니다: [그림1. 전통적 모델] Y축이 비용(Cost),..
답글삭제개발자 입장에서는 이런 생각을 가진 고객을 만나면 정말 괴롭죠. 하지만 그런 고객이 생각보다 많다는 점이 문제이기도 하죠. 고객과 개발자 모두의 인식변화도 중요하지만 보다 더 현실적인 제도적 뒷받침도 강화되야 할 듯 합니다.
답글삭제필넷님 안녕하세요.
답글삭제여전히 어려운 문제죠. 법을 만들어도 피해가는 일이 허다하니... 그래도 분석능력이 뛰어난 개발사는 열악한 고객이라고 하더라고 그 안에서 최대한 효과적으로 분석을 해내곤 하지요. 무조건 고개 탓만 할 수는 없을 것 같습니다. 고객은 다 그러니까요. 분석역량을 키우는 일이 우리가 해야 할 일인 것 같습니다.
블로그에서 재미있는 글을 하나 읽었습니다. Ray라는 닉네임을 쓰며 최근에 흥미있는 포스트를 자주 올리는 블로거의 글입니다. ‘소프트웨어는 소프트하지 않다’라는 제목의 이 글에는 고객이나 세일즈 파트너(개발자를 잘 이해하지 못하는)들이 소프트웨어가 너무 소프트하다고 생각하고 있다는 말로 시작합니다. 그들은 소프트웨어는 아주 소프트해서 언제든지 주물럭(?)거릴 수 있다고 생각하고 있지만 사실 소프트웨어는 주물럭거리는 시점에 따라 소프트할 수도 있고 그..
답글삭제