'처세술'에 해당되는 글 1건

  1. 2009/10/06 kineticroad SI 처세술 (11)

SI 처세술

Diary 2009/10/06 10:39
SI(System Integration) 쪽 개발 종사자들은 (개발자를 비롯해 디자이너들도) 모두 고된 일정을 감수한다.
보통은 대기업쪽에서 SI 사업을 발주하면 중소기업의 개발회사들은 수주를 하고 그 사업에 직원을 파견하여 사업을 마무리하는 것으로 이뤄진다.
그럼 중소기업에선 일을 따오기 위해 제안서, 프리젠테이션, 접대 등을 통해 일을 수주하는데 여기서 문제가 있다.

대기업에선 단가를 낮추기 위해 중소기업들을 고르고
(물론 질좋고 값싼것을 구입하는게 구매자의 기본 욕구라 어쩔 수 없다고 생각한다.)
중소기업에선 대기업의 요구에 맞추기 위해 기간과 금액을 조정한다.
투입되는 인원과 프로젝트의 규모에 맞춰 금액을 상정하고 적정선에서 서로의 이해관계가 성립되면
계약을 하고 프로젝트를 진행한다.

SI사업을 따오는것은 영업사원이 부담하고
 그 사업을 이끌어가는 것은 개발자, 디자이너, 기획자들이 맡는다.

자. 계약서를 썼다 치고 프로젝트에 투입되는 인원은 1차적으로 업무에 대한 내용을 전달받고 경악한다.
(보통 그래왔던것 같다.)
나는 4개월안에 혼자서 포탈사이트급 대형 사이트의 게시판을 Flex로 개발하라는 일을 받은적도 있었다.
게시판 갯수만 무려 80개. 각각의 게시판은 서로다른 스펙과 기능을 갖고 있었고 어느것 하나 클래스 하나로 엮을 수 없었지만 그 영업을 맡았던 대표는 한마디로 일축했다.

"CRUD 80개야. 잘 묶어서 하면 금방 끝낼 수 있어"

오마이 갓.
이런 무개념할 때가.(심지어 무성의하기까지 하다.) 어쨌든 그 프로젝트는 마무리되서 나오긴했지만.. 아, 물론 당연하게도 사고 직전까지 갔었다.
이 대표라는 사람은 스스로가 개발자 출신이라 자청하고 다녔던 사람이라는 점에서 경악을 금치 못했다.
그리고 Flex 개발자라는 제약은 서버쪽 개발까지 할 수 없다는 조건이 걸려있다.
이유는 UI 요구사항도 만만찮은데 서버쪽 개발까지 했다가는 이미 초과된 업무량을 뛰어넘어야만 하기 때문이다.
그럼 보통은 서버쪽 인력과 협업을 하는데 다른 개발자들과 손발을 맞추다가 삿대질하며 싸우기 일쑤고
나중엔 누가 잘났네 아니네 하면서 시간을 잡아먹기 일수다.
그런데다가 클라이언트는 자신이 상상했던것과 다르게 나오면 일단 다 엎고 나가야 한다는 식으로 기획을 엎기 일쑤.

기본적으로 업무를 시작하더라도 업무량이 초과된 시점에서 다른 개발자들과의 이해관계가 어긋나면 서로 싸우고 잘못을 떠넘기는데다가 클라이언트가 기획을 엎어 버리는 일이 수도 없이 발생하는 곳이 SI 개발이라는 곳이다. 사람이 할 짓이 아니라는 이야기다.
더 큰일인 것은 기획을 엎는다고 해서 "종료일은 늦춰지지 않는다".
불문율이다. 프로젝트 종료일은 결코 늦춰지지 않고 사건 사고, 기획을 엎는데 발생하는 시간적인 손실은 결국 야근과 철야로 채워넣어야한다.(나는 이런생활을 1년 7개월간 했었더랬다. 그덕에 병을 안고 퇴사를 했었지)
그래서 각 대기업의 인트라넷, 모니터링 시스텀, 대시보드 같은 서비스를 만들어내고 관공서, 대기업들의 홈페이지들을 만들어 낸다. 한마디로 개발자들(다시한번 말하지만 여기서 말하는 개발자는 프로그래머, 디자이너, 기획자들을 이야기 한다. 프로젝트를 개발하는 사람들을 통칭한다.)의 피와 눈물과 땀과 잠과 욕지기나오는 상황들을 뚫고 나온거라는 거다. 그렇다면 돈이라도 많이 벌어야할텐데 난 작년 한달에 100만원 조금 더 받는 수준이었다.(120만원이라도 받았으면 좋았을뻔했다)
야근 수당, 휴일근무수당 이따위 대우는 없었다. 1년간 내게 주어진 연차는 2일뿐이었고 그 2일도 연중에 사용할 수 없어서 다음해 사용했다.

