📚책 정리 - 개발자에게 물어보세요

 

 

개발자에게 물어보세요 

디지털 공급망으로 조직의 핵심 역량 구축하기

제프 로슨 저/박설영 역 | 인사이트(insight) | 2023년 03월 27일 | 원제 : Ask Your Developer

 

해당 책 정리본은 주관적인 내용 및 편집이 포함되어 있을 수 있습니다.

 

 

 

책을 읽은 목적

1. 개발이 프로덕트에서 얼마나 중요할까?
2. 개발자들은 어떻게 생각하고 행동할까?
개발자들과 원활한 커뮤니케이션을 위해, 그들의 업무 방식을 이해하기 위해 책을 읽어봤다.

짧은 책 리뷰

기본적으로는 읽는 이 가 ‘개발자’로 쓰인 책. 업무와 관련하여 개발자가 어떤 역량을 가지고 있는지 확인하고 이를 이끌어내는 방법, 개발자가 생각을 확장하고 주도적으로 프로젝트를 이끄는 방법 등이 적혀있다. 또한 애자일의 주요 개념에 따른 개발자의 업무 방향성이 제시되어 있어서, 애자일을 목표로 하는 개발자들에게 도움이 될 것 같다.
개발자들에게 도움이 되는 책인가? 그렇다. 주변 개발자들에게 한 번쯤 추천하고 싶은 책이다.
그렇지만 프로덕트 디자이너나 프로덕트 매니저가 읽어도 좋을 것 같다. (PD보다는 PM이 읽었을 때 좀 더 많은 인사이트를 얻을 것 같긴 하다). 프로덕트를 위해 결국 개발자와 협업해야 하고, 그들과 커뮤니케이션하기 위해서는 그들을 이해할 필요가 있으므로.

 

---

 

1. 시작하며

 

디지털 비즈니스 시대의 리더라면 소프트웨어 가치를 이해해야 한다

이 책은 매니저와 기업의 리더, 그리고 그들이 고용한 소프트웨어 개발자들이 함께 극도의 불 확실성을 성공적으로 헤쳐 나갈 수 있도록 서로를 이해하게 도와주는 필수 지침서다. 소프트웨어의 중심적 위치와 그게 어떻게 사 용 되는지 설득력 있는 사례로 제시할 뿐 아니라, 규모를 막론하고 차세대 기업을 만들고자 하는 이에게 실용적인 조언을 제공한다.

 

 

 

 

 

2. 업무 작업

 

2.1 소프트웨어 피플

다음과 같이 질문을 던지는 사람이라면 누구나 소프트웨어 피플이다. 

"소프트웨어로 이 문제를 어떻게 해결할 수 있을까?

소프트웨어 피플이 된다는 건 기술이 아니라 사고방식의 차원이기때문이다.

 

 

 

2.2 차별화된 경험 구축하기

 

 

중요한 것은 서버를 어떻게 사용하는지가 아니라
사용자에게 어떻게 서비스할 것인가이다.

_제프 로슨, 2010

 

 

" 저는 차이를 만들고 싶습니다. 무언가를 이루고 싶어요. 제겐 이 일이 큰 기회였어요. 어떤 위험도 감수하지 않으면 만족스러운 결과도 얻지 못합니다."

 

경험상 고객에게 차별화된 경험을 제공하는 것이라면 만들어야 한다는 게 내 원칙이다. 고객을 상대하는 소프트웨이라면 제작해야 한다. 고객이 '왜 여기엔 X라는 기능이 없나요'라고 묻는데, 그게, 우리가 구매한 제품에 X라는 기능이 없거든요'라고 답해야 하면 곤란하다. 이런 서비스는 무조건 만들어야 한다. 고객이 관심을 가질 때도 제작해야 한다. 백엔드 소프트웨어를 직접 만드는 게 설득력 있는 경우도 가능하다. 재고를 얼마나 잘 관리하느냐에 따라 경쟁 우위를 확보할 수 있는 사업이라고 하자. 이럴 땐 당연히 자체적인 공급망 소프트웨어를 만들어라.

