Бережливый подход при разработке продукта. Часть 1

Семь типов потерь в бережливом подходе

Эта лекция посвящена бережливому подходу (Lean), основанному Таити Оно, в контексте создания IT-продуктов. Ключевых типов потерь выделяют семь. Любые потери можно отнести к одной из этих категорий:
1. Ожидание: Время простоя, очереди или ожидания согласования документов.
2. Транспортировка: Потерянные время и усилия на перемещение чего-либо внутри процесса или между ними.
3. Дефекты: Ошибки, нефункционирующие элементы, всё, что неприемлемо для клиента.
4. Запасы (излишки): Любые неиспользованные остатки. Это не только физическое сырье (как цемент у строителей), но и невыработанные человеко-часы или неиспользуемое оборудование. Сюда относят любые неграмотно рассчитанные ресурсы, которые остались в избытке.
5. Излишняя обработка: Выполнение работы в объеме большем, чем нужно для создания ценности. Трудозатраты есть, а их вклад в ценность для клиента минимален. От такой переработки нужно отказываться.
6. Перепроизводство: Создание значительно большего объема продукта, чем требуется.
7. Перемещение: Потери, вызванные нерациональным размещением объектов. В отличие от транспортировки (перемещения между процессами), здесь речь идет о лишних движениях из-за плохой эргономики или планировки.

Шесть принципов Lean в разработке продукта

1. Ориентация на создание ценности
Главное — покрыть потребности клиента, создать ценный для него результат. Субъективные оценки разработчика о важности, сложности или красоте продукта не имеют значения. Важен не объем выполненных работ, а предоставляемый функционал. Делать нужно только то, что нужно пользователю. Происходит смещение приоритетов от обязательных функций (Must Have) к желательным (Nice to Have), которые можно отложить.

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

3. Работа циклами
Начинать надо с маленьких шагов, следуя концепции минимально жизнеспособного продукта (MVP — Minimum Viable Product). Это некий минимальный набор функционала, достаточный для выхода на рынок. Получив обратную связь на первой итерации, на последующих продукт донасыщают функционалом, пока он не начнет соответствовать ожиданиям клиента.

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

5. Право на ошибку на раннем этапе
Принцип базируется на адаптивности и философии Кайдзен (Kaizen) — непрерывном совершенствовании. Ошибки на ранних стадиях допустимы (при грамотной работе впоследствии они должны исчезнуть).

6. Оптимизация рабочего процесса (Workflow)
Деятельность нужно планировать так, чтобы работать точно в срок. Следует избегать потерь из-за незавершенной работы (WIP — Work in Process), когда часть задач с сегодняшнего дня откладывается на завтра. Это лучше, чем пытаться успеть всё и сразу. Но если откладывать задачи комом, важные компоненты не будут готовы, что парализует работу всего продукта.

Управление на уровне компании

На уровне компании необходимо сокращать семь типов потерь. Каждый проект должен соответствовать стратегии. Запросы бизнес-подразделений важно получать, оценивать и приоритизировать, двигаясь от Must Have к Nice to Have.
Лучшее решение — выделенная команда из архитекторов, бизнес-аналитиков и менеджеров продуктов. Совмещение этих ролей в одном человеке чревато конфликтом интересов. Бизнес-аналитик, оценивая продукт, по сути, формирует дополнительный объем работы для архитектора. Когда это разные люди, процесс объективен. Когда роли совмещены, возникает соблазн минимизировать требования и сместить приоритеты в сторону Nice to Have, чтобы упростить себе работу. Для управления стратегическим бэклогом требуется понимание бизнеса, технические знания и системное мышление.
Управление запросами сравнимо с диспетчерской службой аэропорта: нужно синхронизировать множество параллельных процессов (релизы, разработку компонентов) с ожиданиями клиентов.

Разница в восприятии времени

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

Классификация элементов продукта

Элементы продукта делятся по двум критериям: степени доступности и характеру влияния.

Характер влияния	Видимые компоненты	Невидимые компоненты
Позитивное	Фичи (Features) — функционал, который наглядно демонстрирует работу и вызывает удовлетворенность.	Архитектурные решения — нравится то, как организована работа (например, цепочка навигации), но конкретную причину выделить сложно.
Негативно	Баги (Bugs) — дефекты и ошибки.	Технический долг (Technical Debt) — недоработки в архитектуре, которые нужно компенсировать.

Уровни документирования требований

В зависимости от масштаба проекта применяется разный уровень документации.

• Бизнес-кейс (Business Case Document): для крупных проектов (тип А). Включает:
o Бизнес-требования (зачем нужен продукт).
o Скоп (Scope) — круг задач и фич с их приоритизацией.
o Контекст (интеграции, системы, способы взаимодействия с пользователем).
o Анализ затрат и выгод (Cost and Benefit Analysis).
o Риски и меры противодействия им.
• Видение и скоп (Vision & Scope Document): для проектов типа Б. Упрощенная документация. Требования бизнеса описываются единым блоком, где по «крупным мазкам» сводятся фазы проекта, фичи для каждой фазы и высокоуровневый контекст.
• Документ-описание работ (Statement of Work): для небольших улучшений. Документ на 1-2 страницы с описанием скоупа работ.

