대부분이 J2EE 기반 SI 프로젝트일 것입니다.
하지만 이런 SI 프로젝트가 힘든 이유가 무엇
일까요 그 풀리지 않은 미스터리에 대한
의문점과 나름 해결 방법을 몇자 적어보려고
합니다.
- 왜? 크리니컬 이슈는 항상 개발 막바지에 발생 하는가?
애자일의 가장 기본은 바로 test-first 입니다. 즉 개발 보다
테스트 환경구축 입니다.
공통모듈,프레임웍,비지니스 로직 개발 등 이러한 것보다
제일 먼저 아래와 같은 Activity가 선행이 되어야 할 것입니다.
- JUNIT과 같은 단위 테스트 탬플릿
- CI(Maven,Nexus,Hudson..등)를 위한 자동화 빌드
- Code Inspect (PMD..등)
※ 가끔 개발자 분들이 JUNIT을 상당히
귀찮은 존재로 생각을 하십니다.
개발할 것도 많은데 어느 세월에 Test
Junit을 만드냐고 합니다.
하지만 그건 전혀 잘못된 생각 입니다.
스프링이 Pojo인 이유는 바로 테스트를
편하게 하기 위해서 입니다.
그리고 저는 예를 들어서 게시판 CRUD 한 셋을
화면 포함해서 개발할때 비지니스로을
먼저 만들고 Junit으로실행 한다음
뷰단을 몰아서 작업 합니다.
그 중독성이란... 여러분 한번 제 방식이랑
여러분 방식이랑 CRUD 배틀 한번 해볼실까요^^
로직이 복잡할수록 그 공수 차이는 더 커집니다.
- 왜? 화려한 시스템 아키텍쳐 청사진과 멋진 패턴로 구성된 UML 문서는 있음에도 불구 하고 프레임웍은 항상 불안 할까?
대부분 개발표준,프레임웍 구성등은 AA(Application Architecture)가
설계및 구축을 담당하고 있습니다. 하지만 최근 개발 동향을 보면
금융권을 제외한 (책임문제 때문인지 상용툴만 사용)한 일반
프로젝트는 스프링 기반에 오픈 소스로 구성 되었습니다.
물론 AA가 당연히 기술적인 부분을 많이 알고 있어야하지만
많은 오픈소스에 대해서 물리적으로 혼자서 해결 한다는 것은
무리라고 생각 합니다. 즉 전문 Technical 팀이 구성이 되어야
한다고 봅니다. AA 팀에 같이 소속이 되었던 별도의 공통파트이건
간에 이러한 팀이 AA와 기술적인 긴밀한 협조를 통해서
기술적 리딩을 해야 한다고 생각 합니다.
- 일정은 있고 대화는 없는 건가?
하지만 일정관리 와 같은 중요도를 가지고 있는 것이
바로 프로젝트 팀원 관리 입니다.
하지만 이런 부분을 간과하는 경우가 많습니다.
가끔 저는 프로젝트가 이슈가 생겨서 중간에 투입
하는 경우가 있습니다. 그럴때 저는 일정이 연기되었거나
또는 기술적인 이슈가 생기는 것은 그다지 우려가 되지
않지만 PM,PL과 개발자 사이에 대화가 없으면
투입을 주저 합니다.
서로 대화가 없으면 솔직히 그프로젝트는 끝나다고 봅니다.
그 얘기는 개발자를 단지 도구나 툴로 밖에는 생각 하지
않는 다는 것입니다. 자 프로젝트 리스크를 제일 정확하고
잘알고 있는 사람이 누구일까요?
1.PM 2.PL 3.AA 4.개발자
정답은 전 개발자라고 생각 합니다. 개발자끼리 모여서
담배 피면 아마도 십중팔구
"이 프로젝트 큰일이다 답이 없다 답이" 이런 말들을
합니다.
개발자가 네거티브한거 인정 합니다. 하지만 틀린 얘기는
아닙니다. 일정만 강요하는 프로젝트에서는 절대로
왜 답이 없는지 말을 하지 않을 것입니다.
- 누가 고급이고 누가 중급인가?
가끔 개발을 하게 되면 누가 고급이고 중급인지 분간을
할 수가 없습니다. 개인적으로 한분야에서 7년차까지는
구분이 필요하다고 생각합니다. 하지만 그 이상이 넘어가면
경력은 무의미 하다고 봅니다. 예전 개발 환경은 잘하는 사람,
못하는 사람 별 차이가 없었습니다.
하지만 최근에는 업무적/기술적 규모나 복잡도가 예전에
비해서 비교도 할 수 없을 정도로 커졌습니다.
즉 개개인의 능력 차이가 엄청나게 커졌습니다.
프로젝트 전문가 얘기를 들어보면 잘 하는 사람과
못하는 사람의 본수가 10본이상 차이가 난다고 합니다.
앞으로 인력을 선별할때 단순 년차 비교가 아니라
이전 플젝 PM이나 아니면 인맥 정보를 동원해서
그만큼 스킬이 있다면 중급이더라도 고급 대우를
해야 한다고 생각 합니다.
즉 경력보다는 인재를 확보해야 합니다.
- 왜? 리스크가 있음에도 불구하고 그걸 바보처럼 한다고
- 한 담당자에게만 책임을 몰빵하는가?
한번은 DA (Data Architecture)와 업무적으로 다툼적이 있었습니다.
Date형을 전부 varchar2(14)로 수정했다는 얘기 입니다.
그 런 큰 이슈를 전체 공지나 이슈화 하지 않았냐고 하니
"저번에 말씀 드렸잖아요. 그리고 개발문서에도 있구여"
그말을 듣는 순간 이단 옆차기 하고 싶은 충동이....
프로젝트하는 곳이 가정법원인가? 그래 나랑 개발팀이
몰랐다 글면 자기 혼자 사는 것인가? 어떻게 대놓고
책임을 회피하는 발언을 하는지...
그리고 한번은 PL이 저한테
"저 김과장님 이거 하는데 잘안되네..."
"내 제가 잠깐 볼게요"
다음날...
"그거 언제 되요? 늦어도 이번주까지는 되야 하는데"
음..................
- 왜? 우리는 많은 경험을 하고도 또 경험을 해야 하는 것일까?
현실적으로 SI 프로젝트에 대해서 A~Z까지
다 알수는 없지만 각자 말못한 고충과
일들이 있을 것입니다.
무 조건 "갑",PM,PL,개발자 들을 비난할수는
없 습니다. 하지만 체질 개선은 반드시
필요하다고 생각 합니다.
사실 SI 프로젝트라는 것이 고객의 needs를 잘 분석해서
끈끈한 팀웍과 훌륭한 조직원들이서로 공유하고
리스크 최소화 하면서 결국 최고의 시스템을
고객에게 주는 것인데 무엇이 우리를 힘들게 하는 것인지
참...우리 모두 고민을 해야 할 것 같습니다. 마지막으로
"SI Project (전문가로 가는길)"이란 책에서 발췌한
"성공적인 프로젝트의 요건"에 대해서 말씀 드리고
마무리 하겠습니다.
1. 고객을 프로젝트에 최대한 깊이참여 하도록 한다.
2. 고객 경영진의 적극적인 후원을 얻어야 한다.
3. 인수인계를 위한 대비를 일찌감치 시작한다.
4. 80:20(인재) 률을 최대한 활용하라.
5. 고객의 속마음을 읽어라
6. 프로젝트팀을 잘 관리하라.
모드 성공적은 SI 프로젝트가 되길 바랍니다.
댓글 없음:
댓글 쓰기