- Что это за правило и зачем оно нужно
- Почему без этого правила проекты разваливаются
- Как построить правило под ваш проект
- Шаг 1. Определите, что значит «три часа» в вашем контексте Три часа — это не три часа в календаре с перерывами на кофе и почту. Это три часа сфокусированной работы над конкретной задачей. Для разработчика это может быть один помодоро-цикл с перерывами. Для дизайнера — один сеанс исследования и набросков. Для менеджера — один блок без встреч, где можно разобрать требования. Если ваша команда работает спринтами, три часа — это примерно половина одного рабочего дня. Если команда маленькая и нон-стоп в потоке — возможно, это утро одного дня. Главное: это непрерывный фокус на одной задаче. Шаг 2. Зафиксируйте критерии «глубины» Вам нужна простая шкала, которую команда понимает одинаково. Вот пример из практики: Уровень глубины Что это значит Пример Действие Поверхностный Задача полностью понятна, решение очевидно, правки минимальны Изменить цвет кнопки, поправить текст в шапке Делайте сразу, не раздумывайте Средний Задача понятна в общих чертах, но есть 1–2 неизвестных, которые нужно проверить Добавить валидацию формы с новыми правилами Три часа на исследование — затем принимайте решение Глубокий Задача содержит более двух неизвестных, может повлиять на другие части системы Переработать систему авторизации с добавлением новых провайдеров Три часа на разведку — затем отдельная оценка и планирование Разведочный Задача сформулирована расплывчато, требует значительного исследования перед оценкой «Улучшить производительность личного кабинета» Три часа на диагностику — затем формулировка реальных задач Ключевой момент: эта шкала не для отчётности. Она для команды, чтобы все одинаково понимали, что значит «мы ещё не знаем, что делать». Шаг 3. Встроите правило в процесс приёма задач Правило не работает, если о нём вспоминают постфактум. Его нужно встроить в момент, когда задача попадает в работу. Практический сценарий: когда задача приходит в работу, исполнитель получает три часа на «распаковку». За это время он обязан либо: Сделать задачу целиком (если она действительно простая). Чётко описать границы задачи: что входит, что не входит, какие есть неизвестные. Сказать: «Я потратил три часа, и вот что узнал» — и предложить следующий шаг. Третий вариант — самый ценный. Это не провал. Это результат. Вы за три часа получили информацию, которой не было до этого, и теперь можете принять решение с пониманием, а не вслепую. Как применять правило на практике Сценарий 1: Вы — исполнитель Вам пришла задача. Первое ощущение — «ну, на полчаса». Не доверяйте первому ощущению. Засеките три часа. В течение этого времени: Сделайте первый набросок решения или реализации. Запишите всё, что вызывает сомнения — каждое «не уверен», «надо проверить», «а что если». Если нашли больше двух пунктов в списке сомнений — остановитесь и идите к руководителю или заказчику. Цель — не сделать задачу за три часа. Цель — понять её реальный объём. Сценарий 2: Вы — руководитель или PM Когда команда даёт оценку, спросите: «Это оценка после трёх часов погружения или первое впечатление?» Если первое впечатление — отправляйте тратить три часа. Это не замедление, это экономия. Потому что потом переделывать всегда дольше, чем разобраться в начале. Ещё один приём: в планировании закладывайте «буфер глубины». Если команда оценила задачу в 2 дня, но это оценка без трёхчасового погружения — добавьте 30–50% сверху. Не как наказание, а как страховку от неизвестных, которые обязательно всплывут. Сценарий 3: Вы — фрилансер или консультант Клиент говорит: «Сделайте простую посадочную страницу». Вы знаете, что «простая» — самое опасное слово. Три часа вы тратите на интервью и анализ конкурентов, потом приходите с двумя вариантами: действительно простая страница за X часов, или страница с интеграцией CRM, аналитикой и адаптацией под 5 типов устройств за 3X часов. Клиент видит, что вы не раздуваете смету, а разбираетесь. Это доверие стоит больше, чем экономия на первом этапе. Частые ошибки при внедрении Ошибка 1: Превратить три часа в наказание Если команда воспринимает правило как «ты не справился за три часа — ты плохой», оно перестаёт работать. Три часа — это не дедлайн на задачу. Это дедлайн на понимание задачи. Если за три часа вы поняли, что задача огромная — это победа, а не провал. Ошибка 2: Использовать правило для абсолютно всех задач Не нужно тратить три часа на исследование задачи «поменять иконку». Правило применяется к задачам, где есть хотя бы один признак неопределённости: новые технологии, неясные требования, влияние на другие модули, участие нескольких людей. Ошибка 3: Не фиксировать результат трёх часов Если вы потратили три часа и просто пошли дальше «с чувством, что разобрались» — вы потеряли время. Результат трёх часов должен быть зафиксирован: короткий документ, комментарий в задаче, схема на доске. Что угодно, что можно показать другому человеку. Ошибка 4: Игнорировать результат и делать по-прежнему Самопасная ошибка. Команда потратила три часа, поняла, что задача — не два дня, а две недели, и всё равно взяла её в спринт на два дня «потому что дедлайн горит». Это не героизм, это путь к выгоранию и срыву сроков. Результат трёх часов должен менять решение. Когда правило работает лучше всего Правило 3-часовой глубины особенно ценно в следующих ситуациях: Новый проект или новая команда. Никто ещё не знает, где водятся подводные камни. Три часа на каждую задачу — это быстрый способ собрать карту рисков. Работа с легаси-кодом. Старый код всегда сложнее, чем кажется. Три часа на чтение и понимание — это не роскошь, это необходимость. Межкомандные зависимости. Когда ваша задача зависит от другой команды, три часа на согласование интерфейса экономят недели переделок. Инциденты и баги. Прежде чем чинить баг, потратьте час-полтора на понимание его реальной причины. Часто «баг» оказывается следствием архитектурной проблемы. Как внедрить правило в команду без сопротивления Любое новое правило в команде встречает скепсис. Вот как снизить сопротивление: Начните с добровольного эксперимента. Не объявляйте новое правило сверху. Попробуйте на себе в течение двух недель и покажите результат: «Вот эту задачу я взял за 2 дня, а потом две недели переделывал. А вот эту — потратил 3 часа на разбор, понял реальный объём, сделал за 5 дней без правок». Сделайте результат видимым. Заведите привычку: после трёх часов погружения писать короткий summary. Не отчёт — конкретику: «Задача X. Потрачено 3 часа. Результат: задача средней глубины, неизвестные — A и B. Предлагаю сделать C». Не привязывайте к KPI. Как только правило становится метрикой эффективности, оно начинает лукавить. Это инструмент качества, а не контроля. Обсудите на ретро. Через месяц применения спросите команду: «Где нам помогло остановиться на три часа? Где стоило бы остановиться, но не остановились?» Что делать, если три часа прошли, а понимания нет Это нормально — и это тоже результат. Если за три часа вы не смогли ни сделать задачу, ни очертить её границы, значит: Задача сформулирована слишком абстрактно. Нужно разбить на подзадачи и применить правило к каждой. Вам не хватает информации от других людей. Три часа — это сигнал: «Мне нужен разговор с экспертом / заказчиком / смежной командой». Задача требует прототипирования или эксперимента, а не анализа. В этом случае три часа — это времи на создание минимального прототипа, а не на чтение документации. Главное: три часа без результата — это не «я не справился». Это «задача требует другого подхода». Используйте эту информацию. Итог: что делать прямо сейчас Если вы узнали в описании свои боли — попробуйте уже сегодня. Возьмите одну задачу, которая кажется простой, засеките три часа и посмотрите, что произойдёт. Скорее всего, одно из трёх: Вы сделаете её за три часа — и будете знать, что подобные задачи можно не переоценивать. Вы обнаружите скрытый объём — и сможете честно переоценить до того, как пообещали сроки заказчику. Вы поймёте, что задача требует другого подхода — и сэкономите команде дни переделок. Правило 3-часовой глубины — это не про скорость. Это про честность с собой и с командой. Про то, чтобы не обещать того, чего не понимаешь. Про то, чтобы тратить время на понимание там, где оно реально экономит время.
- Шаг 2. Зафиксируйте критерии «глубины» Вам нужна простая шкала, которую команда понимает одинаково. Вот пример из практики: Уровень глубины Что это значит Пример Действие Поверхностный Задача полностью понятна, решение очевидно, правки минимальны Изменить цвет кнопки, поправить текст в шапке Делайте сразу, не раздумывайте Средний Задача понятна в общих чертах, но есть 1–2 неизвестных, которые нужно проверить Добавить валидацию формы с новыми правилами Три часа на исследование — затем принимайте решение Глубокий Задача содержит более двух неизвестных, может повлиять на другие части системы Переработать систему авторизации с добавлением новых провайдеров Три часа на разведку — затем отдельная оценка и планирование Разведочный Задача сформулирована расплывчато, требует значительного исследования перед оценкой «Улучшить производительность личного кабинета» Три часа на диагностику — затем формулировка реальных задач Ключевой момент: эта шкала не для отчётности. Она для команды, чтобы все одинаково понимали, что значит «мы ещё не знаем, что делать». Шаг 3. Встроите правило в процесс приёма задач Правило не работает, если о нём вспоминают постфактум. Его нужно встроить в момент, когда задача попадает в работу. Практический сценарий: когда задача приходит в работу, исполнитель получает три часа на «распаковку». За это время он обязан либо: Сделать задачу целиком (если она действительно простая). Чётко описать границы задачи: что входит, что не входит, какие есть неизвестные. Сказать: «Я потратил три часа, и вот что узнал» — и предложить следующий шаг. Третий вариант — самый ценный. Это не провал. Это результат. Вы за три часа получили информацию, которой не было до этого, и теперь можете принять решение с пониманием, а не вслепую. Как применять правило на практике Сценарий 1: Вы — исполнитель Вам пришла задача. Первое ощущение — «ну, на полчаса». Не доверяйте первому ощущению. Засеките три часа. В течение этого времени: Сделайте первый набросок решения или реализации. Запишите всё, что вызывает сомнения — каждое «не уверен», «надо проверить», «а что если». Если нашли больше двух пунктов в списке сомнений — остановитесь и идите к руководителю или заказчику. Цель — не сделать задачу за три часа. Цель — понять её реальный объём. Сценарий 2: Вы — руководитель или PM Когда команда даёт оценку, спросите: «Это оценка после трёх часов погружения или первое впечатление?» Если первое впечатление — отправляйте тратить три часа. Это не замедление, это экономия. Потому что потом переделывать всегда дольше, чем разобраться в начале. Ещё один приём: в планировании закладывайте «буфер глубины». Если команда оценила задачу в 2 дня, но это оценка без трёхчасового погружения — добавьте 30–50% сверху. Не как наказание, а как страховку от неизвестных, которые обязательно всплывут. Сценарий 3: Вы — фрилансер или консультант Клиент говорит: «Сделайте простую посадочную страницу». Вы знаете, что «простая» — самое опасное слово. Три часа вы тратите на интервью и анализ конкурентов, потом приходите с двумя вариантами: действительно простая страница за X часов, или страница с интеграцией CRM, аналитикой и адаптацией под 5 типов устройств за 3X часов. Клиент видит, что вы не раздуваете смету, а разбираетесь. Это доверие стоит больше, чем экономия на первом этапе. Частые ошибки при внедрении Ошибка 1: Превратить три часа в наказание Если команда воспринимает правило как «ты не справился за три часа — ты плохой», оно перестаёт работать. Три часа — это не дедлайн на задачу. Это дедлайн на понимание задачи. Если за три часа вы поняли, что задача огромная — это победа, а не провал. Ошибка 2: Использовать правило для абсолютно всех задач Не нужно тратить три часа на исследование задачи «поменять иконку». Правило применяется к задачам, где есть хотя бы один признак неопределённости: новые технологии, неясные требования, влияние на другие модули, участие нескольких людей. Ошибка 3: Не фиксировать результат трёх часов Если вы потратили три часа и просто пошли дальше «с чувством, что разобрались» — вы потеряли время. Результат трёх часов должен быть зафиксирован: короткий документ, комментарий в задаче, схема на доске. Что угодно, что можно показать другому человеку. Ошибка 4: Игнорировать результат и делать по-прежнему Самопасная ошибка. Команда потратила три часа, поняла, что задача — не два дня, а две недели, и всё равно взяла её в спринт на два дня «потому что дедлайн горит». Это не героизм, это путь к выгоранию и срыву сроков. Результат трёх часов должен менять решение. Когда правило работает лучше всего Правило 3-часовой глубины особенно ценно в следующих ситуациях: Новый проект или новая команда. Никто ещё не знает, где водятся подводные камни. Три часа на каждую задачу — это быстрый способ собрать карту рисков. Работа с легаси-кодом. Старый код всегда сложнее, чем кажется. Три часа на чтение и понимание — это не роскошь, это необходимость. Межкомандные зависимости. Когда ваша задача зависит от другой команды, три часа на согласование интерфейса экономят недели переделок. Инциденты и баги. Прежде чем чинить баг, потратьте час-полтора на понимание его реальной причины. Часто «баг» оказывается следствием архитектурной проблемы. Как внедрить правило в команду без сопротивления Любое новое правило в команде встречает скепсис. Вот как снизить сопротивление: Начните с добровольного эксперимента. Не объявляйте новое правило сверху. Попробуйте на себе в течение двух недель и покажите результат: «Вот эту задачу я взял за 2 дня, а потом две недели переделывал. А вот эту — потратил 3 часа на разбор, понял реальный объём, сделал за 5 дней без правок». Сделайте результат видимым. Заведите привычку: после трёх часов погружения писать короткий summary. Не отчёт — конкретику: «Задача X. Потрачено 3 часа. Результат: задача средней глубины, неизвестные — A и B. Предлагаю сделать C». Не привязывайте к KPI. Как только правило становится метрикой эффективности, оно начинает лукавить. Это инструмент качества, а не контроля. Обсудите на ретро. Через месяц применения спросите команду: «Где нам помогло остановиться на три часа? Где стоило бы остановиться, но не остановились?» Что делать, если три часа прошли, а понимания нет Это нормально — и это тоже результат. Если за три часа вы не смогли ни сделать задачу, ни очертить её границы, значит: Задача сформулирована слишком абстрактно. Нужно разбить на подзадачи и применить правило к каждой. Вам не хватает информации от других людей. Три часа — это сигнал: «Мне нужен разговор с экспертом / заказчиком / смежной командой». Задача требует прототипирования или эксперимента, а не анализа. В этом случае три часа — это времи на создание минимального прототипа, а не на чтение документации. Главное: три часа без результата — это не «я не справился». Это «задача требует другого подхода». Используйте эту информацию. Итог: что делать прямо сейчас Если вы узнали в описании свои боли — попробуйте уже сегодня. Возьмите одну задачу, которая кажется простой, засеките три часа и посмотрите, что произойдёт. Скорее всего, одно из трёх: Вы сделаете её за три часа — и будете знать, что подобные задачи можно не переоценивать. Вы обнаружите скрытый объём — и сможете честно переоценить до того, как пообещали сроки заказчику. Вы поймёте, что задача требует другого подхода — и сэкономите команде дни переделок. Правило 3-часовой глубины — это не про скорость. Это про честность с собой и с командой. Про то, чтобы не обещать того, чего не понимаешь. Про то, чтобы тратить время на понимание там, где оно реально экономит время.
- Шаг 3. Встроите правило в процесс приёма задач Правило не работает, если о нём вспоминают постфактум. Его нужно встроить в момент, когда задача попадает в работу. Практический сценарий: когда задача приходит в работу, исполнитель получает три часа на «распаковку». За это время он обязан либо: Сделать задачу целиком (если она действительно простая). Чётко описать границы задачи: что входит, что не входит, какие есть неизвестные. Сказать: «Я потратил три часа, и вот что узнал» — и предложить следующий шаг. Третий вариант — самый ценный. Это не провал. Это результат. Вы за три часа получили информацию, которой не было до этого, и теперь можете принять решение с пониманием, а не вслепую. Как применять правило на практике Сценарий 1: Вы — исполнитель Вам пришла задача. Первое ощущение — «ну, на полчаса». Не доверяйте первому ощущению. Засеките три часа. В течение этого времени: Сделайте первый набросок решения или реализации. Запишите всё, что вызывает сомнения — каждое «не уверен», «надо проверить», «а что если». Если нашли больше двух пунктов в списке сомнений — остановитесь и идите к руководителю или заказчику. Цель — не сделать задачу за три часа. Цель — понять её реальный объём. Сценарий 2: Вы — руководитель или PM Когда команда даёт оценку, спросите: «Это оценка после трёх часов погружения или первое впечатление?» Если первое впечатление — отправляйте тратить три часа. Это не замедление, это экономия. Потому что потом переделывать всегда дольше, чем разобраться в начале. Ещё один приём: в планировании закладывайте «буфер глубины». Если команда оценила задачу в 2 дня, но это оценка без трёхчасового погружения — добавьте 30–50% сверху. Не как наказание, а как страховку от неизвестных, которые обязательно всплывут. Сценарий 3: Вы — фрилансер или консультант Клиент говорит: «Сделайте простую посадочную страницу». Вы знаете, что «простая» — самое опасное слово. Три часа вы тратите на интервью и анализ конкурентов, потом приходите с двумя вариантами: действительно простая страница за X часов, или страница с интеграцией CRM, аналитикой и адаптацией под 5 типов устройств за 3X часов. Клиент видит, что вы не раздуваете смету, а разбираетесь. Это доверие стоит больше, чем экономия на первом этапе. Частые ошибки при внедрении Ошибка 1: Превратить три часа в наказание Если команда воспринимает правило как «ты не справился за три часа — ты плохой», оно перестаёт работать. Три часа — это не дедлайн на задачу. Это дедлайн на понимание задачи. Если за три часа вы поняли, что задача огромная — это победа, а не провал. Ошибка 2: Использовать правило для абсолютно всех задач Не нужно тратить три часа на исследование задачи «поменять иконку». Правило применяется к задачам, где есть хотя бы один признак неопределённости: новые технологии, неясные требования, влияние на другие модули, участие нескольких людей. Ошибка 3: Не фиксировать результат трёх часов Если вы потратили три часа и просто пошли дальше «с чувством, что разобрались» — вы потеряли время. Результат трёх часов должен быть зафиксирован: короткий документ, комментарий в задаче, схема на доске. Что угодно, что можно показать другому человеку. Ошибка 4: Игнорировать результат и делать по-прежнему Самопасная ошибка. Команда потратила три часа, поняла, что задача — не два дня, а две недели, и всё равно взяла её в спринт на два дня «потому что дедлайн горит». Это не героизм, это путь к выгоранию и срыву сроков. Результат трёх часов должен менять решение. Когда правило работает лучше всего Правило 3-часовой глубины особенно ценно в следующих ситуациях: Новый проект или новая команда. Никто ещё не знает, где водятся подводные камни. Три часа на каждую задачу — это быстрый способ собрать карту рисков. Работа с легаси-кодом. Старый код всегда сложнее, чем кажется. Три часа на чтение и понимание — это не роскошь, это необходимость. Межкомандные зависимости. Когда ваша задача зависит от другой команды, три часа на согласование интерфейса экономят недели переделок. Инциденты и баги. Прежде чем чинить баг, потратьте час-полтора на понимание его реальной причины. Часто «баг» оказывается следствием архитектурной проблемы. Как внедрить правило в команду без сопротивления Любое новое правило в команде встречает скепсис. Вот как снизить сопротивление: Начните с добровольного эксперимента. Не объявляйте новое правило сверху. Попробуйте на себе в течение двух недель и покажите результат: «Вот эту задачу я взял за 2 дня, а потом две недели переделывал. А вот эту — потратил 3 часа на разбор, понял реальный объём, сделал за 5 дней без правок». Сделайте результат видимым. Заведите привычку: после трёх часов погружения писать короткий summary. Не отчёт — конкретику: «Задача X. Потрачено 3 часа. Результат: задача средней глубины, неизвестные — A и B. Предлагаю сделать C». Не привязывайте к KPI. Как только правило становится метрикой эффективности, оно начинает лукавить. Это инструмент качества, а не контроля. Обсудите на ретро. Через месяц применения спросите команду: «Где нам помогло остановиться на три часа? Где стоило бы остановиться, но не остановились?» Что делать, если три часа прошли, а понимания нет Это нормально — и это тоже результат. Если за три часа вы не смогли ни сделать задачу, ни очертить её границы, значит: Задача сформулирована слишком абстрактно. Нужно разбить на подзадачи и применить правило к каждой. Вам не хватает информации от других людей. Три часа — это сигнал: «Мне нужен разговор с экспертом / заказчиком / смежной командой». Задача требует прототипирования или эксперимента, а не анализа. В этом случае три часа — это времи на создание минимального прототипа, а не на чтение документации. Главное: три часа без результата — это не «я не справился». Это «задача требует другого подхода». Используйте эту информацию. Итог: что делать прямо сейчас Если вы узнали в описании свои боли — попробуйте уже сегодня. Возьмите одну задачу, которая кажется простой, засеките три часа и посмотрите, что произойдёт. Скорее всего, одно из трёх: Вы сделаете её за три часа — и будете знать, что подобные задачи можно не переоценивать. Вы обнаружите скрытый объём — и сможете честно переоценить до того, как пообещали сроки заказчику. Вы поймёте, что задача требует другого подхода — и сэкономите команде дни переделок. Правило 3-часовой глубины — это не про скорость. Это про честность с собой и с командой. Про то, чтобы не обещать того, чего не понимаешь. Про то, чтобы тратить время на понимание там, где оно реально экономит время.
- Как применять правило на практике
- Сценарий 1: Вы — исполнитель
- Сценарий 2: Вы — руководитель или PM
- Сценарий 3: Вы — фрилансер или консультант
- Частые ошибки при внедрении
- Ошибка 1: Превратить три часа в наказание
- Ошибка 2: Использовать правило для абсолютно всех задач
- Ошибка 3: Не фиксировать результат трёх часов
- Ошибка 4: Игнорировать результат и делать по-прежнему
- Когда правило работает лучше всего
- Как внедрить правило в команду без сопротивления
- Что делать, если три часа прошли, а понимания нет
- Итог: что делать прямо сейчас
Когда проект разрастается — сроки сжатых задач множатся, правки идут круглосуточно, а команда тонет в согласованиях, — проблема почти всегда одна: никто не знает, насколько задача реально глубока. Взялись «поправить заголовок», а через два дня переписывают половину экрана. Сказали «простая интеграция», а она потянула за собой переработку архитектуры.
Правило 3-часовой глубины — это не ещё один инструмент из учебника по менеджменту. Это практический фильтр, который помогает на старте задачи понять: насколько она действительно простая, и где прячется скрытый объём работы. Ниже — как его построить и как применять.
Что это за правило и зачем оно нужно
Суть простая: если задача действительно поверхностная, вы должны понять это за три часа максимум. Не за три дня, не за три недели — за три часа сфокусированной работы. Если за три часа вы не смогли либо сделать задачу, либо чётко очертить её границы — значит, она сложнее, чем казалась.
Три часа — это не магическое число. Это точка, в которой у вас достаточно информации для принятия решения, но ещё не накопился усталость и иллюзия прогресса. Вы либо уже видите всю картину, либо понимаете, что она размыта — и это сигнал остановиться и переоценить.
Почему без этого правила проекты разваливаются
В сложных проектах основная боль — не в больших задачах. Большие задачи хотя бы видны. Боль — в маленьких, которые притворяются маленькими.
Вот типичная цепочка:
- «Давайте добавим фильтр в каталог» — звучит на 20 минут.
- Через день выясняется, что фильтр должен работать с пятью типами товаров, у каждого своя логика.
- Потом оказывается, что фильтр нужно привязать к персонализации.
- Потом — что он должен работать в трёх вариантах для разных ролей пользователей.
- Итого: задача, которую оценили в полдня, раздулась до двух недель.
Проблема не в том, что фильтр сложный. Проблема в том, что на старте никто не потратил три часа на то, чтобы докопаться до реального объёма. Правило 3-часовой глубины — это привычка останавливаться в нужный момент и задавать себе вопрос: «Я уже понимаю, что делаю, или ещё нет?»
Как построить правило под ваш проект
Шаг 1. Определите, что значит «три часа» в вашем контексте
Три часа — это не три часа в календаре с перерывами на кофе и почту. Это три часа сфокусированной работы над конкретной задачей. Для разработчика это может быть один помодоро-цикл с перерывами. Для дизайнера — один сеанс исследования и набросков. Для менеджера — один блок без встреч, где можно разобрать требования.
Если ваша команда работает спринтами, три часа — это примерно половина одного рабочего дня. Если команда маленькая и нон-стоп в потоке — возможно, это утро одного дня. Главное: это непрерывный фокус на одной задаче.
Шаг 2. Зафиксируйте критерии «глубины»
Вам нужна простая шкала, которую команда понимает одинаково. Вот пример из практики:
| Уровень глубины | Что это значит | Пример | Действие |
| Поверхностный | Задача полностью понятна, решение очевидно, правки минимальны | Изменить цвет кнопки, поправить текст в шапке | Делайте сразу, не раздумывайте |
| Средний | Задача понятна в общих чертах, но есть 1–2 неизвестных, которые нужно проверить | Добавить валидацию формы с новыми правилами | Три часа на исследование — затем принимайте решение |
| Глубокий | Задача содержит более двух неизвестных, может повлиять на другие части системы | Переработать систему авторизации с добавлением новых провайдеров | Три часа на разведку — затем отдельная оценка и планирование |
| Разведочный | Задача сформулирована расплывчато, требует значительного исследования перед оценкой | «Улучшить производительность личного кабинета» | Три часа на диагностику — затем формулировка реальных задач |
Ключевой момент: эта шкала не для отчётности. Она для команды, чтобы все одинаково понимали, что значит «мы ещё не знаем, что делать».
Шаг 3. Встроите правило в процесс приёма задач
Правило не работает, если о нём вспоминают постфактум. Его нужно встроить в момент, когда задача попадает в работу.
Практический сценарий: когда задача приходит в работу, исполнитель получает три часа на «распаковку». За это время он обязан либо:
- Сделать задачу целиком (если она действительно простая).
- Чётко описать границы задачи: что входит, что не входит, какие есть неизвестные.
- Сказать: «Я потратил три часа, и вот что узнал» — и предложить следующий шаг.
Третий вариант — самый ценный. Это не провал. Это результат. Вы за три часа получили информацию, которой не было до этого, и теперь можете принять решение с пониманием, а не вслепую.
Как применять правило на практике
Сценарий 1: Вы — исполнитель
Вам пришла задача. Первое ощущение — «ну, на полчаса». Не доверяйте первому ощущению. Засеките три часа. В течение этого времени:
- Сделайте первый набросок решения или реализации.
- Запишите всё, что вызывает сомнения — каждое «не уверен», «надо проверить», «а что если».
- Если нашли больше двух пунктов в списке сомнений — остановитесь и идите к руководителю или заказчику.
Цель — не сделать задачу за три часа. Цель — понять её реальный объём.
Сценарий 2: Вы — руководитель или PM
Когда команда даёт оценку, спросите: «Это оценка после трёх часов погружения или первое впечатление?» Если первое впечатление — отправляйте тратить три часа. Это не замедление, это экономия. Потому что потом переделывать всегда дольше, чем разобраться в начале.
Ещё один приём: в планировании закладывайте «буфер глубины». Если команда оценила задачу в 2 дня, но это оценка без трёхчасового погружения — добавьте 30–50% сверху. Не как наказание, а как страховку от неизвестных, которые обязательно всплывут.
Сценарий 3: Вы — фрилансер или консультант
Клиент говорит: «Сделайте простую посадочную страницу». Вы знаете, что «простая» — самое опасное слово. Три часа вы тратите на интервью и анализ конкурентов, потом приходите с двумя вариантами: действительно простая страница за X часов, или страница с интеграцией CRM, аналитикой и адаптацией под 5 типов устройств за 3X часов.
Клиент видит, что вы не раздуваете смету, а разбираетесь. Это доверие стоит больше, чем экономия на первом этапе.
Частые ошибки при внедрении
Ошибка 1: Превратить три часа в наказание
Если команда воспринимает правило как «ты не справился за три часа — ты плохой», оно перестаёт работать. Три часа — это не дедлайн на задачу. Это дедлайн на понимание задачи. Если за три часа вы поняли, что задача огромная — это победа, а не провал.
Ошибка 2: Использовать правило для абсолютно всех задач
Не нужно тратить три часа на исследование задачи «поменять иконку». Правило применяется к задачам, где есть хотя бы один признак неопределённости: новые технологии, неясные требования, влияние на другие модули, участие нескольких людей.
Ошибка 3: Не фиксировать результат трёх часов
Если вы потратили три часа и просто пошли дальше «с чувством, что разобрались» — вы потеряли время. Результат трёх часов должен быть зафиксирован: короткий документ, комментарий в задаче, схема на доске. Что угодно, что можно показать другому человеку.
Ошибка 4: Игнорировать результат и делать по-прежнему
Самопасная ошибка. Команда потратила три часа, поняла, что задача — не два дня, а две недели, и всё равно взяла её в спринт на два дня «потому что дедлайн горит». Это не героизм, это путь к выгоранию и срыву сроков. Результат трёх часов должен менять решение.
Когда правило работает лучше всего
Правило 3-часовой глубины особенно ценно в следующих ситуациях:
- Новый проект или новая команда. Никто ещё не знает, где водятся подводные камни. Три часа на каждую задачу — это быстрый способ собрать карту рисков.
- Работа с легаси-кодом. Старый код всегда сложнее, чем кажется. Три часа на чтение и понимание — это не роскошь, это необходимость.
- Межкомандные зависимости. Когда ваша задача зависит от другой команды, три часа на согласование интерфейса экономят недели переделок.
- Инциденты и баги. Прежде чем чинить баг, потратьте час-полтора на понимание его реальной причины. Часто «баг» оказывается следствием архитектурной проблемы.
Как внедрить правило в команду без сопротивления
Любое новое правило в команде встречает скепсис. Вот как снизить сопротивление:
- Начните с добровольного эксперимента. Не объявляйте новое правило сверху. Попробуйте на себе в течение двух недель и покажите результат: «Вот эту задачу я взял за 2 дня, а потом две недели переделывал. А вот эту — потратил 3 часа на разбор, понял реальный объём, сделал за 5 дней без правок».
- Сделайте результат видимым. Заведите привычку: после трёх часов погружения писать короткий summary. Не отчёт — конкретику: «Задача X. Потрачено 3 часа. Результат: задача средней глубины, неизвестные — A и B. Предлагаю сделать C».
- Не привязывайте к KPI. Как только правило становится метрикой эффективности, оно начинает лукавить. Это инструмент качества, а не контроля.
- Обсудите на ретро. Через месяц применения спросите команду: «Где нам помогло остановиться на три часа? Где стоило бы остановиться, но не остановились?»
Что делать, если три часа прошли, а понимания нет
Это нормально — и это тоже результат. Если за три часа вы не смогли ни сделать задачу, ни очертить её границы, значит:
- Задача сформулирована слишком абстрактно. Нужно разбить на подзадачи и применить правило к каждой.
- Вам не хватает информации от других людей. Три часа — это сигнал: «Мне нужен разговор с экспертом / заказчиком / смежной командой».
- Задача требует прототипирования или эксперимента, а не анализа. В этом случае три часа — это времи на создание минимального прототипа, а не на чтение документации.
Главное: три часа без результата — это не «я не справился». Это «задача требует другого подхода». Используйте эту информацию.
Итог: что делать прямо сейчас
Если вы узнали в описании свои боли — попробуйте уже сегодня. Возьмите одну задачу, которая кажется простой, засеките три часа и посмотрите, что произойдёт. Скорее всего, одно из трёх:
- Вы сделаете её за три часа — и будете знать, что подобные задачи можно не переоценивать.
- Вы обнаружите скрытый объём — и сможете честно переоценить до того, как пообещали сроки заказчику.
- Вы поймёте, что задача требует другого подхода — и сэкономите команде дни переделок.
Правило 3-часовой глубины — это не про скорость. Это про честность с собой и с командой. Про то, чтобы не обещать того, чего не понимаешь. Про то, чтобы тратить время на понимание там, где оно реально экономит время.