Company, Development

Remote work

개인적으로 항상 고민하고 있는 주제이다.

remote work가 가능해지면, 많은 것들이 좋아지고 편리해지지만, remote work가 가지게 되는 Async communication 을 중요시 생각한다.

SW개발할때 중요한 것들 중에 한 가지가 몰입이다. SW개발이라는 실제로 존재하기 보다는 머리속으로 상상해서 가상적으로 만드는 작업이라 집중해서 하는게 매우 중요한데, 이 단계에 들어가기 힘들고, 깨지기 쉽다.

그래서 집중해서 작업 중인데, 동료가 와서 질문한다거나, 전화를 와서 받게 되면 집중이 흐트러지고 마는 것이다. 그걸로 다시 집중하는데 드는 시간도 시간이지만 더 큰 문제는 그 때 버그를 만들 가능이 높다는 것이다.

Async communication이 중요한 이유 중에 하나가, 이걸 하기위해서 기록을 하게 된다는 것이다. 이슈에 댓글을 남기던, 채팅창으로 대화를 하게 되던, slack의 경우에는 대화 기록이 잘 되고, 검색도 용이하다. 또 한 나중에 참석한 사람들도 이전에 만들어진 글을 볼 수 있다.

또 Async communication을 잘 하기 위해서는 코딩도 미래의 내가 알아볼 수 있고, 내가 아닌 다른 개발자가 잘 이해하도록 짜야 한다는 점이다.

이 post이 관련 글들을 수집해볼까 한다.

https://en.wikipedia.org/wiki/Distributed_development

http://blogs.atlassian.com/2013/06/devops-distributed-teams/

http://blogs.atlassian.com/2014/05/top-10-tips-distributed-development-teams/

http://www.allofsoftware.net/2014/06/blog-post.html – 개발자에게 채택 근무가 필요한 이유

http://www.itworld.co.kr/news/74908 – 성공적인 분산 개발을 위한 12가지 조언

http://profjkim.egloos.com/2109538 – SW 분산 개발이 일자리를 만든다.

https://msdn.microsoft.com/ko-kr/library/jj620910.aspx – 분산 scrum

http://tech.co/remote-jason-fried-david-heinemeier-hansson-2013-10

http://blog.outsider.ne.kr/1009 – [Book] Remote

http://besuccess.com/2014/06/hangout/ – 구글 행아웃 화상회의

http://tech.co/remote-work-culture-lessons-successful-startups-2015-08

https://spoqa.github.io/2014/08/03/remote.html – 성공적으로 사내 리모트 시스템을 도입하는 방법

http://trendinsight.biz/archives/36239 – 2014/10/19 원격근무여행

http://ppss.kr/archives/38438 – 원격근무를 하고 바뀐 삶

http://blog.weirdx.io/첫-원격근무를-해보고-느낀-점/

http://www.bloter.net/archives/233978 – 스포카 “성장배경? 리조트와 블로그 문화 덕분이죠”

https://www.atlassian.com/agile/remote-teams – Think globally, code locally: the secret to remote teams

http://www.toptal.com/remote/digital-nomads-can-manage-teams-and-manage-to-see-the-world – 2015/8

https://blog.hipchat.com/2015/07/30/4-hipchat-secrets-for-remote-teams-using-agile

기본
Company

오픈컨텐츠랩(opencontentslab) 방문

WizardFactory Team은 주로 ggihub에서 제공하는 오픈오피스에서 일해왔다.

드림엔터, 디캠프, 마루, 등 내가 가봤던 곳 중에서 시설은 단연 으뜸이다. 문제는 주말에 에어콘을 가동하지 않는다는 것이다.

곧 여름인데.. 여름 ㅠ.ㅠ

그러던 중에 TodayWeather 를 같이 하기로한 친구가 오픈컨텐츠랩을 소개해주어, 답사왔다.

첫째 에어콘 가동함!!

주말에는 10시부터 17시 30분까지 운영한다. (WizardFactory는 주말에 일하기 때문에 장소 찾기가 쉽지 않다.)

역삼 땅값이 비싸다 보니, 오픈오피스가 크지 않다. ggihub 개인 좌석공간 정도이다.

2015-07-05 10.47.00

테이블은 7개정도이고, 의자는 식당의자 스타일이다.

위치가 좀 애매하다. 역삼역에서 선릉쪽으로 올라와야 한다.

스크린샷 2015-07-05 10.54.37

실제로 아직 알려지지 않아서 인지 사람들이 많지 않다. (이것은 장점?)

그러나 에어콘이 있는 쾌적함은 다른 나쁜 점을 상쇄하고도 남을 정도로 매력적인 요소이다.

기본
Company

[책] The Goal

8983002530_1

현금 창충률, 이것은 시스템이 판매을 통해서 돈을 창출하는 비율이라네. 회계파트에서는 공헌이익이라고 부르지.

재고는 조직에서 팔고자 하는 물품을 구매하는데 투자한 총액

운영비용이란 조직이 재고를 현금창추로 전화시키기 위해 발생되는 총비용.

Dependent events and Statistical Fluctuations p164

우리 공장의 목표는 로봇의 생산성 향상이 아니오. 목표는 전체 시스템을 생산성 있게 만드는데 있다는 점을 명심하기 바라오. p234

비용을 최소화하기 위해 수요와 생산능력을 맞추려고 노력한 것이 실제로는 우리를 벼랑 끝으로 내몰고 있소. p249

생산능력과 수요의 균형을 맞추는 것이 아니라, 제품의 흐름과 수요의 균형을 맞추어야 한다는 점을 잊지 마십시오. p251

그들은 내가 숫자를 점검해주기를 원했습니다. 그 수치들은 거의 언제나 정확했다. 대신 그들이 세운 가정을 확인해보면 문제는 거기에 있었습니다. p280

공정 몇 군데의 효율성을 약간 하향조정해 전체 공정의 효율성을 생산적으로 만든다. p332

효율성을 위해 비명목자원을 가동시킴으로써 우리는 수요를 초과하는 재고를 만들어 냈다. p355

자원을 작동(Activation)시키는 것과 자운을 가동(Utilization)하는 것은 별개라는 겁니다. Activation은 시스템의 목표 달성을 위해 자원을 활용하는 것을 의미한다고 했고, Utilization은 기계의 작동 스위치를 누르는 것과 같은 단순한 개념으로 창출되는 이익과는 상관없이 일장적인 의미라고 설명했다. p358

시스템 내에 있는 모든 자원 하나하나를 최적화할 필요는 없다는 겁니다. 일부 영역에서만 최적을 추구하는 시스템은 가장 비효율적인 시스템입니다. p358

비병목 자원의 경우 시스템의 이익을 창출하는 자원의 활동수준은 자원의 잠재력에 의해서가 아니라 시스템의 다른 제약 조전에 의해 결정됩니다. p423

우리는 가동(Utilization)과 작동(Activation)을 같다고 가정했었습니다.  자원을 작동시키는 것과 자원을 가동한다는 것은 동의어가 아닙니다. p424

안전하다는 이유로 과거의 관습을 답습하는 거지. p437

그는 미리 준비해둔 질문 속에 내 질문에 대한 정답도 숨겨놓았었거든. 소크라테스식 질문방버엔 단순히 질문하는 것, 그 이상의 뭔가가 있는 것 같아. p440

상대방을 설득하는 방법, 기존의 관행을 걷어내는 비결, 그리고 변화에 대한 반발을 제어하는 기술들. p440

척도의 중요도를 바꾸어 한 세계에서 다른 세계로 옮겨간 것은 두말할 것도 없이 근본적인 조직문화의 변화를 의미하오. p486

우린 하나의 과정(병목 자원을 찾아내는 일)을 향해 나아갔습니다. 그게 바로 우리가 했던 일이죠. p488,490

  1. 시스템의 제약요인(들)을 찾아낸다.
  2. 제약 요인(들)을 최대한 이용할 수 있는 방법을 결정한다.
  3. 2의 결정에 다른 모든 것을 종속시킨다.
  4. 시스템의 제약요인(들)을 향상시킨다.
  5. 만일 4단계에서 제약요인(들)이 더 이상 시스템의 성과를 제약하지 않게 되면 다시 1단계로 돌아간다.

    ! 경고 그러나 관성이 시스템의 제약요인이 되지 않도록 한다.  p502

내게 핵심적인 문제를 밝혀 내는 방법을 가르쳐 주십시오! p539

  1. 무엇을 변화시켜야 하는가?
  2. 어떤 방향을 변화시켜야 하는가?
  3. 어떻게 변화를 일으킬 것인가? p543
기본
Company

Running LEAN (린 스타트업)

8979149697_1

랜딩페이지에서 8초 안에 고객의 관심을 끌 수 있어야 한다. p36

고객은 여러분의 솔루션에는 관심이 없다. 자신의 문제에만 관심이 있다. – 데이브 맥클루어, 500 스타트업스 p37

창업가로서 실제 해야 할 일은 시간의 흐름에 따라 체계적으로 위험을 줄여가는 것이다. p38

문제가 정말 해결할 가치가 있다면 이미 반은 이룬 셈이다. p63

제품을 사용한 ‘후’ 고객이 누릴 혜택에 초점을 맞춰야 한다. p64

가격은 여러분의 고객을 정의 한다. 여러분이 선택한 생수 가격이 고객군을 결정한다는 사실이다. p73

고객과의 상호작용은 모든 직원의 임무다. p91

제품은 단순한 기능의 집합이 아니라 사용자 작업 흐름의 집합이다. 따라서 고객의 관점에 맞게 사용자 경험을 제공할 줄 알아야 한다. p93

스타트업은 한 가지 지표에만 집중해야 한다. 그러므로 해당 지표가 무엇인지 판단하면 나머지는 모든 것은 무시해야 한다 – Noah Kagan p95

가장 비효율적인 부분을 ‘충분할 정도’로만 자동화시켰다. p97

학습을 위한 가장 빠른 방법은 고객과 이야기하는 것이다. p107

아무도 원하지 않는 것을 계속 만들기에는 인생이 너무 짧다.. p109

중립적인 100명의 고객보다 10명의 얼리어답터를 확보하는 편이 훨씬 낫다고 본다. p141

‘실제 고객 문제를 해결’하는 ‘가장 단순한’ 제품을 만들기 위해서다. p142

구매 저항을 낮추는 것보다 욕구를 유발해 강한 고객 충성도를 확보해야 한다. p142

고객이 의견을 제시했다면 그 의견을 반영할 설득력 있는 이유가 있는지 토론하라. p151

반드시 필요한 선결 기능이 아니라면, 있으면 좋은 기능들은 기능 대기 목록에 추가하라. p156

서버, 소스코드, 데이터베이스등을 최적화하는데 노력을 낭비하지 마라. 대부분 하드웨를 추가해서 시간을 벌 수 있다. p157

MVP를 구축하는 지금이 지속적 배포를 위한 기반과 업무 관행을 구축하기에 가장 적합한 시점이다. p159

제품/시장 적합성 이전의 목표는 고객 생애주기에서 문제가 있는 부분을 재빨리 파악하고 문제를 해결하는 것이다. p167

가장 강한 피드백 또는 가장 흔한 피드백에 귀 기울인다고 해서 항상 더 나은 제품을 만드는 데 도움되는 내용을 파악할 수 있는 것은 아니다. p182

시험 서비스의 목표는 지금까지 인터뷰한 얼리어답터의 80%가 전체 고객 생애 가치 주기를 거치는 것이다. p183

퍼널 단계마다 해당 단계에서 중단한 사용자 목록을 뽑을 수 있어야 한다. p184

테스터 다섯명만 있으면 제품 문제의 85%를 발견할 수 있다. p186

더 많은 기능을 더 빨리 만들어 내지 않게 주의해야 한다. p193

린 스타트업에서는 어떤 기능을 고객에게 검증을 받아야 ‘완료’한 것이다. p197

사용자의 40%이상이 제품을 더 사용하지 못한다면 매우 실망할 것이라고 답한다면 성장할 가능성이 매우 높다. p206

복잡한 제품보다는 성공적인 제품을 구축하는 법을 익히는 데 흥미를 느끼게 되었다. p215

직원들이 실험자의 입장에서 지속해서 학습하는 문화를 구축하는 것이 중요하며, 고객 가치를 창조하고 확보하는 일을 모든 사람의 임무로 간주한다. p224

모든 자원 중에서 시간보다 중요한 자원은 없다. 시간은 오로지 한 방향으로만 움직인다. p232

문제와 솔루션 둘 다 불확실한 스타트업 환경에서는 코딩을 되도록 적게 하고 더 학습하면서 반복 개선하는 것이 가장 좋다. p236

노력 중 80%는 새 기능을 구축하는 것이 아니라 기존 기능을 최적화하는데 사용해야 한다. 고객 개발의 핵심은 고객이 공감하는 MVP를 파악하는 것이다. p237

모든 노력은 인프라가 아닌 애플리케이션 구축에 집중해야 한다. p250

기본
Company

How Spotify Builds Products(스포티파이의 제품 개발 방법)

이 글은 “THE LEAN MINDSET” 에서 발췌한 글이다.

How Spotify Builds Products

Written and illustrated by Henrik Kniberg

제품 개발은 쉽지 않다. 사실 제품 개발은 대부분 실패로 끝난다. 그리고 가장 중요한 실패 원인은 부적절한 제품을 만들었기 때문이다.

스웨덴의 린 스타트업인 스포티파이는 멋진 제품을 제공하고 있다. 사용자와 아티스트들은 이들의 제품을 사랑하여, 제품은 바이럴 효과를 통해 퍼지고 있다. 활성 사용자는 2천만 명이 넘고, 그중 5백만명이 유료 사용자이며, 회사는 빠르게 성장하고 있다. 이미 기존 업체들이 많이 자리 잡은, 스포티파이 입장에서는 해외 시장인 미국에서도 서비스를 시작한지 1년이 채 되지 않아 가입자가 1백만명으로 증가했다.

제품은 쉽고 친근하고 재미있도록 설계된다. 그러나 역설적이게도 기업은 사람들이 좋아하는 제품을 제공하고 싶어 하지만, 제품을 내놓기 전까지는 사람들이 그 제품을 좋아할지 알 수 없다. 그렇다면 스포티파이는 이런 역설을 어떻게 해결하고 있을까? 이 절에서는 스포티파이의 제품 개발 방법에 대해 살펴본다.

요약

스포티파이의 핵심 철학은 다음과 같다.

  • 조기에 저렴한 비용으로 프로토타입을 만들어 리스크를 관리하는 동시에 혁신적인 제품을 만든다.
  • 출시 예정일이 아니라 품질을 기준으로 출시 여부를 판단한다.
  • 출시 이후에도 계속 제품을 수정하여 훌륭한 제품이 더 훌륭하게 되도록 만든다.

모든 주요 제품 이니셔티브(initiative)는 생각(Think), 구축(build), 전달(ship), 수정(tweak)의 4단계를 거친다. 그림 4-3은 아이디어가 제품이 되기까지의 흐름과 각 단계의 결과물을 보여준다.

Figure 4-3 High-level view of product flow  from  idea to product

Figure 4-3 High-level view of product flow from idea to product

  • Think It = 어떤 종류의 제품을 왜 구축할지 생각한다.
  • Build It = 실제 사용자에게 공개할 만한 최소 존속 제품을 만든다.
  • Ship It = 평가하고 개선하며넛 모든 사용자에게로 공개 범위를 점차 넓힌다.
  • Tweak It = 제품을 계속 개선한다. 이것이 진짜 마지막 단계이다. 제품이 폐기되거나 다시 생각(Think It) 단계로 돌아가기 전까지 계속 수정 단계에 머무른다.

스포티파이에는 30개 이상의 스쿼드(Squads)와 많은 제품이 있기 때문에, 전체 상황을 파악하고 각각의 상황을 다른 부서에 시각적으로 보여주기 위해 제품 현황판을 이용한다. 이 제품 현황판은 각 제품이 어떤 단계에 있는지 알려준다. 그림 4-4는 제품 현황판의 개략적인 모습이다.

