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

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

Спасибо Александру Лучкову, его мысли в чате ассоциации аритекторов натолкнули меня на идею о написании этой статьи.

Анатомия двух миров

birth c online with no prescription needed blog writing service australia go here cialis 100 mg hap satn al https://reflectionsbodysolutions.com/doctor/buy-generic-viagra-in-germany/82/ essay introduction creator leo harlem gallo viagra https://shepherdstown.info/conclusion/make-introduction-paragraph-compare-contrast-essay/17/ ap rhetorical analysis essay template example source source link sildenafil and tadalafil drugs https://iaace.com/annual/uf-dissertation-formatting/92/ online generic viagra meds 24 7 viagra dosage for performance anxiety https://themauimiracle.org/bonus/amoxicillin-for-strep-throat-how-many-days/64/ meglio sildenafil o tadalafil source url conclusion on bullying essay 3 page essay examples go here death of a salesman critical essays gothic architecture essay topics https://stonecottagegardens.com/fda/does-insurance-cover-dapoxetine/14/ argumentative essay ap language examples 2008 78 buy azithromycin chlamydia treatment https://willcoxwinecountry.org/linkedin/how-write-resume/47/ does viagra make your pennis smaller source link best phd essay ghostwriters websites for university solve my statistics problem Исследовательские задачи

Представьте, что ваша команда получает задачу разработать новый алгоритм машинного обучения для распознавания аномалий в поведении пользователей. Никто в вашей компании раньше подобного не делал. Какие-то данные есть, но их структура неоднородна. Известные методы могут сработать, а могут и нет. Это классическая исследовательская задача – работа в условиях частично неизвестного контекста.

Ключевая характеристика таких задач — высокая неопределенность множества решений (Solution Space).

Вы не знаете заранее:

Сработает ли вообще выбранный подход
Сколько итераций потребуется до работающего прототипа
Какие скрытые технические ограничения всплывут в процессе

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

Типовые задачи

Теперь представьте другую ситуацию: вашей команде нужно интегрировать уже знакомую платежную систему в существующую информационную систему. Документация на API есть, технология знакома, аналогичные интеграции уже проводились. Риски понятны и ограничены. Это типовая задача — работа в полностью известном контексте.

Здесь применимы все классические методы оценки:

Оценка по аналогии
Декомпозиция задачи на подзадачи
Трехточечная оценка (оптимистичный, реалистичный, пессимистичный)
Статистический анализ исторических данных

Вероятность неожиданностей здесь низкая и измеримая. Главные риски связаны не с невозможностью решения, а с тем, что «что-то может пойти не так» в процессе выполнения (а эту вариативность мы снижаем за счет процессов).

Конус неопределенности

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

Проблема в том, что многие менеджеры не различают форму конуса для разных типов задач:

Для типовых задач конус узкий с самого начала – неопределенность быстро снижается после первичного анализа
Для исследовательских задач конус остается широким долгое время – неопределенность снижается только по мере получения конкретных результатов экспериментов

Именно поэтому попытка измерить время решения для исследовательской задачи на этапе планирования — это системная ошибка. Измерить можно, но не время решения, а уверенность в том, что решение будет найдено за некоторое время. Это уже не классическая оценка сроков, а построение спектра вероятностей по осям «решение / время»: распределение, показывающее вероятность нахождения решения за заданный промежуток времени.

Таким образом, в исследовательской задаче мы фактически оцениваем степень уверенности в собственной способности достичь решения в заданных условиях времени и ресурсов, а в типовой – напротив, предметом оценки становится вероятность отклонения от планового результата, то есть риск ошибки или неэффективного исполнения.

Практические инструменты

Критерии классификации задач

Прежде чем начать оценку, задайте себе вопросы:

Вопрос	Исследовательская задача	Типовая задача
Известны ли технические требования?	Частично или нет	Да
Делали ли мы это раньше?	Нет или очень давно	Да, недавно
Можем ли мы декомпозировать задачу на известные шаги?	Нет или с трудом	Да, легко
Известны ли внешние зависимости?	Частично или нет	Да
Есть ли рабочие аналоги (внутренние/внешние)?	Нет или неизвестно	Да

Если на 3+ вопроса ответ указывает на исследовательскую задачу – не пытайтесь дать точную оценку сроков.

А где же тогда граница перехода от исследовательской задачи к типовой? Здесь помогут принципы нечеткой логики. Вместо бинарного подхода — «понятно / непонятно» — целесообразно измерять степень ясности задачи в данный момент времени. То есть, оценивать, насколько текущие знания и контекст позволяют считать задачу уже осмысленной и поддающейся формализации.

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

Степень полноты контекста можно рассматривать как нечеткую величину, отражающую динамику накопления знаний командой в процессе решения задачи. Для ее описания целесообразно использовать функцию принадлежности — инструмент, показывающий, насколько состояние понимания в текущий момент соответствует состоянию «осмысленности» задачи.

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

Точками фазового перехода могут быть, например, – момент, когда появляется первая формализованная гипотеза, то есть переход от исследовательской растерянности к осмысленным экспериментам и момент, когда команда способна построить план реализации без фундаментальных неизвестных.

Ограничение по времени для исследовательских задач

В Agile-практиках существует концепция «spike» — специального типа задач для исследований с жестким ограничением по времени (timebox). Вместо оценки «когда будет готово» устанавливается бюджет времени на поиск решения.

Spike часто путают с Proof Of Concept (PoC), ниже сравнительная таблица, которая объясняет spike в сравнении с PoC:

Критерий	Спайк	PoC
Цель	Ответить на вопрос	Показать возможность
Время	Часы-дни	Недели-месяцы
Код (или иной артефакт)	Выбрасывается	Может стать основой
Фокус	Конкретное исследование	Широкая концепция
Результат	Знание	Прототип

Директивная оценка по ресурсам

Proof of Concept в действительно тоже исследовательская задача, но зачастую куда более масштабная, так что сравнение выше было представлено не просто так 🙂 Для PoC лучше подойдет оценка не по срокам, а по доступным ресурсам:

Определите, сколько времени команды вы готовы выделить на поиск решения (например, 1 квартал, 2 разработчика)
Так как это длительное исследование, чтобы не потерять контроль, определите контрольные точки
Определите, при каких условиях продолжать, при каких – останавливаться
Фиксируйте выводы, так как даже отрицательный результат – это ценное знание

Такой подход честно признает, что мы не знаем, получится ли у нас, но готовы потратить X ресурсов на попытку.

Вопрос культуры?

Главная проблема, как водится – не технологическая, а культурная. Во многих организациях признать неопределенность считается слабостью.

Тут есть несколько рекомендаций:

Легализовать неопределенность через создание процессов, через которые могут проходить исследовательские задачи. Нет процесса — нет «легального» способа работать с такими задачами.
Отделить Discovery от Delivery. Discovery оценивается по ресурсам, Delivery — по срокам.
Сравнивать план с фактом по оценке (например на ретро) и самое главное – выделять паттерны ошибок и менять систему так, чтобы с этими паттернами работать.

Выводы

Исследовательские и типовые задачи живут в разных вселенных планирования. Попытка применить статистические методы к исследованиям – это как пытаться измерить температуру линейкой. Инструмент не подходит для измеряемой величины.

Кому интересно взорвать себе мозг в части измерений подумайте о деньгах. Деньги – это одновременно и объект измерений и мера ценности которая к тому же постоянно меняется.

Для исследовательских задач управляйте ресурсами, а не сроками. Установите бюджет времени, определите контрольные точки, зафиксируйте критерии успеха.

Для типовых задач применяйте всю мощь статистики – декомпозицию, исторические данные, вероятностные оценки.

Спасибо, надеюсь было интересно и, главное, полезно 🙂