http://subokim.wordpress.com/2013/04/21/what-is-user/

유저학 개론

비즈니스 세계에서 소비자, 고객은 매우 중요한 요소입니다.
성공과 직결된 요소이므로 그들에 대한 연구를 게을리 하지 않습니다.

반면, 아직 인터넷 시장에서는 ‘소비자’, ‘고객’, ‘사용자’ 등이 혼재되어서 사용되고 있습니다.
하지만, 명백히 다르므로 이것을 분류해서 이해하고자 합니다.

※ 참고
1. 국부론, 김수행 역, 비봉출판사
2. 경영학의 실체, 피터드러거
3. ‘고객, 클라이언트, 소비자’ 작지만 큰 차이, 조지틸먼

---

(아이패드를 보고 있는 아기는 사용자일까, 소비자일까, 고객일까?)

1. 소비자, 사용자, 고객

• 사용자(User)
물건의 기능을 이용하는 사람
리모콘을 사용한다고 하지 소비한다고 하지는 않습니다.
제조업에서 많이 사용한다.
기능은 물건을 팔리게 만드는 가치와 직결된다.
사용자는 기능을 어떻게 만들 것인가라는 고민에서 출발한다.
• 소비자(Consumer)
물건(또는 가치)를 이용해서 사라지게 하는 사람
음식물은 먹어서 없애는 거죠. 소비한다고 합니다.
생산, 공급, 소비 (=시장)로 나뉘는 경제학에서 주로 사용한다.
• 고객(Customer)
물건(가치)을 돈을 내고 사는 사람 또는 대상.
유통이나 마케팅 등 Sales 파트에서 주로 이야기한다.

2. 서비스를 발전시키는 키워드, 사용자(User)

사용자는 기능을 사용함으로써 자신의 욕구를 해소합니다.
그래서 좋은 서비스는 기능을 자꾸 사용하도록 사람의 욕구를 건드립니다.
사람은 욕망의 화신이기 때문에, 욕구를 건드리는 서비스는 오래 갑니다.
욕망이란, 큰 것부터 자질구레한 것까지 다양한 것이 있습니다.

얼마나 어떻게 욕구를 건드리는가 하는 것이, 서비스의 존속가치를 결정하는 것 같습니다.

3. 비즈니스 모델의 키워드, 소비자(Consumer)

가치를 소비하는 사람이 있어야 생산하는 사람이 삽니다. 
돈이 돌고 도는 게 아니라 가치가 돌고도는 겁니다. Value Chain 이라고 부르지요.

가치의 흐름은 예측가능하지 않습니다. 짐작해볼 수는 있지요. 과거에는 가치의 흐름을 생산자가 예측한대로 움직이게 하는 것이 중요했습니다만, 요즘에는 가치를 누구나 사용할 수 있도록 개방하고 접근성을 높여 시장이 가치흐름을 자율적으로 만들 수 있게 합니다.

하지만 , 돈을 벌려면 역시 가치흐름은 통제 되어야 합니다.
그리고 가치흐름은 절대 혼자 커지지 않습니다. 다양한 소비패턴에 의해 증가합니다.
따라서 ‘적절한 제휴’는 비즈니스 모델 뿐 아니라 서비스의 성장에도 매우 중요합니다.

어떤 것이 소비되고 있는지를 잘 파악하는 것이 매우 중요합니다.
소비되는 가치를 발견할 수 없다면 엉뚱한 것을 생산하다가, 고비용으로 사업이 쓰러질 수 밖에 없습니다.

4. 사업을 발전시키는 키워드, 고객(Customer)

소비자는 사실 사람보다는 소비되는 재화, 가치에 집중된 단어입니다.
고객은 사람을 표현하는 말입니다. 고객은 B2C, B2B의 고객일 수도 있습니다.

고객은 돈을 지불하고 제품을 사는 사람을 말합니다.
지불과 산다는 것에 초점이 맞추어진 용어입니다.

사업이란 재화를 팔아서 이윤을 남겨서 법인과 구성원이 존속하는 것이 목적입니다.
사업은 반드시 고객이 있어야 합니다.
그래서, 고객은 바로 ‘사업의 목적’이라고도 합니다. – 피터드러거

