개발이 배보다 배꼽이 과도하게 더커지는 현상.
글쓴이: ㅡ,.ㅡ;; / 작성시간: 금, 2007/02/09 - 6:11오후
사람마다 다같진 않겠지만..
날이 갈수록 심해지는것같군요..
개발이 배보다 배꼽이 과도하게 커지는경우... 어차피 한정된시간으로 원하는데로 해주는것이지만...
아무리 생각해도..좀...
한달 개발분량이 전혀 과장됨없이 한나절이면 충분한경우가 많습니다. 아주특별한경우는 2~3일이면 충분합니다.
그런데...문서관련및 그에 관련된여타 잡무가 3주이상을 차지 하네요...
이미 개발관리를 위한목적보다 현재의 문서관련이나 작업이나 기타 업무환경 파악하기가 훨씬힘든상태죠..
과연 옳다고 할수 있을것인가...
과연 무엇을 위해 개발보다 3000%가 넘는 추가비용을 들이고 있는가..
Forums:
하긴 개발 프로젝트 시작과 끝은...
수십페이지에 달하는 계획보고서와 결과보고서죠...
사실 만들어낸 작품과는 관련이래봐야 눈꼽만큼밖에 없고.. 그 자체도 전혀 의미도 없는...
그래서 전 요즘 이런 의미없는 보고서를 볼때마다 내가 왜 이일을 하는가에 대한 회의감을 느낍니다..
===========================================
니네 군대에서 멀쩡한 몸으로 18시간 자봤어? ㅋㅋㅋ
---------------------------------------------------------------
폐인이 되자 (/ㅂ/)
SE 시간
하루 개발 코드량이 5줄이면 된다는 말이 생각 나더군요;;
나머지는 문서 만들고 유지 보수하고;; 쩝접;;
둘중 하나죠
1. 정말 할짓 없는 놈들이 하는 삽질이다.
2. 이 소스가 장기적으로 연속성있게 유지되길 바란다. - 이것은 어찌보면 소스를 중요시 하는것이 아니라 해당 소스로부터 나올 결과물에 대한 지속성 유지라는 측면이 강합니다. 일명 호환성 및 유지보수 편의를 위한 것이지요.
2번이라면 그냥 열심히 하시면 됩니다.
====================여기부터 식은어치====================
안녕하세요. 저는 야동 초등학교 2학년 6반 11번입니다!! 제 컴퓨터에 리눅스를 깔아보고 싶습니다. 리눅스라는건 어제 처음 들어 보았습니다.
리눅스에서도 카트라이더는 되겠지요? 설마 안되나요? 안되면 왜 쓰나요? =3=33 리눅스에서는 카트라이더 캐릭터 머리가 너무 커서 못받아들이나요?
어떻게 A 를 쉽게
어떻게 A 를 쉽게 파악하고자 만든 도구나 방법따위의 B가
A보다 B를 만들거나 파악하는데 걸리는 시간이 몇십배가 더들어가는지...
가만 생각해보면.. 도무지 이해할수 없는 일들이 너무나 당연하다는듯이... 계속되네요...
----------------------------------------------------------------------------
C Library Development Project
----------------------------------------------------------------------------
혼자 만들고 계속 유지보수할 것이 아니라면
상세한 문서화는 기본도 아닌 기초가 아닐까요.
짧게는 몇달에서 길게는 몇년,
더 길게는 10년 이후에 그 만들어 놓은 것을 다른 사람이 유지보수를 할 일이 안생긴다고 장담할 수 없을테니까요.
"아마 많은 시간을
"아마 많은 시간을 투자해서 문서작성을 했으니 매우자세하고 훨씬 쉬울것이다.."
그렇지가 않다는게 문제죠..
동일한내용을 5~7가지형태혹은 다른문서로 중복 관리되며.. 대부분 어디에 무엇이 있는지 알수없어하는...
수정내용이 모두 반영되는지는 의문...
그렇다고 동일한내용이니 문서하나만 보고 할수있느냐.. 그것도 아니라는.. 비슷한데 문서규정상 내용이 한두가지씩빠져있다는..ㅡㅡ;;
그렇다면 한곳에 잘정리하면되지 않나?? 그러고싶지만.. 그렇게 할수 없다는게...
그리고 정작 필요한건 없다는... 문서화 대상이 아니라서...
예를들면... 통신이라면 통신규격(format)이 없는..
----------------------------------------------------------------------------
C Library Development Project
----------------------------------------------------------------------------
쉬운가 안쉬운가의 문제가 아니고
왜 그런 것을 만들었으며,
어떻게 그것을 설계했으며,
어떠한 기능을 가지고 있으며,
사용한 기술과 툴은 무엇이고 등등...
그냥 보기 쉬운게 아니고, 전혀 그쪽에 모르는 사람이 문서자료를 볼 수도 있습니다.
현재 문서화 작업이 무언가 잘 안맞는다고 생각하시면 개선안을 만드셔서 직접 건의하시는 것도 좋은 방법 중 하나라고 생각합니다.
상당히 피곤한 상태에서 제목을 봤는데...
순간.. "개발(開發)이 배보다 배꼽이 ...."을 "개(犬)의 발(足)이 배꼽보다 과도하게 커질 때"로 착각했었습니다.
당연히 크지 않나... 라는 생각을 잠시 한 후에, 내가 뭘 잘못알고 있나... 의심했었습니다.
죄송합니다. ㅡ.,ㅡ;
------------------------
LINUH DESKTOP - Never be alone again
LINUH DESKTOP - Never be alone again
제가 읽고 있는 책의
제가 읽고 있는 책의 내용을 빌어서 말하자면, 문서를 만드는 이유는 나중에 다시 볼 일이 생기기 때문입니다. 해당하는 문서를 찾기 쉽고, 그 문서에 필요한 내용을 담고 있고, 그것을 통해서 원하는 내용을 쉽게 파악할 수 있어야 합니다. 즉, 문서 작성에 목적이 있는 것이 아니라 그것을 유용하게 사용하는데 목적이 있습니다.
상사한테 문서 작성의 이유, 효용성 등을 물어보세요. 좋은 질문을 통해서 원하는 답/결과를 얻을 수 있을 것입니다.
내 블로그: http://unipro.tistory.com
ㅎㅎ
이건 비효율적이지 않나요? 이런것도 안적혀있고. 이건 여기저기 흩여져있고 한곳으로 몰아야되지 않나요?
답: 무슨불만이 그렇게 많아.. 시키면 시키는데로햇..
----------------------------------------------------------------------------
C Library Development Project
----------------------------------------------------------------------------
우리나라의 삽집
우리나라의 삽집 문화는 언제쯤 고쳐질런지요... -.-;;;;;
내 블로그: http://unipro.tistory.com
곧 전직장이 될
곧 전직장이 될 곳에서 했던 일이 산출물 품질관리였는데, 계속 논점이 되었고, 지금도 되고 있는것이
산출물이더군요...
대부분의 컨설턴트와 개발자는 일단 개발을 중점으로 하고 있고, 개발의 결과물로 산출물을 작성해서
넘기고자 하는 경향이 강하고, 그에 반해서 최종적으로 완성품을 인수해서 장기적으로 유지보수를
수행해야할 SM 조직에서는 SM에 유리한 형태의 문서를 요구하게 되는 것이 인지상정이더군요.
동일한 형태의 문서(물론 버전업이 되지만)를 중복해서 작성하고 관리할 경우 뒤의 산출물을 수정하게
되면 앞의 연관된 산출물의 내용을 바꿀것이냐 말것이냐 하는 논란,
그와 동시에 최종적으로 나올 결과물(프로그램)에 해당되는 최종산출물이 중요한 것이 아닌가 하는 논란,
각각의 산출물을 하나의 파일로 만들어서 단계별로 내용을 채우는 것이 편한 컨설턴트와 개발자의
논리에 비해서 그때 그때 유지보수시에는 화면, 보고서, 사양서를 따로 만들어야 자기가 편하다는
SM 조직의 논리 등...
이와 더불어 한번에 하나의 파일에 계속 내용을 추가하는 것이 익숙한 SAP구축 조직과
일일이 찢어서 만드는 SI 개발 조직이 동시에 프로젝트를 진행하면서 니가 맞니 내가 맞니 하는
개발 철학의 차이 등...
품질관리 조직에서 파견된 QAO도 양쪽의 관점에 따라서 산출물의 작성 방법과 관리방법이 다른 문제...
하여간 어지간히 머리가 아프죠...
문서는 분명히 다음에 다시 볼일이 생기지만, 그 다음이 언제냐(설계단계에서 개발 단계, 유지보수 단계)에
따라서 산출물의 작성방법은 분명히 달라야하고, 어느 관점에 중심을 두느냐 하는 것 부터 결정한 후
그 관점에서 가장 유리한 방향으로 나머지 사람들이 의견을 일치시키지 않으면. 결국 매번 똑같은
내용을 또 만들고 또 만드는 수가 생길 가능성이 크죠...
어쨌던, ㅎㅎㅎ 이번주면 이 짓도 땡~~
--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러
--------------------------------
윈도위의 리눅스 윈도위의 윈도우 리눅스위의 익스플로러
문서 작업에 많은
문서 작업에 많은 시간을 할애하는게 당연하다는 관점에서 몇가지 언급하겠습니다.
개발보다 포장이 중요한 경우 문서작업이 시간 낭비라고 여겨질 수 있을 만큼 비중이 크게 차지할 것 같습니다. 개발자가 만드는 시스템은 코딩을 위한것 만이 아니라, 고객을 요구를 수렴하고 이해시키고 또한 개발과정과 결과물 역시 고객과 관련 조직의 사람들이 이해할 수 있도록 해야 하기 때문이겠죠. 유지관리를 위해 작성과정에는 한번도 보지 않지만 언젠가 보게 될 수도 있고..
또한, 개발과정에 있어 코딩과 프로그래밍 과정은 극히 일부이며 투입되는 인원역시 일부이며 작은 부분을 차지합니다. 개발과정에 참여한 분들 중 보면 높은 연봉(일의 중요도로 볼수 있겠죠?)을 받는 분들은 개발자가 아닙니다. -.-;;
개발자 입장에서 개발자체에만 집중하고 싶어 하겠지만, 이는 여건이 허락될 경우입니다. 해당 개발자의 역할에 맞지 않은 일이 주어질 수 있겠지만 이는 스스로 해결해야할 문제이지요. 극단적으로 정말 개발을 잘하는 사람이 있다고 합시다. 회사 차원에서도 의미없는 잡일을 시키기 보단, 그 사람의 역량이 제대로 발휘될 수 있는 개발에 집중할 수 있는 여건을 만들어 주리라 봅니다. 개발자가 코딩만 하는 사람도 아니고, 자신이 만들어 내놓을 제품에 대한 문서화는 적어도 책임을 져야겠죠? 이 문서화 또는 그와 유사한 시간은 코딩의 몇십배가 되는게 이상하지 않습니다.
단, 작성 과정중 의미없는 내용으로 페이지 수만 채워지고 정말 어디에도 쓸모 없을거 같은 경우가 있긴합니다. 이건 좀.. 어려운 문제이긴 한데 스스로 어떻게 처신하냐의 문제이겠죠. 사람사는 세상이나.. -_-;;
문서작성에 아무리
문서작성에 아무리 많은시간을투자해도 나쁘지 않다고 생각하시는분들이 많은것 같군요...
글쎄.. 과연..
그렇다면 그한계는 어디일지... 그렇다면 결국 1줄코딩에 1년의 문서작업은 최고의 방안?
----------------------------------------------------------------------------
C Library Development Project
----------------------------------------------------------------------------
몇년전에
몇년전에 모프로젝트에서 기존문서가 책으로되어 한수레정도 되더군요..
하나도 안봤습니다..^^;;
왜냐면 그럴시간도 없고.. 그거보느니 그냥 소스보는게 훨씬쉽기때문에...
역시나 개발끝나고 문서는 한수레 넘겼습니다..^^;
----------------------------------------------------------------------------
C Library Development Project
----------------------------------------------------------------------------
개발 : 코딩 vs 프로젝트
개발 = 코딩 자체가 아니라 프로젝트라고 보면 어떨까요? 프로젝트는 어떤 요구사항(requirements)을 결과물(deliverables)로 만드는 것으로 볼 수 있습니다.
IT프로젝트 그 결과물 속에는 장비, 소프트웨어(소스코드, 바이너리코드), 각종 분석,설계 자료, 보고서 등등이 있습니다. 결과물에서 코딩과 관련된 것은 아주 일부분입니다. 문서작업은 프로젝트의 활동입니다.
많은 개발자들이 프로젝트에서 문서작업을 그냥 계약상 그래야하기 때문에 싫어도 하는 경우가 많습니다. 많은 문서는 써 놓고 보지도 않는 경우가 많습니다. 계획한 것 (계획 문서)는 한번 써 놓고 나면 범위가 변경되어도 일정이 바뀌어도 수정하지도 않습니다. 그냥 장식용 문서일 뿐입니다.
툭 까놓고 말하면, 문서 쓰기 싫어하는 개발자, 참조하지 않는 산출물 ... 이러한 게 나타나는 프로젝트는 대개 실패하는 프로젝트이며 프로젝트 관리가 안 되는 프로젝트입니다. 필요한 걸 안 하고 쓸 데없는 걸 하고 중요한 리소스를 낭비하는 프로젝트인 거죠. - 산출물(문서 측면)이 많은 거하고 쓸데 없는 문서 생산하는 거하고는 전혀 다른 겁니다. - IT 프로젝트에서 갑-을 관계로 이루어지는 프로젝트에서 많이 발생합니다.