Специалист по информационным системам работает на пересечении технологий, бизнеса и людей. Это означает, что задачи – самые разные: от проектирования архитектуры до объяснения технического долга директору, который слышал это слово впервые. Промпты для специалиста по информационным системам способны закрыть большую часть рутины быстрее, чем кажется.
Но есть одна типичная проблема: большинство специалистов используют нейросети так же, как поисковик – вводят короткий запрос и удивляются, почему результат размытый. Это не вина инструмента.
В этой статье – 29 готовых рабочих запросов для нейросети, каждый из которых заточен под реальные задачи специалиста по ИС. Вот что здесь найдете:
- Проектирование и документирование систем
- Анализ требований и работа с заказчиками
- Оценка рисков и технического долга
- Написание технических заданий и регламентов
- Интеграции, миграции и архитектурные решения
- Подготовка отчетов и презентаций для руководства
- Работа с командой и постановка задач разработчикам
Каждый промпт сопровождается объяснением: почему именно такая структура дает нужный результат, а не просто «хороший текст ни о чем».
29 промптов для специалиста по информационным системам
1. Составление технического задания на разработку модуля
Проблема: Техническое задание пишется «по памяти» и интуиции, в итоге разработчики понимают его каждый по-своему, а приемка превращается в переговоры о том, что вообще имелось в виду.
Решение: Промпт формирует структурированное техническое задание с обязательными разделами, которые закрывают типичные пробелы в понимании между заказчиком и исполнителем.
Текст промпта:
*****
Ты – опытный системный аналитик с практикой составления технических заданий по ГОСТ 34 и корпоративным стандартам.
Задача: составь техническое задание на разработку программного модуля на основе исходных данных, которые я предоставлю.
Контекст: [опишите систему и модуль, например, «модуль управления заявками в корпоративной ERP-системе на базе 1С:Предприятие»].
Исходные данные для ТЗ:
– Назначение модуля: [укажите, например, «автоматизация приема и маршрутизации заявок от сотрудников»]
– Пользователи системы: [укажите роли, например, «сотрудник, руководитель отдела, администратор»]
– Ключевые функции: [перечислите, например, «создание заявки, назначение исполнителя, уведомление по электронной почте, история изменений»]
– Интеграции с другими системами: [укажите, например, «Active Directory для авторизации, почтовый сервер для уведомлений»]
– Ограничения и требования: [укажите, например, «работа на серверах под управлением Windows Server 2019, без использования облачных сервисов»]
Структура ТЗ:
- Общие сведения (назначение, область применения)
- Требования к функциям и задачам системы
- Требования к интерфейсу
- Требования к надежности и безопасности
- Требования к документации
- Порядок приемки
Формат: деловой, точный, без лишних слов. Каждый раздел – отдельным блоком с заголовком. Объем – достаточный для однозначного понимания разработчиком без дополнительных уточнений.
Чего избегать: размытых формулировок («система должна быть удобной»), субъективных оценок, требований без критерия проверки.
*****
Почему это работает: Структура по ГОСТ 34 сразу задает нейросети профессиональный фрейм, а перечень конкретных переменных не позволяет ей уйти в общие фразы – каждый раздел привязан к реальным данным проекта.
2. Анализ требований заказчика и выявление противоречий
Проблема: Заказчик формулирует требования в свободной форме, часть из них противоречит друг другу или техническим ограничениям – и это обнаруживается уже в процессе разработки, когда переделывать дорого.
Решение: Промпт проводит структурированный анализ требований и выявляет противоречия, пробелы и неоднозначности до начала работ.
Текст промпта:
*****
Ты – системный аналитик с опытом работы с требованиями в крупных государственных и коммерческих проектах.
Задача: проанализируй список требований заказчика, выяви противоречия, неоднозначности, пробелы и технически нереализуемые пожелания.
Требования заказчика: [вставьте текст требований или их перечень, например, «система должна работать без интернета и одновременно синхронизироваться с облаком в реальном времени; доступ должен быть у всех сотрудников, но только авторизованные могут видеть данные»]
Технические ограничения проекта: [укажите, например, «инфраструктура – локальная сеть предприятия, бюджет ограничен, срок – 4 месяца»]
Проведи анализ по четырем блокам:
- Противоречия – требования, которые исключают друг друга
- Неоднозначности – формулировки, которые можно трактовать по-разному
- Пробелы – важные аспекты, о которых заказчик не упомянул, но они критичны
- Технические риски – требования, реализация которых вызывает сомнения в рамках указанных ограничений
Для каждого пункта: укажи суть проблемы и сформулируй уточняющий вопрос к заказчику.
Тон: профессиональный, без оценочных суждений о компетентности заказчика. Цель – помочь, а не указать на ошибки.
*****
Почему это работает: Разбивка на четыре конкретных блока заставляет нейросеть работать методично, а не выдавать общий «список замечаний» – каждое наблюдение привязано к категории и завершается практическим вопросом.
3. Описание архитектуры информационной системы для нетехнической аудитории
Проблема: Руководство и заказчики не понимают технических объяснений архитектуры, что приводит к недоверию к проекту и сложностям с согласованием бюджета.
Решение: Промпт переводит техническое описание архитектуры на язык бизнес-ценностей и понятных аналогий.
Текст промпта:
*****
Ты – технический писатель и архитектор информационных систем с опытом презентации сложных решений совету директоров и государственным заказчикам.
Задача: преобразуй техническое описание архитектуры информационной системы в понятное объяснение для нетехнической аудитории.
Техническое описание: [вставьте исходный текст или схему архитектуры, например, «трехзвенная архитектура: клиентское приложение на Windows Forms, сервер приложений на .NET 6, база данных PostgreSQL, взаимодействие через REST API»]
Аудитория: [укажите, например, «финансовый директор и руководители подразделений, которые будут использовать систему»]
Цель объяснения: [укажите, например, «получить одобрение бюджета на следующий этап разработки»]
Структура объяснения:
- Что это за система и зачем она нужна (1–2 абзаца)
- Как она устроена – через понятную аналогию (без технических терминов)
- Почему выбрано именно такое решение – конкретные преимущества для бизнеса
- Что это значит для пользователей на практике
Ограничения: никаких аббревиатур без расшифровки, никаких слов «микросервис», «API», «фреймворк» без объяснения. Если термин необходим – объясни в скобках одним предложением.
Тон: уверенный, деловой, уважительный к аудитории.
*****
Почему это работает: Явное указание аудитории и цели объяснения переключает нейросеть с режима «технической документации» в режим «убеждающей коммуникации» – это принципиально разные задачи с разным результатом.
4. Оценка технического долга системы
Проблема: Технический долг накапливается незаметно, и когда его становится много, объяснить руководству, почему система «тормозит» и «падает», уже сложно – потому что нет структурированного описания проблем.
Решение: Промпт формирует структурированный реестр технического долга с приоритизацией и оценкой последствий.
Текст промпта:
*****
Ты – архитектор информационных систем с опытом аудита корпоративного программного обеспечения и оценки технического долга.
Задача: на основе предоставленного описания системы сформируй структурированный реестр технического долга с оценкой приоритетов и последствий.
Описание системы: [опишите систему, например, «корпоративная система документооборота, разработана в 2014 году, работает на устаревшей версии фреймворка, база данных не индексирована, документация отсутствует, часть кода не покрыта тестами, интеграции реализованы через прямые запросы к базе данных сторонних систем»]
Известные проблемы: [перечислите, например, «периодические зависания при пиковой нагрузке, сложность внесения изменений, отсутствие журналирования ошибок»]
Для каждого элемента технического долга укажи:
– Суть проблемы (что именно не так)
– Последствия: технические и бизнесовые
– Приоритет устранения: критический / высокий / средний / низкий
– Ориентировочная сложность устранения: низкая / средняя / высокая
Итог: сводная таблица и краткое резюме для руководства (3–5 предложений) о состоянии системы и рекомендуемых первых шагах.
Тон: объективный, без алармизма, но с четкими формулировками последствий бездействия.
*****
Почему это работает: Требование указать и технические, и бизнесовые последствия для каждого пункта превращает технический список в управленческий инструмент – руководство получает не «список проблем программистов», а обоснование для принятия решений.
5. Разработка плана миграции данных
Проблема: Миграция данных воспринимается как «перенос файлов», а не как сложный процесс с рисками потери, искажения и несовместимости – и план пишется задним числом, когда уже что-то пошло не так.
Решение: Промпт создает детальный план миграции с этапами, контрольными точками и процедурами отката.
Текст промпта:
*****
Ты – специалист по информационным системам с опытом реализации проектов миграции данных в государственных и коммерческих организациях.
Задача: разработай детальный план миграции данных из исходной системы в целевую.
Параметры миграции:
– Исходная система: [укажите, например, «Microsoft Access 2010, база данных кадрового учета, ~50 000 записей»]
– Целевая система: [укажите, например, «1С:Зарплата и управление персоналом 8.3»]
– Объем данных: [укажите, например, «данные за 10 лет, включая историю начислений, личные карточки сотрудников, приказы»]
– Критичность данных: [укажите, например, «высокая – данные используются для расчета пенсий и налоговой отчетности»]
– Допустимое время простоя системы: [укажите, например, «не более 4 часов в нерабочее время»]
Структура плана:
- Предварительная подготовка (аудит данных, выявление несоответствий форматов, создание резервных копий)
- Этапы миграции с указанием последовательности и зависимостей
- Контрольные точки проверки корректности данных
- Процедура отката при обнаружении критических ошибок
- Приемочное тестирование после миграции
- Риски и способы их снижения
Формат: структурированный документ с нумерацией этапов и четкими критериями перехода к следующему этапу.
Чего избегать: игнорирования рисков потери данных, отсутствия процедуры отката, размытых формулировок этапов.
*****
Почему это работает: Обязательное включение процедуры отката и контрольных точек заставляет нейросеть мыслить не только «как перенести», но и «что делать, если что-то пошло не так» – это принципиальная разница между планом и реальным рабочим документом.
6. Составление регламента работы с информационной системой
Проблема: Регламенты пишутся один раз, кладутся в папку и не читаются – потому что они длинные, абстрактные и не отвечают на реальные вопросы пользователей.
Решение: Промпт создает пользователецентричный регламент, организованный вокруг типичных рабочих ситуаций, а не разделов системы.
Текст промпта:
*****
Ты – методолог и технический писатель с опытом разработки эксплуатационной документации для корпоративных информационных систем.
Задача: составь регламент работы пользователей с информационной системой, организованный вокруг типичных рабочих ситуаций.
Система: [опишите систему, например, «система электронного документооборота на базе ТЕЗИС, используется в муниципальном учреждении»]
Категории пользователей: [перечислите, например, «делопроизводитель, руководитель отдела, исполнитель по документу, администратор системы»]
Типичные рабочие ситуации: [перечислите, например, «регистрация входящего документа, создание поручения, контроль исполнения, согласование проекта документа, поиск документа в архиве»]
Структура регламента:
- Назначение документа и область применения
- Роли и права доступа (кто что может делать)
- Типичные рабочие сценарии – для каждого: пошаговое описание действий, возможные ошибки и как их исправить
- Что делать в нестандартных ситуациях (система недоступна, ошибка при сохранении и т.д.)
- Контакты технической поддержки и порядок обращения
Требования к тексту: каждый шаг – одно действие, никаких абзацев-простыней, скриншоты заменить описанием «[здесь будет скриншот]». Язык – понятный рядовому сотруднику без технического образования.
Тон: нейтральный, инструктивный, уважительный.
*****
Почему это работает: Организация вокруг рабочих сценариев, а не разделов интерфейса, означает, что пользователь открывает регламент и сразу находит ответ на свой вопрос – именно поэтому такие документы читают, а не кладут в папку.
7. Подготовка технического отчета о состоянии информационной инфраструктуры
Проблема: Технические отчеты либо слишком детальны для руководства, либо слишком поверхностны для технических специалистов – и в итоге не используются никем.
Решение: Промпт формирует двухуровневый отчет: краткое резюме для руководства и технические детали для специалистов.
Текст промпта:
*****
Ты – ведущий специалист по информационным системам с опытом подготовки управленческой и технической отчетности.
Задача: составь технический отчет о состоянии информационной инфраструктуры организации на основе предоставленных данных.
Данные для отчета: [вставьте исходные данные, например, «серверное оборудование: 3 сервера, средний возраст 7 лет; сетевое оборудование: коммутаторы 2015 года; программное обеспечение: Windows Server 2012 R2 (поддержка прекращена), 1С:Предприятие 8.2; резервное копирование: ежедневное, хранение 30 дней; инциденты за последний квартал: 4 критических, 12 некритических»]
Структура отчета:
Блок 1 – Резюме для руководителя (1 страница):
– Общая оценка состояния (светофорная система: зеленый/желтый/красный)
– Ключевые риски в понятных формулировках
– Рекомендуемые приоритетные действия с обоснованием
Блок 2 – Технические детали для специалистов:
– Состояние каждого компонента инфраструктуры
– Выявленные уязвимости и несоответствия требованиям
– Детальные рекомендации с техническими параметрами
Период отчета: [укажите, например, «3-й квартал 2025 года»]
Формат: деловой документ с четкой структурой. Резюме – без технических аббревиатур. Технический блок – с конкретными параметрами и версиями.
Тон: объективный, без преувеличений, с четкими формулировками рисков.
*****
Почему это работает: Двухблочная структура решает проблему разных аудиторий в одном документе – руководитель читает резюме и понимает суть, специалист погружается в детали, и каждый получает то, что ему нужно.
8. Описание требований к интеграции двух систем
Проблема: Требования к интеграции формулируются на уровне «система А должна передавать данные в систему Б» – и это оставляет разработчикам слишком много пространства для интерпретации, которая всегда оказывается неверной.
Решение: Промпт создает детальное техническое описание интеграции с форматами данных, протоколами и обработкой ошибок.
Текст промпта:
*****
Ты – системный архитектор с опытом проектирования интеграций между корпоративными информационными системами.
Задача: разработай детальное описание требований к интеграции двух систем.
Системы:
– Система-источник: [опишите, например, «1С:Бухгалтерия 8.3, данные о платежных поручениях»]
– Система-получатель: [опишите, например, «система бюджетного планирования на базе собственной разработки, работает на PostgreSQL»]
Данные для передачи: [перечислите, например, «номер платежного поручения, дата, сумма, статья затрат, контрагент, статус исполнения»]
Бизнес-требования: [укажите, например, «передача данных в течение 15 минут после проведения документа в 1С, без ручного вмешательства оператора»]
Структура описания требований к интеграции:
- Схема взаимодействия (направление, инициатор передачи)
- Протокол и формат передачи данных
- Частота и триггеры передачи
- Формат данных (поля, типы, обязательность)
- Правила трансформации данных (если форматы отличаются)
- Обработка ошибок и недоступности систем
- Журналирование и мониторинг
- Требования к безопасности передачи
Формат: технический документ, пригодный для передачи команде разработки без дополнительных уточнений.
Чего избегать: описания без конкретных форматов и протоколов, игнорирования сценариев ошибок.
*****
Почему это работает: Явное требование описать обработку ошибок и сценарии недоступности систем закрывает самую частую дыру в документации интеграций – то, что происходит, когда что-то идет не по плану.
9. Разработка матрицы ролей и прав доступа
Проблема: Права доступа назначаются «по запросу» без системного подхода, в итоге часть сотрудников имеет доступ к данным, которые им не нужны, а часть не может выполнять свою работу из-за отсутствия нужных прав.
Решение: Промпт создает структурированную матрицу ролей и прав доступа с обоснованием каждого решения.
Текст промпта:
*****
Ты – специалист по информационной безопасности и проектированию прав доступа в корпоративных системах.
Задача: разработай матрицу ролей и прав доступа для информационной системы на основе описания бизнес-процессов.
Система: [опишите, например, «система управления договорами: хранение договоров, согласование, контроль исполнения, формирование отчетности»]
Подразделения и должности: [перечислите, например, «юрист, руководитель юридического отдела, менеджер по продажам, финансовый директор, администратор системы, сотрудник ИТ-отдела»]
Функциональные блоки системы: [перечислите, например, «создание договора, редактирование, согласование, подписание, архив, отчетность, настройки системы»]
Требования к безопасности: [укажите, например, «принцип минимальных привилегий, разделение полномочий между согласующими и исполняющими, аудиторский след всех действий»]
Результат:
- Матрица ролей и прав в табличном виде (роль × функция = право: просмотр / создание / редактирование / удаление / запрещено)
- Описание каждой роли: кто относится, какие задачи решает
- Обоснование ограничений доступа для критичных функций
- Рекомендации по периодическому пересмотру прав
Тон: профессиональный, обоснованный. Каждое ограничение – с объяснением причины.
*****
Почему это работает: Требование обосновать каждое ограничение превращает матрицу из технического артефакта в управленческий документ – руководители понимают логику решений и реже пытаются ее обойти.
10. Составление плана тестирования информационной системы
Проблема: Тестирование сводится к «проверили – работает», без описания сценариев, критериев приемки и разграничения ответственности – что приводит к тому, что ошибки обнаруживаются уже в продуктивной среде.
Решение: Промпт создает структурированный план тестирования с конкретными сценариями, критериями и распределением ответственности.
Текст промпта:
*****
Ты – специалист по качеству программного обеспечения с опытом тестирования корпоративных информационных систем.
Задача: разработай план тестирования информационной системы перед вводом в промышленную эксплуатацию.
Система: [опишите, например, «веб-портал самообслуживания сотрудников: просмотр расчетного листа, подача заявлений на отпуск, изменение личных данных»]
Ключевые функции для тестирования: [перечислите, например, «авторизация, просмотр расчетного листа, подача заявления, уведомление руководителя, одобрение/отклонение заявления»]
Участники тестирования: [укажите, например, «специалист ИТ-отдела, представители кадровой службы, 5 сотрудников из разных подразделений в роли пилотных пользователей»]
Сроки: [укажите, например, «2 недели до плановой даты ввода в эксплуатацию»]
Структура плана тестирования:
- Цели и область тестирования
- Виды тестирования (функциональное, нагрузочное, безопасности, удобства использования)
- Тестовые сценарии – для каждого: описание, входные данные, ожидаемый результат, критерий прохождения
- Критерии готовности к вводу в эксплуатацию
- Процедура фиксации и устранения ошибок
- Распределение ролей и ответственности
Формат: документ, понятный как техническим специалистам, так и представителям бизнеса.
Чего избегать: абстрактных сценариев без конкретных входных данных, отсутствия критериев прохождения теста.
*****
Почему это работает: Требование для каждого сценария указать ожидаемый результат и критерий прохождения устраняет субъективность в оценке – «работает» или «не работает» становится измеримым, а не вопросом интерпретации.
11. Подготовка презентации ИТ-проекта для руководства
Проблема: Технические специалисты готовят презентации проектов так, как хотели бы их услышать сами – с деталями архитектуры и технологическими подробностями, которые руководство не воспринимает и не запоминает.
Решение: Промпт создает структуру презентации, ориентированную на управленческие решения и бизнес-результаты.
Текст промпта:
*****
Ты – опытный руководитель ИТ-проектов с практикой защиты проектов перед советом директоров и государственными заказчиками.
Задача: разработай структуру и ключевые тезисы презентации ИТ-проекта для руководства организации.
Проект: [опишите, например, «внедрение системы электронного архива документов: перевод бумажного архива в цифровой формат, интеграция с системой документооборота, обеспечение быстрого поиска»]
Аудитория: [опишите, например, «генеральный директор, финансовый директор, руководители ключевых подразделений – всего 8 человек»]
Цель презентации: [укажите, например, «получить одобрение бюджета 2,5 млн рублей и утверждение сроков проекта»]
Ключевые параметры проекта: [укажите, например, «срок – 6 месяцев, команда – 3 человека, ожидаемый эффект – сокращение времени поиска документов с 40 минут до 2 минут, экономия на аренде архивного помещения 600 000 рублей в год»]
Структура презентации (слайды):
- Проблема, которую решаем (в бизнес-терминах, не технических)
- Предлагаемое решение (кратко, без технических деталей)
- Ожидаемые результаты для бизнеса (измеримые)
- Финансовое обоснование (затраты и выгоды)
- Риски и как мы их снижаем
- План и контрольные точки
- Что нужно от руководства (конкретный запрос)
Для каждого слайда: заголовок, 3–5 ключевых тезисов, рекомендации по визуализации.
Тон: уверенный, конкретный, ориентированный на решение, а не на технологии.
*****
Почему это работает: Последний слайд с конкретным запросом к руководству – ключевой элемент, который большинство технических специалистов упускают, и именно из-за этого презентация заканчивается «подумаем» вместо принятого решения.
12. Анализ инцидента и составление отчета о сбое системы
Проблема: После сбоя системы либо пишется формальный отчет «система упала – система поднялась», либо начинается поиск виновных вместо поиска причин – ни то, ни другое не предотвращает повторение инцидента.
Решение: Промпт создает структурированный отчет об инциденте с анализом первопричин и планом предотвращения повторения.
Текст промпта:
*****
Ты – специалист по информационным системам с опытом расследования инцидентов и разработки мер по предотвращению их повторения.
Задача: составь структурированный отчет об инциденте в информационной системе на основе предоставленных данных.
Данные об инциденте:
– Система: [укажите, например, «система расчета заработной платы»]
– Дата и время начала: [укажите, например, «15 октября, 14:32»]
– Дата и время устранения: [укажите, например, «15 октября, 17:45»]
– Описание симптомов: [опишите, например, «пользователи не могли войти в систему, появлялась ошибка подключения к базе данных»]
– Предпринятые действия: [опишите, например, «перезапуск службы, проверка подключения к базе данных, восстановление из резервной копии конфигурации»]
– Установленная причина: [укажите, например, «некорректное обновление конфигурации базы данных в ходе планового обслуживания»]
– Затронутые пользователи: [укажите, например, «все пользователи бухгалтерии – 23 человека»]
Структура отчета:
- Краткое резюме инцидента
- Хронология событий
- Анализ первопричины (метод «5 почему» или аналогичный)
- Последствия для бизнеса
- Принятые меры по устранению
- План предотвращения повторения с конкретными мероприятиями и сроками
- Выводы и уроки
Тон: объективный, без поиска виновных, ориентированный на улучшение процессов.
*****
Почему это работает: Метод «5 почему» в качестве обязательного элемента гарантирует, что анализ дойдет до системной причины, а не остановится на поверхностном симптоме – именно это отличает отчет, который меняет ситуацию, от отчета, который просто фиксирует факт.
13. Разработка политики резервного копирования
Проблема: Резервное копирование настраивается один раз и забывается – пока не наступает момент восстановления, когда выясняется, что копии либо устарели, либо не проверялись, либо хранятся там же, где и основные данные.
Решение: Промпт создает полноценную политику резервного копирования с учетом рисков и требований к проверке восстановления.
Текст промпта:
*****
Ты – специалист по информационной безопасности и администрированию информационных систем с опытом разработки политик защиты данных.
Задача: разработай политику резервного копирования данных для организации.
Параметры организации:
– Тип организации: [укажите, например, «производственное предприятие, 200 сотрудников»]
– Критичные данные и системы: [перечислите, например, «база данных 1С (бухгалтерия и зарплата), файловый сервер с рабочими документами, база данных CRM-системы»]
– Объем данных: [укажите, например, «база 1С – 80 ГБ, файловый сервер – 2 ТБ, CRM – 15 ГБ»]
– Допустимое время восстановления: [укажите, например, «для 1С – не более 4 часов, для остального – не более 1 рабочего дня»]
– Допустимая потеря данных: [укажите, например, «не более 1 рабочего дня»]
– Инфраструктура: [укажите, например, «локальные серверы, возможность использования внешнего хранилища»]
Политика должна включать:
- Что резервируется (перечень систем и данных)
- Расписание резервного копирования (полное, инкрементальное, дифференциальное)
- Где хранятся копии (правило 3-2-1 или аналогичное)
- Сроки хранения копий
- Порядок и периодичность проверки работоспособности копий
- Ответственные лица и их обязанности
- Порядок восстановления при различных сценариях потери данных
Формат: нормативный документ организации. Язык – понятный, без избыточного технического жаргона.
*****
Почему это работает: Явное включение раздела о проверке работоспособности копий закрывает самую опасную слепую зону – резервные копии, которые никогда не проверялись, с той же вероятностью окажутся нерабочими, что и их полное отсутствие.
14. Написание должностной инструкции специалиста по информационным системам
Проблема: Должностные инструкции копируются из интернета или других организаций, не отражают реальные задачи конкретной должности и превращаются в формальность, которую никто не читает и которая не защищает ни сотрудника, ни работодателя.
Решение: Промпт создает актуальную должностную инструкцию, отражающую реальные функции и зоны ответственности.
Текст промпта:
*****
Ты – специалист по управлению персоналом и организационному проектированию с опытом разработки нормативной документации для ИТ-подразделений.
Задача: составь должностную инструкцию специалиста по информационным системам, отражающую реальные задачи и зоны ответственности.
Параметры должности:
– Организация: [опишите, например, «государственное бюджетное учреждение здравоохранения, 500 сотрудников»]
– Подчинение: [укажите, например, «начальник отдела информационных технологий»]
– Реальные задачи должности: [перечислите, например, «администрирование медицинской информационной системы, техническая поддержка пользователей, ведение документации, обеспечение резервного копирования, взаимодействие с поставщиками ПО»]
– Ключевые системы, с которыми работает специалист: [перечислите, например, «МИС на базе БАРС.Здравоохранение, сервер Active Directory, система электронного документооборота»]
– Особые требования: [укажите, например, «работа с персональными данными пациентов, требования 152-ФЗ»]
Структура инструкции:
- Общие положения (кому подчиняется, квалификационные требования, что должен знать)
- Должностные обязанности (конкретные, измеримые, без размытых формулировок)
- Права
- Ответственность (с указанием нормативных оснований)
- Взаимодействие с другими подразделениями
Требования: соответствие трудовому законодательству РФ, ссылки на профессиональный стандарт при необходимости. Обязанности – конкретные действия, а не абстрактные функции.
*****
Почему это работает: Привязка к реальным задачам и конкретным системам организации превращает шаблонный документ в рабочий инструмент управления – и руководитель, и сотрудник понимают, за что именно отвечает специалист.
15. Формирование технического задания на закупку программного обеспечения
Проблема: Техническое задание на закупку ПО пишется под конкретного поставщика или копируется с прошлой закупки – и либо не обеспечивает реальную конкуренцию, либо позволяет выиграть тому, кто предложит наименьшую цену при минимальном соответствии требованиям.
Решение: Промпт создает объективное техническое задание с измеримыми требованиями, не привязанное к конкретному продукту.
Текст промпта:
*****
Ты – специалист по государственным и корпоративным закупкам в сфере информационных технологий с опытом подготовки конкурсной документации.
Задача: составь техническое задание на закупку программного обеспечения, соответствующее требованиям законодательства о закупках и обеспечивающее объективный выбор поставщика.
Параметры закупки:
– Потребность: [опишите, например, «система управления проектами для ИТ-отдела, 15 пользователей»]
– Функциональные требования: [перечислите, например, «планирование задач, отслеживание времени, отчетность, интеграция с почтой, мобильный доступ»]
– Технические ограничения: [укажите, например, «развертывание на собственных серверах (не облако), совместимость с Windows 10/11, работа без постоянного интернет-соединения»]
– Требования к безопасности: [укажите, например, «шифрование данных, разграничение прав доступа, журналирование действий»]
– Бюджет и срок: [укажите, например, «до 500 000 рублей, внедрение в течение 3 месяцев»]
– Тип закупки: [укажите, например, «по 44-ФЗ / по 223-ФЗ / коммерческая закупка»]
Структура технического задания:
- Цели и назначение закупки
- Требования к функциональным характеристикам
- Технические требования и совместимость
- Требования к безопасности и защите данных
- Требования к внедрению и обучению пользователей
- Требования к технической поддержке
- Критерии оценки предложений
Требование: все характеристики должны быть измеримыми и проверяемыми, без указания конкретных торговых марок или производителей.
*****
Почему это работает: Требование измеримости и проверяемости каждой характеристики – это защита от двух противоположных рисков: от закупки «для своих» и от победы поставщика с формально соответствующим, но непригодным продуктом.
16. Составление плана обучения пользователей новой системе
Проблема: Обучение пользователей сводится к одному инструктажу в день внедрения – после чего половина сотрудников продолжает работать по-старому, а другая половина завалывает службу поддержки вопросами, ответы на которые были в инструкции.
Решение: Промпт создает многоэтапный план обучения с учетом разных категорий пользователей и механизмами закрепления знаний.
Текст промпта:
*****
Ты – методист и специалист по внедрению информационных систем с опытом организации обучения пользователей в организациях с различным уровнем цифровой грамотности.
Задача: разработай многоэтапный план обучения сотрудников работе с новой информационной системой.
Система: [опишите, например, «система электронного документооборота, заменяет бумажный документооборот»]
Категории пользователей: [перечислите, например, «рядовые сотрудники (100 человек, разный уровень владения компьютером), руководители подразделений (15 человек), делопроизводители (5 человек – ключевые пользователи)»]
Сроки внедрения: [укажите, например, «система запускается через 6 недель»]
Ресурсы для обучения: [укажите, например, «1 специалист по обучению, учебный стенд системы, возможность проводить занятия в учебном классе на 20 человек»]
Структура плана обучения:
- Подготовительный этап (учебные материалы, тестовая среда, выбор ключевых пользователей)
- Обучение ключевых пользователей (углубленное, они станут внутренними консультантами)
- Обучение рядовых сотрудников (по категориям, с учетом уровня подготовки)
- Обучение руководителей (акцент на контроле и отчетности, не на рутинных операциях)
- Поддержка в первые недели после запуска
- Оценка результатов обучения
Для каждого этапа: цели, содержание, формат, продолжительность, ответственный.
Чего избегать: единого обучения для всех категорий, обучения без практики, отсутствия поддержки после запуска.
*****
Почему это работает: Концепция «ключевых пользователей» как внутренних консультантов масштабирует поддержку без увеличения ресурсов ИТ-отдела – это системное решение, а не разовое мероприятие.
17. Разработка концепции информатизации подразделения
Проблема: Концепции информатизации пишутся как списки желаний без анализа текущего состояния, приоритизации и обоснования – в итоге документ существует сам по себе, а реальные решения принимаются по другим основаниям.
Решение: Промпт создает обоснованную концепцию с анализом «как есть», видением «как должно быть» и дорожной картой перехода.
Текст промпта:
*****
Ты – консультант по цифровой трансформации и информатизации организаций с опытом разработки стратегических документов для государственных и коммерческих структур.
Задача: разработай концепцию информатизации подразделения на основе предоставленных данных.
Подразделение: [опишите, например, «отдел кадров производственного предприятия, 8 сотрудников, обслуживает 600 человек»]
Текущее состояние (как есть): [опишите, например, «личные карточки ведутся в Excel, приказы создаются в Word и хранятся в бумажном виде, табель учета рабочего времени – бумажный, взаимодействие с бухгалтерией – через передачу файлов Excel»]
Проблемы и боли: [перечислите, например, «дублирование ввода данных, ошибки при ручном переносе, долгий поиск документов, сложность формирования отчетности»]
Стратегические цели организации: [укажите, например, «повышение эффективности, сокращение бумажного документооборота, соответствие требованиям проверяющих органов»]
Ограничения: [укажите, например, «бюджет на следующий год – 800 000 рублей, приоритет российским решениям, интеграция с существующей бухгалтерской системой обязательна»]
Структура концепции:
- Анализ текущего состояния и выявленные проблемы
- Целевое состояние (как должно быть через 2–3 года)
- Предлагаемые решения с обоснованием выбора
- Дорожная карта реализации (этапы, сроки, ресурсы)
- Ожидаемые результаты и показатели эффективности
- Риски и способы управления ими
Тон: профессиональный, обоснованный, ориентированный на результат.
*****
Почему это работает: Привязка к стратегическим целям организации и измеримым показателям эффективности переводит концепцию из категории «технических хотелок» в категорию управленческих инструментов, которые рассматривают и финансируют.
18. Подготовка ответа на предписание регулятора по информационной безопасности
Проблема: Ответы на предписания регуляторов пишутся в режиме паники, формально и без реального плана устранения нарушений – что приводит к повторным проверкам и усилению претензий.
Решение: Промпт создает структурированный ответ с конкретным планом устранения замечаний и реалистичными сроками.
Текст промпта:
*****
Ты – специалист по информационной безопасности и юридическому сопровождению ИТ-деятельности с опытом взаимодействия с регуляторами в сфере защиты информации.
Задача: подготовь ответ на предписание регулятора об устранении нарушений в области информационной безопасности.
Данные:
– Регулятор: [укажите, например, «Роскомнадзор / ФСТЭК / собственный орган управления»]
– Суть предписания: [опишите выявленные нарушения, например, «отсутствие политики обработки персональных данных, отсутствие согласий на обработку ПД от сотрудников, не назначен ответственный за обработку ПД»]
– Срок устранения по предписанию: [укажите, например, «60 дней с даты получения предписания»]
– Реальные возможности организации: [опишите, например, «юриста в штате нет, ИТ-специалист 1 человек, руководство готово выделить ресурсы»]
Структура ответа:
- Вводная часть (реквизиты, ссылка на предписание)
- По каждому нарушению отдельно:
– Признание факта нарушения (или обоснованное несогласие)
– Принятые меры (уже выполненные)
– План устранения (конкретные мероприятия с датами и ответственными) - Приложения (перечень подтверждающих документов)
Тон: деловой, корректный, без излишних оправданий. Демонстрация готовности к сотрудничеству с регулятором.
Чего избегать: общих обещаний без конкретных сроков, отрицания очевидных фактов, агрессивного тона.
*****
Почему это работает: Разбивка ответа по каждому нарушению отдельно с конкретными датами демонстрирует регулятору системный подход – это принципиально меняет характер дальнейшего взаимодействия по сравнению с общими обещаниями «принять меры».
19. Описание бизнес-процесса для последующей автоматизации
Проблема: Бизнес-процессы описываются либо слишком поверхностно («сотрудник делает X, потом Y»), либо в формате блок-схем, которые никто не умеет читать – и разработчики автоматизируют не то, что нужно бизнесу.
Решение: Промпт создает структурированное описание процесса с указанием участников, исключений и критериев качества – именно то, что нужно для проектирования автоматизации.
Текст промпта:
*****
Ты – бизнес-аналитик с опытом описания и оптимизации бизнес-процессов перед их автоматизацией в информационных системах.
Задача: создай структурированное описание бизнес-процесса, пригодное для проектирования автоматизации.
Процесс: [назовите и кратко опишите, например, «процесс согласования договора с контрагентом»]
Участники процесса: [перечислите, например, «инициатор договора (менеджер по продажам), юридический отдел, финансовый директор, генеральный директор, делопроизводитель»]
Известные шаги процесса: [опишите, например, «менеджер готовит договор, передает юристу, юрист проверяет, при необходимости возвращает на доработку, потом финансовому директору, потом генеральному, потом делопроизводителю для регистрации»]
Известные проблемы процесса: [укажите, например, «непонятно, где находится договор в каждый момент времени, согласование занимает до 3 недель, часть договоров теряется»]
Структура описания:
- Назначение и область применения процесса
- Участники и их роли
- Триггер запуска процесса (что его начинает)
- Основной сценарий (шаг за шагом, кто что делает)
- Альтернативные сценарии и исключения (что происходит при отклонении, отказе, ошибке)
- Результат процесса (что считается успешным завершением)
- Показатели качества процесса (как измерить, что процесс работает хорошо)
- Что можно автоматизировать, а что требует участия человека
Формат: структурированный текст, понятный и бизнес-пользователю, и разработчику.
*****
Почему это работает: Отдельный раздел об альтернативных сценариях и исключениях – это то, что отличает описание реального процесса от его идеализированной версии: именно в исключениях скрывается большинство ошибок автоматизации.
20. Составление плана перехода на отечественное программное обеспечение
Проблема: Переход на российское ПО часто планируется как замена «один к одному», без учета функциональных различий, необходимости переобучения и изменения привычных рабочих процессов – что приводит к срывам сроков и сопротивлению пользователей.
Решение: Промпт создает реалистичный план перехода с анализом функциональных разрывов и управлением изменениями.
Текст промпта:
*****
Ты – специалист по информационным системам с опытом реализации проектов импортозамещения программного обеспечения в государственных и коммерческих организациях.
Задача: разработай план перехода с иностранного программного обеспечения на российские аналоги.
Параметры перехода:
– Заменяемое ПО: [укажите, например, «Microsoft Office 365 (Word, Excel, Outlook, Teams)»]
– Целевое ПО: [укажите, например, «МойОфис Стандартный, Яндекс Почта для бизнеса, Яндекс Телемост»]
– Количество пользователей: [укажите, например, «150 человек, офисы в двух городах»]
– Срок перехода: [укажите, например, «12 месяцев, жесткий срок – требование учредителя»]
– Критичные сценарии использования: [перечислите, например, «работа с документами Word/Excel, корпоративная почта, видеоконференции, совместная работа над документами»]
Структура плана:
- Анализ функциональных разрывов (что есть в старом ПО и чего нет или что работает иначе в новом)
- Пилотный проект (выбор группы, критерии успеха)
- Подготовка инфраструктуры
- Поэтапный переход пользователей
- Обучение (с учетом функциональных различий, а не просто «вот новые кнопки»)
- Поддержка в переходный период
- Завершение перехода и отключение старого ПО
Для каждого этапа: сроки, ответственные, риски, критерии успеха.
Чего избегать: планирования перехода без анализа функциональных разрывов, одновременного перевода всех пользователей, недооценки сопротивления изменениям.
*****
Почему это работает: Анализ функциональных разрывов как первый обязательный этап не позволяет перейти к планированию, не ответив на ключевой вопрос: что именно изменится в работе людей – и именно это определяет весь дальнейший план.
21. Разработка технического задания на доработку существующей системы
Проблема: Задания на доработку систем формулируются как «добавить кнопку» или «сделать как раньше, но по-другому» – без описания бизнес-цели, контекста и критериев приемки, что гарантирует несовпадение ожиданий и результата.
Решение: Промпт создает полноценное задание на доработку с обоснованием необходимости изменений и измеримыми критериями приемки.
Текст промпта:
*****
Ты – системный аналитик с опытом управления изменениями в корпоративных информационных системах.
Задача: составь техническое задание на доработку существующей информационной системы.
Система: [опишите, например, «система учета обращений граждан в государственном органе на базе собственной разработки»]
Запрос на изменение: [опишите, например, «добавить возможность фиксировать повторные обращения по одному вопросу и автоматически связывать их с исходным обращением»]
Бизнес-причина изменения: [укажите, например, «требование нового регламента Министерства, вступающего в силу через 3 месяца; также позволит отслеживать системные проблемы, порождающие множество обращений по одной теме»]
Текущее поведение системы: [опишите, например, «каждое обращение регистрируется независимо, связи между обращениями не отслеживаются»]
Требуемое поведение системы: [опишите подробно, например, «при регистрации нового обращения система предлагает проверить, есть ли у заявителя предыдущие обращения по тому же вопросу; оператор может связать обращения; в карточке обращения отображается история всех связанных обращений»]
Структура ТЗ на доработку:
- Обоснование и цель доработки
- Описание текущего и требуемого поведения
- Функциональные требования к доработке
- Требования к пользовательскому интерфейсу
- Требования к данным (новые поля, изменения в структуре)
- Критерии приемки (как проверить, что доработка выполнена правильно)
- Требования к документированию изменений
*****
Почему это работает: Раздельное описание текущего и требуемого поведения системы устраняет главный источник недопонимания – разработчик видит не только «что сделать», но и «от чего отталкиваться», что кратно снижает количество уточняющих вопросов.
22. Анализ рисков внедрения информационной системы
Проблема: Риски внедрения либо не анализируются вовсе, либо перечисляются формально в виде списка без оценки вероятности и плана реагирования – и когда риск реализуется, команда оказывается к этому не готова.
Решение: Промпт создает структурированный реестр рисков с оценкой, приоритизацией и конкретными планами реагирования.
Текст промпта:
*****
Ты – руководитель ИТ-проектов с опытом управления рисками при внедрении корпоративных информационных систем.
Задача: проведи анализ рисков внедрения информационной системы и разработай реестр рисков с планами реагирования.
Проект: [опишите, например, «внедрение системы управления складом на производственном предприятии, срок – 8 месяцев, команда – 5 человек (2 от заказчика, 3 от исполнителя)»]
Контекст: [опишите особенности, например, «действующий склад не может останавливать работу в процессе внедрения; предыдущая попытка внедрения системы 3 года назад была неудачной; часть сотрудников склада активно сопротивляется изменениям»]
Известные проблемы и опасения: [перечислите, например, «нечеткие требования к отчетности, зависимость от ключевого сотрудника заказчика, который может уйти, интеграция с устаревшей бухгалтерской системой»]
Для каждого риска укажи:
– Описание риска
– Вероятность (высокая / средняя / низкая)
– Влияние на проект (высокое / среднее / низкое)
– Приоритет (произведение вероятности и влияния)
– Стратегия реагирования (принять / снизить / передать / избежать)
– Конкретные действия по управлению риском
– Владелец риска (кто отвечает за мониторинг)
Итог: сводная таблица рисков и топ-3 риска с детальным планом реагирования.
Тон: реалистичный, без преуменьшения рисков.
*****
Почему это работает: Назначение владельца для каждого риска превращает реестр из статичного документа в живой инструмент управления – без ответственного конкретного человека риск остается на бумаге, а не в зоне чьего-то внимания.
23. Написание инструкции по информационной безопасности для сотрудников
Проблема: Инструкции по информационной безопасности пишутся юридическим языком для галочки – сотрудники подписывают их, не читая, и продолжают открывать подозрительные письма и использовать пароль «12345».
Решение: Промпт создает инструкцию, написанную человеческим языком с конкретными примерами угроз и понятными правилами поведения.
Текст промпта:
*****
Ты – специалист по информационной безопасности с опытом разработки обучающих материалов для нетехнических сотрудников.
Задача: напиши инструкцию по информационной безопасности для сотрудников организации, которую они действительно прочитают и запомнят.
Организация: [опишите, например, «медицинская организация, сотрудники работают с персональными данными пациентов и медицинскими записями»]
Основные угрозы для данной организации: [перечислите, например, «фишинговые письма от имени страховых компаний, утечка данных пациентов, использование личных устройств для работы с медицинскими данными»]
Аудитория: [опишите, например, «врачи и средний медицинский персонал, большинство не имеют технического образования»]
Структура инструкции:
- Зачем это важно (не «требования законодательства», а реальные последствия для пациентов и организации)
- Правила работы с паролями (конкретные, с примерами плохих и хороших паролей)
- Как распознать мошенническое письмо (с конкретными признаками и примерами)
- Правила работы с данными пациентов (где можно хранить, где нельзя, как передавать)
- Что делать, если что-то пошло не так (конкретный алгоритм действий)
- Правила работы с личными устройствами
Требования: конкретные примеры угроз из медицинской сферы, правила – в виде «можно/нельзя», язык – понятный врачу без технического образования.
Тон: серьезный, но без запугивания. Объясняем, почему это важно, а не просто запрещаем.
*****
Почему это работает: Замена абстрактных требований конкретными примерами угроз из реальной практики данной отрасли включает у сотрудников личную заинтересованность – человек соблюдает правила, когда понимает, от чего именно они его защищают.
24. Формирование требований к системе мониторинга и оповещения
Проблема: Мониторинг систем настраивается реактивно – после того, как что-то упало, а не проактивно. В итоге о проблемах узнают от пользователей, а не от системы мониторинга.
Решение: Промпт создает структурированные требования к системе мониторинга с пороговыми значениями и матрицей эскалации.
Текст промпта:
*****
Ты – системный администратор и архитектор информационных систем с опытом построения систем мониторинга для критичных корпоративных приложений.
Задача: разработай требования к системе мониторинга и оповещения для информационной инфраструктуры организации.
Инфраструктура для мониторинга: [опишите, например, «3 сервера (сервер приложений 1С, сервер баз данных, файловый сервер), сетевое оборудование, корпоративный сайт, система резервного копирования»]
Критичность систем: [укажите, например, «сервер 1С – критичный (простой = прямые финансовые потери), файловый сервер – высокая важность, сайт – средняя важность»]
Команда реагирования: [опишите, например, «1 системный администратор (доступен в рабочее время), аутсорсинговая компания (доступна круглосуточно), руководитель ИТ-отдела»]
Требования к системе мониторинга:
- Что мониторить для каждого компонента (с пороговыми значениями: предупреждение / критично)
- Каналы оповещения (электронная почта, СМС, мессенджер – для каких уровней критичности)
- Матрица эскалации (кто получает оповещение, через какое время, если нет реакции)
- Требования к панели мониторинга (что должно быть видно с первого взгляда)
- Требования к журналу событий
- Рекомендации по выбору инструментов мониторинга (с учетом российских решений)
Формат: технический документ с конкретными значениями порогов, а не абстрактными требованиями.
*****
Почему это работает: Матрица эскалации с конкретными временными интервалами устраняет ситуацию, когда оповещение ушло, но никто не среагировал – потому что каждый думал, что среагирует другой.
25. Подготовка технического описания системы для аудита
Проблема: К аудиту информационных систем готовятся в последний момент, собирая документацию по кускам – в итоге аудиторы получают несвязный набор документов, задают много дополнительных вопросов и находят больше замечаний.
Решение: Промпт создает полное и структурированное техническое описание системы, готовое для представления аудиторам.
Текст промпта:
*****
Ты – специалист по информационным системам с опытом подготовки организаций к аудитам в сфере информационных технологий и информационной безопасности.
Задача: подготовь техническое описание информационной системы для представления аудиторам.
Система: [опишите, например, «система обработки персональных данных сотрудников: кадровый учет, расчет заработной платы, электронные трудовые книжки»]
Тип аудита: [укажите, например, «проверка соответствия требованиям 152-ФЗ о персональных данных»]
Известные сведения о системе: [опишите, например, «система на базе 1С:ЗУП 8.3, сервер в собственном серверном помещении, доступ по локальной сети и VPN, пользователи – 12 человек из кадровой службы и бухгалтерии, данные хранятся 75 лет по требованиям архивного законодательства»]
Структура технического описания:
- Назначение и область применения системы
- Архитектура системы (компоненты, схема взаимодействия)
- Состав обрабатываемых данных (категории, объем, источники)
- Пользователи системы и права доступа
- Меры защиты информации (технические и организационные)
- Порядок резервного копирования и восстановления
- Журналирование и аудит действий
- Соответствие нормативным требованиям
Формат: официальный документ с четкой структурой. Технические термины – с пояснениями там, где аудиторы могут не быть техническими специалистами.
Чего избегать: утаивания известных проблем (лучше указать с планом устранения), размытых формулировок о мерах защиты.
*****
Почему это работает: Рекомендация не скрывать известные проблемы, а указывать их с планом устранения – это нетривиальный, но эффективный подход: аудиторы ценят честность и наличие плана значительно больше, чем отсутствие видимых проблем при скрытых реальных.
26. Составление плана восстановления после катастрофы
Проблема: Планы восстановления после катастроф либо не существуют вовсе, либо существуют как документы, которые никто не проверял на практике – и когда происходит реальный инцидент, выясняется, что план не работает.
Решение: Промпт создает практичный план восстановления с конкретными процедурами и требованием регулярного тестирования.
Текст промпта:
*****
Ты – специалист по непрерывности бизнеса и восстановлению информационных систем с опытом разработки и тестирования планов аварийного восстановления.
Задача: разработай план восстановления информационных систем после катастрофических сбоев.
Организация: [опишите, например, «торговая компания, ежедневный оборот 5 млн рублей, работа зависит от системы управления заказами и складом»]
Критичные системы: [перечислите, например, «система управления заказами, база данных клиентов, система складского учета, корпоративная почта»]
Целевые показатели восстановления:
– Максимально допустимое время простоя: [укажите, например, «для системы заказов – 2 часа, для почты – 4 часа, для остального – 8 часов»]
– Максимально допустимая потеря данных: [укажите, например, «не более 1 часа транзакций»]
Доступные ресурсы для восстановления: [опишите, например, «резервный сервер в другом офисе, резервные копии на внешнем хранилище, договор с сервисной компанией на аварийное обслуживание»]
Структура плана:
- Сценарии катастроф (отказ оборудования, пожар, кибератака, ошибка администратора)
- Для каждого сценария: процедура восстановления шаг за шагом
- Роли и ответственность в кризисной ситуации
- Контакты: внутренние и внешние (с альтернативными способами связи)
- Процедура объявления аварийного режима
- Коммуникация с пользователями и руководством во время инцидента
- График тестирования плана и критерии успешного теста
Тон: практичный, конкретный. Каждый шаг – одно действие с ответственным.
*****
Почему это работает: Включение в план разных сценариев катастроф с отдельными процедурами для каждого – это принципиальное отличие от универсального «восстановить из резервной копии»: реальные катастрофы не бывают одинаковыми, и план должен это учитывать.
27. Разработка критериев выбора информационной системы
Проблема: Выбор информационной системы происходит под влиянием самой убедительной презентации поставщика или рекомендации знакомого – без структурированного сравнения по объективным критериям, что приводит к дорогостоящим ошибкам.
Решение: Промпт создает взвешенную систему критериев оценки, позволяющую сравнивать системы объективно.
Текст промпта:
*****
Ты – независимый консультант по выбору и внедрению корпоративных информационных систем с опытом сравнительного анализа программных продуктов для различных отраслей.
Задача: разработай систему критериев для выбора информационной системы и оцени варианты на основе предоставленных данных.
Потребность организации: [опишите, например, «система управления проектами для строительной компании, 50 проектных менеджеров, работа в полевых условиях с нестабильным интернетом»]
Рассматриваемые варианты: [перечислите, например, «Битрикс24, собственная разработка на базе 1С, Яндекс Трекер с доработками»]
Ключевые требования организации: [перечислите, например, «работа в офлайн-режиме, мобильное приложение, интеграция с 1С:Бухгалтерия, российское ПО, бюджет – до 1,5 млн рублей в год»]
Разработай систему критериев оценки по блокам:
- Функциональное соответствие (покрытие ключевых требований)
- Технические характеристики (надежность, производительность, безопасность)
- Условия приобретения и владения (стоимость, модель лицензирования)
- Внедрение и интеграция (сложность, сроки, риски)
- Поддержка и развитие (качество поддержки, дорожная карта развития)
- Соответствие регуляторным требованиям
Для каждого критерия: вес (важность), шкала оценки, способ проверки. Итог: сводная матрица оценки с рекомендацией и обоснованием.
Чего избегать: критериев, которые нельзя объективно проверить, игнорирования совокупной стоимости владения.
*****
Почему это работает: Требование указать способ проверки для каждого критерия устраняет «критерии на бумаге» – когда написано «высокая производительность», но непонятно, как это измерить при демонстрации системы поставщиком.
28. Подготовка акта приемки информационной системы
Проблема: Акты приемки подписываются формально, без реальной проверки соответствия требованиям – что лишает заказчика рычагов влияния при обнаружении проблем после подписания.
Решение: Промпт создает детальный акт приемки с конкретными проверочными процедурами и четкими критериями.
Текст промпта:
*****
Ты – специалист по управлению ИТ-проектами с опытом организации приемки информационных систем и защиты интересов заказчика.
Задача: разработай структуру и содержание акта приемки информационной системы с четкими критериями проверки.
Проект: [опишите, например, «разработка и внедрение системы учета обращений граждан для органа местного самоуправления»]
Ключевые требования из технического задания: [перечислите, например, «регистрация обращений, маршрутизация по ответственным, контроль сроков, формирование ответов, отчетность, интеграция с порталом Госуслуги»]
Участники приемки: [укажите, например, «заказчик: начальник отдела ИТ и представитель от бизнеса; исполнитель: руководитель проекта и технический специалист»]
Структура акта приемки:
- Реквизиты (стороны, документы-основания, период выполнения работ)
- Перечень выполненных работ
- Результаты проверки функциональных требований (таблица: требование – способ проверки – результат проверки – соответствует/не соответствует)
- Результаты приемочного тестирования
- Перечень выявленных замечаний и порядок их устранения
- Заключение (принято / принято с замечаниями / не принято)
- Подписи сторон
Требование: для каждого требования из ТЗ – конкретный способ проверки, а не просто «проверено».
Тон: юридически корректный, защищающий интересы заказчика без агрессии в отношении исполнителя.
*****
Почему это работает: Таблица «требование – способ проверки – результат» превращает приемку из формального подписания в реальную процедуру контроля качества – и именно наличие способа проверки для каждого пункта делает акт юридически значимым документом.
29. Составление отчета об эффективности внедренной информационной системы
Проблема: После внедрения системы никто не измеряет, достигнуты ли заявленные цели – ни ИТ-отдел, ни руководство, ни подразделения-пользователи. В итоге следующий проект снова обосновывается на уровне ожиданий, а не на основе реальных данных.
Решение: Промпт создает структурированный отчет об эффективности с измеримыми показателями и выводами для будущих проектов.
Текст промпта:
*****
Ты – аналитик эффективности ИТ-проектов с опытом оценки результатов внедрения корпоративных информационных систем.
Задача: составь отчет об эффективности внедренной информационной системы через [укажите период, например, «6 месяцев после запуска»].
Система: [опишите, например, «система электронного документооборота, внедрена в организации численностью 300 человек»]
Заявленные цели внедрения: [перечислите, например, «сокращение времени согласования документов с 5 дней до 1 дня, отказ от бумажного документооборота на 80%, сокращение затрат на бумагу и хранение»]
Доступные данные для анализа: [опишите, например, «статистика из системы (количество документов, время согласования), опрос пользователей, данные о закупках расходных материалов»]
Структура отчета:
- Краткое резюме (достигнуты ли цели – светофорная оценка)
- Анализ по каждой заявленной цели: цель → факт → отклонение → причины
- Дополнительные эффекты (незапланированные положительные и отрицательные)
- Удовлетворенность пользователей (результаты опроса или наблюдений)
- Проблемы, которые остались нерешенными
- Рекомендации: что улучшить в системе и что учесть в следующих проектах
- Финансовая эффективность (если данные позволяют)
Формат: управленческий отчет с конкретными цифрами. Раздел резюме – не более одной страницы.
Тон: объективный, честный – включая признание того, что не достигнуто.
*****
Почему это работает: Требование анализировать незапланированные эффекты – и положительные, и отрицательные – превращает отчет в источник реальных знаний о том, как работают внедрения в данной организации, а не просто в отчет о галочках напротив заявленных целей.
Типичные ошибки при использовании нейросетей специалистом по ИС
- Описывать задачу без контекста системы и организации. Нейросеть не знает, что у вас за система, какая отрасль и какие ограничения – без этого она выдает универсальный ответ, который подойдет кому угодно, кроме вас.
- Принимать первый ответ без проверки на соответствие нормативным требованиям. Нейросеть может написать убедительный текст, который противоречит 152-ФЗ, ГОСТ 34 или требованиям ФСТЭК – и выглядеть при этом вполне профессионально.
- Использовать один запрос для задач, требующих нескольких итераций. Сложные документы – технические задания, концепции, планы – лучше создавать поэтапно: сначала структура, потом наполнение каждого раздела, потом проверка связности.
- Не указывать аудиторию документа. Техническое описание для разработчика и для аудитора – это разные документы с разным уровнем детализации и разным языком, даже если речь об одной и той же системе.
- Копировать текст промпта из общих источников без адаптации под свою нишу. Запросы для нейросети, написанные для абстрактного «специалиста», не учитывают специфику работы с ИС: требования к документации, взаимодействие с регуляторами, особенности государственных закупок.
- Не проверять технические детали в ответе нейросети. Нейросеть может указать несуществующий ГОСТ, устаревшую версию законодательства или технически некорректный параметр – это нужно проверять, а не принимать на веру.
- Использовать результат нейросети как финальный документ без редактуры. Нейросеть создает хорошую основу, но не знает специфики вашей организации, внутренних договоренностей и нюансов конкретного проекта – финальная редактура обязательна.
- Забывать указывать ограничения и то, чего делать не нужно. Блок «чего избегать» в промпте – не формальность. Без него нейросеть с высокой вероятностью включит именно то, что вам не нужно: абстрактные формулировки, избыточные технические детали или рекомендации, не применимые в российских реалиях.
- Ожидать, что нейросеть самостоятельно выберет правильный уровень детализации. Без явного указания на объем и глубину ответа одни задачи будут раскрыты поверхностно, другие – с избыточными подробностями: уровень детализации нужно задавать явно в каждом запросе.
Сравнение слабых и сильных формулировок запросов для специалиста по информационным системам
| Задача | Слабая формулировка | Сильная формулировка | Почему разница критична |
| Техническое задание | Напиши ТЗ на систему учета | Составь ТЗ на модуль учета заявок в 1С:Предприятие для муниципального учреждения по структуре ГОСТ 34, аудитория – разработчики, срок приемки – 3 месяца | Без контекста нейросеть напишет шаблонный текст, не пригодный для реального проекта |
| Анализ требований | Проверь эти требования | Проанализируй требования заказчика: выяви противоречия, неоднозначности, пробелы и технически нереализуемые пункты. Для каждого – сформулируй уточняющий вопрос | Без структуры анализа нейросеть даст общие замечания вместо конкретного разбора |
| Описание архитектуры | Объясни архитектуру системы просто | Переведи техническое описание трехзвенной архитектуры на язык бизнес-ценностей для финансового директора, цель – получить одобрение бюджета | Без указания аудитории и цели «простое объяснение» все равно останется техническим |
| Оценка рисков | Какие риски у этого проекта? | Проведи анализ рисков внедрения с оценкой вероятности и влияния, стратегией реагирования и назначением владельца для каждого риска | Без структуры получится список общих рисков без плана действий |
| Инструкция по безопасности | Напиши инструкцию по информационной безопасности | Напиши инструкцию по информационной безопасности для врачей медицинской организации: конкретные примеры угроз из медицинской практики, правила в формате «можно/нельзя», без технического жаргона | Без аудитории и отраслевой специфики получится стандартный документ для галочки |
| Отчет о сбое | Напиши отчет о том, что система упала | Составь отчет об инциденте с хронологией, анализом первопричины методом «5 почему» и планом предотвращения повторения с конкретными мероприятиями и сроками | Без метода анализа нейросеть опишет симптомы, а не причины, и отчет ничего не изменит |
| Регламент работы | Напиши регламент для пользователей системы | Составь регламент работы с системой электронного документооборота, организованный вокруг типичных рабочих сценариев делопроизводителя, с пошаговыми инструкциями и описанием действий при ошибках | Без сценарного подхода получится описание интерфейса, а не инструкция для работы |
Советы по работе с нейросетями для специалиста по информационным системам
- Создайте библиотеку базовых промптов под свои типовые задачи и обновляйте ее после каждого удачного результата. Специалист по ИС работает с повторяющимися задачами – ТЗ, регламенты, отчеты – и библиотека готовых шаблонов экономит время на каждом следующем документе.
- Используйте нейросеть как «второго аналитика» для проверки собственных решений – задавайте ей вопрос «что я мог упустить» после завершения анализа. Это работает не как замена экспертизы, а как способ выявить слепые зоны, которые не видны изнутри задачи.
- При работе с нормативными документами всегда указывайте конкретный нормативный акт и просите нейросеть сослаться на конкретные статьи, а потом проверяйте эти ссылки самостоятельно. Нейросеть может «изобрести» убедительно звучащую ссылку на несуществующую норму – это редко, но происходит именно тогда, когда цена ошибки высока.
- Для сложных многосоставных документов применяйте поэтапную генерацию: сначала запросите структуру и согласуйте ее, потом наполняйте каждый раздел отдельным запросом. Попытка получить полный документ за один запрос часто приводит к тому, что одни разделы проработаны глубоко, другие – поверхностно, и это трудно исправить постфактум.
- Включайте в запросы описание «антипаттернов» – того, что вы видели в плохих документах по данной теме. Нейросеть хорошо реагирует на негативные ограничения: «избегай размытых формулировок без критерия проверки» дает более конкретный результат, чем «пиши конкретно».
- При подготовке документов для внешних аудиторов или регуляторов используйте нейросеть для генерации «неудобных вопросов», которые могут задать проверяющие. Это позволяет заранее подготовить ответы и выявить слабые места в документации до того, как это сделает аудитор.
- Сохраняйте весь диалог с нейросетью при работе над сложным документом – включая промежуточные версии и правки. При возврате к задаче через несколько дней история диалога позволяет быстро восстановить контекст и не начинать объяснение заново с нуля.
