병풍
- 국어사전 정의
[명사]
 바람을 막거나 무엇을 가리거나 또는 장식용으로 방 안에 치는 물건.
[북한어]
음흉한 목적을 가리기 위하여 쓰는 수단을 비유적으로 이르는 말.

- 오픈사전 정의
[명사]
 별 존재감 없는 사람을 가리키는 신조어.

- 이 동네 정의
[동사] 병풍치다.
 사고를 친 사람에게 여러 사람이 뒤에 달라 붙어 있는 "뭐가 문제야"를 반복하는 상태.


사고 한번 쳐보면 안다. 뒤에 병풍친 느낌이 어떤 느낌인지.
두 번 다시 겪어보고 싶지 않은 경험이다.

뭘 더 써야 할까 썼다 지웠다 반복하다. 남길 말은 이거 밖에 없다.

"좀 더 신중히 행동하자."

천성이 게을러먹어 그런건지 일을 쌓아놓는 스타일이다.
일이 생기면..(급한게 아니면) 일단 쌓아놓고 논다..(뭐 마냥 놀기만하는건 아니고 소스도 좀 훑어보고 디비도 끄적거리고 서버들어가서 뒤적뒤적 그렇게 시간 때운다.)
그러다가 어느날 갑자기 일이나 해볼까 하고 시작하면 미친듯이 일만 한다. 집중될 때만 일한다.
맨날 이렇게 집중해서 일할 수 있다면 얼마나 좋겠냐먀는 그렇지 않은게 현실(이렇게 말하지만 현실은 핑계)

그닥 좋은 습관은 아닌데 그래도 여태까지 크게 일을 빵구낸적은 없으니 그거하나 맘에 위로를 삼는다.
이렇게 일하게 된 원인을 가만 보니 내가 했던 일들이 대부분 다른 영역과 관계없이 독립적으로 동작하는 모듈개발이 대부분이었다.
두번째로는.. 아직은 말단인 나에게 order를 내려주는 사람은 있으나.. 체크하는 사람이 없다. 일단 order가 떨어지면 일단 나는 검토해보겠습니다. 하고 자리에 앉는다.. 그리고는 한 반나절 이면지에 그림 그려가면서 어느정도 일정이 나올지 계산해보고 보고한다. 대부분은 그대로 가는데 그 중간에 날 터치하는 사람이 없다.
좋게 보면 믿어주는거고, 나쁘게 보면 날 버려두는거다.

이야기가 딴데로 샜다.

일을 쌓아놓는 버릇에 대한 변명아닌 변명을 하자면 개발이건 어떤 일이던간에 그 일을 처리하는데 절대적으로 필요한 시간이 있다. 막상 일시작하고 열혈모드로 키보드를 두드리는 시간이 10시간이라고 하면 실제로 그일은 최소 50시간의 시간이 필요한 일이다.
그럼 나머지 40시간은 어디갔냐.. 일단 시작할때 그림그려가며 개념잡고 레거시가 있으면 소스도 좀 보고.. 디비 레이아웃도 보고 하는데 몇시간 잡아먹고 설계하는데도 시간이 절반정도 그럼 나머지 20시간은 ???

숙성..
일을 시작하고 파악하고 분석해서 설계하고 그대로 바로 개발에 들어가면 경험상 항상 탈이 났다. 원인은 설계시에 빼먹은 부분들이 꼭 있었다. 그런데 설계와 개발 사이에 텀이 좀 있으면 이런일이 좀 줄어든다.
이걸 난 정보의 숙성이라 부른다. (거창하지 않은가)

일을 쌓아놓는건 결국 저런 숙성과정인거다. 이런 생각을 확고하게 된 계기는 마크 헌트의 실용주의 사고와 학습 이란 책을 보면서였다. 인간의 뇌는 정보를 처리모드가 직관적이고 비선형적인 모드와 계산적이고 선형적인 모드로 나뉜다.(흔하게는 좌뇌/우뇌 이렇게 부르기도 함)
어쨌건 이런 기간동안에 '아!' 하고 뭔가 떠오를 때가 있다. 이게 숙성에 핵심이다.

그런데 하나 중요한건 숙성기간에 그냥 놀아재끼면 다 까먹는다. 그럼 그건 숙성이 아니라 망각이 되버린다. 가끔씩 안까먹게 refresh 해줘야 된다.

그럼 refresh는 어떻게 하는가?
1. 가끔 심심하면.. 이면지에 첨 끄적거렸던거 다시 한번 본다.
2. to-do list를 작성한다.. 그리고 다시 접어둔다.
3. 상상한다. (뭐든 좋다 그 일에 대한 어떠한 상상도 좋다.)

이런 방식으로 처리할 만한 일거리에 분량은 경험상 짧게는 3~4일에서 길게는 2~3주 정도 걸리는 일들에 적당하다. 하루 이틀 걸리는 일들을 이렇게 해버리면.. 욕 좀 먹겠지??
일이란게 한번에 하나만 처리하는게 아니니 버닝모드로 들어가는 스케쥴만 잘 맞추면 이 방법이 나한테 잘 맞는것 같다.

ps. 일하는게 먹는것도 아니고 숙성에다 비유를... 거참 일안하고 노는 핑계 한번 거창하다.ㅋㅋㅋㅋ
     그러면서 지금도 놀고 있다.(근데 주말에 출근해서 뭐하는거냐..)

내가 겪은 프로젝트.. 또 내가 가까이 볼 수 있었던 다른 프로젝트 중에 최초 예상했던 오픈일에 오픈한 프로젝트를 한번도 본적이 없다.

