위 무료 교육에 참석했다.

Atlassian blog(http://korea.blogs.atlassian.com/ ) 에는 개발에 대한 이야기가 많아서 자주 본다. 그래서 이번에 한국에서 교육을 한다기에 참석했다.

역시나, 개발문화나 방법들 잘 되어 있고, 선구적이다 라는 느낌을 받았다.

몇 가지 개인적으로 기억해두고자 하는 PT내용이 있어 첨부해둔다.

stash에서는 bugfix한 것을 version별로 다 자동으로 적용(boring work 부분)해준다고 한다. AWESOME!!

git을 upstream(공동 저장소)/master에 merge하는 방법에 대한 이야기인데, 내 경우에는 Rebase(Squash)를 선호한다.

그런데 대부분 Merge commit를 하고, 가끔 Rebase(Fast Forward)를 한다고 한다. ;;

그림 느낌대로, obvious code가 가장 중요하고, 순서대로다 PR는 Review comments로 봐도 되겠다. Review Comments에 따라 obvious code를 만들어가자는 이해 되었는데, commit message에서 code comments는 잘 ;;

참고 : http://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/

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

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-5 Risk-versus-cost curve for four-stage model of product development

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

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

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

생각단계

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

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

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-8 Minimum viable product

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

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

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

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

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

전달 단계

Figure 4-9 The Ship It Stage

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

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

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

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

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

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

수정단계

Figure 4-10 The Tweak It Stage

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

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

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

Figure 4-11 Local Maximum

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

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)을 강화시키는지 약화시키는지 판단한다. 디자인과 관련된 모든 결정은 제품에 대한 인식에 어떤 양향을 주는지를 근거로 검토된다.

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

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

Development

Distributed Development

http://monkeykinggamesllc.com/distributed-development/

A distributed development project is a research & development (R&D) project that is done across multiple business worksites or locations. It is a form of R&D where the project members may not see each other face to face, but they are all working collaboratively toward the outcome of the project. Often this is done through email, the Internet and other forms of quick long-distance communication.

Success factors

Select and/or recruit good, strong, highly skilled people.
Spend some money for face-to-face meetings, especially at the beginning of each major project.
Build an organizational design that supports working in a distributed development, including the right incentive systems.

지역적 분산 소프트웨어 개발을 위한 툴들

지역적 분산 개발(Geographically Distributed Development, GDD)은 효율성이나 비용면에서 다수의 보상을 가져다 주지만, 성공적인 GDD 팀을 만들기 위한 몇가지 문제들도 있다.

GDD 프로젝트가 마주치는 가장 큰 위험은 내부적으로 효율적인 의사소통을 할 수 있는가에 대한 것이다.

우리에게 있어 GDD의 기본초석은 Internet Relay Chat 프로토콜이다. 우리는 IRC가 원거리 개발에 있어 인스턴트 메시징보다 우월하다.

중간에 들어온 사람도 처음부터 글을 볼 수 있음.
연결 유지가 쉬움.
언어장벽에도 맞설 수 있는 기반 또한 제공

GDD 팀원간의 시차는 팀을 위기로 내몰고, 작업흐름을 혼란시키는 장애물이 될 수 있다.

timeanddate.com – 회의 스케쥴을 잡을 때 시차를 시각화하기 쉽게 만들어주는 Meeting Planner

개발 흐름을 촉진시킬 툴들

메일링리스트, 버전관리, 버그추척, 문서 관리
aMember – 여러분의 툴들이 단일 로그인
CollabNet사의 SourceCast – GDD를 막 시작한 팀들을 위해 이러한 모든 툴들을 통합해서 제공하는 상용서비스
Skype – 음성회의를 하고, 좀더 세부적인 논의가 필요할 때는 음성과 화상을 교차하여 회의

성공적인 분산 개발을 위한 12가지 조언

