통합검색
· 마을서비스란?  · 포럼마을  · 일반마을  · 테마마을  · 마을랭킹  · 활동왕
· 덱스퍼트란?  · TECBOX   · PRSBOX   · 이용안내  
· DEXT제품군  · 솔루션베이  · S/W & ESD 컴포넌트
· 프로그램베이
· LiveSeminar  · LiveConference
데브피아 사이트 운영자, 비사모 마을 입니다.
개발이 아니더라도 다양한 분야에 많은 얘기를 나누는 공간입니다.
  마을등급 비사모 마을   이 마을은 테마마을 입니다이 마을은 자유가입제 마을 입니다 마을소개 페이지로 이동 전입신청
마을촌장촌장 비사모 방문자 100184 since 2006-12-31
데브피아 공지사항
자유게시판
앨범
개인게시판
[마을 게시판]
데브피아 운영 소식
교육 & 세미나 홍보
[개발자 공감]
개발자 공감글
개발자 공감만화
랑데브 게시판
칼럼 게시판
개발자 고충상담
Dev Talk
자유토론방
벼룩시장
재나미 우스개
구인/프로젝트 정보
사람인 채용 게시판
  고객지원 게시판
마이 데브피아
 나의 e-Money 내역
 활동왕 My Page
 스크랩한 게시글보기
 쪽지관리
 주소록관리

 개발자 고충상담
 정신병원에서 나온 디자인에 대한 이야기입니다. 2008-02-01 오후 4:15:36
 island78  island78님께 메시지 보내기island78님을 내 주소록에 추가합니다.island78님의 개인게시판 가기 번호: 10227  / 읽음:5,054

회사에 들어온 웹디자이너가 엘런 쿠퍼가 쓴 "정신병원에서 나온 디자인"이란 책을 주더군요.. 뭐 디자인 책 중에서는 가장 좋은 책이라고 생각한다면 말이죠..

 

읽어 보니까.. 앞의 1/3은 너무나 복잡한 인터페이스를 씹는 내용이고 나머지 1/3은 그렇게 된 이유가 개발자들이 UI, 특히 사용자 인터페이스에 너무 많은 영향력을 행사하기 때문이고 나머지 1/3은 페르소나를 소개하면서 개발자들을 설득하기 위한 전략을 설명하더군요..

 

제가 알기로는 엘런 쿠퍼 또한 대단히 수준 높은 개발자로 알고 있습니다. 그래서 그런지 마치 거기서 적은 불특정 다수의 개발자에 대한 이야기가 제 이야기 같...더군요..--;

 

몇 군데 발췌해 보면요

 

 

프로그래머들은 소프트웨어를 배우는 데 엄청난 시간과 에너지를 바치기 때문에, 사용자들이 시간을 들여 그의 작품을 이해하려고 하지 않는다는 것은 그들에게 상상도 할 수 없는 일이다. 그는 회사 내에 문제가 있다는 사실은 기꺼이 받아들였지만, 회사 내에서 자신이 맡은 일에 문제가 있다고는 생각하려 하지 않았다.

 

-Part3 포크로 스프먹기, 테크노 정신병원

 

 

 

침입자가 접근해 오면 그들은 통제권이 무책임한 사람들에게 넘어가지 않도록 조심한다. 대부분 프로그래머들은 아주 책임감이 강한 사람들이며, 외부 컨설턴트나 마케팅 전문가, 경영자들을 종종 무책임하고 무능한 존재로 여기곤 한다.


 프로그래머들에게는 아주 예민한 거짓말 탐지 능력이 있어서, 마케팅 전문가나 관리자들이 '인터페이스를 개선하기 위해' 프로그램을 고치라고 주문했는데 결국 고쳐도 아무런 효과가 없었던 경우를 두어 번 겪고 나면 외부의 간섭에 단련이 돼버린다. 이러한 변경은 바람직한 것이든 아니든 상관없이, 프로그래머에게 추가적인 일을 하게 만든다. 또 변경을 할 때마다 프로그램에 불가피하게 상처와 땜질 자국들을 남기기 때문에 작성된 코드의 품질이 떨어지게 된다. 누군가 '확인' 버튼을 전부 대화상자의 오른쪽 위 구석에 두면 프로그램이 사용하기 쉬워질 것이라고 주장하면, 프로그래머는 자신의 경험과 지혜에 비추어 그것은 그저 시간 낭비라고, 정확하게 말하면 '자신에게' 시간 낭비일 뿐이라고 되뇌일 것이다. 이러한 두려움은 전혀 근거 없는 것이 아니다.


 이런 어이없는 일을 몇 번 겪고나면 프로그래머들은 외부에서 오는 모든 디자인 지시 사항을 그저 충고로만 여기기 시작한다. 잘못 설계된 벽들이 너무 많아 철거해야 하는 건축가와 같은 경험을 한 그들은, 이제 청사진을 아니꼬운 눈으로 바라보며 그것을 있는 그대로 받아들이지 않으리라 결심한다.

 

