클라우드에서 소프트웨어 시작 확장(3부 중 1부)

Nov 29 2022

오늘날 소프트웨어 스타트업은 5년에서 10년 전보다 상당한 이점을 가지고 있습니다. 부분적으로는 Google Cloud Platform(GCP), Amazon Web Services(AWS) 및 Microsoft Azure와 같은 하이퍼스케일 클라우드 호스팅 공급자의 확산 때문입니다. 버튼 클릭으로 사용할 수 있는 수많은 관리형 서비스를 통해 솔루션의 프로토타입을 신속하게 제작하고 기록적인 시간 내에 거의 무한한 규모로 시장에 출시할 수 있습니다.

저는 운이 좋게도 20년 넘게 신생 기업, 벤처 투자 및 사모펀드 기업, IPO가 있는 글로벌 대기업에 이르기까지 다양한 기술 조직의 일원이었습니다. 그 과정에서 많은 재능 있는 사람들과 멘토들로부터 배우면서 저는 배운 교훈, 도구, 기술 및 프로세스를 "선택"합니다.

"앞으로 지불"하려는 노력의 일환으로 배운 몇 가지 교훈을 공유하고 싶습니다. 이 시리즈의 첫 번째 기사에서는 소프트웨어 스타트업을 구축하고 확장하는 데 유용한 개념과 리소스를 소개합니다. 두 번째 기사에서는 가상의 온라인 데이트 스타트업을 설계하여 이러한 조각들이 어떻게 조화를 이루는지 설명합니다. 세 번째 기사에서는 궁극적 으로 GCP를 사용하여 클라우드 아키텍처에 정보를 제공하는 방법을 설명합니다.

2020년 초 저는 새로운 것을 시도하기로 했습니다. 소프트웨어 신생 기업을 만들고 성장시키는 대신 이스라엘에 뿌리를 둔 DoiT International 이라는 클라우드 파트너에 가입하여 조언하고 지원하기 시작했습니다 . 우리 회사는 완전히 원격에 있으며 그 이후 불과 2년 만에 전 세계적으로 약 50명에서 거의 500명으로 성장하여 연간 10억 달러 이상의 연간 클라우드 소비를 지원했습니다. 저는 우리가 그렇게 빠른 성장을 통해 우리 문화를 얼마나 잘 보존하면서 많은 재능 있는 사람들을 유치하고 유지해왔는지 늘 경외심을 느낍니다.

수천 개의 조직이 클라우드 서비스 파트너로 DoiT를 선택합니다. 그들은 무료 자문 및 지원, 그리고 클라우드의 원래 약속을 이행하도록 설계된 최신 소프트웨어 도구의 이점을 얻습니다. 즉, 제품과 고객에 집중하고 나머지는 걱정하지 마십시오. 그렇게 간단하다고 생각하고 싶지만 일반적으로 고도로 숙련된 기술 팀을 보유한 고객이 선행됩니다.

최근에 제가 주목한 한 가지 추세는 대규모 팀이나 심도 있는 클라우드 전문 지식이 없을 수 있는 클라우드 기술을 채택하는 초기 단계의 소프트웨어 스타트업이 성장하고 있다는 것입니다. 소프트웨어 기업가로서 저는 제 "전생"과 DoiT에서 배운 교훈을 공유함으로써 여러분의 여정을 더욱 성공적으로 만들 수 있기를 바랍니다.

초기

기술에서 한 걸음 더 나아가 문제를 식별하는 것부터 문제를 해결하는 데 전념하는 회사를 만드는 것, 그리고 그 너머까지의 여정을 먼저 탐색해 봅시다. 조직이 성숙함에 따라 감사할 수 있는 클라우드 모범 사례를 넘어서는 몇 가지 인기 있는 방법론과 프레임워크가 있습니다.

소프트웨어 신생 기업을 구축하고 성장시키는 데 유용한 방법론입니다. 각각은 반복적이지만 서로에게 정보를 제공합니다.

