Чутка не про ИИ и ИТшку)

У меня есть вредная привычка, но достаточно распространённая в ИТ-кругах)

Я часто хожу в кальянные.

В последнее время меня сильно увлекла данная сфера.

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

В общем, если будете в Питере, то могу вам посоветовать пару интересных мест с топовыми кальянами, едой и сервисом)

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

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

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

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

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

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

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

Часть 2. Что тут не так

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

Вчера в первой части я разобрал, как выглядит процесс, если все роли в SDLC отдать одному человеку с ИИ. Теперь давайте разберемся, что тут не так.

1️⃣Получается, один человек собрал все требования, разработал архитектуру, написал код и сам же его проверил. Звучит очень странно: если все процессы завязать на одном человеке, то не факт, что получится что-то качественное. Свои ошибки, как известно, видно хуже всего.

2️⃣Окей, будем считать, что у нас мощный боец на всех контурах. Но что делать, если он ушел в отпуск или заболел? Процесс останавливается? Нет, это не вариант. Нужен как минимум еще один человек, который будет помогать. Условно лид и рядовой сотрудник.

3️⃣Так, у нас уже получается два человека. А что по операционке? Она же никуда не ушла. Показатели команды, 1к1, дейлики, различные созвоны со стейкхолдерами, подготовка к показам и т. п. Кто все это будет делать? Тут или отменять всю операционку, или нанимать еще одного человека. А если он уйдет в отпуск? Кто тогда будет заниматься операционкой? Если перекинем ее на оставшегося человека, то кто будет делать его работу? Получается, нужен еще один человек. Уже трое.

4️⃣А теперь самое главное. Где мы найдем хотя бы одного человека, который будет шарить в бизнесе продукта, в архитектуре, справляться с кодом, тестами и сопровождением? Не думаю, что таких специалистов много и что все они готовы идти на ставку одного разраба.

5️⃣Ну и завершающий, но не менее важный фактор — переключение контекста. Я сомневаюсь, что один человек может это затащить. День будет состоять из созвонов, чата с ИИшкой, контроля переписок со стейкхолдерами и т. п. А на глубокую работу, ради которой его и нанимали, времени почти не останется.

Что я предлагаю в развитии:

1️⃣Нужно разграничить процесс на контуры, где на каждом есть минимум один человек. Он будет отвечать за свой контур, будет экспертом в определенной области и будет отвечать за входные и выходные данные своего контура, чтобы качественнее передавать артефакты в другой контур. ИИ при этом никуда не уходит — он помогает каждому на своем участке.

2️⃣Тимлид нужен как человек, который управляет процессами. Надо не забывать, что микросервисы в продукте могут писать другие команды, и коммуникация с ними никуда не девается.

3️⃣Надо качественно подумать над проблемой bus-фактора. Не должно быть такого, что если вытащить одного человека из процесса, то все встанет. Как минимум надо продумать систему обучения в смежных контурах.

4️⃣Никто из нас не застрахован от увольнений. К процессу онбординга теперь надо подходить более качественно. Во всех компаниях сейчас свой процесс взаимодействия с ИИ, и об этом надо помнить, когда вводишь нового человека в команду.

А что вы думаете? Какие роли сейчас у вас начинают появляться? Пишите в комментариях свое мнение👇

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

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

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

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

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

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

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

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

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

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

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

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

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

Самое интересное начинается, когда подключается кто-то со стороны. Свои слепые пятна сам видишь плохо (на то они и слепые). А вот коллега, который не варился в задаче, часто с первого взгляда замечает то, мимо чего ты ходил неделями. Поэтому не стесняйтесь прямо спрашивать «что я тут не вижу?». На 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 — очень жду в комментариях, кто с какими граблями столкнулся и как их разрулил 👇

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

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

Хочу сегодня поговорить немного про стиль, ИИ и моё отношение к этому всему.

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

И если честно, мне кажется, скоро будет волна хайпа ручного труда ВЕЗДЕ.

Это как вещь, которую вы купили в массмаркете или вам сделали её на заказ.

Да, ту, что сделали на заказ, раза в 2 или даже в 3 дороже, но её покупают. На это есть спрос.

