Привет, друзья!👋

За последнее время я очень много писал про ИИ. Делился опытом внедрения в команде, рассказывал про свои фишки и просто рассуждал о плюсах и минусах.

Постов набралось прилично, и найти нужный в ленте уже непросто. Поэтому собрал все статьи в одном месте:

1️⃣ИИ-конвейер. Часть 1 — зачем делить работу с ИИ на контуры (требования, архитектура, код, тесты) и держать заполненность контекстного окна в пределах 40–50%. Читать

2️⃣ИИ-конвейер. Часть 2 — как управлять этими контурами через openspec и спеки и какие скилы для этого пригодились. Читать

3️⃣Мои инструменты для работы с ИИ — opencode и Claude Code в CLI, что такое скилы и пара лайфхаков с алиасами и командами. Читать

4️⃣Как передавать знания по ИИ в компании — почему наработки надо фиксировать и шарить внутри и вовне и зачем поддерживать тех, кто тащит эту тему. Читать

5️⃣Что такое SDD и почему столько шума — что такое Spec-Driven Development, почему подход вернулся вместе с ИИ и какие у openspec плюсы и минусы. Читать

6️⃣Как мы вкатываем команду в SDD — выбор инструмента, разбор документации по продукту, свои скилы и точки контроля. Читать

7️⃣Что не так с ИИ. Часть 1 — откуда завышенные ожидания и почему из коробки ИИ делает изолированный продукт. Читать

8️⃣Что не так с ИИ. Часть 2 — делим SDLC на кубики со своими скилами, ревьюим каждый этап и делимся знаниями между командами. Читать

9️⃣Что не так с ИИ. Часть 3 — практика. Собираем процесс постепенно и начинаем со спеки, а не с промпта. Читать

Сохраняйте себе, чтобы не потерять. А если какой-то темы про ИИ не хватает, пишите в комментариях, разберу в следующих постах 👇

Читать полностью…

Часть 2. Как с этим помогает openspec

Привет еще раз! В первой части разобрались, зачем вообще дробить задачу на контуры. Теперь про то, как это удобно собрать в одну систему.

С этим всем отлично справляется openspec. Достаточно простая система, которая работает со спецификациями (это и есть результаты на каждом контуре). Задачу можно даже довести до определенного контура и передать другому сотруднику, и ему не придется с нуля делать всё, а можно будет продолжить с того контура, на котором вы остановились.

Что делает openspec? Он как раз формирует спецификации на каждом этапе. У него есть отличные скилы, которые помогают вам в наполнении этих спецификаций. Например, explorer поможет вам проанализировать задачу до старта написания кода. Это нужно, когда у вас есть размытое описание и нужно что-то сделать. Далее он предлагает вам постановку задачи, и ее можно будет перекинуть в новый скил propose. На этом этапе он анализирует бизнес-требования пользователя и формирует техническое предложение в виде md-файла. Вы его ревьюите и переходите на следующий этап — apply. Он переводит агента в строгий рабочий режим «прочитал задачу ➔ написал код ➔ протестировал ➔ валидировал». Опять ревью, и уже можно завершать работу над задачей путем перевода задачи в архив.

Все эти процессы попутно записывают спецификации в вашу репу. Получается тот самый забытый, но в последнее время актуальный подход в разработке — SDD.

На самом деле для старта openspec достаточно в базовом виде. Дальше вы его будете докручивать на каждом этапе своими скилами и правилами.

Так что вся фишка не в том, какая у вас модель, а в том, чтобы не тащить всю задачу в одно окно. Разбили на контуры, и на каждом этапе агент работает со свежей головой и только с тем, что ему реально нужно. Мы с командой сейчас как раз идем по этому пути, так что потом обязательно расскажу, что из этого вышло)

А вы как переносите контекст между сессиями? Пользуетесь openspec или придумали что-то свое? Пишите в комментариях👇

Читать полностью…

Привет, друзья!👋

Я тут много писал про ИИ. Как вкатываем команду в SDD, как собираем процессы из кубиков, как делиться знаниями внутри компании. И поймал себя на мысли, что ни разу толком не спросил вас, а помогает ли он вам вообще.

У меня ощущения смешанные. Бывают дни, когда за час делаешь то, на что раньше уходил день, и сидишь довольный. А бывает, что полдня объясняешь ему контекст, потом ещё столько же разгребаешь, что он там напридумывал, и думаешь, что руками было бы быстрее) Одну вещь я для себя заметил. Если даёшь ему нормальную спеку и он понимает границы, то всё летит. Если просишь «сделай хорошо», он и сделает хорошо, но в своём маленьком мире, который потом не стыкуется ни со смежниками, ни с остальным кодом.

Так что я скорее за, но с оговоркой. Сам по себе ИИ ничего не ускоряет. Ускоряет процесс, в который его нормально встроили, а на это нужно время, и немалое.

Интересно, как у вас. Чувствуете реальную пользу или пока больше возни с настройкой? Где он выручает чаще всего, в коде, в аналитике или в какой-нибудь рутине вроде разбора встреч? И есть ли в команде те, кто принципиально им не пользуется? Мне кажется, их аргументы тоже стоит послушать.

Пишите в комментариях или в нашем чате тимлидов👇

Читать полностью…

Привет, друзья!👋

Хочу поделиться с вами инструментами, которые постоянно использую в работе с ИИ: с чем я чаще всего взаимодействую, какие лайфхаки обнаружил и что улучшил (а главное — где).