Приоритизация требований (MoSCoW)

Приоритеты выставляются по соотношению «ценность/сложность реализации».

• Высокий приоритет: несложно сделать и несет высокую ценность.
• Средний приоритет: легко сделать, но ценность невысокая, ИЛИ ценность высокая, но реализовать сложно.
• Низкий приоритет (Nice to Have): крайне сложно в разработке и не несет высокой ценности (просто «вишенка на торте»).

Стратегически приоритизация ведется по модели MoSCoW:
1. Must Have (Обязательно): Критически важное требование. Критерий успеха: если не сделано, проект нельзя считать выполненным.
2. Should Have (Следует сделать): Важное требование, но может быть реализовано позже. В любом случае будет выполнено.
3. Could Have (Можно сделать): Не столь важное, но улучшающее пользовательский опыт. Включается в релиз только при наличии свободных ресурсов. Отличие от Should Have в том, что от Could Have можно отказаться насовсем.
4. Won't Have (Не будет сделано сейчас): Требование не реализуется в данный момент.

Модель Кано (Kano Model)

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

Типы компонентов:
• Базовые: Обязательные свойства, без которых продукт не рассматривается (например, руль в автомобиле).
• Дополнительные (Фичи): «Плюшки», вызывающие восторг (например, люк в автомобиле).
• Одномерные (Статичные): Свойства, по которым сравнивают продукты количественно (например, расход топлива на 100 км).

Ключевое наблюдение модели Кано:
Зависимость удовлетворенности по оси Y от вложений в реализацию по оси X ведет себя по-разному.

• Кривая базовых компонентов — возрастающая, но она всегда находится ниже нейтрального уровня. Доведение этих свойств до совершенства не вызывает восторга (водитель не радуется наличию руля), а лишь подводит потребителя к нейтральной оценке.
• Кривая дополнительных фич — дает нелинейный рост восторга. Чем больше таких фич, тем быстрее растет удовлетворенность при первичной оценке, даже если в итоге они окажутся бесполезными.
• Прямая одномерных компонентов — линейна. Насколько больше/лучше характеристика, настолько выше удовлетворенность.

Практическое применение:
Можно компенсировать нехватку базового функционала (низкую точку на кривой) усилением позиций по дополнительным фичам и одномерным компонентам, чтобы в сумме обеспечить высокую общую удовлетворенность продуктом.

Жизненный цикл продукта и Time-to-Market

Ключевой вопрос — время выхода на рынок (Time-to-Market). Для его сокращения используется принцип 80/20: 80% сценариев использования покрываются 20% функционала. Сделав эти 20%, вы покроете большинство пользовательских кейсов.
Важно отвечать на вопрос «какие проблемы решает мой продукт?», а не «что делает мой конкурент?».

Цикл разработки:
1. Начальная идея и инвестиции позволяют разработать видение продукта.
2. На основе видения формируется гипотеза, согласно которой требования распределяются по категориям MoSCoW.
3. Создается часть продукта и уходит в релиз.
4. На основе наблюдений и измерений гипотеза корректируется. Требования перераспределяются между Must Have, Should Have и Could Have.
5. Цикл повторяется до получения минимально жизнеспособного продукта (MVP) и выхода на рынок.
6. Если рост удовлетворенности не наблюдается — идея нежизнеспособна и производство закрывается.

Краткие итоги

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

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

Методология приоритизации MoSCoW и модель Кано дают практическую основу для принятия инвестиционных решений. С их помощью становится очевидно, что вложения в базовый «обязательный» функционал не приносят пропорциональной эмоциональной отдачи от клиента. Они лишь удерживают продукт «на плаву», в зоне нейтральной оценки. Прорывной рост удовлетворенности создается иным классом решений — избирательными инновационными функциями, эффект от которых нелинейно усиливает пользовательский опыт, компенсируя несовершенство или отсутствие некоторых базовых элементов.

Стратегия вывода продукта на рынок, следовательно, не должна опираться на исчерпывающую реализацию всех мыслимых требований. Она превращается в циклический процесс валидации гипотез, нацеленный на скорейшее достижение состояния минимально жизнеспособного продукта. Прагматизм требует применения правила 80/20, что позволяет быстро занять нишу, получив реальные данные об использовании, и только затем итерационно дорабатывать решение. Критическим фактором успеха становится синхронизация «разноскоростного» мышления бизнеса и разработки, где абстрактная архитектурная ценность должна быть переведена на язык деловых ожиданий и временных рамок.