-Part3 포크로 스프먹기, 테크노 정신병원

 

 

 

대부분의 사람들이 적당한 수준으로 노력을 기울이는데 별 어려움을 겪지 않지만, 프로그래머들이 대부분의 사람들과 다른 점은 그들이 극도로 복잡성한 시스템을 정복하려는 의지와 능력을 지녔다는 점이다. 서로 인터랙션하는 수많은 요소들로 구성된 시스템을 이해하도록 관리하는 것은 프로그래머라는 직업에서 특히 만족스러운 부분이다.

 

-Part3 포크로 스프먹기, 호모 로지쿠스

 

 

 

이 책에서 개발자로서 최고의 공감 200%의 단락은...

 

소프트웨어 엔지니어들은 인테랙션 디자이너들과 목표를 공유한다. 즉, 그들도 제품이 성공적이기를 바란다. 단지 그 성공을 측정하기 위한 그들의 도구와 용어가 디자이너들의 것과는 전혀 다른 것 뿐이다.


 확실한 증거가 없는 상태라면, 프로그래머들은 반드시 자기 자신의 교육과 경험, 본능적인 감각에 의존하려고 할 것이다. 그의 본능은 그에게 가능한 많은 기능을 제공하라고 말한다. 그의 경험은 아마추어들이 일시적인 기분이나 어림짐작으로 민감하고 복잡하고 섬세한 개발 과정을 망치게 내버려 두지 말라고 말한다. 그가 받은 교육은 그에게 자기 자신을 참조하여 인터페이스를 구축하라고 말한다.


인터랙션 디자이너들은 이러한 동기들을 직접적으로 공격할 수 없다. 개발자들은 너무나 이성적이고 합리적인 사람들이라 절대 다른 사람의 의견을 따르기 위해 자신의 경험을 저버리지 않는다. 디자이너는 그들에게 문제를 바라보는 새로운 관점을 제시해야 하며, 그 관점이 효과적이라는 것과 기존의 관점과 양립할 수 있다는 것. 이렇게 2가지를 추가로 입증해야 한다.

 

-Part 5 운전석으로 돌아가며, 강력함과 즐거움

 

 

 

 

이 부분이 많이 공감이 가더라구요..

 

게임의 부담

소프트웨어 엔지니어링이 갖는 강한 문화적 결정 요소 중 하나는 그것이 홀로 이루어진다는 것이다. 프로그래머들은 홀로 책상에 앉아 있다. 한 시점에 단 한 명의 프로그래머만이 코드를 입력할 수 있다. 코드는 컴퓨터 상에서 겉으로 거의 드러나지 않으며, 읽히는 일도 거의 없다. 다른 사람들이 작성한 코드를 읽는 것은, 책을 읽는 것이라기 보다는 본인만 알아볼 수 있게 끄적거린 타인의 강의 노트를 읽는 것에 더 가깝다. 프로그래밍 작업은 아주 복잡해서 한결같이 집중해야 하고 오랜 시간 방해받지 않으면서 일해야 한다. 프로그래머들은 이러한 고립과 그것이 내포하는 의미를 분명히 의식하고 있다. 그 누구도 프로그래머가 자신의 프로그램 속에서 하는 일에 이렇다 할 통제력을 행사할 수 없다. 프로그래머들은 자기 코드의 질이 스스로의 성실함과 양심에 달린 문제라는 것을 알고 있다. 상사는 높은 품질을 요구할 수는 있어도 정말 높은 품질인지 확인하기 위해 팔요한 시간과 노력을 직접 투자하려고 하지 않을 것이다. 프로그래머가 작성한 코드를 해독하는 데는 그것을 원래 작성하는 데 걸린 시간보다 더 많은 시간이 소요될 수 있다. 프로그래머들도 이 사실을 알고 있으며, 그들의 개인적인 결정과 행동이 다른 어떤 고려사항보다도 최종제품과 사용자 만족에 많은 영향을 미치는 것도 안다. 궁극적으로, 그들은 제품 성공 여부에 대해 개인적으로 책임을 져야 할 것이다. 그들은 자신들이 게임에서 많은 부담을 지고 있다는 것을 안다.


