반응형

이번에도 겨우겨우 마친 번역작업....

하아.. 퀄리티는 어찌할거니.. ㅠㅠ


원문 : 4 Steps to a culture of performance 


http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS3666867495



전략적인 자원 사용과 할당, 최대화를 위한 가이드 라인 

구글 처럼 웹 성능에 의해 구동되는 기업들은 성능에 관심을 갖고 있는 CEO 덕분에 톱다운(top-down) 방식으로 성능의 문화를 개발한다. 그러나 대부분의 기업들은 이러한 방식을 사용하지 않는다. 종종, 회사가 전반적으로 성능에 초점을 맞춘 사업가치를 가지고 있는 기업임을 알리고, 프로세스와 인프라를 실제로 변경하고 성능 중심의 문화를 유지하려고 이해 관계자들을 설득시키기 위해 매일 성능을 모니터링 하는 것은 일하는 사람들의 몫이다. 

단계 1 : 사례를 만들어라 

당신이 성능에 대한 문화를 정착시키기 전에 먼저 동료나 상사들에게 웹 성능의 장점을 보여줄 필요가 있다. 이를 위해 사람들과 연관이 있는 비즈니스 표준을 기반으로 웹 성능과 수익 간의 명확한 연관성을 보여주는 사례를 만들어야 한다. 당신의 사이트가 몇 시간 또는 몇 분이라도 다운 되었을 경우 얼마나 수익에 영향을 미치는지 측정해봐야 한다. IT 인력들이 문제가 발생했을 때 해결하는데 얼마나 시간이 필요한지 알아봐야 한다. 그리고 당신의 경쟁사의 웹 성능과 비교해봐야 한다(그들보다 더 좋다면 잘 유지 시켜야 하고 그렇지 않다면 약점을 극복할 수 있는 기회로 만들어야 한다).

당신의 의견을 납득시킬 수 있도록 언제 어디서든지 가능한 자료를 제공해야 한다. 당신의 기업이나 또는 다른 사람들 중에서 성능과 관련 있는 성공적인 사례에 대한 예를 제공해야 한다. 당신의 사이트의 현재 로드 타임을 없애는 것이 얼마나 수익을 증가시키고 고객들의 충성도를 향상시킬 수 있는지 증명해야 한다. 성능에 대한 우선 순위를 결정할 수 있는 고객과 이야기를 하고 성능이 그들의 결과에 어떤 영향을 줄 수 있는지 찾아내야 한다. 

단계 2 : 벤치마킹을 작성하라 

당신이 비즈니스에 영향을 주는 아이디어를 한 번 판다면 그 영향을 측정하는 것도 중요하다. 이렇게 하려면 벤치마크를 작성하면 성능이 얼마나 향상되었는지 측정할 수 있고 모니터 할 수 있는 당신의 투자수익을 보장할 수 있다. 

단계 3 : 목표를 전달하고 다시 알려라 

우선순위로 성능 모니터링을 구축함으로써 당신은 사이트의 향상된 속도, 신뢰도 그리고 수립된 벤치마크를 이용해서 유효성을 추적할 수 있다. 또 이런 성공적인 상황을 팀 동료와 상사에게 전달하는 것도 필수적이다. 진행 상황을 보여줌으로써 당신의 주변사람들을 기운나게 하고 더 나은 최적화 전략을 찾도록 촉구할 수 있다. 

단계 4 : 성능에 대한 태도를 서서히 주입시켜라 

사이트의 성능을 향상시키는 것은 훌륭하고 좋은 일이다. 그러나 당신이 완료라고 말할 수 있는 시간은 절대 오지 않는다. 성능은 여행이지 목적지가 아니라는 것을 기억해라. 향상을 위한 여지는 항상 존재할 것이다. 

즉, 하나의 단일한 프로젝트를 완료하는 것보다 성능에 대한 문화를 확산시키는 것이 중요하다. 당신의 팀은 성능을 지속적으로 측정해야 하고 목표를 수정하고 향상시키기 위한 더 많은 영역을 찾아야 한다. 

또한 온라인 환경의 변화에 대해 철저한 조사가 지속적으로 필요하다. 새로운 변화가 사이트의 로딩 시간에 영향을 주는가? 새로운 마케팅 기술이 사이트에 위험을 초래하는가? 장소의 변화에 대응하여 효과적으로 확장할 수 있는가? 

성능에 대한 인식을 갖도록 하는 것이 중요하다. 앞에서 말한 질문들은 의사결정 절차의 한 부분이 될 것이다. 그리고 이런 일들이 일어나서 뒤로 돌아가 바로잡기 보다는 그전에 당신과 당신의 팀원들이 가능한 문제들을 예측할 수 있도록 도와줄 것이다. 

