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

Почему основателям нужен настоящий тест

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

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

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

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

Настоящий тест отвечает на простые вопросы:

• Может ли этот человек превратить сырую идею в внятный план?
• Двигается ли он вперед без лишней драмы?
• Объясняет ли он компромиссы простым языком?
• Ведет ли он себя как человек, который чувствует ответственность, когда деталей не хватает?

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

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

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

Что именно должен проверять пробный период

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

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

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

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

Сигналы, которые важнее блеска

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

Обращайте внимание на такое поведение:

• Он просит контекст, прежде чем писать код.
• Он сокращает объем, когда срок поджимает.
• Он объясняет компромиссы простым языком.
• Он делает что-то рабочее, а потом честно говорит, чего еще не хватает.

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

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

Выберите правильный двухнедельный кусок продукта

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

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

Хороший кусок обычно включает:

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

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

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

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

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

Как написать короткий бриф на пробный период

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

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

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

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

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

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

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

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

Как проводить эти две недели

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

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

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

• День 1. Согласуйте проблему, пользователя и точный объем. Запишите, что входит в задачу, а что нет. Если цель нельзя объяснить несколькими простыми предложениями, кусок все еще слишком размыт.
• Дни 2–3. Сначала попросите варианты, а не код. Кандидат должен оценить ограничения, назвать риски и выбрать план. Вам нужен понятный путь, примерные этапы и короткая заметка о том, что он намеренно игнорирует.
• Дни 4–9. Дайте человеку строить. Проводите один короткий чек-ин каждый день, примерно по 15–20 минут. Используйте его, чтобы разблокировать решения, смотреть прогресс и корректировать объем, если реальность изменилась.
• Дни 10–12. Переходите от черновой разработки к доработке. Исправьте шероховатости, которые влияют на демо, добавьте базовые тесты, улучшите названия и зафиксируйте компромиссы. Хорошие разработчики понимают, что оставить грубым, а что стоит подтянуть перед передачей.
• Финальный день. Закончите рабочим демо, коротким обзором кода или настройки и честным разбором с обеих сторон. Человек должен объяснить, что он сделал, что пропустил, что сломалось и что он бы сделал дальше за еще одну неделю.

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

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

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

Что смотреть во время пробного периода

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

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

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

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

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

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

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

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

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

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

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

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

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

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

До конца двух недель кандидат делится коротким апдейтом с основателем:

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

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

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

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

Ошибки, которые портят сигнал

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

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

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

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

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

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

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

Быстрые проверки и следующие шаги

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

Используйте короткую оценочную таблицу и честно ответьте на вопросы:

• Стал ли продукт понятнее? Смотрите, стало ли меньше расплывчатых вопросов, проще ли стал пользовательский путь и точнее ли стал объем, чем в первый день.
• Стало ли меньше необходимости постоянно подсказывать основателю? Сильные кандидаты задают точные вопросы, сами разблокируют себя и принимают разумные решения, не ожидая вас весь день.
• Зафиксировал ли человек решения и незакрытые вопросы? Вам нужны заметки о компромиссах, рисках, допущениях и о том, что еще требует доработки. Если все это только у него в голове, следующая итерация быстро станет беспорядочной.
• Доверили бы вы этому человеку более сложную задачу? Подумайте о смене биллинга, неприятном баге в продакшене или плохо определенной функции с реальным влиянием на пользователей.
• Вел ли он себя как человек, который чувствует ответственность? Он должен думать о результате, возражать, когда объем слабый, и при этом выполнять то, о чем договорился.

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

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

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