프로그래머의 외로운 작업은 프로그래머가 자신의 권한을 강하게 의식하게 만든다. 어떤 프로그래머들은 이런 권한을 불편하게 느끼기도 하지만, 게임에서 적은 부담을 지고 있는 다른 사람에게 권한을 양도하는 것을 그보다 훨씬 더 불편하게 여긴다. 마케팅 담당자나 관리자, 디자이너가 그들에게 충고를 하면, 프로그래머들은 그 제안을 상당히 회의적인 시각으로 본다. 만약 충고를 받아들여 일이 잘못된다면, 조언자들은 이미 사라진 지 오래고 비난은 프로그래머에게 그대로 쏟아지리라는 것을 그들은 알고 있다.


~중략~


한편, 모든 프로그래머들은 자신들처럼 사용자가 원하는 것이 무엇인지 잘 모르는 관리자들이 내린 멍청한 디자인 지시 때문에 좋은 제품이 시장에서 실패했던 끔찍했던 기억을 가지고 있다. 타이핑을 싫어하는 한 고위 임원이 자기 회사의 모든 프로그램을 마우스만으로 조종 가능해야 한다고 요구했던 일이 기억난다. 또, 마우스 사용이 서툰 또 다른 고위 임원은 자기 회사의 모든 프로그램이 키보드만으로 조종되어야 한다고 지시한 사례도 있었다. 이 자신을 기준으로 하는 이 파괴적인 디자인은 두 회사 모두에 절망적인 파문을 불러 일으켰다.


일부러 심술궂게 굴고 파괴적인 성격의 프로그래머들도 있지만, 내가 만나본 많은 프로그래머들로부터 판단하건데 그런 사람들은 극히 드물다. 제트 전투기 조정사들처럼 훈련과 규율이 아주 엄격하기 때문에, 이들이 일단 정상급 능력에 도달하게 되면 프로그래머가 아닌 사람을 능력이 떨어지는 사람으로 여기게 되는 것은 어쩔 수 없는 일이다. 소프트웨어 엔지니어들은 같은 분야 사람들을 존중하지만, 프로그래머가 아닌 사람이 프로그래밍의 세계로 뛰어들면, 무디가 이야기했듯이, 그들을 깔보거나 심지어는 엘리트주의자처럼 군다.


프로그래머는 소프트웨어 개발이라는 첨단 기술 세계에 참견하려는 아마추어들을 비웃을 권리가 충분히 있다. 마찬가지로, 프로그래머가 경리부장실 문을 두드리고 들어가 사업 관련 수치들을 다시 계산하기 시작한다면, 경리부장은 남의 일에 간섭하는 프로그래머의 욕심과 오만함을 비난할 자격이 있다.


문제가 생기는 것은 인터랙션을 디자인하는 것과 이를 구현하는 것이 일반적인 개발 과정에서 너무나 철저히 뒤섞여 있기 때문이다. 관리자는 프로그램의 행동 방식을 변경해 달라고 요구할 수는 있겠지만, 감히 프로그래머에게 다른 코드 작성법을 이용하라고 요구하지는 않을 것이다. 그러나 프로그램의 행동양식과 그 구현은 아주 밀접하게 관련이 있기 때문에, 어떤 것은 반대하면서 다른 것은 반대하지 않는 것이 불가능하다. 이것이 무디가 마이크로소프트 사에서 경험한 어려움 가운데 하나이다.


소프트웨어 기반 제품의 개발에 관여하는 대부분의 사람들은 사용하기 쉽고 편한 제품을 만들고 싶어한다. 결과적으로 그들은 계속해서 프로그래머들을 귀찮게 한다. 개발자들에게는 시간 여유가 거의 없기 때문에 이러한 간섭은 그들을 화나게 할 수 있다. 많은 프로그래머들이 혼자 일하려 하며 프로그래머가 아닌 다른 팀 멤버들과 잘 대화하려 하지 않는다. 테므라 히더쇼-하트는 테크니컬 라이터로 일할 때 프로그래머들로부터 정보를 얻어냈던 이야기를 나에게 해주었다.

 

 