성능에 관한 문화는 비싼 인프라의 투자를 의미하는 것이 아니다. 오히려 성능 문화는 기업이 그들의 자원들을 더 효과적이고 전략적으로 극대화 하고, 할당해서 영향력을 발휘할 수 있도록 도와줄 것이다. 그러나 무엇보다 중요한 점은 최종 사용자 경험에 대한 변함없는 관심이다. 최종 사용자 경험에 대한 잠재적인 영향은 모든 웹사이트와 관련된 결정과 제안된 변경사항들 안에서 가장 먼저 생각해야 할 부분입니다. 

성능문화를 만들고 유지하는 것은 시간과 노력이 필요하다. 그러나 충분히 해볼만한 가치가 있다.

728x90
반응형
반응형

양도 많지 않았는데.. 너무 오래 걸려버렸다.

한 2달 반 넘게 걸린듯... 그래서 이번 전반기에는 이거 하나밖에 못하겠네.. 


원문 : The reason everyone should learn to code 


http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS2204135551



우리는 왜 모든 사람들이 코드를 배우기를 원하는 것일까요? 이건 분명히 코더를 양산하겠다는 의미가 아닙니다. 저 또한 모든 사람이 코드를 배울 것이라는 망상도 없습니다. 이런 일은 일어나지도 않을뿐더러 일어나서도 안됩니다. 

그러나 슬로건이 말하고 있는 근본적인 근거는 슬로건 자체가 아니라 슬로건이 가능하냐 입니다. 나는 Bloomberg 시장이 Python을 배웠는지 안 배웠는지에 전혀 관심이 없습니다. 단지 그의 새로운 경력에 도움이 되기를 바랄 뿐입니다. 그러나 그가 프로그래밍 기술에 상관 없이 그의 일을 잘 해낼 거라 생각합니다. 내가 좀더 관심을 갖는 것은 "모든 사람이 코딩을 해야합니다"라는 슬로건에서 직접 파생된 Black Girls Code 같은 단체입니다. 

단지 흑인 소녀들이어서 일까요? 그 점에 있어서는 흑인 소년들도 마찬가지 입니다. 왜냐하면 정확한 기사의 초점은 가난, 빈곤은 상속된다는 점이기 때문입니다. 만약 당신이 도심의 학교에 다니는 가난한 흑인 소년이라면 당신의 경력은 맥도널드나 월마트 같은 최저 임금을 주는 곳 밖에 없을 것입니다. 

코드를 배우는 것은 가난의 굴레를 깨버릴 몇 안 되는 방법 중의 하나입니다. 80년대 초에 흑인 친구 한 명이 “프로그래밍에 대한 정규 교육 없이 소프트웨어를 개발하러 가는 마지막 세대라서 슬프다”라고 말한 적이 있습니다. 그러나 그것은 틀린 말이었습니다(그는 Stanford를 졸업했지만 CS는 아니었습니다). 그 후 매년 그게 잘못된 것이라는게 입증되었습니다. 컴퓨터에 대한 정규교육이 관련 없는 것은 아니지만(이건 별게의 문제입니다) 이게 절대적으로 필요한 것도 아니고 당분간 실현되지도 않을 것입니다. 그리고 웹 상점, 사무실, 또는 어디서든지 간에 그들의 직업들은 맥도날드와 월마트의 최저 임금보다 훨씬 좋습니다. 

그리고 이것은 중요한 점입니다. 왜냐하면 대학을 나오지 않은 채로 가난의 고리를 끊을 수 있는 다른 좋은 방법이 없기 때문입니다. “법을 공부하는 흑인 소녀들”, “은행에서 일하는 흑인 소녀들” 과 같은 사례는 없습니다. 소프트웨어를 제외한 법률, 금융, 의학과 같은 모든 전문분야들은 진입하기 높은 장벽을 가지고 있고 대학 학위부터 시작을 해야 합니다. 그리고 다른 도시 아이들에게 대학은 불안정한 가치입니다. 4년동안 당신을 지원해줄 수 있는 재정지원패키지로 좋은 학교에 들어간다 하더라도 부모님이 일자리를 잃거나 병을 얻게 될 수도 있고 당신이 갑자기 직장을 그만둬야 할지도 모릅니다. 

코드를 배웠다 하더라도 확실히 가난은 기술경력에 많은 어려움을 줍니다. Anil Dash는 기업문화에서 성공을 하기 위해 소수자들이 배워야 하는 다른 코드들과 성공에 필요한 기업문화의 변화에 관련된 글을 썼습니다. Dash가 언급한 요점은 정말 중요합니다. 바로 코드를 배우는 것이 사회적 유동성에 무료 티켓을 제공하는 만병통치약이 아니다라는 점이죠. 