Начну с самих инструментов. Для работы с ИИ я в основном использую CLI: для рабочих процессов — opencode, а для личных дел — Claude Code. Раньше я плотно работал в ИДЕшках и агентах с UI, но почему-то CLI мне нравится больше. Почему? Не знаю. Возможно, в CLI модель лучше работает со скилами и переключением контекста. Как будто сам CLI больше подталкивает вызывать скилы через команды (а особенно создавать новые), а также чаще переключаться на новое контекстное окно.

Давайте расскажу об этих двух темах подробнее.

Что такое скилы? Скилы (навыки) — это описание того, как работать с информацией и задачей, которую дает человек. Грубо говоря, вы перекладываете и переписываете свои навыки в текстовый документ. Почему это скил, а не системный промпт? Потому что в нем могут быть прописаны MCPишки, вызовы скриптов и т. п. В общем, тема нужная, и если хотите, могу написать о ней отдельный пост (залайкайте этот пост — и я пойму, что это актуально).

Далее — «переключение контекста». Что это такое? Это то, с чем так или иначе сталкивается каждый, кто использует ИИ не для генерации дефолтных лендингов, а в работе с большими проектами. Вот есть у вас эпик-задача, которую вы хотите решить с ИИшкой. Вы пишете ей «Привет, давай работать» — и уже минус 50–70к токенов. Два-три запроса — и контекстное окно заполнено на 40%. Дальше модель начнет сжимать контекст, и ответы будут становиться все хуже и хуже. Так делать нельзя. Задачу надо как-то разбивать на этапы, где входные данные следующего этапа = выходные данные предыдущего. Тут и начинается «переключение контекста».

Возвращаясь к CLI и его плюсам, о которых я писал выше, хочу поделиться с вами «приколами», которые сделал у себя)

1️⃣Можно открывать opencode/claude сразу в нужной директории. Делается это через алиасы — их можно прописать в файле .zshrc. Вот пример:

alias название_команды_в_терминале='opencode /путь_к_проекту'
alias название_команды_в_терминале='cd "/путь_к_проекту" && claude'

2️⃣Свои скилы можно сразу превратить в запускаемые команды. Делается это просто: открываете конфигурационный файл CLI (у opencode это ~/.config/opencode/opencode.json — по крайней мере, у меня на маке он лежит именно там) и добавляете скил в раздел command. Вот пример того, как он хранится в этом файле:

"command": {
  "Название скила": {
    "description": "описание скила из файла",
    "template": "Load skill 'название скила' and apply it to: $ARGUMENTS. If $ARGUMENTS is empty and input is required, explain what the skill does and ask for the needed information."
  }
}

Это лишь небольшой пул советов, которыми я хотел с вами поделиться) В общем, тема действительно большая, и у меня много мыслей и опыта, которыми я мог бы поделиться. Если хотите, могу сделать несколько статей, где подробно разберу openspec и то самое «переключение контекста», а также расскажу про MCP и скилы.

Пишите в комментариях свое мнение и дайте фидбэк — о чем еще мне стоит рассказать👇

Читать полностью…

Привет, друзья!👋

Сегодня хотелось бы обсудить тему передачи и обсуждения знаний, связанных с ИИ. Сейчас эта тема очень сильно развивается в каждой IT-компании, и вопрос о передаче знаний и их развитии стоит очень остро.

Если вы в начале пути и считаете, что этого пока делать не нужно, так как системы еще нет, то знайте — это не так!

Очень важно фиксировать все то, что вы развиваете. Знания накапливаются, и их очень необходимо систематизировать. В самом начале будет просто склад из заметок, которые отвечают на вопросы, но не имеют структурированной последовательности. Конечно, в самом начале невозможно это делать всем вместе. Необходимы лидеры, которые это будут все адаптировать, тестировать и выявлять закономерности. Только они смогут сформировать общий пул таких заметок. Нет, это не означает, что процесс надо оставить только этим людям. Но это означает, что таких людей/команды необходимо поощрять в этих стремлениях, дабы показать остальным, что есть не только кнут, но еще и пряник.

Конечно же, стоит не забывать и о транслировании бестпрактисов, которые есть у прорывных людей/команд. Знания необходимо шарить внутри компании. Это как минимум развивает базу знаний, так как на один и тот же вопрос люди могут давать разные ответы и смотреть на вещи под разными углами. Всегда есть люди, которые могут отвечать на сложные вопросы и из-за высокой экспертности могут не замечать простые вещи, которые являются барьером для других, у кого нет такого глубокого опыта.

Ну и самое главное, что уже ранее озвучивал, — это поощрение и развитие инициативных людей/команд. Если использовать только кнут, то в какой-то момент люди/команды могут перегореть и быть негативным примером для других. Наказали инициативных = показали пример того, что не стоит туда идти.

И еще один важный момент — это референсы. Не только у вас идет развитие, но и в других компаниях тоже идет. Кто-то уже набил шишки на том этапе, где вы находитесь. Обмен знаниями должен быть не только внутри, но еще и вовне. Приглашайте экспертов, устраивайте нетворкинг и просто общайтесь!

Так как я часто в последнее время пишу про ИИ, то считайте, что цель этого поста (и других) — как раз создать этот нетворкинг и обмен знаниями. Не стесняйтесь и заходите в комментарии под этим постом (или в чатике тимлидов) и пишите все, что думаете🫶

Читать полностью…

Более 30 лидеров IT-индустрии поделятся практическим опытом управления командами, отдельными сотрудниками и ИИ-агентами — на конференции для тимлидов TEAM LEAD TODAY 2026. Мероприятие пройдет 10 сентября в Москве (ВДНХ, Бизнес.Техноград).