위에 설명된 각 기술은 자체적으로 반복적 이지만 이 시리즈의 다음 기사에서 볼 수 있듯이 각 기술의 출력은 다른 사람 에게 알려줍니다 .

TL;DR; 유용한 온라인 리소스

위의 기술과 개념을 설명하는 대신 이 비디오를 시청하여 빈칸을 채우고 이를 실행하기 위한 입문서 역할을 하는 것이 좋습니다.

스타트업을 구축해야 할까요 (14분)— Michael Seibel, Y Combinator
전략 대 계획 (9분) — HBR [OGSM과 같은 1페이지 계획 사용]
린 스타트업 요약 (13분) - Eric Ries
사업 아이디어 확인하기 (9분) - Eric Ries
린 UX (60분) - Jeff Gothelf
Lean UX 캔버스 사용 (15분)— Jeff Gothelf
건축 제품 (59분) - Michael Seibel, Y Combinator
MVP 계획 방법 (13분) - Michael Seibel, Y Combinator
사용자 스토리 매핑 (50분) - Jeff Patton
사용자 스토리 매핑에 대한 최고의 가이드 — Nick Muldoon, Easy Agile
C4 모델을 사용한 소프트웨어 아키텍처 (35분) - Simon Brown
Spotify에서 실험 문화 구축 (47분) - Ben Dressler
DevOps vs SRE (44분) - Seth Vargo, Google

해결해야 한다고 느끼는 문제를 인식하면 현재 진행 상황과 가치를 제공하기 위해 진행 중인 몇 가지 주요 지표를 그리는 데 도움이 됩니다. 이는 Amazon에서 팀이 빌드 승인을 받기 전에 미래에 빌드할 내용을 설명하는 보도 자료의 초안을 작성하도록 요구한 방식과 유사합니다.

약 10년 전 하루 종일 진행되는 계획 세션에서 회사를 상장한 후 약 20억 달러에 Oracle에 매각한 멘토가 저에게 OGSM 프레임워크 를 소개 했습니다. Objectives, Goals, Strategies, Measures의 약자입니다. 그것은 당신이 미래의 3-5년에 대한 그림을 간결하게 그리고 그 과정에서 몇 가지 측정 가능한 목표를 그리는 동시에 이를 달성하기 위한 전략과 단기 전술을 파고들도록 합니다.

전체 팀이 모여서 모든 활동의 초점을 맞출 수 있는 단일 페이지 비즈니스 계획, 다시 방문하고 수정하는 살아있는 문서 로 끝납니다. 예를 들어, 일부 활동이 목표를 달성하기 위해 정의된 전략에 매핑되지 않는 경우 실제로 수행할 가치가 있는지 또는 전략을 업데이트하는지 여부에 대해 질문합니다.

일부는 인기 있는 다른 프레임워크인 OKR(Objectives and Key Results)과의 차이점이 무엇인지 궁금해할 수도 있습니다. OGSM은 미래를 내다보는 반면 OKR은 주로 단기 목표에 중점을 둡니다. 회사의 단계에 따라 OKR을 도입하는 것이 이치에 맞을 수 있지만, 모든 사람이 뒷받침할 수 있는 단일 장기 비전은 필요한 "북극성"인 경우가 많습니다.

SWOT 분석, Porter's 5 Forces, Balanced Scorecard 또는 McKinsey's 3 Horizons와 같이 전반적인 전략 계획에 영향을 미칠 수 있는 다른 많은 기술이 있지만 OGSM은 중요한 것에 대한 팀의 초점을 좁히고 공유하기 위한 개인적 도구로 남아 있습니다. 더 큰 비전.

아이디어

여정 초기에 원칙과 프로세스를 안내하면 성장함에 따라 팀을 조정하는 데 도움이 될 수 있습니다. 저는 데이터 기반 문화와 모든 것을 측정하는 마음가짐이 귀사 문화의 일부가 되어야 하고 최고위층에서 나와야 하며 모든 상호 작용에서 분명해야 한다고 믿습니다.