그러나 Dash의 문화적 기술에 대한 주장에도 불구하고 코드를 배우는 것이 도시나 시골의 빈민들 또는 3세계의 빈민들에게는 최고의 선택으로 여겨집니다. 나는 프로그래머들이 다른 영향을 받지 않고 그들의 특권을 가지고 있는 영역에 대한 걱정에 다소 즐겁습니다. 슬로건 이외에, 대부분의 사람들이 코드를 배우지 않을 것이라는 많은 이유 만큼이나 직업관련 기술로 코드를 배우는 것을 제외하는 많은 이유들이 있습니다. (문화적 지식도 이유 중 하나입니다.) 코더들이 많아서 일까요? 그것은 문제가 되지 않습니다. 피부색이나 백인 남자 프로그래머의 문화적 습관에 따라 공유하지 않는 코더들 때문일까요? 그런 사람들은 데려오십시오. 더 많은 사람들이 필요합니다. 

모든 사람들이 코드를 배우는 것이 코더를 양상한다는 의미가 아니라는 것이 요점입니다. 10살이 되는 동안 프로그래밍을 해보지 않은 사람들 중에 재능있는 사람을 찾으려는 것입니다. 코드 학습이 필요하거나 시작할 방법을 찾지 못한 사람들에게 교육을 제공하고 그들의 창의성을 활용하는 것입니다. 이것은 그들이 해결하기를 원하는 문제이기도 하며 현재 불쑥 나타난 신생기업보다 중요합니다. 나는 도심에 사는 아이들이 자바스크립트나 파이썬을 가르쳐줄 사람들 찾는 것보다 여름 농구 캠프를 보내기 위한 장학금을 받는게 더 쉽다는데 동의합니다. 우리는 그것을 고쳐야 하고 또 고칠 수 있습니다.

728x90
반응형
반응형



폴리글랏 프로그래밍

저자
임백준 지음
출판사
한빛미디어 | 2014-03-03 출간
카테고리
컴퓨터/IT
책소개
이제 프로그래머는 어느 언어 하나에 안주할 수 없다. 패러다임을...
가격비교



폴리글랏이 뭐지?


폴리가미(polygamy) : 한 사람이 여러명의 배우자와 함께 살아가는것

폴리글랏(polyglot) : 여러개의 언어를 사용하는것. (28페이지 오타네요)


개발을 하다보면 확실히 프로그래머라는 직업은 어느 하나의 언어만 알아서는 안된다는 생각을 하게 된다. 

그리고 실제 개발 현장에서도 그것을 당연하게 여긴다.

가장 무난한 예로는 자바 + 자바스크립트 + sql 정도는 기본 셋트라고 볼 수 있다. 

"나는 서버사이드만 개발할거야, 나는 웹페이지만 개발할거야, 나는 쿼리만 짜주면 되지."

이런 말을 했다가는 쫓겨날지도 모른다. -_-;


이런것 때문인지는 몰라도 예전에, 아니 지금까지도 고민하고 있던것이 "스페셜리스트"이냐, "제너럴리스트"이냐다.

하나만 파고들어서 정말 전문가가 되느냐, 아니면 이것저것 두루두루 알고 있느냐.


그런데 지금의 추세는 아마도 제너럴 리스트 + 약간의 고급기술을 사용할줄 아는 그런 개발자들이 인정받는것 같다. 그래서 이런 폴리글랏 프로그래밍이라는 말도 나왔을것 같다. (내 생각임)


또 하나 중요한점은 얼마나 다른 언어를 빠르게 습득해서 적응하고 적용시킬줄 아느냐가 관건이 되었다. 

프로젝트 내에서도 그런 모습들은 자주 관찰해 볼 수 있다. 똑같이 교육받고 온 후배들이 프로젝트가 진행됨에 따라서 그 능력이 차이가 나는것을 뚜렷히 볼 수 있다. 또 반대로 개발이 많아서 경험도 많지만 기존의 개발 방법에 너무 익숙해진 나머지 새로운 프레임워크나 UI를 개발하는 툴에 대해 적응을 못하는 분들도 많이 봤다. 그렇기에 프로그래머는 항상 새로운것을 익혀야 하고 공부해야하고 적응력을 높여야 하다는 말을 듣는다. 어떻게 보면 참 피곤한 직업일 수도 있다. (이건 끝이 없으니깐..하아...)


그래도 이렇게 하루하루 개발을 하고 있는것은 새로운 개발 방법에 대한 즐거움과 한줄 코드에 대한 짜릿한 매력, 그리고 바꿔말하면 항상 무궁무진한 가능성이 열려있다는 점이 아닐까.


책 표지에 나온 수많은 언어들. 그리고 책에 나온 자바, C#, 스칼라. 

나는 주로 자바를 개발했기에 C#이나 스칼라는 잘 모른다. C++까지는 해봤는데 C#은 하라고 하면 아마도 다시 책을 계속 찾아봐야 할것이다. 스칼라는 얘기는 예전부터 많이 들었지만, 들여다볼 시간이 없었다.(핑계인듯 -_-);

목차를 나눠서 언어에 대한 생각, 경험등이 책안에 써있지만 역시나 말하는것은 한가지 인것 같다.


"다양한 언어에 대해서 빨리 학습하고 적용할줄 아는 개발자가 되자"


