15.06.2020 18:18:41 |
Автор: С чего начинается IT-стартап и вообще любая новая задача в IT-проекте? С идеи и вопросов к себе
Чтобы создать вау, недостаточно только вдохновения. Важно быть уверенным в себе и в своей идее. Порой, чтобы убедить себя, что придумано что-то полезное и крутое, нужно реально выдержать груз сомнений и устранить их в начале пути. А вот если груз устранить не удалось, то стоит пересмотреть планы на запуск и отложить инвестиции на что-то более стоящее.
Тема не нова, но сталкиваться с разочарованными разработчиками и бизнесменами периодически приходится. Разочарование обычно возникает из-за потухающего к середине проекта костра. На это есть распространенные причины: непонимание что и для кого делаем, а затем сожаление о потраченном времени.
Я очень рекомендую этот материал к прочтению тем, кто хочет заказывать разработку стартапов, но сомневается в своем решении, и тем, кто крутится в сфере IT над созданием-развитием проектов. При создании чего-либо для всех сторон важно осознание, что они творят нечто востребованное, а не трудятся над созданием бесполезного бантика. Вдохновение и костер в душе никто не отменяет.
Я хочу постараться направить людей с потоком идей по лестнице самоанализа, а вот куда она приводит вверх или не очень, главное, чтобы к верному и честному решению.
Предлагаю познакомиться с чек-листом Не хочу делать бесполезное, который рекомендую пройти, прежде чем с горящими глазами начинать разработку.
Чек-лист с содержанием в коротких абзацах
Я хочу создать <Идея>, потому что <Кто Ваши пользователи и конкретные примеры реальных потенциальных клиентов?> имеют проблемы: <Какие проблемы у Ваших потенциальных пользователей?>.
Мое решение будет <Список особенностей, составляющих Идею>, что позволит устранить проблемы целевой аудитории. Мои пользователи Не могут решить проблемы иначе / Также могут решить задачу <Список альтернативных решений>.
Я выполнил анализ информации и Не нашел аналогов своего решения / Нашел аналоги своего решения, но мое будет лучше, потому что <Список уникальных особенностей, отличающих Идею от аналогов>.
Я готов потратить на создание минимальной версии продукта <Сумма денег и количество времени>, чтобы получить <Сумма денег> за <Количество времени>. Я принимаю риск, что я могу ошибаться в расчетах.
Я планирую запустить разработку <Дата>.
Я готов и я уверен в своей Идее.
Use the Google, my Dear
Применимо не только к IT, а вообще для любой области. Как бы смешно это ни было, но реально приходится напоминать людям о том, что есть Google, и что их крутая идея могла быть изобретена вчера или 5 лет назад. Но тут важно не просто загуглить и разочароваться в себе, а изучить найденную информацию (перекрашивать и улучшать можно всё).
Если Google говорит, что идея нова, то с удовлетворением можно ставить галочку в чек-листе и переходить дальше, но советую разочаровавшимся не отчаиваться и попробовать провести анализ. Для начала пролистаем первые страницы результатов и выберем список работающих решений (если хоть одно вообще работает!) их может быть одно, а могут быть десятки.
Занимаясь развитием продукта и найдя, что фича была реализована неоднократно другими разработчиками, стоит срочно включать её в состав своего приложения. Если это сделали много конкурентов, значит оно пользуется спросом. А вот если аналогов не так много, то стоит попробовать поискать отзывы или статистику по использованию. Может сложиться так, что возможность была реализована, но попросту оказалась не востребована, а возможно пока не популярна. В любом случае, это повод отметить необходимость разработки и перемещаться к следующему шагу чек-листа.
Если создается новый продукт, а готовых решений с новой идеей десятки, то не стоит изобретать велосипед людям уже есть из чего выбирать. А вот если решений мало, то значит, что можно пробовать. Нужно понять, насколько готовые продукты пользуются спросом и что будет лучше в Вашем. Нет спроса нет необходимости разрабатывать. Есть спрос анализируем: собираем список готовых продуктов и под каждый выписываем список особенностей. После этого добавляется еще одна колонка новая идея со своими запланированными особенностями, возможно дополненная только что найденными фичами. Если новая идея перекрывает основные возможности готовых продуктов и содержит что-то уникальное по сравнению с ними, то, кажется, шансы на существование есть. Все отличительные особенности это наша уникальность. Дальнейшие шаги анализа выполняем, рассматривая только ее.
Шаг конкурентного анализа рынка позволяет снять много вопросов на старте, без лишних затрат ресурсов.
Какую проблему я хочу решить и для кого?
Если идея что-то создать пришла, значит конечный продукт должен стать востребованным. А задавались ли вопросы: кукую проблему решит продукт и проблема ли это вообще? В этом деле лучше быть жестким.
Часто мы пытаемся решить проблемы, которые на самом деле ими не являются, или находим неудобства, которые готовы устранить, но эти неудобства видны только нам и ограниченному кругу лиц. Создавая или улучшая какой-либо продукт, нужно проверить, что решается реальная задача.
Предлагаю базовый список вопросов, достаточный для проверки гипотезы о существовании проблемы:
Это создается для устранения потерь времени или денег?
Если решение никаким образом с этим не связано, то круг ваших пользователей скорее всего будет очень ограниченным. Сразу же хочу остановить негодование: развлекательные IT-проекты (например игры) решают проблему потери времени. Вместо того, чтобы бесполезно его терять, умирая со скуки, люди теряют его, занимаясь делом. Поэтому не обязательно, что решение напрямую касается времени и денег, но важно притянуть его к тому, что эти потери будут устранены.
Есть ли альтернативные способы решения придуманной проблемы?
Если альтернативные способы есть, значит ими пользуются и до сегодняшнего дня всех это устраивало. Нужно понять причину отказа потребителя от текущего алгоритма и перехода на новый. Для этого нужно больше вопросов, ответы на которые помогут понять в будущем способы продвижения:
Если есть альтернативное решение, то чем новое будет лучше?
Почему будут выбирать созданный продукт, а не делать как раньше?
А у кого эта проблема?
Это последний и главный вопрос. Бывает так, что проблема кажется проблемой только для ограниченного круга лиц или только для одного человека себя.
Для проверки гипотезы существования проблемы определитесь с кругом лиц, которому может потребоваться создаваемое решение, выберите целевую аудиторию и звоните, пишите и спрашивайте. Важно! При опросе не пытайтесь продавать, используйте фразы: А интересно ли , А как Вы отнесетесь к, А что, если мы бесплатно предложим Вам поучаствовать в тестировании и другие.
Если Вы найдете отклик среди своих друзей, знакомых или потенциальных клиентов среди любых возможных пользователей, то значит найдена целевая аудитория, и создается что-то действительно нужное. В противном случае, кажется, что решается локальная проблема это нормально, если Вы не планировали большого количества конечных пользователей. А вот если планировали кажется что-то пошло не так и не стоит делать бесполезный продукт.
Время, деньги и рок-н-ролл
Любая идея автоматизации преследует за собой цель завоевание пользователей. Получение пользователей получение прибыли.
Прежде чем запускать разработку, оцените доходность идеи, какой бюджет она может принести в новый или развивающийся проект.
Для новых проектов оцениваем ожидаемое количество пользователей в первые 6 месяцев, а для развивающихся их ожидаемый прирост в целом за этот же период. Строим план с минимальными продажами и с минимальной стоимостью. Оцениваем затраты на разработку: как денежные, так и временные ресурсы (это отдельная большая тема, главное держите в голове комбинацию слов минимальная версия продукта).
Время создания минимальной версии не должно превышать 4-6 месяцев это тот простительный период, когда никто не успеет начать делать то же самое, а вдохновение будет еще сильным. Перед началом разработки обязательно нужно будет пройти этап описания минимальной версии проекта, для понимания масштабов на этом этапе. Это шаг формирования технического задания (только не думайте о ГОСТ нам это не надо).
Время финансовой окупаемости и получения первой прибыли не должно быть больше времени разработки, потому что в плюс нужно будет выходить, чтобы развиваться. Расчет бюджета IT-проекта отдельный вид искусства. Бывают разные виды проектов и разные способы заработка. Например, проекты для себя, где нужно автоматизировать какие-то внутренние процессы организации, чтобы получить выгоду от внедрения решения, а не от продажи его кому-либо. Есть приложения для разовой продажи и внедрения, есть приложения по подписке. Слишком много всего, главное найти способ примерно оценить доход.
Если затраты и окупаемость удовлетворяют, то чек-лист пройден и уверенности должно стать явно больше, а желание ярче!
Я дочитал до этого раздела и все еще уверен в себе
А если Вы все еще не сомневаетесь в своей идее, значит надо делать.
Никогда не затягивайте с реализацией и старайтесь как можно скорее донести горячий пирожок пользователю, чтобы видеть результат и поддерживать свой костер в душе.
Спасибо за внимание!
Категории: