반응형

무너진 프로젝트 R&R, 사라진 Modeler

 

최근 프로젝트에 합류해 보면, 업무의 R&R이 많이 무시되는 것 같습니다.

프로젝트 비용을 줄이기 위해서인지, 지켜야 할 선을 넘어서고 있는 듯 합니다.

 

예전에는...

PM, PL, 설계자, 개발자 로 구성되어 하나의 업무팀을 이루었습니다.

규모에 따라 PM, 설계자, 개발자로 구성되기도 했습니다.

 

최근에는...

PM, 개발자로 구성되는 경우가 많습니다.

대외적으로는 개발자가 설계/개발을 함께 하는 것으로 되어 있습니다.

 

여기서... 문제가 발생합니다.

대부분의 개발자는 '프로그래밍적' 관점에서는 뛰어날 수 있으나, 업무는 글쎄요...?!

설계자의 경우 '업무' 관점에서는 이해도가 높을 수 있으나, 개발은... 역시 ?!?

 

프로젝트에 참여해보면, 업무요건의 협의 및 기술검토( 개발방향성 설정 ), 타팀과의 협의 및 요청사항 등

설계자가 해야할 일들이 무궁무진합니다.

개발자도 새로운 개발환경에 적응하고, 업무요건에 따른 코딩 및 테스트, 데이터 검증을 해야합니다.

 

대부분의 프로젝트가 일정의 여유가 없습니다.

그런데, 두 가지를 함께 한다?? 쉽지 않은 일입니다.

 

그러고, 무엇보다...

개발자들은 기술( =프로그래밍 언어 등 )이 맞으면 어느 업무고 일을 찾아 갑니다.

( 먹고 살아야죠. 원하는 업무만 찾아 다니다가는 굶어죽기 딱 좋습니다 )

개발표준, 프레임웤, 사이트 정책, 개발툴 등 숙지하고 이해할 것이 많습니다.

다양한 업무를 접하고, 바쁘다보니(?) 업무의 이해도가 높아지려고 해도 그럴수가 없습니다.

( 아주 오랜기간 특정 업무를 꽤 많이 했다면, 예외일 수 있습니다 )

 

그런데, 현실은 설계 및 개발을 함께 요구합니다.

그래서 프로젝트들이 다 망해가는 것 같습니다.

 

이런 환경이다 보니... 

예전에는 따로 있었던 Modeler라는 역활이 사라져 버렸습니다.

공통DA이니 DBA이니 하며, 프로젝트에 Model을 관리하는 1~2명으 사람만 존재합니다.

 

각 업무팀의 모델러는 어느새 '개발자'로 대체되어 있습니다.

20년을 한 개발자들 중에서도 Model을 제대로 설계해 본적이 없는 사람이 허다하게 많이 있습니다.

ERD를 한번도 그려보지 못한 사람도 부지기수 입니다.( ERD의 필요성을 무시하는 사람도 많습니다. )

 

그런데, 이런 사람들에게 모델을 설계하게 하고, 그렇게 만들어진 물리모델로 개발을 합니다.

명명규칙부터, Relation까지 제대로 맞는게 없기도 합니다.

 

이렇게 아낀 프로젝트 비용은 다 어디로 갈까요?

하청에 하청에 하청을 주면서, 수수료로 빠지고, ( IT 지알못 )소싱업체들이 다 먹습니다.

인건비는 안 오르고, (프로젝트는 망하니) 일은 점점 더 힘들어지고, 4D직종이라 신규유입은 없고...

고령화 되다보니 트렌드나 기술흐름을 따라가지 못하고...

 

이번 프로젝트를 보니...

DBA는 어디에도 보이지 않고, 1명 있는 DA는 업무를 처음하는 사람 수준이고

혼자라는 이유로 제대로 일처리도 안되고 있습니다.

 

이 바닥의 종사자중 한 사람으로써... 참 갑갑하고 안타깝습니다.

OTL...

반응형