В числе спикеров — эксперты компаний Сбер, Газпромнефть, Альфа Банк, Гринатом, Шереметьево Хэндлинг, Билайн, Positive Technologies, Skillaz, Herbarium Games и многих других.

500+ участников | 30+ спикеров | 10 часов нетворкинга

TEAM LEAD TODAY объединит лекторий и несколько интерактивных форматов, позволяющих участникам обмениваться рабочими инструментами, инсайтами и применять новые знания сразу на практике.

В программе: кейсы спикеров, панельные дискуссии, битва промптов, живое ревью, собеседование на скорости, speed networking, карьерные консультации, сложная 1:1, peer-to-peer круглый стол и многое другое.

TEAM LEAD TODAY — площадка, где обсуждают, как строить эффективные команды, управлять сложными проектами, развивать ИТ-культуру и совмещать техническую экспертизу с лидерскими качествами.

Присоединяйтесь к встрече лидеров ИТ-индустрии, чтобы научиться принимать решения увереннее, управлять смешанной командой из людей и ИИ-агентов и приобрести новые профессиональные связи в неформальной атмосфере.

TEAM LEAD TODAY 2026 | Кейсы и практика для тимлидов
🗓 10 сентября 2026
📍 Бизнес.Техноград | Москва
Подробности и регистрация на сайте teamleadtoday.ru

Ловите скидку 10% на билеты — по промокоду TLS10

Читать полностью…

Меньше чем через месяц, 10–11 сентября, в Новосибирске пройдет TeamLead Сибирь — конференция для тимлидов и руководителей.

Самый большой трек — про AI в работе руководителя: 11 докладов о реальных внедрениях. Как считать эффект, где ИИ окупается, а где бюджет уходит впустую, как перестроить роли в команде и работать с ИИ-агентами.

Что еще вас ждет на конференции:
— 30+ докладов по семи темам: кроме AI это найм, процессы, выгорание и коммуникация;
— отдельный зал мастер-классов, где разбираешь свою рабочую задачу с ведущим;
— фейл-митап про провалы, которыми обычно не делятся со сцены;
— фасилитируемый нетворкинг со знакомствами по интересам;
— квест по площадке с розыгрышем мерча;
— скидки участникам на отели, перелеты и рестораны по промокодам.

Два дня офлайн в Новосибирске плюс онлайн-трансляция.

👉 Программа и билеты

Читать полностью…

Привет, друзья!👋

Вот вам несколько полезных ссылочек по теме SDD:
🔗https://youtu.be/JU13uM2b7WM?si=1dmd0Qdvm4r0leSm
🔗https://habr.com/p/983316/
🔗https://youtu.be/tSpj7muShX0?si=5JNgWXQUC153hoUW
🔗https://www.youtube.com/watch?v=EZwcBSX_Rbs

Если у вас что-то есть по этой теме, то смело кидайте в комментарии👇

Читать полностью…

Более 30 лидеров IT-индустрии поделятся практическим опытом управления командами, отдельными сотрудниками и ИИ-агентами — на конференции для тимлидов TEAM LEAD TODAY 2026. Мероприятие пройдет 10 сентября в Москве (ВДНХ, Бизнес.Техноград).

В числе спикеров — эксперты компаний Сбер, Газпромнефть, Альфа Банк, Гринатом, Шереметьево Хэндлинг, Билайн, Positive Technologies, Skillaz, Herbarium Games и многих других.

500+ участников | 30+ спикеров | 10 часов нетворкинга

TEAM LEAD TODAY объединит лекторий и несколько интерактивных форматов, позволяющих участникам обмениваться рабочими инструментами, инсайтами и применять новые знания сразу на практике.

В программе: кейсы спикеров, панельные дискуссии, битва промптов, живое ревью, собеседование на скорости, speed networking, карьерные консультации, сложная 1:1, peer-to-peer круглый стол и многое другое.

TEAM LEAD TODAY — площадка, где обсуждают, как строить эффективные команды, управлять сложными проектами, развивать ИТ-культуру и совмещать техническую экспертизу с лидерскими качествами.

Присоединяйтесь к встрече лидеров ИТ-индустрии, чтобы научиться принимать решения увереннее, управлять смешанной командой из людей и ИИ-агентов и приобрести новые профессиональные связи в неформальной атмосфере.

TEAM LEAD TODAY 2026 | Кейсы и практика для тимлидов
🗓 10 сентября 2026
📍 Бизнес.Техноград | Москва
Подробности и регистрация на сайте teamleadtoday.ru

Ловите скидку 10% на билеты — по промокоду TLS10

Читать полностью…

Привет, друзья! 👋

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

Процесс разработки плавно смещается из контура с кодом в контур постановки задачи. И у этого действительно есть свои плюсы. Зачем ИИ анализировать доработку в момент написания кода, если на вход уже может прийти задача с готовым решением?

Тут как раз идеально подходит SDD.

Немного теории. SDD (Spec-Driven Development, разработка через спецификации) — это подход, при котором код пишется по заранее описанным инструкциям, спецификациям. А сами спеки формируются на основе технической и бизнесовой документации по продукту. Грубо говоря: сначала договариваемся, что именно строим, и только потом пишем код. Спека становится источником истины, а не чат и не чья-то память.

Давайте начнём с того, а куда он вообще уходил? Да всё просто) Людям было влом вести спеки и поддерживать их актуальность. Надо не только сохранять всё по новым доработкам, но ещё и держать историю уже сформированного. Это, конечно, лично моё мнение, но на форумах встречал единомышленников.

