이 시리즈의 1부 에서는 소프트웨어 신생 기업을 구축하고 성장시키는 데 도움이 되는 방법론과 프레임워크를 살펴보았습니다. 이 게시물의 목적은 이러한 기술을 적용하여 낭비되는 노력을 최소화하는 방법과 소프트웨어 비즈니스 계획이 클라우드 인프라로 변환되는 방법을 설명하는 것입니다.

앞으로 나아가기 위한 전제 조건

• 시리즈의 1 부를 읽었습니다 .
• 1부 에서 공유된 비디오 링크를 시청하여 아래에서 살펴보는 프레임워크/방법론에 익숙합니다.

위의 다이어그램은 앞서 언급한 방법론의 핵심 개념을 보여줍니다. 이 게시물에서는 가상의 온라인 데이트 시작을 발명하고 "확장"하는 재미를 느낄 것입니다. 이러한 원칙과 회사 전략의 관계, 제품 및 성장 요구 사항, 그리고 이러한 원칙이 클라우드 인프라 설계에 어떤 영향을 미치는지 설명합니다.

우리가 해결하고 있는 문제와 누구를 위한 것인지 식별

당신과 다른 사람들이 외로움에 싫증이 나고 기존 솔루션이 그것을 자르지 않는다고 가정하십시오. 당신은 실제로 결혼식에 너무 많이 가봤고 바에 가봤고 인기있는 앱을 사용해 보았지만 여전히 뭔가 빠진 것 같은 느낌이 듭니다. 당신은 이 문제에 대해 열정적이며 당신을 포함하여 사람들의 외로움을 해결하는 데 도움을 주는 팀이라고 믿습니다. 먼저 다른 솔루션의 잠재적인 전략을 분석해 보겠습니다.

부인 성명

나는 온라인 데이트 앱을 사용한 적이 없기 때문에 어떤 기능이 포함되어 있는지 "추측"할 뿐입니다. TV에 나오는 내용이나 다양한 인기 앱의 헤드라인을 사용하여 경쟁자를 구축하는 척할 수 있습니다. 내 가정이 완전히 빗나가거나 우리가 모든 유형의 관계를 탐구하지 않는 경우 이러한 개념을 설명하기 위해 불신을 중지할 것을 요청합니다 .

eHarmony

이 서비스는 과학적 성격 프로파일을 기반으로 한 매칭을 통해 사람들이 덜 위축될 것이라는 이론을 가지고 있었습니다. 그들의 전략은 성격을 주요 요인으로 삼는 것입니다. 그들은 미개척 시장을 이용하여 여전히 외롭고 외모에 자신이 없는 사람들을 끌어들일 것입니다.

부싯깃

이 서비스는 많은 사람들이 외롭지만 장기적인 관계를 추구하지 않는다는 이론을 가지고 있었습니다. 그들의 전략은 캐주얼 만남을 대체하고 시장의 이 부분을 포착하는 것이었습니다.

범블

이 서비스에는 여성이 누구와 관계를 맺을지 선택할 수 있다면 플랫폼에서 더 편안함을 느낄 것이라는 이론이 있었습니다. 그들의 전략은 경기 후 첫 번째 메시지를 보낼지 여부를 여성이 결정하도록 하는 것이었다.

eTumble — 새로운 기능!

우리 는 사람들이 외롭고 시장의 솔루션이 아직 전 세계적으로 외로움을 해결하지 못했다고 가정 합니다. 우리는 승리하는 솔루션이 위의 세 가지 모두의 조합이라고 믿습니다. 우리는 깊은 곳에서 캐주얼한 만남을 추구하는 사람들이 초기 성격 일치를 통해 더 깊은 개인적 연결의 기회를 갖는 것을 선호할 것이라고 의심하지만, 상호 작용 여부는 여성이 선택합니다.

Lean Startup 관행은 대담한 가정 을 한 다음 빠르게 반복하면서 사용자의 행동 을 관찰(묻지 않음) 하여 "대규모 실험"처럼 운영할 것을 조언 합니다. 종종 우리는 "Lean" 캔버스 를 사용하여 아이디어를 쏟아내지 만 우리 팀은 위에서 이미 수행했다고 가정합니다. 시작하자!

