사내 프로젝트를 진행하면서 이전에는 가장 어렵고 오래 걸리던 작업이 오픈 후 버그를 수정하는 작업이었습니다.

이 문제가 발생하는 이유는 개발을 진행하며 테스트를 등한시 했기 때문입니다.

이에 원론적인 문제는 프로젝트 개발 일정을 말도 안되게 짧게 잡아놓고 작업하다 보니 개발하기 바빠서 테스트를 제대로 진행하지 못했기 때문에 발생합니다.

그냥 겨우겨우 일정에 맞추어 개발을 하고 시스템을 오픈하면 여러분은 잃을 것이 엄청 많습니다.

 

1. 유저들의 신뢰를 잃어 버립니다. ( 에러가 많은 프로그램을 사용해보고 좋아할 리 없겠지요? )

2. 당연히 경영진에서 바라보는 전산실의 신뢰도 잃어버리게 됩니다.

3. 버그 수정으로 인해 많은 공수가 들어가고 다음 프로젝트에도 영향을 주어 악순환이 반복됩니다.

4. 전산담당자도 자신감을 잃어버리고 일에 대한 흥미도 잃어버리게 됩니다. ( 이제 제일 크죠 )

 

제가 생각나는거 크게 이 4가지이고 더 많은 있죠.

이 일에 시작은 말도 안 되는 스케줄 관리에 있고 이로 인한 테스트의 부재에 있습니다.

프로젝트 스케쥴스케줄 검토 시에는 리스크에 대한 타임 스케줄을 꼭 추가로 관리하시기 바랍니다.

( 규모에따라 10~25% 정도에 시간적 여유를 더 두는 것이 좋습니다. )

그리고 프로그램은 모듈단위에 빡세게 테스트하기 바랍니다

사용자들이 우리가 개발한 의도대로 사용해주기를 바라지만 유저들은 생각보다 똑똑하고 우리가 상상하지 못한 방법으로 프로그램을 사용합니다.

테스트하는 우리도 이 방법으로만 사용하겠지?라는 순진한 생각은 버리시기 바랍니다.

모든 환경에 대한 버그를 사전에 다 예방할수는 없지만 50% 이상의 문제점만 잡아내어도 시스템 오픈 후 크게 어렵지 않습니다.

하지만 테스트를 제대로 못하고 오픈 후 계속되는 문제점 해결에 끌려다니다 시스템 오픈에 실패하는 경우도 꽤 많이 봐왔습니다.

 

이왕 진행하는 프로젝트 결과도 베스트하게 한다면 좋지 않을까요?

물론 테스트를 강화하는 일은 개발작업이 상당히 힘들어 지기는 합니다.

하지만 이렇게 확실한 테스트를  통하여 성공적인 프로젝트를 진행해 보면 오히려 다음 프로젝트부터는 테스트 시간이나 개발 시간을 줄일 수 있습니다.

테스트도 역쒸나 하면 할수록 노하우가 생기고 시간도 짧아지게 됩니다.

지금 프로젝트를 진행하고 있다면 프로그램 개발보다 테스트에 좀 더 시간을 투여해 보시기 바랍니다.

반드시 좋은 결과를 얻으 것입니다!!

 

Posted by Midas Min™
,

저희는 전산팀 내부에서 개발을 하기에 1년에 3~4건 정도의 중규모의 개발 작업을 진행합니다.

짧게는 1달 , 길게는 6~12개월 일정을 잡고 프로젝트를 진행하고 완료 후 별도의 완료보고를 진행하고 있습니다.

저도 처음 전산팀장 자리로 이직하게 되면서 욕심이 많이 생겼습니다.

그래서 회사에서 원하는 프로그램을 빠른 시간내에 만들어 보고하는 것이 제가 인정 받는 것이라고 생각했습니다.

지금 팀장으로서 7년째 생활 중인데 그 사이에 생각이 많이 바뀌게 되었습니다.

 

하지만 타이트하게 잡은 스케줄을 저를 괴롭게 했고 개발하는 프로그램에 퀄리티를 낮추게 되고 사용자들이 요구하는 요구사항을 들어주지 않는 결과를 낳게 되더군요.

그리고 완료 기간이 다 가 올 수록 저에게 가해지는 스트레스도 장난이 아니었습니다.

그리고 이렇게 개발을 진행하니 사용자들의 만족도는 당연히 떨어지겠죠?

저는 2년간 진행하다 생각을 바꿔먹고 프로젝트 기간을 산정할 때 가중치를 주게 되었습니다.

 

* 일반 보강 프로젝트 : 예상 소요기간 * 1.3

* 신규 개발 프로젝트 : 예상 소요기간 * 1.5

* 신기술 적용 신규 개발 프로젝트 : 예상 소요기간 * 1.8(2.0)

 

2년간 개고생을 해본 후 위와 같이 프로젝트 기간을 잡도록 룰을 정했고

추가된 프로젝트 기간은 테스트 및 디버깅, 사용자들과 미팅, 요구사항 수용 등에 적용하였습니다.

이렇게 프로젝트를 진행하면서 얻은 것이 굉장히 많았습니다.

 

1. 사용자들의 믿음을 얻을 수 있음 ( 요구하는 사항에 대해 90% 이상 만족 )

2. 유지보수에 어려움이 없음 ( 테스트 및 디버깅의 고도화로 인하여 디플로이 후 수정사항에 대한 문의가 현저히 적어짐 )

3. 사용자들의 만족도 상승으로 인하여 전산팀 평판이 좋아짐 ( 이게 젤 좋은 거 같네요 )

4. 약속된 시간 내에 프로젝트를 완료하여 경영진에서 바라보는 평가가 높아짐

5. 기존 성공한 프로젝트를 토대로 신규 개발 시 사용자들 설득이 쉬워짐

 

대략 얻은 것을 요약하자면 위와 같지만 생각한 것보다 많은 것을 얻을 수 있었습니다.

그리고 사용자(동료)들에게 만족감을 준다는 것은 정말 큰 성과입니다

그리고 이후 모든 일을 하는데 도움이 정말 많이 되며 동료들의 적극적인 지원을 받을 수 있습니다.

 

물론 중소기업 내에서 소규모 프로젝트를 위주로 진행한 것이기 때문에 정답이라고 할 수는 없습니다.

하지만 나름 팀장으로서 업무를 시작하며 다양한 프로젝트를 진행하였고 어떤 방식으로 진행해야 성공한 프로젝트를 진행할 수 있을까 많은 고민을 하였습니다.

 

그리고 실패의 원인은 잘못 잡은 타임 스케줄이라는 것을 저는 찾아내었습니다.

여러분들도 지금 적절한 프로젝트 기간을 설정하고 작업하고 계신가요?

아니시라면 저처럼 가중치를 두고 진행해 보면 어떨까요?

 

그리고 이렇게 개발된 소프트웨어는 퀄리티가 높고 유지보수가 매우 유리합니다.

그래서 시간이 지날수록 오히려 시간을 아껴주는 시스템이 됩니다.

저희는 전산팀이지만 사무실 전화로 전화가 하루 3통 이하로 옵니다. ( 안 올 때도 많네요 )

그만큼 시스템 안정화가 되어 있단 반증이겠죠~~!!

이건 다음 프로젝트 개발 퀄리티를 높여 주고 개발 시간을 단축하는 효과를 만들어 줍니다.

 

프로젝트 이제 다른 시각에서 타임 스케줄을 잡아 보시기 바랍니다~~~!!

Posted by Midas Min™
,