아직 고객을 정의하지 못했다면, 일이 아직 사업단계에 진입하지 못했다는 뜻입니다.
사업을 준비할 때 고객을 정의하는 것은 매우 중요합니다.

하지만, 많은 사람들이 신규사업을 준비할 때 존재하지 않은 ‘새로운 고객’을 정의합니다.
레드오션에서 경쟁하는 것보다 블루오션을 찾는 건 누구에게나 당연합니다.

하지만, 새로운 고객을 통해 새로운 시장을 여는 것은 아이디어 하나로 만들어지지 않습니다.
현실적으로 수많은 물량공세가 동반됩니다.
2013년 애플의 설비투자가 100억달러(11조)에 달하고, R&D비용이 한해 34억달러(3.8조)에 달한다고 합니다.

새로운 사업을 준비하는 사람들을 만나보면, 고객과 소비자가 헷갈리고, 사용자와 고객을 헷갈려 하는 경우를 자주 보아왔습니다.

준비가 완벽해야 한다고 말하려는 것은 아닙니다.
다만, 위 세가지 개념을 헷갈리신다면 아직 사업할 준비가 되어있지 않은 것입니다.

더 보기»

http://subokim.wordpress.com/2012/06/20/developer-story/

개발자의 인생은 프로그램이다.

프로그래머는 자신의 인생에 프로그래밍 습관이 베어 있습니다.
왜냐하면, 프로그래머는 하루시간의 대부분을 코딩을 하다보니 무의식 중에 그렇게 살고 있기 때문입니다.

몇가지를 볼까요?

