AI-команда без project manager: план первого месяца

Почему первый месяц кажется хаотичным

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

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

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

Беспорядок растёт, когда задачи меняются, пока кто-то ещё работает над старой версией. Разработчик может сделать то, что было в ticket в 9:00, а founder в 11:00 уже переписывает scope в чате. Оба думают, что двигаются быстро. На деле они просто создают переделку.

Заблокированная работа часто исчезает в личных сообщениях. Кто-то пишет: «Мне нужен текст, чтобы закончить это», или «API key всё ещё не проходит», и эта заметка остаётся в приватной переписке. Остальные не видят блокер, никто не подхватывает задачу, а потом команда спрашивает о статусе, потому что работа выглядит застопорившейся без очевидной причины.

Небольшие команды чувствуют это особенно остро, потому что каждый человек закрывает больше зон. Один пропущенный ответ может одновременно остановить дизайн, код, QA и заметки к запуску.

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

Запишите правила scope, которым люди смогут следовать

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

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

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

Пишите список поставки как результаты, а не как расплывчатые действия. «Улучшить onboarding» — слишком размыто. «Выпустить новый signup flow с email verification» — понятно. Одна точная фраза может сэкономить часы переписки.

Список вне scope не менее важен. Он не даёт команде незаметно добавлять «маленькие» дополнения, которые потом превращаются в неделю работы. Добавляйте туда соблазнительные идеи, edge cases и задачи по cleanup, если они реальны, но не нужны в этом месяце. Когда кто-то позже предложит такую идею, можно просто сослаться на заметку и двигаться дальше.

Жёстко определите, кто может менять задачу. Если scope может переписать каждый, никто не понимает, что является реальностью. В небольшой команде один человек должен отвечать за product scope. Tech lead может делить или оценивать работу, но не должен в одиночку добавлять новые цели. Остальные могут предлагать изменения, но не утверждать их окончательно.

Храните все заметки по scope в одном общем месте. Один документ, одна доска, один источник правды. Не распыляйте scope между чатами, заметками с встреч и названиями задач. Именно так снова начинается погоня за статусами.

Небольшой пример делает правило наглядным. Если в месячном плане команда должна выпустить исправление для billing, более лёгкий onboarding flow и базовые ответы AI для поддержки, то редизайн dashboard остаётся вне плана, пока владелец scope не одобрит замену. Одно это правило делает месяц спокойнее.

Задайте окна ревью и придерживайтесь их

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

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

Простого расписания достаточно: 10:00 — быстрые проверки, 14:00 — обычная работа, 17:00 — только срочные исправления.

Держите окна короткими. Обычно хватает 20–30 минут, если люди хорошо подготовились, а автоматические проверки уже отработали. Такой порядок особенно хорошо работает для небольших команд: сначала машины ловят очевидные проблемы, потом люди тратят время на решение, где нужен их взгляд.

Не каждое изменение должно идти по одному и тому же пути. Исправление текста, небольшая правка интерфейса или обновление сообщения в логах может попасть в быстрое окно. А изменение, которое затрагивает payments, auth, структуру базы данных или prompts, влияющие на ответ клиенту, должно идти через отдельный risk review. Такой обзор может потребовать больше одного человека и более широкого временного окна.

Ревьюеры должны оставлять прямые комментарии, а не расплывчатые сигналы. «Переименуйте это поле, чтобы оно совпадало с API» — полезно. «Нужно доработать» — нет. Ясные комментарии экономят целый цикл переписки, а это часто 15–20 минут на небольшой задаче и гораздо больше на крупной.

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

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

Держите заблокированную работу в одной очереди

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

Используйте одну общую доску или список для каждого blocked item. Не две доски, не личную заметку, не чат, который исчезает к обеду. Если работа не может двигаться, она попадает в эту очередь.

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

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

Этого достаточно для быстрой сортировки. «Ждём ревью» — слишком расплывчато. «Текст для checkout ждёт одобрения legal, Anna спросила в 10:40, следующее действие — ответ legal к 15:00» даёт команде понятный ориентир.

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