이 실험적 문화를 강화하는 제가 가장 좋아하는 리소스로는 Eric Ries의 Lean Startup(및 Lean Canvas)과 Jeff Gothelf의 Lean UX가 있습니다. 거의 모든 어드바이저와 스타트업 인큐베이터는 창업자에게 모든 것을 측정하고, 빠르게 반복하고, 최소 실행 가능한 제품(MVP)을 구축하여 아이디어를 시장에서 테스트할 것을 조언합니다. 이들은 모두 "린(Lean)" 원칙에 공감합니다.

Jeff Gothelf는 모든 규모의 조직에서 모든 팀, 부서 및 아이디어에 적용되기 때문에 제가 좋아하는 방향으로 "린(Lean)" 원칙을 취합니다. 전제는 "우리는 아무것도 모른다"이며 [고객이 원하는 것]을 배우기 위해, 그리고 진정으로 문제를 해결하는 것이 과학적 방법을 적용합니다. 가설 진술을 구성하고 측정하면서 테스트하고 결과를 분석하고 필요에 따라 수정합니다. . 이 접근 방식의 가치는 낭비되는 노력을 최소화하고 올바른 문제를 더 빨리 해결하고 있는지 확인하는 것입니다.

설계

사람들이 시스템과 소프트웨어 아키텍처 문서화를 소홀히 하는 것을 보면 목재 더미로 집을 지으려는 사람이 떠오릅니다. 물론 결국 알아낼 수 있지만 계획이 있다면 실수가 줄어들고 훨씬 빨라질 것입니다. 내가 좋아하는 제품 디자인 기술 두 가지는 사용자 스토리 매핑 과 C4 모델 입니다.

내용을 기록함으로써 공유된 이해 를 보장 하고 모든 사람이 합의된 내용을 전달할 책임을 지도록 합니다.

토론과 아이디어를 기록하지 않을 위험

몇 년 전 저는 사모펀드(PE) 회사인 Francisco Partners 의 연례 CTO 서밋에 연사로 초대되었습니다 . 나는 다른 세션에 참석했고 가장 흥미로운 세션 중 하나는 다른 포트폴리오 CTO와 경영진에게 제품 조직의 메트릭 추적에 대해 조언하는 파트너 중 하나였습니다. 저를 놀라게 했지만 이제는 완전히 이해가 되는 메트릭 중 하나는 제품 관리자의 효율성을 평가하기 위해 재작업의 양을 측정하는 것입니다. 나는 다른 엔지니어링 리더들에게 재작업을 측정하는지 물어봤고 대부분 감사하지만 아직은 그렇지 않습니다.

재작업은 시간을 들여 고객을 이해하고 고객에게 가장 즉각적인 가치를 제공하는 데 우선순위를 두어 영향을 미칠 수 있는 핵심 지표입니다. 이것이 바로 사용자 스토리 매핑 연습이 다양한 이해 관계자 간의 협업을 촉진하면서 촉진하는 데 도움이 되는 것입니다. 어떤 회사 단계에서든 그것에 대한 나의 주장은 공유 화이트보드에서 몇 개의 상자를 이동하는 것이 나중에 재작업으로 이어지는 개발 주기를 시작하는 것보다 훨씬 저렴하고 빠르다는 것입니다.

나는 처음으로 내 시대에 추악한 아키텍처 다이어그램을 가지고 있음을 인정합니다. 나는 더 많은 것을 목격했다. 아키텍처 및 다른 시스템과의 관계를 기록하는 데 시간을 투자하는 것이 중요합니다. C4 모델 은 UML 지식 없이 표준 방식으로 수행할 수 있는 가장 좋은 방법 중 하나입니다. 위의 비디오 링크에 설명된 대로 표준 방식은 최대 3단계 깊이(구성 요소 보기)를 설계하는 것입니다. 이를 더 쉽게 해주는 IcePanel 과 같은 제품 이나 다른 플랫폼의 다양한 플러그인 또는 도구가 있습니다. 생각보다 빠르며 이 시리즈의 다음 기사에서 이에 대해 설명합니다.