비전과 전략으로 시작

SWOT 분석

내부(강점, 약점) 및 외부(기회, 위협) 세력을 모두 인정함으로써 SWOT 분석을 활용하여 성공하기 위해 발생해야 하는 사항을 더 잘 식별할 수 있습니다.

이 분석은 피할 수 없는 기복에 대한 해결에 대한 가설을 테스트할 때 제품 설계에 정보를 제공합니다. 예를 들어 높은 사용자 이탈이 위협이 되는 경우 사람들이 플랫폼을 다시 찾도록 하는 기능에 우선순위를 둘 수 있습니다. 약점을 감안할 때 팀의 심리학 경험이 부족하다는 점을 감안할 때 고문을 고용하거나 유치하는 동안 누구를 목표로 삼아야 하는지 알 수 있습니다. 팀이 경쟁 앱에 대한 경험이 제한적이라면 앱을 사용하고 데이트를 하는 것이 과제라는 것을 알 수 있습니다.

OGSM을 사용하여 초기 전략 계획 정의

초기 단계에서 귀하의 목표는 MVP(Minimum Viable Product)를 신속하게 출시하여 사용자 행동을 관찰하고 가설을 반복적으로 테스트하는 것입니다. 소프트웨어 세계에서 우리는 최선의 의도에도 불구하고 프로토타입이 항상 프로덕션이 된다는 농담을 자주 합니다. 전략과 조치를 문서화하기 위해 팀과 브레인스토밍하는 데 며칠을 투자하면 재작업을 줄이고 제품 설계 및 개발 속도를 높일 수 있습니다. 아래에서 그 방법을 살펴보겠습니다.

위의 OGSM 예에서 우리는 이미 미래의 팀, 제품, 메트릭 및 인프라 요구 사항을 파악하기 시작했습니다. 모바일 애플리케이션, 기계 학습 및 API 개발에 대한 전문 지식이 필요합니다. 또한 언어 번역, 텍스트 및 이미지 난독화, 온라인 결제 수락이 필요합니다. 전 세계 고객을 위해 우리는 특히 유럽 연합에서 규제 및 개인 정보 보호 요구 사항을 충족해야 합니다.

린 UX

Lean UX 는 저자 Jeff Gothelf가 겸손하게 시작한 제품 팀 사이에서 더 잘 알려져 있습니다. 가설 진술을 통해 아이디어를 전달하는 효과는 제품 팀뿐만 아니라 조직 전체에 걸쳐 인식을 보장한다고 생각합니다. Lean UX는 전략과 비전에 속하며 모든 곳에서 사용된다고 생각합니다.

위의 OGSM 계획에서 각 전략과 이후의 전술(기능)은 본질적으로 가설입니다. 우리의 아이디어를 이 구조로 더 많이 표현할수록 아이디어는 더 실행 가능하고 집중됩니다. 예를 들어, "보다 안전한 상호 작용 장소 제공"을 통해 목표를 달성할 전략은 다음과 같이 표현할 수 있습니다.

"우리는 [여성]이 [만약 그들만이 경기 후 대화를 시작하기로 선택한]과 [상호작용하는 것이 더 안전하다고 느끼면] [수백만 명의 사용자]가 우리 서비스에 가입할 것이라고 믿습니다."

이는 "[사용자]가 [기능]을 통해 [혜택]을 달성하면 [비즈니스 결과]가 달성될 것이라고 믿습니다." 로 느슨하게 해석됩니다. 린 UX 캔버스에 설명된 대로. 나는 때때로 이 형식을 "제품 발견" 애자일 원칙에 정의된 다른 형식과 교환하지만 전제는 동일 합니다. 바로 구조화된 커뮤니케이션 입니다.

이러한 방법론을 결합하면 이러한 방법론의 반복적 특성을 볼 수 있습니다. 아직 검토하지 않으셨다면 이 시리즈의 1부 에서 Lean UX에 대한 비디오를 검토하시기 바랍니다 .

제품 디자인

"린(Lean)" 원칙과 관련하여, 해결하려는 문제, 해결 대상, 해결 방법에 대한 대담한 가정이나 가설이 있으면 신속하게 반복하고 테스트해야 합니다.

