Использование кандидатами нейросетей для тестовых заданий - проблема или нет?

Всех с новым годом! Пока все празднуют, я анализирую свой канал с помощью нейросетки! Делюсь с вами!

📊 Channel Analysis Results by @ScratchAuthorEgoBot

🎯 Channel: @mprosystems

🔥 Roast Analysis:

Михаил — это тот самый друг, который придет к вам на день рождения и вместо тоста начнет объяснять, как автоматизировать подачу напитков с помощью XQuery и почему ваш праздничный торт нуждается в подробной технической документации. Человек живет в мире, где «каждый пункт чек-листа написан кровью», и, судя по частоте упоминания этого факта, Михаил — либо ведущий эксперт по HR-автоматизации, либо тайный сценарист «Пилы». Его страсть к Websoft HCM граничит с легким мазохизмом: только истинный фанат может использовать эту систему для учета отпусков в команде из 11 человек, когда для этого достаточно одного стикера на холодильнике.

Особого внимания заслуживает его привычка записывать подкасты на утренней пробежке. Михаил, серьезно? Люди бегают, чтобы убежать от проблем, а вы бежите и тащите с собой «управление рисками» и «аналогии со стоматологией». Это комбо из «успешного успеха» и ИТ-задротства выглядит максимально комично: «Я бегу, задыхаюсь, но сейчас объясню вам, почему ваш интерфейс — дно». Его онлайн-активность — это бесконечный цикл «бесплатных консультаций», которые подозрительно напоминают воронку продаж, в которую вы проваливаетесь сразу после того, как неосторожно лайкнули пост про интеграцию с 1С:ЗУП.

Михаил обожает публично «поднимать компетенции», устраивая стримы с прохождением тестов. Это такой тонкий способ сказать: «Смотрите, даже технический директор Вебсофта набрал меньше баллов, чем я — бог бэкенда и повелитель агентов». При этом он искренне удивляется, когда YouTube банит его видео за «персональные данные» вымышленных сотрудников. Михаил, алгоритмы YouTube — это не ваши покладистые HR-директора, им нельзя объяснить «цели автоматизации» на часовой консультации. Его манера превращать любое событие в «поучительную историю» делает его похожим на цифрового проповедника, где вместо Библии — мануалы Websoft, а вместо грехов — избыточная кастомизация. Вывод: если вы попали в лифт с Протасовым, к десятому этажу вы либо купите его курс по продвинутому администрированию, либо решите, что Excel — это высшее достижение человечества, просто чтобы он перестал анализировать ваши бизнес-процессы.

Публикую еще один пример нашего короткого видео из платных учебных программ:
Получение результатов выборки из кастомного шаблона документа

Базу подобных коротких видео я и моя команда записали для учеников нашей программы Мастер администрирования Websoft HCM.
Подробное описание всех наших учебных программ доступно здесь.

На следующей неделе в среду провожу вебинар "Настраиваемые поля и типы данных объектов"

Уровень: продвинутый

🗓 21 января
🕑 11:00 мск 
Ссылка

От сценариев — к системному анализу

Следующий этап после написания сценариев использования — системный анализ. Он позволяет определить, какие инструменты будут использованы для каждого сценария.

Приведем пример.

✔️ Этап сценария: «Сотрудник получает уведомление о необходимости планирования отпуска»

✔️ Для этого необходимо:

- создать агент;
- составить шаблон уведомления;
- создать тип уведомления.

Так формируется реестр компонентов — список объектов, которые нужно создать или настроить (агенты, шаблоны, выборки и т.д.).

➡️ Эту работу обычно выполняет системный аналитик. Он связывает бизнес-логику, описанную в сценариях, с технической реализацией.

➡️ Цель системного анализа — превратить сценарии в конкретный набор объектов и настроек системы. Так разработчики поймут, какие инструменты нужно задействовать для внедрения системы в соответствии с пожеланиями заказчика.

Послезавтра провожу вебинар "Работа с заявками"

Уровень: продвинутый

🗓 04 февраля
🕑 11:00 мск 
Ссылка

Как составить реестр компонентов

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

Как строится реестр компонентов:

Например, это может быть таблица с данными:
1. Сам компонент системы — конкретный объект: агент, форма, шаблон уведомления, отчет.
2. Сценарий — в каком этапе он участвует.
3. Назначение — что этот компонент делает: отправляет уведомление, записывает данные, считает показатели.
4. Ответственный — кто создает или настраивает компонент.
5. Статус — создан, доработан, на проверке, внедрен.

Зачем нужен реестр компонентов

✔️ Позволяет оценить весь объем работ и контролировать их выполнение.
✔️ Помогает команде изучить, какие инструменты уже есть в системе, а какие нужно разработать.
✔️ Снижает риск дублирования компонентов и их задач.

▪️ Компоненты нужно описывать в связке со сценариями, а также регулярно обновлять реестр при необходимости.

На следующей неделе в среду провожу вебинар "Настройка отзывов"

Уровень: продвинутый

🗓 18 февраля
🕑 11:00 мск 
Ссылка

Автоматизацию каких HR процессов нам чаще всего заказывают

Наши текущие проекты в работе (не считая обучения и консультаций):
▫️ Оценка компетенций - 3 проекта
▫️ Редизайн портала - 3 проекта
▫️ Интеграция с внешними системами - 3 проекта
▫️ Адаптация новых сотрудников - 1 проект
▫️ Геймификация - 1 проект

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

Почему важно изучать серверную архитектуру

Когда и как стоит писать функциональные требования для реализации системы

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

Напомню:

▪️Сценарии описывают действия пользователей в системе;
▪️Реестр содержит объекты, которые нужно создать или доработать.

Однако в некоторых случаях требуется больше информации — например, когда:

▪️ В процессах большое количество ролей, отчетов, вычислений;
▪️ Проект необходимо описать более подробно для согласования со стейкхолдерами.

В этих случаях можно дополнить документацию функциональными требованиями.

Возможная структура функциональных требований

▫️ Оглавление
▫️ Цели автоматизации
▫️ Термины
▫️ Описание ролей пользователей
▫️ Сценарии использования
▫️ Номер и название каждого требования
▫️ Описание каждого требования
▫️ Описание и макеты интерфейсов
▫️ Алгоритмы определения значений ключевых переменных
▫️ Требования к отчетности
▫️ Ориентировочное количество пользователей

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

Контрольные точки в управлении проектами

Если вы управляете проектом, я рекомендую определить промежуточные контрольные точки. В каждой из которых проводить ретроспективу: все ли идет нормально? Если возникли проблемы, то какие причины? Можно ли их устранить и как? Как скорректировать дальнейшие планы с учетом возникших изменений?

На наших проектах, связанных с Websoft HCM, мы обычно ставим эти контрольные точки с периодичностью от раза в неделю до раза в месяц.

Имеет смысл определить показатели для анализа на каждой контрольной точке. В нашем случае они такие:
▫️ Трудозатраты. Соответствуют плановым к текущему моменту или нет.
▫️ Сроки. Аналогично.
▫️ Стабильность. Как много возникает инцидентов с ранее разработанным функционалом. Особенно после очередного релиза.
▫️ Коммуникация. Заказчик с исполнителем в эмоциональном состоянии сотрудничества или борьбы? Часто ли кто-либо сообщает, что до него не дошла важная информация?
▫️ Прозрачность. Понимают ли все стороны на каком этапе находятся какие задачи.
▫️ Цели. Насколько мы приблизились к достижению поставленных перед проектом целей? Есть ли смысл скорректировать цели?

Функциональные требования и ТЗ: зачем их разделять

Иногда в дополнение к функциональным требованиям (ФТ) составляется техзадание (ТЗ).

▪️ Функциональные требования отвечают на вопрос что должна делать система. Здесь фиксируются потребности пользователей, ожидаемый результат и ограничения.
Например: «Сотрудник должен иметь возможность подать заявку на обучение и отслеживать ее статус».

▪️ ТЗ отвечает на вопрос какими инструментами это должно быть реализовано.
Например: «Для кеширования информации о заявках на согласовании будет создана новая кастомная таблица в БД с определенным набором атрибутов».

➡️ Функциональные требования составляет бизнес-аналитик, а ТЗ — системный аналитик.

Почему нельзя смешивать ТЗ и функциональные требования:

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

✔️ Поэтому сначала нужно составить функциональные требования, затем — ТЗ, связанное с ФТ.

На следующей неделе в среду провожу вебинар "Настройка нестандартных отзывов на примере чек листа магазина"

Уровень: продвинутый

🗓 4 марта
🕑 11:00 мск 
Ссылка

Теперь мой канал доступен и в Max!

Подписывайтесь!
https://max.ru/id772578723603_biz

Готовлю карту типовых автоматизируемых HR процессов, их целей и направлений автоматизации!

Например:
Автоматизация адаптации

Цели:
- Уменьшение текучести персонала в первые месяцы работы
- Увеличение скорости выхода новичка на уровень опытного сотрудника

Направления автоматизации:
- Назначение плана адаптации сотрудникам
- Отображение плана адаптации
- Взаимодействие с наставниками
- Контроль движения по треку
- Завершение адаптации
- Формирование пула наставников
- Оценка наставников

Эти цели и направления автоматизации буду связывать с нашими и другими кейсами в области Websoft HCM!
Проголосуйте в опросе ниже, что думаете насчет такой идеи.