В первой части этой серии мы рассмотрели методологии и фреймворки, которые я считаю полезными при создании и развитии стартапов в области программного обеспечения. Цель этого поста — проиллюстрировать, как вы можете применять эти методы, чтобы свести к минимуму напрасные усилия, и как планирование вашего программного бизнеса переносится на вашу облачную инфраструктуру.

Предпосылки для движения вперед

• Вы прочитали 1 часть серии
• Вы знакомы с фреймворками/методологиями, которые мы изучаем ниже, просмотрев ссылки на видео, опубликованные в части 1 .

На приведенной выше диаграмме показаны ключевые концепции вышеупомянутых методологий. В этом посте мы повеселимся, придумав вымышленный стартап онлайн-знакомств и «масштабируя его». Мы проиллюстрируем применение этих принципов и взаимосвязей между стратегией компании и потребностями в продуктах и ​​росте, а также то, как они учитывают нашу структуру облачной инфраструктуры.

Определите проблему, которую мы решаем, и для кого

Предположим, что вам и другим надоело одиночество, и существующие решения не помогают. Вы были на свадьбах, на самом деле слишком много, и вы были в барах, и даже пробовали популярные приложения, но все еще чувствуете, что чего-то не хватает. Вы увлечены этой проблемой и считаете себя командой, которая поможет решить проблему одиночества людей, в том числе и вашего собственного. Давайте сначала проанализируем потенциальные стратегии других решений.

Отказ от ответственности

Я никогда не пользовался приложением для онлайн-знакомств, поэтому просто «предполагаю», какие функции и функции они включают. Используя то, что показывают по телевидению или заголовки новостей о различных популярных приложениях, мы можем сделать вид, что создали конкурента. Если мои предположения далеки от истины или если мы не исследуем все типы отношений, я прошу вас приостановить недоверие ради иллюстрации этих концепций .

электронная гармония

У этой службы была теория, согласно которой, сопоставляя данные на основе научного профиля личности, люди будут чувствовать себя менее запуганными. Их стратегия заключается в том, чтобы сделать личность основным фактором, они будут привлекать людей, менее уверенных в своей внешности, которые все еще одиноки, извлекая выгоду из неиспользованного рынка.

Tinder

У этой службы была теория о том, что многие люди одиноки, но не ищут долгосрочных отношений. Их стратегия заключалась в том, чтобы заменить случайные знакомства и захватить эту часть рынка.

Бамбл

У этого сервиса была теория, согласно которой женщины чувствовали бы себя более комфортно на платформе, если бы могли выбирать, с кем общаться. Их стратегия заключалась в том, чтобы позволить женщинам решать, отправлять ли им первое сообщение после матча.

eTumble — НОВИНКА!

Наше предположение состоит в том, что люди одиноки, и решения на рынке еще не решили проблему одиночества в глобальном масштабе . Мы считаем, что выигрышное решение — это комбинация всех трех вышеперечисленных. Мы подозреваем, что в глубине души случайные искатели секса предпочли бы иметь шанс на более глубокую личную связь через первоначальное совпадение личности, но женщины делают выбор, взаимодействовать ли.

Практики бережливого стартапа советуют действовать как «грандиозный эксперимент», делая смелые предположения , а затем наблюдая (а не спрашивая) поведение пользователей, быстро повторяя итерации. Часто мы выбрасываем идеи, используя канву «бережливого производства» , но мы предполагаем, что наша команда уже сделала это выше. Давайте начнем!

Начиная с видения и стратегии

анализ SWOT

Признавая как внутренние (сильные и слабые стороны), так и внешние (возможности, угрозы) силы, вы можете использовать SWOT-анализ, чтобы лучше определить, что должно произойти, чтобы добиться успеха.

Этот анализ информирует вас о дизайне вашего продукта, когда вы проверяете гипотезы о решении неизбежных взлетов и падений. Например, если высокий отток пользователей представляет угрозу, вы можете отдать приоритет функциям, которые заставят людей возвращаться на вашу платформу. Слабым местом было отсутствие психологического опыта в команде, вы знаете, на кого ориентироваться при найме или привлечении консультантов. Если у команды ограниченный опыт работы с конкурирующими приложениями, то вы знаете, что задача состоит в том, чтобы использовать их и ходить на свидания — победа, победа.

Определите первоначальный стратегический план с помощью OGSM

На ранней стадии ваша цель будет состоять в том, чтобы быстро запустить минимально жизнеспособный продукт (MVP), чтобы начать наблюдать за поведением пользователей и итеративно проверять гипотезы. В мире программного обеспечения мы часто шутим, что прототипы всегда превращаются в производство, несмотря на наши самые лучшие намерения. Потратьте несколько дней на мозговой штурм с вашей командой, чтобы задокументировать стратегии и меры, чтобы сократить количество переделок и ускорить проектирование и разработку вашего продукта — давайте рассмотрим, как это сделать, ниже.