또한, 우리는 예측 메커니즘을 실험하고 있는데, 각 스쿼드는 자신의 제품이 언제 다음 단계에 도달할지 예상 날짜 범위(X일에서 Y일 사이)를 주기적으로 업데이트 한다.

왜 4단계인가?

가장 큰 리스크는 부적절한 제품, 즉 사용자를 기쁘게 하지 못하거나 사용자 확보, 사용자 유지 같은 핵심 사업 자료를 개선하지 못하는 제품을 만드는 것이다. 우리는 이것을 ‘제품 리스크’라고 부른다.

4단계 모델을 이용하면 효과적으로 리스크를 줄이고 제품을 빨리 출시할 수 있다. 그림 4-5는 각 단계마다 제품 리스크가 어떻게 줄어들고(실선), 비용은 얼마나 들어가는지(점선)보여준다.

Figure 4-4 Portfolio board

Figure 4-4 Portfolio board

Figure 4-5 Risk-versus-cost curve for four-stage model of  product development

Figure 4-5 Risk-versus-cost curve for four-stage model of product development

여기서 볼 수 있듯이 생각 단계는 적은 비용으로 리스크를 크게 줄인다. 그리고 구축 단계를 가능한 단축시키려는 이유를 알 수 있을 것이다. 이 단계에서는 비용은 많이 들고 리스크는 거의 감소하지 않기 때문이다. 수정 단계에서 비용이 점차 줄어 드는 것은 시간이 지나면서 제품을 그다지 많이 업데이트할 필요가 없어지고 스쿼드가 다른 제품 개발로 옮겨갈 수 있는 점이 반영된 것이다.

각 단계의 길이는 다른 수 있다. 그림 4-5의 단계들의 길이 비율은 단지 예시일뿐이다. 전체 시간도 달라질 수 있다. 어떤 제품은 한두 달 만에 제품화 될수 있지만 다른 제품은 반년 이상 걸리기도 한다. 그러나 각 단계 안에서 릴리즈(내부 릴리즈일지다로)는 꽤 지속적으로 이루어진다.

그럼 각 단계를 좀 더 자세히 살펴보자.

생각단계

제품 아이디어는 항상 탄생하며 직원 누구가 제품 아이디어를 내놓을 수 있다. 아이디어 대부분은 기존 제품을 개선하는 것(수정)이며, 수정 아이디어는 스쿼드가 자체적으로 구현하고 릴리즈한다.

생각 단계는 누구나 완전히 새로운 제품 아이디어를 내놓거나 기존 제품을 새롭게 재탄생시키고자 하는 경우에 해당한다.

Figure 4-6 The Think It Stage

Figure 4-6 The Think It Stage

만약 경영진이 그 아이디어가 검토할 가치가 있다고 판단하면, 여러 기능이 포함된 소규모의 생각 스쿼드가 조직된다. 이 스쿼드는 보통 개발자 한명, 디자이너 한명, 제품 리더 한 명으로 구성된다. 이들의 힐은 제품을 정의하고 매력적인 프로토타입을 만드는 것이다.

제품 정의는 다음 질문에 답하는 짧은 문서로 표현된다.

  • 이 제품을 구축해야 하는가? 이 제품으로 어떻게 누가 혜택을 볼 것인가?
  • 이 제품은 어떤 핵심지표를 개선할 것으로 예상되는가? 이 질문은 얼마나 많은 음악이 스트리밍으로 재생되는가? 얼마나 많이 다운로되는가? 얼마나 많이 로그인하는가? 등으로 측정할 수 있다.
  • 어떤 가설이 뒷받침되어야 하는가? 이 제품이 성공적인지 어떻게 알 수 있는가?
  • 이것은 ‘큰 변화‘(즉 관련지표를 2배 이상 개선할 것으로 예상되는 제품)인가? 예상되는 지표개선 폭이 작다면 이 제품을 구축할 다른 강력한 이유, 가령 전략적 이유 같은 것이 있어야 한다.

제품 정의는 요구사항 명세서나 프로젝트 기획서가 아니다. 제품 정의에는 특징 목록이나 예산, 자원 계획 같은 것이 없다. 이것은 데이터를 바탕으로 작성된 목적 기술서와 더 비슷하다. 제품 정의에서 가장 중요한 부분은 내러티브(narrative)다. 우리는 세상에 어떤 이야기를 하고 싶은가? 보도 자료는 어떤 내용이겠는가?

예를 들어, 다음은 스포티파이의 ‘디스커버’탭의 내러티브를 보여주는 짧은 동영상에서 발췌한 것이다.

음악을 발견하는 더 좋은 방법을 소개합니다.

보세요! 여러분이 좋아하는 아티스트가 지금 막 여러분과 음악을 공유했습니다. 아티스트와 팬들이 그 어느 때보다 가까워질 수 있어요. 좋아하는 아티스트가 있습니까? 그 아티스트를 팔로하세요. 그리고 여러분이 발견한 것을 친구들과 공유하세요.

여기서 중요한 것은 제품이 만들어지기 전에 내러티브가 작성된다는 점이다! 이렇게 하면 심지어 제품을 만들기 전에 제품이 매력적인지 확인할 수 있다.

게다가 생각 스쿼드는 이 제품의 룩앤필을 실험하기 위해 다양한 프로토타입을 많이 제작한다. 종이에 그려보기도 하고 실제 작동하는 프로토타입을 만들기도 한다. 어떤 프로토타입이 내러티브를 가장 잘 보여주는지 검토하여 몇몇 후보군으로 압축하는 데는 내부 포커스 그룹이 이용된다.

이것은 기한이 없는 반복 개선 프로세스이다. 제품은 매력적인 내러티브와 그 내러티브를 충족시키는 작동 가능한 프로토타입을 보여줄 수 있어야 구축할 가치가 있으며, 이것이 얼마나 오랫 기간이 걸릴지는 미리 결정할 수 없다.

리스크-비용 곡선에서 볼 수 있듯이 생각 단계는 비용 면에서 매우 효과적으로 제품 리스크를 감소시킨다. 우리는 단지 프로토타입을 만들고 실험할 뿐이다. 이렇게 하면 안전하고 낮은 비용으로 실패를 경험할 수 있으므로, 구축할 적절한 제품을 찾을 때까지 계속 시도해볼 수 있다.

생각 단계 완료의 기준: 생각 단계는 경영진과 스쿼드 모두 제품을 구축할 가치가 있다고 생각할 때(또는 제품을 구축할 가치가 없고 제품 아이디어가 폐기되어야 한다고 생각할 때) 끝난다.

이것은 정량적인 데이터를 바탕으로 하지 않는 주관적 판단이다. 정량적 데이터는 전달 단계에서 입수되므로 최대한 빨리 전달 단계에 도달하는 것이 좋다.

구축단계

이제 생각 스쿼드는 실제 제품을 만들고 테스트하고 전달하는 데 필요한 모든 기술을 갖춘 더 장기적인 스쿼드(때로는 여러 개의 스쿼드)로 확장된다. 이 스쿼드는 구축 단계 동안만이 아니라 더 오랫동안 제품을 담당한다.

구축 단계의 목표(그림4-7)는 외부 사용자에게 릴리즈하기 충분하고 제품에 대해 뭔가를 입증하기에 충분한 MVP(Minimum Viable Product)를 만드는 것이다. MVP는 스크럼, 칸반, XP(eXtreme Programming) 같은 애자일 방법론을 접목한 소프트웨어 개발 방법을 사용하여 반복 개선 방식으로 구축된다.

이 단계에서는 그림 4-8의 표현된 것처럼 균형점을 찾아야 한다.

Figure 4-7 The Build It Stage

Figure 4-7 The Build It Stage

Figure 4-8 Minimum viable product

Figure 4-8 Minimum viable product

한편으로는 완벽한 제품을 만들고 나서야 제품을 제공하는 것은 좋지 않는데, 그 이유는 그렇게 하면 학습 기회가 늦어지기 때문이다. 실제 소프트웨어를 실제 사용자에게 전달하기 전까지는 우리가 제대로 하고 있는지 확인할 수 없으므로 완벽한 제품을 만들려고 하지 말고 가능한 한 빨리 제품을 공개하는 것이 좋다. 다른 한편으로, 우리는 쓸모없는 당황스러운 제품을 제공하기를 원하지 않는다. 우리가 베타 버전 또는 알파 버전이라고 말해도 사람들은 스포티파이가 훌륭한 소프트웨어를 만들 것으로 기대하고 우리가 릴리즈한 것으로 우리를 판단한다.

