Цивилизация
— Как действовать владельцу, если он хочет оцифровать свой бизнес или запустить ИТ-продукт на рынок? Где искать исполнителей?
— Чтобы подобрать исполнителей для ИТ-разработки, на сегодняшний день вариантов много: собрать внутреннюю команду, отдать задачу на аутсорс, арендовать специалистов (аутстафф), обратиться к фрилансерам, интегрировать готовые решения, поглотить другие компании или слиться с ними… В условиях сжатых сроков и неизвестности или отсутствия у себя необходимой ИТ-экспертизы выигрышный во всех отношениях вариант — это аутсорс, если вы знаете, как выбрать подрядчика.
Отдавая задачи по цифровизации на аутсорс, подумайте, кого вы хотите видеть рядом на этом нелегком пути: просто проектных исполнителей или технологического партнера.
При стандартном проектном подходе вас попросят прийти с готовым ТЗ и сделают все согласно ему, так как основная цель исполнителя — это попасть по срокам, бюджету и пожеланиям клиента. Здесь помимо объема подготовительной работы на заказчика ложится ответственность за жизнеспособность продукта, его соответствие рынку и удобство для конечных пользователей. Основной риск в таком подходе — получить решение, не соответствующее реалиям рынка, поскольку разработка может вестись в среднем 6-9 месяцев на стороне исполнителя практически в «вакууме».
При продуктовой разработке основная цель — создать продукт, который закрывает боли конечных пользователей и решает бизнес-задачи заказчика. При таком подходе сроки, бюджеты и требования к качеству формируются гибко в ходе разработки на основе результатов тестов, так как важно уберечь заказчика от ненужных трат и потери времени. Таким образом, в продуктовой разработке аутсорс-компания выступает не только «руками», но и «умом», разделяя ответственность и за то, чтобы конечный продукт решал задачи пользователей и был полезен.
— Что отличает продуктовый подход от других?
— Во-первых, фокус на создании ценного для пользователя продукта, а не на выполнении условий в ТЗ. Если ваш разговор с исполнителями фокусируется на функциях кнопок и прочих спецификациях, то это красный флаг. Ведь спецификации могут быть выполнены, а ваши бизнес-задачи — нет. Узнав от заказчика целевую проблему, продуктовая команда еще до начала разработки проводит подготовительную работу: изучает рынок, формирует предположения, проводит эксперименты, валидирует гипотезы, прорабатывает пользовательские пути, готовит прототипы, анализирует варианты с минимальными сроками и бюджетом. Во всем этом пути команда сфокусирована в первую очередь на закрытии нужд пользователей, а все остальное выстраивается вокруг этой задачи.
Получив все данные, команда выпускает часть продукта, представляющую собой полноценное решение. Он тут же отправляется на тесты и совершенствуется дальше на основе обратной связи, пока идет работа над следующими частями. «Что вы хотите, чтобы мы вам разработали?» — это отличный клиентоориентированный вопрос от подрядчика. Но вам надо ждать вопроса: «Какую проблему вы хотите решить?»
Во-вторых, это Time to Market — скорость передачи продукта в пользование и получение от него положительного эффекта. Продуктовый подход предполагает результат. Поэтому на старте внутри продуктовой команды ведется большая аналитическая работа: она определяет базовый функционал и стремится к выдаче минимального жизнеспособного продукта. Вся «мишура» откладывается до получения подтверждения действиями пользователей.
Вместо того, чтобы окунуться в затяжную разработку, команда идет итеративно: периодически по результатам исследований в короткие сроки выпускается часть продукта (обычно две недели). Для сравнения, в проектном подходе финальный продукт можно получить через 6-9 месяцев, а после, если в нем обнаружатся проблемы, потребуется доработка. Продуктовый подход позволяет выпустить первую версию продукта уже через 1,5 месяца, протестировать его на рынке и доработать в процессе.
В-третьих, бережливый подход к производству. В проектной разработке важно, чтобы бюджет и требования были целиком определены и согласованы с исполнителями еще на старте. Но зачастую в начале пути ни бизнес-цели, ни концепция, ни границы проекта не бывают четко определены. Разработка строится по чек-листу, а при приемке выясняются нюансы, многое оказывается уже не нужно, а в самый ответственный момент релиз откладывается на неопределенный срок из-за ошибок и несовместимости. Это ведет к перерасходам, отсрочкам и неправильному распределению средств. При продуктовом подходе оплачивается каждый промежуточный результат, а тестирование и приемка идут параллельно с релизами. Такой подход дает возможность заказчикам в процессе работы вносить изменения, правильно расставлять приоритеты и сокращать бюджет, отказываясь от ненужного.
В четвертых, прозрачность процесса доставки продукта. У продуктовой команды есть инструменты и процессы, благодаря которым заказчики могут погрузиться в детали проводимой работы в любой момент. Например, ритуалы Agile: планирование короткими спринтами, ежедневные стендапы, демо, ретроспектива. Более того, у зрелой продуктовой команды должны быть настроены системы аналитики эффективности и метрик с доступом для заказчиков.
И наконец, главное отличие продуктового подхода — адаптивность команды и процессов под реалии и изменения рынка, пользователей и бизнеса. Так как команда в первую очередь фокусируется на закрытии нужд пользователей, то она постоянно держит руку на пульсе рыночного контекста, и изменение курса — это частая практика для продуктовой разработки. Благодаря планированию короткими периодами, релизам итерациями и поставке самодостаточных частей продукта, команда может оперативно менять фокус без негативного влияния на весь продукт.
В заключение, важно, чтобы аутсорс-команда (как, впрочем, и внутренняя) обладала добавленной ценностью: доменная, техническая и продуктовая экспертизы были совместимы с вами по ДНК, чувствовали ваши цели и могли разделить стоящие перед вами задачи, вашу культуру.