Тимлид – это человек, который одновременно должен писать код, проводить встречи, разруливать конфликты, следить за дедлайнами и при этом делать вид, что все под контролем. Неудивительно, что на рутинные задачи времени почти не остается. Промпты для тимлида – это способ передать часть этой нагрузки нейросети и наконец сосредоточиться на том, что требует живого человека.
В этой статье – 28 готовых шаблонов запросов для нейросети, которые закрывают реальные задачи: от разбора кода и написания технических заданий до проведения встреч один на один и составления планов развития команды.
Какие задачи здесь охвачены:
- Управление командой и индивидуальная работа с разработчиками
- Технические задания, документация, описание архитектурных решений
- Разбор кода, ревью, обратная связь
- Планирование спринтов и расстановка приоритетов
- Найм, онбординг, адаптация новых людей
- Коммуникация с бизнесом и смежными командами
- Личное развитие и рост команды
Каждый промпт – это не абстрактная заготовка, а рабочий инструмент с объяснением, почему именно такая формулировка дает нужный результат.
28 промптов для тимлида: готовые шаблоны запросов для нейросети
1. Подготовка к встрече один на один с разработчиком
Проблема: Встречи один на один часто превращаются в формальный ритуал без реальной пользы – тимлид не знает, что спросить, разработчик молчит, и оба уходят с ощущением потраченного времени.
Решение: Промпт генерирует структурированный план встречи с конкретными вопросами под ситуацию конкретного человека.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный инженерный менеджер с десятилетним опытом проведения встреч один на один»].
Подготовь план встречи один на один с разработчиком для тимлида.
Контекст: [опишите ситуацию, например, «разработчик работает в команде 8 месяцев, последние 3 недели заметно снизилась активность на ревью, задачи закрываются в срок, но без инициативы»].
Составь план встречи продолжительностью 30–40 минут. Включи:
– 3–4 открытых вопроса для выяснения реального состояния человека (не формальных)
– 2–3 вопроса про профессиональный рост и интересы
– 1–2 вопроса про команду и рабочий процесс
– блок для обсуждения конкретной ситуации: [опишите то, что хотите обсудить, например, «снижение активности на код-ревью»]
– итоговый вопрос, который помогает завершить встречу с ощущением движения вперед
Тон вопросов – живой, не анкетный. Никаких закрытых вопросов с ответом «да/нет». Формат: нумерованный список по блокам.
*****
Почему это работает: Разбивка на смысловые блоки не дает встрече превратиться в монолог тимлида, а открытые вопросы вытаскивают реальную информацию вместо социально одобряемых ответов.
2. Написание технического задания для новой фичи
Проблема: Бизнес приходит с идеей «хотим кнопку, которая делает все лучше», а тимлид должен превратить это в документ, понятный разработчикам – и при этом не упустить ни один угол зрения.
Решение: Промпт создает структурированное техническое задание с разделами, которые действительно нужны команде разработки.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный технический писатель с глубоким пониманием разработки программного обеспечения»].
Составь техническое задание для разработки [опишите фичу, например, «модуля уведомлений в мобильном приложении для доставки еды»].
Контекст: [опишите продукт и аудиторию, например, «приложение для курьеров на Android и iOS, 50 000 активных пользователей, команда из 4 разработчиков»].
Требования бизнеса: [перечислите, что хочет заказчик, например, «пуш-уведомления о новых заказах, возможность отключить звук, история уведомлений за 7 дней»].
Структура документа:
- Цель и контекст задачи
- Описание пользовательских сценариев (не менее 3)
- Функциональные требования (список)
- Нефункциональные требования (производительность, безопасность, совместимость)
- Что явно выходит за рамки задачи (ограничения)
- Открытые вопросы, которые нужно уточнить до начала разработки
Стиль – четкий, технический, без воды. Объем – достаточный для понимания, без избыточных деталей.
*****
Почему это работает: Блок «что за рамками задачи» и список открытых вопросов – это то, что чаще всего пропускают, а именно из-за этого потом возникают споры и переделки в середине разработки.
3. Разбор сложного фрагмента кода для объяснения команде
Проблема: Тимлид понимает, как работает запутанный кусок кода, но объяснить это пятерым разработчикам разного уровня за 10 минут – уже другая задача.
Решение: Промпт создает понятное объяснение кода с аналогиями и пошаговой логикой, адаптированное под уровень аудитории.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный технический наставник, который умеет объяснять сложный код простым языком»].
Разбери следующий фрагмент кода и объясни его команде разработчиков.
Код: [вставьте код]
Язык/стек: [укажите, например, «Python, асинхронный код с использованием asyncio»]
Уровень аудитории: [укажите, например, «смешанная команда: 2 джуниора, 3 мидла, 1 синьор»]
Формат объяснения:
– Что делает этот код в целом (1–2 предложения, понятные джуниору)
– Разбор по блокам: что делает каждая часть и почему именно так
– Неочевидные моменты и подводные камни в этом коде
– Аналогия из реальной жизни, которая помогает понять логику
– Вопросы для проверки понимания (2–3 штуки для самопроверки команды)
Тон – объясняющий, без снисхождения. Никаких «это же очевидно».
*****
Почему это работает: Аналогия из реальной жизни и вопросы для самопроверки переводят пассивное слушание в активное понимание – разработчики не просто слышат объяснение, а проверяют, дошло ли до них.
4. Составление плана развития разработчика на квартал
Проблема: «Расти профессионально» – это не план. Тимлиды часто дают общие советы вместо конкретного маршрута с измеримыми результатами, и через три месяца оба не помнят, о чем договаривались.
Решение: Промпт создает конкретный план развития с задачами, сроками и критериями успеха под конкретного человека.
Текст промпта:
*****
Ты – [укажите роль, например, «инженерный менеджер с опытом построения индивидуальных планов развития для разработчиков»].
Составь план профессионального развития разработчика на ближайший квартал (13 недель).
Данные о разработчике:
– Уровень: [укажите, например, «мидл-разработчик, 2 года в компании»]
– Стек: [укажите, например, «Python, PostgreSQL, базовые знания Kubernetes»]
– Сильные стороны: [перечислите, например, «аккуратный код, хорошее покрытие тестами, надежность»]
– Зоны роста: [перечислите, например, «системное мышление, слабое понимание архитектурных решений, избегает сложных задач»]
– Цель разработчика: [укажите, например, «хочет дорасти до синьора через год»]
Структура плана:
- Фокус квартала (1–2 ключевых направления, не больше)
- Конкретные задачи по каждому направлению (с примерами, что именно делать)
- Ресурсы (книги, практика, задачи в проекте)
- Контрольные точки (раз в 3–4 недели: что должно быть сделано)
- Как тимлид поймет, что цель достигнута (критерии)
Стиль – конкретный, без воды. Никаких абстрактных «изучить архитектуру».
*****
Почему это работает: Ограничение до 1–2 фокусных направлений критически важно – когда целей больше, они все превращаются в фон, и ни одна не выполняется.
5. Написание обратной связи по результатам ревью кода
Проблема: Комментарии в ревью либо слишком мягкие («можно было бы подумать об оптимизации»), либо слишком резкие – и в обоих случаях разработчик не понимает, что именно нужно изменить и почему.
Решение: Промпт формирует структурированную, конкретную и конструктивную обратную связь, которую можно напрямую использовать в комментариях к коду.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный тимлид с сильными навыками конструктивной обратной связи»].
Напиши обратную связь по результатам код-ревью для разработчика.
Контекст: [опишите ситуацию, например, «мидл-разработчик сдал пул-реквест с реализацией нового эндпоинта, код работает, но есть проблемы с читаемостью и обработкой ошибок»]
Конкретные замечания, которые нужно донести: [перечислите, например, «функции слишком длинные, нет разбивки на смысловые блоки; ошибки обрабатываются только в одном месте, а не там, где они возникают; переменные названы непонятно»]
Формат обратной связи:
– Начни с того, что сделано хорошо (конкретно, не формально)
– Основные замечания: каждое с объяснением «почему это проблема» и примером как лучше
– Приоритет замечаний: что критично исправить сейчас, что можно улучшить потом
– Завершающая фраза, которая поддерживает, не обесценивает
Тон – прямой, уважительный, без пассивной агрессии. Никаких намеков – только конкретика.
*****
Почему это работает: Разделение замечаний на «критично сейчас» и «можно потом» снимает ощущение, что все плохо, и помогает разработчику расставить приоритеты без стресса.
6. Подготовка к сложному разговору с разработчиком о производительности
Проблема: Разговор о том, что человек работает плохо – один из самых некомфортных для тимлида. Многие откладывают его месяцами, а потом проводят в формате ультиматума, что только усугубляет ситуацию.
Решение: Промпт помогает структурировать сложный разговор так, чтобы он был честным, конкретным и направленным на решение, а не на обвинение.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный инженерный менеджер, специализирующийся на сложных разговорах о производительности»].
Помоги подготовиться к разговору с разработчиком о снижении производительности.
Контекст: [опишите ситуацию, например, «разработчик работает в команде 1,5 года, последние 2 месяца срывает сроки, качество кода ухудшилось, на встречах стал пассивным. Личных разговоров на эту тему еще не было»]
Что известно о возможных причинах: [укажите, например, «возможно выгорание, недавно сменился проект, новые задачи сложнее предыдущих»]
Составь:
- Как начать разговор (первые 2–3 предложения, которые задают правильный тон)
- Конкретные факты для обсуждения (без обобщений вроде «ты всегда опаздываешь»)
- Открытые вопросы, которые помогут понять причину, а не только зафиксировать проблему
- Как сформулировать ожидания на следующий период (конкретно и измеримо)
- Как завершить разговор с ощущением движения вперед, а не тупика
Тон подготовки – прямой, без мягкотелости и без агрессии. Цель – помочь человеку, а не поставить галочку.
*****
Почему это работает: Опора на конкретные факты вместо обобщений – это принципиальный момент: «в трех последних спринтах задачи закрывались с опозданием на 2–4 дня» воспринимается как информация, а «ты всегда опаздываешь» – как нападение.
7. Описание архитектурного решения для нетехнической аудитории
Проблема: Тимлид принял технически верное решение, но не может объяснить его продуктовому менеджеру или директору так, чтобы те поняли ценность и не начали сомневаться в разумности трат.
Решение: Промпт переводит техническое решение на язык бизнеса с понятными аналогиями и обоснованием через последствия.
Текст промпта:
*****
Ты – [укажите роль, например, «технический директор с опытом коммуникации между командой разработки и бизнесом»].
Опиши архитектурное решение для нетехнической аудитории.
Техническое решение: [опишите, например, «переход с монолитной архитектуры на микросервисы для модуля обработки заказов»]
Аудитория: [укажите, например, «продуктовый директор и финансовый директор, без технического бэкграунда»]
Контекст решения: [опишите, например, «текущий монолит не справляется с ростом нагрузки в пиковые часы, каждый месяц теряем 15–20% заказов из-за падений системы»]
Структура объяснения:
- В чем проблема сейчас (через последствия для бизнеса, не через технику)
- Что предлагается сделать (через аналогию, понятную без технических знаний)
- Что это даст через 3 и 6 месяцев (конкретные измеримые результаты)
- Какие риски есть и как они управляются
- Что будет, если не делать это сейчас
Длина – не более одной страницы. Никаких технических терминов без объяснения. Никакого снисхождения – уважительно и по делу.
*****
Почему это работает: Блок «что будет, если не делать» – самый убедительный раздел для нетехнической аудитории, потому что переводит разговор из режима «расходы» в режим «риски».
8. Планирование спринта и расстановка приоритетов задач
Проблема: Бэклог растет быстрее, чем команда успевает работать, а все задачи объявляются срочными. Тимлид тратит часы на обсуждение приоритетов вместо того, чтобы просто начать работать.
Решение: Промпт структурирует задачи по реальным приоритетам с обоснованием и помогает сформировать спринт, который команда действительно выполнит.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный скрам-мастер и технический руководитель с опытом планирования итераций разработки»].
Помоги спланировать спринт и расставить приоритеты задач.
Задачи из бэклога: [перечислите задачи с кратким описанием, например:
– «Исправить ошибку авторизации на iOS (баг, влияет на 12% пользователей)»
– «Добавить фильтрацию в каталоге (запрос от продакта)»
– «Рефакторинг модуля платежей (технический долг)»
– «Интеграция с новой платежной системой (бизнес-требование к следующему кварталу)»]
Емкость команды: [укажите, например, «4 разработчика, спринт 2 недели, один в отпуске первую неделю»]
Критерии приоритизации: [укажите, например, «влияние на пользователей, бизнес-обязательства, технические риски»]
Составь:
- Рекомендуемый список задач в спринт с обоснованием каждого выбора
- Что оставить за рамками спринта и почему
- Риски спринта (что может пойти не так)
- Как распределить задачи с учетом емкости команды
Формат – структурированный список с короткими обоснованиями. Без воды.
*****
Почему это работает: Явное обоснование каждого выбора делает планирование прозрачным – команда понимает логику, а не просто получает список сверху, что снижает сопротивление и споры.
9. Написание вакансии для найма разработчика в команду
Проблема: Большинство вакансий для разработчиков – это копипаст из интернета с бесконечным списком технологий и фразой «дружный коллектив». Такие объявления не привлекают сильных кандидатов, потому что сильные умеют читать между строк.
Решение: Промпт создает честную и привлекательную вакансию, которая отражает реальность команды и фильтрует неподходящих кандидатов еще на этапе прочтения.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный технический рекрутер с пониманием разработки программного обеспечения»].
Напиши вакансию для найма разработчика в команду.
Позиция: [укажите, например, «бэкенд-разработчик Python, уровень мидл/синьор»]
О команде и продукте: [опишите честно, например, «команда из 6 разработчиков, работаем над платформой для управления складом, продукт используют 200+ компаний, технический долг есть, но активно работаем с ним»]
Стек: [укажите, например, «Python, FastAPI, PostgreSQL, Redis, Kubernetes, GitLab CI»]
Что реально предстоит делать: [перечислите, например, «разрабатывать новые модули, участвовать в архитектурных решениях, проводить ревью, помогать джуниорам»]
Что важно в кандидате: [укажите, например, «умение объяснять решения, самостоятельность, готовность работать с неопределенностью»]
Структура вакансии:
- Цепляющий первый абзац (зачем сюда идти)
- Честное описание задач (без приукрашивания)
- Требования (разделить: обязательное и желательное)
- Что предлагается (конкретно, без «конкурентной зарплаты»)
- Как проходит отбор (чтобы кандидат понимал, чего ожидать)
Тон – живой, честный, без корпоративного шаблона.
*****
Почему это работает: Честное описание задач и явное разделение требований на обязательные и желательные резко повышают качество входящих откликов – люди лучше понимают, подходят ли они, еще до отправки резюме.
10. Проведение технического интервью: составление вопросов
Проблема: Технические интервью часто проверяют способность решать алгоритмические задачки за 40 минут, а не реальные навыки, которые нужны в работе. В результате нанимают тех, кто умеет готовиться к интервью, а не тех, кто умеет работать.
Решение: Промпт создает набор вопросов, которые проверяют именно те навыки, что нужны на конкретной позиции, с разными форматами проверки.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный технический интервьюер с пониманием того, какие навыки реально важны в работе разработчика»].
Составь набор вопросов для технического интервью на позицию [укажите позицию, например, «мидл Python-разработчика в продуктовой команде»].
Стек и контекст: [укажите, например, «Python, FastAPI, PostgreSQL, работа в продуктовой команде с быстрыми итерациями, много неопределенности в требованиях»]
Что важно проверить: [перечислите, например, «понимание асинхронного программирования, работа с базами данных, умение принимать решения в условиях неопределенности, коммуникация»]
Составь:
– 3 вопроса на техническое понимание (с ожидаемыми ответами и красными флагами)
– 2 практических задачи (небольшие, решаемые за 15–20 минут)
– 3 ситуационных вопроса (как кандидат действовал в реальных ситуациях)
– 2 вопроса на понимание архитектурных компромиссов
Для каждого вопроса укажи: что именно проверяется и что является признаком сильного ответа.
Тон – профессиональный, без снисхождения к кандидату.
*****
Почему это работает: Ситуационные вопросы о реальном опыте дают несравнимо больше информации, чем абстрактные задачи, потому что прошлое поведение – лучший предсказатель будущего.
11. Составление плана онбординга нового разработчика
Проблема: Новый человек приходит в команду и первые две недели занимается тем, что пытается понять, к кому обращаться, где документация и почему вот этот модуль написан именно так. Тимлид при этом занят своими задачами и не может постоянно отвечать на вопросы.
Решение: Промпт создает структурированный план адаптации, который позволяет новому разработчику стать продуктивным за 2–4 недели без постоянного сопровождения.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный тимлид с многолетним опытом выстраивания процессов адаптации новых сотрудников»].
Составь план онбординга для нового разработчика.
Контекст: [опишите ситуацию, например, «бэкенд-разработчик, уровень мидл, выходит через неделю, команда из 5 человек, продукт – CRM для малого бизнеса, стек Python/Django/PostgreSQL»]
Первый рабочий месяц разбей на недели:
Неделя 1: [что должно произойти в первую неделю – знакомство, доступы, первое погружение]
Неделя 2: [первые задачи, понимание архитектуры, знакомство с процессами]
Неделя 3–4: [самостоятельная работа с поддержкой, участие в ревью, первый небольшой вклад в продукт]
Для каждой недели укажи:
– Конкретные задачи и активности
– Кто отвечает за каждый блок (тимлид, ментор, коллега)
– Что должен знать/уметь разработчик к концу недели
Добавь список: что нужно подготовить до выхода человека (доступы, документация, первая задача).
Формат – структурированный по неделям, конкретный.
*****
Почему это работает: Четкое распределение ответственности между тимлидом, ментором и коллегами снимает с одного человека всю нагрузку по адаптации и делает процесс устойчивым.
12. Анализ технического долга и подготовка обоснования для бизнеса
Проблема: Технический долг накапливается годами, а тимлид не может объяснить бизнесу, почему нужно тратить время на «непонятные рефакторинги» вместо новых фич. Бизнес слышит «нам нужно переписать код» и видит только потерянное время.
Решение: Промпт помогает перевести технический долг в бизнес-язык с конкретными последствиями и обоснованием инвестиций.
Текст промпта:
*****
Ты – [укажите роль, например, «технический директор с опытом обоснования технических инвестиций перед бизнесом»].
Помоги подготовить обоснование работы с техническим долгом для нетехнической аудитории.
Описание технического долга: [опишите конкретно, например, «устаревшая библиотека авторизации, которую уже не поддерживают; монолитный модуль отчетов, который тормозит всю систему при нагрузке; отсутствие автоматических тестов в 60% кодовой базы»]
Текущие последствия для бизнеса: [опишите, например, «каждая новая фича в модуле отчетов занимает в 3 раза больше времени, чем должна; раз в месяц система падает под нагрузкой»]
Что предлагается сделать: [опишите, например, «выделить 20% емкости команды на технический долг в течение квартала»]
Составь документ:
- Что происходит сейчас (через бизнес-последствия, без технических деталей)
- Что будет через 6–12 месяцев, если ничего не делать
- Что предлагается и сколько это займет
- Что бизнес получит в результате (конкретные измеримые улучшения)
- Риски предложения и как они управляются
Длина – не более двух страниц. Тон – деловой, конкретный, без технического жаргона.
*****
Почему это работает: Сценарий «что будет, если ничего не делать» переводит разговор из режима затрат в режим управления рисками, что значительно проще продать любому руководителю.
13. Подготовка повестки командной встречи
Проблема: Командные встречи без структуры превращаются в дискуссионный клуб: обсуждают все подряд, принимают ноль решений и расходятся с ощущением потраченного часа. Тимлид виноват – он не подготовил повестку.
Решение: Промпт создает четкую повестку с таймингом, ответственными и ожидаемыми результатами по каждому пункту.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный фасилитатор командных встреч и технический руководитель»].
Составь повестку для командной встречи.
Цель встречи: [укажите, например, «ретроспектива спринта и планирование следующего»]
Участники: [перечислите, например, «5 разработчиков, продуктовый менеджер, тимлид»]
Длительность: [укажите, например, «90 минут»]
Ключевые темы для обсуждения: [перечислите, например, «разбор того, почему не успели с задачей по интеграции; обсуждение нового процесса ревью; приоритеты следующего спринта»]
Составь повестку с:
– Точным таймингом каждого блока
– Форматом каждого блока (обсуждение, голосование, информирование, мозговой штурм)
– Ответственным за каждый блок
– Ожидаемым результатом (что должно быть принято/решено)
– Правилами встречи (2–3 коротких, которые стоит озвучить в начале)
Также добавь: что нужно подготовить участникам заранее.
Формат – таблица или структурированный список. Четко и по делу.
*****
Почему это работает: Ожидаемый результат по каждому пункту повестки – это то, что отличает продуктивную встречу от разговора ни о чем: участники знают, зачем они здесь, и встреча заканчивается конкретными решениями.
14. Написание постмортема после инцидента
Проблема: После падения системы команда разбирает причины, находит виноватого и идет дальше. Через три месяца происходит то же самое. Настоящий постмортем – это не поиск виноватых, а системный анализ, который предотвращает повторение.
Решение: Промпт создает структурированный постмортем, ориентированный на системные причины и конкретные улучшения процессов.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный инженер надежности с опытом проведения анализа инцидентов без поиска виноватых»].
Напиши постмортем по произошедшему инциденту.
Описание инцидента: [опишите, например, «16 ноября с 14:30 до 17:15 сервис оплаты был недоступен для 100% пользователей. Причина – деплой новой версии без отката на случай ошибки. 847 транзакций не были обработаны»]
Хронология событий: [опишите по шагам, например, «14:30 – деплой; 14:45 – первые сообщения об ошибках; 15:00 – инцидент подтвержден; 16:00 – начат откат; 17:15 – сервис восстановлен»]
Структура постмортема:
- Краткое резюме (3–5 предложений)
- Временная шкала инцидента
- Анализ первопричин (не «кто виноват», а «что в системе/процессе привело к этому»)
- Что сработало хорошо
- Что можно улучшить
- Конкретный план действий (с ответственными и сроками)
Тон – аналитический, без обвинений. Принцип: система подвела, не люди.
*****
Почему это работает: Явное разделение «анализ причин» и «план действий» – это то, что превращает постмортем из формальности в реальный инструмент улучшения: без конкретных шагов с ответственными документ остается красивым текстом.
15. Создание системы метрик для оценки продуктивности команды
Проблема: Тимлиды либо не измеряют продуктивность команды вообще, либо измеряют количество закрытых задач – что приводит к дроблению задач на мелкие части ради красивых цифр.
Решение: Промпт создает систему метрик, которая отражает реальную эффективность команды, а не создает стимулы для игры с показателями.
Текст промпта:
*****
Ты – [укажите роль, например, «инженерный менеджер с опытом выстраивания измеримых систем оценки команд разработки»].
Разработай систему метрик для оценки эффективности команды разработки.
Контекст: [опишите, например, «продуктовая команда из 6 разработчиков, работаем по двухнедельным итерациям, основная проблема – непредсказуемость сроков и накопление технического долга»]
Что важно измерять: [укажите приоритеты, например, «предсказуемость поставок, качество кода, скорость обнаружения и исправления ошибок, нагрузка на команду»]
Составь систему метрик:
– 4–6 ключевых показателей с объяснением, что именно они измеряют
– Для каждого показателя: как собирать данные, как часто, что считается нормой, что является сигналом тревоги
– Что эти метрики НЕ измеряют (чтобы не было иллюзий)
– Как использовать эти данные на практике (не для контроля людей, а для улучшения процессов)
Тон – аналитический. Никаких метрик ради метрик.
*****
Почему это работает: Явное указание на то, что метрики не измеряют, – это защита от типичной ловушки, когда показатели начинают управлять поведением людей вместо того, чтобы отражать реальность.
16. Написание документации по архитектуре системы
Проблема: Архитектурная документация либо отсутствует, либо устарела на два года, либо написана так, что понять ее может только автор – и то не всегда.
Решение: Промпт создает структурированную архитектурную документацию, которую реально читают и поддерживают в актуальном состоянии.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный технический архитектор с навыками написания понятной технической документации»].
Напиши архитектурную документацию для системы.
Описание системы: [опишите, например, «сервис обработки заказов для маркетплейса: принимает заказы от пользователей, передает в систему склада, отслеживает статусы, уведомляет пользователей»]
Стек и компоненты: [перечислите, например, «Python/FastAPI, PostgreSQL, Redis для очередей, интеграция с внешним сервисом склада через REST API»]
Аудитория документации: [укажите, например, «новые разработчики команды и смежные команды, которые интегрируются с нашим сервисом»]
Структура документа:
- Обзор системы (что делает, кто использует, какие проблемы решает)
- Архитектурная схема (описание компонентов и связей между ними текстом)
- Ключевые архитектурные решения (почему именно так, какие альтернативы рассматривались)
- Потоки данных (основные сценарии шаг за шагом)
- Внешние зависимости и интеграции
- Известные ограничения и технический долг
- Как развернуть локально (кратко)
Стиль – четкий, технический, но понятный. Никаких очевидных вещей ради объема.
*****
Почему это работает: Раздел «почему именно так» – самый ценный в архитектурной документации, потому что через год никто не помнит, почему было принято то или иное решение, и начинают его переделывать, наступая на те же грабли.
17. Подготовка аргументов для переговоров о ресурсах команды
Проблема: Тимлид понимает, что команде нужен еще один разработчик, но не знает, как убедить в этом руководство, которое видит только бюджет и слышит «нам не хватает людей» от каждого отдела.
Решение: Промпт помогает подготовить обоснование расширения команды через бизнес-язык с конкретными цифрами и последствиями.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный инженерный менеджер с навыками переговоров о ресурсах с руководством»].
Помоги подготовить обоснование для найма дополнительного разработчика в команду.
Текущая ситуация: [опишите, например, «команда из 4 разработчиков ведет 3 параллельных продуктовых направления, последние 3 квартала срываем сроки на 30–40%, технический долг растет, команда работает сверхурочно»]
Что изменится с новым человеком: [опишите, например, «сможем выделить одно направление отдельному разработчику, снизить переключение контекста, вернуться к нормальному темпу работы»]
Что потеряет бизнес без найма: [укажите, например, «продолжим срывать сроки, риск выгорания и ухода ключевых людей из команды»]
Составь:
- Краткое резюме ситуации (для руководителя, который читает 2 минуты)
- Текущая стоимость проблемы (через потери: время, сроки, риск ухода людей)
- Что конкретно изменится с новым человеком (измеримо)
- Стоимость найма vs. стоимость бездействия
- Предложение: что именно нужно и когда
Тон – деловой, конкретный. Никакого нытья, только факты и логика.
*****
Почему это работает: Сравнение «стоимость найма vs. стоимость бездействия» переводит разговор из режима расходов в режим инвестиций – руководителю проще принять решение, когда он видит, что обходится ему дороже.
18. Написание шаблона для регулярного статус-отчета команды
Проблема: Статус-отчеты либо занимают полчаса на написание и никто их не читает, либо настолько поверхностны, что несут ноль информации. Оба варианта – потеря времени.
Решение: Промпт создает шаблон отчета, который пишется за 10 минут и содержит только то, что нужно руководству для принятия решений.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный технический руководитель с навыками эффективной коммуникации с руководством»].
Создай шаблон еженедельного статус-отчета команды разработки.
Аудитория отчета: [укажите, например, «директор по разработке и продуктовый директор, нетехническая аудитория»]
Периодичность: [укажите, например, «раз в неделю, по пятницам»]
Что важно отражать: [перечислите, например, «прогресс по ключевым направлениям, риски и блокеры, что нужно от руководства, план на следующую неделю»]
Требования к шаблону:
– Заполняется за 10–15 минут
– Читается за 3–5 минут
– Содержит только то, что влияет на решения руководства
– Использует светофорную систему (зеленый/желтый/красный) для быстрой оценки статуса
Создай шаблон с:
– Фиксированной структурой разделов
– Примером заполнения для каждого раздела
– Инструкцией: что писать, а что не писать в каждом разделе
Стиль – лаконичный, деловой.
*****
Почему это работает: Светофорная система и строгий лимит времени на заполнение и чтение – это то, что превращает отчет из формальности в реальный инструмент управления: руководитель за 3 минуты видит картину и знает, где нужно вмешаться.
19. Разработка системы проведения код-ревью в команде
Проблема: Без четких правил ревью каждый разработчик делает его по-своему: один пишет роман в комментариях, другой ставит «ок» не глядя. Качество кода непредсказуемо, а конфликты из-за разных стандартов съедают время и нервы.
Решение: Промпт создает конкретные правила и процесс ревью, которые выравнивают стандарты в команде.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный тимлид с многолетним опытом выстраивания процессов качества кода в командах разработки»].
Разработай систему проведения код-ревью для команды.
Контекст: [опишите, например, «команда из 5 разработчиков разного уровня (1 джуниор, 3 мидла, 1 синьор), работаем с Python/Django, ревью сейчас хаотичное: нет единых стандартов, ревью затягивается на 2–3 дня»]
Проблемы, которые нужно решить: [перечислите, например, «долгое ожидание ревью, неконструктивные комментарии, разные стандарты у разных ревьюеров»]
Составь систему, включающую:
- Правила для автора пул-реквеста (что сделать перед отправкой на ревью)
- Правила для ревьюера (что проверять, как комментировать, тайминг)
- Классификация замечаний (что блокирует слияние, что желательно, что на усмотрение)
- Процесс разрешения разногласий (когда ревьюер и автор не сходятся)
- Метрики: как понять, что процесс работает хорошо
Формат – четкий, готовый к использованию как внутренний регламент. Без воды.
*****
Почему это работает: Классификация замечаний по степени критичности – это ключевое: когда ревьюер не разделяет «это блокирует» и «это было бы лучше», автор воспринимает все замечания как равнозначные и либо исправляет все, либо игнорирует все.
20. Составление карьерной лестницы для разработчиков команды
Проблема: Разработчик не понимает, что нужно сделать для перехода на следующий уровень, и либо уходит в другую компанию, где это объяснят, либо остается и теряет мотивацию. Тимлид теряет хорошего человека в обоих случаях.
Решение: Промпт создает прозрачную карьерную лестницу с конкретными критериями для каждого уровня.
Текст промпта:
*****
Ты – [укажите роль, например, «инженерный директор с опытом построения систем карьерного роста в командах разработки»].
Составь карьерную лестницу для разработчиков команды.
Контекст: [опишите, например, «продуктовая команда бэкенд-разработчиков, стек Python, нужны уровни от джуниора до тимлида»]
Уровни: [перечислите, например, «джуниор, мидл, синьор, тимлид»]
Для каждого уровня опиши:
– Технические навыки (конкретно, с примерами задач, которые человек решает самостоятельно)
– Самостоятельность и зона ответственности
– Вклад в команду (ревью, менторство, процессы)
– Коммуникация и работа со стейкхолдерами
– Типичные признаки, что человек готов к следующему уровню
Добавь:
– Что НЕ является критерием повышения (частые заблуждения)
– Как тимлид использует эту лестницу в разговорах о росте
Формат – структурированный по уровням, конкретный, без абстракций вроде «демонстрирует лидерские качества».
*****
Почему это работает: Явное указание на то, что не является критерием повышения, устраняет самые распространенные заблуждения – например, что повышение зависит от стажа или от того, насколько человек нравится тимлиду.
21. Написание технического раздела для презентации продукта
Проблема: Тимлид умеет строить системы, но объяснить инвесторам или партнерам, почему техническое решение надежно и масштабируемо – это отдельный навык, которому нигде не учат.
Решение: Промпт создает технический раздел презентации, который убедителен для нетехнической аудитории и не теряет сути для технической.
Текст промпта:
*****
Ты – [укажите роль, например, «технический директор с опытом представления технических решений инвесторам и партнерам»].
Напиши технический раздел для презентации продукта.
Продукт: [опишите, например, «платформа для автоматизации бухгалтерской отчетности для малого бизнеса»]
Аудитория презентации: [укажите, например, «потенциальные инвесторы, преимущественно без технического бэкграунда»]
Технические преимущества, которые нужно донести: [перечислите, например, «обработка данных в реальном времени, интеграция с 1С и Контуром, соответствие требованиям ФНС, масштабируемость до 100 000 компаний»]
Структура раздела (3–4 слайда):
– Слайд 1: Почему наш технический подход решает проблему лучше (через результат, не через технологии)
– Слайд 2: Надежность и безопасность (что это значит для пользователя)
– Слайд 3: Масштабируемость (что позволяет расти без переделки всего с нуля)
– Слайд 4: Технические риски и как мы с ними работаем
Для каждого слайда: тезис, 2–3 ключевых пункта, метафора или аналогия для нетехнической аудитории.
Тон – уверенный, конкретный, без технического жаргона.
*****
Почему это работает: Слайд о технических рисках и управлении ими парадоксально повышает доверие аудитории – команда, которая честно говорит о рисках, воспринимается как более зрелая, чем та, которая обещает, что все идеально.
22. Анализ причин ухода разработчика из команды
Проблема: Когда разработчик уходит, тимлид обычно проводит короткое прощальное интервью, выясняет, что «все было хорошо, просто интересное предложение», и теряет реальную причину. Паттерн повторяется со следующим человеком.
Решение: Промпт помогает подготовиться к глубокому выходному интервью и проанализировать системные причины ухода.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный инженерный менеджер с навыками проведения выходных интервью и анализа причин текучести»].
Помоги подготовиться к выходному интервью с разработчиком и проанализировать возможные системные причины ухода.
Контекст: [опишите ситуацию, например, «синьор-разработчик работал 2 года, последние полгода был менее активен, принял оффер в другой компании, официальная причина – более высокая зарплата»]
Что известно о ситуации: [опишите, например, «за полгода сменился продукт, которым он занимался; недавно был конфликт с коллегой по архитектурному решению»]
Составь:
- Вопросы для выходного интервью (7–10 открытых вопросов, которые помогут узнать реальные причины)
- Что слушать «между строк» (типичные формулировки и что за ними стоит)
- Анализ: какие системные факторы могли повлиять на решение уйти
- Что тимлид может сделать, чтобы не повторить это с другими людьми
Тон подготовки – аналитический. Цель – понять, а не оправдаться.
*****
Почему это работает: Расшифровка типичных формулировок («интересное предложение» часто означает «здесь мне было неинтересно») превращает формальное интервью в реальный источник информации для улучшения команды.
23. Составление технического задания для внешнего подрядчика
Проблема: Подрядчик сделал «все по заданию», а результат не совпадает с ожиданиями. Причина почти всегда одна: задание было написано так, что каждый понимал его по-своему.
Решение: Промпт создает техническое задание для внешней команды с такой степенью конкретности, что двойных трактовок почти не остается.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный технический менеджер с опытом работы с внешними подрядчиками и аутсорсинговыми командами»].
Составь техническое задание для внешнего подрядчика.
Задача: [опишите, например, «разработать модуль интеграции нашей системы с внешней системой ЭДО Диадок»]
Контекст: [опишите, например, «наша система – CRM на Python/Django, интеграция нужна для автоматической отправки документов клиентам, срок – 6 недель»]
Ограничения: [перечислите, например, «использовать только официальное API Диадока, код должен покрываться тестами минимум на 80%, документация обязательна»]
Структура технического задания:
- Цель и контекст задачи
- Технические требования (детально, с примерами форматов данных где нужно)
- Требования к качеству (тесты, документация, стиль кода)
- Процесс сдачи работы (этапы, как проверяем)
- Критерии приемки (конкретные, измеримые – что должно работать)
- Что за рамками задачи (явно)
- Контактные лица и процесс коммуникации
Стиль – однозначный, без возможности двойной трактовки. Если что-то не указано – подрядчик обязан уточнить, а не придумывать.
*****
Почему это работает: Явное указание «что за рамками задачи» и конкретные критерии приемки – это два раздела, которые чаще всего пропускают, и именно они являются источником 80% конфликтов с подрядчиками.
24. Подготовка к разговору о повышении зарплаты разработчика
Проблема: Тимлид понимает, что человек заслуживает повышения, но не знает, как обосновать это перед HR или руководством так, чтобы получить «да», а не «рассмотрим в следующем году».
Решение: Промпт помогает подготовить конкретное обоснование повышения через вклад человека и рыночный контекст.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный инженерный менеджер с навыками ведения переговоров о компенсации сотрудников»].
Помоги подготовить обоснование повышения зарплаты для разработчика.
Данные о разработчике: [опишите, например, «мидл-разработчик, работает 1,5 года, последние полгода де-факто выполняет функции синьора: ведет архитектурные обсуждения, менторит джуниора, закрывает самые сложные задачи»]
Текущая зарплата: [укажите, например, «180 000 рублей»]
Желаемое повышение: [укажите, например, «до 230 000 рублей»]
Рыночный контекст: [укажите, например, «по данным последних обзоров, синьор Python-разработчик в Москве – 220–280 тысяч рублей»]
Составь:
- Краткое резюме вклада человека за последние полгода (конкретные примеры)
- Обоснование через рыночный контекст
- Риск потери человека и его стоимость (замена разработчика обходится в X зарплат)
- Предложение: конкретная сумма и срок
- Ответы на типичные возражения (бюджет, «подождем следующего года»)
Тон – деловой, фактический. Никаких «он очень старается».
*****
Почему это работает: Включение стоимости замены сотрудника – это тот аргумент, который переводит разговор из «расход на зарплату» в «инвестиция в удержание», и именно он чаще всего меняет позицию руководства.
25. Создание шаблона для технического задания на рефакторинг
Проблема: Рефакторинг часто начинается с «перепишем вот этот модуль» и заканчивается тем, что переписали все, ничего не улучшили и потратили три спринта. Причина – не было четкого задания с критериями успеха.
Решение: Промпт создает структурированное задание на рефакторинг с измеримыми целями и четкими границами.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный технический руководитель с пониманием процессов улучшения качества кодовой базы»].
Составь техническое задание на рефакторинг.
Что нужно переработать: [опишите, например, «модуль обработки платежей: 3000 строк кода, функции по 200–300 строк, нет тестов, сложно добавлять новые платежные системы»]
Почему это нужно: [опишите, например, «каждая новая интеграция занимает 3–4 недели вместо одной, последние два квартала это блокирует бизнес-цели»]
Что должно получиться: [опишите желаемый результат, например, «модульная структура, каждая платежная система – отдельный адаптер, покрытие тестами 80%+, новая интеграция занимает не более недели»]
Структура задания:
- Текущее состояние (что не так и почему это проблема)
- Целевое состояние (конкретно, с измеримыми критериями)
- Что явно НЕ меняется (чтобы не уйти в бесконечный рефакторинг)
- Этапы работы (с промежуточными результатами)
- Критерии приемки (как поймем, что готово)
- Риски и как их снизить
Стиль – технический, четкий. Никаких абстрактных целей.
*****
Почему это работает: Явное указание «что НЕ меняется» – это защита от scope creep, когда рефакторинг постепенно захватывает все больше кода и никогда не заканчивается, потому что всегда есть что улучшить.
26. Написание сообщения об инциденте для пользователей и стейкхолдеров
Проблема: Когда система падает, первый инстинкт – замолчать и быстро починить. Но пользователи уже пишут в поддержку, а руководство узнает о проблеме последним и злится вдвойне. Плохая коммуникация во время инцидента наносит репутационный ущерб больше, чем сам инцидент.
Решение: Промпт создает правильно структурированное сообщение об инциденте для разных аудиторий на разных этапах.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный технический руководитель с навыками антикризисной коммуникации»].
Напиши сообщения об инциденте для разных аудиторий.
Описание инцидента: [опишите, например, «сервис оплаты недоступен с 15:30, причина выясняется, примерное время восстановления – 2 часа»]
Аудитории: [укажите, например, «пользователи сервиса, внутренняя команда, руководство компании»]
Для каждой аудитории составь:
– Сообщение на момент начала инцидента (что произошло, что делается, когда следующее обновление)
– Сообщение во время инцидента (промежуточный статус через час)
– Сообщение о восстановлении (что произошло, что сделали, что будет дальше)
Требования:
– Для пользователей: простой язык, без технических деталей, с конкретными рекомендациями что делать
– Для руководства: факты, масштаб влияния, статус, следующие шаги
– Для команды: технические детали, кто что делает, как координируемся
Тон – честный, спокойный, без паники и без преуменьшения проблемы.
*****
Почему это работает: Три разных сообщения для трех аудиторий – это принципиально важно: пользователям нужно знать, что делать прямо сейчас, руководству – масштаб и контроль над ситуацией, команде – координация и технические детали.
27. Подготовка к квартальному обзору работы команды
Проблема: Квартальные обзоры часто превращаются в перечисление закрытых задач, которое никому не интересно. Тимлид не знает, как представить работу команды так, чтобы это выглядело как реальный вклад в бизнес, а не просто список активностей.
Решение: Промпт помогает структурировать квартальный обзор через бизнес-ценность и конкретные результаты.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный технический директор с навыками представления результатов команды перед руководством»].
Помоги подготовить квартальный обзор работы команды разработки.
Что было сделано за квартал: [перечислите, например, «запустили модуль аналитики, исправили критические баги в модуле оплаты, провели рефакторинг авторизации, наняли и адаптировали нового разработчика»]
Метрики команды: [укажите, например, «предсказуемость поставок выросла с 60% до 82%, среднее время исправления критических багов снизилось с 4 часов до 1,5 часов»]
Что не получилось: [укажите честно, например, «не успели с интеграцией новой платежной системы, перенесли на следующий квартал»]
Планы на следующий квартал: [опишите, например, «интеграция платежной системы, работа с техническим долгом в модуле отчетов, найм еще одного разработчика»]
Структура обзора:
- Главные результаты квартала (через бизнес-ценность, не через задачи)
- Ключевые метрики (динамика, не просто цифры)
- Что не сделали и почему (честно, с выводами)
- Фокус следующего квартала
- Что нужно от руководства
Формат – для устной презентации 15–20 минут с опорными слайдами. Конкретно и по делу.
*****
Почему это работает: Представление результатов через бизнес-ценность, а не через список задач, меняет восприятие аудитории – руководство видит не «что делала команда», а «что получил бизнес».
28. Создание шаблона для принятия архитектурных решений
Проблема: Архитектурные решения принимаются на созвонах, фиксируются в чьей-то голове и через полгода никто не помнит, почему сделали именно так. Следующая команда переделывает все с нуля, наступая на те же грабли.
Решение: Промпт создает шаблон документирования архитектурных решений, который помогает принимать их осознанно и сохранять для будущего.
Текст промпта:
*****
Ты – [укажите роль, например, «опытный технический архитектор с пониманием процессов документирования технических решений»].
Создай шаблон для документирования архитектурных решений команды.
Контекст: [опишите, например, «продуктовая команда из 6 разработчиков, решения часто принимаются на созвонах и не фиксируются, через 3–6 месяцев никто не помнит обоснование»]
Требования к шаблону:
– Заполняется за 20–30 минут
– Содержит все, что нужно для понимания решения через год
– Фиксирует не только «что», но и «почему» и «какие альтернативы рассматривались»
– Достаточно легкий, чтобы команда реально его использовала
Структура шаблона:
- Название и дата решения
- Контекст (какая проблема решается)
- Рассмотренные варианты (минимум 2–3 с кратким описанием плюсов и минусов каждого)
- Принятое решение (что именно и почему)
- Последствия (что изменится, какие компромиссы приняты)
- Критерии пересмотра (при каких условиях это решение стоит пересмотреть)
Добавь пример заполнения шаблона на конкретном решении.
Стиль – лаконичный, структурированный, без бюрократии.
*****
Почему это работает: Раздел «критерии пересмотра» – это то, что отличает живой документ от архивного: команда знает, что решение не высечено в камне, и понимает, когда его стоит вернуться и переосмыслить.
Типичные ошибки при использовании промптов для тимлида
- Давать нейросети задачу без контекста о команде и ситуации. Результат будет универсальным и бесполезным – как инструкция по применению лекарства без диагноза.
- Копировать результат нейросети без редактуры и вставлять напрямую разработчику или руководству. Нейросеть не знает интонации отношений в команде, истории коммуникации и того, что между вами уже было сказано – и это всегда чувствуется в тексте.
- Использовать один промпт для принципиально разных ситуаций. Промпт для разговора о снижении производительности с джуниором через два месяца работы и с синьором через три года – это разные промпты, потому что это разные разговоры.
- Не уточнять уровень аудитории в промпте. Нейросеть по умолчанию пишет для среднего читателя, что означает либо слишком просто для технарей, либо слишком сложно для бизнеса.
- Ожидать готового результата с первой попытки для сложных задач. Промпты для деликатных разговоров, архитектурных обоснований и переговоров о ресурсах требуют итерации – первый вариант задает структуру, второй уточняет детали.
- Игнорировать раздел «почему работает» и просто копировать промпт. Понимание механики позволяет адаптировать шаблон под свою ситуацию, а не использовать его как шаблон на все случаи жизни – что почти никогда не совпадает с реальностью.
- Давать нейросети противоречивые требования внутри одного промпта. «Напиши коротко, но подробно» или «будь прямым, но мягким» – нейросеть попытается выполнить оба условия и не выполнит ни одного по-настоящему.
- Не указывать формат результата. Без явного указания формата нейросеть выдает текст в том виде, который кажется ей подходящим – а это может быть эссе вместо таблицы или список вместо нарратива.
Сравнение слабых и сильных запросов для тимлида: как формулировка меняет результат
| Задача тимлида | Слабый запрос | Сильный запрос (ключевые добавления) | Почему разница критична |
| Написать обратную связь по ревью | Напиши комментарии к коду разработчика | Напиши конструктивную обратную связь по пул-реквесту мидл-разработчика: начни с сильных сторон, выдели 3 конкретных замечания с объяснением «почему это проблема» и примером как лучше, раздели на критичные и некритичные | Без структуры получается список претензий; с ней – диалог, после которого хочется исправить, а не защититься |
| Подготовить план встречи один на один | Составь вопросы для встречи с разработчиком | Составь план встречи один на один с разработчиком, который последние три недели снизил активность. Нужны открытые вопросы по трем блокам: состояние человека, профессиональный рост, рабочий процесс. Формат – нумерованный список по блокам | Общие вопросы дают социально одобряемые ответы; ситуационные вопросы вытаскивают реальную информацию |
| Объяснить техническое решение бизнесу | Объясни что такое микросервисы простым языком | Объясни переход на микросервисы для финансового директора без технического бэкграунда: через проблему, которую это решает, через аналогию, через конкретный бизнес-результат через 6 месяцев и через риски | Объяснение технологии ради технологии не убеждает; объяснение через последствия для бизнеса – убеждает |
| Написать вакансию | Напиши вакансию Python-разработчика | Напиши честную вакансию мидл/синьор Python-разработчика: укажи реальные задачи (не шаблонные), раздели требования на обязательные и желательные, опиши команду и продукт без приукрашивания, объясни процесс отбора | Шаблонная вакансия привлекает случайных людей; честная – фильтрует неподходящих еще до отклика |
| Обосновать технический долг | Объясни почему нужно рефакторить код | Подготовь обоснование работы с техническим долгом для директора: через текущие бизнес-потери, через сценарий «что будет через год без действий», через конкретное предложение с измеримым результатом | Разговор о коде – это расход; разговор о бизнес-рисках – это управление инвестициями. Руководство слышит только второе |
| Подготовиться к сложному разговору | Помоги поговорить с разработчиком о проблемах | Помоги подготовиться к разговору о снижении производительности: как начать без обвинений, какие конкретные факты использовать (не обобщения), какие открытые вопросы помогут понять причину, как сформулировать ожидания измеримо | Без подготовки разговор становится ультиматумом; со структурой – диагностическим инструментом |
Неочевидные советы по работе с запросами для нейросети в роли тимлида
- Сохраняйте промпты, которые дали хороший результат, в отдельный файл с пометкой о контексте. Через три месяца та же ситуация повторится с другим разработчиком, и поиск рабочей формулировки заново – это потеря времени, которого и так нет.
- Давайте нейросети роль конкретного специалиста, а не просто «помощника». Запрос к «опытному инженерному менеджеру» и просто запрос без роли – это принципиально разные по глубине результаты, потому что роль задает угол зрения и приоритеты в ответе.
- Для деликатных задач – сначала попросите нейросеть задать вам уточняющие вопросы, а потом уже генерировать результат. Это особенно работает для сложных разговоров и переговоров: нейросеть вытаскивает детали, которые вы сами не подумали включить в запрос.
- Используйте нейросеть для игры в «адвоката дьявола» перед важными встречами. После подготовки аргументов попросите нейросеть выступить в роли скептичного директора и найти слабые места в вашей позиции – это эффективнее любой самопроверки.
- Указывайте в промпте, что именно вас не устраивает в типичных ответах на эту задачу. «Напиши план развития без абстрактных целей вроде ‘изучить архитектуру’, только конкретные задачи с примерами» – такое ограничение сразу отсекает 80% мусора.
- Для повторяющихся задач создайте мастер-шаблон промпта с заполнителями вместо конкретных данных. Шаблон для встречи один на один, шаблон для обоснования найма, шаблон для постмортема – это библиотека инструментов, которая работает на вас постоянно, а не только тогда, когда вы вспоминаете о нейросети.
- После получения результата просите нейросеть найти в нем то, что может не сработать в вашей конкретной ситуации. Нейросеть охотно критикует собственный вывод и часто указывает на реальные слабые места, которые стоит доработать перед использованием.