그래서 나는 개발자(특히 웹을 하겠다고 덤벼드는)를 하겠다고 하는 후배가 있다면 말렸다.

사실 서점에 가보면 프로젝트 진행에 있어서 도움을 주는 서적들이 많이 나와있다. "애자일 프렉티스"라던가 하는 것들 말이다. PM으로써 개발자로써 해야할 처세술에 대해 설명해 놓은 것들인데 실무에가서 써먹을 수 있을까 하고 사다 읽어봤지만 역시나 꿈같은 이야기들이지 않나 싶었다.
현실은 개발이 완료되는 시점이 다가와서 클라이언트가 난데없이 "저건 좀 아닌거 같은데 수정해 주세요"라는 말 한마디에 코드도 엎고 디자인도 엎고 기획도 엎어지는 현실에 무슨 애자일한 개발론이냐는 거다.
그럼 영업사원 투입되서 계약기간과 업무량에 대해 설명하고 이래선 안된다는것을 어필해서 성공하면 다행이지만 내 경험상 클라이언트 대다수의 성격은 똥고집의 소유자다.

이 사태를 어떻게 이끌어 가야하는 걸까.
어떻게 해야 개발자들이 보다 나은 대접을 받을 수 있을까?

그럼 일단 현재 직면한 문제들을 생각해보자.

1. 돈(Money)
아주 웃긴것은 지식경제부에서 소프웨어 개발자들에 대한 몸값을 지정해 놓았다는 것이다.
그 덕에 내 경력이 그보다 못하다면 돈을 적게 받을 수밖에 없다.
내 능력이 어떻든 내가 일을 많이 하든 적게하든 말이다.
야근을 하고 철야를 하고 주말도 없이 일하지만 내가 한달에 받을 돈은 정해져 있다.
(보통 SI에서는 M/M으로 금액을 산정하니까 말이다.)

2. 시간(Time)
인간이 하루에 일할 수 있는 적정시간은 8시간정도로 아침 9시에서 저녁 6시까지 일하고 중간에 점심시간 한시간은 제외한다. 이런 노동시간은 노동법에도 명시가 되어있어서 야근을 했을때는 기본급의 1.5배를 지급해야하며 주당 야근할 수 있는 시간을 제한해 놓았다.
하지만 3개월안에 뭔가 대단한것을 만들어야하고 그 안에 들어가는 로직이 클래스 1,400개정도 분량에 눈에 보이는 디자인 페이지가 무려 100개가 넘고 기획서가 백여장이 넘어버리면 개발자들은 매일을 철야에 밤샘에 주말도 없이 일을 해도 모자르다. 그래놓고 완료를 못한다 하면 "너가 놀아서 그런거다"라고 일축하고 내 밤샘과 내가 포기한 주말들은 그저 쓰레기 종이조각이 될 뿐이다.

3. 사람(Man)
보통 SI 사업엔 적게는 3명. 크게는 백명가까이 되는 사람들이 매달려(물론 더 많은 프로젝트도 있다더라.. 아직 경험해보진 못했다.) 일한다. 사람이 많으면 발생하는 이슈가 업무분장 이라는 것인데 서로 무슨 업무를 맡아서 진행할지 결정하는 일이다. 물론 이런 과정에서 업무가 확실히 분리되서 자신의 일만 처리하면 되는 그런 꿈같은 일은 벌어지지 않는다.
다들 완벽하게 일을 분리했다고는 하지만 결국 나중에 프로젝트 중후반에 들어서서는 제대로 나눠지지 않은 업무가 나타나고 이런 업무에 대해 서로 책임지지 않으려 한다. 그런 과정 속에서 일정은 지멋대로 흐르고 처리되지 않는 업무들이 늘어만 가게 된다. 종국엔 프로젝트 "사고"가 일어날 수도 있는 일이다.
물론 그런 일이 발생하면 서로 책임 전가하기 바빠서 내가 말싸움을 하러왔는지 일을하려고 왔는지 알 수 없는 일들도 생긴다.