사용자에게 질문하는 것보다 항상 사용자 의 행동을 관찰 하여 가정을 검증하는 것이 가장 좋습니다. 그렇기 때문에 MVP를 시작하는 것이 좋습니다. 라이브 제품에서는 A/B 테스트 도구 또는 기능 플래그/토글도 활용할 수 있습니다.

이론을 테스트하기 위해 OGSM에서 회피한 모든 기능이 즉시 필요하지는 않지만 이제 우리가 향하고 있는 방향에 대한 전체론적 이해가 있습니다. 다음으로 빠르게 반복 하면서 MVP가 사용자 가치를 극대화하기 위해 무엇을 제공해야 하는지 우선순위를 정합니다 . 이를 위해 사용자 스토리 매핑 을 활용 합니다.

사용자 스토리 매핑

위에 보이는 것은 이미 버전 6입니다! 전체적인 관점에서 시작하여 전체 사용자 여정을 신속하게 파악했습니다. 그런 다음 대상 고객에게 원하는 결과를 테스트하기 위해 전달할 수 있는 최소량을 식별하기 위해 상자를 뒤섞고 사용자 스토리의 우선 순위를 재지정했습니다.

그 과정에서 가설을 테스트하면서 정체된 세부 사양에 시간을 낭비하지 않고 발견한 내용을 적용하고 민첩한 방식으로 이러한 "살아 있는 문서"를 계속 편집합니다.

C4 모델 아키텍처

이제 우리는 소프트웨어 및 시스템 아키텍처를 정의하는 데 도움이 되는 정보를 가지고 있지만 표준화된 방식으로 정의하는 것을 간과하는 경우가 많습니다. 다른 이해 관계자와 효율적으로 소통하기 위해 구축하려는 계획(또는 청사진)이 있는지 확인하세요. UML은 오랫동안 표준으로 남아 있지만 오늘은 더 가벼운 C4 모델 을 권장합니다.

이 문서의 간결성을 위해 eTumble용 아키텍처의 일부 예를 설명합니다. C 4 에는 4개의 수준이 있지만 표준 관행은 필요한 만큼만 자세히 설명하는 것입니다. 효과적으로 UML 표기법이 될 "코드" 수준은 일반적으로 건너뜁니다.

위의 면책 조항 에서 언급했듯이 이것은 가상의 앱이며 온라인 데이트 서비스를 사용한 적이 없으므로 프로세스를 설명하기 위한 교육적인 추측입니다.

종종 나는 디자인을 통해 생각하기 위해 종이에 아이디어를 스케치하기 시작합니다. 무엇이 필요한지에 대한 일반적인 아이디어가 있으면 아키텍처의 요소를 나열하여 세부 사항을 정리합니다. 예를 들어, 우리는 데이터베이스가 필요하다는 것을 알고 있지만 우리의 전략은 글로벌 플레이를 의미합니다. 출시를 위해 Postgres 또는 MySQL로 시작할 수 있는지 여부와 나중에 Cockroach DB 또는 GCP의 Cloud Spanner와 같은 분산 시스템으로 마이그레이션하는 것이 얼마나 어려운지 결정해야 합니다.

때때로 화면의 상자와 선을 응시하면서 "작가의 블록"을 경험 하면 다이어그램을 작성하기 전에 더 많은 것을 생각하면서 아래와 같은 스프레드시트를 사용 하면 쉽게 항목을 이동하거나 행을 삽입할 수 있습니다.

일부 앱에서는 아래와 같이 IcePanel 내에서와 같이 간단히 복사/붙여넣기를 할 수 있습니다. 익숙해지면 훨씬 더 빠른 Markdown이 지원됩니다.

바라건대 이것은 작성한 내용을 다이어그램 작성 도구로 얼마나 빨리 전송할 수 있는지 보여줍니다. 아름다운 다이어그램을 생성하는 데 1시간도 걸리지 않습니다. 위의 디자인으로 디자이너 및 엔지니어와 참여하고 얼마나 더 빠르고 더 저렴할지 상상해 보십시오.

확장성

