Оба, но в разное время
Нам платят за создание продуктов, поэтому нет ничего более естественного, чем тратить свое время на создание как можно большего количества продуктов. Однако выпуск этих продуктов влечет за собой прямые и косвенные расходы, такие как затраты на обслуживание, поддержку и сложность.
В этой статье я в трех частях объясняю, следует ли вашей компании инвестировать в качество или в скорость.
Часть 1. Стремление к созданию новых функций
«Новая функция будет убийственной, верно?»
«Да, конверсия и удержание увеличатся!»
«Мир станет лучше, когда эта функция выйдет!»
«Давайте запустим его вживую, не беспокойтесь о техническом долге. После релиза мы сможем это исправить!»
«А как насчет тестов, предупреждений, регистрации, отслеживания, мониторинга и устойчивости? ”
«Мы можем сделать все это позже. Крайне важно иметь быстрый выход на рынок».
Если бы я зарабатывал по одному центу каждый раз, когда инженер слышит подобные фразы, я был бы миллиардером.
ИМХО, одно большое заблуждение состоит в том, что мерилом нашего успеха является количество выпущенных фич, а не их влияние. Это трудно принять, но клиенты обычно не бессонны в ожидании вашего следующего релиза.
Предположим, у вас уже есть клиентская база, использующая ваши продукты, которая довольна текущими функциями. В этом случае удержание ваших клиентов с помощью надежного продукта является более важным, чем наполнение его функциями за счет его стабильности.
Компании зарабатывают деньги не на продуктах, которые они разрабатывают, а на тех, которые они эксплуатируют.
Как я уже говорил в этом другом блоге о важности команд, каждая выпускаемая вами функция увеличивает объем поддержки и обслуживания, пока эта функция находится в производстве. Если у этой функции есть проблемы в работе, она будет потреблять ваши ресурсы от ответственных команд, поддержки первого уровня и заинтересованных сторон, то есть продаж.
На приведенном выше рисунке показано, как некоторые мощности будут скомпрометированы для обслуживания/поддержки после разработки продукта, что замедлит разработку следующих продуктов.
Нестабильность еще больше увеличит пропускную способность поддержки, тем самым уменьшая способность команды разрабатывать более ценные функции.
Другими словами, чем выше качество производства, тем меньше вам придется инвестировать в поддержку и обслуживание, и тем продуктивнее будут ваши команды. Но после переломного момента не стоит больше вкладываться в качество. Излишняя инженерия — это всего лишь причудливая растрата.
Часть 2: Сосредоточьтесь на ядре
У продуктов есть ядро, которое является решением потребности. Например, Airbnb выступает в роли посредника между людьми, сдающими комнаты, и людьми, которые ищут место, где можно провести несколько дней.
Чтобы сделать аренду комнаты более надежной, приятной и прибыльной, Airbnb внедрила такие функции, как поиск на карте, оценка хозяев и т. д.
Эти функции полезны и приносят пользу. Они активно используются и стали частью ядра Airbnb.
Как вы можете прочитать в классической книге Эрика Риса Бережливый стартап (или в этом блоге), нам приходится много экспериментировать, чтобы найти нужные функции для наших клиентов, и не следует полагаться на свою интуицию, выпуская функцию за функцией. .
У нас должно быть по крайней мере два способа работы: а) как мы работаем с нашим ядром и б) как обнаружить следующие продукты или функции.
Мы не должны идти на компромиссы при работе с нашим ядром. Это ядро должно иметь необходимое качество во всех соответствующих аспектах:
- Юзабилити и дизайн
- Производительность
- Стабильность
- Надежность
- Ремонтопригодность
- Тестируемость
- Устойчивость
- Честность
- Безопасность
У вашего ядра должна быть политика отсутствия ошибок и среднее время восстановления в течение нескольких минут. Ответственная команда предупреждена о любых проблемах и немедленно приступает к их устранению.
Первоначально команды будут много заниматься тушением пожаров, но они будут изучать и использовать шаблоны и инструменты, которые помогут им, например следующие:
- Автоматизация выпуска
- Автоматизация тестирования
- Мониторинг, регистрация, отслеживание и оповещение
- Хаос-инженерия
- SAST (статическое тестирование безопасности приложений) и DAST (динамическое тестирование безопасности приложений)
- Обязанности по вызову
- Runbook
Также важны инвестиции в современную архитектуру и хорошее и практичное качество кода.
Все эти аспекты улучшат качество вашего продукта в эксплуатации, тем самым снизив когнитивную нагрузку на его поддержку и избежав переключения контекста для ваших команд.
Через некоторое время ваше ядро становится надежной платформой. Кроме того, вы можете эффективно и, надеюсь, эффективно создавать новые продукты и функции.
Часть 3: Теперь вы можете ускориться
Открытие новых продуктов и функций должно быть как можно более быстрым и дешевым, с быстрой итерацией и отбрасыванием 100% того, что протестировано, даже в случае успеха. Цель состоит не в том, чтобы создать что-то «готовое к производству», а в том, чтобы проверить проблему и ее решение.
Крайне важно разделить то, что вы проверяете, и то, что вы хотите в своем ядре, потому что разработчики, как правило, чувствуют себя привязанными ко всему, что они создают, и имеют проблемы с отбрасыванием любой части работы, даже неудач.
Если идея будет одобрена, и вы решите, что стоит ее создать, вы можете сделать это с учетом всего качества, которое у вас есть для текущей платформы.
Существует несколько инструментов, фреймворков и практик для максимально простой проверки идей:
- Дизайн-спринты
- Быстрое прототипирование
- Канарские релизы
- A/B-тестирование
Все, что вы проверяете, должно быть отклонено, не оставляя остатков на вашей платформе.
Последние мысли
Идея состоит в том, чтобы работать только с продуктами, которые, несомненно, представляют ценность для ваших клиентов.
Создайте отказоустойчивый подход к технической платформе, чтобы снизить когнитивную нагрузку ваших команд.
Подтвердите идеи как можно дешевле и проще, и если они действительно являются адекватным решением соответствующей проблемы, создайте их, помня об их превосходстве в производстве.
