정말 100% 공감하는 글 입니다.
극단적인 표현일지 몰라도 . 많은 프로젝트들이 실패를 해야 한다고 생각이
듭니다.
부정적인 시각이라기 보다 현실적인 시각이죠...
프로젝트가 시작하면 이미 절반이상 실패를 했다고
생각합니다.
근거를 알 수 없는 개발공수, 복불복 개발 방법론(나만 아니면돼),
커뮤니케이션 없는 일방적 진행,무늬만 개발 총괄,
기술보단 정치가 중요한 환경등...
재난이 난 후 피해액보다 예방에 투자한 금액이 훨씬 저렴하고
안정적이란걸 깨달았으면 합니다.
쓰나미가 밀려오는 걸 알면서 피하지 않고 기다린다는게 너무 슬프군요

바늘로 찔러 고름을 짜낼것을 미루고 미루다가
10%도 안되는 성공율의 수술을 받아야 하는 상황이 된게 아닐까 싶습니다.

시나리오는 영화로 제작하지 않는한 실감하기가 쉽지 않죠.
또한 영화로 제작한다고 시나리오가 현실이 되는것도 아니고요.
삼성의 SW 성공 시나리오는 말그대로 시나리오일 뿐..

현실에서의 실질적인 대책은
역시 어느 누구도 세울 수 없는 상황인 것 같습니다.

그 동네는 해외 유학파 출신 인재들도 많은 걸로 알고 있습니다만, 선진국으로부터 배운 것들은 조직문화에 별 영향을 주지 못하는 것 같습니다. '인천공항의 기적'이라는 말도 있던데.. 주로 대학 쪽에서 쓰이던 말이지만, 업계에서도 그것은 통용되고 있지 않나 싶네요.

포스팅 잘 읽었습니다. CMMI에서도 요구사항에 대해서 요구사항을 먼저 "개발" 하고 그 다음 레벨이 요구사항 "관리"입니다. 지속적으로 요구사항이 바뀌기 때문이지요. 본문의 내용과 비슷한 맥락이라 허접 답변 남기고 갑니다. ^^

어쩌면 가장 중요한 차이점은,
요구사항이 변경되고 나서 재계산되는 시간, 비용의 차이가 아닐까 생각이 됩니다.
한국에서는 변경되도 마감일이나 비용이 변하지 않으니 말이죠..

괜히 이글에 찔리네요 ㅋ_ㅋ;;

생존력있는 사람이 오래갑니다..
님이 어려서 아직 멀..모르고 있네여...

문서가 실용적이어야 한다는 의미는 공감합니다만,

> 문서가 거의 바뀌지 않는다면 잘 작성된 것이고, 그렇지 않으면 잘 작성되지 않은 것입니다.

이 부분은 일반적인 이야기가 아니지 않나 생각됩니다. 코드는 문서보다 훨씬 빠르게 바뀌기 때문에 문서는 뒤쳐지게 되어있는데, 아마도 말씀하신 의미상으로는 문서를 이런 변화까지 수용하게 적어야 된다는 것이 아닐까 추측되는데, 그건 잘 작성된 기준으로 생각하기에는 적합한 기준이 아니지 않나 생각됩니다. 문서가 바뀌기 때문에 잘 작성하지 않았다는 것은...

또한, 다음 단계(?)의 개발자가 이를 활용할 수 있는 프로젝트가 있는 반면, 그렇지 않은 프로젝트도 많이 있기도 한 것 같습니다.

문서라 지긋지긋하지요.

정말 돈받고 만드는 프로덕트로서의 문서들은 가끔 종이값과 타이핑값을 받기 위해 만드는거 아닐까 하는 생각이 들곤 합니다. 그래서 도큐멘트도 아니고 산출물이라고 하는게 아닐까 생각하죠. ^^

SI성 프로젝트를 많이 하다보니 몇십종의 산출물들이 과연 필요나 할까 싶을떄가 많기도 하고, 왜 보지도 않고 쓸데도 없는 문서를 주구줄창 만들어야 할까 싶습니다.

경험적으로 생각해보면 산출물은 의사전달을 위한 문서, 생각을 정리하기 위한 문서, 점검을 위한 문서 세종류가 있는 것 갑습니다. (그냥 제 기준입니다.)

무엇을 위해서 작성을 하는지가 중요한 것 같은데.. 문서 프레임에 압도당할때가 만은데요. 잘하지는 못하지만 고객이나 내부 팀원이 쓸 수 있을 만한 표현력이 들어가면 문서의 프레임이야 얼마든지 고칠 수 있지 않나 싶네요. ㅎㅎ

뭐 항상 만들고 나면 이것 저것 한방에 보고 싶다는 욕심에 덕지덕지 붙여넣다가
질려서 흐지부지 되는 경향이 있어서.

될 수 있으면 간략한게 좋지 않나 생각이 드네요.

특히나 고객의 요구사항이 수시로 변할떄는 말이죠.