Почему его вдруг опять вспомнили? Да потому что теперь всю эту бюрократию на себя берёт ИИ и отлично справляется. Плюс снижается сжигание токенов: контекст ходит из чата в чат без повторного анализа, а вся история лежит в спеках.

По факту, вы совместно с ИИ формулируете задачу, учитываете архитектуру, бизнес и сам код ещё до его написания. Спека первична, код — то, что из неё вытекает.

Теперь про инструменты. Самый лёгкий вход — openspec (уже больше 50к звёзд на гите). Ставится через npm, внутри проекта делаете openspec init — и дальше работаете через слэш-команды прямо в вашем ИИ-ассистенте.

Фишка в том, что каждое изменение живёт в своей папке, а спеки остаются документацией, которую читает и человек, и ИИ. Работает это с кучей ассистентов — Claude Code, Cursor, Codex и ещё 20+ инструментов.

Какие тут плюсы?

1️⃣Вы не забиваете контекст одной сессии. Весь нужный контекст уже хранится в спецификациях, а не держится в памяти чата.
2️⃣Сохраняется история изменений. Появилась доработка по уже сделанной задаче — не нужно жечь токены заново, у вас лежит спека с описанием изменений.
3️⃣Экономите токены в долгую. Да, в начале вы сожжёте их много, но потом получите в разы больше импакта.
4️⃣Прозрачность для команды. Спека читается человеком. Аналитик, тестировщик и новичок видят одну и ту же картину, а не пытаются реконструировать логику по коду.

Но давайте честно — минусы тоже есть.

1️⃣Высокий порог входа. На старте это больно. Надо перелопатить документацию, договориться о формате спек, потратить время и токены.
2️⃣Спеки надо поддерживать. Забьёте на актуальность — и вернётесь ровно туда, откуда начинали.
3️⃣Подходит не под всё. Разворачивать спеку ради правки в одну строчку — оверхед. SDD раскрывается там, где важны архитектура и контекст.
4️⃣Нет простого ответа "Как встроить это в уже существующий монолит". Непонятно как это встраивать в проект из нескольких продуктов. Или связать это между репой бэка и фронта.
5️⃣Инструменты ещё сырые. openspec, BMAD и прочие активно меняются, устоявшихся стандартов пока нет, что-то придётся допиливать под себя.

Бонусом, вот несколько полезных ссылок по этой теме:
🔗https://aipdlc.ru/ru
🔗https://tproger.ru/articles/razrabotchik-uhodit-inzhener-ostayotsya-kak-ai-ekosistema-menyaet-r

Читать полностью…

Более 30 лидеров IT-индустрии поделятся практическим опытом управления командами, отдельными сотрудниками и ИИ-агентами — на конференции для тимлидов TEAM LEAD TODAY 2026. Мероприятие пройдет 10 сентября в Москве (ВДНХ, Бизнес.Техноград).

В числе спикеров — эксперты компаний Сбер, Газпромнефть, Альфа Банк, Гринатом, Шереметьево Хэндлинг, Билайн, Positive Technologies, Skillaz, Herbarium Games и многих других.

500+ участников | 30+ спикеров | 10 часов нетворкинга

TEAM LEAD TODAY объединит лекторий и несколько интерактивных форматов, позволяющих участникам обмениваться рабочими инструментами, инсайтами и применять новые знания сразу на практике.

В программе: кейсы спикеров, панельные дискуссии, битва промптов, живое ревью, собеседование на скорости, speed networking, карьерные консультации, сложная 1:1, peer-to-peer круглый стол и многое другое.

TEAM LEAD TODAY — площадка, где обсуждают, как строить эффективные команды, управлять сложными проектами, развивать ИТ-культуру и совмещать техническую экспертизу с лидерскими качествами.

Присоединяйтесь к встрече лидеров ИТ-индустрии, чтобы научиться принимать решения увереннее, управлять смешанной командой из людей и ИИ-агентов и приобрести новые профессиональные связи в неформальной атмосфере.

TEAM LEAD TODAY 2026 | Кейсы и практика для тимлидов
🗓 10 сентября 2026
📍 Бизнес.Техноград | Москва
Подробности и регистрация на сайте teamleadtoday.ru

Ловите скидку 10% на билеты — по промокоду TLS10

Читать полностью…

🔥 Разыгрываем 3 билета на TeamLead Сибирь

Условие простое: пройти наш опрос про AI в работе тимлида. На все 14 вопросов уйдет 3-6 минут.

Спрашиваем, какие задачи вы уже отдали AI и что из этого получилось. Из ответов соберем срез того, как это устроено у тимлидов в России.

🧭Дедлайн прохождения: 14 августа.

Трех победителей выберем с помощью рандомайзера. Остальным пришлем промокод на скидку 10% на билет.

Полный отчет по исследованию пришлем на почту после конференции. На закрытии TeamLead Сибирь 10-11 сентября объявим результаты со сцены.

↗️Заполнить и попасть в розыгрыш

Читать полностью…

ЧАСТЬ 3

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

Раскидайте в команде задачу по определению собственных процессов. Не наполняйте систему последовательно, а действуйте по ситуации. Есть идея по анализу встреч и формированию ТЗ для заказчика — оформляйте это в процесс и собирайте кубики. Появится ещё идея — ещё кубик. Через какое-то время вы сможете объединить кубики в одну систему. А если ждать и делать всё строго по порядку, процесс затянется.

Начинайте со спеки, а не с промпта. Прежде чем звать ИИ, коротко опишите, что должно получиться. Даже пара абзацев спеки экономит часы разгребания «не того» результата.

