Для того, чтобы создать эффективный ИТ продукт нужно совершить ряд действий и не наделать ошибок. О том и о другом расскажу в данной статье.
Если вы только собираетесь запускать свой бизнес, основанный на ИТ-сервисе, но не слишком разбираетесь в тонкостях разработки - читайте внимательно.
За много лет работы в сфере информационных технологий я совершил каждую ошибку, описанную в этой статье. Сейчас же стараюсь уберечь от них своих клиентов и поделиться опытом с коллегами.
# Стратегия и фичи
Прежде чем начать какое-либо дело, нужно в первую очередь определить, кому и зачем это может быть нужно и полезно. Есть ли на рынке аналогичные предложения, и чем конкретно ваше выгодно выделяется на их фоне.
Директор по продукту и рыночной стратегии должен определить вектор развития и уникальные отличительные черты будущего продукта. Звучит очень высокопарно и корпоративно, но на самом деле здесь есть несколько простых действий. Одним из первых таких шагов назовем анализ рынка. Приведу пример.
Много лет назад я работал в рекрутинговой компании. Моим клиентом были Johnson & Johnson Medical, пожалуй, одно из самых успешных предприятий в мире. Я занимался поиском кандидатов на самые разные позиции, в том числе - менеджеров по продукту. В качестве конкурса на это место компания давала ситуацию, в которой требовалось составить план выхода на рынок какого-либо медицинского продукта. Успешный кейс всегда включал в себя анализ целевой аудитории и отличительных черт конкурентов.
Что же представляет собой этот анализ для предпринимателя, планирующего запускать свой продукт?
Вот ключевые вопросы, на которые у вас должны быть ответы до того, как вы начнете составлять план действий. Можно назвать его пункт номер 0, если хотите:
- Какие продукты есть на рынке
- Какую основную потребность они закрывают
- За счет каких функциональных особенностей люди склоняются к выбору того или иного предложения (см. маркетинг сегментирование)
- За счет какого уникального свойства люди захотят выбрать именно ваш продукт
Итак, делаем первый шаг. Необходимо опросить живых людей с целью выявления истинной заинтересованности в тех или иных предложениях. Ваше субъективное мнение относительно положения дел на рынке не может быть отправной точкой для начала серьезного предприятия.
Директор по продукту и рыночной стратегии - это тот человек, который сможет сформулировать бизнес требования, исходя из конъюнктуры и тренда. Ему, в отличие от вас, не будет мешать желание поскорее запустить продукт, игнорируя реальные статистические данные.
Можно ли пропустить этот шаг? Я бы не рекомендовал. Слишком велик риск выпустить продукт, который никому не будет нужен. Product owner в условиях недостатка времени или бюджета на исследования скорее всего станет тем, кто выпускает мертвые и неинтересные пользователю проекты.
Успешные продукты всегда начинаются с качественного изучения рынка, делай как самые успешные.
# Бизнес-требования, аналитика, архитектура и техническое задание
Прежде чем приступать к разработке, было бы неплохо хорошо все описать. Техническое задание - это прямое воплощение бизнес-требований в интерфейсах будущей системы, кратко - ТЗ.
Без ТЗ резалт ХЗ. Для того, чтобы рассчитать приблизительную стоимость разработки любого ИТ продукта недостаточно просто выписать желаемый функционал в столбик и уточнить стоимость каждого пункта. В таком случае разработчики не видят картину целиком и не могут оценить конечную стоимость продукта, возможные риски, недочеты в вашей логике, сколько времени потребуется на запуск проекта. В итоге в процессе работы цифры будут постоянно меняться в большую сторону.
Для составления грамотного технического задания вам скорее всего потребуется аналитик. Да, это дополнительные затраты на первоначальном этапе, но серьезная экономия бюджета и нервов, когда на выходе готовый продукт приходится допиливать, а то и вовсе переделывать целиком. Такое встречается и, увы, не редко.
Структура технического задания
1. Выбор программных продуктов для реализации проекта.
Представьте, что вы собираетесь построить дом, как вы поймете какие выбрать для этого материалы?
Когда я делал свой самый первый продукт, мне предложили сделать его на C#/ASP.NET, хотя это было MVP и реально больше подходил Python/Django. Получилось бы быстрее и дешевле. Но в тот момент мне никто внятно не мог ответить на вопрос, какой язык нужно выбирать и почему. А сам я тогда не видел между ними никакой разницы. Так как у меня не было понимающего архитектора рядом, этот выбор произошел без моего участия, но последствия остались на мне. Достаточно знаний я получил уже по прошествии времени, набив множество шишек.
Поэтому либо личный опыт запуска продуктов на разных технологиях, либо специалист по подбору программных продуктов.
2. Макеты интерфейсов и прототипирование.
На этом этапе вам понадобится аналитик. Он должен описать интерфейсы, исходя из бизнес требований и необходимых опций. Можно ли эту работу сделать самостоятельно?
Ой, как прекрасно я себя чувствовал, сидя в поверпоинте и изображая разные интерфейсы и описывая их функционал в зоне комментариев под слайдами. Когда в первый раз я отдал такую презентацию толковому аналитику, у него возникло несколько десятков вопросов по каждому слайду. Оказалось, я не учел массу вещей.
Хуже был опыт, когда я не отдал свои заметки аналитику, а сразу передал разработчикам. Те почти ничего не спросили и взяли все в работу.
Вопросы стали возникать в процессе разработки. В итоге, трехнедельный проект растянулся на два с половиной месяца и на деньги, которые я не планировал.
3. Юзкейс сценарии.
Какую цель пользователь должен достигнуть в каждом интерфейсе, куда пройти и откуда прийти. Все сценарии поведения пользователя внутри системы должны быть описаны.
Представьте себе, вы подходите к машине и вам необходимо ее использовать для передвижения, а педаль газа находится в багажнике. Внимание вопрос! Как вы дотянитесь до этой педали, сидя на водительском сиденье? Очевидно, что кто-то описал в задании наличие педали газа, но не описал, какое действие и в каких условиях с ней будет производить пользователь.
Вот эта часть ТЗ отвечает за то, насколько удобно будет вашим пользователям, поэтому изначально этим должен заниматься опытный человек.
В качестве промежуточного итога относительно технического задания и прототипов можно сказать следующее: финансовые затраты на специалистов в этой области станут для вас лучшей страховкой от перерасхода средств, невнятного результатата и сорванных сроков.
4. Дизайн. Что такое хороший дизайн, кому он нужен и сколько он должен стоить?
На этот раз вопрос короткий и больше связан с логикой и здравым смыслом. Деньги стоит вкладывать в дизайн только в том случае, если он является частью продуктовой стратегии. В то время, когда для одного проекта будет достаточно работы среднего дизайнера на фрилансе, для другого понадобится полноценное участие серьезной студии.
Некоторые люди совершают ошибку и выбирают дизайн исходя из критерия “нравится - не нравится”, на мой взгляд такое поведение выходит за рамки объективной реальности.
Схема та же - анализируем, изучаем спрос, запускаем в разработку.
5. Минимально жизнеспособный продукт (minimum viable product - MVP).
Итак, продуктовую стратегию осилили, исследование провели и смогли ответить себе на вопрос – почему это будут покупать и за счет каких особенностей люди сделают выбор в пользу данного продукта?
Следующим шагом определяем минимальный набор функций, с которым потенциальные клиенты будут готовы купить ваш продукт.
Я несколько раз наблюдал, как люди определяли MVP на глаз, что является такой же распространенной ошибкой, как в случае с дизайном.
Кем бы ни был потребитель вашего продукта - сотрудник вашей же компании, клиент из другой организации или просто физическое лицо, нельзя пренебрегать потребностями других людей при запуске продукта, которым они будут пользоваться.
Если вы ловите себя на том, что на глаз пытаетесь прикинуть, чем привлекательно ваше предложение для клиента, значит вы торгуете апельсинами. Хотя с апельсинами то же самое: если люди ждут от вас оранжевых спелых апельсинов, а вы даете им зеленые, их просто не будут покупать.
MVP - это один из подходов, который помогает сосредоточиться на небольшой выборке потенциальных потребителей и осчастливить их своим продуктом, а потом реинвестировать полученные средства в развитие этого проекта на более широкую аудиторию.
На мой взгляд, это первый серьезный тест для любого продукта, который покажет, какие перспективы вас ожидают.
# Выбор разработчика
Выбор разработчика - это всегда сложный и чувствительный вопрос. В процессе взаимодействия будут замешаны ваши амбиции и деньги, поэтому стоит уделить поиску особое внимание. Существует несколько сценариев развития событий. Ниже мы рассмотрим их все и выявим плюсы и минусы каждого подхода.
1. Хочу подешевле.
В этом случае люди часто ищут фрилансера - Full-stack (фулл-стэк) разработчика, который сделает им работу под ключ. Это первая распространенная ошибка. “На все руки мастер” скорее всего упустит из вида множество составляющих цикла производства продукта, например исследования, продуктовую стратегию, аналитику, управление проектом или контроль качества.
Если понимаете, что денег мало, лучше не ввязываться в историю с разработкой, а искать дополнительный источник финансирования.
Даже если кажется, что есть видение продукта, и вы сами можете нарисовать ТЗ, а потом проверить работу на выходе, не стоит.
Факты запуска успешных продуктов говорят об одном, вам так или иначе нужна команда. Цена фрилансеров всегда привлекательна, но она напрямую отражает и качество работы, за которую никто потом никакой ответственности нести не будет.
2. Есть миллион.
У меня есть миллион, сделайте мне вот такой продукт. Что мы можем туда добавить или убрать?
В самом начале моей профессиональной деятельности в этой индустрии я несколько раз совершал такую ошибку. Приходил к разработчикам и называл бюджет. Они говорили “круто”, я разбивал оплату на части, и начиналась работа.
Я тогда не знал, что мне нужна целая команда, а не просто пара ребят, которые знают .NET или php. В итоге работа получалась плохо и из-под палки.
Все компании, которые готовы были разрабатывать ИТ продукт за фиксированную стоимость, сейчас закрылись.
3. Обращаться к CMSникам.
Все зависит от задач, под которые необходимо создавать продукт. Если бизнес предполагает выполнение шаблонных задач и не требует разработки специальных функций, то вполне можно обойтись вариантом с CMS: для текстового сайта прекрасно подойдет бесплатный WordPress, для информационных сайтов можно использовать также бесплатный Joomla!, а интернет магазины прекрасно работают на 1C-Битрикс. Такие сайты быстро создаются и ими легко управлять.
В случае же когда требуется разработать проект с обширным функционалом и оригинальной идеей, стоит обращаться к специалистам, которые, следуя вашим бизнес требованиям и техническому заданию, произведут эксклюзивный продукт под конкретные требования и задачи.
4. Обращаться в дизайн агентства.
Здесь ситуация очень похожа на историю с 1С-Битрикс. Дизайн студия разрабатывает визуальную составляющую продукта. Выше я уже писал писал, что если основным двигателем продаж является дизайн, вам надо идти в топовую студию и заказывать у них красивую продающую картинку.
Дела обстоят таким образом, что с одной стороны, разработчики программного обеспечения не могут создавать яркий качественный визуал. С другой стороны, студии дизайна не обладают достаточной компетенцией, чтобы выпускать полноценный продукт.
Если не хотите выбирать между функциональной составляющей и внешним видом, то однозначно есть смысл разделять задачи между компетентными специалистами.
5. Растить экспертизу самому.
Круто, но дорого. Больше подходит для крупной компании с большим количеством ИТ проектов.
Ниже я привожу таблицу, в которой рассчитал зарплату всех специалистов, которых требуется привлечь к разработке продукта.
Зарплата указана средняя по Москве, где-то конечно вы можете сэкономить. Но главная мысль заключается в том, что самые дорогие кадры нужны ненадолго, и содержать их на постоянной основе смысла нет.
Однако здесь кроется проблема: необходимые высокооплачиваемые специалисты уже где-то сидят и чем-то занимаются, и нанять их на проектную занятость тяжело. Поэтому дешевле и проще выходит, когда вы нанимаете кого-то сделать вам продукт целиком.
В таблице стоимость, которую я недавно рассчитывал для разработки внутренней ERP системы для одного из наших клиентов. Общий смысл в том, что людей нужно на 20 миллионов, а их содержание обходится в 50 миллионов. Поэтому собственная экспертиза актуальна большому бизнесу с множеством проектов, которому чаще всего нужны просто дополнительные руки в разработке.
6. Продуктовая студия.
Этот вариант можно сравнить с походом в ресторан и попыткой соорудить мишленовское блюдо на собственной кухне.
Хорошая продуктовая студия будет смотреть на вас как на партнера в долгосрочной перспективе и будет учитывать ваши финансовые и другие возможности для осуществления продаж.
На мой взгляд любой бизнес «в своем уме» будет хотеть, чтобы его клиенты процветали, особенно если он предоставляет value added решения для своих клиентов.
Тем не менее такой подход – большая редкость. Скорее вас будут хотеть подписать на наибольшее количество часов, долго и упорно обсуждать техническое задание и прочие нюансы и договоренности.
Поэтому компания, нацеленная на рост вашего бизнеса, в первую очередь будет стремиться понять бизнес-требования и точки получения прибыли более глубоко. Возвращаясь к началу статьи, вспомним, что продукт начинается с исследования рынка и стратегии, поэтому выбранная продуктовая студия, должна иметь необходимую экспертизу, если вы хотите увеличить шансы на успех вашего бизнеса.
Если суммировать все, о чем я написал выше, то получается вот такая занимательная таблица рисков.
Как мы видим, важные риски для бизнеса лежат почти на каждом члене команды.
# Тестирование. Quality Assurance.
Тестирование - это одна из частей процесса разработки, и ее нельзя игнорировать. На выходе должен получиться готовый продукт. Если этот продукт будет работать некорректно или не будет работать вовсе, пользователь получит негативный опыт при использовании вашей системы. Это критичный фактор для любого вида бизнеса и ИТ-систем.
Распространенная ошибка у бизнеса при отсутствии экспертизы в разработке заключается в предположении, что достаточно проводить ручное тестирование продукта, и недостаточном понимании того, что такое регресс. Ошибочное мнение о том, что при разработке достаточно ручного тестирования продукта, обусловлено дефицитом профессионального опыта и желанием сэкономить время и деньги в самом конце пути.
Если коротко, то каждая функция в вашей системе должна тестироваться заново перед выдачей пользователям. Ваша система состоит из пары красных кнопок? Ок, тестируйте руками.
А что делать, когда в вашей системе 1000 и 1 функция, или у вас одновременно в работе десяток разных проектов? Вам нужен человек, который разбирается в теме и понимает, как правильно настроить этот процесс. Помимо всего прочего он должен понимать цели и задачи вашего бизнеса, и пользовательские сценарии из ТЗ, о которых было сказано выше.
Вот простой пример: вы ставите задачу – «пользователь должен иметь возможность сформировать отчет». Хороший тестировщик также заглянет в бизнес требования и сделает выводы – понятен ли отчет и насколько быстро он формируется.
Тестирование дает вам уверенность в том, что разработка завершена, итог положительный, продукт готов к использованию.
Техническая документация. Ну вот у вас есть ТЗ, вы формируете спринты, ставите задачи, получаете фичи. Что еще нужно? Необходимо постоянно собирать промежуточные результаты в один документ, который будет содержать всю актуальную информацию о вашей системе в каждый момент времени.
В большей степени это гигиенический фактор. Как только человек включается в работу над проектом, вы начинаете тратить деньги. Таким образом, чем быстрее новый член команды сможет вникнуть в текущую ситуацию, тем большую экономию вы получите.
Еще один небольшой reality-check. См. картинку ниже. Я ничего не упускаю в этом цикле разработки продукта? Раньше мне казалось, что прямоугольников должно быть намного меньше. По этой причине я совершал ряд ошибок, тратил кучу своих нервов и лишних денег на разработку, не учитывая множество различных лучших практик при запуске продуктов.
Как и многие люди, я думал что нужно лишь написать ТЗ, отдать его разработчику и потом проверить на выходе. Вот так просто – каждый может – 3 прямоугольника вместо 12.
Это и есть разница между вашим успешным бизнесом и эпическим провалом. Главное помнить, что игнорирование опыта большинства, иногда приводит к прорывам, но чаще всего приводит к обидным провалам.
Выводы
Все шаги, описанные в данной статье проверены временем и опытом многих начинающих предпринимателей и разработчиков. Соблюдая простые правила конструирования продукта, вы обезопасите себя не только от финансовых потерь, но и сможете обеспечить своим проектам своевременный запуск и полноценную жизнь.
Время - главный и ценнейший ресурс, которым располагает человек на сегодняшний день. Мир меняется с бешеной скоростью и то, что было актуально всего несколько месяцев назад, может стать совершенно ненужным уже завтра. В условиях современного рынка нельзя терять время на изобретение велосипеда.
