Это первая часть статьи о релизе новых модулей заказы и финансы в TS, который выйдет в начале 2022 года. Цель — дать общее теоретическое описание, чтобы приблизиться к единому пониманию базовых принципов, на которых базируется разработка TS. Здесь рассказываем о том, что такое крупный IT-продукт и как он создается. Статья будет полезна всем пользователям Платформы ABCP — и тем, кто ничего не понимает в IT, и тем, кто считает, что всё понимает. Просим вас внимательно ознакомиться со статьей, а если после прочтения появятся вопросы, будем рады обсудить их в специальном чате Платформы.
Что такое крупный IT-продукт?
Крупный IT-продукт — это уникальный и неповторимый организм. IT-продукты отличаются друг от друга всем — от условий старта до бесконечности других параметров. Путь одних IT-продуктов начинается с глобальной идеи, неограниченного бюджета и укомплектованной профессиональной команды, других — с локальной идеи без бюджета и без команды. Также на развитие проектов влияют любые сочетания условий и событий, в т.ч. экономических, политических, социальных, они предопределяют настоящее и будущее IT-продуктов. Позитивное развитие событий позволяет IT-продукту превратиться в масштабный, успешный, высокодоходный продукт массового использования.
Если бы все запускаемые IT-продукты развивались по позитивному сценарию, то мы уже давно жили бы в совсем другом мире. Даже статистика закрытых проектов мировых гигантов, которые могут себе позволить и лучшие технологии, и лучших специалистов, и неограниченные бюджеты, говорит, что далеко не все начинания заканчиваются успехом. Но само понятие “успех” для IT-продукта является также неоднозначным для всех его участников. И со стороны создателей, и со стороны пользователей есть бесконечное количество мнений и метрик оценки успешности продукта.
Кто создаёт IT-продукты?
Участники группы создателей распределяют между собой различные роли и подразделяются на команды внутри компании-разработчика:
- продукт-менеджер или управляющий продуктом — компетентный в экономике, маркетинге и управлении специалист, ответственный за разработку и финансовый успех, за создание новых или развитие существующих продуктов компании на основе анализа рынка, потребительских ожиданий и стратегии развития компании;
- продукт-оунер или владелец продукта — компетентный в IT и управлении специалист, отвечающий за реализацию продуктов, утвержденных продукт-менеджерами;
- менеджеры проектов — специалисты различных направлений (разработчики, аналитики, маркетологи и т.д.) с управленческими компетенциями, обладающие необходимой для продукта экспертизой, их целью является реализация проектов внутри продукта на этапах запуска или в процессе улучшения;
- участники проектов — специалисты различных направлений, различного уровня и компетенций, выполняющие узкоспециализированные задачи внутри проектов.
У каждого специалиста и команды могут быть индивидуальные и общепринятые метрики успеха продукта. Отношение разных компаний к метрикам и оценкам также отличается, нет единых стандартов. Где-то придерживаются строгой параноидальной оцифровки каждого шага и действия, затрачивая на это массу усилий и денежных средств, а где-то опираются только на показатель чистой прибыли компании. Кто из них поступает правильнее, никто точно сказать не сможет. Точнее, мнений и убеждений на этот счёт миллион, но действительно доказанных и многократно воспроизводимых примеров не существует.
А теперь затронем самое больное место крупного IT-продукта — это пользователи и их мнение. Один пользователь считает продукт бесполезным, неудобным и не рекомендует им пользоваться, а другой считает лучшим решением на рынке и платит за его использование сотни тысяч рублей в месяц. Парадокс состоит в том, что наличие диаметрально противоположных мнений — это правило. И IT-индустрия не стала исключением. Более того, новизна и сложность понимания особенностей IT-продуктов не только далекими от этой сферы людьми, но и профессионалами часто формирует среду информационного хаоса вокруг продуктов. Ни один внешний IT-специалист не способен объективно оценить IT-продукт, а если речь идет о крупном продукте, то и не все внутренние специалисты. Обратная связь от пользователей с кейсами и опытом использования продукта — это один из важнейших инструментов для улучшения и совершенствования продукта. Пользователей, принимающих активное участие в обсуждении продукта на первых этапах его выхода в свет, по праву можно относить к команде создателей. Их опыт и кейсы закладываются в функционал и логику продукта.
Вышеописанное вносит свой вклад в становление и успешность крупного IT-продукта. Однако помимо непосредственных создателей и пользователей есть огромный мир факторов внутри и за пределами компании, оказывающих прямое или косвенное воздействие на продукт, а также запускающих созидательные или разрушительные цепочки событий. К примеру, по мере развития IT-продукта его содержание, обслуживание и поддержка усложняются и дорожают. Объем кода, пользовательская нагрузка, эволюция языков программирования, новые технологии, новые сервисы, с которыми приходится строить интеграции, приводят к необходимости вносить большие изменения или полностью переписывать некоторые модули продукта. Часто такие изменения являются чистым расходом для компании и не приводят к увеличению прибыли. Поэтому важно удерживать баланс между перспективными разработками и безвозвратными инвестициями, вовремя отказываясь от убыточных модулей, проектов и продуктов, но при этом не переставать генерировать и тестировать идеи.
Что такое MVP?
Не все идеи IT-продуктов находят своё место в мире. Исследования рынка, потребителей, анализ существующих технологий и продуктов не могут гарантировать успешность или безуспешность новых идей. Довольно часто без реального теста на потребителях крайне сложно оценить перспективы продукта или правильность выбранного для реализации пути, набора функций и т.д. Поэтому и появился особенно распространенный в создании IT-продуктов метод — MVP (minimal viable product или минимально жизнеспособный продукт). MVP представляет собой пробник продукта, способный дать потребителю пользу, а взамен получить ценную информацию о спросе, опыте использования и удовлетворенности. MVP применяется как на этапе первоначального запуска, так и в процессе улучшения и добавления новых функций.
Плюсы работы с MVP:
- экономия времени и средств на проверке жизнеспособности гипотезы или идеи;
- быстрая корректировка планов, постановка целей и приоритетов дальнейшей разработки на основе опыта пользователей и собранных данных;
- поэтапная разработка, постепенное улучшение и доработка продукта во время использования.
Крупные IT-продукты разрабатываются годами и даже десятилетиями. Поэтому важнейшим преимуществом MVP является возможность поэтапно предоставлять продукт, способный каждой своей версией закрывать часть потребностей пользователя. Важно понимать, что закрыть сразу все потребности и разработать сразу весь функционал не представляется возможным. Почему? Причина проста — ресурсы. Тут можно даже объединить ресурсы в один самый важный — время. Время включает в себя всё — ценность и доступность денежных средств, состав и профессионализм команды, ошибки и возможность их исправить, технологии и оборудование и т.д. Ключевой момент — на какой период можно позволить себе использовать то, что требуется для создания продукта, в каком составе и в каком качестве. Поэтому выпуская продукт поэтапно и получая заинтересованных пользователей, создатели выигрывают время.