---나는 간절히 부탁하는 것보다 뇌물을 주는 것이 훨씬 효과적이라는 사실을 알게 되었다. 나는 주로 초콜릿을 이용하곤 했다. 뇌물 방법은 효과가 너무 좋아서 한번은 엔지니어링 매니저가 제품의 변경 내용을 알려주지 않은 것에 대해 공식적으로 사과를 하기까지 했다.(어쨌든 그는 뇌물을 받긴 받았다.) 어떤 회사에서는 초콜릿에 사족을 못 쓰는 엔지니어 한 사람이 그의 동료들의 변경 내용까지 전부 이야기해주고, 그들 몫의 초콜릿까지 받아간 적이 있었다. 뇌물 방법을 사용하기 전에는 제품에서 무엇이 변경되었는지 알아내기 위해 오랜 시간 초과 근무를 해야 했다. 결국, 나는 초과 근무 시간을 절반 이상으로 줄였다.---

 

 

이 일화가 흥미로운 이유는 소프트웨어 개발 사업에 조금이라도 경험이 있는 사람이라면 정말로 그렇다는 것을 알기 때문이다. 만약 어느 회사의 경리부장이 수금 관리 직원에게 오늘의 입금액에 대한 정보를 얻기 위해 초콜릿을 뇌물로 주어야 한다는 이야기를 듣게 되다면, 당신은 놀라워하고 분개할 것이며, 또 믿지도 않을 것이다.


 

 

 

많은 임원들이 그들이 내린 지시나 심지어는 가벼운 제안에 대해서도 부하 사원들이 즉각 따르는데 익숙해져 있다. 그들은 프로그래머들이 기술직이므로 그다지 높은 지위와 권력을 가지고 있지 않으며 상사의 지시에 순종적으로 따를 것이라고 생각한다. 프로그래머의 관점에서 보면, 임원들은 게임에서 아무런 부담도 지고 있지 않기 때문에 과연 순종해야 할지 상당히 의심스러울 수 밖에 없다. 독립심이 강한 소프트웨어 엔지니어는 직위의 고하를 막론하고 다른 사람이 하라고 한다는 이유만으로 자신의 코드를 고치지는 않을 것이다.


기존의 코드를 수정하기를 원한다면, 당신은 우선 프로그래머의 마음부터 바꾸어야 한다. 그는 기존 코드에 대한 기득권뿐이나라 불필요하게 코드를 변경하는 수고로움을 거부할 기득권도 가지고 있다. 그들에게 명령이 아닌 부탁을 해야 하는 것은 물론이고, 변경해야 하는 논리적이고 납득시킬 수 있는 이유도 제시해야 한다. 이는 엔지니어가 이해할 수 있는 용어로 표현되어야 하며, 또 게임에서 부담을 갖는 누군가에 의해 제시되어야 한다.


-Part3 포크로 스프먹기, 그들만의 문화

 

 

선배 분들의 생각은 어떠십니까.. 저는 찔리는 구석이 한 두 군데가 아니라서요...ㅡㅡ;

[코멘트] 슬픔
2008-02-01 16:26
 kkoijae  kkoijae님께 메시지 보내기kkoijae님을 내 주소록에 추가합니다.kkoijae님의 개인게시판 가기 
저두 많이 찔리네요..ㅠㅠ . 이걸 다 손수 쓰셨는지...대단하시네요.. bb
저장 취소
[코멘트] 좋음
2008-02-01 16:29
 wxjin  wxjin님께 메시지 보내기wxjin님을 내 주소록에 추가합니다.wxjin님의 개인게시판 가기 
컥 정말 많이 공감이 가는군요....... ^^;;
저장 취소
[코멘트] 궁금
2008-02-01 16:30
 bestinlife  bestinlife님께 메시지 보내기bestinlife님을 내 주소록에 추가합니다.bestinlife님의 개인게시판 가기 
저도 공감 한표요;;;
저장 취소
[코멘트] 좋음
2008-02-01 17:00
 huunji  huunji님께 메시지 보내기huunji님을 내 주소록에 추가합니다.huunji님의 개인게시판 가기 