짓다

당신의 팀이 이 단계에 정통하다고 가정해 봅시다. 성장함에 따라 애자일 이데올로기를 구현하기 위해 잘 정의된 프레임워크를 채택하면 확장에 도움이 될 수 있습니다. "린(Lean)" 원칙을 따르고 학습을 기반으로 우선순위를 변경한다면 이미 제대로 진행하고 있는 것입니다. 조직의 초점이 속도와 혁신에서 성장과 안정성으로 이동함에 따라 그 과정에서 변곡점과 팀 구성에 유의하십시오.

운용하다

제품 개발 관행을 성숙시키는 것과 함께 공동 책임 문화를 유지하기를 원할 것입니다. 여기에서 DevOps 원칙이 적용됩니다. Google은 SRE( Site Reliability Engineering ) 라는 DevOps 구현을 공유했으며 많은 조직에서 이러한 관행을 채택했습니다.

별도의 팀이나 기능이 필요하지 않을 수 있지만 최소한 운영, 모니터링 및 자동화 성향이 있는 엔지니어로 팀을 구성하면 배당금을 지불할 수 있습니다. 예제 스타트업에 대해 더 깊이 파고들고 아키텍처와 클라우드 인프라를 정의할 때 이러한 개념을 더 자세히 살펴볼 것입니다.

성장을 위한 계획

스타트업이 소규모 창립 팀을 넘어 성장함에 따라 아래 그림과 같이 커뮤니케이션 및 거버넌스의 복잡성도 커집니다.

팀 확장 시 커뮤니케이션 문제

기업은 비즈니스의 변곡점을 인식하고 대부분 자율적인 전담 팀을 구성하여 특정 문제를 해결함으로써 이러한 확장 문제를 해결했습니다.

예를 들어 소프트웨어 팀 확장에 대한 훌륭한 리소스는 Seth Blank의 이 블로그 게시물 입니다. 이 게시물 을 꼭 읽어 보시기 바랍니다. Blank는 프로세스, 경우에 따라 회사를 시작하는 데 도움을 준 사람들도 어느 시점에서 미래의 성장과 확장성에 방해가 되거나 "다음 단계"로 향할 수 있다고 경고합니다. 여기에서 McKinsey의 3 Horizons 가 미래 전략 계획과 관련이 있습니다. 반대로 다른 블랭크인 스티브 블랭크는 그것이 오늘날 더 이상 유효하지 않은 이유를 주장합니다 .

조직 설계 및 팀 상호 작용을 위한 실용적이고 단계별 적응형 모델을 제공하는 " 팀 토폴로지 " 라는 또 다른 리소스가 있습니다 . 가장 얇은 실행 가능한 플랫폼(TVP)이라고 하는 조직과 플랫폼을 합리화하는 데 중점을 둡니다.

조직 또는 제품을 확장하는 데 유용한 또 다른 개념은 AKF Partners Scale Cube 입니다. 수년 전 스타트업에서 팀 리더를 위해 구입한 " The Art of Scalability "라는 제목의 책에서 이에 대해 처음 알게 되었습니다. 이 책은 필요에 따라 관련 장으로 건너뛸 수 있는 또 다른 유용한 참조 자료이기도 합니다.

그러나 회사가 계속 성장하고 전담 팀을 구성함에 따라 거버넌스와 잘 정의된 프로세스, 문서화, 멘토링 및 교육의 필요성이 함께 커짐에 따라 거의 모든 사람이 동의할 것입니다. 저는 최근 이 단계에서 여러 팀을 효율적으로 수용하기 위해 클라우드 인프라를 구성하는 최선의 방법에 대한 지침을 찾는 많은 조직을 목격했습니다. 이 시리즈의 뒷부분에서 이에 대해 다룰 것입니다.

이 시리즈의 2부에서는 가상의 온라인 데이트 소프트웨어 스타트업을 설계, 구축 및 확장하기 위해 이러한 조각들을 결합하는 방법을 살펴봅니다.