1. 통신을 하기 위해서는 프로토콜을 맞추어야 합니다.
프로토콜을 맞추지 않고, 메시지부터 던지면 통신은 되지 않습니다.
당신은 혹시 회의석상에서 메시지부터 던지시진 않나요?
2. 그리고, 스펙도 정의해야 합니다.
즉, 같은 용어는 같은 뜻이어야 합니다.
같은 말을 다르게 듣고 있지 않으신가요?
논쟁을 하거나 회의를 할 때 만일 같은 이야기가 맴돈다면,잠시 중단을 하고 스펙을 정의하셔야 합니다.
3. 일을 시작할 때는 “{” 끝날 때는 “}” 라고 하십시요.
일의 시작선언과 종료선언을 하지 않는다면, 당신은 프로그래머가 아닙니다.
“언제 시작해서 언제쯤 끝날 것 같아요.”
“끝났습니다.” 이렇게 이야기를 해야 합니다.
늦어지면, 당연히 늦어진다고 이야기해야죠. 익숙해지셔야 합니다.
4. 그리고, 전역변수와 글로벌변수를 잘 선언해서 쓰십시요.
대화하면서, “아까 그거? 아니 그거” 를 자주 말씀하신다면, 변수선언을 잘못했을 확률이 큽니다.
잠시 대화를 멈추시고, “그건 A이고, 그건 B야.” 라고 다시 선언을 하세요.
5. 일이 많고, 혼란스러우신가요?
그러면, thread 를 더 만들어야 합니다.
thread 는 멀티태스킹을 의미합니다.
thread 없이 여러 개의 일을 혼돈해서 처리하고 있다면, 분명 잘못된 결과가 나올 가능성이 큽니다.
일이 복잡해진다면, thread를 분리하십시요.
6. 혼자서 할 수 없을만큼 일이 많다구요?
프로세스를 하나 더 만들어야 합니다.
자신과 비슷한 일을 하는 사람을 데려오세요.
그렇지 않으면, 현재 돌고 있는 프로세스(당신)가 dead-lock 이 걸려서 좀비상태가 되어버립니다.
만일, 혼자 밖에 없다면 혼자서 할 수 있는 만큼만 하세요.
dead-lock이 되면, throughput 이 제로이지만 혼자서라도 처리하면 적어도 제로는 아니니까요.
7. 그리고, 가능하면 super deamon이 process들을 control 하는 방식으로 일하지 마세요.
대용량 처리가 힘들어집니다. component 를 잘 정리하고 스펙을 잘 정리해서 event driven 방식으로 처리하세요.
(잘 안될겁니다. 하지만, 성공하면 업그레이드 되는 겁니다.)
당신이 사람인 이상, super process 의 한계는 있습니다.
일욕심을 혼자 내지 마세요.
일이 늘었다 줄었다 하는 동안 프로젝트는 실패를 향해 치닫게 될겁니다.
8. 일이 잘 진행되고 있는지 모르겠다구요? Alive check를 날리세요.
물론, 규격은 사전에 합의해야겠지요.
Alive check를 하지 않으면, 업무 펑크(장애)가 나도 알 수가 없습니다.
이건 매우 중요한 행위입니다.
9. 자, 중요한 건 로그입니다.
화면이 없는 서버프로그램의 경우, 로그를 통해서만 정상작동 여부를 알 수 있습니다.
당신은 업무로그는 어디에 찍고 계십니까?
만일 팀에 당신이 하고 있는 일을 찍은 로그시스템이 없다면, 당장 JIRA 를 설치하십시요.
그렇지 않으면 wiki 라도 설치해서, 하고 있는 일의 이력을 남기십시요.
그렇지 않으면, 일이 중간에서 멈추었을 때 추적하고, 분석하고, 감지하는 모든 행위를 할 수 없게 될 것입니다.
로그를 남기지 않는 서버 프로세스는 빠르지만, 결국 유지보수할 수 없는 프로세스가 되고 맙니다.
항상 하는 일이 똑같아서 소스변경이 없는 경우에는 로그를 남기지 않기도 합니다.
하지만, 매번 하는 일이 갱신이 되는데, 업무 로그를 남기지 않는다면 이미 당신은 프로그래머가 아닙니다.
빨리 다른 직업으로 전환하시길 권유드립니다.
10. 주석을 잘 달지 않는 사람들은 두 가지 경우입니다.
아주 쉽게 말을 하거나, 대화를 잘 하지 않는 성격인 경우입니다.
아주 쉽게 말을 하는 사람은 코드가 실제 언어처럼 쉽게 읽힙니다.
따라서, 주석을 달 필요가 없습니다.
하지만, 대인관계에 서투른 사람은 다른 사람을 배려하지 않기 때문에 주석을 달지 않습니다.
전자는 고수이고, 후자는 하수이죠.
11. 프로그래머가 procedual language 에서 object oriented language 를 배우게 되면, 사고체계도 그렇게 변하게 됩니다.
은행 전산실의 사람들은 일을 순차적으로 처리하는 걸 좋아합니다.
또, cobol의 숙련도만큼 순차적 일처리가 매우 세련됩니다.
일을 잘하는 것과 사고체계가 다른 것은 분리되어 이해되어야 합니다.
자신과 카테고리가 다른 개발자들을 무시해서는 안됩니다.
우리와 맞는지 안맞는지를 판단해야 합니다.
맞지 않다면, 빨리 제자리를 찾아주는게 좋습니다.
12. 웹 프로그래밍과 서버 프로그래밍과 클라이언트 프로그래머는 사고체계가 틀립니다.
프로그래머들도 그 변화를 겪을 때 매우 많이 성장하게 됩니다.
하지만, 꼭 클라이언트에서, 웹, 서버, DB가지 섭렵해보시길 강권해드립니다.
시장에서 강자가 되려 하신다면, 적어도 1년씩은 해보시길 추천드립니다.

그리고, 당신이 프로그래머라면 지켜야 하는 당연한 것들이 있습니다.
만일 당신이 동료들과의 커뮤니케이션조차 어려움을 겪고 있다면 분명 당신은 이 업종이 적성에 맞지 않는 겁니다.

더 보기»

http://subokim.wordpress.com/2011/11/07/agile-work/

Agile하게 일하기

Agile 방법론이 대세이고, 화두입니다. (Agile = 날렵한, 재빠른, 기민한)
“어떻게 일해야 하고, 어떻게 해야 성공적일 수 있을까?”를 고민해보았습니다.