디자이너와 프로그래머의 눈의 방향이 틀려 종종 다투지요.
전 그래서 한번 디자이너 울려서 그만 둬버려서 제가 나머지 디자인을
혼자 독학으로 공부하여 마무리 했던 안좋은 기억이 있네요.ㅎㅎ

전 마지막 부분의...
--------------------------------------------------------------------------------------------------------------------------------------
기존의 코드를 수정하기를 원한다면, 당신은 우선 프로그래머의 마음부터 바꾸어야 한다.
그는 기존 코드에 대한 기득권뿐이나라 불필요하게 코드를 변경하는 수고로움을 거부할 기득권도 가지고 있다.
그들에게 명령이 아닌 부탁을 해야 하는 것은 물론이고, 변경해야 하는 논리적이고 납득시킬 수 있는 이유도 제시해야 한다.
이는 엔지니어가 이해할 수 있는 용어로 표현되어야 하며, 또 게임에서 부담을 갖는 누군가에 의해 제시되어야 한다.
--------------------------------------------------------------------------------------------------------------------------------------
가 정말 마음에 드네요.^^*
저장 취소
[코멘트] 슬픔
2008-02-01 17:10
 crossbow  crossbow님께 메시지 보내기crossbow님을 내 주소록에 추가합니다.crossbow님의 개인게시판 가기 
훔... 자기확신, 타인무시...

반성해야 겠네요.

그럼...
저장 취소
[코멘트] 궁금
2008-02-01 18:13
 cantata  cantata님께 메시지 보내기cantata님을 내 주소록에 추가합니다.cantata님의 개인게시판 가기 
업무에 접근하는 프로그래머로서의 자세에 대하여 다시 한번 고뇌하게 만드는 글이군요.

하기야 저도 아집을 버리는데 10년이 넘게 걸렸으니...

설익었을때 껍질이 단단하죠.
저장 취소
[코멘트] 슬픔
2008-02-01 18:54
 sthouse  sthouse님께 메시지 보내기sthouse님을 내 주소록에 추가합니다.sthouse님의 개인게시판 가기 
죄송한데요..

전 솔찍히 저 글의 요점이 뭔지 와닿지 않네요.
(국어가 딸리나???)

누가 딱 와닿게 정리좀 해주세요.. ㅠㅠ
저장 취소
[코멘트] 좋음
2008-02-01 18:54
 toskf  toskf님께 메시지 보내기toskf님을 내 주소록에 추가합니다.toskf님의 개인게시판 가기 
퍼갑니다..^^
좋은 글이네요..
저장 취소
[코멘트] 난감
2008-02-01 19:02
 island78  island78님께 메시지 보내기island78님을 내 주소록에 추가합니다.island78님의 개인게시판 가기 
장기주님//

엘런 쿠퍼가 쓴 저서는 솔직하게 개발자들 졸라 까는 내용입니다. 개발자는 본질적으로 어려움에 도전하는데 성취욕이 강한 사람들이고 고도로 높은 지식과 열정이 있기 때문에 인터페이스가 어지간히 어려워도 신경쓰지 않으며 자신들이 모두 컨트롤 하기를 바란다는 거죠.. 그리고 그런 개발자들이 설계한 인터페이스 때문에 많은 사람들이 소프트웨어 관련 제품을 사용하기 어렵다는 것입니다.

쿠퍼는 "정신병원에서 나온 디자인"을 UI아키텍쳐를 설계하는 디자이너들을 위해 썼습니다. 디자이너들은 대체로 개발자들에게 발언권에서 밀리고 그렇게 될 수 밖에 없는 상황인 경우가 많은데 그럴 경우 디자이너들에게 개발자들은 이러이러한 사람들이니 이런 식으로 설득하지 않으면 안되다는 것을 책의 지면의 1/3이나 할애하고 있죠..-_-;;

그렇기는 해도 쿠퍼 본인이 높은 수준의 프로그래머이기 때문에 자신을 통찰하면서 소프트웨어 엔지니어들이라고 불리우는 집단에 대해 일종의 문화적 특징에 대해 기술했습니다. (저를 포함한) 많은 개발자들이 무책임한 비개발자들의 참견으로 낭패본 경험이 있고(주로 야근..-_-;;) 대부분 책임감이 강한데 상대가 직급이 높아도 실질적으로 그들은 책임을 지지 않는다고 생각하기 때문에 의사결정에서 그들의 의견을 거의 반영하지 않는다는 이야깁니다. 따라서 개발자들을 설득하기 위해서는 비개발적 관점에서 접근해서(어차피 프로그래밍은 프로그래머가 가장 잘 알기 때문에..-_-;;) 그들을 납득시켜야 한다는 거죠.. 그렇지 않으면 사실상 비개발자들이 개발에 관여할 수 없기 때문에 개발자들은 자기 식으로 일하게 되고 비개발자들은 그걸 통제할 능력이 없다는 겁니다.

