Привет, Хабр! Меня зовут Артем Колчин, я Senior Project Manager (ранее Delivery Lead, а ещё ранее разраб на C# и аналитик) и автор курса «Мидл менеджер проектов» в Яндекс Практикуме.
Как менеджеру проектов мне важно находить и использовать инструменты, которые повысят эффективность работы команды и при этом не добавят новых проблем при внедрении. Проблема в том, что не всегда такие инструменты есть, а если они есть — непонятно, устроят ли они всех и помогут ли с процессами. В этой статье я поделюсь своим опытом и расскажу, как я использую нейросети для оптимизации процессов и быстрого прототипирования инструментов с нужным функционалом (чтобы понять, а точно ли нам нужно именно это).
Цель прототипирования — быстрая проверка гипотезы: «А точно ли нам это нужно?» и «А так ли мы представляем, как это будет работать?». Обидно потратить месяцы на внедрение какой-то внутренней новой системы, а потом обнаружить, что значительная часть функционала простаивает, а то, что реально было нужно, работает плохо.
Конечно, не для всего нужен прототип. Если задача стандартная — например, подключить уже отлаженный сервис для проведения встреч, тут проще взять готовое решение и допилить его под себя. Прототипирование оправдано именно там, где есть специфичные процессы: стандартные формы из Jira не ловят нужные метрики или корпоративный календарь не учитывает особенности вашей команды.
ИИ в этом плане немного поменял правила игры. Раньше для прототипирования любого внутреннего инструмента нужно было привлекать разработчика на какое-то время, а сейчас за пару часов можно собрать рабочий прототип. Да, он будет максимально простым, с кучей ограничений, но сразу позволит оценить, нужен ли нам именно этот функционал или же что-то другое. Дальше разберём, как нейросети могут помочь менеджеру с этим.
Если смотреть глобально, то задача менеджера — не просто поддерживать рабочие процессы, но стараться их оптимизировать и улучшать. Это влияет как на ускорение работы, так и на улучшение общего состояния коллектива (потому что менеджер в первую очередь работает с людьми). И даже небольшая мелочь может косвенно повлиять на основные метрики компании вроде выручки или, что ближе, time to market (время вывода продукта на рынок).
Раньше для внедрения инструмента оптимизации процесса требовалось узнать мнение команды, найти идеальное решение, согласовать бюджет, обучить всех пользоваться инструментом. И это всё равно не гарантировало результата успешного внедрения.
Сейчас, с развитием ИИ, с этим стало немного проще — можно создавать простые инструменты для оптимизации самому, при этом не выходя за рамки бюджета и не усложняя процессы. Ещё неочевидный бонус — можно быстро дорабатывать логику под непосредственно свою команду, так как это решение не должно быть универсальным (для больших команд, где нужно именно универсальное решение для всех, нужен немного другой подход, его при случае разберём в отдельной статье).
Для каждого менеджера — неважно, проектного или продуктового — есть определенный пласт регулярной работы, которую уже почти все научились оптимизировать к 2026 году с помощью стандартных инструментов. Это и оптимизация продуктовых исследований через сервисы вроде Gemini и Perplexity, и работа с данными и аналитикой с помощью любых LLM, которые вам больше нравятся, и банальная рутина типа быстрой саммаризации встреч и договорённостей.
Но при этом всё равно остаётся часть универсальных решений, которые не подходят под конкретные задачи менеджера. Вот на них остановимся немного подробнее.
Один из примеров — опросы, они бывают внутренние и внешние. Инструменты вроде Google Forms, конечно, достаточно гибкие, но бесшовной автоматизации там точно не хватает, даже несмотря на встроенные скрипты.
Если мы говорим про внутренние опросы сотрудников — там всё ещё сложнее. Гугл далеко не у всех входит в набор корпоративных инструментов (в том числе из-за внутренних требований к безопасности), а формы у Sharepoint, Jira, Notion и аналоги имеют ещё более скудный функционал.
И как раз для таких задач можно сделать своё решение, без необходимости искать готовые аналоги и тратить на это большие бюджеты. Тут важно отметить — в корпорациях на 1000+ человек решения должны быть более стабильны. Здесь иногда имеет больше смысла потратить деньги на готовое решение, но с SLA и гарантиями.
Например, обладая хоть каким-то опытом продуктовой разработки на Python + React, можно с помощью ИИ достаточно быстро написать селф-хостед систему для внутренних отчетов. При этом там будет авторизация через Microsoft SSO в связке с сервисом уведомлений через корпоративный мессенджер:

Такой подход открывает огромные возможности в быстрой разработке локальных мини-инструментов, не затрачивая большого количества времени и ресурсов.
Есть много операционных процессов, оптимизация которых требует либо дорогих решений, либо много сил, которые нужно на них потратить.
Хороший классический пример — бронирование переговорных комнат. Есть множество софтовых решений (и хардварных, кстати, тоже), но сложность в том, что каждое из них необходимо закупить, адаптировать и внедрить. В итоге это оказывается негибким, дорогим и сложным в использовании инструментом.
Сейчас можно быстро завайбкодить (или использовать Low-Code) свою систему бронирования, связанную с календарем компании по API и работающую в корпоративном боте.
Мы реализовали это за 1 день на базе телеграм-бота — и это оказалось намного удобнее для сотрудников, чем стандартные корпоративные инструменты. Выглядит просто, работает безотказно, а в рабочие процессы всё легко встроилось буквально сразу же:

Дополнительный плюс такого подхода — возможность создания кастомных решений, заточенных именно под наши процессы, и это сильно упрощает этап внедрения.
Можно ли менеджеру жить без всех этих мини-инструментов и работать по старинке? Да, но любое улучшение может стать фундаментом для масштабирования или сокращения костов.
Даже исходя из тех инструментов, собранных за несколько дней (я про бронирование переговорных комнат и систему отчётности), это уже экономит до 40 рабочих часов в квартал даже по самым скромным подсчетам.
Практически каждый, кто этим занимался, знает, что сбор информации по проектам и занесение всех данных в таблицу — это огромный пласт монотонной работы для достаточно дорогих специалистов. А сейчас, после внедрения даже таких простых инструментов, всё работает автоматически, включая генерацию отчётов и других сопутствующих документов.
В перспективе можно будет сделать интеграцию с системой документооборота, и мы сможем сэкономить еще больше человеко-часов. Правда, толковый менеджер должен заранее продумать, как лучше использовать освободившееся время команды, но это тема для отдельной статьи :-) Если интересна эта тема, напишите в комментариях ситуации, где это было проблемой для вас или команды.
Ещё важный аспект ИИ-разработки мини-инструментов — возможность быстро и дёшево спрототипировать необходимый функционал перед покупкой и внедрением большой системы.
Например, компания может быть не готова к покупке и внедрению HRM-платформы (системы для автоматизации процессов управления персоналом), но некоторый простой функционал было бы точно интересно протестировать перед покупкой. Хотя бы для того, чтобы понять, что именно мы хотим от полноценной системы, какие возможности для нас критичны, а от каких можно отказаться (или потом допилить самим).
Или мы хотим проверить гипотезу полезности подобной платформы в компании. У разработчиков, конечно, есть демо-версии своих продуктов, но очень часто они ограничены настолько, что иногда сложно понять, как подобной системой правильно пользоваться. Более того, часто бывает так, что нужен не весь функционал, а лишь какая-то его часть — и тут как раз отлично подходит прототипирование с ИИ.
Какой инструмент выбрать для оптимизации процессов — зависит от требований безопасности и того софта, который уже внедрён. Если вы используете Slack в связке с Google Workspace, то вам вряд ли будет удобно использовать прокладку в виде телеграм-бота (у Slack есть свое отличное API, которое отлично работает для любого рода автоматизаций).
А ещё нужно учитывать простоту реализации и задачи. Для множества автоматизаций могут подойти ИИ и No-Code конструкторы, вроде n8n или Lovable. И это будет отличным выбором, если вы раньше сами никогда не писали код. Если у вас есть опыт в разработке, то можно выбрать уже более серьёзные ИИ-инструменты вроде Claude Code и Cursor (или вообще все вместе).
Глобально всё можно разделить на три варианта.
Плюсы: максимально гибкая штука, и, когда в готовых решениях нет нужного функционала, это может быть единственным вариантом. В опросах нам нужна была форма с достаточно специфичным поведением, поэтому альтернативы самописной разработке не было.
Минусы: долго, дорого, нужно самому заботиться о безопасности, стабильности и так далее. Если вы в первую очередь менеджер и можете тот же функционал организовать проще, это не самый лучший вариант.
Плюсы: результат можно получить намного быстрее, чем писать самому всё с нуля (плюс функционал может получиться удобнее). Например, что проще для оформления отпуска: зайти в чат в Slack, где прикручена SaaS-автоматизация, или вспоминать, на каком домене висит нужная форма заявки?
Минусы: много ограничений самой платформы, отсутствие гибкости, в некоторых случаях — нюансы с подключением и развёртыванием.
Плюсы: можно довольно быстро собрать что-то рабочее, даже не зная программирования вообще. Если знаете — будет ещё быстрее и функциональнее. Иногда бывает так, что такая штука, собранная на коленке за пару часов, настолько заходит всем, что потом сложно представить, как вообще жили без этого.
Минусы: все минусы самописного решения плюс нужно уметь настроить рабочее окружение и запустить готовый код (а в идеале ещё сделать так, чтобы он сообщал об ошибках или сам перезапускался при падении, но это уже высший пилотаж). Совсем без технических знаний это будет сделать довольно сложно.
Несколько лет назад, будучи Delivery-лидом, я убедился, что очень важно собирать обратную связь у команды по их самочувствию и настроению вне контекста ретро или других формализованных мероприятий. Тогда мы нашли отличное стороннее решение— бота, который регулярно ходил в личку выбранным сотрудникам и задавал несколько стандартных вопросов.
Штука была достаточно гибкая, но дорогая. Сейчас подобное можно навайбкодить самому за один вечер. В примере мы сделаем намного проще и легче, но тут даже вечер не понадобится, всё будет ещё быстрее.
Дано:
Абсолютно любой сервер, способный крутить Python-скрипт
Телеграм в качестве корпоративного мессенджера
Вайбкодинг-инструменты (в моем случае Cursor + Codex)
Желание сделать бот-опросник для сотрудников
Поехали.
Используя формат Prompt as Code, собираем следующий промпт для создания простого бота:
SYSTEM: You are a senior Python developer. Optimize for maximum simplicity, clarity, and explicit behavior. No background jobs, no schedulers, no cron, no hidden logic. CONTEXT: I need a very simple Telegram bot in Python for emotional check-ins. The bot asks “How are you?” only: 1) Immediately on bot startup (first run after launch) 2) When a user explicitly presses a button "Рассказать как дела" There must be NO daily or automatic repeating logic. TASK: Create a minimal project consisting of: - main.py - requirements.txt - .env.example - .env Functional requirements: 1) Users registry: - When a user sends /start: - Save user_id to users.json - If user already exists, do nothing - Send a welcome message with ONE button: [Рассказать как дела] 2) Startup behavior (MANDATORY): - On EVERY bot startup (not only first ever): - Immediately send to ALL known users: "Как дела сегодня? Оцени от 1 до 5" with inline buttons [1][2][3][4][5] - No flags, no first_run logic, no schedules - Startup → send immediately 3) Manual check-in: - When user presses button "Рассказать как дела": - Bot sends: "Как дела сегодня? Оцени от 1 до 5" with inline buttons [1][2][3][4][5] 4) Answers: - When user presses a number 1–5: - Append to answers.json: { "user_id": number, "value": number (1–5), "timestamp": ISO8601 } - Reply: "Спасибо, принял" - After reply, show button again: [Рассказать как дела] 5) Storage: - JSON files in project root: - users.json (list of user_ids) - answers.json (append-only list) - If files do not exist, create them automatically 6) Environment: - Use python-dotenv - Read TELEGRAM_BOT_TOKEN from .env - If missing or empty: - Exit immediately with a clear error message 7) Tech constraints: - python-telegram-bot v20+ (async) - Minimal dependencies - Single-file logic in main.py - Clean and obvious code, no abstractions OUTPUT_FORMAT: - Output files with clear separators: --- main.py --- <code> --- requirements.txt --- <code> --- .env.example --- <text> --- .env --- <text> - No explanations outside file contents
На выходе может получиться разный результат с одного и того же промпта, но в моём случае Cursor собрал всё верно. Получилась следующая структура проекта:
answers и users json-файлы для хранения ответов и юзеров
main()-скрипт
.env для хранения ключей
И даже сам main(), написанный нейронкой, не так плохо выглядит:
import json import os from datetime import datetime, timezone from pathlib import Path from dotenv import load_dotenv from telegram import InlineKeyboardButton, InlineKeyboardMarkup, Update from telegram.ext import Application, CallbackQueryHandler, CommandHandler, ContextTypes load_dotenv() TOKEN = os.getenv("TELEGRAM_BOT_TOKEN") if not TOKEN: print("Error: TELEGRAM_BOT_TOKEN is missing or empty in .env") exit(1) USERS_FILE = Path(__file__).parent / "users.json" ANSWERS_FILE = Path(__file__).parent / "answers.json" CHECKIN_TEXT = "Как дела сегодня? Оцени от 1 до 5" RATING_BUTTONS = InlineKeyboardMarkup([ [InlineKeyboardButton(str(i), callback_data=str(i)) for i in range(1, 6)] ]) TELL_BUTTON = InlineKeyboardMarkup([ [InlineKeyboardButton("Рассказать как дела", callback_data="tell")] ]) def load_users() -> list: if not USERS_FILE.exists(): return [] with open(USERS_FILE) as f: return json.load(f) def save_user(user_id: int) -> None: users = load_users() if user_id in users: return users.append(user_id) with open(USERS_FILE, "w") as f: json.dump(users, f, indent=2) def append_answer(user_id: int, value: int) -> None: entry = { "user_id": user_id, "value": value, "timestamp": datetime.now(tz=timezone.utc).isoformat(), } if ANSWERS_FILE.exists(): with open(ANSWERS_FILE) as f: data = json.load(f) else: data = [] data.append(entry) with open(ANSWERS_FILE, "w") as f: json.dump(data, f, indent=2, ensure_ascii=False) async def cmd_start(update: Update, context: ContextTypes.DEFAULT_TYPE) -> None: user_id = update.effective_user.id save_user(user_id) await update.message.reply_text( "Добро пожаловать!", reply_markup=TELL_BUTTON, ) async def send_checkin_to_chat(bot, chat_id: int) -> None: await bot.send_message( chat_id=chat_id, text=CHECKIN_TEXT, reply_markup=RATING_BUTTONS, ) async def on_startup(app: Application) -> None: users = load_users() for uid in users: try: await send_checkin_to_chat(app.bot, uid) except Exception: pass async def callback_tell(update: Update, context: ContextTypes.DEFAULT_TYPE) -> None: query = update.callback_query await query.answer() await send_checkin_to_chat(context.bot, query.message.chat_id) async def callback_rating(update: Update, context: ContextTypes.DEFAULT_TYPE) -> None: query = update.callback_query await query.answer() user_id = update.effective_user.id try: value = int(query.data) except ValueError: return if value not in range(1, 6): return append_answer(user_id, value) await query.edit_message_text("Спасибо, принял", reply_markup=TELL_BUTTON) def main() -> None: app = Application.builder().token(TOKEN).post_init(on_startup).build() app.add_handler(CommandHandler("start", cmd_start)) app.add_handler(CallbackQueryHandler(callback_tell, pattern="^tell$")) app.add_handler(CallbackQueryHandler(callback_rating, pattern="^[1-5]$")) app.run_polling() if __name__ == "__main__": main()
Дальше — дело техники: закидываем скрипт на сервер и запускаем его (или просим коллегу-разработчика это сделать, если чувствуете, что свои технические навыки в этом могут подвести).
После запуска скрипта получаем простенький, но рабочий функционал внутри самого бота. Теперь любой сотрудник сможет поставить оценку своему настроению и самочувствию. Быстро, относительно просто и, главное, — полностью решает нашу задачу:
Очевидно, такое примитивное решение ещё стоит дорабатывать и дорабатывать (после одного промпта-то). Но мы быстро собрали прототип нужного решения с помощью ИИ и уже можем оценить, насколько нам в реальности нужен такой функционал, что туда ещё добавить, а главное — стоит ли всё это в сумме того, чтобы покупать что-то отдельное, или хватит и такого решения.
Источник