하지만 다시 한번 내 경험법칙을 반복하자면, 고객을 직접 상대하는 소프트웨어는 꼭 만들어라. 왜냐면 차별화된 경험은 구매할 수 없기 때문이다. 그건 직접 구축하지 않고는 길이 없다.

 

 

 

2.3 실험은 혁신의 전제조건

 

무언가 발명하고 있는 중이라면
자신이 무슨 일을 하는지 모를 수밖에 없다

_ 카테리나 페이크, 플리커 공동설립자

 

 

(1) 먼저 아이디어를 점검하라, 완벽할 필요는 없다

새로운 실험을 시작할 수 있는 낮은 수준의 에너지만 있으면 된다. 실제로 우리가 알고 싶은 것은 딱 두 가지다.

고객, 문제, 시장이 어떠하다고 가정하고 있는가.
- 어떻게 실험으로 가정이 옳았음을 혹은 틀렸음을 입증할 것인가?
- 크게 성공하면 큰 결과물을 거두게 될까?
핵심은 큰 나무를 기르는 것이다. 그러니 자신이 심는 씨앗이 성공하면 그럴 가능성이 생길지 자문해 보라.

 

실험을 거절해도 되는 이유는 다음 두 가지 외엔 없다.

(a) 기회 자체가 너무 작아서 성공해도 아무 의미가 없을 때, (b) 팀이 진척 상 황을 측정할 방법을 모를 때.

하지만 앞에서 언급한 두 가지 질문에 훌륭히 대답할 수 있으면 소규모팀을 꾸려서 시작하라. 새로운 팀을 만들든 기존 팀에 업무를 추가하든, 다섯 명이면 일을 착수하기에 충분하다. 팀에 꼭 '훌륭한 아이디어'를 던지려고 하지는 말라. 대신 세분화된 고객과 해결이 필요한 문제를 주어라. 그들에게 무엇을 만들라고 하지 말고, 어떤 고객에게 집중해야 하는지, 그 고객을 위해 어떤 (바라건대) 중요한 문제를 해결할 수 있는지 말해 주라. 이렇게 해야 팀이 고객과 미션을 명확히 파악할 수 있다.

 

 

(2) 다음으로 어떻게 성공을 측정할 것인지 합의하라

소규모팀에는 성공적인 실험 결과를 정의할 수 있는 측정법이 필요하다. 주의할 점은 장기간에 걸친 사업 결과가 아니라 단기간의 실험 결과를 대상으로 한다는 점이다. = 맹목적 가정이 타당한지 입증하는 것

 

 

(3) 다음으로 기록하라

옳고 그름을 입증하는 가설과 가정을 세우는 것도 좋지만, 진행 상황을 추적할 수 있도록 기록하는 작업도 필요하다. 핵심 가치 중 하나는 '기록하라'이고, 진행 상황 추적과 기록을 연습하기엔 실험이 가장 좋다. 원래의 가설을 잊어버리는 일이 흔하므로 가설은 물론 결과를 계속해서 기록하면 모두가 진행 과정을 순조롭게 따라갈 수 있다. 과학자와 발명가들이 연구 노트를 상세하게 적는 이유도 이 때문이 아닐까. 실험 내용과 진행 과정을 제 대로 기록하지 않으면 사람들, 특히 우리 같은 경영진은 맥락을 잊 어 버린 채 "왜 발전이 없는 거야?"라고 되묻기 쉽다. 기록하고, 사람들에게 실험의 목적을 상기시키고, 진행상황을 업데이트하는 것 은 실험적 태도를 유지하고 지지하는 훌륭한 방법이다.

 

 

(4) 실험은 가능한 많이

가장 쉬운 방법은 고객에게 그냥 물어보는 것이다. "00한 제품을 구매할 의향이 있습니까?" 이게 반응을 미리 살피는 가장 쉬운 방 식이다. 내가 한 일이라 곤 잠재 고객들과 인터뷰를 하고 아이디어가 그들의 일상적 문제를 해결할 수 있을지 확인하는 게 전부였다. 어떤 약속을 하는 게 아니므로 고객을 실망시킬 가능성이 아주 적다. 대개 사람들은 누군가 자신이 어떤 불편을 겪고 있는지 물어보고 고민한다는 것에 그저 만족한다.