그러므로 스쿼드는 기본적인 내러티브를 충족하고 사용자를 기쁘게 할 수 있는 최소한의 제품을 알아내야 한다. 특징 면에서 완전한 것이 아니라 내러티브 면에서 완전하게 만들어야 한다. 아마 최소 호감 제품(Minimum Lovable Product)이 더 적당한 표현일지도 모른다. 자전거는 더 좋은 교통 수단이 없는 사람에게는 사랑받고 유용한 제품이겠지만 더 발전된 제품인 오토바이와는 많은 차이가 있다. 우리는 기본적인 내러티브를 반드시 충족해야 한다. 그렇지 않으면 측정 결과를 잘못 해석할 수 있다. “우리가 바퀴를 출시 했지만 아무도 사용하지 않으니 제품은 실패작이고 자전거의 나머지 부분도 안 만드는게 좋겠어!”

생각과 구축 사이의 중요한 차이점은 생각 단계에서는 가능한 모든 지름길을 택하여 기술적인 품질에 대해서는 신경쓰지 않는다. 구축 단계에서는 제품 수준의 코드를 작성하고 품질을 확보하려 노력한다.

구축 단계 완료의 기준: 구축 단계는 경영진과 스쿼드 모두 제품이 기본 내러티브를 충족하고 실제 사용자에게 공개하기에 충분하다고 생각할 때 끝난다.

이제 진실의 순간을 맞을 준비가 되었다!

전달 단계

Figure 4-9 The Ship It Stage

Figure 4-9 The Ship It Stage

전달 단계의 목적(그림4-9)은 실제로 제품이 약속을 충족하는지 측정하고 확인하면서 전체 사용자에게 제품을 점차 확산하는 것이다.

스쿼드는 우선 전체 사용자 중 일부(보통 1%~5%)에게 제품을 공개해서 데이터를 수집한다. 이런 사용자는 나머지 95~99%의 사용자와 비교할 때 어떻게 행동하는가?

생각 단계에서 제품에 대해 몇가지 가설을 세웠다는 것을 기억하라. 이제 우리는 드디어 이런 가설이 맞는지 테스트하고 필요하면 제품을 반복적으로 개선할 수 있다. 한번 만에 바로 만족스러운 결과를 얻는 경우는 거의 없으며, 이 모델의 장점 중 하나는 그렇게 할 필요도 없다는 것이다.

경영진과 스쿼드가 소규모 사용자 그룹이 제품이 의도한 가치를 느낀다는 데 동의하면, 측정과 개선 작업을 계속하면서 동시에 더 많은 사용자에게 제품을 서서히 확산한다. 이렇게 하면 하드웨어 용량, 모니터링, 배포 스크립트, 확장성 등 운영 측면의 요소를 다룰 시간을 확보할 수 있다.

전달 단계 완료의 기준: 전달 단계는 제품이 모든 사용자에게 공개하면 끝난다.

이 단계에서 제품은 아직 ‘특징이 완성’되지 않는다는데 주의하라. 전달 단계를 완료했다는 것은 단지 제품(최소 존속 제품 + 필요한 개선)이 모든 사용자에게 공개되었다는 의미이다. 특징은 완성될 수 없다. 제품은 전달 단계 이후에도 계속 개선되기 때문이다.

수정단계

Figure 4-10 The Tweak It Stage

Figure 4-10 The Tweak It Stage

수정단계(그림4-10)은 가장 중요한 단계이다. 왜냐하면, 모든 제품이 (여기까지 오는 동안 폐기되지 않았다면) 이 단계에서 끝나고 제품 주기에서 제품이 가장 오랜 시간 머무르는 단계이기 때문이다.

제품은 이제 만들어졌고 모든 사용자가 사용할 수 있다. 비록 전달 단계에서 어느 정도 입증되었지만, 개선의 여지는 항상 많이 있다. 스쿼드는 지표를 추적하면서 계속 실험하고 A/B 테스트를 하며 제품을 개선한다. 이 과정에서 소소한 수정뿐만 아니라 상당히 중요한 새로운 특징이 추가될 수도 있다.

그러나 언젠가는 제품의 수확 체감 지점에 도달한다. 이제 제품은 훌륭하고 가장 중요한 개선이 완료되었으며 새 특징을 개발하는 비용 대비 효과는 덜 매력적이다.  그리고 새 특징을 추가하고 개선해도 지표에 큰 변화가 없을 것으로 예상된다. 이는  제품이 ‘국지 극대(Local Maximum)’ 지점에 도달하고 있다는 의미이다.(그림 4-11 참조)

Figure 4-11 Local Maximum

Figure 4-11 Local Maximum

이 시점에서 스쿼드와 경영진은 “이 언덕 정상에 있는 것으로 만족할 것인가 아니면 더 높은 봉우리를 찾을 것인가?”에 대해 토의한다. 전자의 경우라면 스쿼드는 점차 다른 제품으로 이동한다. 후자의 경우에는 스쿼드는 생각 단계로 다시 돌아가 이 제품에 대해 다시 생각해보고 전역 극대(Global maximum)를 찾게 된다(또는 적어도 현재보다 더 높은 봉우리를 찾는다.). (그림 4-12 참조)

Figure 4-12 Reimagining a product

Figure 4-12 Reimagining a product

이것의 한 예가 spotify.com 웹사이트이다. 이 웹사이트는 2012년 여름, 재구축하기로 결정하기 전까지 4년 동안 조금씩 수정되었다. 이제 이 웹사이트는 완전히 달라진 훨씬 더 효과적인 방법으로 스포티파이의 비전을 전달하고 있다.

마무리

만약 이 모델의 어떤 부분에 대해 “쯧쯧, 이미 알고 있는 내용이고 오랫동안 그렇게 해왔는데…”라는 생각이 든다면 아마 여러분의 생각이 옳을 것이다. 이 모델은 ‘새롭고 멋지다’라기보다는 ‘효과적으로 작동’한다. 오래된 모델이건 새로운 모델이건 그건 중요하지 않다. 내 경우에는 여러 기법을 결합한 이 모델이 매우 강력하고 고무적이었다. 여러분도 각자의 상황에서 여러분에게 도움이 되는 모델을 찾기 바란다.

기본
Company, Development

From Agile to Design

이 글은 “THE LEAN MINDSET” 에서 발췌한 글이다.

From Agile to Design

-Written by Theresa Smith, Sphere of Influence.

애자일에서 디자인으로 옮겨가는 여정은 많은 애자일 소프트웨어 개발자들이 경험하는 까다로운 고객, 목표 명세서, 불가능한 일정에서 출발했다. 물론 애자일은 여기에 완벽히 들어맞아 보였고 우리는 애자일 개발에 뛰어들었다. 우리에게 성공이란 고객사가 요구하는 많은 기능이 작동하는 제대로 된 코드를 제 시간에 납품하는 것이었다. 고객은 프로세스의 모든 사소한 부분에 깊이 관여하여 일부가 되어 우선순위, 지침, 피드백을 제품에 매일 전달했다.

클라이언트가 중요하게 생각하는 기능이 가득 구현된 소프트웨어는 성공적으로 개발되어 고객에게 전달되었다. 이 모든 것은 거의 불가능해 보이는 일정 안에 이루어졌다. 최종 소프트웨어는 훌륭했고 우리 고객은 결과에 만족해했다.

Just One Problem : The Client Was Only Satisfied