При чём тут ИТшка? :)

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

В общем, надо нам переждать ИИ-зиму и дальше посмотрим :)

Обещал не писать про ИИ. Сори :) Но тут реально больше про людей.

Ну и, как мне кажется, в будущем (2–4 года) креативные люди будут стоить ГОРАЗДО дороже, так как все устанут от типичных «b2b saasилонмаскклода» стартапов.

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

<poll>

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

Часть 1. Как это выглядит

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

Текст получился большим, поэтому разбил его на две части. Это первая.

Сегодня хотел бы поговорить про тренд, который потихоньку появляется везде. Это попытка заменить все роли в SDLC одной. Один человек собирает бизнес-требования, превращает их в концепции, пишет по ним архитектуру, разрабатывает код, пишет тесты и тестовую документацию — и все это с помощью ИИ!

С точки зрения производства это очень логично. Мы экономим деньги на количестве людей, и звучит это очень приятно. НО!

А действительно ли в этом есть качество, и нужна ли такая оптимизация?

Давайте рассмотрим весь процесс от и до по пунктам:

1️⃣Первый этап — это сбор требований и анализ. Требования могут поступать из разных источников: созвон с заказчиком, правки, прилетевшие на почту, сообщения заказчика в чате, попутный анализ рынка, который тоже расширяет функционал. А, ну и, конечно же, обратная связь от самих пользователей. Источников достаточно, и все их нужно контролировать. И тут ИИ поможет только в обработке информации. Как минимум нужен сотрудник с глубоким пониманием бизнеса продукта. Не все доработки нужны и попадают в рынок, а некоторые косвенно могут пересекаться с существующим функционалом. Если делать все бездумно и считать каждую хотелку новой фичей, то рано или поздно получим продукт, который отвечает на все запросы, но настолько переполнен функционалом, что по нему тяжело пройти хотя бы один сценарий использования. Пройти можно, но экспириенс будет не самым приятным для пользователя. А продукт мы делаем именно для него. Да, с помощью ИИ можно попутно писать юзер-кейсы и обновлять их, но ревьюить и контролировать это должен человек. Вроде звучит адекватно для одного человека, но мы не забываем, что ему еще и другое делать.

2️⃣Переходим ко второму этапу. На этом контуре у нас уже есть готовые бизнесовые доки. Теперь пора проработать архитектуру решения. Что надо знать? Ну как минимум понимать, какие микросервисы участвуют в решении, какая у них архитектура, какие бизнес-объекты, какие интеграции и т. п. Иначе мы свалимся в то, что наши решения будут изолированы и будут повторять функционал других микросервисов. Это плохо, так как продукт станет тяжеловесным и постепенно превратится в монолит. Так что нам нужен человек, который будет разбираться в архитектуре продукта. Вроде как это можно повесить на того же человека, что и в первом пункте. Важно понимать, что он должен качественно ревьюить все, что нагенерировала ИИшка.

3️⃣Уже как минимум два больших процесса, за которые отвечает один человек. Человек с такими знаниями и опытом — достаточно ценный сотрудник. И ценен он не умением пользоваться ИИ, а именно умением ревьюить то, что ИИ выдал на выходе. На третьем этапе он начинает писать код, так как у него есть все необходимое для разработки. Если первые два этапа выполнены качественно, то написать код становится намного проще. Написать проще, но кто будет его ревьюить? Ревью кода можно отдать ИИшке, а заодно поручить ей писать, прогонять и поддерживать тесты. Тут надо понимать, что одних API- и UI-тестов недостаточно. Надо проводить нагрузочное, нефункциональное, фаззинг-тестирование и т. п. И результаты всего этого кто-то тоже должен смотреть и понимать, что с ними делать.

4️⃣Ну и дальше идут деплой, обучение и сопровождение решения у заказчика. Это отдельный вид работы, который требует большого внимания к продукту: инциденты, вопросы пользователей, доработки по итогам эксплуатации. И все это снова возвращается к нам в виде новых требований — то есть в первый пункт.

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

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

<poll>

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

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

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

Начну с того, что удивило меня самого. Я не собирался превращать канал в блог про нейросети. Честно. Но открываю список постов за лето и осень, а там 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

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