갑은 항상 고민한다. 특히 어디에서나 하는 고민은 개발업체 휘둘리지 않기위해서 머리를 쥐어짠다
이것은 작은 기업이든, 대기업이든, 정부기관이든 모두하는 고민이다. 개발업체가 마음에 들지 않지만 바꾸지 못하는 곳도 수시로 만날수 있다.
그이유는 간단하다. 개발은 한순간에 끝나지만 개발했던 업체가 나가고 나면 유지보수를 하지 못하기 때문이다. 특히 유지보수 조차 업체에게 맡긴다면 그것은 헤어나올수 없는 덫에 빠져버린다.
더욱 웃기는 것은 경영자의 입장에서 보면 도저히 이해하지 못하고 전산관리자는 능력없는 사람으로 바로 전락하게 된다.
참.. 웃기는 노릇이 아닐까 한다.
전산담당자는 개발이 시작되면 요구사항을 이야기하는 사람들의 대표자 격으로 이야기하며 설계단계가 들어가면 설계, 개발단계에서는 행정지원이나 한고 있다. 행정지원이 노는 일만은 아니기에 나름대로 엄청 바쁘게 보낸다.
이 시기에는 대충 이런일들을 한다. 주간회의개최, 기능별로 개발이 잘되고 있는지 공정체크, 테스트 등이다.
좀더 부연설명
주간회의 : 꼭 주간회의는 아니지만 주기적으로 지휘계통의 윗사람과 회의를 통해서 안심을 시킨다. 권위적인 조직일수록 여기에 대한 일은 더욱더 늘어난다.
공정체크 및 테스트 : WBS, 프로젝트일정 등을 통해 개발이 잘되고 있는지 블랙박스 테스트 아니 사용자 테스트수준으로 시행한다. 그러면 좀 안되보이면 개발자를 더 투입하라는 등, 밤새워서 하라는 등 이야기를 하고 자신이 뭔가 엄청난 실력이 있는냥? 기세등등해 한다. (여기에 대한 부분은 나중에 좀더 이야기 하기로 하자)
테스트는 감리업체, 전문 평가업체를 통해서 한다. 물론 여기에도 전산담당자는 계약, 일정조율 등 많은 일을 수행한다.
갑의 기업의 전산담당자는 너무 바쁘다. 시간이 부족하여 매일 야근을 한다. 하지만 개발기간은 금방 지나가고 유지보수라는 늪의 시기가 들어선다.
유지보수 기간에는 갑이 을이 되고 개발업체가 갑이 된다. 신규기능을 개발이라고 할 양이면 전산담당자는 개발업체에 인간적으로 호소를 한다. "다음에 너희가 또 개발을 담당할거야.. (회유), 이건 너희가 당연히 해줘야 되는거야?(협박)" 등 방법은 가지가지 이다. 직접 유지보수를 하기에는 너무 힘들고 개발능력이 있는 전산담당자로 프로그램을 왜 이렇게 만들었는지? 몰라 많은 시간을 투자한다.
유지보수를 업체에 넘겨도 늪의 시간은 당연히 찾아온다. 왜 그 업체랑 계속 계약을 해야하나? 다른 업체로 바뀌기라도 하는 양이면 인수인계는 어떻게 해야하는지? 에 대한 고민은 쏟아져 내린다.
내가 아는 어떤곳은 회사가 3번이나 바뀌었는데로 개발자는 회사를 갈아타며 계속 동일한 사람이 하는 경우 보았다.
그럼 이제 본론으로 들어가서 유지보수의 덫에 벗어나기 위해서는 어떻게 해야 할까? (서론이 너무 길었다..)
1. ALM 을 제대로 구축하고 제대로 이용하자
이것저것 다 구축하기 함들면 소스관리, 이슈관리 2개만은 확실히 구축하자. 더욱더 중요한것은 이것 사용해서 받드시 개발을 하도록 하자. 저번 글에 이슈관리시스템을 이용해서 어느정도 규모 개발도 하는것을 말한적이 있지만 아주 효율적이다. 너무 큰규모는 힘들겠지만 작은 규모는 매우 효과적이다.
2. SRS를 제대로 작성하자
SRS는 최근 되어야서 좀 적용하는 모습이 보이고 있지만 예전에는 그냥 요구사항 분석서라는 이름으로 대층 넘겨버리는 경우가 많았다. 자세한 사항은 IEEE 문서를 참고하시고 실정에 맞춰보시기를 부탁한다. 한국실정과는 좀 안맞고 여러 샘플을 보고 의미를 찾는데 참고했으면 한다. (나는 아직도 어렵다)
3. 중요부분, 특이한 부분은 반드시 문서를 통해 상세화 하라.
일반적은 그냥 넘어가더라도 특정부분은 반드시 문서를 통해서 상세화 하여야 한다. UML, 상세설계, 코드분석서 갖가지 이름을 가지는 문서를 통해서 반드시 문서화 해라. 차후에 인수인계에도 유용하게 쓰일것이다.
4. 마지막으로 일일빌드와 코드리뷰를 통해 관리하자
어려운 일이다. 전산관리자가 직접 코드를 보는것은 결코 쉬운일이 아니다. 하지만 올라오는 파일명이라도 볼수 있도록 하자.
특히 일일빌드는 추천하지 말라는 사람도 많다. 하지만 전산담당자가 빌드를 하는 작업에 참여하라고 권하고 싶다. 이것은 개발을 하라는 것은 아니다. 그냥 이런작업을 참여하면 자연스럽게 문제가 되는부분, 중요부분을 알수 있게 된다. 그리고 임의로 개발되는 부분이 없어지게 된다.
많은 이야기를 하고 싶지만 실력도 부족하고 글솜씨도 부족해서 이렇게 마치고 다음에 좀더 적어보겠습니다.
최근 덧글