위와같은 문제점은 사실 1년 반 정도를 혼자서 프로젝트를 뛰어왔던 내게 일어났던 일들을 크게 3가지로 분류해서 써놓은 것이다. 물론 위와같은 일이 없는게 좋지만 내가 뛰었던 프로젝트 (약 11 - 14개)  중에서 9개 정도는 그저 싸움만 하다 끝이 났었더랬다. 한번에 10명과 싸운적도 있었고 때로는 다른 업체 차장급 개발자와 삿대질 하며 싸웠다. 그 이유는 프로젝트가 사고 직전으로 다가올 때 그 책임을 인정하는 순간 프로젝트 실패에 대한 모든 책임을 떠안아야했었기 때문이었고 그 책임은 손해배상으로 다가왔기 때문이었다.
(전 회사 사장은 그럴때면 직원들에게 이야기 했다. "그 책임을 너희들 월급에서 까야 정신차리겠냐"고. 그러니 피터지게 나가서 싸워야 했다.)

그렇지만 뒤늦게 깨달은건 프로젝트를 진행함에 있어서 사고라는 것은 모두의 책임이고 프로젝트 참여자 하나하나의 책임이라는 것이며(프로젝트를 따온 영업사원 및 회사 대표까지 전부 다) 그 책임을 누구하나에게 전가할 수 없다는 사실이다. 누구 때문인지 잘잘못을 가리는 순간 이미 망쳐버린 프로젝트가 되어버린다는 것을 깨달았다.
 누구에게 책임을 넘기기 전에 일단 하던 일은 마무리 해야 무슨 할말도 할것 아니냐.
 
아무도 대신 일해주지 않는다.


제목엔 SI 처세술 이라고 적어 놨기 때문에 몇가지 적어놨는데 결론은 다음과 같다.

1. 책임을 떠넘기기 전에 내 할일을 끝내놓는다.
2. 불확실한 일에 대해 확언하지 않는다.
3. 일을 받게되어 스케쥴을 정할 때 기간은 내머리속에 떠오른 기간보다 3배정도 늘려 잡는다.(그래야 집에가서 잘 수 있다. 단, 터무니 없는 기간을 제시하지 않는다.)
4. 지금 프로젝트를 같이 하는 사람이 웃으면서 점심도 같이 먹고 농담도 하면서 술도 마시는 사이라고 하지만 언제 내 뒤통수를 칠지 모른다. 상대에 대한 긴장을 늦추면 그 순간 프로젝트의 실패가 내 책임으로 돌아온다고 생각해야한다.
5. 프로젝트의 실패는 남의 탓이 아니라 모두의 탓이다.
6. 내가 원하는 것이 있다면 남이 원하는 것을 먼저 들어준다.(등가교환의 법칙이라고 생각하면 된다.)
7. 3번에서 말한 스케쥴보다 작업량이 많아 기간을 넘길 것 같으면 기간의 3분의 2가 지나지 않은 시점에서 먼저 이야기 한다.
8. 7번처럼 이야기 하고 기간을 조정하는 기회는 단 한번뿐이라고 생각해야한다. 두번 하면 자신의 신뢰도가 떨어지고 프로젝트 실패의 원인이 나로 지목될 수 있다.
9. 언제나 당당해야한다.(약한모습을 보이면 그저 보기좋은 먹이가 될 뿐이다. 물론, 잘못된 정보를 갖고 있을 때는 예외다.)
10. 절대 다른 사람의 업무영역을 침범하지 않느다.(예를들어 프로그래머가 디자인에 대해 왈가왈부한다던가 하는 일이다. 더 나은 대책이 없다면 왈가왈부하지 마라)
11. 사람은 악하지 않다. 다만 상황이 악하게 만들 뿐이다. 상황이 악화되지 않으려면 쌓여있는 일을 처리하는 것이 최선이다. 아무도 나의 일을 대신해주지 않는다.


p.s 돈에 관한 문제는 회사사정에 따라 다르므로 어쩔 수 없다. 이직을 하거나 협상을 잘하는 수밖에
2009/10/06 10:39 2009/10/06 10:39
TAG , , , , , ,
트랙백은 하나, 댓글 11개가 달렸습니다.
◀ 이전페이지 1 다음페이지 ▶