+Tip. 온라인으로 아이디어를 시험하는 방법 ‘가짜문 테스트 paint-ed door text’

 

 

---

 

3. 작업 환경

 

3.1 RAPID 의사결정 체계

이는 조직에서 '결정권자가 누구인지' 파악하도록 도와주는 수많은 체계 중 하나다. RAPI는 베인 Ban이 의사결정의 5가지 핵심 기능(권유 Recommend, 동의 kgree, 실행 Perform, 의견 제 Input, 결정 Decide)에 역할을 부여해서 결정에 관련된 책임을 확실히 하기 위해 만든 도구다.

 

사람들은 의사결정권자와 얼마나 가까우냐에 따라 자신에게 자율성이 있으며 '이를 알고 있다고 느 끼는데, 구분하자면 다음과 같다.

• 자신이 의사결정권 자라면 완전한 자율성을 갖는다.
• 자신의 매니저에게 결정권이 있으면 결정이 내려지는 과정을 이해하고, 결정에 영향을 미치는 대화에 참여하고, 결정에 동의할 가능성이 높다.
• 자신과 좀처럼 교류하지 않거나 심지어 알지도 못하는 멀리 있는 누군가가 본인에게 영향을 미치는 결정을 내리면 피해자적 사고방식을 가지게 된다. 그런 결정은 자신에게 가해지는 것이 지, 자신이 함께 참여하는 것이 아니다. 본인이 자율성을 가진 신뢰받는 행위자가 아니라, 반대로 과정의 수동적인 일부에 불 과하다고 믿기 시작한다.

소규모팀과 단일 스레드 리더는 직원들이 자신을 제삼자라고 느낄 만한 상황을, 즉 자신이 동의하지 않는 결정에 의해 무력감을 느끼 고 피해를 입는 가능성을 최소화하도록 지원한다.

 

사람들 때로 투자자들은 내게 왜 소규모팀에 우선권과 로드맵을 가지도록 그토록 많은 권한을 주느냐고 묻는다. 그러면 나는 대답한다 “고객에게 봉사하는 방법을 가장 잘 아는 사람이 누굴까요? 나는 지금 여기 앉아서 투자자와 대화하고 있지만, 내 팀들은 고객과 대화하기 바쁩니다. 오늘 우리가 고객을 위해 무 엇을 해야 하는지 더 잘 아는 사람이 누구일 거라 생각하세요?

나에게 다양한 분야로 구성된 소규모팀과 단일 스레드 리더의 가 장 큰 목적은 팀이 고객에게 친밀감을 느끼고, 결정에 책임지며, 자 신의 일이 곧 발전을 의미한다는 사실을 아는 것이다. 팀원들이 어떻게 느끼는지 알아보기 위해 의사결정이 어떻게 이루어지는지 물어볼 수도 있다.

 

개발자들에게 다음과 같은 질문을 던져 보라.

• 최근에 결정을 내린 사람은 누구인가?
• 본인이 그 결정 과정에 참 여했는가?
• 본인의 동의 없이 결정이 이루어졌는데도 팀으로써 함께 애쓰고 헌신했는가?

결정에 영향을 미친 것이 조직도인지 고객의 요구인지 물어보는 것도 좋다. 팀원들이 일의 진척 상황에 책임을 느끼는지 알아보려면 평가 지표가 뭔지, 스스로 지표를 합리적으로 제어할 수 있다고 생각하는지 물어보라. 얼마나 많은 사람이 팀 외부에서 그들에게 감 놔라 배 놔라 하는지도 물어보라.

 

이 과정에서 얻게 되는 것은 결국 책임감과 고유한 추진력이다.

팀 리더에게 주어진 과제에 성공했는지 실패했는지, 대체로 자신에게 통제권이 있다고 느꼈는지 물어보라. 그렇지 않다고 답하면, 모든 사람이 결정과 결과물에 책임이 있다고 느끼도록 팀을 조직하는  법을 고민하라. 그렇지 않으면 사람들이 다른 데 정신을 팔 것이다.

 

 

 

