Но не каждый предприниматель имеет навыки разработчика и не каждый способен понять, каких специалистов лучше выбрать, как проконтролировать команду IT-специалистов, которые будут трудиться над этим продуктом. В идеале привлечь к процессу продукт-менеджера: он проследит за процессом от начальной точки до конечной и убережет от фатальных ошибок. Если нет такой возможности, нужно разбираться в процессе самостоятельно. Как сделать качественный IT-продукт, не имея навыков разработчика, какие знания для этого нужно иметь и как не совершить критических ошибок, рассказывает Фарид Газизов, продукт-менеджер, который работал с такими компаниями, как Ulmart, «РивГош», «Дефиле», «Дикая Орхидея», а также основатель компании Double Your Rental Profit и Real Time Group.
Получить базовые технические и аналитические навыки
Для разработки IT-продукта важно иметь технический бэкграунд, чтобы уменьшить количество совершенных ошибок, которые могут оказаться критичными. В числе базовых навыков – принципы программирования, знание основных языков программирования. Это помогает в дальнейшем более эффективно контролировать разработчиков в команде и понимать, что с продуктом не так, где искать ошибку. Кроме того, нужны хорошие аналитические навыки. Потому что с анализа начинается создание продукта и с ним продолжается.
Когда я начал заниматься разработкой продуктов, у меня не было ни технических, ни аналитических знаний, ни навыков дизайна. Я учился на ошибках, через них понимал, где правильно, а где не так – это очень большая потеря времени, денег, человеческих ресурсов. Первые продукты вспоминаю с дрожью, например первую версию купонного сайта, где наделал массу ошибок. Причем мы тогда ничего не анализировали, не понимали, как что работает. Мы собрались, наняли компанию, которая сделала ТЗ, долго мучительно писали, а потом выкатили результат. Через три месяца мы после релиза увидели, насколько все плохо, перечеркнули и сделали иначе. Но мы потеряли время и деньги. Поэтому совсем без базовых знаний начинать разрабатывать продукт не стоит.
Провести детальную аналитику
Разработка IT-продукта – это очень многогранная задача, крайне сложная и рискованная. Нет гарантии, что он выстрелит, даже если исполнением занимается опытный специалист: может оказаться, что команда просто потеряла время, силы и деньги. А отсутствие опыта разработки удваивает или даже утраивает риски. Поэтому, когда предпринимателю пришла в голову интересная идея, связанная с веб-сайтом, мобильным приложением или другим IT-продуктом и выглядящая перспективной, он должен задать себе несколько вопросов.
Во-первых, кто будет разрабатывать, как нанимать этих людей, как мотивировать и как удерживать в команде. Последние два момента очень важны, потому что постоянная смена разработчиков не идет на пользу продукту. По итогу с высокой вероятностью получится нечто, требующее все делать заново. Во-вторых, нужно определить, как контролировать процесс разработки, как убедиться в том, что продукт выходит качественный, и как не потерять контроль над ним. Я часто вижу, когда человек без опыта IT-разработки приходит ко мне и говорит: «У меня гениальная идея, хочу разработать такое мобильное приложение». В течение получаса или часа я ему озвучиваю перечисленные вопросы, которые он даже не думал себе задавать, и он уже начинает сомневаться, стоит ли вообще начинать.
Но, кроме аналитики технической части проекта, нужно провести исследование рынка и аудитории. Выяснить, есть ли уже аналоги, кто конкуренты и сколько их, определить целевого потребителя, соответствие задуманного его желаниям, болям и потребностям. Обязательно оценить продуктовые метрики: объемы продаж, рентабельность.
Уделить внимание методам разработки
Я часто сталкивался с ситуацией, когда предприниматели или организации, которые никогда не занимались разработкой, наняли специалиста (программиста или разработчика) для создания продукта, что-то сделали, оно функционирует, но по каким-то причинам меняется команда, занимающаяся проектом. Приходит новая и ничего не может сделать с продуктом, потому что прежние разработчики писали код и не комментировали в определенном стиле и не делали качественное описание кода. А сам предприниматель процессу внимания не уделял, с командой не взаимодействовал и теперь ничего не может подсказать. В результате продукт нужно переписывать с нуля, потому что никакие изменения в него внести невозможно.
У меня такая история была в «Дикой Орхидее», где пришлось работать с чужим продуктом, о «изнанке» которого никто ничего не знал и не мог подробно рассказать. Мы начали разбираться, откуда возникают проблемы и почему теряются клиенты, как это исправить, и выяснили, что внести изменения в продукт не получится – только писать заново, так как продукт был создан с помощью конструктора, который уже устарел. Подобные ситуации очень опасны для бизнеса. И, чтобы их избежать, нужно уделять внимание методам разработки на всех этапах, получить доступ к коду и контролировать его изменения.
Проверить все данные и подходы
Все изменения IT-продукта можно проводить только на основании данных. Нельзя улучшать метрики «в вакууме», но при этом еще хуже вносить изменения, отталкиваясь от ошибочных цифр. Поэтому всегда необходимо проводить тщательную проверку данных, которые поставляют аналитики, разработчики, маркетологи. Какими бы хорошими специалистами они ни были, цифры всегда нуждаются в перепроверке. Я всегда скрупулезно задаю вопросы, как именно были получены эти метрики, как проверялась их точность.
Выводы, сделанные на неточных данных, могут оказаться смертельными для продукта и критичными для компании. Зачастую это даже хуже, чем движение совсем без каких-либо данных. Когда я начал работать в «Дикой Орхидее», первым делом начал проверять метрики и выяснил, что сайт был неправильно размечен ивентами и аналитика собиралась неверно. Свыше 30% заказов не попадали в Google Analytics и не обрабатывались соответственно. Пришлось сначала исправить эту разметку, дождаться получения новой информации и только после этого строить гипотезы и работать с продуктом.
Взаимодействовать со всеми отделами
Ни один продукт не находится в вакууме: это то же самое, что автомобиль, который едет по дороге без разметки и дорожных знаков. После того как приложение или сайт будут созданы, с ним начнет взаимодействовать, например, отдел маркетинга, который должен его продвигать и привлекать к нему трафик. В процессе может выясниться, что есть какие-то проблемы, мешающие увеличению трафика или делающие его привлечение слишком дорогим. Это влечет за собой крушение юнит-экономики и бизнес-модели, потерю прибыли компании и требует доделывать или переделывать продукт.
Или, например, в продукт закладывается какая-то интересная опция, которая кажется крутой, но в результате выясняется, что она затягивает процесс разработки, съедает ресурсы, а на выходе совершенно не окупается. Этого можно избежать, если сразу все обсудить с разработчиками. Поэтому при создании любого продукта нужно взаимодействовать со всеми отделами в компании. С аналитиками обсуждать текущие показатели продукта, ставить под сомнение результаты сбора данных, проверять их в связке с разработчиками, с маркетингом – анализировать стратегию закупки трафика, с поддержкой – проблемы, с которыми сталкиваются пользователи, и способы их решения. Чем теснее это взаимодействие будет, тем лучше получится итог.
Чек-лист: советы по разработке IT-продукта:
- Получить базовые знания в программировании, аналитике и желательно дизайне, иначе у продукта высокие риски провалиться.
- Проанализировать рынок и аудиторию, востребованность и рентабельность идеи, затраты, конкурентов.
- Вникать в процесс разработки, используемые программистами методы и стараться не допускать частой смены команд, которые трудятся над продуктом.
- Проверять все данные и подходы к их получению, чтобы иметь на руках достоверные цифры.
- Взаимодействовать со всеми отделами компании в ходе разработки, иначе после релиза возникнут проблемы при запуске, продвижении, пострадают юнит-экономика и бизнес-модель.
Подписывайтесь на Telegram-канал Atameken Business и первыми получайте актуальную информацию!
Мнение редакции может не совпадать с мнением автора
