[Учебный процесс в IT, Развитие стартапа, Управление продуктом] YC Startup Library на русском: Создавать продукт как небольшой стартап (Майкл Сибель) (перевод)

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
19-Ноя-2020 16:32

Цитировать

9 ноября 2020 стартовала бесплатная Школа стартапов для будущих основателей (Startup School for Future Founders от Y Combinator) от лучшего в мире акселератора и мы будем публиковать полезные переводы для тех, кто планирует стать основателем стартапа международного уровня. Следите за новостями YC Startup Library на русском в телеграм-канале или в фейсбуке .

Майкл Сибель — сооснователь (в 25 лет) стартапов Justin.tv/Twitch (капитализация $15 млрд) и Socialcam, член правления Reddit. На данный момент исполнительный директор (CEO) Y Combinator.
Многие проблемы, с которыми я столкнулся в начале развития своей компании, появились потому что я не смог понять, как выпустить продукт в свет. Вместо этого, у меня и моих сооснователей были долгие споры, превращающиеся в ссоры о том, что мы не напишем четкие спецификации, о том что мы не уложимся в сроки, мы теряли мотивацию действовать. Через некоторое время я осознал, что лишь небольшое число людей может действительно научить тому, как выпустить продукт. Они говорят о том, что важно выпускать, но не объясняют как. И вот способ быстрого запуска продукта, который мы придумали во времена моей последней компании. Разумеется, нет необходимости все в точности повторять. Фактически вам необходимо повторить любую часть этого процесса. Но вот, что я вам скажу, более формальные первые шаги, которые есть у хороших стартапов, это те, которые способствуют запуску продукта.
Вот, что мы сделали. Сначала мы пришли к тому, что хотим выпускать наш продукт раз в две недели. У нас было приложение для iOS, которое требовало подтверждение от Apple, что занимало какое-то время. Поэтому такой двухнедельный цикл разработки имел больше всего смысла. Второе: мы назначили человека, ответственного за продукт, и это был я. Если быть точным, когда вы ответственны за продукт, это не значит, что вы решаете, что создавать, это значит, что вы ответственны за то, что мы достигнем цели в нашем цикле разработки и выпустим продукт. В-третьих: мы выяснили, какие у нас ключевые показатели эффективности. Первым показателем было создание нового продукта, вторым — новые пользователи, третьим — сохраненные пользователи. Следующий шаг: кто бы не был во главе, мы придумывали тему для этого цикла разработки продукта основанную на ключевых показателях эффективности, о которых мы говорили ранее. Итак, на этой неделе мы поговорим о том, как удерживать пользователей.
Мы собирали всех людей компании вместе, на том этапе их было всего 4-5 человек. Мы проводили вместе мозговой штурм. Наш цикл разработки продукта начинался со встречи, и это была единственная формальная встреча. Но она длилась столько, сколько требовалось для того, чтобы прийти к определенному выводу. Всего одна встреча, но мы должны были решить, что будем создавать. В начале встречи на большой доске мы расписывали три разные категории: новые функции, баги и тесты, которые мы хотели проводить. Затем мы ходили по кругу и каждый озвучивал идею, которая даст толчок нашему ключевому показателю эффективности, что помогло бы нам удержать пользователей. Каждая идея была написана на доске. Ни одна идея не обсуждалась, не было времени на критику. Если возникали вопросы, кто-то мог прояснить, но все идеи попадали на доску. Конечно, все записывалось в одну из категорий: новая это функция или повторение уже существующей, возможный баг или тест. Это здорово заносить баги в список, так как часто баги это то, что препятствует росту и сохранению пользователей. Они часто идут в странную категорию обслуживания и их удается избежать. У нас ошибки фактически добавлялись непосредственно в цикл разработки продукта — отлично. Итак, как только этот мозговой штурм был проведен, наша доска была заполнена функциями, вещами, которые мы можем сделать.
Следующий шаг на нашем пути назывался “легко, средне, тяжело”. В нашей команде были разные люди, одни более техничные, чем другие. Иногда людям сложно было понять, насколько сложно или легко воплотить ту или иную их идею. Проходя через эту стадию, которую возглавлял тот, кто вел технические процессы в компании, они оценивали идеи, основываясь на том, сколько времени уйдет на их воплощение, два часа, полдня или несколько дней — легко, средне, сложно.
Как только вы видите все идеи на доске, вы прежде всего чувствуете себя включенным в процесс, каждый человек в компании чувствует себя вовлеченным в процесс придумывания того, над чем мы будем работать эти две недели. Во-вторых, когда вы видите идеи других на доске, вы начинаете думать, что, возможно, какие-то их идеи лучше ваших и вы хотите поддержать их идеи вместо своих собственных. И, в-третьих, как только вы сталкиваетесь с “легко, средне, сложно”, все становится по-настоящему весело, потому что неожиданно вы осознаете, что, возможно, лучшая идея на доске — самая простая, которую можно быстро воплотить. А та идея, которую выдвинули вы — средняя или сложная, на которую уйдет больше времени. Неожиданно у вас появляется эти своего рода объективные рамки, посредством которых вы можете оценить ситуацию и понять, что делать, вместо того, чтобы просто спорить на почве ваших убеждений или мыслей.
Следующая ступень называется “сначала трудности”. С небольшой командой вы можете выполнить одну или две сложные задачи за две недели. Поэтому проще всего обсуждать только сложные идеи, потому что как только вы сталкиваетесь со средними или легкими идеями, которые могут быть более эффективными, большинство сложных идей уходят на второй план. Сначала вы работаете над сложными идеями, затем над средними, затем над простыми. Вы выписываете их в список.
И следующий шаг, когда абсолютно все в одной комнате, вы структурируете идеи, вы записываете кто и что точно хочет сделать с идеей и кто конкретно отвечает за ту или иную часть процесса. Вы делаете это на месте, чтобы не возникло никакой путаницы в том, что будет сделано. Затем поместите эту спецификацию в любую систему управления продуктом или любое другое программное обеспечение, которое вы используете, так чтобы все могли видеть этот документ и чтобы каждый делал необходимое.
Затем, как только встреча заканчивается, вы замолкаете и приступаете к работе. Вы прекращаете все споры, даже если ваша идея не была реализована. В этом нет ничего страшного, просто смиритесь с этим, будут и другие встречи по продуктам через неделю или две, где можно будет снова вносить предложения. Возможно, вы сможете податься в аналитику и найти больше доказательств пригодности вашей идеи. В любом случае, так как вы знаете, что скоро наступит другая часть цикла развития, нет необходимости цепляться за то, что вашу идею не выбрали. Поскольку человек, занимается продуктом, особенно если он не инженер, в данном случае крайне важно промолчать. Не вносите изменений в спецификацию, не меняйте расстановку обязанностей, у вас есть фиксированное количество времени, и самое главное — выпустить продукт в руки клиентам, научившись чему-то при этом. Если вы уверены в том, что цикл разработки хорошо функционирует, вам будет понятно, что даже если один из циклов не принесет плодов, то другие обязательно это сделают.
В частности для нас как для мобильной компании завершающим этапом цикла развития продукта были тесты. Тяжело выпускать исправления ошибок в мобильном приложении, так как уходит какое-то время на подтверждение от Apple, поэтому приходится быть более внимательными на этапе тестов. Для нас тестирование было работой всей команды, потому что все это ненавидели. У нас был длинный список того, что нужно проверить. Это был исторический момент. Каждый раз, когда у нас был новый релиз, мы пополняли наш список для проверки. У нас было высказывание: “Тестирует каждый”. В результате все инженеры и остальная часть команды, мы все тестировали то, что было в списке. Как только мы находили баги, мы их выписывали и старались понять, как их повторить. Затем после всех тестов проводилось исправление ошибок. В итоге, все прочувствовали, насколько это болезненно проводить тесты.
Итак, цикл развития продукта, который мы создали, очень хорошо работал для нас. Я не знаю, будет ли это работать хорошо и для вас. Я лишь рекомендую как можно скорее создать что-то вроде цикла со своим ритмом.
Спасибо.
Извините, данный ресурс не поддреживается. :(
(Мы готовим полный перевод всех учебных материалов Startup School и YC Startup Library, следите за новостями в телеграм или фейсбуке )
Полезные материалы

===========
Источник:
habr.com
===========
===========
Автор оригинала: Michael Seibel
===========Похожие новости:

Теги для поиска: #_uchebnyj_protsess_v_it (Учебный процесс в IT), #_razvitie_startapa (Развитие стартапа), #_upravlenie_produktom (Управление продуктом), #_y_combinator, #_yc_startup_library_na_russkom (YC Startup Library на русском), #_uchebnyj_protsess_v_it (
Учебный процесс в IT
), #_razvitie_startapa (
Развитие стартапа
), #_upravlenie_produktom (
Управление продуктом
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 23-Ноя 00:45
Часовой пояс: UTC + 5