Как запустить годный ИТ-продукт и не прогореть

Ошибка №1. Отсутствие продуманной стратегии

Без изучения рынка и потребностей живых людей слишком велик риск выпустить продукт, который никому не будет нужен. Приведу пример. Много лет назад я работал в рекрутинговой компании. Моим клиентом были Johnson & Johnson Medical.

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

Вот ключевые вопросы, на которые у вас должны быть ответы до того, как вы начнете составлять план действий: 

• Какие продукты есть на рынке? 
• Какую основную потребность они закрывают?
• За счет каких функциональных особенностей люди склоняются к выбору того или иного предложения? 
• За счет какого уникального свойства люди захотят выбрать именно ваш продукт?

Ваше субъективное мнение относительно положения дел на рынке не может быть отправной точкой для начала серьезного предприятия. Стоит воспользоваться услугами директора по продукту и рыночной стратегии.

Product-owner в условиях недостатка времени или бюджета на исследования, скорее всего, станет тем, кто выпускает мертвые и неинтересные пользователю проекты. Успешные продукты всегда начинаются с качественного изучения рынка.

 

Ошибка №2. Отсутствие внятного технического задания и ошибки в его составлении

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

Все сервисы и компании, связанные с релокацией, на одной карте

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

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

Структура технического задания:   

• 1. Выбор программных продуктов для реализации проекта. Представьте, что вы собираетесь построить дом, как вы поймете какие выбрать для этого материалы? Когда я делал свой самый первый продукт, мне предложили сделать его на C#/ASP.NET, хотя это было MVP и реально больше подходил Python/Django. Получилось бы быстрее и дешевле.

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

• 2. Макеты интерфейсов и прототипирование. На этом этапе вам снова понадобится аналитик. Он должен описать интерфейсы, исходя из бизнес-требований и необходимых опций. Можно ли эту работу сделать самостоятельно? Ох, как я гордился собой, сидя в PowerPoint и изображая разные интерфейсы, описывая их функционал в зоне комментариев под слайдами.

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

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

• 3. Юзкейс-сценарии. Все сценарии поведения пользователя внутри системы должны быть описаны. Представьте себе, вы подходите к машине и вам необходимо ее использовать для передвижения, а педаль газа находится в багажнике. Как вы дотянитесь до этой педали, сидя на водительском сиденье?

Очевидно, что кто-то описал в задании наличие педали газа, но не описал, какое действие и в каких условиях с ней будут производить. Эта часть ТЗ отвечает за то, насколько удобно будет вашим пользователям, поэтому изначально ей должен заниматься опытный человек. 

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

 Некоторые люди совершают ошибку и выбирают дизайн, исходя из критерия нравится/не нравится. На мой взгляд, такое поведение выходит за рамки объективной реальности. Схема та же – анализируем, изучаем спрос, запускаем в разработку. 

• 5. Минимально жизнеспособный продукт (minimum viable product – MVP). Определяем минимальный набор функций, с которым потенциальные клиенты будут готовы купить ваш продукт. Я несколько раз наблюдал, как люди определяли MVP на глаз. Это такая же распространенная ошибка, как и в случае с дизайном.

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

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

 

Ошибка №3. Неправильный подход при выборе разработчика 

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

Ниже мы рассмотрим их все и выявим плюсы и минусы каждого подхода. 

• 1. «Хочу подешевле». В этом случае люди часто ищут фрилансера – full-stack (фулл-стэк) разработчика, который сделает им работу под ключ. Это первая распространенная ошибка. «На все руки мастер», скорее всего, упустит из вида множество составляющих цикла производства продукта, например, исследования, продуктовую стратегию, аналитику, управление проектом или контроль качества.

Если понимаете, что денег мало, лучше не ввязываться в историю с разработкой, а искать дополнительный источник финансирования. Даже если кажется, что есть видение продукта, и вы сами можете «нарисовать ТЗ», а потом проверить работу на выходе, не стоит.

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

• 2. «Есть миллион». «У меня есть миллион, сделайте мне вот такой продукт. Что мы можем туда добавить или убрать?» В самом начале моей профессиональной деятельности в этой индустрии я несколько раз совершал такую ошибку. Приходил к разработчикам и называл бюджет.

Они говорили: «Круто!», я разбивал оплату на части, и начиналась работа. Тогда я не знал, что мне нужна целая команда, а не просто пара ребят, которые знают .NET или php. В итоге процесс шел плохо и из-под палки. Все компании, которые готовы были разрабатывать ИТ-продукт за фиксированную стоимость, сейчас закрылись.

• 3. Обращаться к CMSникам. Все зависит от задач, под которые необходимо создавать продукт.

Если бизнес предполагает выполнение шаблонных задач и не требует разработки специальных функций, то вполне можно обойтись вариантом с CMS: для текстового сайта прекрасно подойдет бесплатный WordPress, для информационных сайтов можно использовать также бесплатный Joomla!, а интернет-магазины прекрасно работают на 1C-Битрикс.

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

• 4. Обращаться в дизайн-агентства. Здесь ситуация очень похожа на историю с 1С-Битрикс. Дизайн-студия разрабатывает визуальную составляющую продукта.

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

• 5. Растить экспертизу самому. Круто, но дорого. Больше подходит для крупной компании с большим количеством ИТ-проектов, которой чаще всего нужны просто дополнительные руки в разработке. Самые дорогие кадры нужны ненадолго, и содержать их на постоянной основе смысла нет.

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

• 6. Продуктовая студия. Хорошая продуктовая студия будет смотреть на вас как на партнера в долгосрочной перспективе и будет учитывать ваши финансовые и другие возможности для осуществления продаж.

На мой взгляд, любой бизнес «в своем уме» будет хотеть, чтобы его клиенты процветали, особенно если он предоставляет value-added решения для своих клиентов. Тем не менее, такой подход – большая редкость.

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

 

Ошибка №4. Пропуск этапа тестирования или только ручное тестирование для сложной системы

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

Распространенная ошибка у бизнеса при отсутствии экспертизы в разработке – вера в то, что достаточно проводить ручное тестирование продукта. Ошибочное мнение обусловлено дефицитом профессионального опыта и желанием сэкономить время и деньги в самом конце пути.

Ваша система состоит из пары красных кнопок? Ок, тестируйте руками. А что делать, когда в вашей системе 1000 и 1 функция, или у вас одновременно в работе десяток разных проектов? Вам нужен человек, который разбирается в теме и понимает, как правильно настроить этот процесс. Помимо всего прочего он должен понимать цели и задачи вашего бизнеса, и пользовательские сценарии из ТЗ.

Вот простой пример: вы ставите задачу «пользователь должен иметь возможность сформировать отчет». Хороший тестировщик также заглянет в бизнес-требования и сделает выводы, понятен ли отчет, насколько быстро он формируется. 

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

 

Выводы

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

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

Фото на обложке: pixabay.com