[Перевод] В простых системах меньше даунтайм
Четырёхсотметровый контейнеровоз Maersk класса Triple-E перевозит 18 тысяч контейнеров на 11 тысяч морских миль между Европой и Азией, а вся его команда легко поместится в московской маршрутке
Как бывший морской архитектор, а ныне консультант по маркетингу стартапов, уверенно вам скажу: если команда из тринадцати человек способна без поломок провести через полмира самый большой на планете контейнеровоз, то нет вообще никаких невыполнимых задач для маленького стартапа.
В простых системах меньше даунтайм.
На кораблях максимально простые системы. До боли понятные интерфейсы. Всё многократно дублируется. Если систему легко понять и ей легко управлять, то будет легко и чинить, что уменьшает время простоев. Это очень важное качество для корабля, где «даунтайм» может означать аварию за тысячу километров от ближайшей помощи.
К примеру, система управления. Металлические стержни двигают руль влево или вправо. Сами стержни работают под действием гидравлического давления. Давление контролируется гидравлическим насосом. Насос управляется электронным сигналом из рулевой рубки. Сигнал управляется автопилотом. Не нужно быть физиком-ядерщиком или морским архитектором, чтобы понять причину и найти решение любой проблемы:
- Если не работает автопилот, управляем судном вручную из рулевой рубки.
- Если не проходят электронные сигналы, переходим на ручное управление насосом, подавая команды на мостик по аналоговому телефону с питанием от голоса (то есть без внешнего источника питания; здесь микрофонный преобразователь преобразует звуковое давление голоса в ток, который преобразуется обратно в звук на стороне приёмника).
- Если отказала гидравлика, используем аварийный руль с механической связью.
- Если не работает механическая связь, зацепим руль цепью и просто потянем в нужном направлении!
Как и корабли, стартапы не могут позволить себе даунтайм. Длительные простои в системах продаж, маркетинга, бэкенда, поддержки клиентов, найма, поддержки продукта нанесут непоправимый ущерб на старте, когда у нас экспоненциальный рост каждый день по всем показателям.
(Хотя на современных судах многие системы автоматизированы, это сокращает только время выполнения действий, но не количество времени для контроля этих систем. Судовые пропульсивные и вспомогательные системы сегодня просты как никогда, благодаря современным дизельным и электрическим двигателям, которые заменили паровые установки с трубами).
1. Быстрое обучение
Если ответственный за систему сотрудник уволился, выпал за борт, попал под автобус или ушёл на другой проект, коллега возьмёт на себя его обязанности без особого обучения или подготовки. Это означает, что больше людей могут подключиться к решению проблем и устранению неполадок. То есть у нас становится больше профессионалов.
Например, аналитическая панель Tableau работает проще, чем панель на множестве пользовательских скриптов и API. Соответственно, решить проблему в ней способно большее количество сотрудников. Никто не будет отрывать высококвалифицированных аналитиков, дата-сайентистов или программистов, чтобы исправить простенькую гистограмму.
2. Быстрое устранение неполадок
Если поведение каждого компонента и их связи между собой полностью ясны, то становятся интуитивно понятны первопричины любой неисправности, тупо методом исключения.
Например, если у компании на сайте много документов PDF для скачивания, и все они закрыты общей формой (а не отдельными), то в случае сбоя загрузки потребуется устранить неполадки только в одной форме и одном рабочем процессе автоматизации.
3. Больше альтернативных решений
Если в системе у каждой части чёткая функция, то легче найти альтернативные решения.
Например, процесс Salesforce использует мешанину из автоматизации и сторонних инструментов для оценки, фильтрации, классификации, назначения новых лидов (потенциальных новых клиентов). Если процесс выйдет из строя, то очевидной замены нет. Всё остановится, пока процесс исправят или заменят аналогичным сложным решением.
Теперь представьте процесс, в котором отдел продаж просто получает уведомление о каждом новом лиде вместе с соответствующими деталями для принятия решения, продолжать ли работу с этим лидом. Если уведомления Salesforce перестали работать, легко придумать сотню других способов донести эту информацию до отдела продаж: отчёты, уведомления в Slack, экспорт списков, ручной мониторинг или Zapier для отправки оповещений практически по любым каналам. Время простоя продлится максимум несколько минут.
У одного моего клиента в устаревшей платформе автоматизации маркетинга Marketo за несколько лет накопилось 629 процессов. Когда что-то ломалось или требовало доработки, то среди полутора сотен сотрудников все искали одного-единственного компетентного парня. На устранение каждой проблемы уходило несколько дней или недель, а маркетинговые кампании простаивали. И с каждым патчем система только усложнялась.
Когда тот парень уволился, управлять системой стало некому. Каждую неделю возникали новые проблемы. Мы не успевали их устранять.
Чтобы не допустить остановки работы, я поспешил перевести компанию с Marketo на более простую платформу HubSpot.
Переход занял всего неделю. Однако по пути мне на глаза попалась ещё одна сложная система — Salesforce. Там был десяток автоматизированных процессов с более чем сотней комбинированных операций, и все они зависели от различных тонко рассчитанных по времени автоматизаций в Marketo. На понимание и интеграцию этих процессов в новую маркетинговую платформу ушло две недели — вдвое больше, чем на миграцию.
В целом, две эти сложные системы (Marketo и Salesforce) вызвали шесть недель простоя отдела маркетинга и три недели отдела продаж. Чтобы полностью оценить ущерб, добавьте многие недели простоя за последние несколько лет и многие недели в будущем.
Я внедрил новую систему с 20 процессами вместо 629, которая обеспечивала все те же возможности. Когда через несколько дней нашли баг, его исправили за четыре минуты.
Этот опыт заставил меня задуматься о принципах работы стартапов, чтобы избежать ловушек сложных систем.
Апгрейд системы и миграция дорого обходятся, даже если долгосрочные преимущества того стоят. У многих стартапов, как у кораблей, нет времени и ресурсов для капремонта.
Вот три принципа, которым я следую при оценке или внедрении новых систем:
- Фичи — не оправдание для сложности. Что хорошего в навороченной системе управления полётом, если она выводит из строя все самолёты? Или в корпоративной маркетинговой платформе типа Marketo, если после сбоя никто не может провести маркетинговую кампанию? Выбирайте простые инструменты, а не максимальную функциональность. Я часто рекомендую стартапам в качестве маркетинговой платформы HubSpot вместо Marketo, Eloqua или Pardot.
- Сложные идеи ведут к сложным реализациям. Если на объяснение или понимание идеи уходит много времени, то и реализация будет сложной. А когда что-то неизбежно сломается, потребуется слишком много времени на исправление. Например, если презентация нового процесса продаж заняла целый час, то его поддержка станет кошмаром, каким бы умным процесс ни казался.
- Лучше исправить, чем добавить. Когда появляются новые требования, возникает искушение добавлять слои поверх существующей системы — дополнительные шаги или интеграции. Вместо этого посмотрите, можно ли изменить ядро системы, чтобы она соответствовала новым требованиям. Поначалу изменения могут вызвать (запланированные) простои, как в моём примере миграции с Marketo на HubSpot, но в долгосрочной перспективе (незапланированный) даунтайм будет меньше.
»… Чем проще вещь, тем труднее её испортить и тем легче её исправить, когда она испорчена». — Томас Пейн, «Здравый смысл», 1776 г.
Конечно, во время путешествия в стартапе всё будет ломаться, как и на корабле, пересекающем земной шар. Но если бортовые системы просты и понятны, то стартап не бросят беспомощно дрейфовать посреди океана.