3.2 배움과 학습

 

배우기를 멈추고 경청하기를 멈추고
새로운 질문을 찾고 묻기를 멈춘다면
그건 죽을 때가 된 것이다.

_릴리언 스미스

 

 

“우리는 완벽하지 않습니다. 하지만 배우고 발전한다면 잘하고 있는 거예요."

우리도 완벽하진 않지만 보다 개방적이고 보다 교육적인 환경을 위해 끊임없이 노력하고 있다.

혹은 매일 "덜 형편없어지기 위해서" 말이다. 이 정도면 괜찮다.

 

 

 

 

3.3 열린 학습 환경 만들기

 

 

벽이 아닌 문을 만들어라.
우리에겐 규칙이 없다. 테두리가 있을 뿐이다.

테두리를 잘 설정하면 움직임이 오히려 자유로워진다.

 

“ 다시 말해, 설령 오늘날의 베테랑 매니저가 한때 뛰어 난 엔지니어였다고 해도 입사 당시의 그 기술 전문가는 아니라는 뜻이다. 여하튼 인텔의 매니저들도 매일 조금씩 구식이 되어 가고 있다."

그렇지만 ‘개발자에게 묻기’ 사고방식을 받아들이면 명령과 통제보다 원하는 것(결과)를 얻기가 훨씬 쉬워진다.

열린 환경이란, 문제를 공유함으로써 사람들에게 자율권을 주는 곳이다. 열린 환경은 (a)테두리와 (b)지원책을 제공한다.

 

 

 

 

 

3.4 우리는 고객 편이에요

 

사람들은 누군가 한 말과 행동은 잘 잊어버린다.
하지만 어떤 기분이 들게 했는지는 절대 잊지 않는다.

_ 마이아 앤절로

 

"서비스는 기술적으로 제품을 제공하는 것이다. 환대는 제품을 제 공할 때 받는 사람이 어떤 기분을 '느끼도록' 만드는 것이다. 서비스는 '독백'이다. 우리는 우리가 어떻게 하고 싶은지 결정하고 우리만의 서비스 기준을 세운다. 반면 환대는 '대화'다. 손님의 편에 서려면 모든 감각을 이용해 그 사람의 말에 귀 기울이고 사려 깊고 품위 있게 적절한 반응을 해야 한다. 최고의 자리에 오르기 위해선 훌륭한 서비스와 환대 모두 필요하다."

 

"우리의 전략은 단순합니다. 고객이 원하고 돈을 지불할 만한 것을 만드는 것입니다."라고 말한다. 

물론 장기적인 사업 계획은 있다. 하지만 팀이 고객에게 봉사하자는 회사의 목표를 혼동하기를 원치 않는다. 우리가 기업 계획을 실천할 수 있는 유일한 방법은 고객에게 봉사하는 것이다.

 

전략이나 기능을 곧장 언급하지 말고, 고객이 이 프로덕트에 왜 관심을 가질 것 같은지 이야기하는 데서 시작하라. 리더에게 어떤 고객이 그 문제를 제기했는지, 그 문제의 시장 수요가 광범위하다 는 것을 어떻게 검증했는지 물어보라. 과정이 대답보다 중요하다.

팀 내에 고객을 진정으로 이해하기 위한 올바른 메커니즘이 갖춰져 있는가?

이를 물음으로써 우리 팀이 어떤 생각을 하고 있는지 파악할 수 있다.

 

 

3.5 TSOC

개발자가 툴을 만지작거리는 시간을 측정하기 위해 제이슨은 코드 외적인 사용 시간 Time Spent Outside Code, TsoC' 지표를  만들었다. 평균 TSOC가 절대 0에 도달하지는 못하겠지만, 최대한 0에 가까워지는 것이 목표다.

“플랫폼의 미래는 소프트웨어 개발자가 오직 기능과 고객에만 집중할 수 있도록 돕는 일이 될 겁니다. 소프트웨어를 누군가의 머릿속에서 클라우드로, 장치로, 고객경험으로 옮기는 데 필요한 기본 시스템을 만드는 게 아니라요.”

 

 

