2020년 2월 16일 일요일

[Software Spec Series 6] 스펙과 프로젝트의 성공

스펙을 부실하게 작성하고 진행하는 프로젝트는 수없이 많다. 하지만 그 중에서 성공을 하는 프로젝트도 있다. 그래서 스펙을 제대로 작성했다고 착각을 하기도 하고 반대로 스펙을 제대로 작성해야 하다는 것을 믿지 않기도 한다. 이럴 때는 프로젝트가 10배로 커지고 개발자가 10배 투입되면 어떤 일이 벌어질지 상상을 해보면 된다.

많은 프로젝트들이 첫번째 버전을 성공했다가 이를 업그레이드하는 두번째 프로젝트에서 실패를 한다. 이를 “두번째 버전 신드롬”이라고 부른다. 첫번째 버전은 규모도 작고 적은 인원으로 진행을 해서 성공 확률이 높았지만 첫번째 제품의 성공을 기반으로 두번째 버전을 만들 때는 프로젝트의 규모가 커지면서 실패 확률이 확 높아진 것이다. 부실한 스펙 하에서 개집 만들기에 성공해 놓고 스스로 마천루를 개발할 수 있다고 착각하면 안된다.

스펙과 프로젝트 성공 확률의 상관관계를 아래 그래프로 살펴보자. 감을 잡기 위해서 개념을 설명하는 것이다. 숫자적인 의미를 부여하려는 것이 아니다. 프로젝트 성공과 관련된 수많은 요소가 있지만 그 중에서 스펙과의 관계만 살펴보자.


(프로젝트 규모와 프로젝트 성공확률과의 성관관계)


스펙을 부실하게 작성하면 프로젝트의 규모가 커지면서 프로젝트 성공 확률이 확 떨어지지만 스펙을 잘 작성하면 프로젝트의 규모가 커져도 프로젝트 성공 확률이 급격히 줄어들지 않는다.

share with abctech.software

2020년 2월 2일 일요일

[Software Spec Series 5] 스펙을 제대로 작성하지 않으면

소프트웨어를 개발하는데 있어서 꼭 알아야 할 규칙이 하나 있다. 바로 “1:10:100 rule"이다. 성숙한 개발 문화를 가지고 있는 회사는 전 직원들이 진정으로 그 의미를 알고 있고 실행하고 있다. 하지만 우리나라의 크고 작은 많은 소프트웨어 회사 임직원들은 그 의미를 모르거나 알고 있어도 단어의 의미로만 알고 있고 진정으로 깨우치고 있지는 못하다. 소프트웨어를 개발하면서 발생하는 많은 비효율과 문제들이 바로 여기서 출발하는 것이다.

그 1:10:100 rule을 설명한 그래프가 아래에 있다.

(스펙 1:10:100 규칙 그래프)

스펙을 작성할 때 요구사항을 바꾸면 “1"이라는 비용이 들지만 고객에게 전달된 다음에 바뀌면 수백배의 비용이 들어간다. 요구사항이든 설계든 한단계 뒤에서 고치게 될 경우 2~5배의 비용이 들어가서 단계를 거치고 시간이 흐를수록 수정 비용은 기하급수로 증가를 한다. 따라서 기획이 제대로 되어야 하고 분석 설계가 적절하게 잘되어야 한다. 한창 개발 중에 기획이 바뀌거나 요구사항이 바뀌면 그 수정 비용은 엄청나다는 것을 알아야 한다.

개발자들은 기획에서 정확한 요구사항을 주지 않는다거나 나중에 요구사항을 바꾼다고 불평이 많다. 불평은 하지만 그것을 현실로 받아들이고 스스로 이를 개선하려는 노력은 별로 하지 않는다. 오히려 상황이 그러니 분석, 설계를 제대로 하지 않고 대충 개발하다가 나중에 바꿔달라고 하면 또 대충 받아들여서 바꿔주고 이런 악순환을 반복하곤 한다.

기능에 따라서는 나중에 고쳐도 비용이 크지 않은 것도 있지만, 비용이 수백배 들어가는 것도 있다. 특히 아키텍처에 관련된 것이나, 비기능적인 요소는 나중에 수정할 경우 상상할 수 없는 비용이 들어간다.

이런 것을 극복하기 위해서 여러 방법론이 나오기도 하고 한때 Agile이 각광을 받았지만, 이런 방법론이나 기법으로는 이를 해결할 수는 없다. 정공법 외에는 방법이 없다. 기획을 제대로 하고 분석 설계를 효율적이고 적절하게 하면 된다. 또한 그 과정에서 모든 이해관계자가 책임을 지고 검토를 해서 문제가 없게 해야 하면 나중에 딴소리를 하거나 바꿔달라고 하면 안된다. 정말 중요한 변경 요청이 아니면 다음 버전으로 미루는 것이 좋은 전략이다.

share with abctech.software