[스크랩]IT 프로젝트의 안구에 습기차는 스토리

IT 프로젝트의 안구에 습기차는 스토리

블로그뉴스

@ IT 프로젝트 현실 신입 사원 때 이 그림을 접했을 때는 크게 공감가는 부분이 없었는데, 기업 상대의 솔루션 회사에서 일하면서 2년이 되어가는 지금 시점에 이 그림을 다시 우연히 보니까 완전 공감이 간다. 슬픈 것은 이 그림의 원본이 영어로 되어 있다는 점이랄까? 결국 인프라나 시스템이 잘 갖춰져 있는 외국 또한 이런 현실에서 벗어나지 못하고 있다는 이야기일 것이다. 그림의 내용에 덧이어, 개발자의 입장에서 최근 느끼는 가장 큰 문제는 구현이 완료되고 클라이언트 측에서 테스트를 수행하는 안정화 기간에서야 클라이언트 측이 시스템에 대한 이해를 하고, 마음에 안 드는 부분, 빠진 부분을 막 요구하기 시작한다는 점이다. 안정화 기간의 의미는 최종 테스트를 수행하고 에러 발생시에 에러를 수정하는 검수 이전 단계인데, 마치 2차 요구사항 반영 시기같은 상황이 일어난다. 결과적으로 프로젝트 후반기 일정이 완전히 무너지고 검수는 늦어진다. 왜 이런 비효율적인 프로세스가 관습적으로 내려오는 것일까? 내가 생각하는 가장 큰 이유는 시스템 도입 기업(일명 갑)에서 애초에 시스템에 대한 이해와 관심이 크지 않은 상태에서 인터뷰를 수행하고, 구현 이후 안정화 기간에서야 실제로 돌아가는 모습을 보고 '이거 불편하고 저거 잘못됐네, 이건 좀 넣어줘야겠다' 식으로 실시간으로 오더를 내려버리는 것으로 보인다. 안타깝게도 안정화 기간이 검수 이전에 이루어지기 때문에 파워 게임에서 갑이 칼자루를 쥐고 있기에 개발 측에서 이를 거부할 수 있는 경우는 별로 없어 보인다.(검수 이후에 유지보수 기간에도 거부하기 쉽지 않긴 하지만... 영업 측에서 잘 풀어야되는 문제이긴 하다) 설계, 프로토타입 및 구현된 프로그램을 수시로 보여 주며 프로세스 진행 중간중간에 수시로 인터뷰하고 계속적으로 수정하는 방법이 그나마 선택할 수 있는 방법이 되지 않을까 생각되지만, 그렇게 협조를 잘 해줄 클라이언트가 있을지는 조금 미지수랄까... 이렇게 아무리 고민해도 뚜렷한 방안은 없다. 하긴, 그러니까 SI 프로젝트가 몇 년씩이나 시행되어 왔지만 이런 문제가 전혀 해결되고 있지 않고 있겠지. 결국은 그 놈의 '손님은 왕이다' 정신이 문제 (*) 윗 글의 출처는 아래 블로그입니다. - 블로그명: JT Lim's Life Inside - 블로그주소:http://heartdev.tistory.com/ - 기사바로가기:http://heartdev.tistory.com/408