1. 왜 대세인가?
소프트웨어 제품은 만드는 것도 중요하지만, 계속해서 온라인으로 업그레이드 시킬 수 있다는 장점이 있습니다.
이것은 제품 출시 후에는 업그레이드 할 수 없는 하드웨어보다는 매우 매력적인 특성입니다.
온라인 서비스의 경우는 특히 “신규 개발”보다 “운영 및 지속적 업그레이드”가 중요한 비즈니스입니다.
하지만, 안타깝게도 비즈니스 환경이 개발자가 선호할만한 환경은 아닙니다.
1. 체계적인 요구사항이 없다.
2. 사업 환경에 따라서 구현하거나 보완해야 할 사항이 자주 바뀐다.
3. 어떤 것이 목표인지 목적인지 뚜렷하지 않다. 신기술이나 실험적인 시도도 필요하다.
4. 이런 짓을 평생 반복해야 한다.
이런 상황에 대해 분석, 설계, 개발을 엄격하게 규정짓는 Waterfall 방법론은 넌센스라고 할 수 있습니다.
Waterfall 은 “요구사항을 Fix시키지” 않으면, 이후 프로세스를 진행할 수 없기 때문입니다.
그리고, “요구사항이 변경”되면 그만큼 Roll back해야 합니다.
과거 하드웨어 중심의 프로젝트에서는 제품출시 후 변경하기 어려웠으므로, 개발 착수 전에 모든 걸 결정짓는 Waterfall 방법론이 적합했습니다.
하지만, 소프트웨어 비즈니스에서는 위와 같이 규정짓기 힘든 경우가 태반입니다.
즉, Agile 이 주목받고 있는 이유는, 소프트웨어 시장이 포화가 되어서 신규구축이 많이 없어졌고, 시장에 유연하게 대응하면서 사업을 성장시키는 노하우가 중요해졌기 때문입니다.
2. 누가 필요로 하는가?
Agile 한 환경을 누가 필요로 할까요?
Waterfall 은 버려야 할까요? 그렇지 않습니다. 방법론은 “프로젝트를 성공시키는 수단”일 뿐.
방법론을 잘 지켰다고 반드시 프로젝트가 성공하지는 않기 때문입니다.
Agile하다는 것은 “눈에 보이는 (작은)성과물을 가지고 Speedy 하게 Communication 하는 것”을 말합니다.
• Agile 은, “프로세스가 없어서 일을 못한다고 이야기하는 조직”이 해야 합니다.
프로세스를 이야기하는 조직은 대부분 큰 조직들입니다. 프로세스는 감정적인 분쟁을 억제하고, 전체적인 책임으로부터 자유롭게 해줍니다.
프로세스를 중시하는 조직에서는, Agile을 “또 하나의 프로세스”로 이해하는 경우가 있습니다.
그러나, Agile 은 일하는 방법이지, 프로세스가 아닙니다.
작은 조직이이라면, 프로세스를 논의하기 전에 Agile 한 방법을 도입해보길 강력히 추천드립니다.
큰 조직이라면 상황이 다릅니다.
• Agile 은 “매일 상황이 변하는 서비스 운영 조직”에서 해야 합니다.
작게 일을 나누고, 작게 개선합니다. 그리고, 많이 커뮤니케이션합니다.
“이야기하면서 방향을 정하고, 이야기하면서 피드백합니다.”
상황이 매일 변하므로 약속과 원칙에 얽매이면, “변화의 시기”를 놓쳐버리기도 합니다.
여기서 중요한 것은, 노하우를 기록하고 남겨야 한다는 것입니다.
Agile 은 작고 가볍기 때문에 체계가 부족합니다.
즉, 실패를 기록해두지 않으면 반복할 가능성이 큽니다.
노하우가 유사한 환경의 멤버들에게 공유될 수 있어야 합니다.
기록을 공유하는 가장 쉬운 방법은 사내 게시판을 활용하는 것입니다. 잊지 마십시요. Agile은 툴이 아닙니다.
사내 게시판이 없는 경우는 메일을 사용해도 좋습니다.
3. 어떻게 일해야 하는가?
Agile 방법론은 “프로세스”가 아니라“문화”입니다.
일하는 방식에 대한 것입니다. 형식없는 형식입니다. (무슨 도 닦는 이야기 같군요.)
• 첫째, 목표를 정하라.
진행하다가 목표가 달라지면, 연관된 것을 재점검합니다.
목표를 정하는 것은 협업의 기본입니다.
무엇을 바라봐야 할지 정하는 것은 당연합니다.
목표가 공유되지 않았는데, 이야기할 거리가 있을까요?
아무도 그 목표에 대해 고민하지도 않을거고 서로의 역할에 대해서 말하지도 않을 겁니다.
주욱, 텍스트로 적으십시요. 그리고, 그것으로 논의하십시요.
• 둘째, 기한을 정하라.
언제쯤이면 무엇을 눈에 볼 수 있는지 기한을 정하십시요.
그래서, 무엇을 평가하고 어떻게 피드백할 것인지도 사전에 공유하십시요.
“이 기능이 되면, 이런게 만족 되는지 보자.”라고 이야기하십시요.
iteration의 기본은 반복하는 것입니다. 즉, iteration 이라는 갈림길에서 어떤 의사결정을 할 것인가를 미리 공유해두는 건 매우 중요합니다.
팀원들은 그 의사결정을 할 수 있도록 충분히 준비할 것입니다.
• 셋째, 각 일의 책임자를 정하라.
애매한 것이 없도록 나누어서 맡아야 합니다.
애매한 것의 업무부담은 PM이 조절해야 합니다.
PM은 쪼개어진 일에 따라 전문인력을 쉽게 넣고 빼고 할 수 있어야 합니다.
모듈의 전문성을 높이기 위해서는 일단위의 시작과 끝을 적절히 자르는게 중요합니다.
그렇지 않으면, 한 번 투입된 인력이 오랫동안 투입되고 단위업무의 품질은 떨어지고, 전체일정의 혼란은 가중될 것입니다.
PM은 Job Load 에 대한 분배와 함께 전체 스토리가 초점을 잃지 않도록 관리해야 합니다.
• 넷째, 빠진 것이나 이슈는 bucket list로 관리하라.
iteration 을 도는 동안 test 를 하면서, 문제나 이슈가 제거되거나 완화되어야 합니다.
iteration 을 하면서 만들어진 새로운 기능이 “다른 문제를 야기”하지 않도록, Business Unit을 모듈화시키고, “Sandbox 형태”로 설계해야 합니다.
만일, exception을 발생시킨다면 다른 iteration에서 쉽게 참조할 수 있도록 document 가 있어야 합니다.
project wiki page 를 하나 만들고, 거기서 관리하십시요. 아니면, issue tracker도 좋습니다.
이슈 관리에 “메일”은 가능하면 쓰지마십시요. “메일”은 공유의 개념보다 책임 떠넘기기로 오해될 수 있습니다.
wiki 나 게시판 같이 함께 볼 수 있는 곳에 게재하십시요.
• 다섯째, 위험의 크기를 사전에 공유하라.
기일을 정했는데 변할 수 있습니다.
Feature를 정했는데 변경될 수 있습니다. 기한 내에 맡은 일을 못할 수도 있습니다.
어떤 경우든 팀원들이 빨리 위험신호를 알리고 미리 대응할 수 있게 해야 합니다.
위험을 미리 예상하여 작게 쪼개어서 점검할 수 있게 계획하십시요.
실패에 대한 부담이 적을수록, 창조적으로 일하게 된다.
기일을 못맞추면 어떤 일이 생기는지 구성원들이 사전에 공유하십시요. 위험에 대한 인식이 다르면, 협업이 힘들어집니다.
4. Agile 방법론의 종류
이 항목은 wiki 페이지를 참조하였습니다.
• eXtreme Programming 해야 할까?
무조건 우선 개발을 시작하는 방식입니다.
처음에 고객과 2주 정도 이야기하면서 컨셉을 잡고는, 우선 개발합니다.
구성원들이 시스템에 대한 이해도가 높아야 하고, 전문가들이어야 합니다.
따라서, 외주활용이 힘듭니다.
중요한 것은 자동화된 테스트 시스템이 있어야 합니다.
즉, 개발환경(테스트가 가능한)이 없으면 결과를 확인할 수 없어서 다음 Cycle에 진입할 수가 없습니다.
개발환경 하에서 짧게 짧게 Cycle을 돌면서 개발을 하는 것이므로, “기능개선 중심의 과업”에 적합합니다.
하지만, 개선효과를 금방금방 확인할 수 있으므로 신기술을 플랫폼에 도입하거나, 중소규모의 기능을 플랫폼에 추가하고자 할 때 적합합니다.
개발환경없이 신규멤버로 맨땅에서 시작하는 경우라면, XP 개발은 하지마십시요.
구성원들 간 커뮤니케이션에 혼란이 생길 것입니다.
XP 를 하기 위해서는 개발환경을 잘 갖추는게 중요합니다. 아주 빡센 개발방법입니다.
• Scrum 원래 Scrum은 한 달 단위로 한다고 합니다.
사전에 개선할 목록을 뽑고, Iteration 마다 동작가능한 결과물을 내어 놓을 수 있도록 일을 나누어 일하는 방식입니다.
매일 정해진 시간에 모여서 짧게 개발을 하는 방식인데, 오픈 소스 커뮤니티가 많이 사용한다고 합니다.
조금 느슨하므로, 구성원들의 참여의욕이 높아야 합니다. 너무 Free 해보여서 기업형 개발에는 적합하지 않을 것 같네요.
• Feature-Driven Development
도메인 객체 모델이 중요합니다. 전체 업무를 객체단위로 부품화하고, 이 목록대로 기능을 나누어서 개발합니다.
2주 단위로 Cycle 을 돌면서, 반복 개발합니다.
분석 설계를 끝나고, 개발단계 이후로 iteration을 할 수 있네요.
최근에 “아키텍쳐 개발방법”에 많이 사용되기도 합니다.
• Adaptive Software Development
이게 Agile 을 대표하는 방법론이 아닐까 싶습니다. 이 방법은 Rapid Application Development 의 확장판입니다.
이것은 상시 적용이 가능하다는 전제에서 시작합니다.
ASD는 추측, 협동, 학습을 반복하는 것인데요.
추측이란 의사결정권자들이 어떤 관점에서는 이슈를 잘못 판단할 수 있다는 가정에서 시작하는 것입니다.
학습이란, 디자인-개발-테스트를 반복함으로써 의사결정권자들이 알게하는 것을 말합니다.
ASD 는 의사결정권자들이 쉽게 결정할 수 있도록, 포인트를 나누어서 iteration을 도는 것을 말합니다.
Waterfall 방법론과 섞어서 진행할 수도 있습니다.
중요한 건, 중간 성과를 자주자주 보고하는 것입니다.
5. Agile 하게 일하지 않아야 하는 경우는?
SI 용역 프로젝트의 경우 Agile 하기 힘듭니다.
외부집단이 내부 내용까지 깊이있게 이해하기 힘들 뿐더러, 책임감이나 위기의식이 공유되기 힘들기 때문입니다.
Agile을 적용하기 힘들다면 “전통적인 Waterfall 방법론에 Agile 한 문화를 조금 섞어서” 해보길 추천드립니다.
중간 산출물에 대해 Feed-back 만 제대로 할 수 있어도 Risk는 꽤 줄어듭니다.
그러기 위해서는, PM 이나 아키텍쳐가 상세레벨까지 이해할 수 있어야 합니다.
6. 어떻게 끝낼 것인가?
Agile 은 끝이 있을까요? 취지에 따르면 끝이 없다고 봐야 합니다.
하지만, 모든 일에 끝이 없다면 멤버들은 금방 지치고 말 것입니다.
일정을 너무 내세우면 Agile 하게 일하기 힘듭니다. 실패하면 다시 해야 하거든요.
• 단위 과업의 목표품질을 가지고 이야기하십시요.
• 그 품질목표를 만족해야 단위 프로젝트가 끝나게 하십시요.
• 그 목표에 다다르기 위해 일정과 리소스를 정하고,
• 리소스을 얼마나 활용할 수 있는지 미리 예측하십시요.
만일 그렇게 한다면, Agile 은 “장기 인프라 개발”에도 꽤 유용한 방법론입니다.

※ 엮인글 : 애자일방법론
※ 참조 :

위키피디아

블로그 : Agile과 프로젝트 현실

Adaptive Software Development

더 보기»