Идея тестировать код постановкой его в неудобные ситуации появилась далеко не сразу. До этого не разработчик думал о том, как поломать код в разных тестах, а тестировщики пытались сделать это руками. Грубо говоря, предполагалось, что мудрый разработчик пронзит код мыслью и сразу представит все его состояния в квантовой суперпозиции.
Очень многие вещи из ИТ-сферы напрямую относятся к бизнес-процессам. Тойота в какой-то момент придумала промежуточные юнит-тесты на производстве в своей TPS («каждое следующее звено — внутренний заказчик с критериями приёмки»), но вот в областях типа переговоров истории сквозных проверок далеко не зашли. Вообще, в решении типовых переговорных ситуаций есть очень много гениальных механик вроде «русской рулетки» или «техасской перестрелки» при разделе имущества. Только мало кто договаривается подобное применять, потому что в конечном итоге нужно уметь декомпозировать ситуацию и отладить её.
Лет 7 назад я писал про очень простую модель того, как могут договариваться основатели небольшой компании на старте: кто за что отвечает, кто главный в ситуации клинча, как принимаются важные решения и так далее. Это была хорошая рабочая механика, но, как выяснилось за это время, случиться может вообще всякое. И все эти исключения надо обрабатывать. Например, я не думал, что у нас будет смерть соучредителя (и последовавшие проблемы для начала с почтой и доменом, зареганными на него, а потом ещё с кучей всего с наследством его доли).
И вот в какой-то момент к нам в гости завалился человек, который посвятил полжизни конфликтам учредителей. Первая мысль была: «Ну, это не про нас». А потом здравый смысл пересилил, и мы попробовали его механику договорки. И знаете, что? Отдаёт мазохизмом, но удивительно хорошо работает. В общем, давайте покажу, как выглядит очень далёкий, но всё же аналог юнит-тестов сотрудничества нескольких предпринимателей.
Как это выглядит
Есть Дима Гриц, он адвокат, но выступает он в роли психолога, скорее. Он может задать сотни вопросов, после которых будущие учредители могут подраться уже на месте — но на выходе будет сущностное соглашение, как делать, и как не делать. Его позже можно и занести в устав компании, но смысл не в этом, а в том, чтобы очертить границы.
Эти же вопросы есть в виде карточек, если партнёры хотят сделать всё сами — ну или если не хотят делиться сокровенным с какими-то левыми людьми. Тем более адвокатами.
Интересно, что это продукт своего времени: мы всё чаще и чаще видим разные непонимания из-за многозадачности на проектах. Когда человек работает сразу в 5-6 бизнесах (а это нормально, особенно после того, как мир перевернула удалёнка), то границы ой как нужны. Нужно знать, что от тебя ждут, что можно и что нельзя. Понятно, что можно это выяснять эмпирически за годы притирки друг к другу — а можно сесть и обсудить заранее.
Итак, собираетесь на 3 часа, берёте блокнот для записей и начинаете задавать друг другу вопросы. Понятно, что по факту многие ситуации решать преждевременно: бизнес ведь ещё нужно начать, ещё нужно заработать и так далее. Но лучше потратить эти 3 часа и потом закрыть проект, чем не потратить и оказаться в ситуации конфликта, когда медведь уже убит, и шкуру надо делить.
Зачем всё это?
Один из первых вопросов — это зачем вообще делается бизнес. Он нифига не случайный, потому что есть много следствий из цели. Например, если кто-то хочет 3 миллиона долларов на редкую операцию для хомячка Зиновия, то может оказаться, что можно добиться цели не деньгами, а чем-то ещё по ходу проекта, например, оказав важную услугу бартером нейрохирургу. Ну и просто партнёрам хорошо бы заранее знать, что каждый из них хочет. Потому что если цель будет «переехать в Австралию», это может слегка повлиять на сюжет.
Но куда важнее сразу решить, бизнес для себя или на продажу. Потому что это разные типы подходов, разные модели управления, разные приоритеты. Например, наш «Метеор» на текущий момент, хоть и самая большая нефраншизная сеть детских спортивных школ в России, но продать его, если мы захотим, будет очень и очень сложно. Спортивные школы сами по себе никому не нужны, нужна клиентская база, нужна технология и процессы, которая позволяет всё это объединять и делать системой. Если Мосигра продавалась, фактически, по оценке клиентской базы (точнее, покупался клиентский трафик, число потенциальных сделок), то в случае Метеора нам важно будет разработать методологию (уже есть вторая версия от РГУФК), следить за её эффективным исполнением (работаем над нейросетевой видеоаналитикой тренировок) и создать какую-то платформу, которая объединяет клиентов. То есть физрук дядя Петя должен оказаться в ситуации, что даже если он крутой футболист, ему будет выгоднее открыть наше отделение и работать в нём, нежели пытаться тренировать детей без нашей помощи. Кстати, уже сейчас есть сетевой эффект, когда мы можем делать первенства районов между школами благодаря большому количеству отделений, и собирать сборные по районам — но если (когда) мы захотим международное масштабирование, только этого будет мало.
С другой стороны, если бизнес строится на продажу, у него часто нет цели получить прибыль в моменте. Да, юнит-экономика должна сходиться, но нужно максимально быстро расти, чтобы получать максимум покрытия рынка. Бизнес для себя может быть комфортным и неторопливо-уютным, но если речь про быть №1 или в крайнем случае №2 на рынке — это сразу адская гонка.
Где-то в этом месте выясняется, что есть люди, которые могут внятно сформулировать ожидания, а есть люди, которых это неимоверно бесит. До сих пор мы изредка встречаем интересных гуманитариев, которые не хотят считать финмодели, потому что это как-то сложно, и нужно много прогнозировать, лучше начнём, а там посмотрим. Мы считаем их опасными психами. И тут снова помог Дима Гриц, внезапно дав инструмент: вместо того, чтобы просить их дать состояние будущего, он разбивает всё это на десятки вопросов о том, «что, если». И это работает.
Вот так делай, вот так не делай
Как только становится понятно, зачем нужен бизнес, например, можно решить, что этично, а что неэтично делать. Например, в историях для инвесторов часто встречается принцип fake it till you make it — говори, что это у тебя есть, продвигай, собирай инвестиции, а потом уже делай. Принцип в общем-то логичный и эффективный, но не так, чтобы честный. Недавний пример — Engineer.ai сказали, что у них есть AI для написания скриптов по аналогам с сайта и словесному описанию того, что делает программа. Но есть нюанс: «По словам бывшего сотрудника, Engineer.ai начал разрабатывать технологию, необходимую для автоматизации создания приложений, только в последние два месяца. Несколько нынешних и бывших сотрудников заявили, что большая часть работы в целом выполняется персоналом вручную». Где-то сразу за решением этого вопроса следует вопрос про взятки, откаты, можно ли стучать в прокуратуру на конкурента, можно ли ругать кого-то из партнёров, контрагентов или госорганы в личных соцсетях и так далее. А потом стоит задаться вот этим прекрасным вопросом, который снимет много иллюзий:
Я знаю одну прекрасную даму, которая управляет личными отношениями примерно как проектами. Например, она выдвигала концепцию, что сначала должен быть быстрый MVP на одну ночь, а потом уже можно детальнее разбираться друг с другом как с личностями. Она же сразу выставляла кросс-SLA как мы в своё время франшизам: «Хотите, чтобы заказ комплектовался быстрее на 2 дня? Готовы платить роялти больше на 5 тысяч рублей в месяц?» — то есть когда партнёру что-то важно, и он ставит на это SLA, в ответ от вас приходит другой SLA, который важен уже вам. И, по идее, все отношения описываются такими цепочками: если договориться сразу (а мы с франшизами договорились далеко не сразу в своё время), то будет понятно, что кому важно, и что как делать. Заслуга дамы в том, что она договаривается о таком файле настроек не только в деловой сфере, что в какой-то момент меня довольно сильно удивило, поскольку люди, как правило, не готовы рационализировать и покрывать бизнес-процессами личные отношения.
Дальше нужно обсудить возможные критические ситуации. Вот, например, прекрасный вопрос с прекрасным вариантом решения: но если его не задать на берегу, время будет фатально упущено:
Ещё неподсвечиваемые обычно области
В малом бизнесе очень много вопросов связано с тем, кто и что делает на проекте. Я не зря выше сказал про многозадачность: когда проект у вас один, более-менее понятно, что вы все вместе врываетесь и делаете. А когда проектов 5, 8 или 26 — нужно очень чётко понимать, где чья роль заканчивается. Это может быть время в часах, это закрытие каких-то целей, это возможность доступа к нужным людям, это деньги — всё это хорошо бы обсудить сразу в виде конкретных действий, которые друг от друга ожидаются. А ещё — будет ли обязательный офис, нужно ли согласовывать свои рабочие графики, могут ли все сразу убежать в отпуск на майские или кто-то останется дежурить и так далее. Интересно тут же обсудить зарплаты. Вообще, история с зарплатами очень важна для того, чтобы не прочухать момент, когда вы превращаете проект в самозанятость.
Предполагается, что у партнёров есть доли (либо опционы за 1 рубль на эти доли, что куда проще оформлять на начальных этапах), и есть оклад. Оклад даётся в обмен на работу. Это важно, потому что бизнес, по идее, в какой-то момент должен работать без учредителей: финмодель должна сходиться так, что их заменят наёмные сотрудники. Этот оклад пишется в расходы компании, а прибыль распределяется на развитие, подушку безопасности, и уже потом — на выплаты дивидендов и премий. Кстати, схему распределения прибыли тоже лучше обсудить сразу. У нас, например, предполагается два состояния: оклады и продажа доли внутри компании или внешнему покупателю.
Большой блок вопросов касается того, как решаются личные вопросы в компании. Например, можно ли бесплатно оказывать услуги родственникам, есть ли специальные скидки у самих партнёров, можно ли вдруг нанять родственника или друга. Как и кого представляют сотрудникам? Что у кого написано на визитке? Готов ли партнёр рассказывать совладельцам о личных деньгах, своём времени, планах на жизнь раз в год?
Можно ли обсуждать секретные вещи по почте, телеграмму, телефону? Кто сколько может тратить на такси, гостиницы в командировках и рестораны?
Есть ли заказчики, с которыми работать ну прям совсем зашквар? Можно ли рядом делать точно такой же проект самому или с другими типами? А из этой же области, но другой?
Когда точно нужно останавливать бизнес и разбегаться? Кто получает бренд при ликвидации?
Кто может давать интервью, а кто не может?
Очень важно — какая отчётность и как ведётся. То есть у нас-то документы открыты для всех соучредителей, и после опыта розницы отчётность ведётся достаточно жёсткая. Но есть компании, где либо просто что-то не фиксируется, либо получать данные о том же финансовом анализе нужно по запросу. Так вот, очень хорошо обсуждать не только то, что всё это приходит само и без вопросов, но и конкретные формы, как это приходит. Более глубокий смысл не в том, чтобы показать, как вы доверяете партнёру, а в том, чтобы система как таковая исключала возможность злоупотреблений. Это как гигиена.
Нужно ли заранее думать про брачный договор на случай развода, чтобы чья-то бывшая жена не появилась в учредителях? Что нужно предусмотреть на случай смерти партнёра? Что делать, если кто-то сломает ногу или загремит в больницу, под арест, в роддом или в армию?
Ещё один интересный вопрос — это условия пересмотра партнёрского соглашения. Есть интересные модели, когда оно заключается на срок, скажем, 3 года, а через эти 3 года пересматривается по результатам работы каждого участника — с выкупом долей, если надо. Причём, кстати, вопрос выкупа долей встаёт регулярно: это нужно и при дофинансировании для роста, и при желании партнёра выйти из бизнеса и так далее. Естественно, сразу на берегу нужно договориться об оценке компании — о методике и о числе, например, что это будет EBITDA с мультипликатором. Ну и как считается эта самая ебитда: по официальной или «управленческой» отчетности.
В модели ещё очень много посвящено взаимодействию с инвесторами, опционам сотрудникам, разным коллаборациям и прочему. Она как программа подготовки бортинженера на МКС: включает и конкретные действия при типовых авариях, и порядок действия в нештатных непрогнозируемых ситуациях. Оказалось, чертовски полезно обсуждать такое при старте нового проекта: как минимум, это сильно успокаивает всех адекватных соучредителей.
В общем, садитесь, выписываете все вопросы, которые вы недопонимаете, изучаете ошибки друзей-коллег и их конфликты, собираете коллекцию возможных параноидальных ситуаций — и начинаете обсуждать. Если задуматься, такая процедура может быть полезна не только при старте предпринимательского проекта, а в любой ситуации, где проговорить риски и решения к ним заранее гораздо лучше, чем потом собирать выбитые зубы сломанными руками.
Вот тут больше про Диму, если интересно. И да, он один из соучредителей нашего проекта, на который ведёт ссылка, так что эту процедуру применили и к нему тоже :)