아주 간단하고 명료한 주제다. 하지만 그 넓이가 어찌나 넓은지..

프로그램을 공부하고 있는, 또는 프로그래머를 꿈꾸는 사람들은 한번쯤 고민해보고 생각해 봐야 할것이다. 단지 화면에서만 보이는 빌게이츠나 스티브 잡스만 쫓을게 아니다. 왜냐. 세상에는 빌게이츠나 스티브 잡스보다 그 밑에서 그들을 도와 개발을 하는 사람들이 훨씬 많기 때문이다. 그래서 이책은 그런 분들에게 추천해주고 싶다. 임백준님 책들이 항상 읽어보면 내 이야기 같고 하는 느낌을 잘 받을 수 있어서 감정이이도 잘 될것이다. ^^


그런데 확실히 모르는 언어가 있어서 그런지 책을 읽을때 집중력이 떨어진다. 자바야 내가 아는것이기에 그렇다 치지만 다른 언어들에 대한 이해가 떨어지다 보니 실제 언어에 대한 내용에서는 읽기가 힘들었다. 그래서 그런 부분들은 약간이라도 언어에 대한 이해가 필요했다는 생각이 들었다. 








728x90
반응형
반응형

그래프, 정렬, 트리등 알고리즘은 대학교때 들었던 강의 이외에는 책을 통해 들어본 적이 거의 없는것 같다. 단지 관심은 많이 가지고 있었지만 실제로 어떻게 공부를 해야 하는지도 몰랐다. 그래서 이번 기회에 얄팍한 지식을 넓혀보고자 “사전처럼 바로 찾아쓰는 알고리즘"이라는 책을 선택 했다.

 

장점
- 책이 두껍기에 비해서 굉장히 가볍다. 아마도 종이가 가벼운 종이(보통 외국 원서 소설책종이)로 되어 있어서 그런것 같다.
- 내용에 대한 설명과 그림들이 적절히 배치되어 이해를 도와준다.
- 각각의 알고리즘에 대한 분석 및 활용, 결과 등에 대한 내용이 자세하게 설명되어있다. 비교 분석 데이터까지 상세히 적어 놓았다.

 

단점
- 내용을 이해하는데 쉽지는 않다. 좀더 세심하게 볼 필요가 있다. 수학적 지식도 필요한 부분이 있다. 공식이 자주 등장하기 때문에.
- 종이 색이 한가지 색이다 보니 소스코드 부분과 설명 내용, 공식을 적어놓은 부분이 아무래도 가독성이 떨어진다. 특히 소스코드 부분은 네모 상자라도 만들어 줬으면 좋았을 것 같다. 
- 가볍게 읽을 수 있는 책은 아니다. 레퍼런스로 사용하면 좋을 것 같다.

 

위에서도 언급했지만 소설책 처럼 그냥 술술 읽어가는 책은 아니다. 대학 교재로 사용해도 괜찮겠다는 생각이 드는 그러한 책이다. 수학, 프로그래밍, 통계,  알고리즘등에 대한 기초 지식이 있다면 더욱 유용한 책일 것 같다. 하지만 그냥 알고리즘은 뭐다~ 라는 생각을 가지고 시작하는 초보자들이 읽기에는 내용이 상당히 어려울 것 같다. 

728x90
반응형
반응형



DSLR 사진 강의

저자
김주원 지음
출판사
한빛미디어 | 2011-09-08 출간
카테고리
예술/대중문화
책소개
오로지 당신만을 위한 1:1 사진 과외!사진가 김주원이 10년 ...
가격비교 글쓴이 평점  


나는 카메라를 가지고 있다. 물론 DSLR은 아니다. 일명 똑딱이라고 불리는 컴펙트 디카이다. 하지만 분명 사진 찍는것을 좋아한다. 왜? 내눈에 담고 싶은 장면을 오랫동안 기억하기 위해서이다. 아무 생각없이 눌렀는데 멋진 사진이 나온다. 멋지게 찍고 싶은데 찍고 나니 영 마음에 안든다. 마치 머피의 법칙처럼 말이다. 이 책은 그것에 대한 해결책을 어느정도 제시해주고 있다. 


장점

- 우선 다양한 종류, 다양한 주제의 사진들이 많이 실려있다. 단지 사진 뿐만 아니다. 그사진을 찍었을 때의 카메라 셋팅등의 촬영정보나 촬영 포인트등이 있어서 이 사진이 어떻게 나왔다는 것을 알수 있다. 

- 빛, 색, 프레임, 느낌, 이야기등을 주제로 나눠서 설명을 해줬기 때문에 독자가 쉽게 찾아볼수 있다.

- 책 처음에 사진에 앞서 카메라의 기본 지식을 설명해줘서 무작정 카메라들고 사진찍는것보다는 도구에 대한 지식을 알게 해줘서 다시한번 자신의 카메라의 기능들을 살펴보게 한다.


