AI-инструменты не ускоряют работу? Сначала проверьте процесс

Почему больше мест для AI не меняет день

Покупка дополнительных лицензий AI кажется прогрессом. Иногда так и есть. Но чаще всего команды теряют время не в окне с промптом. Они теряют его в ожидании.

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

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

Ещё один тормоз — простое копирование между системами, которые не связаны друг с другом. Кто-то просит помощи в чате, превращает ответ в документ, вставляет часть в задачу, а потом отправляет обновление по почте. Пятнадцать минут тут и там не звучат драматично, но за неделю это съедает часы и ломает концентрацию.

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

Картина знакомая. Один человек просит AI сделать черновик. Другой переписывает его, потому что бриф был слишком слабым. Команда ждёт согласования. Кто-то копирует результат ещё в две-три системы. Работа сдвигается только после встречи или напоминания. Это не проблема AI. Это проблема процесса, в котором AI стоит посередине.

Особенно хорошо это видно в продуктовых командах. Product manager просит AI написать спецификацию, но engineering всё ещё ждёт решения по объёму работ. QA всё ещё ждёт правила приёмки. Support по-прежнему не знает, что изменилось, пока не наступит день релиза. Черновик появился быстрее, а день — нет.

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

Где работа замедляется ещё до того, как AI может помочь

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

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

Цепочки согласований создают ещё одну тихую задержку. Команды часто спрашивают одного и того же решения у трёх человек, потому что никто не верит, что одного согласования хватит. Product хочет «да» от руководства. Engineering хочет «да» от product. Compliance или finance подключаются слишком поздно. Каждый ждёт, просит контекст и отправляет задачу обратно. Эти задержки на согласованиях могут съедать целые полдня.

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

Слабое определение готовности порождает ещё больше переделок, чем готовы признать многие команды. Инженер считает, что задача завершена, потому что всё работает. QA считает, что она не закончена, потому что нет сценариев ошибок. Product считает, что она не завершена, потому что никто не посмотрел текст. Задача открывается снова, и медленные рабочие процессы превращаются в бесконечные петли.

Вот почему проблемы внедрения AI кажутся такими запутанными. Инструмент работает. Команда всё равно ждёт. Прежде чем покупать ещё больше мест, закройте точки, где люди останавливаются, уточняют и отправляют работу обратно. Один владелец, один путь согласования, полные заметки о передаче и простая точка завершения обычно дают больше, чем любая дополнительная лицензия.

Как найти медленные участки

Начните с одной реальной задачи, а не с теории. Возьмите что-то обычное: исправление бага, коммерческое предложение или обновление продукта. Потом проследите путь от первого запроса до момента, когда задача выходит в свет.

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

Запишите все шаги по порядку. Без усложнений. Кто получает запрос первым? Куда его кладут? Кто проверяет? Где он зависает? Потом отметьте каждую паузу, каждое согласование и каждую переписку туда-сюда. Будьте конкретны. «Ждём проверки менеджера» — полезно. «Задержалось» — нет.

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

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

Затем разделите шаги на две группы. Одни требуют оценки: например, решить объём, оценить риск или согласовать чувствительное сообщение клиенту. Другие повторяются: написать заметки к релизу, сделать выжимку встречи, подготовить тест-кейсы или отформатировать статус-обновление. AI отлично помогает именно с повторяющейся работой. А вот с размытым владением и медленными согласованиями он делает очень мало.

Продуктовая команда может выяснить, что написание обновления функции занимает 30 минут, а ожидание комментариев в двух чатах добавляет ещё полтора дня. В таком случае проблема не в скорости письма. Проблема в пути проверки.

Сначала измените одну задержку. Уберите одно согласование, объедините две передачи или выберите одно место для обратной связи. Потом снова измерьте цикл на следующей неделе. Если задача стала двигаться вместо четырёх дней за два, вы нашли реальный блокер. Если нет — проверьте следующую задержку, а не покупайте ещё лицензии.

Простой пример из продуктовой команды

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

Днём product пишет первую заметку. AI превращает сообщение основателя в более чистую спецификацию и делает черновик заметки к релизу. Это быстро. Замедление начинается сразу после этого.

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

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

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

Support слышит, что обновление биллинга может выйти на этой неделе, но финальный сценарий никто не подтвердил. Черновик заметки к релизу уже есть, снова благодаря AI, но support всё ещё не может им пользоваться. Им нужны точное правило, влияние на клиентов и дата, которую можно сообщить пользователям.

Потерянное время было не в написании. Product не зафиксировал правила биллинга до того, как начался дизайн. Design и engineering в разное время нашли открытые вопросы. QA получил сборку до того, как логика устаканилась. Support получил слова, а не подтверждённые факты.

К пятнице коду может не хватать всего ещё одного часа работы. Но команда уже потратила четыре дня, ходя по кругу вокруг одного небольшого изменения. Вот как выглядят узкие места AI-процессов в реальности. Программа может за минуты писать заметки, тест-кейсы и клиентский текст. Но она не может убрать ожидание между командами, неясную ответственность и медленные решения. Более удачный workflow поставил бы одного владельца на изменение, подтвердил правила биллинга в понедельник и дал бы QA и support один финальный источник правды.

Какие изменения в процессе важнее всего

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

Один из частых и простых исправлений: дайте одному человеку право принимать рутинные решения. Не каждый выбор требует встречи. Если product manager может согласовать небольшую правку текста, а технический лидер — выбрать между двумя малорисковыми вариантами, работа движется дальше. Команды тормозят, когда пять человек могут заблокировать мелкое решение, и никто не чувствует себя обязанным принять его.