맨위에 도표를 보고 생각보다 많이 쓴다고 생각했었는데...;;
저희회사도 이제막 도입을 검토중이거든요..
프로젝트에 적용할려면 또 얼마나 걸릴지 모르겠지만;;
늦게나마 도입하려는 시도가 보인다는것만으로도 감사하다고 해야할까요 ㅎㅎ;
그나저나 RSS보다 블코 위젯 메인에뜬걸 보고 들어오다니;; 축하드립니다 ^^

팀에서 개발경험없는 소프트웨어 공학을 전공한 석/박사님들과 충돌을 많이했습니다. 학교에서 배우지 못하는 학문이라서 그랬을까요? ^^;
앞으로 올라올 포스팅이 기대되네요... 저도 많은 의견 올리겠습니다. ^,.^;

제 trackback에 있어서 타고 왔더니 정말 좋은 글이 있군요;ㅁ;
금일 다음 클릭애드클릭스 블로그 선정이 안되어서 우울했는데..
정리의 진수를 보여주시는군요..잘보고 갑니다^0^/

트랙백 있길래 와봣습니다.
참 좋은 내용은 많네용..
흠..소프트웨어 공학..학교때 배워도.어찌보면...그때는 아하 그랫어도 실상 개발자로 살아가다보면 간과 하게되죵..역으로 다시 서적을 통해 보고 있습니다.
잘 보고 갑니다.

그렇다면 '공학'이란 말을 빼야겠네요. ^^

음...저는 학교에서 배울때 소공의 목적이 요즘은 빨리 만드는것보다는 유지보수가 용이하게 잘 만드는 추세로 간다고 들었던 것 같은데, 뭐가 맞는 걸까요? 연구실파는 아니셨는데요...ㅡ.ㅡ;;

녹차프린스님의 글부터 시작해서 트랙백을 따라서 여기까지 왔습니다.
알찬 글들이 많이 있네요.
잘 읽고 갑니다. 구독링크하고 자주 방문하겠습니다. ^^*

자율에 의해 버그가 잘 처리 되고 개발자가 자기 모듈에서 버그가 발생된다면 해당 개발자가 맡아 주는 것이 좋겠죠? 그러나 버그 리포트만 보고 어느 모듈에서 버그가 있는지 알기 어려울때가 있고 또 이전 모듈을 담당한 개발자가 더이상 일하지 않을수도 있고, 우리의 관리자가 개발자의 이름을 다 기억 못할수도 있고 등등등. 이럴때 이전 버그 할당한 히스코리나 버그의 증상을 바탕으로 버그 트래킹 시스템이 자동으로 이 버그를 픽스할만한 후보를 3명 정도 찝어 준다면 어떨까요? 물론 이 3명을 정확하게 찝어줘야 겠지만.

테스트팀이 개발 설계때 부터 투입되고 개발과 테스트관련 작업?이 같이 진행되면 Bug를 발견한 테스터가 직접 개발자를 Assign해도 좋다고 생각합니다. 물론 그 만큼 개발과 테스트가 유기적으로 진행되고 있어야하겠지요. 개발자와 1:1로 개발, 테스트를 진행했었는데 이게 가장 효율적이었습니다.
즉, 현재 조직 상황과 프로세스에 따라 다르게 적용되어야 한다고 생각합니다. 프로세스 성숙도와 규모에 따라 적용하는 것이 달라지겠지요.
Clear Quest를 사용하면서 큰 틀은 함께하면서 팀마다 다른 스키마를 적용했었습니다.

관리자 및 개발자의 성숙한 소프트웨어 개발 프로세스 문화 뿐 아니라 QA팀에서의 Report도 많은 비중을 차지할 것 같습니다.
일단 버그의 담당자를 지정하기 위한 자료는 Issue Report 가 전부이기 때문이죠.
그리고 Stracking System을 Product별로 커스터마이징 해서 킥 오프 단계에서 각 개발 컴포넌트와 그 담당자를 매칭해 주고 자동 Assign 하면서 이 관계를 지속적으로 업데이트하는 방법도 효율적일 것 같습니다.
(가능한 Tracking System 및 양질의 Issue Report, 모든 부서의 원활한 커뮤니케이션이 선행되어야 하는... 어려운(...?!?!?!) 점이 있겠지만요.)

이상적인 환경이네요. 아웃소싱, SI 업계에서는 조건부터 잘못되서 적용이 안될거 같고, 금융 또는 IT 대기업 사내 소프트웨어 연구실 정도면 어느정도 현실화 될지도. 아마 괜찮은 회사에서는 벌써 적용될지도 몰르고. 그러나, 99% 개발자에겐 그림의 떡일듯. 불쌍한 우리회사 개발자들..
실력있는 개발자 같으신데 기회가 되면 창업한번 해보세요. 다양한 경험을 통해 좀더 현실적인 답을 찾아내시길~