짧게는 2~3주. 길게는 1년, 한두달 정도 오픈이 연기되는건 성공한 축에 속한다.
원래 IT프로젝트의 속성이라고 하기에는 뭔가 문제가 있지 않나 싶다.
답을 알면.. 남들은 바보도 아니고 왜 그렇게 안했을까..
서점에만 가도 프로젝트 관리에 대한 수많은 책들이 보인다. 최근에는 그런 서적의 종류가 배로 늘어난 느낌이다.
번역서의 종류도 많이 늘어난 느낌이 든다.
뭐 그책들을 다 보지는 못했지만 대채적으로 프로젝트 실패 혹은 연기의 주요 원인으로

1. 초기의 분석/설계의 미흡으로 인해 개발/테스트 단계에 문제가 생기는 경우
2. 각 개별 파트간의 커뮤니케이션 부재
3. 관리자의 관리능력 부재
4. 설계/개발자의 시스탬의 이해 부족

뭐 대충 이런 이야기들을 한다.

아닌걸 알면서 왜 그렇게 갈까?
내 경험을 비추어보면 내쪽일이 복잡해진 경우는 분석/설계단계에서.. 요구사항이 다 안나왔다.
그게 다인줄 알았는데 개발하다 보니 조금 꼬인 케이스도 있었다. 뭐 이건 큰 구조변경이 없어서 다행이었지만
요구사항이 추가되는데... 기존의 설계를 우회하거나 뒤엎어야 하는 케이스도 있었다.
이런걸 미리 알고 설계에 반영할 수는 없나?
개발 모델이 폭포수라 그런거다 라고 이야기 할 수도 있겠지만..  내생각에는 그보다는 근본적인 문제가 있다.

어떠한 개발모델이던 프로젝트에 적용이 되려면 그 개발모델이 이상적인 모델의 장점을 프로젝트에 최대한 적용할 수 있는 방안과 해당 모델의 문제점을 파악해서 보충할 방법을 찾아놔야 한다.
개발모델만 가지고 프로젝트가 진행되는 것은 아니지만.. 그런 모델들에서 진행상에 발생할 난제들을 예측하는 것도 능력이다.

그런데 경험상 이런 개발모델이나 방법론이 프로젝트의 성공여부에 미치는 영향은 그닥 많지 않다.
원래 그런 모델이나 방법론 자체가 말만가지고 노는(?? 오해의 소지가 있을 수 있다..) 동네다 보니 누가 봐도 그럴싸 해보인다. 그리고 요즘나오는 프로젝트에서 이야기하는 방법론들은 상식적으로 뭔가에 크게 벗어나는 게 별로 안보인다.(개인적인 생각일런지 모른다.)

제일 문제는 프로젝트를 진행하고 있는 사람들의 시스템 혹은 결과, 목표에 대한 이해가 조금씩 다르다.
고객은 자신이 원하는 것을 뒤늣게 빼먹고 이야기 하는 경우 개발자 입장에선.. 저런...~~~~~ 이래버리고
역으로 고객은 당연히 되는거 아냐? 왜안되는데? 이런식으로 나오면.. 백이면 백 프로젝트 망한다.

적어도 이런 프로젝트를 하는 사람들이라면.. 개발자건 고객이건 컨설팅을 하는 사람이건 모두가 그 프로젝트가 원하는 큰 그림은 알고 있어야 한다고 생각한다.
결국 프로젝트의 구성원 모두 같은 모양의 결과물을 바라보고 있어야 한다.
그리고 그 단계가 프로젝트의 시작단계, 즉 요건분석/설계단계에는 완료되어야 한다.
이거 자체가 쉬운일이 아니다. 어쩌면 불가능한 일일지도 모른다. 지금까지 인류의 역사자체가 저랬던 적이 흔치 않기에 오히려 당연하게 보일런지도 모르겠다.
프로젝트를 리딩하는 사람들에게 가장 중요한 목적이 아마도 이게 아닌가 싶다.

IT라는 것 자체가 원래 IT자체를 위해 발생한 기술이 아니다. IT이외의 현실세계에서 필요한 작업들을 처리하기 위해 발생한 기술이다. 그 목적이 군사적이건, 경제적이건 어떠한 목적이건간에.
소프트웨어라는 말을 쓴지도 대략 50~60년은 되었지만 다른 분야에 비하면 그 역사가 턱없이 짧지 않나 생각한다. 무슨 책에서 아직 소프트웨어 공학은 공학이라고 불릴만큼 성숙한 분야가 아니라고 했다. 미국 어디주에서는 IT쪽에 기술자.. 그러니까 엔지니어라는 공식적인 직함?을 부여하는데 부정적인지 불법이라고 했는지 그런 이야기를 본적이 있다.

어쨌건 IT관련 프로젝트는 아직도 활발히(?)진행 중이며 원래의 공정기간을 맞추지는 못했더라도 테스트 후 큰 문제가 없으면 그 시스템은 오픈하기 마련이고 우리는 그 시스템들을 잘(???) 어쨌건 이용하고 있다.

주저리 말이 많아졌는데.. 결론은 과정에 문제가 있어 지연되었지만 결과적으로 쓰고 있는 시스템이다.. 그러니 그 과정을 줄일 여지가 남아있다.
그 여지 중 하나가 프로젝트 구성원들이 프로젝트 초기에 같은 목표.. 같은 그림을 바라보고 있어야 한다. 끝..(다 아는 얘기만 한듯..)