이제는 프로그램을 만들어 주기도 힘들군요. --;;
아주 오래전에 "프로그래머보다는 파워유저?" (http://kldp.org/node/67778) 라는 글을 올린적이 있습니다. 2002년도에 올렸네요. 그런데 올해들어서 두분이 댓글을 달아주셔서 제 관심을 끌었습니다.
그글을 다시 읽어보고, 댓글을 읽어보다 보니, 그때와 달라진 부분을 좀 쓰고 싶어 졌습니다.
달라졌다고 하는것은, 프로그래머는 돈을 받고 프로그래밍을 하는 사람인데, 요즘 사람들은 자신의 업무를 어떻게 프로그래밍을 해달라고 하는 요구자체를 만들지를 못하는것 같습니다.
당신의 업무를 전산화 하기 위해서 프로그램을 짜줄테니, 당신이 하고 있는 업무을 설명하라고 하면, 이렇게 저렇게 해달라고 말로 잘도 요구를 합니다. 그러나 문서화 해서 달라고 했을때, 멀뚱 멀뚱한 경우가 요즘의 상황입니다.
그것은 특히나 나이가 젊은 사람인 경우가 심합니다. 머릿속으로 어떻게 하는것은 잘 알고 있는것 같은데, 그일을 문서로 정리해달라고 하면, 끙끙대는것은 좀 나은편이고, 난 문서로는 절대로 못만든다! 라고 버팅기는 사람도 있습니다.
그럼 어떻게 해야하느냐? 정 할수 없는경우, 옆에서 그사람이 일하는 모습을 보면서 제가 정리를 합니다. 그리고 이렇게 저렇게 하면 맞느냐 하고 정리를 해서 작업에 들어가야 하는 상황입니다. 참 너무도 짜증이 나는 접근방식이 아닌가 합니다. 그러나 방법이 없어요.
이렇게 하면, 어떻게든 일을 하기는 하는데, 또다른 문제는 프로그램을 보여주었을때, 그렇게 만들어 달라고 하지 않았다고 벅벅 우기는 것 입니다. 그런데 이게 문서가 거의 없는 상태에서 만들다 보니, 증거도 없는데다 논쟁을 벌여봐야, 서로 마음만 상하는 절망적인 경우가 많습니다.
요즘 젊은 사람들 컴퓨터를 잘 사용하는 사람이지만, 컴퓨터의 창의적 이용과는 너무나도 거리가 먼듯한 모습이더군요.
성경에 보면, 다니엘서에 유명한 신상이야기가 나옵니다. 바빌론왕이 어떤 꿈을 꾸었는데, 그것을 다니엘이라는 선지자가 해석해 주는것 입니다. 꿈의 내용은 큰 신상인데, 머리는 황금, 어깨는 은, 가슴은 구리, 배는 철, 다리는 흙으로 되어 있는 신상을 빗대어서, 세상은 날이갈수록 어리석어지고, 살기가 힘들어 질것이다 라는 묵시적인 이야기 입니다.
지금과 같이 발달된 과학문명을 생각할때에 말이 되지 않는 내용이라고 생각을 했는데, 각 개인의 능력으로 가늠해 본다면, 지금의 현대인은 과학문명기기에 너무 의존하여, 개인의 능력은 너무 떨어지고 있는것 아닌가 생각됩니다. 그리고 우리는 괜찮게 살고 있지만, 세계적으로 보면, 못먹고 굶는 사람이 점점더 많아지고 있다고 하는것을 보면, 저예언이 맞는것이 아닐까 생각하곤 합니다.
우리는 현재의 과학문명의 발달과 더불어 우리도 같이 진화(?) 하고 있는것 일까요? 심각한 의문이 듭니다.
- 겨울아찌 -
공감이 가는
공감이 가는 이야기입니다.
요즘 읽은 책들에서는 요구사항 분석시 거의
라는 가정을 세우는 것을 첫단계로 하는 경우를 많이 보았습니다.
또한 상기 인용과 같은 경우 요구사항 문서를 사용자나 개발자 중 한쪽이 만들거나 아니면 협의해서 만들고 난 후에 (요구 사항이 꼭 문서화 되지는 않았더라도) 이슈나 모듈 별로 작은 (요약) 카드를 하나 만들어서 개발 착수시에 양쪽 다 사인을 하게 하면 즉흥적인 요구사항의 증가도 막을 수 있고 인용한 것처럼 사후에 부인하는 짜증나는 경우도 방지할 수 있다고 어디서 읽은 듯합니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
요구사항 분석이
요구사항 분석이 그만큼 어렵다는 것이겠지요. ^^
그 반대되는 경우도...
비일 비재하게 일어납니다.
사양서에 잔뜩 적어줘도 이상한 기능만 잔뜩 넣는 경우도 많거든요.
real time 으로 동작해야 하는 장비에서 log 파일을 xls 로 저장하려고 하고 ...
장비의 터치스크린은 800 x 600 인데, 소프트웨어 개발자 노트북 모니터가 1280 x 800 해상도라서 그 모니터 해상도에 맞춰서 UI 를 짜서 ... 거의 한달 넘게 수정하고 ...
같은 프로그램 내에서 login/logon, logout/logoff 등등 다 섞어 써서 ... 이게 서로 따른 뜻인가 .. 한참 생각하게 만들고 ...
이런 경우도 지금 있는 회사에 2년 좀 넘게 있으면서 거의 매달 ... 매번 소프트웨어 개발을 발주처리 할 때마다 겪는 일입니다.
가장 최근에 (그러니깐 1주일 전쯤 ...) 겪은 일로는 ...
사양서에 있지도 않은 easter egg 를 넣는다고 ... 납기일 늦는 경우도 봤습니다. -_-
납기일 늦어서 난리쳤더니 소프트웨어 들고 와서 '자 보세요. 여기 로고를 트리플 클릭하면 ...' 이라고 하는데... 기가 차더군요.
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
http://akpil.egloos.com
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
ㅎㅎㅎ
easter egg...ㅎㅎㅎㅎ 대박이네요.ㅎㅎ
＼(´∇`)ノ.大韓兒 朴鐘緖人
＼(´∇`)ノ.大韓兒 朴鐘緖人
ㅋㅋㅋ 트리플 클릭...
대박입니다. -_-b
---------------------------------------------------------------
피곤함 1테라톤을 가방 보따리에 주섬주섬 짊어메고 다니는 아이 . . . Orz
---------------------------------------------------------------
폐인이 되자 (/ㅂ/)
자기가 뭘 원하는
자기가 뭘 원하는 건지는 사실 잘 모르는게 정상일 수도 있어요. 그리고 그걸 받아들인다면 서로 짜증을 내지 않고 해결할 수 있는 방법을 찾을 수 있겠죠. 예를들면 고객이 원하는 기능을 쓰도록 '도와'주는 거에요. 개발자가 직접 쓰지 않고요. 고객이 원하는게 뭔지 잘 모른다면, 개발자가 그걸 알려주고, 고객이 직접 쓰게 되면 그 기능에 대한 책임은 고객에게 있는거죠.
사용자 스토리와 같은 애자일 방법론을 설명한 책들에서는, 고객이 완벽한 명세를 줄 거란 기대를 하지 말라고 합니다. 언제든지 변할 수 있는게 그들의 요구사항이라고 가정하는거죠.
--
쓰고보니 위에서 같은 내용의 답글을 이미 쓰셨군요.
언제나 삽질 - http://tisphie.net/typo/
언제나 삽질 - http://tisphie.net/typo/
프로그래밍 언어 개발 - http://langdev.net
고객은 자신의 요구를 형상화하지 못한다
레이저로 반짝했다가 급격히 몰락의 길을 가고 있는 모토로라가 바로 그 반짝하던 시절 자랑삼아(?) 출판한 경영서에 저런 말이 있더군여. 책을 잃어버리는 바람에 제목은... 쩝!
모토로라는 몰락해가지만 저 말은 참 명언인 것 같습니다.
모토로라는 그래서 시장 조사를 하는 대신 디자이너들이 알아서 창작하게 냅뒀다더군여.
그런데 결과적으로... 역시 세상이란 별 수가 없는 모양입니다;;;
꼭 프로그램 분야만 그런 것은 아닌듯 싶습니다.
다시 바빌론이 등장하는 것일까요?
같은 언어를 써도 다른 얘기를 하는 사람들을 쉽게 만날 수 있습니다.
사실, 사람들끼리 의사소통을 할 때 가장 필요한 것은 '진심'이 아닐까 생각합니다.
그런 프로그램이 필요하다고 말한다고 해도, 실제로는 그러한 프로그램의 필요성을
못 느끼고 있는 것일지도 모릅니다.
====
( - -)a 이제는 학생으로 가장한 백수가 아닌 진짜 백수가 되어야겠다.
혹시 바벨탑을
혹시 바벨탑을 이야기하려고 하신것은 아닌가요? 아니였다면 죄송합니다.
=====================================
http://www.timothylive.net
=====================================
http://timothylive.net
네. 맞아요. ^^;;;
바벨탑 이야기의 배경이 되는 곳이죠.
바벨탑 이야기 맞습니다. ^^;;;
====
( - -)a 이제는 학생으로 가장한 백수가 아닌 진짜 백수가 되어야겠다.
프로그램을 하는
프로그램을 하는 입장에서는 처음부터 끝까지를 순서적으로 일목요연하게 볼 수 있는 문서를 만드는 것이 보통인데 사용자에게 비슷한 서식의 요구사항을 적어달라고 하는 것은 예나 지금이나 무리인 듯 합니다. 쭉 생각나는대로 1, 2, 3, 4 번호붙여서 하는 일을 적어달라고 하고 그것에 육하원칙으로 문장정리하고 기능별/순서적으로 옮겨가며 문서를 만드는 것은 몇 번의 반복 면담을 하는 것이 필요한 절차라고 봅니다.
그래도 꼭 요구사항이 무엇인지를 보는 문서는 있어야 하겠지요. 여기서는 그 문서의 정리본을 "외부 스펙"이라고 해서 요청자와 설계자가 결과물에 싸인을 하고 개발팀을 위한 "내부 스펙" 작성을 시작합니다. 대신에 국내의 SI에서 보는 도식으로 정리된 문서 형태가 아니라 일반 문장으로 서술한 문서 형태입니다. 각 요청을 밑줄 그면서 읽어야하죠.
----
I paint objects as I think them, not as I see them.
atie's minipage
----
I paint objects as I think them, not as I see them.
atie's minipage
많은 댓글을 달아주셨는데...
글을 쓴 의도는 사람들이 별로 생각을 하지 않는다는 것을 말하고 싶었던 것입니다. 요구사항을 정확하게 추출해서 프로그래밍 하는것은 당연- 당연- 한 이야기 이지요.
그러나 그 요구사항이 모호하기 짝이 없읍니다. 다시 말하자면, 자신이 요구하는 결과만 이야기를 할뿐이지, 그 중간과정은 생각하기도 싫어한다는 것입니다. 최소한의 출력 항목을 문서로 만들어주는것도 싫어하니 원~~~
생각하기 싫어하는 사람들을 보면서, 그래서 아직도 밥벌이를 할수 있게 하는 원인이 될지도...
예전부터 회자되었던 것이지만, 컴퓨터! 재미있기는 한데, 한국에서 직업으로 삼기에는 참 고달픈 직업이지요. 쩝~
- 겨울아찌 -
winchild@kldp.org
- 겨울아찌 -
winchild@gmail.com
공감합니다.
공감합니다.
안녕하세요?
그래도 개발자라는거...
그래도 우린 개발자 자나요...
힘내세요 ^^
파이팅...
'갑' vs '을' 의 역학관계도 있는 것같습니다.
초등학교 친구들 모임에 여러직업의 친구들이 모이는데, SI업체에 다니는 친구와 카드회사,종합병원 약제과에서 일하는 친구들이 있습니다.
SI업체에서 일하는 친구가 이 주제와 비슷한 애로사항을 이야기했더니만, 카드회사와 약제과에 있는 친구들의 말이...
"'갑'이 시키면 '을'은 그냥 알아서 하는거지, '을'이 '갑'한테 이런거 저런거 해달라는 것 자체가 '갑' 마인드에서는 도저히 받아들일수 없다"는 식으로 말하더군요. 심지어 그것이 요구사항 명세라고 할지라도 말입니다.
(물론, 저렇게 대놓고 말한건 아니었지만 결국에는 저런 뜻이었습니다.)
그리고, '갑'의 마인드에 "우리가 너네들한테 돈을 얼마나 주는데 이정도는 부려먹어야지"라는 것도 있다고 합니다.
그 SI업체 친구가 일본에서 일할 기회가 있었는데, 일본회사들은 요구사항 명세가 확실하고 그에 대한 문의도 친절하게 잘 받아주었다고 합니다. 심지어 자기들이 미처 생각하지 못했던것까지 잡아내서 피드백을 주면 좋아했다고 하더군요.
몇년전 이야기라서 요즘 현실은 어떤지 모르겠군요.
예전 대학에서나
예전 대학에서나 이전 직장에서 주어진대로 구현만 하다가
현재 직장에서 요구규격을 작성한다고 스트레스 받고 있는데 이 글을 접하게 되네요.
요구분석도 어렵지만, 그걸 표준 절차에 따라 표현하는 것은 더 어려운 것 같습니다.
말로 서술하는 것도 쉽지 않고, UML이나 도식 같은 것으로 표현하는 것도 만족스럽지 않으며, 산업 표준 문서/절차는 왜 그렇게 갑갑한지...
차라리 내가 구현을 하고 그런 거 안만드는게 편하겠다는 생각까지 들더군요.
시스템 공학이나 커뮤니케이션 방법 같은 것을 좀 더 공부해야겠다는 생각이 많이 들었습니다.
사실 설계나 구현이 없는 시스템은
사실 요구하는 쪽이나 구현하는 쪽이나 모두에게 흐릿할 수 밖에 없다고 생각합니다.
그 흐릿한 시스템을 분석할 때 저는 시스템에만 집중했는데
경험자들의 조언에 의하면 이 고통스러운 작업을 재수행하지 않기 위해서는 설계/구현하는 쪽의 의견이나 형편도 살피라고 하더군요.
(구현하는 쪽에서 어렵다거나 불가능하다고 주장하면, 시스템 분석을 다시 해야하기도 하니까요.)
결국 서로의 feedback이 필요하다고 생각하게 되었습니다.
이전에 몰랐는데 요구분석도 단계 일도 쉽지 않은 것 같습니다.
케케케~
케케케~
집을 리모델링할 때,
집을 리모델링할 때, 인테리어 업자에게 자세히 설명할 수 있는 사람은
그쪽 전문가가 아닌 이상 많지 않을 것입니다.
대충 자신이 관심있는 부분만 어떻게 해달라고 할뿐, 나머지는 알아서 이쁘게 해주길 바라지요.
소프트웨어 개발이 그것과는 성격이 많이 다르다는 것을 압니다.
그러니, 두 쟁점이 잘 합의가 되어서... 개발자들도 노력해야겠고..
일을 맡기는 사람도 노력해야 겠습니다.
-------------------------------------------------
홍환민. http://www.wearethebest.co.kr
-------------------------------------------------
홍환민. http://www.wearethebest.co.kr
그렇기 때문에
그렇기 때문에 프로젝트에서 PM이나 PL들의 역할이 중요한 거겠지요...
보통 갑들은 저런 식으로 문서를 먼저 만들어 주는 일이 거의 없습니다...
일단, 구두 회의로 업무에 대한 분석으로 갑, 을 참여하에 하게 됩니다...
거기서 나온 업무 분석 결과를 을이 정리하여 갑에게 맞게 정리 된 것인 지 확인을 받게 됩니다...
이 단계에서 몇 번의 피드백이 오가게 되고 성의있고 의욕있는 갑이라면 이 부분을 열심히 하게 됩니다...
그리고 업무 분석 단계를 지난 후에 프로그램 설계에 들어가서 실제 프로그램을 작성하고 있다 보면, 갑에서 업무를 변경합니다...
PM이나 PL의 협상력이 떨어지는 경우, 처음부터 다시 하게 됩니다...
ㅎㅎㅎ 악순환이죠...
이제는 프로그램을 제작까지 해주는 프로그래밍 고수들이 널렸군여..
옛날 OS만드는 것도 상당히 어려운 작업으로 인식이 되고 프로그래밍도 상당히 어렵고 그런 작업으로 인식이 됬는데 리눅스의 오픈소스덕에 프로그래머들이 많이 늘어서 좋긴 좋군여...
[위선,거짓, 인간의 모든 추악함에서 꿋꿋이 살아가는 굶주린 영혼이여 편안한 휴식이 찾아오길 기원하겠습니다.]
[위선,거짓, 인간의 모든 추악함에서 꿋꿋이 살아가는 굶주린 영혼이여 편안한 휴식이 찾아오길 기원하겠습니다.]