흔히 프로그래머가 야근많이하는 직업이라고 많이들 하더구려 그러나 소햏은 그렇게 보지 않는다오 야근의 원인이 무었이라 보시오? 가장 결정적인 문제는 프로젝트의 정량화가 안된다는 점이라오 이 프로젝트가 어느정도의 양이고 이런걸 얼마만에 만들수 있는가를 알아야 기간예측이 된다오 뭐 방법론이나 개발문서의 종류는 정말 엄청나게 많소이다만 귀햏의 회사는 이런것에 얼마나 신경쓰는지 한번 보시기를 바라오 소햏의 경우 과거 정통부 발주 프로젝트에서 문서만들다보니 그게 정말 엄청난 도움이 되는구려 그런탓에 요즘은 설계와 문서화에 신경쓰는 프로젝트 위주로 가오 야근하는 기간이 확실히 줄더구려 뭐 혼자서 개발하는 분이라 하더라도 UML이나 개발방법론 보면서 나름대로 문서화에 신경써 보시기를 바라오 소스주석 + 프로세스 흐름도 + ERD 정도만 있어도 상당한 도움이 된다오 특히 프로세스 흐름도에 신경쓰시길 바라오 하라는 대로 테이블 명세서 하나 달랑 짜고 나중에 보면 황당할때가 많다오 코드 컬럼은 있는데 코드의 본테이블은 어디에 있지? 라든지 워드로 오만 요상한 표로 만들어 고칠려면 테이블이 깨져서 문서 다듬느라 시간이 간다던지 이런경험들은 있으실게요 물론 70몇개의 컬럼에 한줄의 설명도 없는 개념없는 대기업 DB도 만나보실날 올게요 그래도 나름대로 정리할려고 해보시오 ERD그리기 귀챤으면 토드로 리버스 엔지니어링 걸어내도 되고 종이에 프로세스흐름도 끄적대도 좋소 일단 문서로 만들어 봅시다. 나중에 나도 못알아 보거나 말거나
흔히 프로그래머가 야근많이하는 직업이라고 많이들 하더구려 그러나 소햏은 그렇게 보지 않는다오 야근의 원인이 무었이라 보시오? 가장 결정적인 문제는 프로젝트의 정량화가 안된다는 점이라오 이 프로젝트가 어느정도의 양이고 이런걸 얼마만에 만들수 있는가를 알아야 기간예측이 된다오 뭐 방법론이나 개발문서의 종류는 정말 엄청나게 많소이다만 귀햏의 회사는 이런것에 얼마나 신경쓰는지 한번 보시기를 바라오 소햏의 경우 과거 정통부 발주 프로젝트에서 문서만들다보니 그게 정말 엄청난 도움이 되는구려 그런탓에 요즘은 설계와 문서화에 신경쓰는 프로젝트 위주로 가오 야근하는 기간이 확실히 줄더구려 뭐 혼자서 개발하는 분이라 하더라도 UML이나 개발방법론 보면서 나름대로 문서화에 신경써 보시기를 바라오 소스주석 + 프로세스 흐름도 + ERD 정도만 있어도 상당한 도움이 된다오 특히 프로세스 흐름도에 신경쓰시길 바라오 하라는 대로 테이블 명세서 하나 달랑 짜고 나중에 보면 황당할때가 많다오 코드 컬럼은 있는데 코드의 본테이블은 어디에 있지? 라든지 워드로 오만 요상한 표로 만들어 고칠려면 테이블이 깨져서 문서 다듬느라 시간이 간다던지 이런경험들은 있으실게요 물론 70몇개의 컬럼에 한줄의 설명도 없는 개념없는 대기업 DB도 만나보실날 올게요 그래도 나름대로 정리할려고 해보시오 ERD그리기 귀챤으면 토드로 리버스 엔지니어링 걸어내도 되고 종이에 프로세스흐름도 끄적대도 좋소 일단 문서로 만들어 봅시다. 나중에 나도 못알아 보거나 말거나
회의 들어갈때 직접 회의록쓰는것도 중요하오 그리고 그 회의록 메일로 담당자에게 안기시오 나중에 고치자는 소리하면 인상팍쓰고 회의록에서 애기한건 뭐냐고 따지시오 두서너번 하면 절대 만만하게 안본다오
소햏 초짜인데, 요즘들어서 문서화작업을 배우기 시작했소, 다들 익숙해지면 엄청 좋다던데 믿고 따라가기로 했소-
정통부 규격 문서화 작업은 ㄷㄷㄷ 이라고 생각하오.. 넘흐 지나치게 많소.. MSF/CD방법론도 나쁘진 않다고 생각하오..(MS에서 곧 버린다고 하더이다 만은.) 정통부 국가프로젝트에서 쓰는 문서화 폼은... 하여튼 ㄷㄷㄷ이오..
정통부껄로 하려면 팍 줄여서 과감히 많은 부분 생략하는게 더 도움이 될꺼라 생각되오..
정량화 시키면 뭐하오..=_= 이사가 찌질이라 뒤집는대.=_=
다 좋다 이거야 야근 안하는 회사 있으면 소개좀 ^^: