Система оценки эффективности сотрудников

Performance Evaluation помогает руководителю оценивать работу команды по данным из Kaiten: срокам, возвратам, плановым и фактическим трудозатратам, статусам задач и принадлежности сотрудников к отделам.

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

Для этого я спроектировал отдельный аналитический интерфейс поверх данных Kaiten. Система забирает информацию из задач, рассчитывает оценку от 0 до 100 и показывает её на трёх уровнях: компания, отдел, сотрудник.

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

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

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

Я проектировал MVP как продуктовую систему: определял логику расчёта, структуру разделов, пользовательские сценарии, состояния интерфейса и правила работы с данными.

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

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

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

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

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

Отдельные карточки метрик показывают вклад каждого показателя в итоговый балл. В примере видно, что точность оценки и возвраты находятся в зелёной зоне, а дедлайны сильно снижают общий результат. Руководителю не нужно вручную сопоставлять цифры: интерфейс сразу показывает сильные и проблемные зоны.

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

Карточка сотрудника

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

Верхние карточки помогают быстро понять состояние отдела. В примере фронтенд-команда получает 73 из 100: общий показатель находится в нормальной зоне, но соблюдение сроков просело до 49. Такой расклад сразу показывает, где искать причину снижения оценки.

Ниже я вывел график динамики за последние 6 месяцев. Руководитель видит, как менялась эффективность отдела, и может сравнить текущий месяц с предыдущими периодами. Это помогает отличить разовый спад от повторяющейся проблемы.

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

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

Дашборд отдела

Для системы оценки я спроектировал отдельный раздел с методологией. Он объясняет, как формируется итоговый балл сотрудника и какие данные участвуют в расчёте.

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

Отдельно я описал веса метрик. Точность оценки трудозатрат получила 40%, возвраты задач — 35%, дедлайны — 25%. Такая структура показывает приоритеты системы: важнее всего планирование, затем качество выполнения и соблюдение сроков.

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

Ниже раскрывается каждая метрика: что она измеряет, по какой формуле считается и как переводится в балл от 0 до 100. Это нужно, чтобы руководитель мог проверить оценку, объяснить её сотруднику и понять, какие действия реально повлияли на результат.

Методология расчёта

Я вынес логику отчётных периодов в отдельный раздел, чтобы пользователь понимал, как система хранит задачи, считает метрики и сравнивает месяцы между собой.

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

Я разделил периоды на три состояния: текущий, открытый прошлый и закрытый. В текущем и открытом периоде задачи можно редактировать. В закрытом периоде данные замораживаются, поэтому прошлые оценки не меняются после пересчёта или правок.

Отдельно я зафиксировал правило привязки задачи к периоду. Задача относится к месяцу по дедлайну, а не по дате создания или закрытия. Если дедлайн стоит на март, задача попадает в мартовский период, даже если её закрыли в апреле. Это помогает учитывать просрочку там, где её ожидали увидеть в плане работ.

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

Логика периодов

Для MVP я спроектировал раздел администрирования, где настраивается источник данных и подключение к Kaiten API.

Пользователь может выбрать, откуда система берёт задачи: из локальных моковых данных или из реального пространства Kaiten. Моковые данные нужны для демонстрации и проверки интерфейса без внешних сервисов. Kaiten используется для работы с реальными задачами команды.

Подключение к Kaiten вынесено в отдельный блок. Администратор указывает URL пространства и API-токен, после чего система может получать данные о задачах, сотрудниках, сроках, статусах и трудозатратах.

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

Отдельно предусмотрел настройки отображения: название компании можно изменить прямо в интерфейсе. Ниже показал техническую информацию о версии системы, бэкенде, фронтенде и порте API. Это помогает быстро проверить окружение при развёртывании и тестировании MVP.

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

Администрирование

В результате я собрал рабочий MVP аналитической системы, которая помогает руководителю оценивать сотрудников по данным из Kaiten. Продукт показывает общую картину по компании, позволяет провалиться в отдел, открыть карточку сотрудника и проверить, какие задачи повлияли на итоговую оценку.

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

Отдельно этот проект стал для меня практикой работы с нейросетями в продуктовой разработке. Я использовал AI не как замену проектированию, а как инструмент ускорения: декомпозировал задачи через промпты, описывал сценарии, проверял сгенерированные решения, дорабатывал логику и собирал интерфейс в связанную систему.

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