미니의 중소기업 전산실 이야기

보통 서버, 네트워크  장비의 경우에는 5년

데스크톱, 노트북 같은 경우 긴 곳은 5년 짧은 곳은 3년 정도에 사용기한을 주더군요.

내구성이 약한 노트북을 전산담당자가 7년째 사용 중이니 이 부분을 지키기는 힘들더군요.

CPU 성능이 상향 평준화 되면서 오래 쓰는 것도 있고 SSD의 등장으로 사용자들이 속도 저하를 느끼는 시점이 매우 늦어진 것도 한 가지 요인이긴 하지만...

중소기업에서 장비에 대한 투자는 인색하죠.

물론 그렇지 않은곳도 아주 가끔 보지만 거의 보기 드문 것 같습니다.

장비는 사전예방으로 교체보다는 고장 후 사후교체가 되고 있죠.

저도 회사를 옮기고 서버 교체주기인 5년이 다가오면서 교체 보고서를 준비 중인데...

어떻게 설득할지 고민 중입니다.

자동차나 다른 장비의 경우 법정 연한이 되면 교체하는걸 당연하게 생각하는데...

눈 앞에 바로 보이지 않는 전산장비에는 많이 인색하네요...

이번에 예산 잡으며 설득 여부에 따라 앞으로의 장비 관리가 틀려지겠죠? @.@

사용자 장비들이야 조금 더 사용하고 사고 후 교체해도 무리가 없다고 판단되지만

서버에 대해서는 사전 예방에 대한 투자가 앞으로 조금 늘었으면 하는 바람이네요!!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

어제는 주말이라 오래간만에 딩굴딩굴하며 부의 확장이란 책을 읽었네요!!

이 책에서도 사람 간의 커넥션을 통해 부의 확장이 이루어진다는 진리였어요!!

제 생각에도 삶도 마찬가지라고 생각합니다.

여러 사람들과의 커넥션을 통해 일하게 되고 그 관계를 통하여 소통하게 되는 거죠.

그리고 사람들은 자신의 약점을 오픈하기를 싫어합니다.

어떤 프로젝트를 진행을 했어도 물론 잘된 부분이 존재하고 실패한 부분도 존재합니다.

이 실패하거나 잘못된 부분을 숨기고 넘기려는 경우를 저는 살아가면서 많이 보았습니다.

분명 지금 잘못된 부분인데 나중에 잘 고쳐지겠지... 아니면 누군가가 마무리하겠지 하는 식으로

다 된 것과 같이 포장하여 보고하거나 통지를 하게 됩니다.

전 이걸 보면서 폭탄 돌리기가 생각나더군요.

현재 프로젝트 결과 보고를 쉽게 하기 위해 프로젝트에서 미완성된 부분을 덮어 높고 완료된 것처럼 보고를 하고

그 피해는 고스란히 후임자가 떠안게 되는 악순환이 발생하는 거죠.

저 또한 여러 번에 이직을 하면서 위와 같은 경험을 몇 번 했습니다.

후임자로 간 저는 그 구멍 난 부분을 메꾸느라 고생하고 욕을 욕대로 먹을 수밖에 없었죠.

그리고 한 가지 저와 약속한 건 있죠.

보고는 확실하게 하고 잘못된 부분이나 덜 완료된 부분에 대해서는 확실하게 보고하고 내가 잘못한 부분은 달게 벌을 받자!! 그리고 이 신념은 아직까지는 잘 지키고 있습니다.

물론 이덕에 저와 같이 일하는 후배들은 아주 힘들게 일하고 있죠 ^^;;;

하지만 이 방법의 큰 장점은 사람을 잃지 않는다는 것입니다.

이 신념 덕에 저는 첫 회사부터 지금까지 이직한 회사 직원들 대부분과 아직도 연락을 하고 지내고 주기적인 모임도 갖습니다

제가 이직을 하면서도 당당하게 인수인계를 하고 최선을 다해 프로젝트나 관리를 했기에 가능하다고 생각합니다.

지금 잘못된 부분에 대한 보고를 하는 것이 어려울 수 있습니다.

하지만 그 또한 한순간이며 그리고 이번 실수로 인해 다음에는 같은 실수를 하지 않을 것입니다.

하지만 이걸 덮고 수습을 한다면 다음번 프로젝트 아니면 다음 이직한 곳에서 같은 실수를 반복할 것입니다.

그래서 저는 솔직하고 당당하게 보고하는 방법이 최고라고 생각합니다.

그리고 실수한 부분은 인정하고 개선하면 됩니다. 이 과정을 거치지 않으면 본인이 더 발전할 수 있는 기회를 놓치는 것과 같습니다.

저 또한 아직까지도 많은 실수를 하고 고치려고 노력하고 리스크를 줄이기 위해 책을 읽고 공부하고 있습니다.

그리고 앞으로 일할 후임자들에게 떳떳한 선배가 되고 싶습니다.