Когда советов стартапу уже недостаточно: признаки, что пора действовать

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

Стартап может выглядеть занятым и при этом оставаться на месте.

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

Именно в этот момент советов часто перестаёт хватать. Дело не в плохих советах. Дело в том, что после звонка никто не берёт на себя работу.

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

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

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

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

Дополнительные советы редко это чинят. Чёткая ответственность — да.

Переворачивающиеся решения — ранний сигнал тревоги

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

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

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

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

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

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

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

Узкое место у фаундера видно по календарю

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

Задержка сначала выглядит безобидно. Дизайнеру нужно «да» по объёму работы. Инженеру нужно выбрать между двумя подходами. Рекрутеру нужно утвердить оффер. На каждый ответ уходит десять минут, но люди ждут два дня. Эта пауза замедляет всё вокруг.

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

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

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

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

Если календарь фаундера становится легче, а команда выпускает быстрее, вы нашли настоящую проблему.

Повторяющиеся срывы сроков говорят сами за себя

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

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

Ещё один частый сигнал — объём работы меняется уже после того, как команда начала. Кто-то добавляет ещё одну деталь на третий день, потом ещё одно изменение появляется после первого демо. Это создаёт сразу две проблемы: команда теряет фокус, и никто не может сказать, был ли изначальный план вообще реалистичным. Если такое происходит часто, дело не в планировании. Дело в ответственности.

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

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

Если ответы не совпадают, задача уже опоздала ещё до того, как кто-то начал её делать.

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

Как проверить, нужна ли вам прямая ответственность

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

Проведите простой 30-дневный аудит. Используйте реальные встречи, тикеты и дедлайны, а не память. Если люди спорят о том, что именно произошло, аудит уже полезен.

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

Ищите паттерны, а не отдельные промахи. Если одна и та же причина всплывает три или четыре раза, советов уже недостаточно.

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

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

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

Простой пример стартапа

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

Но начинается неделя, и фаундер становится этапом согласования почти всего: правок текста на сайте, обновлений цен, приоритетов в бэклоге и времени релиза.

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

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

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

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

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

Через несколько недель у стартапа всё те же шесть человек, тот же продукт и примерно тот же объём работы. Но изменилась ответственность. Еженедельные перезапуски прекращаются, а delivery становится намного предсказуемее.

Ошибки, которые фаундеры совершают на этом этапе

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

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

Распространённая ошибка — пытаться убрать путаницу более длинными встречами. Календарь забивается, фаундер оказывается втянут в каждое решение, а узкие места расползаются по продукту, найму и delivery. Люди уходят со встреч с заметками, а не с одним понятным ответственным.

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

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

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

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

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

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

Короткий чек-лист перед тем, как действовать

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

Начните с ответственности. Спросите, кто отвечает за продуктовые решения, техническое направление и delivery в этом месяце. Если ответ меняется от встречи к встрече или превращается в «все», значит, у вас есть пробел.

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

Дальше разберите последние три промаха. Запишите, что именно сдвинулось, почему это случилось и кто снял блокер. «Это заняло больше времени, чем ожидали» обычно не является настоящей причиной. Медленные решения, неясный объём работы и слабое доведение до конца наносят куда больше вреда.

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

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

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

Что делать дальше

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

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

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

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

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

Если проблема находится на стыке продукта и разработки, привлеките человека, который может отвечать за исполнение, а не только комментировать его. Oleg Sotnikov на oleg.is работает как CTO на частичной занятости и консультант для стартапов, и именно в таких ситуациях практическая техническая ответственность может помочь.

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