Контейнеровоз Maersk Triple-E Class имеет длину 1 800 футов и перевозит более 18 000 контейнеров через 11 000 миль между Европой и Азией, и… весь его экипаж может поместиться в пассажирском фургоне.
Greg Kogan, бывший военно-морской архитектор, а ныне консультант по маркетингу для стартапов, обнаружил, что тот же принцип, который позволяет экипажу из 13 человек успешно перемещать крупнейший в мире контейнеровоз в порт через весь земной шар, также применим и к стартапам. Особенно к тем, которые хотят добиться агрессивного роста и ставят перед собой амбициозные цели.
Корабли состоят из простых систем, которыми легко управлять, в которых легко разобраться. Это облегчает их ремонт, а значит, у них меньше простоев. В данном случае под «временем простоя» мы понимаем время, которое необходимо, чтобы исправить поломку и продолжить движение, находясь за тысячи миль от берега.
Возьмём, к примеру, систему управления кораблем. Руль толкают влево или вправо металлические стержни. Эти стержни перемещаются за счёт гидравлического давления. Давление контролируется гидравлическим насосом. Насосом управляет электронный сигнал от рулевой рубки. Этим сигналом управляет автопилот. Для того, чтобы найти причину поломки и решение любой проблемы, команде корабля не понадобится помощь учёного-ракетостроителя или военно-морского архитектора:
Стартапы, как и корабли, не должны останавливаться из-за простоев системы. Длительные простои в продажах, маркетинге, сети, поддержке клиентов, найме, продуктах и других системах могут нанести непоправимый ущерб проекту и темпам его роста.
Хотя на современных судах уже есть автоматизация, она влияет только на время необходимое для выполнения задач и внимание необходимое для контроля за всеми системами. Двигатели и вспомогательные системы работают проще, чем когда-либо, благодаря современным дизельным и электрическим движительным агрегатам, которые заменили перегруженные паровые установки.
Если человек, ответственный за систему, уходит, падает за борт, попадает под автобус (см. Фактор автобуса) или переходит в новый проект, другой человек может заменить его без специального обучения или тренировки. В таком случае больше людей могут заниматься устранением неполадок и решением проблем.
Например, аналитическая панель, созданная компанией Tableau, вероятно, потребует для обслуживания более высокой квалификации специалистов, чем панель, созданная с помощью набора пользовательских скриптов и API. Никто не должен отвлекать экспертов по аналитике данных или разработчиков продуктов от их непосредственной работы, чтобы поправить гистограмму.
В системе, где поведение каждого компонента и его связь с другими легко понять, устранение проблем и поиск неисправного компонента (основной причины поломки) интуитивно понятны.
Например, если на веб-сайте компании есть много загружаемых документов и за их загрузку отвечает одна и та же форма, устранить неполадки будет проще, так как проблему нужно искать в одном месте (в коде этой формы). Но если для каждого документа существует собственная кастомная форма, это сделать гораздо сложнее.
Когда каждая часть системы выполняет чёткую функцию, её легче заменить на какую-то альтернативу.
Например, представьте себе систему Salesforce, которая использует автоматизацию и сторонние инструменты для оценки, фильтрации, классификации и назначения новых потенциальных клиентов. Если она нас перестанет устраивать или всё сломается, замену сходу предложить не получится. Работа будет заморожена до тех пор, пока проблема не будет решена или не будет найдено аналогичное, столь же сложное решение.
Теперь представьте себе систему, в которой отделу продаж просто приходит уведомление о каждом новом лидере продаж вместе с соответствующими деталями. Это позволяет им решить, нужно ли следовать за этой тенденцией или нет. Если процесс уведомления Salesforce завершится неудачей, легко придумать сотню других способов передачи этой информации в отдел продаж: отчёты, экспорт списка товаров, сбор данных вручную или использование Zapier для отправки оповещения практически любым способом. В этом случае время простоя не превысит нескольких минут.
Один из моих клиентов использовал устаревшую платформу автоматизации корпоративного маркетинга (Marketo) с 629 автоматизированными процессами, которые выстраивались несколько лет. Когда что-то ломалось или нуждалось в настройке, среди 150+ сотрудников был только один человек, который мог это сделать. Для устранения каждой проблемы требовалось несколько дней или даже недель. На период технических работ маркетинговые кампании вставали колом. И с каждым патчем вся система становилась всё более сложной.
Когда этот человек покинул компанию, то не было никого, кто мог бы управлять системой. Каждую неделю могла появиться новая проблема. Но чтобы найти и исправить её, требовалось больше недели.
Чтобы ситуация не зашла в тупик, я поспешил перевести компанию с Marketo на HubSpot, более простую платформу, в которой проще работать и устранять неполадки.
Миграция заняла всего одну неделю. Однако на этом пути возникла ещё одна сложная система — Salesforce. В ней было 10 автоматизированных процессов с более чем 100 связанными друг с другом операциями и все они зависели от различных автоматизированных процессов Marketo. Нам потребовалось две недели (вдвое больше времени, чем понадобилось на миграцию), чтобы разобраться и интегрировать эти процессы с новой маркетинговой платформой.
В целом, эти две сложные системы (Marketo и Salesforce) привели к шести неделям простоя отдела маркетинга и трём неделям простоя отдела продаж. И это не считая тех недель простоя, которые они испытывали в течение последних нескольких лет, и ещё многих недель простоя, которые они испытывали бы в будущем, если бы мы не собрали новую автоматизированную систему.
Новая система имела на 97% меньше процессов (20 против 629), но при этом обеспечивала все те же возможности. А ошибка, обнаруженная через несколько дней, была устранена за четыре минуты.
Этот опыт заставил меня задуматься о том, какие принципы могут использовать стартапы, чтобы избежать ошибок, связанных со сложностью систем.
Держать на плаву такие проекты, живущие по принципу rip-and-replace, — процесс болезненный и разрушительный, даже если долгосрочные выгоды того стоят. Многие стартапы, как и корабли, не имеют такой роскоши, как дополнительное время и ресурсы для проведения капитального ремонта при каждой поломке.
Я предлагаю три принципа, которым нужно следовать при оценке или внедрении новых систем:
Greg Kogan, бывший военно-морской архитектор, а ныне консультант по маркетингу для стартапов, обнаружил, что тот же принцип, который позволяет экипажу из 13 человек успешно перемещать крупнейший в мире контейнеровоз в порт через весь земной шар, также применим и к стартапам. Особенно к тем, которые хотят добиться агрессивного роста и ставят перед собой амбициозные цели.
У простых систем меньше время простоя
Корабли состоят из простых систем, которыми легко управлять, в которых легко разобраться. Это облегчает их ремонт, а значит, у них меньше простоев. В данном случае под «временем простоя» мы понимаем время, которое необходимо, чтобы исправить поломку и продолжить движение, находясь за тысячи миль от берега.
Возьмём, к примеру, систему управления кораблем. Руль толкают влево или вправо металлические стержни. Эти стержни перемещаются за счёт гидравлического давления. Давление контролируется гидравлическим насосом. Насосом управляет электронный сигнал от рулевой рубки. Этим сигналом управляет автопилот. Для того, чтобы найти причину поломки и решение любой проблемы, команде корабля не понадобится помощь учёного-ракетостроителя или военно-морского архитектора:
- если автопилот выходит из строя, управляйте кораблём из рубки вручную;
- если электронные сигналы не срабатывают, отправляйтесь в рулевую рубку, чтобы вручную управлять насосом, разговаривая с мостиком через простой звуковой телефон;
- если гидравлика выходит из строя, используйте механический аварийный руль;
- если это не сработает, зацепите цепь с обеих сторон руля и потяните в нужном направлении!
Стартапы, как и корабли, не должны останавливаться из-за простоев системы. Длительные простои в продажах, маркетинге, сети, поддержке клиентов, найме, продуктах и других системах могут нанести непоправимый ущерб проекту и темпам его роста.
Хотя на современных судах уже есть автоматизация, она влияет только на время необходимое для выполнения задач и внимание необходимое для контроля за всеми системами. Двигатели и вспомогательные системы работают проще, чем когда-либо, благодаря современным дизельным и электрическим движительным агрегатам, которые заменили перегруженные паровые установки.
Почему простота уменьшает время простоя
1. Квалификация экономит время
Если человек, ответственный за систему, уходит, падает за борт, попадает под автобус (см. Фактор автобуса) или переходит в новый проект, другой человек может заменить его без специального обучения или тренировки. В таком случае больше людей могут заниматься устранением неполадок и решением проблем.
Например, аналитическая панель, созданная компанией Tableau, вероятно, потребует для обслуживания более высокой квалификации специалистов, чем панель, созданная с помощью набора пользовательских скриптов и API. Никто не должен отвлекать экспертов по аналитике данных или разработчиков продуктов от их непосредственной работы, чтобы поправить гистограмму.
2. Устранение неполадок занимает меньше времени
В системе, где поведение каждого компонента и его связь с другими легко понять, устранение проблем и поиск неисправного компонента (основной причины поломки) интуитивно понятны.
Например, если на веб-сайте компании есть много загружаемых документов и за их загрузку отвечает одна и та же форма, устранить неполадки будет проще, так как проблему нужно искать в одном месте (в коде этой формы). Но если для каждого документа существует собственная кастомная форма, это сделать гораздо сложнее.
3. Больше альтернативных решений
Когда каждая часть системы выполняет чёткую функцию, её легче заменить на какую-то альтернативу.
Например, представьте себе систему Salesforce, которая использует автоматизацию и сторонние инструменты для оценки, фильтрации, классификации и назначения новых потенциальных клиентов. Если она нас перестанет устраивать или всё сломается, замену сходу предложить не получится. Работа будет заморожена до тех пор, пока проблема не будет решена или не будет найдено аналогичное, столь же сложное решение.
Теперь представьте себе систему, в которой отделу продаж просто приходит уведомление о каждом новом лидере продаж вместе с соответствующими деталями. Это позволяет им решить, нужно ли следовать за этой тенденцией или нет. Если процесс уведомления Salesforce завершится неудачей, легко придумать сотню других способов передачи этой информации в отдел продаж: отчёты, экспорт списка товаров, сбор данных вручную или использование Zapier для отправки оповещения практически любым способом. В этом случае время простоя не превысит нескольких минут.
История одного стартапа
Один из моих клиентов использовал устаревшую платформу автоматизации корпоративного маркетинга (Marketo) с 629 автоматизированными процессами, которые выстраивались несколько лет. Когда что-то ломалось или нуждалось в настройке, среди 150+ сотрудников был только один человек, который мог это сделать. Для устранения каждой проблемы требовалось несколько дней или даже недель. На период технических работ маркетинговые кампании вставали колом. И с каждым патчем вся система становилась всё более сложной.
Когда этот человек покинул компанию, то не было никого, кто мог бы управлять системой. Каждую неделю могла появиться новая проблема. Но чтобы найти и исправить её, требовалось больше недели.
Чтобы ситуация не зашла в тупик, я поспешил перевести компанию с Marketo на HubSpot, более простую платформу, в которой проще работать и устранять неполадки.
Миграция заняла всего одну неделю. Однако на этом пути возникла ещё одна сложная система — Salesforce. В ней было 10 автоматизированных процессов с более чем 100 связанными друг с другом операциями и все они зависели от различных автоматизированных процессов Marketo. Нам потребовалось две недели (вдвое больше времени, чем понадобилось на миграцию), чтобы разобраться и интегрировать эти процессы с новой маркетинговой платформой.
В целом, эти две сложные системы (Marketo и Salesforce) привели к шести неделям простоя отдела маркетинга и трём неделям простоя отдела продаж. И это не считая тех недель простоя, которые они испытывали в течение последних нескольких лет, и ещё многих недель простоя, которые они испытывали бы в будущем, если бы мы не собрали новую автоматизированную систему.
Новая система имела на 97% меньше процессов (20 против 629), но при этом обеспечивала все те же возможности. А ошибка, обнаруженная через несколько дней, была устранена за четыре минуты.
Этот опыт заставил меня задуматься о том, какие принципы могут использовать стартапы, чтобы избежать ошибок, связанных со сложностью систем.
Принципы работы с простыми системами
Держать на плаву такие проекты, живущие по принципу rip-and-replace, — процесс болезненный и разрушительный, даже если долгосрочные выгоды того стоят. Многие стартапы, как и корабли, не имеют такой роскоши, как дополнительное время и ресурсы для проведения капитального ремонта при каждой поломке.
Я предлагаю три принципа, которым нужно следовать при оценке или внедрении новых систем:
- Уникальность не оправдывает сложность. Что хорошего в сложной системе управления полётом, если она основана на целом парке воздушных судов или в корпоративной маркетинговой платформе, такой как Marketo, если никто не может провести маркетинговую кампанию? Выбирайте инструменты, которые просты в обращении и те, которые предлагают большинство необходимых вам функций.
- Сложные идеи приводят к сложным реализациям. Если для объяснения или понимания идеи требуется слишком много времени, её реализация будет сложной и когда что-то неизбежно сломается, чтобы исправить ситуацию, потребуется ещё больше времени. Например, процесс продаж, который требует часового разъяснения, будет кошмаром для поддержки и сопровождения, независимо от того, насколько продуманным он кажется.
- Старайтесь выполнять модификацию, а не плодить надстройки. Когда появляются новые требования, существует тенденция добавлять слои поверх существующей системы с помощью костыльных решений или интеграций. Вместо этого посмотрите можно ли изменить ядро системы, чтобы оно соответствовало новым требованиям. Изменение ядра может привести к (запланированному и единичному) повышению времени простоя, как в моем примере миграции Marketo-HubSpot, но к снижению (незапланированному) времени простоя в долгосрочной перспективе.
Попутного ветра!
«… Чем проще вещь, тем труднее её испортить и тем легче её исправить, когда она испорчена». Томас Пейн, Здравый смысл, 1776Нет сомнений, что во время запуска стартапа что-то обязательно сломается — как на корабле, огибающем земной шар. Однако, если встроенные системы просты, то эти проблемы не оставят стартап беспомощно дрейфующим посреди океана.