쿠퍼는 자기 책에 개발자들은 대체로 직급은 낮지만 실질적으로 가장 큰 영향력을 행사하게 된다고 써놨습니다. -_-;; 무슨 헛소리야!라고 반론하실지 모르지만 쿠퍼 이야기 들어보면 대충 납득은 갑니다. 적어도 10년차 개발자가 나 못합니다라고 하면 어쩔 수 없으니까요..
저장 취소
[코멘트] 좋음
2008-02-01 19:36
 sthouse  sthouse님께 메시지 보내기sthouse님을 내 주소록에 추가합니다.sthouse님의 개인게시판 가기 
이용석님 감사합니다.. ^^

이 책이 그런 내용이라면 책이 말하는 내용 중 프로그래머들의 문화적 특징등에 대해서는
어느정도 수긍을 합니다. 하지만 프로그래머들 때문에 UI가 엉망이됐다라는 주장에 대해서는 공감할 수 없습니다.

새로운 프로젝트를 시작하게 되면 여러가지 단계를 거쳐 제품을 생산해 내겠죠.
요구사항분석/설계/개발/테스트 등등등...
그러면 디자이너는 어느 단계부터 참여를 하면될까요?
현실적으로 보면 보통 설계와 개발 전단계 또는 개발과 같이 디자인이 이루어집니다.
이런식으로 디자인이 이루어지다 보니 시야가 굉장히 좁더라는 겁니다.
프로젝트 전반에 대한 이해도 부족하고 전체 요구사항과 기능들을 파악하지 못한 상태에서
디자인이 이루어지는 경우가 많습니다. 그래서 최악의 경우는 기능에 디자인을 맞추는 경우도 생기게되죠.
이게 프로그래머의 책임임니까?

이렇게 작업이 이루어지는 가장 큰 이유는 회사에 디자이너가 부족하기 때문일거라 생각듭니다.
새로운 프로젝트가 아니더라도 할 일은 많은데 실제 디자인 작업이 아닌 일들을 시킬수가 없는거죠.

제 생각엔 프로젝트 초기부터 디자이너들이 요구사항분석/기능분석/설계 등에 참여해서
프로젝트를 이해하고 사용자를 고려한 UI를 고민해야 되지 않을까 합니다.

결론 적으로 전 UI가 그렇게 복잡하게 나온 이유는 디자이너나 개발자들의 문제라기보다 PM의 문제라고 생각합니다.
저장 취소
[코멘트] 슬픔
2008-02-02 13:43
 kkarinam  kkarinam님께 메시지 보내기kkarinam님을 내 주소록에 추가합니다.kkarinam님의 개인게시판 가기 
프로그래머라서 디자이너에 대한 생각을 다 이해하지는 못했는데.. 제 생각을 말씀드리겠습니다.

일단 저도 개발을 하면서 최대한 디자인대로 해주려고 하지만
업무를 디자인에 맞춰주기에는 일부 안맞는 부분이 있다고 생각합니다.
예를들어서 디자이너가 콤보박스에 들어가는 텍스트박스를 디자인을 위해 작게 만들어놨다고 했을 때
제가 긴 텍스트에 대비해 다시 콤보박스 폭을 넓혔거나 또는 다른 컨트롤로 대체를 해버리면
디자이너는 디자인이 이상해졌다고 반론을 할 수도 있겠죠.
(이런 비슷한 경우에 개발기간이 늦어지는 원인이 되기도 하죠)

또는 그 화면에는 들어가지 말아야 되는 기능들이 디자인을 위해 들어가는 경우도 있고요.
(이럴 구현할 경우 프로그램 진행 흐름이 끊길수도 있겠죠)
그냥 순수 디자인이라면 놔두겠는데 업무를 진행할 수 있는 기능에 디자인이 입혀지니 안고칠래야 안고칠수가 없지요.. ㅠㅜ

디자이너는 업무보다 디자인에 크게 중점을 두는것도 이해합니다만..