---

 

4. 개발자와의 커뮤니케이션

 

4.1 제품 요구사항 정의서

이런 개발자들에게 무엇을 개발할지 자세히 적어 놓은 '제품 요구사항 정의서 product Requirements Document'를 건네는 건 그들의 잠재력으로 대부분 낭비하는 행위다. 전 세계의 경영진에게 다음과 같이 강력하게 조언한다.

개발자들과 함께 문제를 공유하라. 해결책이 아니라.

ex) ‘미국 정부는 수리가 필요하고, 여러분이 그 일을 맡아 줬으면 좋겠다.’_오바마 대통령
이것이 바로 문제 공유다. 그는 개발자들의 창의적인 면에 직접적으로 호소했다. 어떻게 해야 그들이 정부를 위해 기술을 구축할 수 있을까? 대통령이 든든하게 지원해 준다면 어떤 문제를 해결할 수 있을까? 오바마는 자신이 원하는 게 단순히 그들의 코딩 기술만이 아니라, 사고방식과 상상력이라는 것을 알렸다.

 

 

 

4.2 코드 몽키가 되고 싶은 개발자는 없다. 문제를 공유하라

 

똑똑한 사람들을 고용해서 이래라저래라 하는 건 말도 안 된다.
우리가 똑똑한 사람들을 고용하는 건 그들에게 무얼 해야 하는지 듣기 위해서다.

_스티브 잡스

 

 

YC가 신생 스타트업을 발굴하거나 스타트업 설립에 도움을 주는 한 가지 방법이 해결이 필요한 문제의 목록을 게시하는 것이다.
YC는 이를 RFSRequest for Startups라고 부르는데, 이렇게 설명한다. 우리가 투자한 최고의 아이디어 대다수가 우리의 예상을 비껴간 놀 라운 것들이었습니다. 하지만 스타트업이 꼭 지원해 줬으면 하는 아이디어도 있습니다. 다음은 RES의 업데이트 버전으로, 그런 아 이디어 중 일부를 일반적인 용어로 정리해 놓은 것입니다." 이 목록에는 문제를 푸는 방법은 구체적으로 적혀 있지 않다.

 

 

(ex) 포팅 프로젝트

= 고객의 입장에서 생각하기 + 일이 바로해결되지 않는 것은 당연하다

또 문제를 얼마나 잘 해결하 는 지 진정한 차이를 만드는 것은 오존이 그랬듯 개발자가 문제를 이해하는 것에서 비롯됨을 의미한다.

그러고선 그에게 키보드를 건네고 스스로 십여 번 포팅을 해보도록 했다. 고객의 입장이 되어 보는 과정이었다. 그가 직접 문제를 경험하도록 만든 후 그녀가 그에게 물었다. "그럼, 이 문제를 소프트웨어로 어떻게 해결할 수 있을까요?"
오존은 리사에게 "이게 맞는 것 같아요?" 라고 물으면서 데이터 구조를 모델링하기 시작했다. 첫날이 끝날 무렵, 데이터 모형의 기 본이 갖춰졌다. 이 부분이 해결되자 고객들이 정보를 제출할 때 사용하는 양식을 만드는 게 가능해졌다. 이때 그들은 고객들이 잘못된 정보를 제출하는 경우가 많으며, 그로 인해 수없이 왔다 갔다 하는 수고를 겪는다는 것을 알아차렸다. 이 문제는 소프트웨어로 쉽게 해결되었다. 둘째 날이 끝날 무럽엔 필요한 정보를 제대로 수집하기 위한 작업 양식을 완성했다.
(물론 처음부터 이런 실수가 일어나도록 만들지 않았더라면 더 좋았을 것이다. 그렇지만 규모가 급속도로 확장되는 스타트업에서는 이런 일이 비일비재하다.)

 