Обратите внимание, что в приведенном выше примере OGSM мы уже начинаем определять нашу будущую команду, продукт, показатели и потребности в инфраструктуре. Нам понадобится экспертиза в мобильных приложениях, машинном обучении и разработке API. Нам также понадобится языковой перевод, обфускация текста и изображений и прием онлайн-платежей. Для глобальной аудитории нам необходимо соблюдать нормативные требования и требования к конфиденциальности, особенно в Европейском Союзе.

Бережливый UX

Lean UX более известен среди продуктовых команд, где автор Джефф Готхельф имел свое скромное начало. Я считаю, что эффективность передачи любых идей посредством формулировок гипотез требует осведомленности во всей организации, а не только в продуктовых командах. Я думаю, что Lean UX связан со стратегией и видением и используется повсеместно.

Каждая стратегия, а затем и тактика (функция) в приведенном выше плане OGSM по существу является гипотезой. Чем больше мы формулируем наши идеи в этой структуре, тем более действенными и сфокусированными они становятся. Например, стратегию, согласно которой мы достигнем наших целей, «предоставив более безопасное место для взаимодействия», можно сформулировать так:

«Мы считаем, что [миллионы пользователей] присоединятся к нашему сервису, если [женщины] [почувствуют себя в большей безопасности при общении] с [только они решат начать разговор после матчей]».

Это примерно переводится как «Мы ​​считаем, что [бизнес-результат] будет достигнут, если [пользователь] получит [выгоду] с помощью [функции]». как описано в канве Lean UX. Я иногда заменяю этот формат другим, определенным в Agile-принципах «Product Discovery», но предпосылка та же — структурированное общение .

Вы можете увидеть итеративный характер этих методологий, когда вы их комбинируете. Если вы еще этого не сделали, я рекомендую вам просмотреть видеоролики о Lean UX в части 1 этой серии .

Дизайн продукта

Возвращаясь к принципам «бережливого производства», когда у вас есть смелые предположения или гипотезы о проблеме, которую вы решаете, о том, для кого вы ее решаете, и как вы собираетесь ее решать, вы должны быстро повторять и тестировать их.

Вместо того, чтобы спрашивать пользователей, всегда лучше наблюдать за их поведением , чтобы подтвердить свои предположения, поэтому рекомендуется запустить MVP. В работающем продукте вы также можете использовать инструменты A/B-тестирования или флаги/переключатели функций.

Нам не нужны сразу все функции, которые ускользнули от нашего OGSM, чтобы проверить наши теории, но теперь у нас есть целостное понимание того, куда мы движемся. Затем мы определяем приоритеты того, что должен предложить наш MVP, чтобы максимизировать ценность для пользователя, поскольку после этого мы быстро итерируем . Для этого мы будем использовать User Story Mapping .

Отображение пользовательской истории

То, что вы видите выше, уже шестая версия! Начав с целостного представления, я быстро наметил общий путь пользователя. Затем я перетасовал ящики и перераспределил пользовательские истории, чтобы определить наименьшую сумму, которую мы могли бы предоставить для тестирования желаемых результатов для целевой аудитории.

Попутно проверяя гипотезы, вы применяете свои открытия и продолжаете оперативно редактировать эти «живые документы», вместо того чтобы тратить время на застойные подробные спецификации.

Архитектура модели C4

Теперь у нас есть информация, которая поможет нам определить наше программное обеспечение и системную архитектуру, но стандартизированным способом часто упускают из виду. Убедитесь, что у вас есть план (или план) того, что вы строите, чтобы эффективно общаться с другими заинтересованными сторонами. Хотя UML остается давним стандартом, сегодня я рекомендую более легкую модель C4 .

Для краткости этой статьи мы проиллюстрируем частичный пример нашей архитектуры для eTumble. Хотя существует 4 уровня C 4 , стандартная практика состоит в том, чтобы иллюстрировать только настолько глубокие, насколько это необходимо; уровень «Код», который фактически представляет собой нотацию UML, обычно пропускается.

Как отмечалось в моем заявлении об отказе от ответственности выше, это вымышленное приложение, и я никогда не пользовался онлайн-службой знакомств, поэтому это обоснованные предположения, иллюстрирующие процесс.

Часто я начинаю делать наброски идей на бумаге, чтобы продумать дизайн. Как только появляется общее представление о том, что нужно, я перечисляю элементы архитектуры, чтобы выделить детали. Например, мы знаем, что нам понадобится база данных, но наша стратегия подразумевает глобальную игру. Нам нужно решить, можем ли мы начать с Postgres или MySQL для запуска, и насколько сложно будет позже перейти на распределенную систему, такую ​​​​как Cockroach DB или GCP Cloud Spanner.