단점

- 사진을 찍기위한 책이라기 보다는 사진전을 간 느낌이 더 강한것 같다. 물론 기술적인 설명들이 있긴 한데 초보자인 나에게는 많이 와닿지가 않는다.

- 사진만 보여주는것이 아니라 사진을 찍었을때의 동작들도 그림을 넣어서 설명해줬으면 좋았을것 같다.


내가 모르고 찍었던 사진들을 다시 보게 하는 책이다. 그냥 찍어서 좋으면 좋고 안좋으면 다시 찍고 하는 생각보다는 처음부터 느낌있는 장면을 담아 낼수 있도록 알려주고 있다. 또 책 처음에 나오는 카메라에 대한 정보를 읽으면서 내가 가지고 다니는 똑딱이를 다시 천천히 기능부터 살펴보게 되었다. 그냥 무조건 자동만이 아닌 메뉴얼 기능도 살펴보고 사진도 다시 찍어보게되었다. 한마디로 책이지만 그냥 읽는 책이 아닌 독자를 움직이게 하는 책이었다는 느낌이 든다. 



728x90
반응형
반응형



파워포인트 2010

저자
이상훈, 김연희 지음
출판사
한빛미디어 | 2011-05-11 출간
카테고리
컴퓨터/IT
책소개
프레젠테이션, 당당하게 준비하자! 대한민국 1호 MS 파워포인트...
가격비교 글쓴이 평점  


파워포인트라는 툴은 이제 직장인에게는 없어서는 안될 툴이 되어가고 있다. 모든 발표자료는 대부분 파워포인트로 만들어지고 있다고 해도 과언이 아니다. 하지만 그 툴의 기능을 100% 활용할 수 있는 사용자는 과연 몇이나 될까 의문이 든다. 제목에서 알수있듯이 2010. 파워포인트는 지금까지 계속 변해왔고 변해오면서 많은 기능들이 추가되었다. 나 또한 그 기능들을 다 사용하지도, 알지도 못한다. 바로 나와 같은 독자들에게 이 책은 기본 지침서와 같은 역할을 톡톡히 해줄것이다.


장점

- 툴 사용에 대한 책인 만큼 화면을 캡쳐해서 설명해 놓은 부분이 많은데 각각 번호를 붙여서 설명해 놓아서 독자가 쉽게 따라할수 있다.

- 파워포인트 툴과 관련해서 프레젠테이션 방법이나 실무에서 경험한 유용한 팁들이 부록으로 따로 적혀있어서 독자에게 유용하다. 


단점

- 책 중간중간 단축키에 대한 내용이 나오는데 단축키에 대한 내용이 부록으로 추가되어있었으면 좋았을것 같다. 단축키 찾기가 힘들다.

- 캡쳐 화면이 많아서 좋긴한데 중간중간 보다보면 너무 산만하다는 느낌이 들때가 있다. 캡쳐화면이 많은데 글자도 많은 페이지들이 상당히 많다. 

- 예제로 사용한 슬라이드의 디자인이 좀 구식이다라는 느낌이 든다.


책을 보면 알겠지만 초보들에게는 기본 가이드가 되기에 충분하고 파워포인트에 대한 지식이 있는 사람들에게는 레퍼런스로 사용하기에 충분한 책이다. 부록 시디 안에 있는 디자인 소스등을 활용해서 파워포인트를 작성할때 유용하게 사용할 수도 있다. 그리고 앞에 장점에서도 말했지만 프레젠테이션에 대한 실무적인 내용들은 이책을 돋보이게 해줄 장점이라고 할수 있겠다.




728x90
반응형
반응형



프로그래밍은 상상이다

저자
임백준 지음
출판사
한빛미디어 | 2008-09-01 출간
카테고리
컴퓨터/IT
책소개
이 책은 저자가 마이크로소프트웨어, 경영과 컴퓨터 등에 기고했던...
가격비교 글쓴이 평점  


프로젝트를 참여하면서 한참 생각이 많아지고 있다. 

  과연 내가 무엇을 하고 있는지, 프로그래머라는 길을 가는것이 맞는지 조차 의문이 드는 시점에 이 책을 읽기 시작했다. 짦막한 각각의 이야기로 엮어진 이 책은 저자이신 임백준씨가 직접 경험했던 일들을 에세이 형식으로 보여주고 있다. 아마도 현장에서 겪은 일들에 대한 이야기이기 때문에 나에게는 더 직접적으로 와 닿는것이 많이 있었다. 내용도 기술적인 부분, 상황에 대처하는 부분, 프로그래머라는 사람들이 어떤 생각을 가져야 하는지, 등등으로 상당히 다양하게 적혀있다. 처음에는 이 책이 두껍다, 내용이 많다라는 느낌을 받지 않았는데 읽다보니 참 많은 내용이 적혀 있구나 라는 생각이 들었다. 


  책에 이런 내용이 적혀있다.

