Первый пост-знакомство для канала PRO Project Manager
Привет, это твой будущий PM-наставник! 👋
Меня зовут Анастасия, и последние 10 лет я:
✔️ Вела проекты в крупных банках России и Европы
✔️ Спасала сроки в телеком-гиганте
✔️ Тушила пожары в стартапе (и знаю, каково это — делать всё на коленке)
Теперь я здесь, чтобы:
🔹 Делиться реальным опытом — без воды, только то, что работает
🔹 Поддерживать — ты можешь прийти с любой проблемой, даже самой «горящей»
🔹 Быть твоей подушкой для слёз в IT (и да, я припасла виртуальные салфетки)
Что будет в канале?
✅ Разборы моих провалов и побед
✅ Чек-листы и шаблоны, которые сэкономят тебе 100+ часов
✅ Ответы на твои вопросы — пиши, о чём рассказать в первую очередь!
P.S. Какой у тебя самый болезненный опыт в проектах? Готова разобрать его в следующих постах 💬
#PM_ментор #IT_поддержка #управление_проектами
Привет, это твой будущий PM-наставник! 👋
Меня зовут Анастасия, и последние 10 лет я:
✔️ Вела проекты в крупных банках России и Европы
✔️ Спасала сроки в телеком-гиганте
✔️ Тушила пожары в стартапе (и знаю, каково это — делать всё на коленке)
Теперь я здесь, чтобы:
🔹 Делиться реальным опытом — без воды, только то, что работает
🔹 Поддерживать — ты можешь прийти с любой проблемой, даже самой «горящей»
🔹 Быть твоей подушкой для слёз в IT (и да, я припасла виртуальные салфетки)
Что будет в канале?
✅ Разборы моих провалов и побед
✅ Чек-листы и шаблоны, которые сэкономят тебе 100+ часов
✅ Ответы на твои вопросы — пиши, о чём рассказать в первую очередь!
P.S. Какой у тебя самый болезненный опыт в проектах? Готова разобрать его в следующих постах 💬
#PM_ментор #IT_поддержка #управление_проектами
👍4🔥2❤1
Flux_Dev_A_professional_highcontrast_image_with_a_subtle_backg_0.jpg
517.1 KB
Пример пяти фраз, которые никогда нельзя говорить заказчику — они разрушают доверие и портят отношения:
1. «Это невозможно»
⛔️ Почему плохо: Звучит как отказ без попытки решить проблему.
✅ Что сказать вместо:
«Давайте разберём требования — найдём оптимальное решение»
2. «Это не по ТЗ» (сухо и без вариантов)
⛔️ Почему плохо: Кажется, что вам важно только формальное соблюдение условий, а не результат.
✅ Что сказать вместо:
«Это выходит за рамки текущего договора, но мы можем обсудить доп. опции»
3. «Мы всегда так делали»
⛔️ Почему плохо: Показывает негибкость и нежелание учитывать специфику проекта.
✅ Что сказать вместо:
«Обычно мы используем такой подход, но для вашего случая предложу адаптированный вариант»
4. «Это ваша ошибка» (даже если это так)
⛔️ Почему плохо: Перекладывание вины злит заказчика.
✅ Что сказать вместо:
«Давайте проанализируем, как это произошло, и исправим»
5. «Я не знаю» (без продолжения)
⛔️ Почему плохо: Подрывает ваш экспертный статус.
✅ Что сказать вместо:
«Уточню детали у команды и дам ответ до [время]»
1. «Это невозможно»
✅ Что сказать вместо:
«Давайте разберём требования — найдём оптимальное решение»
2. «Это не по ТЗ» (сухо и без вариантов)
✅ Что сказать вместо:
«Это выходит за рамки текущего договора, но мы можем обсудить доп. опции»
3. «Мы всегда так делали»
✅ Что сказать вместо:
«Обычно мы используем такой подход, но для вашего случая предложу адаптированный вариант»
4. «Это ваша ошибка» (даже если это так)
✅ Что сказать вместо:
«Давайте проанализируем, как это произошло, и исправим»
5. «Я не знаю» (без продолжения)
✅ Что сказать вместо:
«Уточню детали у команды и дам ответ до [время]»
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤1🔥1
Как я спасла горящий бюджет, превратив open source в «отечественное ПО»
Привет! Хочу поделиться кейсом, который начался с разговора у кофемашины. Ситуация:
🚨 «Тендер на систему провален — заявился один вендор. ₽XX млн сгорят через 6 месяцев ... Open source? ФСТЭК не пустит!»
Предлагаю: «Может, сами напишем?»
— «Нет ресурсов!»
«Тогда все таки open source?»
— «ФСТЭК же не пропустит!»
🌝 Но я не сдалась. Покопавшись в голове, вспомнила: не всё так безнадёжно! Есть кейсы, как это можно обойти.
💡 План спасения:
1. Берём XX систему (open source для крутых диаграмм).
Почему он?
- Бесплатен— лицензия GPL 3.0;
- Гибкий— диаграммы = текстовые файлы (удобно для Git);
- On-premise — ставится на сервер за 15 минут.
2. «Оботечествляем» или заменяем «рисковые» компоненты, пример:
- Меняем Graphviz → на Viz.js(российский аналог с MIT-лицензией),
- Java → на Axiom JDK (наш форк OpenJDK, реестр Минцифры).
3. Проверяем на ИБ:
- Solar appScreener сканирует код и далее чиним уязвимости,
- Готовим отчёт для ФСТЭК.
4. Регистрируем в реестре отечественного ПО (2-3 месяца, но бюджет уже не сгорит!).
5. Собираем MVP
Состав команды:
- 1 DevOps (развернуть инфраструктуру),
- 1 разработчик (интеграция с Viz.js),
- 1 ИБ-эксперт (подготовка к ФСТЭК).
Итог: MVP за 6 недель с командой из 3 человек!
Этапы:
mermaid
graph TD
Итого через 6 недель:
✅Рабочий прототип с диаграммами;
✅Отчёт для ФСТЭК (соответствие Приказу №239);
✅Дорожная карта для внедрения.
Привет! Хочу поделиться кейсом, который начался с разговора у кофемашины. Ситуация:
Предлагаю: «Может, сами напишем?»
— «Нет ресурсов!»
«Тогда все таки open source?»
— «ФСТЭК же не пропустит!»
💡 План спасения:
1. Берём XX систему (open source для крутых диаграмм).
Почему он?
- Бесплатен— лицензия GPL 3.0;
- Гибкий— диаграммы = текстовые файлы (удобно для Git);
- On-premise — ставится на сервер за 15 минут.
2. «Оботечествляем» или заменяем «рисковые» компоненты, пример:
- Меняем Graphviz → на Viz.js(российский аналог с MIT-лицензией),
- Java → на Axiom JDK (наш форк OpenJDK, реестр Минцифры).
3. Проверяем на ИБ:
- Solar appScreener сканирует код и далее чиним уязвимости,
- Готовим отчёт для ФСТЭК.
4. Регистрируем в реестре отечественного ПО (2-3 месяца, но бюджет уже не сгорит!).
5. Собираем MVP
Состав команды:
- 1 DevOps (развернуть инфраструктуру),
- 1 разработчик (интеграция с Viz.js),
- 1 ИБ-эксперт (подготовка к ФСТЭК).
Итог: MVP за 6 недель с командой из 3 человек!
Этапы:
mermaid
graph TD
A[Скачать ХХ систему]
B[Заменить Graphviz → Viz.js]
C[Интеграция с Astra Linux]
D[Аудит Solar appScreener]
E[Подача в реестр ПО]
Итого через 6 недель:
✅Рабочий прототип с диаграммами;
✅Отчёт для ФСТЭК (соответствие Приказу №239);
✅Дорожная карта для внедрения.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4😁3🔥1
«Как я научилась оценивать сроки без слез: чек-лист + боль моего банковского провала»
Проблема: 80% задержек происходятиз-за ошибок в первоначальной оценке . Исправляем это за 5 шагов.
Итак, коротко и ясно:
Шаг 1: Декомпозируйте без жалости
Что делать:
- Разбейте проект на задачи максимум по 8–16 часов.
Пример:
❌ Разработка модуля = ✅ Создать API для интеграции с SMS-шлюзом.
Зачем: Мелкие задачи = точнее оценка. Ловушка не упасть в яму с микрозадачами.
😱 Шаг 2: Буфер для рисков = ваше спасение
История моего провала: В банке не заложила время на согласование с ИБ. Итог: готовый релиз не мог выйти в прод без согласования с ИБ долгое время. Учитывайте 3 типа рисков:
Техническая сложность 15-30%
Человеческий фактор 10-20%
Внешние зависимости от 20 до 50%‼️
🤯 Шаг 3: Метод трёх оценок- мой священный грааль
Как в стартапе спасли продукт:
- Разработчик: «Сделаем за 2 недели» (он же оптимист🍷)
- Менеджер: «Дай реалистично» - «опа уже 3 недели»
- Техлид: «Если всё сломается — 1,5 месяца»
Факт: сделали за 4.
Как получилось:
1. Оптимистичный срок (если всё идеально)
2. Реалистичный срок (с учётом типичных проблем)
3. Пессимистичный срок (если всё пойдёт не так)
Формула: (2 недели + 4 * реалист 3 недели+ пессимист 6 недель)/6 = итоговый срок
💔 Шаг 4: Говорите правду — даже если хочется исчезнуть
Сорвали срок из-за валютного кризиса. Молчала 2 недели («Решим сами!»). Итог: скандал, штраф, испорченные отношения. Поэтому всегда:
Пиши заказчику сразу при риске >10% Пример:
«Иван, есть риск сдвига на 3 недели из-за X. Предлагаю решение или варианты решений. Ваши мысли?».
Шаблон письма —кому интересно можем подготовить вместе🤝
🌱 Шаг 5: Учитесь на моих костях
Каждую пятницу спрашиваю команду:
- «Какая оценка была самой тупой на этой неделе?» (в моём случае — тестирование «на глазок»).
- «Что сожгло нам нервы?» (внезапный техдолг 😭).
💬 Задачка для вас
«Представьте: ваш техлид (архитектор) говорит: Интеграция с госплатформой — 2 недели. Какие 3 вопроса вы зададите ему ДО встречи с заказчиком?»
Проблема: 80% задержек происходят
Итак, коротко и ясно:
Шаг 1: Декомпозируйте без жалости
Что делать:
- Разбейте проект на задачи максимум по 8–16 часов.
Пример:
❌ Разработка модуля = ✅ Создать API для интеграции с SMS-шлюзом.
Зачем: Мелкие задачи = точнее оценка. Ловушка не упасть в яму с микрозадачами.
😱 Шаг 2: Буфер для рисков = ваше спасение
История моего провала: В банке не заложила время на согласование с ИБ. Итог: готовый релиз не мог выйти в прод без согласования с ИБ долгое время. Учитывайте 3 типа рисков:
Техническая сложность 15-30%
Человеческий фактор 10-20%
Внешние зависимости от 20 до 50%‼️
🤯 Шаг 3: Метод трёх оценок- мой священный грааль
Как в стартапе спасли продукт:
- Разработчик: «Сделаем за 2 недели» (он же оптимист🍷)
- Менеджер: «Дай реалистично» - «опа уже 3 недели»
- Техлид: «Если всё сломается — 1,5 месяца»
Факт: сделали за 4.
Как получилось:
1. Оптимистичный срок (если всё идеально)
2. Реалистичный срок (с учётом типичных проблем)
3. Пессимистичный срок (если всё пойдёт не так)
Формула: (2 недели + 4 * реалист 3 недели+ пессимист 6 недель)/6 = итоговый срок
💔 Шаг 4: Говорите правду — даже если хочется исчезнуть
Сорвали срок из-за валютного кризиса. Молчала 2 недели («Решим сами!»). Итог: скандал, штраф, испорченные отношения. Поэтому всегда:
Пиши заказчику сразу при риске >10% Пример:
«Иван, есть риск сдвига на 3 недели из-за X. Предлагаю решение или варианты решений. Ваши мысли?».
Шаблон письма —кому интересно можем подготовить вместе
🌱 Шаг 5: Учитесь на моих костях
Каждую пятницу спрашиваю команду:
- «Какая оценка была самой тупой на этой неделе?» (в моём случае — тестирование «на глазок»).
- «Что сожгло нам нервы?» (внезапный техдолг 😭).
💬 Задачка для вас
«Представьте: ваш техлид (архитектор) говорит: Интеграция с госплатформой — 2 недели. Какие 3 вопроса вы зададите ему ДО встречи с заказчиком?»
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤🔥1😎1
Частый кейс: Из Product Manager — вдруг ещё и Team Lead?
Знакомо? Меня (и многих коллег) наняли как Продакта, но добавили управление командой разработки: дейли, ретро, трекинг задач, планирование спринтов. Две роли в одном флаконе – вызов!
С чего начать? Мои рекомендации для первых шагов, основанные на опыте:
🎯 Ваша КЛЮЧЕВАЯ РОЛЬ и ЦЕЛЬ теперь:
"Максимизировать ценность продукта, обеспечивая бесперебойную и эффективную работу команды разработки".
Вы – "Щит" и "Экскаватор" команды:
Щит: Защищаете команду от внешних помех (бесконечные запросы стейкхолдеров, срочные "пожары" не по плану).
Экскаватор: Прокапываете путь, убирая внутренние препятствия (блокеры, неясности в задачах, конфликты, пробелы в процессах).
Ваша цель – создать условия, при которых команда может делать максимум полезной работы с высоким качеством и минимальными задержками.
📌 Что СРОЧНО нужно освоить и почитать:
1. 🗂 Основы Процессов (Библия!):
Scrum Guide (обязательно!): Поймите роли, события (Спринт, Планирование, Дейли, Обзор, Ретро), артефакты (Бэклог Продукта/Спринта, Инкремент).
Kanban: Принципы (визуализация потока, ограничение WIP, управление потоком), метрики (Cycle Time, Lead Time). Книга: Дэвид Андерсон "Канбан".
Гибридные подходы (Scrumban): Как это работает на практике.
2. ⚙️ Инструменты (Ваш рабочий арсенал):
Jira (или аналог): Глубокое погружение в создание/настройку проектов, workflows, досок (Scrum/Kanban), отчеты (Burndown/up Chart, Velocity Chart). Без этого – никак.
Confluence (или аналог): Организация документации, фиксация решений,согласование документов.
Основы Git (не кодить, а понимать): Ветки, пул-реквесты, мержи – чтобы говорить с командой на одном языке и понимать их боль.
3. 📊 Метрики Команды (Не для контроля, а для улучшений!):
Velocity: Сколько "стори поинтов" (или задач) команда стабильно делает за спринт? Для реалистичного планирования.
Cycle Time: Сколько времени задача "фактически" находится в работе (от старта до завершения)? Показывает эффективность потока.
Lead Time (моя любимая метрика💜): Сколько времени проходит от появления запроса (фичи/бага) до его попадания к пользователю? Показывает общую скорость доставки ценности.
4. 🛠 Проведение Ключевых Событий (Навык фасилитации):
Дейли (15 мин!): Фокус на блокерах ("Что мешает?"), а не статусе. Правило: Глубокие техдискуссии – выносим, общие фразы – уточняем.
Ретро: Не поиск виноватых! Цель: Выявить 1-2 "конкретных, выполнимых" улучшения процесса на следующий спринт. Обязательно: Отслеживать выполнение.
Планирование Спринта: Четко определить ЦЕЛЬ спринта и ОБЪЕМ работ, который команда "реально" возьмет.
Обзор (Review): Показать инкремент, собрать фидбэк.
5. 🧠 Критически Важные Soft Skills:
Активное Слушание и Эмпатия: Слышать не только слова, но и контекст, настроение, скрытые блокеры.
Конструктивная Обратная Связь (Feedback): Умение давать и получать (регулярные 1:1 с командой).
Разрешение Конфликтов: Внутри команды, с другими отделами. Фокус на интересах, а не позициях.
Делегирование и Доверие: Не контролировать каждый шаг, а давать автономию в рамках зоны ответственности. Доверять технической экспертизе команды.
Четкая Коммуникация: Донесение целей, приоритетов, статуса до стейкхолдеров и команды.
❗️ Важно: Не пытайтесь быть техлидом! Ваша зона – процессы, коммуникация, удаление препятствий и фокус на ценности продукта. Технические решения – ответственность разработчиков (при вашей поддержке в прояснении требований).
Сначала гора информации? Начните с Scrum Guide и настройки Jira. Дальше – по мере задач. Вы справитесь!
#ProductManagement #TeamLead #Agile #Scrum #УправлениеКомандами #Дейли #Ретро #ScrumMaster #РазработкаПО #Карьера #Лидерство
Знакомо? Меня (и многих коллег) наняли как Продакта, но добавили управление командой разработки: дейли, ретро, трекинг задач, планирование спринтов. Две роли в одном флаконе – вызов!
С чего начать? Мои рекомендации для первых шагов, основанные на опыте:
🎯 Ваша КЛЮЧЕВАЯ РОЛЬ и ЦЕЛЬ теперь:
"Максимизировать ценность продукта, обеспечивая бесперебойную и эффективную работу команды разработки".
Вы – "Щит" и "Экскаватор" команды:
Щит: Защищаете команду от внешних помех (бесконечные запросы стейкхолдеров, срочные "пожары" не по плану).
Экскаватор: Прокапываете путь, убирая внутренние препятствия (блокеры, неясности в задачах, конфликты, пробелы в процессах).
Ваша цель – создать условия, при которых команда может делать максимум полезной работы с высоким качеством и минимальными задержками.
📌 Что СРОЧНО нужно освоить и почитать:
1. 🗂 Основы Процессов (Библия!):
Scrum Guide (обязательно!): Поймите роли, события (Спринт, Планирование, Дейли, Обзор, Ретро), артефакты (Бэклог Продукта/Спринта, Инкремент).
Kanban: Принципы (визуализация потока, ограничение WIP, управление потоком), метрики (Cycle Time, Lead Time). Книга: Дэвид Андерсон "Канбан".
Гибридные подходы (Scrumban): Как это работает на практике.
2. ⚙️ Инструменты (Ваш рабочий арсенал):
Jira (или аналог): Глубокое погружение в создание/настройку проектов, workflows, досок (Scrum/Kanban), отчеты (Burndown/up Chart, Velocity Chart). Без этого – никак.
Confluence (или аналог): Организация документации, фиксация решений,согласование документов.
Основы Git (не кодить, а понимать): Ветки, пул-реквесты, мержи – чтобы говорить с командой на одном языке и понимать их боль.
3. 📊 Метрики Команды (Не для контроля, а для улучшений!):
Velocity: Сколько "стори поинтов" (или задач) команда стабильно делает за спринт? Для реалистичного планирования.
Cycle Time: Сколько времени задача "фактически" находится в работе (от старта до завершения)? Показывает эффективность потока.
Lead Time (моя любимая метрика💜): Сколько времени проходит от появления запроса (фичи/бага) до его попадания к пользователю? Показывает общую скорость доставки ценности.
4. 🛠 Проведение Ключевых Событий (Навык фасилитации):
Дейли (15 мин!): Фокус на блокерах ("Что мешает?"), а не статусе. Правило: Глубокие техдискуссии – выносим, общие фразы – уточняем.
Ретро: Не поиск виноватых! Цель: Выявить 1-2 "конкретных, выполнимых" улучшения процесса на следующий спринт. Обязательно: Отслеживать выполнение.
Планирование Спринта: Четко определить ЦЕЛЬ спринта и ОБЪЕМ работ, который команда "реально" возьмет.
Обзор (Review): Показать инкремент, собрать фидбэк.
5. 🧠 Критически Важные Soft Skills:
Активное Слушание и Эмпатия: Слышать не только слова, но и контекст, настроение, скрытые блокеры.
Конструктивная Обратная Связь (Feedback): Умение давать и получать (регулярные 1:1 с командой).
Разрешение Конфликтов: Внутри команды, с другими отделами. Фокус на интересах, а не позициях.
Делегирование и Доверие: Не контролировать каждый шаг, а давать автономию в рамках зоны ответственности. Доверять технической экспертизе команды.
Четкая Коммуникация: Донесение целей, приоритетов, статуса до стейкхолдеров и команды.
❗️ Важно: Не пытайтесь быть техлидом! Ваша зона – процессы, коммуникация, удаление препятствий и фокус на ценности продукта. Технические решения – ответственность разработчиков (при вашей поддержке в прояснении требований).
Сначала гора информации? Начните с Scrum Guide и настройки Jira. Дальше – по мере задач. Вы справитесь!
#ProductManagement #TeamLead #Agile #Scrum #УправлениеКомандами #Дейли #Ретро #ScrumMaster #РазработкаПО #Карьера #Лидерство
👍4❤1
PRO Project Manager pinned «Первый пост-знакомство для канала PRO Project Manager Привет, это твой будущий PM-наставник! 👋 Меня зовут Анастасия, и последние 10 лет я: ✔️ Вела проекты в крупных банках России и Европы ✔️ Спасала сроки в телеком-гиганте ✔️ Тушила пожары в стартапе…»
Как ИИ спас меня от совещательного ада: личный эксперимент IT-PM
(Часть 1: Когда ИИ стал твоими «запасными ушами»)
Транскрибация vs. человеческое терпение
Вводная часть
Всё Telegram завалено постами про ИИ. У всех есть мнение — но мало реальных кейсов, как PM юзать ИИ.
- Кто:Отдел проджектов в компании гиганте 🇷🇺
- Задача: «Внедрить ИИ в процессы к вчера!»
- Реальность: Ни одного работающего решения для PM.
- Мой вердикт: «Или мы что-то упускаем, или рынок ещё не созрел».
🔍 Проблема1️⃣ 😞 нудные/технические митинги =часы расшифровок =дни на протоколы.
Решение:Передать транскрибацию и суммаризацию ИИ.
Барьер:Ни один коробочный инструмент не зашёл (привет, МТС Линк!)
Делюсь моим экспериментом в проектной работе.
Спойлер: экономия 4+ часов в неделю— не миф.
ИИ сгенерировал протокол технического митинга вместо меня — архитектор не нашёл ни одной ошибки
🚨 Ситуация, где ИИ спас
Контекст:
- Совещание: Глубоко технический митинг по интеграции с legacy-системой банка
- Проблема: Параллельно горел прод-инцидент - я решала проблемы с разработчиками -физически отсутствовала мыслями на 70% встречи
- Риск: Пропустить critical path проекта
✅ Что сделал ИИ (и почему архитектор ахнул):
1️⃣ Выделил спорные моменты:
Архитектор: «Интерфейс SOAP не подходит»→ Dev: «Допишем конвертер»- Решение: Задача Сергею (до 15.05)
2️⃣ Зафиксировал технические нюансы:
«Требование: HTTPS вместо FTP для передачи логов». Ответственный: Марина (тестирование до 20.05)
Итог:
Архитектор после проверки: «Как ты всё запомнила? Ни одной ошибки!»
Реальность: Я даже не слышала половины дискуссии 😅 Да, было и не раз🐶
Итак ещё раз 🧪 Мой «колхозный»workflow (рабочая схема):
Шаг 1: Запись Kontur.Talk (лучшее качество транскриптов,экспериментов было много)
Шаг 2: Обезличивание:
- Удаляем имена/названия систем/цифры (30 мин ручной работы)
prompt:
Ты senior IT-проджект менеджер с опытом в банках. Напиши протокол встречи по транскрипту:
1. Ключевые решения(кратко, без общих фраз)
2. Ответственные- [Имя] - [Задача] с указанием сроков, если есть
3. Технические нюансы - API, интеграции, security-требования
4. Риски- Выдели спорные моменты
5. Действия- Что сделать до следующей встречи
Требования:
- Только факты из транскрипта
- Без благодарностей и «вода» вроде «состоялся полезный диалог»
А дальше магия 🪄
Теперь я спокойно жгу продакшн во время совещаний — ИИ мой надёжный соучастник🌝
Пс.Если будут сложные кейсы — присылайте примеры транскриптора (без NDA), проанализируем вместе!
#ai_для_pm #технические_совещания #ии_спасение
(Часть 1: Когда ИИ стал твоими «запасными ушами»)
Транскрибация vs. человеческое терпение
Вводная часть
Всё Telegram завалено постами про ИИ. У всех есть мнение — но мало реальных кейсов, как PM юзать ИИ.
- Кто:Отдел проджектов в компании гиганте 🇷🇺
- Задача: «Внедрить ИИ в процессы к вчера!»
- Реальность: Ни одного работающего решения для PM.
- Мой вердикт: «Или мы что-то упускаем, или рынок ещё не созрел».
🔍 Проблема
Решение:Передать транскрибацию и суммаризацию ИИ.
Барьер:Ни один коробочный инструмент не зашёл (привет, МТС Линк!)
Делюсь моим экспериментом в проектной работе.
Спойлер: экономия 4+ часов в неделю— не миф.
ИИ сгенерировал протокол технического митинга вместо меня — архитектор не нашёл ни одной ошибки
🚨 Ситуация, где ИИ спас
Контекст:
- Совещание: Глубоко технический митинг по интеграции с legacy-системой банка
- Проблема: Параллельно горел прод-инцидент - я решала проблемы с разработчиками -физически отсутствовала мыслями на 70% встречи
- Риск: Пропустить critical path проекта
Решение: graph LR
A[Запись в Kontur.Talk]
B[Обезличенный транскрипт]
C[Промпт в GigaChat]
D[Идеальный протокол]
✅ Что сделал ИИ (и почему архитектор ахнул):
1️⃣ Выделил спорные моменты:
Архитектор: «Интерфейс SOAP не подходит»→ Dev: «Допишем конвертер»- Решение: Задача Сергею (до 15.05)
2️⃣ Зафиксировал технические нюансы:
«Требование: HTTPS вместо FTP для передачи логов». Ответственный: Марина (тестирование до 20.05)
3️⃣ Структурировал даже хаотичное обсуждение: [Риски]
• Отсутствие документации по legacy-API
• Несовместимость форматов данных
Итог:
Архитектор после проверки: «Как ты всё запомнила? Ни одной ошибки!»
Реальность: Я даже не слышала половины дискуссии 😅 Да, было и не раз
Итак ещё раз 🧪 Мой «колхозный»workflow (рабочая схема):
Шаг 1: Запись Kontur.Talk (лучшее качество транскриптов,экспериментов было много)
Шаг 2: Обезличивание:
- Удаляем имена/названия систем/цифры (30 мин ручной работы)
prompt:
Ты senior IT-проджект менеджер с опытом в банках. Напиши протокол встречи по транскрипту:
1. Ключевые решения(кратко, без общих фраз)
2. Ответственные- [Имя] - [Задача] с указанием сроков, если есть
3. Технические нюансы - API, интеграции, security-требования
4. Риски- Выдели спорные моменты
5. Действия- Что сделать до следующей встречи
Требования:
- Только факты из транскрипта
- Без благодарностей и «вода» вроде «состоялся полезный диалог»
А дальше магия 🪄
Теперь я спокойно жгу продакшн во время совещаний — ИИ мой надёжный соучастник
Пс.Если будут сложные кейсы — присылайте примеры транскриптора (без NDA), проанализируем вместе!
#ai_для_pm #технические_совещания #ии_спасение
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6❤2❤🔥1👍1👎1