Испытывая иногда «блок писателей», когда я смотрю на блоки и строки на экране, я обнаружил, что использование электронной таблицы, как показано ниже , позволяет легко перемещать вещи или вставлять строки, когда я думаю о других вещах, прежде чем строить диаграммы.

В некоторых приложениях вы можете просто копировать/вставлять, как в IcePanel , как показано ниже. Существует поддержка Markdown, которая становится еще быстрее, если вы уже знакомы.

Надеюсь, это продемонстрирует, как быстро вы можете перенести то, что вы записали, в инструмент для построения диаграмм — на создание красивых диаграмм уходит меньше часа. Представьте себе взаимодействие с дизайнерами и инженерами с проектами, описанными выше, и насколько быстрее (и дешевле) они будут.

Увеличение масштаба

Предыдущие намеки на то, что мы будем «масштабировать это», означали, что мы предугадываем наши будущие потребности, основываясь на нашем стратегическом плане и нашем общем видении, показанном на карте-истории. Ранее я упоминал масштабный куб AKF и, применяя его принципы осей xyz, пришел к выводу, что нашему глобальному масштабу и десяткам миллионов пользователей потребуется дизайн без сохранения состояния, управляемая событиями система, микросервисная архитектура и, в конечном итоге, несколько команд с охватом хостинга. несколько географических регионов на общедоступной облачной платформе.

• Наша ось X ( дублирование и масштабирование ) поддерживается контейнерными приложениями без сохранения состояния и общедоступным облачным хостингом.
• Наша ось Y ( specialize ) поддерживается специально созданными микросервисами, запускаемыми либо HTTP/RPC, либо сообщениями Pub/Sub. Они также помогают определить, как вы, вероятно, будете развивать свои команды, позволяя автономии и слабой связанности владеть ключевой частью ценности в системе; это часто совпадает с базовым UX, показанным на карте истории.
• Наша ось Z ( разделить похожие вещи ) соответствует регионализации. Мы не рассматриваем это полностью в нашем вымышленном примере. Давайте предположим, что с учетом глобальной стратегии юрисдикционные ограничения на суверенитет систем и данных, иностранные валюты, языки и будущие стратегии выхода на рынок (GTM) могут повлиять на то, как мы масштабируем эту ось. Это может быть даже основано на том, где мы находим/предоставляем таланты для нашей команды, или даже, как описывается в «Топологиях команды», на когнитивной нагрузке команды.

Что мы узнали и построили на данный момент:

Время, потраченное на разработку eTumble, нашего вымышленного стартапа онлайн-знакомств:

• Бережливый [Запуск | UX] canvas — мы не иллюстрировали это, но обычно это момент, когда вы начинаете писать, какую проблему вы решаете, для кого вы решаете, и преимущества/ценность, которые вы предлагаете. Вы можете подтвердить свою идею, например, с помощью «дымовой завесы MVP» и целевой страницы. Посмотрите видео в части 1 , чтобы узнать больше.
• SWOT-анализ — мы определили положительные стороны, которые мы хотели использовать, и отрицательные стороны, которые нам нужно решить, что стало основой для нашего плана OGSM. (30 мин; ожидать несколько часов)
• План OGSM — мы определили ключевые функции, технологии, показатели и команду, которые нам потребуются для реализации нашей стратегии, на основе нашей карты историй. (1 час; ожидать 1-2 дня)
• Карта историй — мы организовали и расставили по приоритетам пользовательские истории, идентифицировав нашего кандидата на MVP, информируя нашу целостную архитектуру, как показано выше. (3 часа; ожидать 1-2 дня)
• Архитектура модели C4 — мы определили необходимые системы, базы данных и компоненты, сообщив о необходимой инфраструктуре. (3 часа; ожидать 2–5 дней)

Подпитываясь этими «живыми документами», наша команда и заинтересованные стороны теперь имеют общее понимание того, почему мы делаем то, что делаем, как мы планируем победить (или, по крайней мере, теории для проверки), и что мы собираемся построить для достижения этой цели. решить глобальную проблему.

Вкладывая это время в совместную работу и записывая вещи, вы также упрощаете процесс проектирования облачной инфраструктуры, репозиториев исходного кода и мониторинга/показателей, которые нам в конечном итоге потребуются для поддержки eTumble. Мы рассмотрим это и многое другое в части 3 этой серии .

Спасибо, что дочитали до сих пор, и я надеюсь, вам понравится более глубокое техническое погружение в части 3 .