" 프로그래머에게 가장 즐거운 놀이는 프로그래밍이다. 전혀 이상하지 않다. 잘 어울리기까지 한다. 이런 점에서 보면 프로그래머는 의사, 판사, 국회의원같은 직업군보다 영화배우, 가수, 화가라는 직업군에 더 가깝다. 일과 놀이의 경계가 불분명 하다는 측면에서 말이다"

  직업이지만 놀이일수 있는 것이 프로그래밍이다. 정말 맞는 말이다. 나 또한 짜증날때도 있지만 하나하나 찾아가면서 코드 한줄 적는것이 재미있다고 느낄때가 있다. 거기에서 나에게 뿌듯함도 느낄때도 있다. 중요한것은 그 즐거움을 계속 유지 하느냐 아니면 유지하지 못하느냐가 아닐까라는 생각이 든다.  그 즐거움을 유지 못하면 그것은 어느새 나에게 스트레스로 돌아와 프로그래머라는 직업에 환멸을 느낄 것이고 그렇지 않다면 나이를 먹어서도 충분히 새로운것을 찾아 도전하는 멋지고 능력있는 프로그래머가 되어있을 것이다. 

728x90
반응형
반응형

어렵게 어렵게 번역한 기사.... 내용은 어렵지 않았는데.. 점점 게을러져서.. 이번에도 기간이 딜레이 됐구나..


원문 : Not Your User’s Problem 

http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS4920798014



사용자 문제, 비즈니스 요구사항, 솔루션의 차이에 대한 이해가 필요합니다. 

 먼저, 제가 요즘 보고 있는 Customer Development, Early user Research, Product Market Fit에 중점을 두고 말하는 것임을 미리 알려드립니다. 이에 따른 제 의견에 혼란이 발생하는 것을 원치 않습니다. 

제가 명확히 하려고 노력했던, 또는 뭔가를 추가할 수 있었던 제품 개발 프로세스의 초기에 팀에서 본 특정 유형의 논란이 있습니다. 우리는 그것을 같이 보게 될 것입니다. 

일부 사람들은 비즈니스 요구사항과 사용자 문제, 그리고 솔루션의 차이를 이해하지 못하는 것 같습니다. 그러나 이것에 대한 이해가 분명히 필요합니다. 그렇지 않으면 잘못된 제품을 설계하거나 잘못된 연구를 수행하게 될 것입니다. 

비즈니스 요구사항 

아주 간단히, 비즈니스 요구사항은 회사가 그 제품에 바라는 것을 말합니다. 이것은 종종 변화가 필요한 형태나 큰 돈을 모을 수 있는 새로운 기능이나 제품을 어떻게 만들 것인가에 대한 가설로 표현됩니다. 

여기 비즈니스 요구사항에 대한 몇 가지 예가 있습니다.

  • 좀더 많은 사람들이 우리의 제품을 찾도록 방문페이지의 전환율 향상. 

  • 더 많은 위젯들의 판매에 의한 수익 향상 

  • 현재 사용자들이 우리 제품을 홍보함으로써 더 많은 사용자들이 등록하도록 유도. 

  • 사람들이 사용자가 될 가능성이 높기 때문에 우리제품에 대한 참여율을 향상시켜야 함. 

  • 수익을 창출할 수 있도록 거대한 사용자공간 기반을 구축

이들 비즈니스 요구사항들에 관련된 흥미로운 점은 무엇일까요? 아마도, 어떻게든 이 모든 것들이 정확하게 실행된다면 결국 우리의 수익이 늘어나거나 비용이 줄어들 것입니다. 우리는 성공할 수 있는 업무들을 가지고 이러한 일들을 할 필요가 있습니다. 그러나 이것들을 수행하는 여러 가지 방법들은 사용자에게 유용한 것도 있고 그렇지 않은 것들도 있습니다. 

업무상 필요를 정의하기 위해서는 기본적으로 양적인 데이터가 있어야 합니다. 그리고 당신의 지표들을 수행하기 위해 어떤 것들이 우선순위를 갖는지 알 필요가 있습니다. 당신은 사용자들과 대화를 통해서는 비즈니스 요구사항을 알아낼 수 없습니다. 

분명하게 비즈니스 요구사항들은 사용자 문제로부터 발생됩니다. 예를 들어 당신의 보딩 프로세스가 사용하기 어렵다면 전환율은 낮을 것입니다. 그러나 비즈니스 요구사항이 전환율을 높이는 거라면 당신은 여러 가지 방법을 모색해 봐야 할 것입니다. 

사용자 문제 

