Техническое наставничество для основателей: как читать риски стартапа

Почему работу над software сложно оценить

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

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

Именно здесь помогает техническое наставничество. Его цель — не научить вас программировать. Его цель — помочь понять, снижает ли команда риск или просто создает видимость активности.

Расплывчатые обновления только ухудшают ситуацию. Фразы вроде «мы почти закончили», «улучшаем архитектуру» или «наткнулись на edge cases» могут означать что угодно. Иногда это обычный прогресс. Иногда — что команда нашла более глубокую проблему, не знает, сколько она займет, и надеется выиграть время мягкими формулировками.

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

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

Вот почему многие проекты очень долго выглядят как «на 80 процентов готовы». Простые 80 процентов часто состоят из внешней части.

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

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

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

Как выглядит риск в стартап-проекте

Большинство проблем стартапа укладываются в три простые группы.

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

Риск delivery — это когда команда не успевает выпустить продукт вовремя или выпускает его с большим количеством пробелов. План на бумаге выглядит нормально, но работа постоянно съезжает понемногу.

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

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

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

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

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

Именно поэтому опытный технический совет иногда звучит почти скучно. Замедлите обещание. Уточните объем. Назовите допущения. Потом стройте. Эта короткая пауза может сэкономить месяцы переделки.

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

Как оценивать риск до того, как вы утвердите работу

Утверждать software-проект становится проще, когда вы перестаете спрашивать: «Смогут ли они это построить?» и начинаете спрашивать: «Что может пойти не так, прежде чем это начнет приносить пользу бизнесу?» Этот сдвиг важнее любого списка функций.

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

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

Основатель в логистике может услышать: «Мы можем собрать дашборд диспетчеризации за три недели». Звучит нормально, пока вы не зададите несколько базовых вопросов. Уже ли водители отправляют чистые данные о местоположении? Кто утверждает изменения маршрута? Сломается ли старая система, если обе инструментации будут работать одновременно? Эти неизвестные могут ударить по срокам сильнее, чем сам дашборд.

Спросите, что сломается первым. Потом спросите, как вы это заметите.

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

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

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

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

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

Вопросы, которые вскрывают скрытые проблемы

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

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

Потом спросите, где план зависит от внешних инструментов или поставщиков. Многие задержки возникают из-за вещей, которыми команда не управляет полностью: платежные провайдеры, проверки в app store, сторонние API, импорт данных, системы входа, ограничения облака или плагин, на который все надеются. Сам по себе dependency — не проблема. Проблема начинается, когда никто не проверил ограничения, неудобные места и запасной план.

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

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

Еще один вопрос часто вскрывает настоящий риск: «Что изменит этот план на следующей неделе?» Сильный ответ может упомянуть обратную связь от пользователей, проваленные интеграционные тесты или лимит поставщика. Слабый ответ звучит так: «Ничего, мы идем по плану». План должен меняться, когда меняются факты.

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

Простой пример из бизнеса без software

Представьте локальную клининговую компанию с 12 сотрудниками. Основателю нужен booking app, чтобы клиенты могли выбрать время, внести депозит и получать SMS-напоминания. Разработчик говорит, что первая версия займет шесть недель. Звучит разумно.

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

Следующая проблема менее очевидна. Никто не владеет правилами сервиса. Основатель думает, что их объяснит офис-менеджер. Офис-менеджер предполагает, что разработчик спросит, если что-то важно. Разработчик делает фиксированные двухчасовые слоты бронирования. Через неделю команда вспоминает, что между заказами уборщикам нужно время на дорогу, для некоторых услуг нужны двое сотрудников, а в некоторых индексах минимальная сумма заказа. Теперь booking flow приходится переделывать.

Эта переделка стоит времени, денег и доверия.

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

Достаточно нескольких еженедельных вопросов:

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

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

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

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

Ошибки, которые делают основатели, когда доверяют слишком сильно

Доверие помогает стартапу двигаться. Слепое доверие делает небольшие проблемы дорогими.

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

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

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

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

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

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

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

Короткий чеклист для еженедельных проверок

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

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

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

Ответы должны быть конкретными. «Мы улучшили backend» — слабый ответ. «Мы закончили вход, исправили две платежные ошибки и теперь ждем продуктовый текст перед релизом» — это ясно. Хорошие команды могут говорить просто, не разговаривая с вами сверху вниз.

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

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

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

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

Что делать дальше, если риск все еще неясен

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

Сделайте эту страницу короткой. Укажите риск, что может случиться, как скоро это может навредить и какие доказательства у вас есть. «Приложение может работать медленно» — слишком расплывчато. «Checkout занимает 9 секунд на мобильном, и 18 процентов пользователей уходят до оплаты» — с этим уже можно работать.

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

Разделите, какая помощь вам нужна

Когда вы назвали самый большой риск, решите, какой тип помощи ему подходит.

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

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

Вот несколько признаков, что стоит привлечь внешнего технического лидера или fractional CTO:

• Команда ходит по кругу и никогда не дает прямого ответа.
• Каждый дедлайн сдвигается, но никто не меняет план.
• Один senior-разработчик — единственный, кто понимает систему.
• Баги возвращаются после «исправлений».
• Вы слышите много деталей, но все равно не понимаете, что именно заблокировано.

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

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

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