2007년 11월 29일
개발 프로세스를 공부하니, 팀장님이 무능해 보입니까?
개발 프로세스를 공부한 신입사원(경력3년 까지)들은 팀장을 우습게 보는 경향이 있습니다.
여기에서 개발 프로세스는 개발 방법론, 개발 관리, 프로세스 개선 등을 이야기 하는데요.
애자일 프로세스(XP, 스크럼...등)나 방법론(RUP 등)를 비롯하여 프로젝트 관리(PMBOK, PRINCE...등)와
프로세스 개선(CMMI, SPICE...등)을 이야기 합니다.
일종의 프로세스 품질(Process Quality)을 다루는 관리/경영(Management) 분야(Domain)들이죠.

이러한 경향을 "신입사원들"에 국한한 것은, 충분한 경험이 있는 사람의 경륜을 존중하는 것일뿐,
사실, 개발 프로세스를 처음 공부하는 사람이라면 누구나 윗사람을 향해서 이러한 경향을 보일 수 있습니다.
하지만, 여러분들의 팀장님들은 실제로 무능하지 않습니다.
물론 무능하고 한심한 팀장도 있죠. (제가 아는 팀장님중에도 그런분이 있습니다) 이런 사람들은 논외로 두고...
열심히 개발하고 일하는 대부분의 경륜있는 팀장님들은 여러분의 생각처럼 무능하지 않답니다.
개발 프로세스 초심자들이 항상 잘못 생각하는것이 '품질'입니다.
개발 프로세스는 제품(솔루션)의 품질을 보장해 주지 않습니다. 심지어는 제어도 하지 못하죠.
그럼에도 불구하고, 많은 초심자들이, 자신이 접한 프로세스 사상에 자극받고 엔돌핀에 중독되어
무작정 프로세스에 주변을 끼워 맞추고, 그에 맞지 않는 것들을 무능히 여깁니다.
지극히 경계해야 될 부분입니다.
개발 프로세스는 제품(솔루션)의 품질과 밀접한 관계가 있을 뿐 동일하지 않습니다.
높은 프로세스 품질이 높은 품질의 제품을 만들어 주지 않습니다.
높은 품질의 제품을 만들수 있는 가능성을 높여주고 그에 전념할 수 있는 기반을 제공해 줄 뿐입니다.
개발 프로세스를 공부하니, 팀장이 무능해 보이십니까?
아마 그 분은 무능하지 않을 것입니다.
단지, 제품의 품질에 집중하고 프로세스는 잘 모를 뿐입니다.
오랜시간 몸에 경험으로 쌓아온 그들의 암묵지를 배우세요.
어짜피 개발 프로세스는 제품에 종속됩니다.

여기에서 개발 프로세스는 개발 방법론, 개발 관리, 프로세스 개선 등을 이야기 하는데요.
애자일 프로세스(XP, 스크럼...등)나 방법론(RUP 등)를 비롯하여 프로젝트 관리(PMBOK, PRINCE...등)와
프로세스 개선(CMMI, SPICE...등)을 이야기 합니다.
일종의 프로세스 품질(Process Quality)을 다루는 관리/경영(Management) 분야(Domain)들이죠.

이러한 경향을 "신입사원들"에 국한한 것은, 충분한 경험이 있는 사람의 경륜을 존중하는 것일뿐,
사실, 개발 프로세스를 처음 공부하는 사람이라면 누구나 윗사람을 향해서 이러한 경향을 보일 수 있습니다.
팀장이 지금 하는 프로젝트 관리는 엉망진창이야.
개발을 저런 방법으로 진행하면 결과는 불 보듯 뻔해.
우리 조직의 프로세스는 말도안되고 허접해.
하지만, 여러분들의 팀장님들은 실제로 무능하지 않습니다.
물론 무능하고 한심한 팀장도 있죠. (제가 아는 팀장님중에도 그런분이 있습니다) 이런 사람들은 논외로 두고...
열심히 개발하고 일하는 대부분의 경륜있는 팀장님들은 여러분의 생각처럼 무능하지 않답니다.
개발 프로세스 초심자들이 항상 잘못 생각하는것이 '품질'입니다.
개발 프로세스는 제품(솔루션)의 품질을 보장해 주지 않습니다. 심지어는 제어도 하지 못하죠.
그럼에도 불구하고, 많은 초심자들이, 자신이 접한 프로세스 사상에 자극받고 엔돌핀에 중독되어
무작정 프로세스에 주변을 끼워 맞추고, 그에 맞지 않는 것들을 무능히 여깁니다.
지극히 경계해야 될 부분입니다.
개발 프로세스는 제품(솔루션)의 품질과 밀접한 관계가 있을 뿐 동일하지 않습니다.
높은 프로세스 품질이 높은 품질의 제품을 만들어 주지 않습니다.
높은 품질의 제품을 만들수 있는 가능성을 높여주고 그에 전념할 수 있는 기반을 제공해 줄 뿐입니다.
개발 프로세스를 공부하니, 팀장이 무능해 보이십니까?
아마 그 분은 무능하지 않을 것입니다.
단지, 제품의 품질에 집중하고 프로세스는 잘 모를 뿐입니다.
오랜시간 몸에 경험으로 쌓아온 그들의 암묵지를 배우세요.
어짜피 개발 프로세스는 제품에 종속됩니다.
이 글과 관련있는 글을 자동검색한 결과입니다 [?]
- 개발 환경을 개선시키는 재미있는 아이디어 하나. by YUZI
- 스크럼의 핵심, 코칭. by YUZI
- [저작권과 자유문화] 크리에이티브 커먼스 by 캐시
- Team//Cider vol 2. - Underground by tyBack
- 끝까지 희망을 버리지 않는 것도 중요합니다. by YUZI
# by | 2007/11/29 14:02 | IT 단상 | 트랙백 | 덧글(12)





☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
공감한표 감사합니다~ 블로그가 특이하시더군요. 헤메다 돌와왔습니다.
하지만, Lead 개발자가 따로있는 조직이라면? (응?)
저 또한 우리 PM을 존경한답니다~ ^^
to epiphany/
조직과 프로젝트의 성격과 형태에 따라 많이 다르죠. (응?)
다만 조직문화 이해나 커뮤니케이션 등 조직공학 스킬이 부족할 뿐 ...
제가 일반론을 잘 모르네요 ^^)a 그래도~ 공감합니다~
하지만,
조직문화 이해나 커뮤니케이션 등 조직공학 스킬등이 개발 능력보다 더 중요한 능력이라고 생각드네요.
하지만 하시려는 말씀에는 동의합니다. PM 은 두가지를 모두 봐야 하기 때문에 신입의 경우 제품자체보다는 자기가 아는 지식에 의존하기 때문이죠... 제 생각에는요. ^^
블로그에 놀러가보니 관심사가 비슷하네요~ 반갑습니다.
동의하지 못하는 부분이 가장 마지막 구문을 말씀하시는것 같은데요.
프로세스 품질이 제품 품질에 포함된다는 의미가 아닙니다. 제품에 포함된다는 의미로써, 제품을 빼고서 프로세스 및 품질을 논할수 없다는 것을 강조하기 위한 문구였습니다. 가끔(자주) 프로세스 자체만 신봉하는 사람이 있거든요. ㅎㅎ
그러나, 개발 프로세스에 대해서 고민하고, 올바르게 정립하고자 하는 노력에 좌우 되지 않을까요?
대부분 관행처럼 굳어진 개발 방법론이 합리적이라고 생각이 되는지 깊이 고민을 해보고, 올바른 길을 찾아나가야 된다고 생각합니다. 일반 SI프로젝트의 개발 방법론과 연구개발형 개발방법론 대한 차이와 개발 프로세스 과정중에 불필요한 중복과 무의미한 프로세스를 걸러내는 데 많이 노력이 필요하다고 봅니다.
나름대로 방법론이 우리 제품을 만들기에 충분하다면 그걸로 충분할 수 있습니다.
저도 제품을 만드는데 필요성을 느끼지 못하는 프로세스를 거쳐는데 불만이 많은 편입니다.
현재의 프로세스랑 항상 100%의 품질을 달성하고 있다면 프로세스를 명문화만 시켜놓으면 끝입니다.
그렇다고 프로세스라는걸 폄하해서는 안된다고 봅니다.
더이상 고민할 게 없으면 확정짓고 넘어가면 되는건지 제품에 종속적인 것이라 생각하고 지나치는 건 좋지 않다고 봅니다.
복잡하고 화려한 걸 쫓기보다는 우리에겐 이게 적합해 라고 소박하지만 명확하게 정의해줄 수 있는 태도가 필요한 거죠.
신참이 뭘 안다고? 이런 태도에 대해서 많이 경계해야 한다고 생각합니다.
어려운 것도 쉽게 설명해 줄 수 있는 것이 진정한 고수 입니다.
고참의 귀차니즘 일 수도 있을거고, 여러 상황이 있겠지만
프로세스는 좋은 제품을 만드는 원동력이 되는 소중한 무형의 자산이라는 인식이 있었으면 합니다.
지당한 말씀이십니다~ 저 또한 프로세스 개선에 촛점을 둔 방법론자랍니다.
이 포스트는, Product 품질과 Process 품질을 혼동하는 초심자들을 대상으로 충고하는 내용입니다.