Ревьюйте много и на каждом стыке. На старте лучше перебдеть. Часть проверок потом сама превратится в навыки, но сначала держите контроль.

И не забивайте на смежников. Изолированное решение красиво живёт ровно до момента интеграции. Общая база, шеринг навыков и договорённости — это не «когда-нибудь потом», а часть подхода.

Я сейчас проживаю всё это на своей команде в реальном времени, так что за красивую теорию не выдаю — рассказываю как есть) Если у вас есть свой опыт внедрения ИИ в процессы команды — делитесь в комментах, очень интересно, кто как решает эту задачу. 👇

Читать полностью…

Привет, друзья!👋

Сразу предупрежу! Статья на эту тему получилась очень длинной, поэтому я решил разбить её на 3 части и выпустить их в течение дня. Это первая.

Всё больше и больше погружаюсь в тему ИИ и внедрения его в командную работу. Перепробовал уже много чего, от cline и kilocode до cursor и claude, и сделал для себя целую кучу выводов. Теперь хочу с вами поделиться)

Начну с проблемы. Инфошум и ожидания от ИИ слишком большие, и, как правило, их источник — это люди, которые не имеют отношения (или имеют косвенно) к разработке продуктов. В чём беда? В том, что из коробки он вам сделает изолированный продукт. Вы сразу обрадуетесь и будете в восторге от результата. НО! Для более качественного и детального продукта вам нужны знания на каждом участке SDLC. Без них вы не сможете интегрировать продукт с другими микросервисами, потому что банально работаете только в контексте одного продукта. А командная разработка микросервисов (да и монолитов) идёт в плотном взаимодействии с другими командами.

Дальше — сам подход. Текущая версия SDLC ещё не адаптирована под работу нескольких команд с ИИ. Да, все пытаются встать на эти рельсы, но чёткого свода правил пока нет. Все только пробуют интегрировать.

При этом ИИ пока помогает в конкретных задачах. Если это разработка, то разработчик пишет под свой стек, свои задачи и архитектурные правила в собственные навыки, которые помогают ему решать задачи. Общей кнопки, которая запускала бы процесс создания КАЧЕСТВЕННОГО продукта, ещё нет, потому что на каждом участке SDLC нужны свои навыки.

И на каждом участке SDLC должно быть качественное ревью. Без знаний в аналитике вы не сможете грамотно оценить ТЗ и требования заказчика и сделать нормальный продукт (я уж молчу про разработку).

MCP, скилы и промпты — это, конечно, круто. Но без грамотного подхода у вас получится свалка, которая просто жрёт токены.

К чему я это всё. ИИ — это инструмент, который надо встроить в процесс. И пока процесс не выстроен, вы будете плодить изолированные решения.

Читать полностью…

Привет, друзья!👋

Сегодня хотел бы поделиться с вами личным опытом проведения встреч по 1к1 и как я научился экономить "мыслетопливо".

Что я для этого делаю.

Как ранее говорил, я работаю в Obsidian и все заметки по команде и своей работе я храню там. Там у меня уже выстроенный процесс, который я формировал и докручивал весь этот год.

Очень удобно хранить сценарий проведения 1к1 в виде заметки. Благодаря такому шаблону я теперь создаю под каждую такую встречу уже готовый экземпляр по сотруднику — и она автоматом создаётся в необходимой папке.

Но оставалась главная проблема. Из-за того, что в команде не один человек, надо такую деятельность вести по всем сотрудникам команды. И где-то уже на 3–4-м созвоне эмоциональные силы заканчиваются, продуктивность падает и тяжело просто слушать человека и давать профит.

Сначала я попробовал размазать такие встречи на неделю и получалось, что раз в день я провожу 1–2 такие встречи. Вроде стало легче, но на самом деле проблема не ушла. Я всё также уставал и не мог сфокусироваться на целях.

Как пришёл к автоматизации.

Я решил воспользоваться кратким саммери встречи, который мне подбивает ИИшка. Но проблема появилась другая — она не понимает контекста встречи. Да, она может составить краткое саммери, сделать транскрипцию встречи, но всё равно это сырой материал.

Тут я и начал думать, как мне автоматизировать этот процесс, но не потерять в качестве. Получился такой флоу:

1️⃣Mymeet делает мне запись встречи + её транскрипцию со всеми диалогами и кратким саммери с задачами.
2️⃣Далее я в Cursor по MCP подключил mymeet. Теперь мне не нужно каждый раз копировать текст всей встречи — могу сразу анализировать.
3️⃣Тут начинается самое интересное. Я написал собственный скилл для ИИшки, который понимает контекст встречи, может определить сотрудника (так как я описал каждого члена команды) и, самое главное, может сохранять результат анализа сразу в Obsidian. С помощью навыка ИИ не только понимает контекст встречи и кто участник 1к1, но ещё и может сформировать готовый отчёт, вытащить оттуда мои задачи (в навыках я и про себя рассказал) и закинуть всё это в Obsidian.

Что получилось в итоге.

Этими инструментами я обеспечил себе хранение контекста прошлых встреч и запись обещаний на 1к1 в виде личных задач.

Как итог, я снизил личную нагрузку и сохранил то самое "мыслетопливо". Важно заметить, что эти инструменты не должны заменять живого общения с сотрудниками и что это не замена вас как лидера. Просто это ваш помощник в резюмировании встреч. Потому что потом вам так или иначе надо работать с тем, что у вас получилось — и тут ИИ уже не поможет.

Как вам адаптировать схожую систему у себя.