당신의 사용자들은 문제들을 가지고 있습니다. 어떤 문제들은 해결하기 위해서 돈을 지불해야 하기도 하고 어떤 문제들은 정말 끔찍한 UX 때문에 발생하기도 합니다. 어떤 문제들은 심지어 문제를 갖고 있는지 조차 모르기도 합니다.

  • 여기 사용자 문제의 몇 가지 예가 있습니다. 

  • 다른 컴퓨터들 간에 문서를 공유가 어려움 

  • 특정 제품에 첫인상이 복잡하고 혼란스러움. 

  • 인터넷이 연결되어 있지 않으면 앱을 사용할 수 없음. 

  • 어떤 분이 집 주변에 좋은 미용실을 찾아서 예약하는데 문제가 있다고 함.

당신은 이 사용자 문제들이 모두 조금씩 다르다는 것에 주목할 것입니다. 첫번째 문제는 DropBox같은 회사들에게서 영향을 받았을 것입니다. 두번째 문제는 많은 제품에서 발생하는 흔한 문제입니다. 세번째는 모바일에 한해서 해당하는 문제입니다. 네번째는 여러 가지 다른 종류의 제품에 의해서 해결되어 왔고 일부는 간단한 기술로 해결되어 왔습니다. 발생할 수 있는 사용자 문제들은 수없이 많습니다. 

여기에서 공통점은 이 문제점들이 인간에 의해서 발생한다는 점입니다. 다른 공통된 요인은 실제로 비즈니스 요구사항을 실현하기 위한 사용자 문제를 해결하는 것은 보수가 없다는 점입니다. 물론 사람들을 위해 문제를 해결하는 것은 일반적으로 좋은 일이지만 문제를 해결하기 위해 돈을 지불해야 하는 문제들이 있고 그렇지 않은 것들이 있습니다.

사용자 문제를 정의하기 위해 가장 좋은 방법은 관찰하고 난 후 만들어지는 리서치입니다. 당신의 제품이나 다른 제품을 사용하는 야생의 사람들을 살펴보십시오. 그들이 다양한 작업을 수행하거나 일을 하는 모습을 지켜보십시오. 그것들이 사람들의 생활을 힘들게 만든다는 것을 이해해야 합니다. 그렇게 된다면 당신이 그들을 위해 해결할 수 있는 크고 중요한 문제점들이 보이게 될 것입니다. 

솔루션 

솔루션은 이름에서 의미하듯이 어떻게 문제를 해결하느냐에 대한 것이다. 이상적으로 당신의 솔루션은 비즈니스 요구사항을 수정하게 될 사용자 문제를 해결할 것입니다. 

여기 솔루션에 대한 몇 가지 예가 있습니다.

  • 당신과 학교 친구들을 모두 연결해주는 네트워크 . 

  • 사용자가 데이터를 입력하는데 도와주는 향상되고 능률적인 온보딩 절차. 

  • 복잡한 프로세스에 대한 동영상 튜토리얼.

문제들과 마찬가지로, 실제로 솔루션은 많습니다. 사실 사용자 문제들은 거의 대부분 수많은 솔루션을 가지고 있습니다. 이러한 솔루션들 중 일부는 다른 사람들보다 쉽게 구현할 수 있을 것입니다. 또 다른 사람들보다 더 좋은 방법으로 해결할 수도 있습니다. 단 하나의 정확한 솔루션이 있는 것이 아니라 다른 사람들보다 더 나은 솔루션이 존재하는 것입니다. 

솔루션을 정의하기 위해서는, 해결하려고 하는 문제에 대한 이해가 필요합니다. 그리고 기본 설계 원칙에 대한 적절한 이해와 당신의 비즈니스를 향상시킬 수 있는지에 대해서도 알아야 합니다. 이건 당신이 아이디어를 만들어내고 공유할 수 있는 프로세스의 일부분입니다. 

리서치는 문제에 대한 정확한 솔루션을 알려주지 않습니다. 당신이 원하는 만큼의 사용자들에게 그들이 경험한 문제들을 어떻게 해결하는지 물어볼 수 없습니다. 만약 그들이 해결 방법을 안다면 당신은 필요없는 존재가 될 것입니다. 리서치가 알려줘야 하는 것은 문제에 대한 더 나은 통찰력을 주는 것입니다. 

왜 걱정을 하나요? 

당신은 비즈니스 문제를 해결해야 하는지, 사용자 문제를 이해해야 하는지, 또는 해결책을 찾아내야 하는지에 따라 전혀 다른 일들을 할 필요가 있습니다. 

예를 들어, 만약 낮은 전환율 같은 비즈니스 요구를 해결하기 원한다면, 비율이 낮은 이유를 찾기 위해 사용성 테스트를 할 것입니다. 반면에 중요한 사용자 문제를 찾길 원한다면 특정 시장에 대한 사람들을 관찰하고 상황에 맞은 연구를 할 것입니다. 그리고 물론 솔루션을 만들기 위해서는 비즈니스와 사용자 문제에 대한 탄탄한 이해뿐만 아니라 확실한 설계에 대한 사고방식도 필요합니다. 

사용자 리서치를 시작하기 전에 몇 분동안 비즈니스 요구사항, 사용자 문제, 솔루션 제안에 대해 더 알려고 노력했는지 스스로에게 물어보기 바랍니다.