포팅 프로젝트는 올바르고 효율적인 해결책을 찾기 위해 문제를 공유한 훌륭한 사례다. 개발자가 사용자가 필요로 하는 것을 깊이 이해하고 그 니즈를 해결하도록 만드는 것이 문제 공유의 핵심이다. 리사는 크리스가 작성하는 코드를 사람들이 왜 필요로 하는지, 그의 코드가 사람들을 어떻게 도울 수 있는지 그가 이해하게끔도 왔다. 공감대를 형성하고 나자 그에게 이런 간단한 워크플로 어플리케이션을 만드는 행위는 큰일이 아니었다.

 

 

 

4.3 근원적 문제를 파악하고 해결하는 방법 (5Why 프레임워크)

 

엔지니어가 일으킨 버그가 운영을 중단시킨 명백한 원인이긴 하지만 진짜 근본 원인은 아니다. 진짜 문제는 오히려 조직 운영 방 식 깊은 곳 이단가에 자리 잡고 있다. 그러니 사람을 탓하는 대신 다음과 같은 진짜 질문을 던지라. 인간이면 실수할 수밖에 없다는 걸 알면서도 왜 '시스템'은 그런 실수가 고객에게 영향을 미치도록 허용했을까?

이에 대답할 수 있으면 진짜 근본 원인을 파악하는 게 가능하다.이를 위해서는 끊임없이 "왜?" 라고 물어야 한다.

 

Q.  왜 고객 서비스가 중단되었을까? 
A. 엔지니어가 버그가 있는 코드를 서비스에 유입시키는 바람에.

 

 

Q. 어째서 버그가 있는 코드 때문에 서비스가 중단됐을까?” 
A. 소프트웨어가 문제에 대비해 방어적으로 작성되지 않아서라는 대답이 나올 수 있다. 정말 강력한 소프트웨어라면 문제를 감지할 뿐 아니라 어 떤 품질 저하도 이겨냈을 테니 말이다. 아니면 탄탄하게 개발됐다 해도 소프트웨어가 버틸 길이 없었을 수도 있다.

 

 

 Q. 왜 버그가 있는 코드가 서비스에 유입되었을까?
A. 문제의 코드를 충분히 테스트하지 않아서.

 

여기까지 오면 질문을 멈추고 항공모함 위로 '임무 완료' 깃발을 펼치기 쉽다. 하지만 이는 사후 검토를 도중에 갑자기 그만두는 것과 같다. 왜일까? 이 역시 은근히 소프트웨어어 개발자를 탓하는 것이기 때문이다. 만약 개발자 또는 품질 보증 이 지니어가 좀 더 열심히 테스트하기만 했더라면 문제를 피할 수 있었을 거라는 논리가 아닌가. 그러니 다음과 같이 계속 물어라. 

 

 

Q. 중요한 코드를 충분히 테스트하지 않은 것을 알면서도 어째서 프로덕션 단계로 넘어갔을까?
A. 이제 어느 정도 진척이 생겼다. 진짜 근본 원인은 기술이 아니다. 조직이다. 어떻게 해서 조직은 사람의 실수를 잡아내지 못하고 고객과 사업에 해를 끼쳤을까? 원자력 발전소의 콘솔 정중앙에 '노심용융'이라 적힌 거대한 버튼이 있다고 상상해 보라. 기술자가 모르고 단추 위에 도시락을 내려놓아 핵연료봉이 녹아내리는 사고가 벌어진다. 여러분이라면 그 기술자를 탓하겠는가? 그보단 애당초 왜 그 버튼이 존재했는지 물을 것이다!

 

이 경우도 똑같다. 왜 '시스템'이 제대로 테스트도 안된 코드를 프로덕션 단계로 넘겼을까? 어쩌면 테스트 인프라가 너무 열악해 테스트를 제대로 하기 어려워서 엔지니어가 일을 진척시키려고 확실한 테스트를 자주 생략했는지도 모른다.

 

 

*해결책 도출

만약 그렇다면 해결책은 우수한 인프라를 구축하는 것이다. 그러면 테스트를 작성하기가 쉬워지고 엔지니어가 제대로 테스트된 코드를 이용해 고객의 요구를 충족시킬 수 있다.  그게 아니라 어쩌면 조직이 괜찮은 테스 트를 작성하도록 엔지니어를 훈련하는 데 투자하지 않았거나, 왜 제대로 테스트된 코드가 중요한지 가르쳐 주지 않았을 수도 있다. 이렇게 질문하면 결국 시스템상의 진짜 근원적 문제를 파악하고 해결할 수 있다.

 