Представьте небольшую продуктовую команду. Инженер не может закончить onboarding flow, потому что после правки prompt изменился output AI summary. Задача попадает в blocked queue, инженер остаётся владельцем, а следующее действие — синхронизироваться с человеком, который менял prompt. Если никто не решит проблему к ежедневному разбору блокеров, команда может решить, откатить изменение, поправить schema или приостановить релиз.

Одна очередь не убирает задержки. Она делает их видимыми заранее, пока исправление ещё небольшое.

Внедряйте это в течение четырёх недель

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

Недели 1 и 2

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

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

Вторая неделя — для письменных правил scope и фиксированных окон ревью. Сделайте правила настолько короткими, чтобы люди действительно их читали. Scope-нота должна отвечать на пять простых вопросов: какую проблему мы решаем? Что вне scope на этой неделе? Кто может утвердить изменение? Когда мы это проверяем? Что считается готовым?

Назначьте время ревью в соответствии с тем, как команда реально работает. Если code review уже обычно происходит в 12:00 и 16:00, оставьте эти времена на полную неделю, прежде чем что-то менять. Если AI-черновики перед выпуском должны проходить через человека, сделайте это правило явным и повторяемым.

Недели 3 и 4

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

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

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

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

Простой пример на небольшой продуктовой команде

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

Они исправили это не большим количеством встреч, а более ясным письмом.

Maya начала использовать AI, чтобы делать первый черновик задач, баг-заметок и коротких спецификаций. Она записывала голосовую заметку или черновой абзац, а в ответ получался draft с правилами приёмки, открытыми вопросами и базовым планом тестирования. Команда никогда не считала этот черновик финальным. Человек дорабатывал его, убирал размытые места и добавлял то, что AI часто пропускает: чего не нужно делать.

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

Более крупное изменение пришло вместе с окнами ревью. Вместо случайных пингов на одобрение весь день команда договорилась о двух окнах ревью: поздним утром и ближе к вечеру. Если кто-то заканчивал код в 13:00, он отправлял его в следующую волну ревью, если только production не горел. Первые три дня правило казалось жёстким. Потом все расслабились. Меньше прерываний означало, что люди успевали завершать реальную работу до переключения контекста.

Они также держали заблокированную работу в одном месте. Если кто-то застревал больше чем на 20 минут, задача попадала на простую blocker board с одной строкой: что заблокировано, кто может разблокировать и какое следующее действие. Никаких длинных веток переписки. Никакой detective work.

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

Ошибки, из-за которых погоня за статусами возвращается

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

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

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

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

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

Следите за несколькими тревожными признаками. Задачи снова открываются после отметки done без письменной причины. Ревьюеры оставляют комментарии в случайное время каждый день. Заблокированные пункты остаются вперемешку с активной работой. Люди спрашивают: «Что мы решили на том звонке?» Члены команды пишут друг другу в личку за статусом вместо того, чтобы посмотреть одну доску.

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

Быстрая еженедельная проверка

Команда может быстро уйти вразнос, если никто не отвечает за статус постоянно. Еженедельная проверка на 10–15 минут помогает держать работу ясной без ещё одной тяжёлой встречи. Начните письменно. Если после этого что-то всё ещё неясно, поговорите пять минут и закройте вопрос.

Используйте каждую неделю одни и те же четыре проверки. Попросите каждого человека написать текущий scope в одной-двух строках. Если ответы различаются, scope слишком размытый. Подтвердите следующее окно ревью для каждой живой задачи, чтобы ревьюеры знали день и правило того, что именно они проверяют. Посмотрите на заблокированную работу и убедитесь, что у каждого блокера есть один владелец, а не «команда». Уберите и старые AI-результаты. Если draft, test или prototype больше не соответствуют плану, закройте или удалите его.

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

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

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

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

Что делать дальше вашей команде

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

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

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

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

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

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

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

Если команда всё равно скатывается обратно к ежедневным check-ins и погоне за статусами, может помочь внешний специалист. Oleg Sotnikov на oleg.is работает со стартапами как Fractional CTO и advisor, и именно такой лёгкий operating system для команд с сильной зависимостью от AI — это тот тип помощи, который он помогает выстроить без лишнего управленческого слоя.