728x90
반응형
반응형


원문 : Putting Developers to the Test 

http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS7965279979


역시나 이번에도 허접하게


화이트 보드와 맨홀 뚜껑은 좋은 개발자를 찾는데 전혀 도움이 되지 않는다. 


 당신이 세계에서 가장 유명한 요리사 중 한 명이라고 가정해보자. CIA를 졸업하고 4성급 레스토랑을 운영하고 있다. 그리고 Food Network에서 방영하는 쇼에 출연하고 있다. 이제 당신은 실리콘 벨리에 카페테리아를 창업하기 위해 면접을 하고 있다. CEO와 간단한 대화를 마치고 그녀는 당신을 건물 밖으로 데리고 나간다. 그리고 그녀는 말한다. "나는 당신이 어떻게 일하는지 보고 싶습니다. 나에게 음식을 만들어주세요". 

"알겠습니다" 라고 대답을 하고 당신은 다시 묻는다. "주방은 어디 있나요?" 

"아니요. 나는 당신이 이 공원에서 장작을 찾은 다음에 서로 마찰시켜서 불을 만들고 창으로 사슴을 사냥한 후 그것을 불 위에 놓고 요리를 하는 모습을 보고 싶습니다. " 

나는 최근에 몇몇 회사들과 면접을 진행하면서 대부분의 기업들이 직원들의 잠재력을 평가하는데 사용하는 프로세스를 보고 웃게 되었다. 그들은 회의실에 앉혀놓고 프로그래밍과 관련된 문제를 제시하고 화이트 보드에 그것을 풀어보라고 한다. 

이것은 오늘날 소프트웨어 엔지니어가 실제로 하는 일과는 거리가 멀다. 이것은 마치 지원자에게 면접관의 초상화를 그리라고 하는 것과 마찬가지다. 나는 적어도 12가지 언어를 구사할줄 안다. 하지만 그 모든 것을 내 머릿 속에 담고 있지는 않다. 만약 내가 자바로 개발을 한다면 이클립스를 사용할 것이다. 만약 iOS 앱을 만든다면 Xcode를 사용할 것이다. 그리고 명령어, 스페이스를 치면서 메서드를 자동으로 찾아주는 기능을 사용할 것이다. 또는 javadoc을 보거나 웹에서 메서드 사용법을 찾을 것이다. 

Larry Wall은 프로그래머의 자질 중 하나가 게으름이라고 말한다. 여기서 게으름이란 작업을 완료하는데 최소한의 작업을 수행한다는 의미이다. 당신이 개발자를 구할 때 그가 얼마나 효율적인지, 그리고 얼마나 좋은 코드를 만드는지 알고 싶을 것이다. 만약 그가 검색을 통해서 5분 안에 문제의 해결책을 찾아낼수 있다면 검색 없이 몇 시간 동안 문제를 해결하려는 사람보다 더 낫다고 평가할 수 있다. 화이트 보드는 이것을 평가할 수 없다. 

내가 했던 가장 인상 깊었던 면접은 ITA에서 했던 면접이었다. 그들은 나에게 PC를 주고 개발 관련 문제를 풀어보라고 했다. 면접관은 내가 코딩을 하는 2시간 이상을 내 옆에서 지켜봤다. 나는 내 마음대로 무료로 제공하는 IDE를 다운로드 받고 웹을 검색하고 일반적으로 하는 일들을 진행했다. 면접이 끝나고 그들은 나에 대해 무엇을 알았을까?

  • 내가 문제를 풀기 위한 툴을 설치할 줄 아는가. 

  • 문제를 내가 어떤 방법으로 접근 하는가. 

  • 문제를 풀기 위해 관련된 정보를 어떤 식으로 찾는가. 

  • 내 코딩 스타일은 어떤가.

비교해서 말하자면 화이트보드에서 설명하는 방법은 요즘 개발자들이 사용하는 툴들에 대해서 정보를 얻을 수 없는 상태에서 얼마나 기억을 하느냐에 대한 테스트밖에 되지 않는다. 만약 당신이 지원하려고 하는 일자리가 인터넷이 없는 사막이 아니라면, 당신이 얼마나 좋은 개발자인지 알리기에는 부족할 수 밖에 없다. 

당신은 이것들이 나 혼자만의 의견이라고 생각하겠지만 구글 또한 그들의 수수께끼 같은 문제들을 푸는 것이 애플리케이션의 품질을 결정하는 데에 영향을 준다고 인정하고 있다. 누군가가 어떻게 일을 잘하는지에 대한 가장 좋은 지표는 그들과 함께 일을 하면서 보는 것이다. 2시간 정도의 짝 프로그래밍은 당신에게 화이트보드를 사용하는 것보다 지원자에 대한 정보를 많이 알려줄 것이다.

728x90
반응형

+ Recent posts