---

 

5. 애자일 개발

 

5.1 애자일 소프트웨어 개발 선언

애자일 소프트웨어 개발 선언

 

수많은 애자일 프로덕트가 기능이 빈약한 상태로 출시된다. 기능이 고객에게 아이디어를 신속하게 얻는 것만큼 중요하지 않다고 본다. 따라서 품질을 기본 전제로 하고 기능보다 마감일을 우선하는 것이다. 기능을 적게 만들되 신뢰를 보장하는 방향이 많은 초기 제품팀이 택하는 길이다. 핵심 기능만 제대로 갖추면 언제든 반복해서 추후 더 많은 기능을 구축할 수 있다.

✅경영진이 꼭 해야 할 일은 어떤 특성을 지킬지, 어떤 특성을 희생 할지 성숙한 대화를 나누는 것이다.

 

 

5.2 애자일을 핏에 맞게

일부 회사는 강사나 컨설턴트, 엄격한 규칙과 절차를 잔뜩 갖추고 ⭐️애자일을 전면적으로 실행하기 보다는, 납득이 되는 몇 가지 원칙만 고수하고 나머지는 폐기한다.  "형식적인 방법론을 사용하지 않은 지 오래 되었어요."

 

 

 

5.3  빠른 실행으로 알게 된 것

이런 빠른 실행으로 우리는 또한 몇 가지 교훈을 얻었다. 

 

이제 기반을 다지고, 긴장의 끈을 놓지 않고 계속 노력할 때다.
새로운 업무 방식은 현재에만 중요한게 아니다.

 

 

1. 실수를 하면 안 된다는, 또는 처음부터 모든 것을 완벽하게 해야 한다는 걱정을 내려놓을 때 얼마나 위대한 일들이 일어날 수 있는지 알게 됐다. 코로나 사태가 벌어지는 동안에는 변화가 자유로웠다. 대안이 없었고 사내 정치도 없었고 실수에 대한 두려움도 없었다. 대안이라는 게 훨씬 형편없었기 때문이다. 이런 일은 경영진이 회의를 무더기로 잡을 시간도, 지휘 체계 위아래로 요청과 승인이 오갈 시간도, 결과물과는 전혀 다른 형태가 될 게 뻔한 거대한 마 스터플랜을 고집할 시간도 없을 때 일어난다. 불안감이 커져 가는 상황에서는 경영진과 개발자가 재빨리 손을 잡은 뒤, 개발자가 문 제를 해결하고 솔루션을 개발하도록 힘을 합친다.
   
   
2. 또한 위기는 소프트웨어를 개발하고 배포하는 속도가 얼마나 빨라질 수 있는지 보여 주었다. 소프트웨어 구성요소, 마이크로서비스, API가 프로세스를 획기적으로 가속화했다. 이 점에 대해 그런 툴들을 만든 수천 명의 개발자에게 감사해야 한다. 모든 최신 인프라가 없었다면 수많은 조직이 코로나에 훨씬 느리고 비효율적으로 대응했을 것이다.
   
   
3. 마지막으로 이런 갑작스런 서비스 출시는 기업 내부에서 일하는 개발자들의 창의성과 적응성을 증명해 보였다. 수많은 개발자들이 엄청난 압박 속에서 난생처음 새로운 툴들을 접했지만 잘 적응해서 모든 이들이 계속 일할 수 있게 도왔다. 그들의 영웅적 노력에 감동받았고 그들과 함께 일하는 것은 영광이었다.

 

---

 

6. 참고 인사이트가 되는 저자의 경험 모음

 

6.1 돈보다는 고객 반응이 우선이다

우리는 대충 계산을 한 끝에 강의 노트 판매 '산업이 1천5백만 달러에 달하는 막대한 시장이라고 판단했다. 그래서 결국 노트를 판매하는 대신(아직 1997년이라 온라인 거래가 힘들었으므로) 공짜로 나눠 주기로 결정했다.

