SI 프로젝트에 대한 단상

SI의 정의는 System Integration 의 약자로 단어대로는 시스템 통합이며
그 내부의 작업들을 들춰보자면 H/W와 S/W를 같이 납품하면서 기존의 시스템과 신규 시스템을
통합하여 기업체의 원할한 비지니스 활동을 유지할 수 있도록 시스템을 구축한다.
라고 생각할 수 있다.

보통의 프로젝트는 분석/기획, 설계, 구현/테스트 , 납품의 단계로 구분 될 수 있으며
각각의 단계는 앞으로 돌아가기엔 (바로 앞단계라 하더라고) 되돌아 가버리면 공정기간을
맞출 수가 없는 프로세스이다.

일단 지나쳐버리면 이전단계의 문제점을 파악하면서 차기 버전에 대한 기획을 해야하며
현재 진행중인 프로젝트에서는 반영하면 안되는 문제점이 있다.
(혹시나 반영하게 되면 프로젝트 완료일은 미뤄져야 하지만 실상은 일정은 그대로고 해야하는
일이 바뀌게 된다 -> 야근의 원인)

머 사실 국내에서 애자일 방법론을 도입하기엔 프로젝트시에 요구하는 문서가 너무 많고
돈을 주고 받고 납품하는 일이기 때문에 결과는 성능이나 프로그램 자체가 아니라 문서가 되는
경우도 있다.

제품의 질이나 성능보다는 당장 눈에 보이는 일시적인 성능과 돈들여서 프로젝트를 진행했다는 증거로
사용할 문서들이 중요시 되는 경향에 대해서 개발자들은 어떻게 생각하는지
혹은 현재 개발되는 프로세스에 대해서 얼마나 이해를 했는지에 따라서 완료시의 프로그램의
품질은 물론 문서의 품질도 달라지게 되는건 분명한 사실이다.

업무를 10%밖에 이해하지 못한 사람이 만든 프로그램 전체의 10%만 대처를 할 수 있을것이며
100%를 이해한 사람은 요구하는것에 무엇인지 확실히 알기 때문에 전체적인 면으로 프로그램을
작성할 것이며 그렇게 된다면 프로그램은 물론 문서의 품질도 올라가게 되는것이다.

배경 : 무엇이 문제인가.
위에 있는 말들은 원론적이고 누구나 알고 저렇게 해야한다고 느끼면서 안한다.
아니 못한다.. 왜 못하는걸까??
능력이 없어서?? 학벌이 딸려서?? 돈이 안되서??
나는 이문제의 시작은 발주처라고 생각한다.
신규 시스템을 도입하건 기존의 시스템을 개선하던 가장 필요한건 해당업무.. 즉 전산화 대상 업무 및
기존의 개선대상 업무에 대해서 명확한 구분을 정의하고 기존의 업무의 담당자가 편하더라도 비효율
적이라면 과감히 새로운 방법을 재정의 할 수 있는 결단성이 필요하다.
하지만 대부분의 프로젝트는 어떤가??
가장 많이 듣는 말이.. "하던대로 해주세요" 이말이다.
어쩌라는건가?
기존의 프로세스를 그대로 쓸거면 어째서 돈 아깝게 전산시스템을 도입하고 개선 프로젝트를 진행하나?
그룹계열사 매출 올려주려고? 아니면 다른 회사가 하니까 자기들도 해야할거 같아서?

이런식으로 프로젝트 진행하면 돈은 돈대로 날리고 업무는 업무대로 복잡해지고
프로그램은 쓰지 않게 된다.. (결과가 같은데 굳이 새로 배울 필요가 있을까? 하던대로 일하면되지)

결론 : 신규/개선 프로젝트의 목적을 생각해야한다.
이윤을 추구 하는 기업이라면 프로젝트의 진행을 결정하기 전에 필요성을 먼저 생각해서
추진하기 바란다..
다들 말할때 SI 개발자가 수준이하라고 하면서 자기들의 수준은 생각하지 않는거 같다.
발주자의 수준부터 확인해보고 싶다. 프로젝트 진행전에 관계자들하고 면담을 하면서
기존의 업무를 체계적으로 정리해보고 정리해서 신규 프로세스를 만들던지
아니면 기존의 내용을 기초로 진행을 하던지 결정해야할 것이다.

엔터프라이즈라 일컬어지는 대규모 시스템에서는 DB의 한 테이블에 있는 같은 컬럼에 대해서
서로 다른 부서에서 다른 값으로 정의해서 쓰는 경우도 있고 같은 역할을 하는 중복된 두개 이상의
컬럼을 쓰는곳도 있다. 이런 것을 모두 막기 위해서 업무를 담당하는 부서의 장이 회의를 하는게
아니라 실무자가 해야한다고 생각한다. 각 팀의 실무자들이 모여서 서로의 업무를 알아야 자신의
업무도 더 이해할 수 있다고 생각한다. 그러면 프로젝트시에 고쳐야 할 점도 눈에 확 보일테니까
견고한 설계과 그에 따른 고품질의 프로그램과 도움되는 문서를 바랄 수 있지 않을까..