이것은 시간이 흐르면서 경향이 뚜렷하게 드러난 많은 것들의 예에 불과했다. 우리의 애자일 프로젝트는 고객이 중요하게 생각하는 거의 모든 사항이 반영된, 높은 품질의 소프트웨어를 적당한 가격에 계속 개발했다. 이런 관점에서 애자일 기업은 업무 성능을 개선했다고 할 수 있다. 그러나 프로젝트가 아닌 제품을 평가하자면, 솔직히 말해 이런 제품에는 위대함이 없었다. 관계자들은 프로젝트 성과에 만족했을지 모르지만, 사용자가 참신한 혁신이나 창조적인 디자인에 기뻐하거나 열광하거나 엄청나게 감동받는 경우는 거의 없었다. 애자일은 고객의 우선순위에 강한 초점을 두며 JustInTime 반복개선은 이런 경향을 더 강화시키는데, 이 때문에 몰입 경험, 일체성, 호감, 심지어 혁신을 제품에 디자인해 넣으려는 어떤 노력도 상당히 힘들어졌다. 애자일에서는 소프트웨어 개발을 고객이 원하는 기능을 한 번에 하나씩 구혁하는 것으로 생각했다. 사실 전혀 그렇지 않은데 말이다.

전형적인 애자일(i.e., agile/Scrum)에는 개발할 적절한 제품을 찾는 창조적인 업무 흐름이 빠졌다는 점이 분명해졌다. 또한, 애자일은 소프트웨어 제품에 더 강력한 의미를 주는 기능 믹스, 형태, 컨텍스트, 우월성, 인지적 개입(feature mix, form, context, dominance, or cognitive engagement)을 조정하는 방법에 대해 아무런 지침도 제공하지 못했다.

Strong Centers

우리는 제품의 전체성(identity)에서 나오는 가치와 제품의 전체성을 표현하기 위해 강력한 중심(Strong Centers)이라는 표현을 쓰기 시작했다. 우리는 정해진 비용과 일정, 기능의 한계 안에서 구현하는 일이 힘든 것이 아니라, 이런 한계를 이용해 훌륭한 결과를 만드는 일이 힘들다는 점을 깨달았다. 우리가 깨달았듯이, 여기에는 애자일 환경에서 사용하는 그 어떤 프로세스보다 더 엄격한 창조적인 혁신 프로세스가 필요했다. 애자일 프로세스의 성공은 일관되고 통일된 독창적인 제품이 나오도록  프로젝트를 이끌 수 있는 신통력을 가진 제품 담당자와 관련자에 달려 있다. 그렇지만 신통력은 현식 전략이 될 수 없다. 혁신 전략은 제품에 대한 비전이 어디에서 나오고 강력한 중심과 관련된 수천 개의 결정에 어떻게 그 비전을 반영하느냐는 질문으로 귀결된다.

관심을 프로젝트에서 제품으로 돌리자 우리는 제품을 있는 그대로 볼 수 있게 되었다. 우리 제품은 특별함이 없고 단조로웠다. 우리는 고객이 ‘만족’하는 데 그치지 않고 ‘감동하고 기뻐하기’를 원했다. 따라서 우리는 변하기 시작했다. 첫째, 우리 개발스튜디오는 위대한 제품을 만들어야 할 의무가 있다는 점을 인정했다. 우리는 우리의 일이 설계를 고객에게 맡기고 단순히 고객의 이야기와 요구사항을 정확히 코드로 옮기는 것이 아니라는 깨달았다. 우리에게는 고객과 고객의 사용자가 결코 내리지 못할 결정을 내림으로써 매력적인 소프트웨어를 디자인하고 기술을 발명할 책임이 있었다. 둘째, 우리는 제품 개념 설계(product conceptual design)를 애자일 스프린트 안에서 동시에 진행되는 활동이 아니라 별도 활동으로 보고 시간을 따로 책정했다. 셋째, 우리는 신뢰받는 애자일 기법이라 하더라도 혁신과 제품 설계에 충분하지 않으며 어떤 상황에서는 실제로 이런 활동을 방해할 수 있다는 사실을 받아들였다.

Small Beginnings

우리의 고객은 제품 개발을 100%통제하는 데 익숙했기 때문에 우리는 어디서부터 시작할지 몰랐다. 첫 시도에서 작은 목표를 세우고 ‘눈에 잘 띄지 않게’, 이미 개발 중인 제품의 몇몇 부분에 우리의 설계 철학을 반영했다. 우리는 고객 주도하에 우선순위를 결정하는 경우에는 거의 주목을 받지 못하지만 제대로 만들면 달라질 것으로 생각되는 부분을 선택했다. 이런 부분은 관계자의 관심을 받지 못했다. 관계자의 관심은 더 고차원적인 비지니스 업무 흐름과 다른 중요한 것에 머물렀다.  당시 우리는 우리가 하는 일에 대해 제품 설계(product design)라는 용어를 아직 사용하지 않았지만, 본능적으로 제품 설계가 빠져 있다는 것을 깨닫고 거기로 주의를 돌렸다. 우리 고객사는 소프트웨어가 핵심 사업이 아니므로 소프트웨어에 대해 잘 모르지만, 우리에게는 스프트웨어야말로 우리가 알고 있는 전부이기 때문에 사용자 인터페이스와 알고리즘 기반 자동화에 대한 고객보다 훨씬 정교한 의견을 낼 수 있다. 이런 것에 대해 고객이 잘 모르는데도 고객에게 결정을 맡기는 대신, 우리는 제품의 몇몇 부분에 우리의 전문성을 적용했다.

제품이 성공적으로 출시된 후 우리는 고객을 대상으로 만족도 조사를 했고 이전과 마찬가지로 고객은 제품에 대해 전체적으로 ‘만족’했다. 그러나 우리가 자체적으로 만든 부분에 대해서 고객은 만족하는 데 그치지 않고 기뻐했다! 이들은 제품 전체에 대해서는 ‘만족’스러우며 기대수준에 대체로 부합한다고 말했지만, 우리가 셜정한 부분에 대해서는 환상적이며 그 부분이 ‘제품을 살렸다(made the product)’고 표현했다.  우리가 지침을 따르지 않은 것을 고객이 과연 알아차렸는지 확실하지 않았지만, 고객은 제품을 좋아했고 이것은 중요했다. 이 일로 우리는 이런 방식을 확대해야겠다는 자신감을 얻었다.

그 다음 두 프로젝트 동안 우리는 세상을 바꿀 혁신을 추구한다는 생각이 아니라, 더 정제된 제품(a more refined product)을 통해 사용자와 상호작용하고 고객의 사업을 지원할 더 좋은 방법을 찾기 위해 약간의 시간과 에너지를 쏟았다. 우리는 점점 더 프로젝트가 아니라 제품에 관심을 두게 되었다.

우리에게 지침이 되거나 열정을 불어넣어 줄 애자일 기법은 없었다. 그래서 대신 창조성과 혁신으로 유명한 업계, 즉 산업 디자인 및 마케팅 스튜디오들을 살펴보았다. 우리는 많은 시간을 들여 IDEO, Frog, Crispin Porter + Bogusky 같은 회사에 대해 연구했고 이 연구로 혁신의 최전선에 적용할 수 있는 디자인을 통해 제품을 향상시키는 아이디어와 기법을 많이 발견했다. 우리는 문화기술학(the science of ethnography)을 공부하고 이것이 어떻게 제품 개발에 적용될 수 있는지 연구했다. 또한, 사용자 인게이지먼트의 심리학에 대해 공부하고 인게이지먼트 강도를 조절하는 많은 기법을 발견했다. 소프트웨어 개발 서적만으로는 이런 것을 전혀 알 수 없지만, 적절한 곳을 찾아보면 이런 것들이 [사용할 수 있을 정도로 충분히] 발달한 형태로 존재한다는 사실을 알게 되었다.

돈을 지급하는 고객이 우리에게 제품 기능과 제품 인도일을 강력하게 요구하면 제품 구현과 납품에만 초점을 맞추고 싶은 마음이 들기도 했지만, 그래도 우리는 마음을 다잡고 상당한 시간과 에너지를 제품 설계과 혁신에 할애했다.

Making Things That Resonate