아웃소싱을 위한 분산 개발이 아니라, 좋은 인재와 같이 일하기 위함
사용도구가 분산 개발을 가능케 함, 분산 개발을 조장해야 함.
오픈 소스 수준의 협업 – 좀 더 모듈화된 API 기반의 접근방식을 조장한다.
정직한 요구조선 수비과 검증 – 최신 정보를 구두보다는 서면으로 전달하고, 양보다 빈도를 많게 소 통
시차가 4시간을 초과하면, 같은 시간에 소통하기 어려움.
팀 크기를 작게 유지함으로써, 더 나은 공동체 의식과 책임감을 조장할 수 있다
팀들이 가능한 많은 채널(스카이프, 채팅, SMS)을 통해서 접촉할 수 있게 해주어서 개발자들이 접촉하는데 부담을 느끼지 않도록 하는 것이다.
관리자라면 시간 절반을 소통하는데 사용해야 한다.
“군대 수준의 정확성”으로 관련 모든 정보(버그번호, JIRA 추적보고, ..)를 전달해야 한다.
버그 개수, 빌드 상태, 서버 부하, 초당 질의 개수, 다운시간 등 개발자들에게 중요한 수치는 모두 공유되어야 한다.
충분한 사회성도 필요하다. – 즐거운 시간 보내기

분산 Scrum

팀 멤버가 분산되어 있는 경우 소프트웨어 개발자는 서로로부터 자신을 분리하려고 코드에 더욱 더 많은 추상화 레이어를 만드는 경향이 있습니다.

인간이 서로 간에 말하는 것 중 많은 부분이 신체 언어를 통해 전달됩니다. 디자인 토론 중에 누군가를 관찰하여 수집한 정보는 화이트보드에 적은 정보만큼이나 중요할 수 있습니다. 이 때문에, 분산 작업자 간의 격차를 해소하기 위해서는 신체 언어 장벽을 극복하는 데 더욱 더 중점을 두어야 합니다.

화면 공유는 매우 효과적인 연결 및 공동 작업 도구입니다.

모든 항목에 대한 단순 확인 규칙을 추가(팀 전체에 걸쳐 수행되는 작업에 대한 집단 이해도를 높임)

각 항목을 완료 상태로 간주된 통합 환경에서 확인해야 합니다.
확인을 수행하는 사람은 작업을 수행한 사람이 아니어야 합니다.

가상 단체방은 항상 열린 상태로 유지되었으며 팀 멤버는 작업할 때 이 작업실을 방문하게 됩니다.

개발자들은 화면 공유 소프트웨어를 사용하여 서로의 화면을 보기 시작했습니다. 이 방법이 더 빠르니까요. 팀에서는 몇 인치의 벽 공간으로 분리된 각자의 사무실에서 앉아 있지만 하루 종일 가상 작업실을 사용하기 시작했습니다.

결국 팀 멤버 중 하나가 몇 일 동안 사무실로 출근하지 않고 재택 근무를 시도했습니다. 스프린트 회고(Sprint Retrospective) 중에 개발 팀은 복도를 지나 몇 번째 문에 해당하는 사무실에 있든 집에 있든 작업자의 위치는 가상 작업실에서 아무런 상관이 없음에 동의했습니다. 가상 단체방이 개인 사무실보다 더 중요함이 입증되었습니다.

물리적 장벽을 극복하고 팀의 커뮤니케이션에서 참여한다면 더 높은 품질, 혼란의 감소, 더 빠른 처리량, 그리고 더 큰 개인적 만족감을 결실로 얻게 될 것입니다. 팀 내에서 도구 및 구현 방식을 신중히 고려할 때 분산 구조가 잘 운영될 수 있습니다.

SW분산개발이 일자리 만든다

클라우드 환경에서 웹을 기반으로 원격 분산개발 환경을 구축할 수 있기 때문이다. 클라우드 웹 기술은 언제 어디서 접속하여도 작업 환경을 복원해주기 때문에 원격 개발의 효율성이 높아졌다.

소프트웨어 분산개발이 활성화 된다면 소프트웨어 기업에서 유연근무와 재택근무 형태가 확산될 것이고 이는 육아부담의재택개발자들에게 양질의 일자리를 제공할 것이다.

참고

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

http://profjkim.egloos.com/2109538

https://www.open.collab.net/kr/products/cee/

http://msdn.microsoft.com/ko-kr/library/jj620910.aspx

Company, Development