В первую очередь начинайте делать записи встреч. Потом кидайте их в ИИшку для анализа. Надо начинать с простого, потому что у каждого тимлида разные ситуации и инструменты, с которыми мы работаем. После этого составьте персональный скилл по анализу таких встреч именно под вашу команду. Эти два инструмента уже заметно вам облегчат работу. Уже с этим вы можете автоматизировать свою работу как угодно.

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

А как вы автоматизируете свою рутину? Поделитесь своим опытом/мнением в комментариях — будет интересно почитать👇

Читать полностью…

Привет, друзья!👋

Сегодня хочу рассказать про теорию ограничений Элияху Голдратта. Голдратт был физиком, который ушёл консультировать заводы и придумал, как искать в них главную проблему. Свою идею он описал в книге «Цель», и написана она не как учебник, а как роман, поэтому читается легко.

Суть теории в том, что в любой системе есть одно самое узкое место, и именно оно определяет скорость всей системы. Не сумма усилий всех участников, а одно звено. Пока вы его не расширите, ускорять всё остальное бессмысленно. А когда расширите, узкое место просто переедет в другое место, и искать его придётся заново.

Теперь переносим это на нашу работу. Представьте, что разработчики стали писать код в два раза быстрее. Отлично? Не факт. Если задачи потом неделю ждут тестирования или висят на согласовании у заказчика, то быстрый код просто копится в очереди перед этим местом. Скорость доставки не меняется, а незавершёнки становится больше. И узкое место совсем не обязательно сидит в разработке. Это могут быть согласования, релизное окно или один человек, через которого проходят все решения.

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

Пишите в комментариях или в нашем чате тимлидов👇

Читать полностью…

Часть 1. Зачем делить задачу на контуры

Привет, друзья!👋

Сегодня бы хотелось подробно рассмотреть тему с переключением контекста в ИИшке и для чего оно нужно. Статья получилась большой, поэтому разбил ее на две части.

Давайте начнем с самого начала. Вообще почему такая проблема появилась и как к ней пришли?

Первое, с чем столкнулись в разработке, — это проблема перекидывания инфы из одного чата в другой. Сессия открыта, контекст от старта анализа до разработки уже достиг 40%, и возникла необходимость открыть новое окно и продолжать там общаться. Зачем переключаться после заполнения 40% контекстного окна? Для достижения максимальной точности работы LLM (больших языковых моделей) лучше всего использовать до 40–50% от заявленного контекстного окна модели.

Но как перенести все то, что было в одном окне, в другое? Ответ оказался на поверхности. Надо просто разделить процесс работы над задачей на контуры.

Первый контур — это выявление бизнес-требований, написание ТЗ, создание бизнес-сценариев и т.п. В этом контуре мы собираем все, что есть по задаче, и превращаем это все в бизнес-доки. Вот и первое контекстное окно. Описываем скилы, которые на вход будут принимать все наработки по задаче, а на выходе получим комплект доков, которые потом понесем на следующий контур.

Второй контур — это описание архитектуры. Тут мы работаем с бизнес-доками относительно нашего продукта. На вход отправляем то, что получилось на первом контуре, и уже в новом контекстном окне работаем над метчингом всего, что есть, с точки зрения архитектуры. Описываем новый/старый функционал уже на основе кодовой базы продукта. АПИшки, бизнес-объекты, их атрибуты и т.п. Уже этот результат мы можем направить на новый контур.

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

Четвертый контур — тестирование. Тут пишем тесты API и UI, проверяем код на соответствие требованиям, заранее установленным по вашему продукту. Читал, что у некоторых есть практика по написанию кода по предыдущим этапам, а потом разработка этого кода, но уже по TDD, и в финале их сравнивают. Интересно, но мне кажется, вначале это избыточно.

Что получается? На каждом контуре у вас отдельная сессия в чате, контекстное окно не успевает заполниться до тех самых 40–50%. Также мы можем ревьюить результаты и править на каждом контуре. Не сразу кидаем задачу, а дробим ее на этапы.

Руками все это собирать долго, но есть инструмент, который сильно упрощает жизнь. Про него расскажу во второй части)

Читать полностью…

Привет, друзья!👋

Часто делюсь тут с вами собственными лайфхаками/системами и т.п. по автоматизации рутины. Да, я многое перекладываю ИИшке. Встречи сами превращаются в заметки и задачи, отпуска команды раскидываются одним промтом, а утром меня уже ждёт собранный ежедневник. Кайф? Кайф.

Но есть нюанс. Рутина ушла, а вопрос «а куда я вообще иду?» никуда не делся. ИИ отлично разгребает то, что ты ему дал. А вот решить, что действительно важно в этом месяце, и честно признаться себе, что из этого так и не сделал, за тебя не сможет никто.

И проблема не в том, что вы что-то неправильно сделали с ИИ, а в том, что ИИ вас не заменяет и не заменит. Это лишь способ автоматизировать вашу рутину и оставить пространство для творчества/развития/планирования и всего другого, на что раньше сил было меньше. Условно ИИ — это ручка, а вы — рука, которая пишет. Ручка и бумага без писателя — это просто инструмент.

А чтобы рука не писала что попало, нужна своя система. Я для себя это закрываю обзорами. Каждый день быстро пробегаю по задачам, а в конце недели ставлю себе обзор и смотрю на неделю целиком. Без этого вся автоматизация превращается в очень быструю беготню по кругу.

Если хочется прокачать именно «руку» — ставить цели, планировать и не терять фокус, — загляните в «Записки трекера».

Читать полностью…

Привет, друзья!👋

Как вы заметили, я в последнее время очень много пишу про ИИ.