디자인 기량이 좋아지면서 우리는 우리의 철학을 다듬기 시작했다. 우리는 위대한 제품은 우선순위가 높은 기능들의 단순한 집합체 이상이라는 게슈탈트(Gestalt)관점을 완전히 수용했다. 위대한 제품에는 유사성(similarity), 지속성(continuation), 종결성(closures), 근접성(proximity), figure, and ground 을 활용한 통일된 전체성(unified wholeness)이 있다.  우리는 모든 기능과 디자인 요소는 ‘중심(center)’이라고도 알려진 통일된 전체에 영향을 주며 궁극적으로 여기에서 정체성과 의미가 나온다는 소신을 전개했다. 건축가 크리스토퍼 알렉산더(Christopher Alexander)는 저서 ‘The Synthesis of Form’에서 최초로, 그리고 나중에 나온 4권짜리 전집 ‘The Nature of Order’에서 디자인의 이런 발현적 성질을 잘 설명한 바 있다. 우리는 강력한 중심은 전체성에서 나온다는 알렉산더의 관점을 수용했다. 알렉산더처럼 우리도 강력한 중심이 없은 제품은 고객과 공감할 수 없고 강력한 중심이 있는 제품은 일반적으로 고객을 기쁘게 한다고 생각한다.

이런 게슈타틀 철학은 우리가 소프트웨어 회사의 목적을 더 분명히 이해하는 데 도움이 되었다. 소프트웨어 회사의 목적은 기능과 사용자 스토리의 우선순위를 정하는 일을 도운 다음 그대로 구현하는 것이 아니다. 우리는 우리의 목적이 강력한 중심을 가진 위대한 제품을 만드는 것이라는 것을 깨달았다. 우리는 우리 작업에 새로운 제약 조건을 적용하는 법을 배웠다. 예를 들어 기능은 강력한 중심이 드러나는 데 도움이 되는 경우에만 제품에 구현된다. 우리는 강력한 중심의 형성에 방해되는 기능은 더 이상 허용하지 않는다. 심지어 사용자가 이런 기능을 강하게 원하는 경우라도 이런 기능은 사용자가 제품에 긍정적으로 반응하지 못하도록 만들기 때문이다. 우리는 제품을 누더기로 만들지 않고도 니즈를 충족시키는 법을 발견했다.

제품이 강력한 중심을 가지도록 설계하는 법을 익히는 것은 첫 도전 과제에 불과했다. 소프트웨어 개발자로서 우리는 공감할 수 있는 사용자 경험을 설계하는 법도 알아내야 했다. 이미 사용성 공학에 대해 잘 알고 있었지만, 사용성 공학을 적용해 개발된 제품은 흐리멍텅했다. 우리는 상호작용 설계(Interaction design)란, 사용성(마우스 클릭 수를 세고 시선을 추적하는 것)을 높이는 것이 아니라, 의미를 만들고 사람들이 시간 가는 줄 모르고 현재 하고 있는 경험 외에 모든 것을 잊어버리도록 복잡한 다층 활동에 몰입하게 만드는 것이라는 점을 깨달았다. 이런 방법을 배우기 위해 우리는 사용성이나 사용자 인터페이스 디자인이 아니라 인게이지먼트 심리학 전문가들에게서 영감을 구했다. 낸시 두아르떼(Nancy Duarte)와 마가렛 로버트슨(Margaret Robertson) 같은 전문가를 연구하여 우리는 디자이너가 사용자를 참여시키고 지리멸렬함을 극복하기 위해 리듬을 사용한다는 것을 알게 되었다. ‘공명하다(Resonate)’는 단어는 제품의 자연적인 진동’vibe’이 사용자와 같은 주파수대라는 것을 의미한다. 가령 황금 비율 같이, 사람들과 근본적으로 공명하는 최적의 전이(transition)와 타이밍이 있는 것으로 드러났다. 우리는 이런 타이밍과 전이에 따라 사용자 인게이지먼트의 강도를 조절하여, 행동 심리학자 미하이 칙센트미하이가 ‘몰입경험’이라고 부르는 경험을 하도록 사용자를 유도하는 법을 알게 되었다. 또한, 게임화(Gamification)에 대해 깊이 연구하여, 사용자를 참여시키고 효과적으로 학습하게 하여 성취를 인정하고 경험을 망치지 않으면서 실패를 인정하게 만드는 미묘한 방법들을 인식하게 되었다.

Escaping Conventionality

대부분의 창조 산업에서 고객이 어떤 에이전시를 고용하는 것은 그 에이전시가 고객이 공감하는 아이디어나 스타일을 보여줬기 때문이다. 고객과 에이전시 사이에는 고객은 항상 옳다는 공감대가 형성되어 있지만, 그럼에도 불구하고 에이전시를 고용하는 것은 에이전시가 창조성, 혁신, 차별화되는 스타일을 제품에 불어넣기때문이라는 점도 양측 다 인정한다. 특정 목적을 위해 만들어진 소프트웨어를 제외한 대부분의 창조 산업은 이런 식으로 작동한다. 우리 산업에서 고객은 의심이 많고 개발 업체가 그 이상도 이하도 아닌 정확히 계약대로 개발하도록 일을 시키는데 익숙하다. 이런 상황에서는 에이전시 역할을 제대로 할 수 없고 단지 노동을 공급할 뿐이다. 폭포수 기법, 애자일 또는 다른 무엇이라 부르든 제품이 아니라 프로젝트 관리에 온통 주의를 쏟는다. 대부분의 소프트웨어 개발 회사는 프로젝트 관리 기술과 역량을 내세우며, 디자인 스타일이나 실제로 만드는 제품과 관련된 것은 홍보하지 않는다.

심지어 요즘도 우리에게 가장 어려운 과제는 프로젝트 관리에 가치를 두기보다 제품에 더 가치를 두는 고객을 만나는 것이다. 고객 대부분은 혁신적인 제품 개념에 대해 설명해달라는 요청보다는 RFQ/RFP를 통해 우리와의 관계를 시작한다. 우리 입장에서는 혁신적인 제품 개념에 대해 프리젠테이션하는 것보다 RFP에 대응하기가 더 쉽다. 어떤 개념을 설득하려면 제품 전략, 문화기술학, 포지셔닝, 개념적 디자인을 연구해야 한다. 경쟁에서 이기려면 고객이 몰랐던 가려운 곳을 긁어주는 동시에 한편으로는 고객이 절대 포기하지 않는 목표와 니즈를 만족시키는 우리 회사만의 무엇이 필요하다. 제품 개념에 들어가는 작업, 창조성, 혁신의 양은 RFP에 대응할 때보다 훨씬 많으며 고객이 누릴 수 있는 가치는 말할 것도 없다. 왜 더 많은 회사가 개발업체 선정 방법으로 개념 설명을 요구하지 않는 생각하면 심란하지만, 고객사는 개발업체에 자신이 원하는 것을 이야기하고 개발업체는 비현실적인 견적서로 대응하는 것이 현재 관례이다.

Product over Project

Peter Rowe 하버드대학 교수는 Design thinking(디자인 사고) 이라는 표현을 고안했고 IDEO의 David Kelley는 이 표현을 널리 알리고 산업 디자인뿐만 아니라 모든 창조 분야가 여기에 주목하게 하였다. 이것은 디자이너는 사고방식이 다르고 세상을 다르게 본다는 생각이다. 예를 들어 기술자는 최소한의 해결책을 찾아 문제를 해결해야 하지만 디자이너는 사용하기 좋은 제품을 만들어서 문제를 해결해야 한다. 여기에는 큰 차이가 있다. 기술자는 사람들이 제품 자체를 좋아하건 말건, 제품을 작동하게 만들고 효율적인 제품이 되게 만들고 제품을 만드는 프로세스가 효율적인 프로세스가 되게 만든다. 디자이너는 사람들이 좋아하는 물건을 만들기 위해 존재하며, 제품 사용과 제품에 대한 인식이 전반적으로 개선된다면 요소와 재료를 비효율적으로 통합하기도 한다. 솔직히 말해 우리는 기술과 디자인 둘 다에 끌렸다. 우리는 엔지니어의 영혼과 디자이너의 가슴을 가지고 있다.