Следующее исправление менее эффектное, но оно реально экономит время. Используйте один формат intake для запросов. Если работа приходит через чат, почту, голосовые заметки и случайные документы, люди половину дня тратят на перевод. Лучше работает короткий шаблон запроса. Он может быть совсем простым: цель, владелец, срок и ограничения. Когда команда каждый раз использует один и тот же формат, AI может суммировать, сортировать и готовить следующий шаг, не гадая, что именно имелось в виду.

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

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

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

Именно отсюда часто начинается помощь со стороны. Хороший fractional CTO обычно не начинает с покупки ещё одного софта. Первая задача — разобрать путь, назначить владельцев, ужать шаблон и каждую неделю смотреть на время ожидания, пока оно не начнёт падать.

Ошибки, из-за которых команды продолжают тормозить

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

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

Вторая ошибка — заставлять всех членов команды использовать AI одинаково. У support-лида, дизайнера и backend-инженера разная работа, поэтому одно правило на всех обычно превращается в поверхностное использование. Хороший процесс даёт каждой роли понятный сценарий. Sales может делать черновики follow-up. Engineering — писать тесты или кратко суммировать логи. Product — превращать заметки со встречи в первую версию спецификации.

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

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

Ещё одна ошибка — измерять объём, а не завершённую работу. Десять сгенерированных черновиков ничего не значат, если клиент всё равно ждёт, баг всё равно не ушёл или релиз всё равно сдвинулся. Смотрите на цикл, число возвратов на доработку, скорость релиза и время ответа. Если текстов стало больше, а готовая работа не двигается быстрее, значит, узкое место всё ещё есть.

Быстрая проверка перед покупкой новых лицензий

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

Начните с одного вопроса: где работа ждала? AI быстро пишет, быстро суммирует и быстро делает черновики. Но он ничего не делает, пока тикет лежит в чужой очереди, пока менеджер ждёт недостающий контекст или пока два человека думают, что следующий шаг делает другой.

Проверьте один важный workflow по этому списку:

• У каждого шага есть один названный владелец.
• Запросы приходят с базовой информацией, которая нужна для работы: цель, срок, файлы, примеры и ограничения.
• Команда использует общие промпты, шаблоны и правила проверки вместо того, чтобы каждый раз собирать их заново.
• Время ожидания видно, особенно если пауза длится больше одного дня.
• Последнее внедрение AI изменило цикл работы, а не только количество черновиков.

Если хотя бы на один пункт вы не можете уверенно ответить «да», сначала исправьте это, а уже потом покупайте новые инструменты.

Чаще всего проваливается именно ответственность. Команда может сказать, что задача «у engineering» или «у ops», но обычно это означает, что никто не чувствует себя ответственным за то, чтобы продвинуть её сегодня. На каждую передачу должен быть один владелец, даже если в работе участвует несколько человек.

Затем идёт качество входных данных. Если запросы приходят слишком короткими, люди половину времени тратят на поиски недостающих фактов. AI может превратить сырой набросок в черновик, но он не угадает политику, историю клиента или настоящий срок. Более удачная форма intake часто экономит больше времени, чем очередное обновление модели.

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

Потом посмотрите на время. Если никто не может указать стадии, где работа стоит больше одного дня, медленный участок остаётся невидимым. Часто достаточно простой доски со статусами «начато», «ждём» и «готово».

Следующие шаги для более маленького и быстрого workflow

Если AI-инструменты не ускоряют работу, следующий шаг обычно меньше, чем люди ожидают. Не переделывайте всё сразу. Возьмите одну повторяющуюся задачу, которая случается каждую неделю, и нарисуйте реальный процесс на одной странице.

Выберите что-то конкретное: выпуск небольшой функции, превращение звонка с клиентом в предложение или закрытие обращения в support. Запишите каждый шаг, каждого человека, каждый инструмент и каждое ожидание. Включайте паузы, которые люди обычно игнорируют, потому что именно они часто съедают больше времени, чем сама работа.

Большинство медленных команд находят один и тот же шаблон. Старое согласование всё ещё существует, потому что никто его не убрал. Передача существует только потому, что раньше две команды работали отдельно. Люди обновляют один и тот же статус в двух инструментах, потому что никто не договорился об одном источнике правды. AI может ускорить шаг, но он не отменяет правила, которым ваша команда всё ещё следует.

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

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

Эффект видно быстро. Команда может использовать AI, чтобы делать черновики заметок к релизу за минуты, но релиз всё равно уезжает на два дня, потому что product правит текст, marketing переписывает его, а support переписывает ещё раз. Более простой поток выглядит так: один владелец создаёт исходную версию, AI адаптирует её под каждую аудиторию, и один финальный проверяющий ставит подпись.

Наблюдайте за задачей две недели. Если команда экономит хотя бы 15–20 минут каждый раз, оставьте изменение и переходите к следующей повторяющейся задаче. Маленькие сокращения складываются. Три более чистых процесса обычно полезнее, чем десять новых мест для AI.

Некоторые проблемы одновременно затрагивают product, engineering и operations. Их сложнее чинить изнутри, потому что каждая команда видит только свой кусок. В таких случаях Oleg Sotnikov на oleg.is работает как fractional CTO и стартап-советник для небольших команд, которым нужна практическая помощь с AI-процессами, изменениями в техническом процессе и бережливыми операционными правилами. Иногда внешний взгляд — самый быстрый способ увидеть, где работа на самом деле буксует.