우리가 "확장"할 것이라는 이전의 힌트는 우리가 전략 계획과 스토리 맵에 설명된 큰 그림 보기를 기반으로 미래의 요구 사항을 예상한다는 것을 의미했습니다. 이전에 AKF Scale Cube 를 언급했으며 xyz 축의 원칙을 적용하여 우리의 글로벌 규모와 수천만 명의 사용자가 상태 비저장 설계, 이벤트 기반 시스템, 마이크로 서비스 아키텍처 및 궁극적으로 호스팅 스패닝이 있는 여러 팀이 필요하다는 결론을 내렸습니다. 퍼블릭 클라우드 플랫폼의 여러 지역.

• 우리의 x축 ( 복제 및 확장 )은 상태 비저장, 컨테이너화된 애플리케이션 및 퍼블릭 클라우드 호스팅에 의해 수용됩니다.
• 우리의 y축 ( specialize )은 HTTP/RPC 또는 Pub/Sub 메시지에 의해 트리거되는 특수 제작된 마이크로 서비스에 의해 수용됩니다. 이들은 또한 팀을 성장시키는 방법을 정의하여 자율성과 느슨한 결합이 시스템의 핵심 가치를 소유할 수 있도록 합니다. 이것은 종종 스토리 맵에 설명된 기준 UX에 맞춰집니다.
• 우리의 z축 ( 유사한 것 나누기 )은 지역화에 의해 수용됩니다. 가상 예제에서는 이 문제를 완전히 다루지 않습니다. 시스템 및 데이터 주권, 외화, 언어 및 향후 채널 판매 GTM(go-to-market) 전략에 대한 관할권 제약이 모두 이 축을 확장하는 방법에 영향을 미칠 수 있는 주어진 글로벌 전략을 가정해 보겠습니다. 팀의 인재를 찾거나 제공하는 위치 또는 "팀 토폴로지"에서 설명하는 것처럼 팀의 인지 부하를 기반으로 할 수도 있습니다.

지금까지 배우고 구축한 것:

지금까지 가상의 온라인 데이트 스타트업인 eTumble을 설계하는 데 소요된 시간:

• 린 [시작 | UX] 캔버스 — 우리는 그것을 설명하지 않았지만 일반적으로 이것은 당신이 어떤 문제를 해결하고 있는지, 누구를 위해 해결하고 있는지, 그리고 당신이 제공하는 이점/가치를 작성하기 시작하는 지점입니다. 예를 들어 "연막 MVP"와 랜딩 페이지로 아이디어를 검증할 수 있습니다. 자세한 내용 은 1부 동영상을 시청하세요 .
• SWOT 분석 — 우리는 활용하고 싶은 긍정적인 요소와 해결해야 할 부정적인 요소를 식별하여 OGSM 계획에 정보를 제공했습니다. (30분, 몇 시간 예상)
• OGSM 계획 — 전략을 구현하는 데 필요한 주요 기능, 기술, 메트릭 및 팀을 식별하여 스토리 맵에 정보를 제공합니다. (1시간, 1~2일 예상)
• 스토리 맵 — 사용자 스토리를 구성하고 우선 순위를 지정하여 MVP 후보를 식별하고위에서 설명한 전체 아키텍처를 알려줍니다. (3시간, 1~2일 예상)
• C4 모델 아키텍처 — 필요한 시스템, 데이터베이스 및 구성 요소를 식별하여 필요한 인프라를 알려줍니다. (3시간, 2~5일 예상)

이러한 "살아있는 문서"에 힘입어 이제 우리 팀과 이해관계자는 우리가 왜 우리가 하고 있는 일을 하는지, 어떻게 승리할 계획인지(또는 적어도 테스트할 이론), 무엇을 구축할 것인지에 대해 공유된 이해 를 갖게 되었습니다. 큰 그림 문제를 해결합니다.

이 시간을 투자하여 협업하고 기록하면 클라우드 인프라, 소스 코드 리포지토리 및 궁극적으로 eTumble을 지원하는 데 필요한 모니터링/메트릭을 설계하는 프로세스가 간소화됩니다. 이 시리즈의 3부에서 이에 대해 살펴보겠습니다 .

지금까지 읽어 주셔서 감사합니다. 3부 에서 좀 더 기술적인 심층 분석을 즐기시기 바랍니다 .