우리는 우리가 하는 일을 Design thinking이라고 부르기 시작했지만, 마침내 이 용어를 쓰지 않기로 했다. 우리는 디자인을 위한 디자인의 예를 너무 많이 목격했는데, 이 경우는 미적 감각 때문에 실용성을 포기하거나 유행에 따르느라 강력한 중심을 무시하기도 했다. 우리는 미적 감각과 세련된 느낌을 좋아하지만, 또한 단순한 구식 애플리케이션이 훌륭할 수 있다는 것도 알고 있다. 우리는 위대한 디자인이라 강력한 중심을 통해 장점이 생기는 제품을 만드는 것이라고 생각한다. 또한, 우리는 단순 조립이 아니라 엔지니어링에서 우아함과 아름다움을 발견하는 골수 소프트웨어 엔지니어들이다. 이 점에 대해 생각하면서 우리는 우리 스스로가 ‘디자인 인력’이나 ‘엔지니어링 인력’이 아니라 사실 ‘제품 인력’이라는 것을 깨달았다. 전략, 포지셔닝부터 디자인, 생산에 이르기까지 우리가 흥미를 느끼는 것은 제품 전체이다.

슬프게도 우리가 일하는 업계는 ‘디자인’에 중점을 둘 것이냐 ‘제품’에 중점을 둘 것이냐를 선택하는 곳이 아니라, 제품이 아닌 프로젝트에 모든 초점이 맞춰진 곳이다. 페이스-게이트, 폭포수 기법, 애자일, 그 외 방법들은 모두 위대한 제품을 만드는 것이 무엇인지에 대해 지침은 없이 프로젝트에 주의를 집중시킨다.

우리에게 가장 중요한 깨달음은 우리의 목적이 제품이라는 것이다. 사람들은 회사가 만든 제품을 통해 회사를 기억하지, 제품을 만든 방식 때문에 회사를 기억하지는 않는다. 이것은 프로젝트 관리를 소홀히 해도 된다는 뜻이 아니라 우선순위를 조절해야 한다는 뜻이다. 애자일 기업이 프로세스보다 사람을 더 중요시하듯이, 우리는 프로젝트보다 제품을 더 중요시한다. 여기서 ‘더 중요시하다’는 표헌에 유의해야 하는데, 즉 다른 하나가 중요하지 않다는 뜻은 아니다.

요약

이 과정에서 우리는 위대한 제품은 어디를 보더라도 알아볼 수 있는 장점이 있다는 것을 배웠다. 모든 요소는 제품 전체에 대한 인식을 강화하기 위해 존재하고 구성된다. 일반적으로 인식은 사람들이 그 제품에서 무엇을 얻고자 하는지와 관련되는데, 그것이 경험이든 목표든 그 제품이 아니면 얻을 수 없다.

우리 팀이 소프트웨어 제품을 디자인할 때는 제품 디자이너가 여러가지 제안을 만들고 이 제안을 경험하고 그 제안이 제품의 정체성(Identity)과 전체성(wholeness)을 강화시키는지 약화시키는지 판단한다. 디자인과 관련된 모든 결정은 제품에 대한 인식에 어떤 양향을 주는지를 근거로 검토된다.

디자인과 관련된 어떤 선택이 발현적 성질을 약화시키면 중심의 강도도 약해진다. 어떤 결정이나 요소 때문에 중심이 약해진다면 그 결정이나 요소는 재검토되거나 폐기되어야 한다.

요즘 고객에게 우리 일을 평가해 달라고 요청하면, 이들은 단지 만족하는 것이 아니라 우리 제품을 사랑한다고 답한다.

기본
Company

린 마인드셋 – 린 스타트업을 위한 경영 철학

8968480923_1

전체를 최적화하는 사람들은 제품 개발에서 효율성이 다른 무엇보다 적절한 제품을 개발하는 것이라는 점을 이해하고 있다. – p17

현재 고객을 위한 기능 추가에 치중하고, 더 낮은 가격과 더 적은 기능을 필요로 하는 잠재 고객은 소홀히 하는 것도 문제다. – p18

어떤 사업을 할지 리더가 일단 결정하고 나면 다음 단계는 사람들이 아이디어 상태의 새 전략을 지속적으로 사람으로 구현할 수 있는 업무 체계를 갖추는 것이라고 말한 바 있습니다. – 피터 드러커의 매니지먼트 세트 : 경영자가 꼭 알아야 할 현대 경영학의 모든 것 – p30

저렴한 가격보다 품질이 중요하다. – 가격이 아닌 가치로 승부한다.
비용보다 매출이 중요하다. – 비용을 줄이기보다 매출을 늘리는데 우선순위를 둔다. -p34

제품 개발은 항상 팀 작업입니다. 따라서 개발을 위한 최고의 업무체계는 소통과 협력을 장려하는 체계입니다. – p35

던바의 수 – p42

  1. 3~5명의 매우 가까운 친구와 가족으로 구성된 ‘핵심 집단’
  2. 서로 염려해주는 12~15명의 가까운 친구로 구성된 ‘지지 집단’
  3. 업무를 완수하기 위해 협력하는 30~50명의 동료로 구성된 ‘사냥 집단’
  4. 안정적인 친분 관계를 유지하는 150명으로 구성된 ‘클랜’
  5. 같은 언어나 사투리를 사용하는 500~2500명으로 구성된 ‘부족’

피터 드러커는 경영자가 지식 노동자를 자원봉사자처럼 다루어야 한다고 제안한 바 있습니다. 왜냐하면 지식 노동자도 자발적으로 일하기 때문입니다. p45

WIKISPEED의 모든 요소는 사람들이 팀에 합륙하거나 팀을 떠날 때 필요한 일을 줄이고 팀에서 활동하는 팀원과 팀원이 아닌 사람들 간의 경계를 흐리게 하도록 구축됩니다. p48

우리는 경쟁자가 차라리 우리 솔루션을 분해하고 모방하여 솔루션을 개발하고 혁신하는 데 그 시간을 썼으면 합니다. p49

임베디드 소프트웨어를 개발하는 팀이 애자일  기업의 한계에 부닥치는 경우를 흔히 볼 수 있는데 그 이유는 애자일 기법이 소프트웨어만으로 구성된 제품에 최적화되어 있기 때문이다. p67

전문성은 오랜 기간 동안 주도면밀하게 계획된 연습을 통해 개발된다는 것이다.
전문성 = 도전 + 코칭 + 발전 + 끈기 p72

히긴스의 이론에 의하면 발전에 초점을 둔 사람에게는 성공 지향적 목표를 제시하는 것이 좋고 예방에 초점을 둔 사람에게는 안전에 초점을 둔 목표를 제시하는 것이 좋다. p73

코치 역할은 책임자가 수행해야 할 많은 역할 중 핵심 역할이 되어야 합니다. p79

지식 노동자에게 가장 큰 동기를 부여하는 것은 의미 있는 일에서 발전하는 것이라는 결론을 내렸다. p79

이론상으로는 근거를 바탕으로 결정하면 인지적 편향을 극복할 수 있다. 그러나 근거를 모으고 검토하려면 느리게 생각해야 하는데, 느리게 생각하는 것은 힘든 일이다. p84

신뢰할 수 있는 직관은 자신의 결정에 대해 정확한 피드백을 받을 수 있는 환경에서 구축된다고 말합니다. p87

회복탄력성은 일부러 오류를 만들어 잠재된 문제를 찾고 모든 복잡한 시스템에 필연적으로 발생하는 오류를 복구하는 법을 배우면서 오랜 시간에 걸쳐 길러진다. p88

어떤 것을 만들기 전에 가능한 많은 것을 파악하려고 노력했습니다. 우리는 이것을 학습 우선 개발 (learn-first development)이라고 부릅니다. p96

애자일 기법은 업무 선능을 개선했다고 할 수 있다. 그러나 프로젝트가 아닌 제품을 평가하자면, 솔직히 말해 이런 제품에는 위대함이 없었다. p105

상호작용 설계란, 의미를 만들고 사람들이 시간 가는 줄 모르고 현재 하고 있는 경험 외에 모든 것을 잊어버리도록 복잡한 다층활동에 몰입하게 만다는 것이라는 점을 깨달았다. p108

우리는 엔지니어의 영혼과 디자이너의 감을 가지고 있다. p110

사람들은 회사가 만든 제품을 통해 회사를 기억하지, 제품을 만든 방식 때문에 회사를 기억하지 않는다. p111

과학적 계획 수립의 가장 좋은 점은 폭넓은 가능성에 대해 신중하게 실험하기 때문에 인지적 편향을 극복할 수 있다는 것이다. p119