Пишу не потому что я делаю какой-то прогрев для своих курсов или занимаюсь инфоцигансвтом.

Делюсь с вами реальным опытом, который проживаю совместно со своей командой и пишу сюда те мысли и наблюдения которые проживаю здесь и сейчас.

К чему я это?

Если вас тошнит от темы ИИ (я вас прекрасно понимаю) то знайте, у меня нет цели что-то восхвалять и смотреть на это через розовые очки.

Я за трушную практику и обмен опытом:)

Есть у меня в obsidian одна заметочка, где я подробно расписал технологии и инструменты для работы с ИИ в нашем ЖЦПО (ну или по нормальному SDLC).

Все теже, но чуть-чуть с ИИшенкой, записки тимлида.

Читать полностью…

Привет, друзья!👋

Брал долгий перерыв и возвращаюсь к вам с новыми силами!)

Накопилось много идей (очень много по ИИшке) и в ближайшее время вам все тут расскажу.

Расскажите как у вас дела? Что изменилось у вас за этот месяц?

Читать полностью…

Привет, друзья!👋

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

Смотрите, какая штука. Если для сотрудника нет никакой разницы между тем, чтобы сдать всё в срок (а то и раньше) или спокойно проехать по дедлайну, то зачем ему выбирать первое? ЗП он всё равно получит. Ну проедет по срокам — максимум кто-то повозмущается, и на этом всё. А раз последствий нет, то и стимула нет.

Кого в этом винить? Легче всего сказать «сотрудник немотивированный» и закрыть вопрос. Но мне кажется, что чаще корень в другом. Например, в самой компании нет выстроенной системы стимулирования. Можно ли стимулировать не только деньгами? Если да, то как стимулировать интересными задачами, признанием и повышением ответственности?

Можно ли вообще найти единый источник этой проблемы? Или у каждого свой стимул, и задача тимлида — нащупать его для каждого отдельно?

Вот об этом и хочу подискутировать:
— где вы сами находите стимулы в работе?
— это задача компании, тимлида или самого сотрудника?
— и что делать, если системы стимулирования в компании просто нет?

Делитесь мнением в комментариях или в нашем тимлидовском чате (http://t.me/teamlead_stories_chat)👇

Читать полностью…

<poll>

Читать полностью…

Привет, друзья!👋

Подготовил для вас свой тулкит тимлида для работы в Obsidian.

Это не просто набор заметок, а связанная система: рабочие заметки и задачи, база по 1:1, статьи — и всё это дружит с анализом встреч. Транскрипция, саммари, а потом автоматический перенос задач прямо в ваши заметки. То есть встреча превращается в готовые записи и таски.

Всё, что нужно сделать, — открыть GUIDE.md и следовать инструкции)

Дальше советую сразу открыть папку vault в Obsidian, запустить ИИ и попросить настроить пространство под вас. Подготовленный скилл всё сделает за вас (и да, это подробно описано в GUIDE.md).

Если что-то непонятно или не работает — пишите в комментариях, помогу разобраться)👇

Читать полностью…

Привет, друзья!👋

В прошлом посте «Что такое SDD и почему столько шума» я разобрал теорию и познакомил вас с openspec. Теперь, как обещал, делюсь личным опытом — как мы вкатываем это всей командой прямо сейчас. Сразу скажу: мы ещё в процессе, финального видения нет, поэтому мне очень интересно узнать, как с этим у вас и что вы вообще об этом думаете.

Давайте по порядку, как оно у нас шло.

Первое — выбор инструмента. Мы начали с openspec. Почему он? Комьюнити постепенно растёт (больше 50к звёзд на гите), инфы всё больше, порог входа низкий. Смотрел ещё на BMAD и AI Factory, но они тяжелее, а мне на старте важнее было быстро попробовать и, если не зайдёт, без боли откатиться.

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

Третье — собственные скилы по продукту. Мы начали собирать навыки, которые переводят нашу доку в спецификации. Такой скилл можно оформить чуть ли не как услугу для соседних команд, потому что в компании подход к ведению доки плюс-минус одинаковый. Один раз собрал — облегчил жизнь не только себе.

Четвёртое — поинты проверки. Их можно закидывать либо в навыки, либо в правила, тут кому как удобнее. Мы для себя решили, что на старте контроля должно быть много. Проверяем не только финальный результат, а каждый этап. Потом, когда флоу устаканится, часть проверок превратим в навыки, но в начале лучше перебдеть.

Как я и говорил, мы пока в пути, и на финальную методичку это не тянет. Поэтому если у вас есть свой опыт вкатывания команды в SDD — очень жду в комментариях, кто с какими граблями столкнулся и как их разрулил 👇

Читать полностью…

Привет, друзья! 👋

Недавно осознал, что за прошедшие 4 месяца я ничего не читал по менеджерской движухе. Исправляюсь.

Выбор пал на «15 заповедей руководителя», так как эта книжка часто попадалась в рилсах (хоть какая-то польза).

Прочитал только четверть, и сложилось ощущение, что книжка больше для продукт-овнеров, чем для тимлидов. Хотя, если вы тимлид и очень близко работаете с продуктом и можете на него влиять, то книжка вам пригодится.

В общем, пора возобновить мою старую рубрику с обзорами менеджерских книжек.

Посоветуйте хорошие книжки в комментариях, а то я сейчас набиваю корзину из качественного чтива.👇

Читать полностью…

Привет, друзья!👋

Продолжаем разбирать вопросы из моей карточной игры для тимлидов.

