Перевод статьи Лукаша Лавицкого «Converting an idea into a fully usable application».
Сколько времени нужно, чтобы идея воплотилась в продукте? Что нужно сделать, чтобы вывести свое приложение на рынок?
В этом посте я попытаюсь описать конвертацию идеи в продукт. Я буду говорить о мобильном приложении, но полагаю, все изложенное ниже применимо и к другим IT-продуктам.
Исследуйте рынок
Должен сказать, я считаю довольно сложным выдумать то, что еще никто не изобрел. Даже если я думаю, будто моя идея уникальна, оказывается, что на рынке есть много подобных продуктов.
Это не плохо. Испытайте эти продукты. Потратьте время и поиграйтесь с ними. Полностью ли они совпадают с вашей идеей? Хотели бы вы ими пользоваться? Если нет – что бы вы в них изменили?
Посмотрите, какое влияние оказали эти продукты на рынок. Популярны ли они? Много ли людей ими пользуется? Будут эти люди пользоваться вашим приложением?
Один мой друг, просмотрев эту статью, сказал:
«Будет хорошей идеей найти группу людей, потенциально заинтересованных в использовании вашего продукта, или занимающихся тем же бизнесом, каким хотите заняться вы. Разошлите им электронные письма. Спросите у них о проблеме, которую вы пытаетесь решить с помощью своего продукта. Не подсказывайте им ответы, ничего не предполагайте. Возможно, они подскажут вам, что делать».
Задавайте себе побольше вопросов. Делайте заметки. Запишите все «за» и «против» и решите, хотите ли вы продолжать. Вам может быть сложно отказаться от своей идеи, но поверьте мне: гораздо лучше сдаться сейчас, чем потратить кучу денег и сдаться позже.
Подумайте о монетизации и стоимости своего приложения
Да, я знаю, вам просто пришла идея в голову и вы захотели создать какое-то простое приложение. Но я вас уверяю, в конечном итоге все будет не так просто.
Сейчас это лишь идея, но мы хотим развить ее в полностью готовый к применению продукт. Никто не хочет создавать продукт, на котором будет терять деньги. Даже самые богатые люди так не делают. Вы должны подумать, хотите ли вы зарабатывать на своем продукте. Если да, то как это должно быть реализовано?
Есть много вариантов. Вы можете включить рекламу, вы можете предоставить премиум-доступ, вы можете сделать приложение платным. Только вы знаете, что делать.
Процесс разработки определенно будет стоить денег. Вероятно, вам будут выставлять счет ежемесячно на протяжении целого года. Подумайте об этом. Даже если вы не собираетесь заниматься поддержкой своего приложения после релиза (очень зря!), все равно остаются затраты на оплату серверов. Можете ли вы позволить себе платить за них просто так, не ожидая от этого никакой отдачи? Хотите ли вы это делать? Помните, что пока ваше приложение еще только идея.
Найдите «своих» людей
Это довольно сложный пункт. Вы уже определились с идеей, вы знаете, чего хотите и имеете такой-сякой бизнес-план. Время начинать действовать. Время найти команду, которой вы сможете доверять. И здесь начинаются сложности.
Все тот же друг, просмотревший эту статью, сказал, что будет хорошей мыслью найти компаньона. Очень хорошо, если его способности будут отличаться от ваших. Если вы технарь, найдите кого-то с развитыми soft skills. Если вы разбираетесь в маркетинге, найдите технаря. Вам будет тяжело справиться со всем в одиночку. Найдите кого-то, кто вам поможет!
Теперь давайте найдем команду разработчиков, которая построит для вас этот продукт. Как это сделать? Я думаю, просто общаться и задавать вопросы.
Почему я говорю, что это сложно? Потому что здесь возникает конфликт интересов. Вы хотите получить свой продукт. А ваша компания, где работает ваша команда, хочет заработать деньги. В сфере IT время = деньги.
Вам нужно найти действительно профессиональную компанию. Компанию, которая понимает, что на первом месте для них должен быть клиент. Возможно, вам придется очень много говорить. Говорить с собственниками компании (или ответственными людьми), а также с менеджером, который будет заниматься вашим проектом.
Я знаю, что порой приходится выбирать компанию, которая просто предложила лучшие условия. Но если у вас есть возможность, сделайте выбор в пользу той компании, где вам самому хотелось бы работать.
Представьте продукт вашей команде
Нет ничего хуже команды разработчиков, не понимающих продукт. Вы должны объяснить, почему вы хотите создать это приложение, почему люди захотят им пользоваться, каковы ваши цели. Чем больше вы расскажете, тем лучше будет продукт. Ваша команда должна иметь полное понимание сути проблемы. Поделитесь своими идеями насчет того, что и как должно быть сделано.
Давайте вашей команде возможность вносить предложения
Построить приложение непросто. Скажем, вы задумали создать мобильное приложение. Знаете ли вы, сколько различных фреймворков/технологий может быть использовано в этом процессе? Я навскидку могу назвать 8 самых популярных. И у каждого — свои достоинства и недостатки.
Выбор зависит от вас. А компания должна помочь вам сориентироваться, рассказав о плюсах и минусах каждого решения. Будьте осторожны. У каждой компании ограниченный стек технологий – вам могут попытаться продать то, что не будет лучшим выбором для вас.
Но выбор технологий это не единственное, о чем следует задуматься. Спросите, как они организовывают свою работу. Waterfall? Kanban? Scrum? Узнайте о преимуществах и недостатках названного подхода.
Читайте и говорите. Говорите и читайте.
Мозговой штурм
Был в моей практике один проект. У клиента появилась идея и он пришел к нам, чтобы мы создали для него приложение. Он поделился с нами своими мыслями. Мы подумали, что идея дельная, однако клиент не знал, как конкретно воплотить ее.
Мы предложили провести круглый стол. Потратили на это целый день. Под «мы» я подразумеваю проджект-менеджера, UI/UX дизайнера, бэкенд-разрабочтика и мобильного разработчика. У нас була куча бумаги, стикеров, маркеров и скотча. Вся стена была в листах бумаги, весь пол в аппликациях. У нас появлялись вопросы, у клиента появлялись вопросы. Мы нашли edge cases. Определились с несколькими вещами. И в результате одного этого митинга мы поняли, что нужно делать. Каждый из нас понял суть.
Как я уже писал, очень важно, чтобы разработчики знали продукт. В противном случае им придется предполагать, как продукт должен работать, а это может привести к проблемам и даже к провалу проекта.
Мозговой штурм также может быть полезен позже, для создания заданий и пользовательских историй. Ведь только вы знаете точно, чего хотите, а также как должен работать ваш продукт.
Проведение подобных мозговых штурмов это стоящее дело. Даже если сейчас вы не видите потенциальной выгоды, позже вы ее заметите. Написание кода будет протекать значительно легче, а управление проектом будет более гладким.
Разработка
Этот этап может стать самым длинным. Для начала, пообщайтесь с дизайнером. К этому моменту он должен знать, как приложение должно работать и что в нем должно быть. Но он может и не знать, какие цвета вы предпочитаете.
Возможно, у вас есть какие-то идеи насчет того, как приложение должно «ощущаться»? Должно оно быть темным, разноцветным, веселым, дружелюбным? Расскажите об этом дизайнеру.
Хотелось бы добавить, что дизайнеру, прежде чем отправлять предложения клиенту, стоит отослать их разработчикам. Ведь что-то может быть сложным в реализации или вообще ненужным.
Тем временем разработчики могут заняться настройками проекта. Есть работы, которые должны быть выполнены еще до реализации функционала приложения. Нужно создать репозиторий, сконфигурировать серверы, настроить CI/CD, создать скелет проекта. Естественно, это требует времени. Получив дизайн, разработчики могут начать работать над функционалом.
Частота показа результатов зависит от ваших договоренностей. Если вам ничего не показывают, значит, что-то могло пойти не так.
Если вы думаете, что можно просто посмотреть на результат в конце, я вам сразу скажу: лучше не надо так делать.
Допустим, вы работаете по скраму. У вас двухнедельные спринты. Это значит, что результат работы вы будете видеть каждые 2 недели. Получив новую версию, вы можете протестировать ее лично. Найдя баг, вы можете сообщить об этом разработчикам, чтобы они могли его исправить. Если вам не понравится работа приложения, вы можете сказать об этом. Если вы хотите изменить требования, то и это вы можете сделать.
А вот когда вы получаете готовую версию после всего процесса разработки, ситуация иная. Вы заметите какие-то проблемы, вы выскажете свое мнение о приложении в комментариях. Но сможете ли вы изменить требования к приложению? Конечно, да. Но за это придется платить. Помните, что время = деньги. Чем быстрее вы выскажете свои замечания, тем лучше для вас.
Тестирование
Допустим, у вас уже есть версия, которую вы хотите представить публике. Вы уверены, что хотите это сделать? Вы ее протестировали должным образом?
Конечно, компания, занимавшаяся разработкой, тестировала приложение, но это ваша идея воплощена в нем. Вы знаете, как оно должно работать и вести себя. Протестируйте свое приложение. Потратьте время и позаботьтесь о своем детище. Убедитесь, что все работает, как положено. Если уверены, что все в порядке, пора назначить релиз.
Выпуск MVP, сбор отзывов и добавление функционала
Это важный этап. Честно говоря, я о нем забыл, но товарищ мне напомнил и сказал, что это критически важный момент.
В общем, идея такова: не создавайте сразу всю систему целиком. Реализуйте только необходимый функционал – создайте минимально жизнеспособный продукт (MVP) и выпустите его в свет как можно раньше. Почему? Потому что так вы увидите, нужен ли он на самом деле людям. Если нет, то стоит прекратить и не тратить деньги на дальнейшую разработку.
И, да, собирайте отзывы. Предоставьте пользователям контактную форму или дайте адрес электронной почты, чтобы они могли написать вам, что им понравилось, что они хотели бы видеть и что не работает. Это очень важно. Как иначе вы узнаете, чего хотели бы пользователи вашего приложения?
Если вы увидите, что большинство ваших пользователей хотели бы иметь возможность залогиниться с помощью Google-аккаунта, есть смысл подумать об этом. Если вы сочтете это полезным, обозначьте приоритет этого функционала и попросите команду реализовать его.
Маркетинг
Теперь, когда вы определились с датой релиза, подумайте о продвижении на рынке. Как вы планируете рекламировать свой продукт? Вам нужно привлечь людей, чтобы они начали его использовать. Самое время этим заняться.
Поддержка
Кажется, что после выпуска приложения делать больше ничего не нужно. Это не так. Кто-то должен за ним присматривать. Вы же не оставите своего ребенка на произвол судьбы?
Есть несколько вещей, которые могут остановить работу: может упасть сервер, ваше приложение могут забанить, вы можете найти баг.
При каждом сценарии ваши пользователи огорчатся. Ведь они теперь не могут пользоваться приложением. Конечно, после получения пачки сообщений от них, вы свяжетесь с командой и спросите: «Какого черта мое приложение не работает?» И они ответят: «Вы за ним не приглядывали, а нас не просили это делать».
Если говорить о поддержке, есть три варианта:
- подписать контракт на поддержку
- следить за приложением самостоятельно
- не заботиться о своих пользователях.
Конечно, третий вариант вам не подходит. Я советую подписать контракт на поддержку. Поговорите с командой, узнайте, сколько времени, по их мнению, будет занимать исправление багов (в месяц). Если исправлений не будет, можно попросить реализовать новый функционал.
Если вы решите приглядывать за своим приложением самостоятельно, то в случае возникновения проблем скорее всего все равно обратитесь к разработчикам. Впрочем, если у вас достаточно технических навыков, можно обойтись и своими силами.
Не могу сказать, какой вариант лучше: все упирается в деньги. Прикиньте, что лучше будет подходить для вашего бизнеса.
И еще одно. Поддержка это не только исправления багов. Это также оптимизация производительности, обновление сторонних библиотек, чистка кода, написанного в спешке.
Действуйте!
Думаю, я описал полный процесс разработки. Конечно, это лишь краткое описание того пути, который пройдет ваша идея, прежде чем станет готовым продуктом. Жизнь есть жизнь, и чтение любого количества статей не предотвратит ее сюрпризы. Поэтому кончайте сомневаться и беритесь за реализацию ваших идей!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
