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

Сегодня про метод Слепого пятна. Бывает, что мы годами не видим каких-то вещей в своих проектах, процессах и в себе, и при этом искренне уверены, что всё учли.

Суть метода в том, чтобы специально искать то, что упускаешь. Не ждать, пока оно само вылезет на проде или на ретро, а заранее сесть и задать себе неудобные вопросы. Что я не учитываю в этом проекте? Какую часть задачи обхожу стороной, потому что она скучная или непонятная? Что может пойти не так, и что я буду делать, если пойдёт?

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

Как это делать на практике? Перед планингом или релизом садитесь и записываете, на чём вообще держится ваш план. Что заказчик быстро ответит, что стенд будет свободен, что никто не уйдёт на больничный в самый неподходящий момент. А потом по каждому пункту спрашиваете себя, а что если нет? Почти всегда находится что-то, о чём вы даже не думали)

Самое интересное начинается, когда подключается кто-то со стороны. Свои слепые пятна сам видишь плохо (на то они и слепые). А вот коллега, который не варился в задаче, часто с первого взгляда замечает то, мимо чего ты ходил неделями. Поэтому не стесняйтесь прямо спрашивать «что я тут не вижу?». На 1к1, на ревью, на планинге.

Пригодится везде, где цена ошибки высокая. В планировании, в оценке рисков, перед релизом или когда берёшь на себя новый процесс.

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

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

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

Давайте поговорим о негативных сторонах ИИ.

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

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

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

Третья проблема сейчас не такая яркая, но в перспективе будет очень большой. Это токены. Да, текущая токеномика достаточно выгодная для разработки, но уже сейчас главы крупных компаний заявляют, что токеномика не соответствует рынку. Есть опасение, что цена через год-два вырастет в х10.

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

Ну и напоследок — проблема высвободившихся мощностей. Код пишется быстро, но есть ли у вас столько функционала под разработку? За неделю все сделали то, что должны были за месяц. А дальше что? Открывать новые продукты и идти в новый бизнес? Или сокращать команду под количество выдаваемой мощности?

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

А какие минусы видите вы? Может, я что-то упустил или, наоборот, сгустил краски? Пишите в комментариях или в нашем чате тимлидов👇

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

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

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

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

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

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

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

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

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

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

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

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

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

Начну с того, что удивило меня самого. Я не собирался превращать канал в блог про нейросети. Честно. Но открываю список постов за лето и осень, а там SDD, скилы, контекстные окна, передача знаний по ИИ... В какой-то момент поймал себя на мысли, что пишу про ИИ чаще, чем про людей. Объяснение простое. Сейчас это большая часть моей работы. Мы прямо сейчас вкатываем команду в новые процессы, набиваем шишки, и держать это в себе просто не получается.

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

А вот что я точно хочу поменять. Канал начинался с людей. С 1к1, с выгорания, с того, как давать обратную связь и защищать команду от давления заказчика. И этого в последнее время было мало. ИИ ИИ, а команду никто не отменял) Так что буду возвращать баланс.

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

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

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

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

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

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, скилы и промпты — это, конечно, круто. Но без грамотного подхода у вас получится свалка, которая просто жрёт токены.

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

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