Сегодняшняя карточка — про документацию на процессы. Всё больше хайпа вокруг SDD, а этот подход хорошо показывает себя в связке с ИИ — и как раз строится вокруг того, что процесс и требования описаны, а не живут в чьей-то голове.

Правила простые:
1️⃣Читаете вопрос.
2️⃣Пишете свой ответ в комментариях.

Здесь нет единственно верного ответа — делитесь опытом, сомнениями и тем, как бы поступили вы.

Жду ваше мнение в комментариях или в нашем тимлидовском чате (http://t.me/teamlead_stories_chat) 👇

Читать полностью…

ХОЛИВАР МЕСЯЦА!

Что будет в голове топ-менеджмента, если команды внедрят ИИ, разработчики будут писать код еще быстрее, но продажи не станут расти?

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

Я не знаю. Думаю, когда команды подружатся с вернувшимся из мёртвых SDD, интегрируют OpenSpec (или то, что вы там выбрали у себя), и всё реализуется, то уже причин сваливать всё на команды резко исчезнет. Менеджерам придётся выкручиваться по-другому.

А вы что думаете на этот счёт? Думаете, внедрение ИИ в разработку реально увеличит продажи? Жду ваше мнение в комментариях👇

Читать полностью…

ЧАСТЬ 2.

В прошлой части я разложил, что не так. Теперь про то, что мы сейчас с этим делаем — и что переживаю лично прямо сейчас.

Мы пытаемся препарировать весь SDLC на составные участки и внутри каждого собрать кубики с процессами обработки через ИИ. Например, участок с аналитикой превращается в набор исполняемых кубиков: от анализа встречи с заказчиком и формирования требований до концепции по реализации функционала. И каждый участок команда собирает из тех кубиков, которые ей подходят. У каждого кубика свой набор скилов и данных, относительно которых он работает. Если сделать один большой кубик и закинуть туда все скилы со всеми знаниями, то получишь размыв контекста, и итог будет не тот, что нужен.

Второе — расстановка поинтов по ревью. Важный этап, потому что за работой ИИ надо следить на всех участках, иначе качественного продукта не будет. В первой версии воркфлоу лучше расставить как можно больше точек проверки. Потом, когда флоу устаканится, часть из них можно превратить в навыки для ревью. Но в начале контроля должно быть много.

Третье и самое главное — взаимодействие со смежными командами. Общая база знаний, шеринг навыков, бестпрактис и кодовая база. Как это будет выглядеть, сказать сложно, но что это должно быть — 100 процентов. Можно всё сложить в общей репе гита, можно подрубить MCP к confluence и т.п. Тут вы сами определяете и обсуждаете это с коллегами. Без этого вы просто генерируете изолированные решения.

Пока мы пилим кубики, я поймал себя на мысли, что мы фактически возвращаемся к спеке. И тут я вспомнил про SDD — Spec-Driven Development, разработку от спецификации.

Идея старая: сначала пишешь спеку — что именно должно получиться, какие требования, контракты, поведение, — и только потом код. Раньше это работало так себе. Спеку лень писать, ещё ленивее поддерживать, и через месяц источником истины становился код, а документация превращалась в кладбище. Методология вроде правильная, но на живых людях буксовала.

А теперь смотрите, что меняется с ИИ. ИИ гораздо лучше работает не с «сделай мне хорошо», а с чёткой спекой на входе. Даёшь ему точное описание — получаешь предсказуемый результат. То есть спека перестаёт быть бюрократией «для галочки» и становится тем, что реально управляет генерацией.

И вот тут для SDD как будто открывается вторая жизнь. Ту рутину, из-за которой методология не приживалась (писать и поддерживать спеки руками), теперь можно частично переложить на ИИ. Спека становится главным артефактом: ты ревьюишь не тонны сгенерённого кода, а спеку — короткую и понятную. Поправил спеку — перегенерил участок. Это идеально ложится на наши кубики: каждый кубик, по сути, и есть маленькая спека со своим набором навыков и данных. И ревью-поинты из второго пункта встают ровно на стыки этих спек.

Не скажу, что мы уже всё так построили — я в процессе. Но направление чувствуется правильное.

Читать полностью…

Привет, друзья!👋

Продолжаем разбирать вопросы из моей карточной игры для тимлидов.

Сегодняшняя карточка — про обещания на one-to-one: когда «потом» становится ответом по умолчанию, а встреча с тимлидом перестаёт приносить реальную пользу.

Правила простые:
1️⃣Читаете вопрос.
2️⃣Пишете свой ответ в комментариях.

Здесь нет единственно верного ответа — делитесь опытом, сомнениями и тем, как бы поступили вы.

Жду ваше мнение в комментариях или в нашем тимлидовском чате (http://t.me/teamlead_stories_chat)👇

Читать полностью…

Если вы читаете этот канал, тема управления командами вам близка. Тогда держите анонс 👋

В сентябре впервые проходит TeamLead Сибирь — конференция для тимлидов и руководителей от Ontico (те же, кто делает TeamLeadConf в Москве и Saint TeamLead в Питере).

Темы для тех, кто ведет команду: найм и удержание, процессы, управление изменениями, оптимизация ресурсов.
Тема года: AI в работе тимлида. Как посчитать экономику внедрения, почему трансформация буксует и что ИИ меняет в буднях менеджера.

Среди спикеров Точка Банк, Альфа-Банк, X5 Tech, Флант, Koronatech, ИнфоТеКС, Совкомбанк, Т-Банк. Плюс мастер-классы на кейсах и общение с теми, кто решает те же задачи.

10–11 сентября, Новосибирск.
Билеты и программа 👈

Читать полностью…