붉은칼님 안녕하세요.
우선 밝혀둘 것이 있습니다. 저는 소프트웨어 개발컨설턴트로서 대한민국의 어떠한 개발자와 비교해도 부족하지 않은 개발 및 컨설팅의 지식과 경험이 있습니다. 수백만명이 쓰는 제품, 전세계인이 쓰는 제품, SI등 다양한 분야의 경험을 풍부하게 다 가지고 있습니다. 제가 쓰는 글들은 모두 경험에서 나온 글들입니다. 또한 저희 펌에서는 한국과 미국에서의 20년이상의 소프트웨어 개발에 대한 다양한 노하우를 가지고 있습니다. 그냥 단순히 보고 들은 내용을 옮기는 것으로 오해하지 마시길 바랍니다.

제가 컨설팅을 하면서 만난 거의 모든 회사는 "우리회사는 다르다"라고 합니다. SI다, 금융이다. 이유는 많지만 사실을 다 똑같습니다. 원리는 같다는 얘기입니다. 99%의 개발자에게 그림의 떡이 아니고 99%의 개발자에게 가능하고 그래야 더 품질이 좋은 제품이 개발되고 회사의 경쟁력이 더 높아집니다.
8시간 근무를 하는 이유도 더 개발을 잘하고 빨리 하기 위해서임을 명심해주시면 좋을 것 같습니다. 잘 이해가 안되면 붉은칼님에게는 정말 좋은 기회인 것 같습니다. 소프트웨어 엔지니어링이 가져올 좋은 개발환경에 대해서 앞으로 제 블로그를 지속적으로 관심을 가지고 봐주세요. 점점 더 구체적인 글들을 작성해 나갈 겁니다.
감사합니다.

미국의 개발자들은 야근을 안하는가? 하는 오해가 있을 수 있습니다. 미국의 개발자들도 야근을 많이 하기로 유명합니다. 하지만 우리와는 경우가 좀 다릅니다. 대부분 체계적으로 개발을 하는데도 야근을 많이 하는 거죠. 특히 MS는 야근을 많이하고 그만큼 많이 보상해주죠. 많이주고 많이 뽑아먹기로 유명합니다.

정말 공감이 가는 글입니다. 이 글은 경영자 필독입니다.

좋은 말씀 잘 보고 갑니다. 선택할 위치에 있는 분들의 뿌리깊은 잘못된 사고방식이 합리적으로 바뀌었으면 좋겠는데, 개발자 출신의 관리자들도 똑같은 생각은 가지신 분들이 많으니 요원한 일로 보이기도 합니다. 하지만 점점 좋아지겠죠? ^^

뭐 워낙 대단한분들이 모이신거 같은데 읽다가 저도 생각을 한줄 표현할까 해서 올립니다만...
환경이 열악한건 사실이죠..근데 환경이 언젠가는 좋아지겠지라는 생각과 그런날이 올까? 라는 생각이 주를 이루는데요...?너무 환경탓을 하기 보다는 자신에게 주어진 환경을 자기가 만들어 갈수 있다는 생각을 가지는것이 중요하다고 생각합니다. 저도 적지않은SI 경험을 가지고 있지만...SI하면서도 일빨리 끝내고 일찍가는 개발자 많고요... 일잘하면 요새는 관리자도 특별히 근태 터치 안합니다.물론 기본적 근태는 지켜줘야죠 9시 출근 6~7시 퇴근 그러다가 일주일에 한두번정도는 8~9시 퇴근 이정도면 처자식과 가정생활 하면서도 충분히 SI에서도 개발자로 생활 가능하다고 보는데요..

실제로 이런 마인드로 힘들어져 가는 회사를 겪어봐서 그런지 더욱 와닿는 글이네요.

전적으로 동감합니다.
아직까지도, 소프트웨어에 제 값 안주고, 하드웨어의 서비스처럼 생각하는 동네도 있습니다.
슬픈 현실입니다.

어제 밤에 우연히 이곳을 발견했습니다.
도움되는 글이 많아서, 오늘 하루를 몽땅 투자해서 처음부터 읽고 있습니다.
좋은 글 감사합니다.

이건 우리나라의 특수성에서도 기인하는 것 같습니다.

미수다였나? 어디선가 외국인이 우리나라 오면 신기해하는 것중 하나가 "어디를 가도 사람 없는 곳이 없다."라는 것이었습니다.

인구밀도가 워낙 높아서, 아파트를 선호하고, 인구밀도가 높으니 네트워크를 설치할 때도 비용이 상대적으로 저렴하죠. 그러니 초고속 인터넷 보급률도 높았죠. 소프트웨어 산업도 비슷한 맥락이 아닐까 합니다. 인력은 넘쳐나니(업무능력은 논외), 손쉬운 대안이 되는 것이고, 개발자는 개발자 나름대로 자기 노하우를 다 쏟아놓으면 토사구팽될까 두려워하고. 뭐, 이런 것 아닐까요?