가장 효율적인 제품 개발 조직은 가장 많은 기능을 제공하는 것이 아니라 필요한 기능만 제공하는 조직이다. p125

진정으로 효율적인 조직은 주로 흐름 효율성(업무가 중단없이 계속 진행되는 것)에 초점을 맞추는데, 이렇게 하면 시스템에 대해 전체적인 관점을 가지게 되고 전반적으로 결과가 더 좋아진다. p126

우리는 불확실성의 시대에 살고 있으므로 일을 숨겨서 이런 불확실성을 더 악화시켜서는 안됩니다. p131

성공적인 사업모델과 좋은 디자인이 결합한 제품을 복제하기란 매우 어렵다. p142

린 스타트업의 접근 방식은 스타트업이 할 일은 지속 가능한 사업을 구축하는 법을 배우는 것이라는 생각에 토대를 두고 있다. p144

스쿼드(Squads@Spotify)는 기본적인 내러티브(Narrative)를 충족하고 사용자를 기쁘게 할 수 있는 최소한의 제품을 알아내야 한다. 특징 면에서 완전한 것이 아니라 내러티브 면에서 완전하게 만들어야 한다. 아마 최소 호감 제품(Minimum Lovable Product)이 더 적당한 표현일지도 모른다.  p153

많이 집중할할수록 확증 편향이 더 강해질 수 있다. p165

소프트웨어는 결코 완성되지 않는다. 단지 출시될 뿐이다. p173

파괴적 경쟁사는 생산성에 소중한 돈과 시간을 낭비하지 않으리라는 것은 분명하다. p174

기본
Company

Zero to One (제로 투 원)

8947529877_1

정말 중요한 진실인데 남들이 당신한테 동의해주지 않는 것은 무엇입니까? – p13

기술이 기적인 이슈는 ‘더 적은 것으로 더 많은 일’을 하게 해주기 때문이다.  – p9

창조적 독점 기업들은 세상에 완전히 새로운 종류의 풍요로움을 소개함으로써 고객들에게 ‘더 많은’ 선택권을 제공한다. – p47

행복한 기업들은 다들 서로 다르다. 다들 독특한 문제를 해결해 독점을 구축했기 때문이다. 반면에 실패한 기업들은 한결 같다. 경쟁을 벗어나지 못한 것이다. – p49

독자 기술은 가장 가까운 대체 기술보다 중요한 부분에서 ’10배’는 더 뛰어나야 진정한 독점적 우위를 확보할 수 있다. – 68

모든 것을 다 제자리에 갖춰놓은 사람에게 승리가 찾아온다. 사람들은 그것을 운이라고 부른다. – 83

잠재적으로 펀드 전체의 가치에 맞먹는 수익을 올릴 가능성이 있는 회사에만 투자하라. – 115

즐겁게 함께 일할 수 있는 사람들을 채용했다. – 160

같은 생각을 가진 사람들이 하나의 부족원이 되어 회사의 미션을 향해 맹렬히 헌신해야 한다. – 163

시장의 가장 중요한 부분을 가장 먼저 점령하는 사람이 전체 시간의 라스트 무버가 된다. – 181

미래에 가치 있는 기업들은 이렇게 물을 것이다. ‘어떻게 하면 인간이 어려운 문제를 해결할 수 있도록 컴퓨터가 도울 수 있을까?’ – 197

모든 기업이 반드시 답해봐야할 일곱가지 질문 – 202

  1. 기술 – 점진적 개선이 아닌 획기적 기술을 만들어낼 수 있는가?
  2. 시기 – 이 사업을 시작하기에 지금이 적기인가?
  3. 독점 – 작은 시장에서 큰 점유율을 가지고 시작하는가?
  4. 사람 – 제대로 된 팀을 갖고 있는가?
  5. 유통 – 제품을 단지 만들기만 하는 것이 아니라 전할 방법을 갖고 있는가?
  6. 존속성 – 시장에서의 현재 위치를 향후 10,20년간 방어할 수 있는가?
  7. 숨겨진 비밀 – 다른 사람들은 보지 못하는 독특한 기회를 포착했는가?

기업들은 10배의 개선을 이루려고 노력하지 않으면 안된다. 점진적 개선은 최종 사용자 입장에서는 전혀 개선으로 느껴지지 않는 경우가 많기 때문이다. – 204

새로운 것들을 창조할 수 있는 하나뿐인 방법들을 찾아내는 것이다. – 251
기본
Company

MARU180 1층 마이크임팩트 스튜디오 이용 후기

이미지

마이크임팩스스튜디오는 오픈형 워크스페이스이다.

최고 장점은 일요일만 21시까지 운영하고, 주중과 토요일은 24시간 운영!!

문제는 여기는 일하는 장소가 아니라 미팅할 장소정도 밖에 안됨. 조명이 너무 어둡고, 책상형 테이블이나  파티션이 너무 부족함.

분위기가 너무 커피숍이라, 드림엔터나 디캠프같은 오피스 분위기가 안남.

그리고 무료가 아니라는 것!

일인당 1시간에 2천원, 하루에 만원, 한달에 20만원(현18만원) – 팀을 위한 요금정책은 아직 없음

혼자 일하는 경우에는 한달 20만원에 개인사물함, OA시스템, 우편택배 보관 등이 있어 쓸만하겠지만 팀으로 쓰기에는 비용이 너무 비쌈.

참고: WORK & OFFICE 를 소개합니다.

기본
Company, Development

JIRA, Confluence, JIRA Agile, Confluence Team Calendars

JIRA  소개

https://www.atlassian.com/software/jira

JIRA demo video(한글자막)
https://www.youtube.com/watch?v=xrCJv0fTyR8

Editing Project Workflows in JIRA
https://www.youtube.com/watch?v=DLrWrpY8mIs

Scrum planning and reporting demo video
https://www.youtube.com/watch?v=1zL3Sfjr4W0#t=92

JIRA import workflow
https://www.youtube.com/watch?v=2TOR3Y13hH0

New JIRA mobile interface
https://www.youtube.com/watch?v=lekTq-kg9gY

Atlassian Software Development Workflow
https://www.youtube.com/watch?v=OMLh-5O6Ub8

Integrating JIRA issues with FishEye Source and Crucible Code Reviews
https://www.youtube.com/watch?v=fFQ4MWQTO4Q

 

JARA Agile 소개

https://www.atlassian.com/software/jira/agile

JIRA Agile – Truly Agile
https://www.youtube.com/watch?v=KdyV9okLRlc

 

Confluence 소개

https://www.atlassian.com/software/confluence

Confluence Team Collaboration Software Overview Video
https://www.youtube.com/watch?v=xrCJv0fTyR8

Introduction to the Confluence Editor
https://www.youtube.com/watch?v=5y41OWc9o7s

Do Agile Right with Atlassian JIRA and Confluence
https://www.youtube.com/watch?v=cmZYGAvpxQc

Meeting Notes Blueprint Video for Confluence https://www.youtube.com/watch?v=2B4cl1p07zE

File List Blueprint Video for Confluence
https://www.youtube.com/watch?v=oJp2era_sug

Confluence Decisions Blueprint Video
https://www.youtube.com/watch?v=P2PK6vfF9hk

Confluence Shared Links
https://www.youtube.com/watch?v=uxqsaWldo00

Confluence Task Management
https://www.youtube.com/watch?v=jpSfXkUTSSc

Produect Requirements
https://www.youtube.com/watch?v=I2vY6FKeXbs

Quick JIRA Issue Creation in Confluence
https://www.youtube.com/watch?v=reiLHEIlXDc

Publish JIRA Reports in Confluence
https://www.youtube.com/watch?v=nsx7brbcL-M

Run Retrospectives in Confluence
https://www.youtube.com/watch?v=x6l7toqpoEQ

Confluence Knowledge Base
https://www.youtube.com/watch?v=cS_bbyLQpjQ

 

Confluence Team Calendars

https://www.atlassian.com/software/confluence/team-calendars

Team Calendars for Confluence
https://www.youtube.com/watch?v=wQ9C9hu-cRg

 

추가

https://www.youtube.com/user/GoAtlassian

기본