Чек-лист наставничества для технического фаундера в акселераторе

Почему наставничество уходит в сторону

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

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

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

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

Вот тут и нужен журнал решений стартапа. Без него старые темы снова и снова возвращаются под видом новых. Ментор говорит: «Мы уже это обсуждали», — а фаундер искренне чувствует, что это не так.

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

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

Что должен покрывать чек-лист

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

В нем должно быть четыре пункта:

• один ритм встреч для каждой команды
• одно место для хранения решений и открытых вопросов
• понятные правила эскалации для фаундера, если нужна дополнительная помощь
• один ответственный, который следит, чтобы чек-лист оставался актуальным

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

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

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

За чек-лист тоже должен кто-то отвечать. В большинстве программ это program lead или оператор, а не фаундер. Если владельца нет, через две встречи он уже устаревает.

Настройте ритм, который люди выдержат

Ритм наставничества работает только тогда, когда фаундеры могут соблюдать его даже в суматошную неделю. Назначьте один еженедельный звонок и держите его в один и тот же день и время. Вторник в 10:00 лучше, чем «когда-нибудь на следующей неделе», потому что никто не тратит силы на бесконечные перестановки в календаре.

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

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

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

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

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

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

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

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

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

Ведите журнал решений

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

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

Записывайте каждый пункт коротко. Пишите решение одним предложением, а не пересказом дискуссии. «Запускаем платный пилот с ручным онбордингом для первых 10 клиентов» — намного лучше, чем «обсудили варианты онбординга и следующие шаги».

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

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

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

Decision: Delay mobile app work until after 20 paid users.
Made by: Founder, with mentor agreement.
Why: Desktop solves the current sales process and the team has one engineer.
Risk if wrong: Prospects who need mobile may stall or leave.
Review date: 15 May.
Open questions: How many lost deals ask for mobile? Can a mobile web flow cover the gap?

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

Заранее пропишите правила эскалации

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

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

У пропущенных дедлайнов тоже должен быть триггер. Не ждите, пока картина станет драматичной. Если один и тот же результат срывается дважды или команда не выполняет две недельные цели за месяц, выводите это из обычного наставничества и переводите в режим разборa. Кто-то должен сократить объем, переопределить владельцев и проверить, был ли план реалистичен с самого начала.

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

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

Для каждого триггера сразу пропишите первый ответ простым языком. Укажите, кто отвечает за реакцию, кто подключается к разговору, что ставится на паузу или сокращается и когда команда снова проверяет прогресс. Затем добавляйте каждую эскалацию в журнал решений стартапа. Так правило не превращается в расплывчатое предупреждение, а повторяющиеся проблемы становятся заметны сразу.

Соберите чек-лист за один день

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

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

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

Если можете, уместите все на одну страницу. Один экран еще лучше.

Проверьте, прежде чем полировать

Попробуйте чек-лист на одном фаундере в течение двух недель. Смотрите, что тормозит звонок. Если ментор спрашивает: «Куда это записать?» или фаундер каждый раз отвечает на одно и то же в двух местах, значит, с формой что-то не так.

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

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

Простой сценарий с фаундером

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

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

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

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

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

Если команде нужен именно такой прямой пересмотр, Oleg Sotnikov делает эту работу через oleg.is как Fractional CTO и startup advisor. Лучше всего это подходит, когда проблема конкретная и операционная: архитектура, процесс поставки, инфраструктура или превращение плана по ИИ в то, что команда действительно может выпустить.

Ошибки, которые ломают процесс

Чек-лист наставничества для технического фаундера перестает работать, если начинает тормозить. Первая ошибка — слишком много бумажной работы до первого звонка. Если до появления доверия фаундерам нужно заполнять длинные формы, scorecard'ы и статусные шаблоны, многие либо пробегут их наспех, либо пропустят самое полезное.

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

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

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

Обновления без владельца — еще одна тихая проблема. Ментор думает, что черновик пришлет фаундер. Фаундер думает, что это сделает оператор. Оператор предполагает, что это уже у accelerator lead. Проходит неделя, потом вторая.

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

Быстрые проверки до и после каждой встречи

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

До звонка проверьте три вещи:

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

Первая проверка важнее, чем кажется. Когда фаундер пропускает обновление, обычно есть причина: команда завалена работой, фаундер застрял или кто-то избегает сложной темы. Позднее обновление — это не шум администрирования. Это сигнал.

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

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

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

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

Что делать акселератору дальше

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

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

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

Когда этот разрыв становится очевидным, подключайте более глубокую поддержку под одну узкую проблему. Короткая рабочая сессия часто помогает заново настроить архитектурные решения, навести порядок в ответственности за поставку, оценить инфраструктурные риски или проверить план по ИИ до того, как он дойдет до production. Именно такую работу Oleg Sotnikov делает через oleg.is, и это лучше всего подходит, когда стартапу нужна практическая помощь уровня CTO без превращения акселератора в штатного оператора.

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