Всем привет! Меня зовут Евгения Красильникова, я технический писатель в команде Russtech (разработчики IT‑решений ведущего российского оператора рекламы вне дома Russ, входит в RWB). Сегодня я хочу рассказать, как мы пришли к единой системе оценки задач и с помощью нейросети создали удобной инструмент, который помог ввести подсчет наших трудозатрат и заметно оптимизировал рабочие процессы.

С чего все началось

По мере роста команды технических писателей и появления новых проектов мы стали замечать, что нам не хватает понимания общей загрузки в коллективе. То есть задачи есть, работа идет, но при этом не совсем ясно, кто насколько занят, равномерно ли распределяются задачи и хватает ли нам текущего состава команды. Возник вопрос: а как вообще понять, когда нам действительно нужно усиливаться и открывать новые вакансии, а не делать это уже в момент, когда все перегружены?

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

Выработка общих критериев

Изначально у нас не было каких‑то единых правил, каждый оценивал задачу так, как сам понимает и чувствует. Кто‑то ориентировался на объем изменений, кто‑то на то, сколько времени по ощущениям это займет. В итоге у всех складывалось свое понимание, что значит простая задача, а что сложная. Формально это выглядело так: чем меньше оценка — тем легче работа, чем больше — тем сложнее. Но что именно стоит за этой сложностью, в чем она измеряется и на что опираться при оценке, общего понимания не было.

Решив привести все к единой логике, мы в первую очередь стали анализировать, на что у нас уходит время при выполнении задач. Если разобрать работу технического писателя, то становится понятно, что основные трудозатраты складываются из двух вещей.

• Первая — это время, которое тратит технический писатель на то, чтобы разобраться, понять, как работает функционал, что именно нужно описать. И здесь уровень сложности очень разный: иногда все понятно сразу из задачи, иногда достаточно посмотреть интерфейс, протестировать, иногда — изучить требования или техническую документацию, а иногда — идти к разработчику или аналитику за разъяснениями, потому что самостоятельно разобраться невозможно или есть противоречия.

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

Таким образом, у нас появилось два критерия оценки задач: объем изменений и уровень исследования.

Как мы разложили оценку на конкретные уровни

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

В итоге получилось по пять уровней для каждого критерия:

• V1–V5 — для объема изменений;

• R1–R5 — для уровня исследования.

Мы обозначили параметры буквами V и R, чтобы было удобно работать с комбинациями. V — это объем изменений (Volume), R — уровень исследования (Research).

Объем изменений

Уровень исследования

Это не какие‑то строгие математические границы, а скорее понятные категории, в которые укладывается большинство задач. Дальше мы просто зафиксировали эти уровни и начали рассматривать их сочетания. По сути, каждая задача стала описываться комбинацией двух параметров: например, V2 + R3 или V4 + R1. И уже на основе этих комбинаций определялась сложность задачи и ее оценка по времени.

Итоговая логика оценивания

Дальше нужно было понять, какие значения давать этим комбинациям, то есть как определить сложность задачи и сколько времени она занимает.

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

Получилась такая матрица.

Важно, что это не точный расчет, а ориентир. Он нужен не для того, чтобы угадать время до часа, а чтобы все задачи оценивались по одной и той же логике. И что не менее важно, эта модель не зафиксирована навсегда. Когда начнет накапливаться фактическое время по задачам, ее можно будет пересматривать и уточнять.

Почему одной матрицы оказалось недостаточно

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

Поэтому появилась задача не просто сделать систему оценки, а сделать ее максимально удобной в использовании. И здесь возникла идея трансформировать эту матрицу в простой инструмент. Чтобы не нужно было смотреть в таблицу, а можно было просто выбрать параметры и сразу получить результат.

Как мы превратили систему оценки в умный помощник

Дальше встал вопрос, как реализовать на практике применение системы оценки. Задача достаточно рутинная, поэтому мы решили попробовать сделать это с помощью искусственного интеллекта. Мы описали идею, как должен работать инструмент, передали саму матрицу с комбинациями, сложностью и оценками и попросили сгенерировать HTML‑код калькулятора.

После этого уже шел обычный процесс общения: что‑то дорабатывали, уточняли, правили формулировки и логику. Но в итоге получили рабочий код. Затем мы встроили его в онлайн‑систему для совместной работы команды. В системе есть HTML‑макрос, в который можно вставить код, — и при просмотре страницы отображался уже не код, а готовый интерфейс.

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

Технический писатель выбирает нужные значения, и калькулятор автоматически:

• показывает уровень сложности задачи;

• дает ей первоначальную оценку в часах.

Дальше остается просто перенести эти значения в задачу.

Где еще можно применять такую логику

В целом этот инструмент довольно простой. Это не какая‑то сложная система, а скорее первый опыт попробовать самостоятельно превратить идею в рабочий инструмент без привлечения разработки.

В процессе стало понятно, что ценность здесь не только в самом калькуляторе. Главное — это подход. По сути, есть несколько параметров, которые влияют на результат, есть понятная логика и есть простой инструмент, который эту логику применяет.

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

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

Например:

• при приоритизации задач — если задать параметры вроде срочности и влияния;

• при оценке рисков — через вероятность и последствия;

• при определении уровня специалиста — через навыки, самостоятельность и сложность задач;

• в обучении — когда нужно понять, в каком порядке давать материал.

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