글쎄 이런 문제는 서로 업무도 알고 디자인도 알면 해결되지 않을까 싶습니다만.. 그럴 사람이 몇이나 될지..

그리고 저는 예전부터 고정관념이 있었는데..
대부분의 고객들은 내부처리부분도 중요하지만 말은 안해도 눈으로 보이는걸 더 중요시하는것 같습니다.
고객이 남들에게 뽐내려는 전시효과라고 할까나..
그게 프로그램이 허접해도.. 고객의 입장에서 디자인이 멋있거나 화려해보이면 대체로 만족하는 표정이더라고요..
저장 취소
[코멘트] 난감
2008-02-03 06:29
 pluto101  pluto101님께 메시지 보내기pluto101님을 내 주소록에 추가합니다.pluto101님의 개인게시판 가기 
(로긴 하게 만드네... ^^.)

S/W산업은 오랜동안 한사람의 천재가 100사람을 대체하는 재능 집약적 산업으로 여겨져 왔습니다. (요즘 처럼 노동집약 산업 아니구...)

앨런 쿠퍼가 개발자를 까는 내용이라기 보다는, 재능 없는 개발자들이 난무하여 산업 자체를 망친다는...
결국 자화자찬의 내용입니다(내가 현역으로 뛸 땐 말이징~~ 이렇게 시작하는). ^^.

자동차 산업과 S/W산업은 비슷한 구석이 많습니다.
디자인 훌륭해도 엔진 후지면 꽝, 엔진 좋아도 디자인 후지면 꽝.

근데, 조금 재미 있는 건, 자동차 디자인은 엔진 디자이너가 하지 않는데
S/W는 둘다 해야 한다는 거죠.

이건 개발자의 문제라기 보다는 S/W를 이해하는 디자이너가 부족하기 때문에 생기는 문제.

책은 읽어보지 않았지만, 발췌된 글의 문맥으로 보면

쿠퍼의 글은 자기 모순에 빠져 있군요.

한정된 시간속에 무슨 수로 북치고 장구치고 하라는 건지...

S/W 산업이 양적으로 팽창하면서, 재능있는 개발자가 점점 없어져 가는 듯한.
현시대에 대한 환멸과 구시대에 대한 추억이 글의 전부라고 말하고 싶네요.... ^^.

레이 오지(로터스 노츠 개발자, 현 MS CTO, 차기 빌 게이츠 대타)를 끝으로
당분간은 1사람 1년 6개월 만들어 세계를 제패하는 제품 만들던 시대는
종말을 고한 것 같습니다.

고집부리는 개발자 = 천재 아님 천치.... 머 이런 내용 같은뎅, 너무 심각하게 들 이야기 하시는 느낌. ^^.

개발자를 까는게 아니라, 재능 없는 개발자를 까는 거... (본인이 재능 있다고 생각하믄 별 문제 없죵)
저장 취소
[코멘트] 좋음
2008-02-05 01:06
 chiptech  chiptech님께 메시지 보내기chiptech님을 내 주소록에 추가합니다.chiptech님의 개인게시판 가기 
요즘에 한참 아키텍쳐에 관한 책들을 보는데 그 중에 괞찬은 제안인데 제안서 대신 사용자 메뉴얼을 만들라는 것입니다.
이제 저도 설계시에 메뉴얼을 만들고 UML만들고 하는 데 나름 괘않은 것 같아요.^^; 앞으로도 써 먹어 보렵니다.
저장 취소
코멘트쓰기
  좋음   놀람   궁금   화남   슬픔   최고   침묵   시무룩   부끄럼   난감
* 코멘트는 500자 이내(띄어쓰기 포함)로 적어주세요.
목록 보기   지금 보고 계시는 글을 회원님의 my Mblog >> 스크랩에 넣어두고 다음에 바로 보실 수 있습니다.  
회사소개  |   개인정보취급방침  |  제휴문의  |   광고문의  |   E-Mail 무단수집거부  |   고객지원  |   이용안내  |   세금계산서
사업자등록번호 안내: 220-81-90008 / 통신판매업신고번호 제 2017-서울구로-0055호 / 대표: 홍영준, 서민호
08390, 서울시 구로구 디지털로32길 30, 1211호 / TEL. 02_6719_6200 / FAX. 02-6499-1910
Copyright ⓒ (주) 데브피아. All rights reserved.