광고 시장이 강의 노트' 시장보다 훨씬 크니 미국 전역을 대상으로 노트에 광고를 실어서 수익을 얻기로 한 것이다.

우리는 회사 이름을 노츠포프리닷컴Notesafree.com으로 결정한 뒤 도메인을 등록하고 비공식 구호도 넣었다. "땡땡이를 용인하는 게 아닙니다. 그냥 더 쉽게 만들 뿐." 예상처럼 서비스는 큰 인기를 끌었다. 어떤 학생이 기숙사 방에 가만히 앉아서 강의 노트를 공짜로 받을 수 있는 데 마다하겠는가?

 

 

6.2 적립카드

작은 웹캠을 이용해 사진을 찍었다. 30초도 안 돼서 총천연색의 회원카드가 발급되었다. 특히 아이들이 열광했다! 십대 초반에게 는 자기만의 나인스타 신용카드가 생긴 것 같은 기분이었을 것이 다. 우리는 회원들에게 1년 동안 구매한 금액의 20퍼센트를 '적립 금’으로 제공하되, 2월에(명절 재고를 처분하고 싶을 때) 포인트처 럼 결제할 수 있게 하자고 결정했다. 나는 관리 시스템에 적립금' 항목을 집어넣었다.

 

 

6.3 대기업에서 배울 것

만약 언젠가 의미 있는 회사를 차리고 싶다면 대기업이 어떻게 운영되는지 배워야 했다. 무엇이 운영에 도움이 될까? 다음 스타트업을 창업할 때 본받아야 할 게 뭘까? 회사가 커지면 어떤 기능이 멈출까? 어떤 위험을 피해야 할까? 사업이 어떻게 작동하는 지, 고속으로 성장하는 조직을 관리하고 지도하고 평가하려면 어떻게해야 하는지 배울 필요가 있었다. 스타트업은 최대한 빨리 달리려고만 하는데 '진짜' 기업들은 어떻게 작동할까? 전부 알고 싶었다. 게다가 월급을 받아서 빈 지갑을 채운다고 나쁠 것도 없었다.

 

 

6.4 해커톤의 시작

“ 그러려면 툴을 만들어야 해요. 하지만 어떤 툴을 만들지 결정하자면 먼저 영감이 필요합니다." 이렇게 현재의 해커톤이 생겨나게 되었다. 쏫은 정기적으로 다 양한 도시에서 해커톤을 개최하고 개발자들을 초대해 1주일 동안 문제를 풀게 한다. 개발자들은 아동 성매매 관련 지식이 거의 전무 하지만 이것이 꼭 해결해야 할 문제라는 건 안다. 애슈턴과 쏠의 여리 리더는 개발자들에게 어떻게 기술이 아동 성매매문제를 악 화시키는지 교육한 뒤, 이를 근절하려면 기술을 어떻게 사용하는 게 좋을지 묻는다. 어떤 툴과 데이터를 사용할 수 있는지 정보를 얻은 뒤, 개발자가 아이디어를 구현할 수 있도록 한다. 애슈턴과 쏠의 리더들이 할 수 있는 건 브레인스토밍을 돕고, 특정 분야 지 식을 제공하고, 개발자들의 질문에 대답하는 것이다.

이 아이디어는 필요에 의해 탄생했다. 대부분의 비영리단체들처럼 쏜도 주머니 사정이 넉넉지 않았다. 해커톤은 쏜의 R&D 연구소 의 일부가 되었다. "우리는 그저 네다섯 가지 문제를 제시하면서 이렇게 말합니다. 좋습니다. 이제 바로잡아 보세요. 문제를 해결 하세요." 쿠처의 말이다.

 

 

---

 

 

 

이 책을 정리하며 특히나 목차와 책의 순서가 아닌, 책에서 인상깊은 내용들을 스스로 더 잘 이해하기 위해서 따로 주제를 설정하고 카테고리를 만들어서 재분류 하는 작업을 진행했다.

따라서 이 정리 내용은 책의 순서나 목차와 연관되지 않음을 알립니다.