Привет! Меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. В статье расскажу о проблеме, с которой сталкивается большинство ИТ-компаний: они тратят миллионы на разработку функций, которыми никто не пользуется.
В лучших компаниях мира только 15% функциональности продуктов действительно востребовано пользователями. В средних компаниях эта цифра падает до 5-10%. Остальные 85-90% функций становятся «синтетическим сахаром» — они есть, но никто ими не пользуется.
Возьмем, например, Microsoft Word, в котором пользователи работают с двумя-тремя вкладками из десятков доступных. Остальные функции прячутся где-то в интерфейсе, и люди о них не узнают, пока кто-то не расскажет или они не прочитают статью. Но по факту эти функции им не нужны — они только усложняют работу и создают технический долг для разработчиков. Каждая неиспользуемая кнопка требует поддержки. Разработчики должны залезать в каждую фичу при исправлении ошибок. Чем больше избыточного функционала, тем дороже обходится поддержка продукта.
Эта проблема — прямое следствие подхода к разработке. Компании до сих пор работают по старой схеме: собрали требования, написали техзадание, команда ушла на полгода делать, и только потом выяснилось, что половина функций никому не нужна. Продуктовый подход предлагает другую логику: делать небольшими партиями и проверять каждый шаг. Но почему тогда большинство компаний продолжают работать по-старому?
Project vs Product
Представьте: команда получает задачу добавить в продукт функциональность, пусть это будет режим рецензирования на примере Word. Как будут действовать при разных подходах?
Проектный путь
Команда идет к пользователям, спрашивает требования, составляет техзадание. Рисует диаграмму Ганта и уходит на полгода разрабатывать. Через полгода выдает готовую функциональность: комментарии, панель правок, версионирование, отслеживание изменений.
Все работает, пользователи довольны, и проект закрыт.
Но никто не проверяет, какими именно кнопками люди пользуются. Возможно, половина функций избыточна — они просто будут влиять на технический долг. Каждую функцию нужно поддерживать, тестировать при обновлениях, исправлять ошибки.
Критерий успеха проектного подхода — проектный треугольник: уложились в бюджет, сроки и ресурсы. Это внутренний критерий: делаем то, что обещали, а не то, что действительно нужно.
Продуктовый путь
Команда тоже идет к пользователям и выясняет потребности, но не пытается сразу реализовать все требования, а работает итерациями.
Сначала добавляют только комментарии. Запускают A/B-тест — видят, что фичу используют. Отлично, значит, функция нужна.
Затем добавляют версионирование. При тестировании оказывается, что это слишком сложно для целевой аудитории, никто не хочет разбираться с версиями документов.
Переделывают версионирование в простое принятие правок: «принять» или «отклонить». Тестируют снова, теперь люди пользуются.
Критерий успеха продуктового подхода — внешний: нужно ли это пользователю, приносит ли пользу. Постоянные инструменты проверки гипотез: количественные метрики, NPS, количественные и качественные исследования. При этом разница не только в процессе, меняется вся философия работы. Вместо «сделать то, что считаем правильным» команда делает «то, что действительно нужно пользователю».
Почему не все идут по продуктовому пути
Продуктовый подход существует не первый год: о нем говорят на каждой IT-конференции, Agile и Scrum стали мейнстримом, но большинство компаний продолжает работать по-старому. Почему?
Главный барьер — психологический. Менеджеры привыкли к контролю и планированию. В проектном подходе все понятно: Петров делает задачу А, Иванов — задачу В. Диаграмма Ганта показывает, кто чем занимается следующие полгода.
В продуктовом подходе такой ясности нет. Команда работает на общую цель, например, увеличить количество пользователей на 2%. Как именно? Дизайнер может заняться маркетинговыми материалами, разработчик — оптимизацией для демо-версии, аналитик — видеосценариями.
Ролевые границы размываются. Никто не знает, чем будет заниматься через месяц. Для менеджеров это стресс — как контролировать работу, если нет четкого плана? Помимо этих опасений, на рынке есть опасные мифы об Agile.
Три мифа об Agile
Миф первый: Agile дороже
Многие считают, что гибкие методологии увеличивают бюджеты. Отчасти это правда, но по определенной причине. В продуктовом подходе появляется соблазн постоянно улучшать: «А давайте еще вот здесь переделаем», «А можно добавить еще одну функцию». Скоп работ растет, потому что команда видит возможности для улучшений, но забывает учитывать это в планировании бюджета.
Миф второй: Agile работает быстрее
Руководители часто думают: «У нас проект через месяц, давайте запустим Agile-команду и все успеем». Agile действительно может ускорить работу, но не за счет магии. Ускорение происходит, потому что команда перестаёт переключаться между задачами. Когда разработчик работает над задачей А и переключается на задачу В, он тратит минимум 20 минут, чтобы погрузиться в новую задачу. Agile призывает сконцентрироваться на одной-двух задачах максимум — отсюда экономия времени.
Но сам объем работы остается тем же. Agile про гибкость и адаптацию под рынок, а не про скорость в первую очередь.
Миф третий: продуктовый подход универсален
Продуктовый подход — это решение не для всех. Прежде всего он заточен под непредсказуемый конкурентный рынок, когда мы не понимаем до конца, что нужно сделать.
Если вы автоматизируете производство, нет смысла ставить одного промышленного робота, смотреть как он работает, потом ставить второго и снова смотреть. Проще сделать план проекта, посчитать все заранее и установить всех роботов сразу.
Примеры компаний, которые страдают от проектного подхода
Продукты одного известного российского разработчика решения для автоматизации процессов на крупных предприятиях — классический пример проектного мышления. Интерфейс перегружен функциями, адаптация к изменениям идет медленно. Компания выигрывает за счет интеграции с налоговой и привычки пользователей, но не за счет удобства продукта.
Например, продукт этой же компании — ERP, для перехода на который компании вкладывают десятки миллионов. При этом внедрение не получается, отношение к системе портится. Партнеры, которые внедряют решения разработчика, не могут внести доработки быстро, все идет через сложные процедуры согласования.
Решение для управления проектами от этого разработчика демонстрирует ту же проблему. В продукте есть канбан-доска, команды разработки теоретически могут работать в единой системе с остальными процессами компании. Но на практике компании используют Jira вместо российского решения. Команды разработки не хотят на него переходить, так как развитие системы идет медленно, а функциональность ограничена.
Цена медлительности
История знает примеры компаний, которые заплатили за приверженность проектному подходу:
Nokia провалилась из-за серии стратегических просчетов. Руководство видело угрозу сенсорных интерфейсов, но боялось разрушить успешную бизнес-модель, построенную на Symbian. Инерция победила здравый смысл. Внутренняя борьба между отделами за ресурсы парализовала разработку — вместо диалога с пользователями компания воевала сама с собой. Когда появился iPhone, Nokia ответила слишком поздно и неубедительно.
BlackBerry стала жертвой собственного успеха в корпоративном сегменте. Руководство верило, что безопасность и физическая клавиатура — неоспоримые конкурентные преимущества. Компания улучшала существующие модели по крупицам, игнорируя сигналы рынка. Пользователи хотели мультимедийные возможности и экосистему приложений, которые предложил Apple. BlackBerry этого не услышала и продолжала делать то, что считала правильным.
Intel проиграла в мобильном рынке из-за архитектурных и бизнес-решений. Мощная x86-архитектура потребляла слишком много энергии для смартфонов, чипы на ARM-архитектуре от конкурентов работали эффективнее. Intel отказалась адаптировать прибыльную бизнес-модель под низкомаржинальные мобильные чипы. Компания слишком поздно начала создавать энергоэффективные решения — Apple и другие производители уже захватили рынок.
Общая проблема всех трех гигантов: они работали в парадигме «мы знаем, что нужно пользователям». Вместо исследований рынка и адаптации под потребности аудитории компании совершенствовали то, что считали важным. Проектное мышление — планируем в начале, делаем по плану, не отвлекаемся на внешние сигналы — привело к катастрофическим последствиям в быстро меняющейся индустрии.
Как меняется мышление в продуктовом подходе
С продуктовым подходом фокус менеджера меняется. Если раньше главным было контролировать сроки и бюджет, то теперь — анализировать ценность для пользователя. Вместо вопроса «Уложились ли в план?» менеджер спрашивает: «Нужно ли это пользователю? Готов ли он за это платить?»
Команда больше не работает по индивидуальным задачам. Все сосредоточены на продукте и его развитии. Продукт становится центральной сущностью, которая объединяет людей вокруг единого видения.
Успех продукта теперь определяют по тому, приносит ли он деньги компании. Но деньги — не единственный критерий. NPS и обратная связь показывают устойчивость позиций на рынке, так как у компании всегда есть риск потерять нишу при появлении более удобного конкурента. Как мы знаем, рынок может поменяться за один день. Компании, которые не умеют быстро адаптироваться, рискуют остаться позади конкурентов, которые реагируют на изменения за несколько недель, а не месяцев или лет.
Мы в SimpleOne считаем, что продуктовый подход можно применить и для управления самой компанией — это открывает неожиданные возможности для оптимизации внутренних процессов. Например, в SDLC-системе можно создать продукт «Компания» с базой знаний всех регламентов, процедур и стандартов работы. Любое предложение по улучшению процессов становится feature request: нужно внедрить методологию OKR? Создаете запрос на изменение регламента.
Хотите изменить процедуру согласования документов? Тот же механизм. Delivery-менеджеры или другие ответственные сотрудники становятся проектной командой для внутренних изменений, которая берет эти запросы в работу.
Такой подход дает измеримость и контроль над развитием компании. Вы видите, сколько времени занимает внедрение изменений — например, в среднем 4 месяца на задачи по процессам. Можете анализировать, какие типы изменений проходят быстрее, где возникают узкие места. База знаний хранит всю актуальную документацию в одном месте, связанную с продуктом-компанией. Так инструменты продуктовой разработки работают не только для IT-продуктов, но и для развития бизнеса в целом.
Для новых задач компании выбирают новые инструменты. Для проектного подхода хорошо подходят PM-системы и таск-трекеры, где каждая команда работает на своей доске, в своем проекте. Есть главный PM, который планирует работу всех, но связи между командами размыты. Напротив, в продуктовом подходе нужна связь между разными направлениями разработки. Один из современных подходов к управлению разработкой сложных комплексных продуктов — это Software Development Life Cycle, или SDLC.
SDLC-системы объединяют видение целого продукта, командам доступны общие цели и стратегии развития. В таких системах появляются интеграции с Git, системами тестирования, продвинутые базы знаний для разработки. Инструменты заточены под разработку, а не просто под управление задачами.
При этом продуктовый подход не заканчивается релизом. SDLC — это управление полным жизненным циклом разработки, то есть и этапами совершенствования продукта.
После релиза начинается поддержка и непрерывное совершенствование, поэтому мы в SimpleOne интегрировали SDLC и ITSM, чтобы у разработчиков была возможность работать с инцидентами после релиза.
ITSM покрывает поддержку существующих продуктов, SDLC — разработку новых. Связка работает через KEDB (базу данных известных ошибок): техподдержка создает задачу на быстрый фикс проблемы, команда разработки планово устраняет корневую причину.
***
Продуктовый подход решает главную проблему IT-разработки — избыточную функциональность. Вместо 15% полезных функций из общего объема вы получаете продукт, где каждая кнопка проверена пользователями и действительно нужна.
А вы в каком лагере: проектный или продуктовый подход?