AI не решит проблему плохого фокуса
Есть соблазнительная мысль:
если разработчики будут использовать AI, команда начнёт работать быстрее.
В каком-то смысле это правда.
AI действительно может ускорить много локальных задач: написать boilerplate, накидать тесты, объяснить кусок кода, помочь с рефакторингом, подготовить черновик документации.
Но есть нюанс.
AI ускоряет исполнение внутри задачи.
Он не чинит систему, в которой задачи постоянно прерываются, переоткрываются, ждут ревью, меняют приоритет и теряют контекст.
Если у команды плохой фокус, AI может сделать ситуацию даже хуже.
Почему?
Потому что раньше человек физически не успевал создать слишком много незавершённой работы.
А теперь успевает.
Можно быстрее написать код.
Быстрее открыть pull request.
Быстрее нагенерировать вариантов.
Быстрее начать следующую задачу.
Но если ревью и принятие решений не ускорились, очередь просто переезжает в другое место.
Получается странная картина:
— кода стало больше;
— pull request’ов стало больше;
— обсуждений стало больше;
— а delivery быстрее не стал.
И тимлид в этот момент может попасть в ловушку.
На уровне активности всё выглядит хорошо.
Команда “использует AI”, задач в работе много, артефакты появляются быстрее.
Но продуктовая ценность всё равно выходит медленно.
Проблема в том, что AI хорошо помогает на уровне отдельного исполнителя, но delivery — это командная система.
В ней есть:
— постановка задачи;
— понимание цели;
— декомпозиция;
— архитектурные решения;
— ревью;
— тестирование;
— релиз;
— обратная связь от пользователей.
Если узкое место не в написании кода, ускорение написания кода не даст большого эффекта.
Простой пример.
Команда страдает от того, что задачи плохо подготовлены.
Разработчики постоянно уточняют требования, спорят с аналитиками, ждут решений от бизнеса.
Внедрили AI.
Теперь код по неясным требованиям появляется быстрее.
Но требования от этого не стали яснее.
Или другой пример.
Главный bottleneck — code review.
Ревью и раньше висели по 2–3 дня.
С AI разработчики стали быстрее открывать pull request’ы.
Очередь на ревью выросла.
Lead time не улучшился, а ревьюеры начали уставать ещё сильнее.
Поэтому я бы не начинал внедрение AI с вопроса:
“Как нам писать код быстрее?”
Я бы начал с другого:
“Где у нас сейчас реально тормозит поток работы?”
Если тормозит boilerplate — AI поможет.
Если тормозит ревью — нужны правила ревью, размер PR, ownership, возможно, AI-помощники для первичной проверки.
Если тормозит постановка задач — нужен лучший discovery и Definition of Ready.
Если тормозит релиз — надо смотреть CI/CD, тесты, согласования и rollback.
AI — это усилитель.
Но он усиливает не только хорошее.
Если в команде порядок, он может дать хороший прирост.
Если в команде хаос, он может просто помочь производить хаос быстрее.
Что можно сделать тимлиду:
1. Перед внедрением AI посмотреть текущий flow.
2. Найти реальное узкое место.
3. Не мерить эффект только количеством написанного кода.
4. Смотреть на lead time, cycle time, ревью, баги и возвраты.
5. Договориться с командой, где AI помогает, а где создаёт риск.
Мне кажется, главный вопрос про AI в разработке сейчас не “заменит ли он программистов”.
Более практичный вопрос:
какую часть нашей системы он ускорит, и не сломается ли от этого всё остальное?
А у вас AI уже ускорил delivery или пока только написание кода?
Есть соблазнительная мысль:
если разработчики будут использовать AI, команда начнёт работать быстрее.
В каком-то смысле это правда.
AI действительно может ускорить много локальных задач: написать boilerplate, накидать тесты, объяснить кусок кода, помочь с рефакторингом, подготовить черновик документации.
Но есть нюанс.
AI ускоряет исполнение внутри задачи.
Он не чинит систему, в которой задачи постоянно прерываются, переоткрываются, ждут ревью, меняют приоритет и теряют контекст.
Если у команды плохой фокус, AI может сделать ситуацию даже хуже.
Почему?
Потому что раньше человек физически не успевал создать слишком много незавершённой работы.
А теперь успевает.
Можно быстрее написать код.
Быстрее открыть pull request.
Быстрее нагенерировать вариантов.
Быстрее начать следующую задачу.
Но если ревью и принятие решений не ускорились, очередь просто переезжает в другое место.
Получается странная картина:
— кода стало больше;
— pull request’ов стало больше;
— обсуждений стало больше;
— а delivery быстрее не стал.
И тимлид в этот момент может попасть в ловушку.
На уровне активности всё выглядит хорошо.
Команда “использует AI”, задач в работе много, артефакты появляются быстрее.
Но продуктовая ценность всё равно выходит медленно.
Проблема в том, что AI хорошо помогает на уровне отдельного исполнителя, но delivery — это командная система.
В ней есть:
— постановка задачи;
— понимание цели;
— декомпозиция;
— архитектурные решения;
— ревью;
— тестирование;
— релиз;
— обратная связь от пользователей.
Если узкое место не в написании кода, ускорение написания кода не даст большого эффекта.
Простой пример.
Команда страдает от того, что задачи плохо подготовлены.
Разработчики постоянно уточняют требования, спорят с аналитиками, ждут решений от бизнеса.
Внедрили AI.
Теперь код по неясным требованиям появляется быстрее.
Но требования от этого не стали яснее.
Или другой пример.
Главный bottleneck — code review.
Ревью и раньше висели по 2–3 дня.
С AI разработчики стали быстрее открывать pull request’ы.
Очередь на ревью выросла.
Lead time не улучшился, а ревьюеры начали уставать ещё сильнее.
Поэтому я бы не начинал внедрение AI с вопроса:
“Как нам писать код быстрее?”
Я бы начал с другого:
“Где у нас сейчас реально тормозит поток работы?”
Если тормозит boilerplate — AI поможет.
Если тормозит ревью — нужны правила ревью, размер PR, ownership, возможно, AI-помощники для первичной проверки.
Если тормозит постановка задач — нужен лучший discovery и Definition of Ready.
Если тормозит релиз — надо смотреть CI/CD, тесты, согласования и rollback.
AI — это усилитель.
Но он усиливает не только хорошее.
Если в команде порядок, он может дать хороший прирост.
Если в команде хаос, он может просто помочь производить хаос быстрее.
Что можно сделать тимлиду:
1. Перед внедрением AI посмотреть текущий flow.
2. Найти реальное узкое место.
3. Не мерить эффект только количеством написанного кода.
4. Смотреть на lead time, cycle time, ревью, баги и возвраты.
5. Договориться с командой, где AI помогает, а где создаёт риск.
Мне кажется, главный вопрос про AI в разработке сейчас не “заменит ли он программистов”.
Более практичный вопрос:
какую часть нашей системы он ускорит, и не сломается ли от этого всё остальное?
А у вас AI уже ускорил delivery или пока только написание кода?
👍1
WIP: почему команда делает много, а заканчивает мало
Есть одна метрика, которую я люблю за простоту.
WIP — Work in Progress.
То есть сколько задач одновременно находится в работе.
Звучит скучно, но на практике это один из самых быстрых способов понять, почему команда вроде бы занята, а результата мало.
Типичная картина:
— один разработчик делает фичу
— параллельно чинит баг
— параллельно ждёт ревью
— параллельно отвечает на вопросы аналитика
— параллельно “быстро смотрит” срочную задачу
— параллельно у него ещё висит почти готовая доработка
В календаре человек занят.
В Jira всё двигается.
В чатах активность есть.
Но завершённых задач мало.
Проблема в том, что мозг не работает как процессор с бесконечным количеством потоков. Каждое переключение съедает контекст. Чем больше задач одновременно в работе, тем больше времени уходит не на работу, а на возвращение в неё.
Для тимлида WIP полезен как простой индикатор перегруза системы.
Если у команды одновременно открыто слишком много задач, почти всегда появляются симптомы:
— ревью копятся
— задачи долго висят в “почти готово”
— люди чаще забывают детали
— растёт количество мелких ошибок
— сроки становятся менее предсказуемыми
— все заняты, но мало что доезжает до done
Самое неприятное: высокий WIP часто выглядит как продуктивность.
Много карточек в работе.
Много обсуждений.
Много коммитов.
Много движения.
Но ценность появляется не когда задача “в работе”.
Ценность появляется, когда задача завершена и дошла до пользователя.
Что можно попробовать без сложных процессов:
1. Посмотреть, сколько задач сейчас реально в работе.
2. Отдельно посчитать задачи, которые “почти готовы”, но чего-то ждут.
3. На неделю договориться: не начинать новую задачу, пока не помогли закрыть старую.
4. Посмотреть, стало ли быстрее доходить до done.
Иногда лучший способ ускорить команду — не начать ещё одну задачу, а наконец закончить три старые.
А у вас чаще проблема в том, что задач мало в работе или наоборот слишком много?
Есть одна метрика, которую я люблю за простоту.
WIP — Work in Progress.
То есть сколько задач одновременно находится в работе.
Звучит скучно, но на практике это один из самых быстрых способов понять, почему команда вроде бы занята, а результата мало.
Типичная картина:
— один разработчик делает фичу
— параллельно чинит баг
— параллельно ждёт ревью
— параллельно отвечает на вопросы аналитика
— параллельно “быстро смотрит” срочную задачу
— параллельно у него ещё висит почти готовая доработка
В календаре человек занят.
В Jira всё двигается.
В чатах активность есть.
Но завершённых задач мало.
Проблема в том, что мозг не работает как процессор с бесконечным количеством потоков. Каждое переключение съедает контекст. Чем больше задач одновременно в работе, тем больше времени уходит не на работу, а на возвращение в неё.
Для тимлида WIP полезен как простой индикатор перегруза системы.
Если у команды одновременно открыто слишком много задач, почти всегда появляются симптомы:
— ревью копятся
— задачи долго висят в “почти готово”
— люди чаще забывают детали
— растёт количество мелких ошибок
— сроки становятся менее предсказуемыми
— все заняты, но мало что доезжает до done
Самое неприятное: высокий WIP часто выглядит как продуктивность.
Много карточек в работе.
Много обсуждений.
Много коммитов.
Много движения.
Но ценность появляется не когда задача “в работе”.
Ценность появляется, когда задача завершена и дошла до пользователя.
Что можно попробовать без сложных процессов:
1. Посмотреть, сколько задач сейчас реально в работе.
2. Отдельно посчитать задачи, которые “почти готовы”, но чего-то ждут.
3. На неделю договориться: не начинать новую задачу, пока не помогли закрыть старую.
4. Посмотреть, стало ли быстрее доходить до done.
Иногда лучший способ ускорить команду — не начать ещё одну задачу, а наконец закончить три старые.
А у вас чаще проблема в том, что задач мало в работе или наоборот слишком много?
👍1
AI не решит проблему плохого фокуса
Есть неприятная ловушка: кажется, что если дать команде AI-инструменты, то она начнёт делать больше и быстрее.
Иногда так и происходит. Код появляется быстрее. Черновики решений появляются быстрее. Документация пишется быстрее. Даже тесты иногда появляются быстрее.
Но если у команды уже был хаос с фокусом, AI этот хаос не чинит.
Скорее наоборот.
Если разработчика постоянно дёргают встречами, срочными вопросами, переключениями и “можешь быстро посмотреть”, то AI просто помогает быстрее плодить незавершённую работу.
Было:
— задача начата
— потом переключились
— потом ещё одна задача
— потом ревью
— потом срочный баг
— потом вернулись и уже не помним контекст
Стало:
— задача начата
— AI быстро нагенерировал кусок решения
— потом переключились
— потом ещё одна задача
— потом ещё один AI-черновик
— потом ревью стало сложнее, потому что теперь надо понять не только код, но и то, насколько автор сам его понимает
Проблема не в AI.
Проблема в системе работы.
AI хорошо ускоряет локальные действия: написать код, накидать варианты, собрать черновик, объяснить кусок документации.
Но delivery обычно тормозит не только на написании кода.
Он тормозит на:
— неясных требованиях
— долгом ревью
— постоянных переключениях
— зависимостях между людьми
— ожидании решений
— незавершённой работе
— отсутствии нормального приоритета
И если это не чинить, получится странная картина: активность выросла, кода стало больше, задач “в работе” стало больше, а до прода всё едет примерно так же.
Для тимлида тут простой вывод.
Перед тем как радоваться ускорению от AI, стоит посмотреть на flow команды:
1. Сколько задач одновременно в работе?
2. Где задачи чаще всего ждут?
3. Сколько времени занимает ревью?
4. Как часто людей дёргают вне текущей задачи?
5. Становится ли быстрее доставка ценности, а не только написание кода?
AI может быть хорошим усилителем.
Но он усиливает не только сильные стороны.
Он так же хорошо усиливает бардак.
Если в команде есть фокус, понятные приоритеты и нормальный процесс ревью — AI может дать хороший прирост.
Если всего этого нет, он просто добавит скорости туда, где и так не хватало управления.
А у вас AI уже ускорил delivery или пока только написание кода?
Есть неприятная ловушка: кажется, что если дать команде AI-инструменты, то она начнёт делать больше и быстрее.
Иногда так и происходит. Код появляется быстрее. Черновики решений появляются быстрее. Документация пишется быстрее. Даже тесты иногда появляются быстрее.
Но если у команды уже был хаос с фокусом, AI этот хаос не чинит.
Скорее наоборот.
Если разработчика постоянно дёргают встречами, срочными вопросами, переключениями и “можешь быстро посмотреть”, то AI просто помогает быстрее плодить незавершённую работу.
Было:
— задача начата
— потом переключились
— потом ещё одна задача
— потом ревью
— потом срочный баг
— потом вернулись и уже не помним контекст
Стало:
— задача начата
— AI быстро нагенерировал кусок решения
— потом переключились
— потом ещё одна задача
— потом ещё один AI-черновик
— потом ревью стало сложнее, потому что теперь надо понять не только код, но и то, насколько автор сам его понимает
Проблема не в AI.
Проблема в системе работы.
AI хорошо ускоряет локальные действия: написать код, накидать варианты, собрать черновик, объяснить кусок документации.
Но delivery обычно тормозит не только на написании кода.
Он тормозит на:
— неясных требованиях
— долгом ревью
— постоянных переключениях
— зависимостях между людьми
— ожидании решений
— незавершённой работе
— отсутствии нормального приоритета
И если это не чинить, получится странная картина: активность выросла, кода стало больше, задач “в работе” стало больше, а до прода всё едет примерно так же.
Для тимлида тут простой вывод.
Перед тем как радоваться ускорению от AI, стоит посмотреть на flow команды:
1. Сколько задач одновременно в работе?
2. Где задачи чаще всего ждут?
3. Сколько времени занимает ревью?
4. Как часто людей дёргают вне текущей задачи?
5. Становится ли быстрее доставка ценности, а не только написание кода?
AI может быть хорошим усилителем.
Но он усиливает не только сильные стороны.
Он так же хорошо усиливает бардак.
Если в команде есть фокус, понятные приоритеты и нормальный процесс ревью — AI может дать хороший прирост.
Если всего этого нет, он просто добавит скорости туда, где и так не хватало управления.
А у вас AI уже ускорил delivery или пока только написание кода?
👍1
Написал на vc.ru большой пост про своего Telegram-бота для Jira:
https://vc.ru/dev/3010823-telegram-bot-dlya-jira
Изначально идея была простая: мне надоело постоянно открывать Jira ради мелких, но частых действий.
Посмотреть статус задачи.
Понять, что зависло.
Быстро подготовиться к дейли.
Проверить активный спринт.
Получить сводку по команде.
Увидеть, где задачи стоят слишком долго.
Вроде бы всё это можно сделать в Jira.
Но если за день таких переключений десятки, инструмент начинает съедать внимание сам по себе.
Так появился SleepJiraBot.
Это не попытка заменить Jira и не “ещё один таск-трекер в Telegram”. Скорее тонкий слой поверх Jira, который помогает быстрее доставать нужный контекст там, где уже идёт рабочая коммуникация.
В посте рассказал:
— зачем вообще делать бота для Jira;
— какие сценарии он закрывает для тимлида и команды;
— как работают подписки на задачи и проекты;
— зачем нужна /daily-сводка;
— какие отчёты по спринтам и канбану хочется видеть;
— почему автоматизация не чинит плохой процесс, но хорошо подсвечивает, где он болит.
Бот уже можно попробовать: @Sleep_Jira_Bot
Исходники тоже выложил на GitHub.
Буду рад фидбеку, особенно от тех, кто живёт между Jira, Telegram, дейли, ревью и вечным вопросом: “а что у нас сейчас происходит?”
https://vc.ru/dev/3010823-telegram-bot-dlya-jira
Изначально идея была простая: мне надоело постоянно открывать Jira ради мелких, но частых действий.
Посмотреть статус задачи.
Понять, что зависло.
Быстро подготовиться к дейли.
Проверить активный спринт.
Получить сводку по команде.
Увидеть, где задачи стоят слишком долго.
Вроде бы всё это можно сделать в Jira.
Но если за день таких переключений десятки, инструмент начинает съедать внимание сам по себе.
Так появился SleepJiraBot.
Это не попытка заменить Jira и не “ещё один таск-трекер в Telegram”. Скорее тонкий слой поверх Jira, который помогает быстрее доставать нужный контекст там, где уже идёт рабочая коммуникация.
В посте рассказал:
— зачем вообще делать бота для Jira;
— какие сценарии он закрывает для тимлида и команды;
— как работают подписки на задачи и проекты;
— зачем нужна /daily-сводка;
— какие отчёты по спринтам и канбану хочется видеть;
— почему автоматизация не чинит плохой процесс, но хорошо подсвечивает, где он болит.
Бот уже можно попробовать: @Sleep_Jira_Bot
Исходники тоже выложил на GitHub.
Буду рад фидбеку, особенно от тех, кто живёт между Jira, Telegram, дейли, ревью и вечным вопросом: “а что у нас сейчас происходит?”
👍3
AI делает разработчика быстрее.
Но вместе со скоростью он добавляет новую ответственность: управлять тем, что ты просишь у модели, и отвечать за то, что потом попадёт в продукт.
Похоже, в эпоху AI хороший разработчик — это уже не только тот, кто умеет писать код.
Это тот, кто умеет руководить маленьким очень быстрым, очень уверенным и иногда очень ошибающимся помощником.
И, возможно, это главный навык, который командам придётся прокачивать дальше: не просто “уметь пользоваться AI”, а уметь ставить ему задачи, проверять результат и не терять инженерное мышление по дороге.
Потому что AI может написать код за тебя.
Но ответственность за этот код всё равно останется на тебе.
А у вас в команде уже обсуждали правила для AI-кода или пока каждый использует как привык?
Но вместе со скоростью он добавляет новую ответственность: управлять тем, что ты просишь у модели, и отвечать за то, что потом попадёт в продукт.
Похоже, в эпоху AI хороший разработчик — это уже не только тот, кто умеет писать код.
Это тот, кто умеет руководить маленьким очень быстрым, очень уверенным и иногда очень ошибающимся помощником.
И, возможно, это главный навык, который командам придётся прокачивать дальше: не просто “уметь пользоваться AI”, а уметь ставить ему задачи, проверять результат и не терять инженерное мышление по дороге.
Потому что AI может написать код за тебя.
Но ответственность за этот код всё равно останется на тебе.
А у вас в команде уже обсуждали правила для AI-кода или пока каждый использует как привык?
❤3💯1
Команда не должна читать мысли тимлида
Одна из частых ошибок руководителя — держать ожидания у себя в голове.
Как будто команда каким-то магическим образом должна сама понять:
— что для тебя важно;
— как ты относишься к срокам;
— чего ждёшь от 1:1;
— когда нужно эскалировать проблему;
— что для тебя значит ownership;
— где у команды свобода, а где красная линия.
А потом начинается классика жанра.
Тимлид раздражается:
«Ну это же очевидно».
Команда удивляется:
«А откуда мы должны были это знать?»
И все дружно играют в корпоративную версию “угадай мелодию”, только вместо мелодии — невысказанные ожидания менеджера.
В статье How to make your team read your mind Anton Zaides пишет про идею Manager’s ReadMe — документа, в котором руководитель описывает, как с ним работать и чего он ждёт от команды.
Не для того, чтобы повесить это на стену как конституцию маленького офиса.
А чтобы убрать туман.
Что туда можно включить:
— роль тимлида в команде;
— как проходят 1:1;
— ожидания по коммуникации;
— правила доступности в рабочее и нерабочее время;
— отношение к планированию и оценкам;
— что значит владеть фичей;
— как команда должна поднимать проблемы;
— какие решения можно принимать самостоятельно.
Мне нравится в этой идее не сам документ, а принцип.
Если ожидание не проговорено, странно требовать его выполнения.
Да, опытные люди многое считывают по контексту.
Да, культура команды постепенно формируется через действия.
Да, не всё нужно регламентировать до уровня “как правильно дышать в Jira”.
Но есть большая разница между живой культурой и набором скрытых правил, которые человек узнаёт только после ошибки.
Manager’s ReadMe помогает сделать ожидания видимыми.
И заодно заставляет самого тимлида подумать:
— я правда так считаю?
— я сам соблюдаю эти правила?
— команда это знает?
— это помогает работе или просто отражает мои личные заморочки?
Последний пункт особенно неприятный, поэтому обычно самый полезный.
Важно: такой документ не должен звучать как ультиматум.
Скорее как черновик договора:
«Вот как я сейчас вижу нашу работу. Давайте обсудим, где это полезно, где спорно, а где я сам себе придумал красивую управленческую галлюцинацию».
Потому что цель не в том, чтобы команда идеально подстроилась под тимлида.
Цель — чтобы у людей было меньше поводов тратить силы на угадывание правил игры.
А больше — на саму работу.
Статья: https://zaidesanton.substack.com/p/how-to-make-your-team-read-your-mind
Одна из частых ошибок руководителя — держать ожидания у себя в голове.
Как будто команда каким-то магическим образом должна сама понять:
— что для тебя важно;
— как ты относишься к срокам;
— чего ждёшь от 1:1;
— когда нужно эскалировать проблему;
— что для тебя значит ownership;
— где у команды свобода, а где красная линия.
А потом начинается классика жанра.
Тимлид раздражается:
«Ну это же очевидно».
Команда удивляется:
«А откуда мы должны были это знать?»
И все дружно играют в корпоративную версию “угадай мелодию”, только вместо мелодии — невысказанные ожидания менеджера.
В статье How to make your team read your mind Anton Zaides пишет про идею Manager’s ReadMe — документа, в котором руководитель описывает, как с ним работать и чего он ждёт от команды.
Не для того, чтобы повесить это на стену как конституцию маленького офиса.
А чтобы убрать туман.
Что туда можно включить:
— роль тимлида в команде;
— как проходят 1:1;
— ожидания по коммуникации;
— правила доступности в рабочее и нерабочее время;
— отношение к планированию и оценкам;
— что значит владеть фичей;
— как команда должна поднимать проблемы;
— какие решения можно принимать самостоятельно.
Мне нравится в этой идее не сам документ, а принцип.
Если ожидание не проговорено, странно требовать его выполнения.
Да, опытные люди многое считывают по контексту.
Да, культура команды постепенно формируется через действия.
Да, не всё нужно регламентировать до уровня “как правильно дышать в Jira”.
Но есть большая разница между живой культурой и набором скрытых правил, которые человек узнаёт только после ошибки.
Manager’s ReadMe помогает сделать ожидания видимыми.
И заодно заставляет самого тимлида подумать:
— я правда так считаю?
— я сам соблюдаю эти правила?
— команда это знает?
— это помогает работе или просто отражает мои личные заморочки?
Последний пункт особенно неприятный, поэтому обычно самый полезный.
Важно: такой документ не должен звучать как ультиматум.
Скорее как черновик договора:
«Вот как я сейчас вижу нашу работу. Давайте обсудим, где это полезно, где спорно, а где я сам себе придумал красивую управленческую галлюцинацию».
Потому что цель не в том, чтобы команда идеально подстроилась под тимлида.
Цель — чтобы у людей было меньше поводов тратить силы на угадывание правил игры.
А больше — на саму работу.
Статья: https://zaidesanton.substack.com/p/how-to-make-your-team-read-your-mind
❤3