일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- maven #junit
- SI와 SM 차이점
- SW분석
- angular 6
- sonoff
- ASUS 공유기
- 경력개발자
- open cursors
- 소프트웨어설계
- SW설계
- 네트워크 기본개념
- Tomcat error-page version
- tvheadend
- 프로젝트관리
- USB-C충전
- USB-C to HDMI 아답터
- EXK
- 구글캘린더 검색
- docker 네트워크
- 자바튜닝
- Data Transfer Object(DTO)
- Value Object(VO)
- 객체설계
- LG그램2017
- SpringBoot
- LAN WAN
- 자바스크립트 JQuery
- 자바개발
- 실해하지 않는
- CBD 단점
- Today
- Total
대빵's Blog
실패하지 않는 SI 프로젝트의 필수요건 본문
SI 경력 19년차 정도 되면 이제 왠만한 프로젝트 패턴들은 눈에 익숙하기 마련이다.
개인적으로 이곳 저곳 프로젝트를 진행하고 소방수 역할도 하고 지원도 하면서 도대체 왜 이 프로젝트는 실패 했을까....를 고민해보니 결론은 의외로 단순한 곳에 있었다.
1. 프로젝트가 실패하지 않으려면 필수적으로 리스크를 관리해야 한다.
프로젝트는 리스크관리와의 싸움이다. 관리되는 리스크는 더 이상 이슈화 되지 않기 때문에 프로젝트는 결과적으로 큰 문제없이 마무리 된다.
문제는 리스크관리, 리스크관리 하는데 도대체 어떤게 리스크관리 인가를 알아야 한다.
2. 결론 안나면 둘다 해봐라
프로젝트에서 리스크는 뭔가 제때 결론나지 않는 것이다. 지금 무엇인가 업무를 진행해야 되는데 결론 나지 않는 것이 바로 리스크 이다.
하드웨어가 더 필요한지 아닌지, 개발자가 더 필요한지 아닌지, 솔루션이 더 필요한지 아닌지.... 등 프로젝트는 현재 의사결정 해야 하지만 여러가지 여건상 의사결정할 수 없는 경우가 많이 있다.
가장 좋은 리스크 회피 방법은 둘다 하는 것이다.
좀 어이없이 들릴수도 있지만 하드웨어가 더 필요하면 더 필요한건 그것대로 진행하고 필요한것을 못 얻는 경우를 상정해서 플랜B를 만들어야 한다. 굉장히 간단하지만 의외로 많은 사람들이 플랜A만 고집하고 플랜B는 의식적으로 미루거나 숨긴다. 왜냐하면 일을 더 해야 되기 때문이다.
플랜 A 만 하면 되는데 플랜 B 도 해야 하기 때문에 일이 두배 많으면 세배도 된다. 하지만 이보다 더 큰 문제는 플랜 A 외에 플랜 B를 할수 있는 능력 그 자체가 없다는 것이다.
하드웨어가 없어서 소프트웨어 적으로 해결가능한지 알고 싶은데 프로젝트에 개발자가 없거나 PM/PL 이 개발능력이 없어서 시도자체를 할 수 없는 경우가 가장 큰 문제이다.
3. 프로젝트 시작부터 엔지니어(개발자)가 있어야 한다.
2번의 문제를 해결하는 가장 좋은 방안은 프로젝트 시작부터 개발자(엔지니어)가 존재하는 것이다. 프로젝트 초기에 실력이 검증되고 신뢰할만한 엔지니어가 있는 프로젝트는 거의 실패하지 않는다.
가끔 PM / PL 이 엔지니어인 경우 해당 프로젝트는 상대적으로 덜 문제를 일으킨다. (물론 PM / PL 이 엔지니어로서만 능력있고 PM/PL로서의 능력이 떨어지는 건 또다른 리스크를 야기한다.)
대기업 또는 대형 공공 프로젝트인 경우 이러한 리스크를 해결하기 위해서 아키텍트 라는 직군의 엔지니어들이 투입된다. 사실 아키텍트는 간단히 얘기하면 PM 과 유저와 직접 소통하면서 의사결정할 수 있는 엔지니어가 아키텍트 인 것이다.
4. PM/PL 도 엔지니어(개발자) 이어야 한다.
대부분의 SI 사업에서 인건비는 가장 큰 비용항목이고 인건비를 줄이려면 프로젝트 분석/설계 초기단계에 개발자가 없어야 비용이 줄어들기 때문에 많은 기업들이 초기에 개발자 투입하지 않고 비용을 절감하려고 하지만 결국 이렇게 절감된 비용은 차후 프로젝트가 제때 끝나지 않고 하자보수단계로 넘어가면서 더 많은 비용을 발생시켜서 결과적으로 더 많은 비용을 발생시킨다.
하지만 이러한것을 엔지니어가 아닌 의사결정권자(임원급)들에 설득하는 것은 부질없는 짓이다. 설득당할 사람은 이미 그러한 내용을 알고 있기 때문에 시행하고 있거나 시행할 여력이 안되는 경우이고 대부분의 비엔지니어 의사결정권자들은 이해야지 못한다.
따라서 PM/PL 이 엔지니어 이어야만 프로젝트의 리스크가 관리될 수 있다.
실패하지 않는 프로젝트를 만들기 위한 필수요건은 PM/PL 이 엔지니어 이면서 PM/PL 업무도 같이 어느정도 수행해야만 SI 프로젝트가 큰 문제없이 진행가능하고 이러한 인력이 현재 거의 없기 때문에 대한민국의 SI 사업이 항상 실패리스크가 높은것이 현실이다.
'개발관련' 카테고리의 다른 글
CORS(Cross-Origin Resource Sharing) 정리 (0) | 2019.01.16 |
---|---|
Hyper-V 에서 docker 네트워크 설정하기 (0) | 2018.12.21 |
실력있는 개발자가 인정받지 못하는 이유 (0) | 2018.10.24 |
VO 와 DTO 의 차이점 (0) | 2018.10.24 |
Spring Security + Angular 6 설정하기 (0) | 2018.09.26 |