Что произойдёт с продуктом без основателя

«Если основатель на время пропадёт со связи, что станет с продуктом и моими деньгами?» Я считаю этот вопрос частью разговора о вложении. Приложение может открываться, платежи проходить, а работа уже остановиться: покупатель ждёт ответа, подрядчик — согласования, исправление — решения о выпуске. Инвестор замечает последствия позже, когда компания пропустила срок или потратила деньги на ожидание.

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

Сначала я смотрю, какая работа остановится

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

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

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

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

Доступ, полномочия и умение отвечают за разное

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

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

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

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

Вместе с задачами приходится передавать причины решений

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

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

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

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

Органический рост тоже состоит из чьей-то работы

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

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

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

Где работа остановится при пробной передаче до раунда

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

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

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

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

Короткая пауза может оставить длинную очередь

Дальше условный пример, не показатели Diaverse. В поддержку небольшого продукта приходит 18 обращений за рабочий день, а в очереди уже лежит 12. Основатель на 4 рабочих дня становится недоступен, и без него обработка полностью останавливается. Предположим, все обращения остаются в очереди, а после возвращения ежедневно удаётся закрывать 24. Сложность обращений считаем одинаковой, новых сбоев нет.

Сначала я считаю поступившие за паузу обращения: 18 × 4 = 72. Прибавляю прежнюю очередь: 72 + 12 = 84. После возвращения из 24 закрытых за день обращений 18 приходятся на новые. Для сокращения накопленной очереди остаётся 24 − 18 = 6 обращений в день. Значит, на её полное устранение потребуется 84 ÷ 6 = 14 рабочих дней после возвращения.

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

Что я хочу обсудить после проверки

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

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

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