Допустим, вы создаете продукт для автоматизации маркетинга в социальных сетях, где вы позволяете пользователям планировать несколько публикаций на разных платформах социальных сетей. Для вашего первого релиза вы планируете использовать только Twitter в качестве единственной платформы. Вы выпускаете его, и людям нравится ваш продукт. Есть несколько ошибок. Иногда сообщения не сохраняются в БД и теряются. В других случаях сообщения не публикуются в твиттере в нужное время, на которое это было запланировано. Это мелкие неприятности, но ваших первых последователей они не волнуют.
Вопрос: у вас есть неделя рабочего времени вашего разработчика, после чего он уезжает в длительный отпуск. Что бы вы сделали?
- Вариант А. Добавить новую функцию (публикация в facebook или instagram), которая принесет вам больше денег?
- Вариант Б. Исправить эти две ошибки, на которые жалуются существующие клиенты?
Вариант A: ОСОБЕННОСТИ MOAR
Многие бизнесмены / нетехники в компании предпочли бы добавить в продукт больше функций.
Для покупателя новые функции - конфета для пятилетнего ребенка. Если вам так нравится продукт, вы захотите увидеть больше функций, чтобы получить большую отдачу за деньги, которые вы платите.
А для специалистов по продажам и маркетингу новые функции - простой способ привлечь больше клиентов. Вы можете вообще выйти на новый сегмент рынка. Добавление Instagram означает, что вы можете обращаться к сайтам электронной коммерции. Добавление LinkedIn означает, что вы можете обращаться к компаниям, которые хотят нанять людей.
Эти мелкие ошибки просто раздражают, и пока мало кто из клиентов жалуется на них. Так что поработать еще есть время. В конце концов мы это исправим.
Такой образ мышления имеет большое значение для генерального директора и совета директоров, потому что все хотят больше доходов, верно? Если добавление одной небольшой функции может в 2 или даже 3 раза увеличить ваш доход, вы должны поступить глупо, чтобы этого не сделать.
Вариант Б: ИСПРАВИТЬ ДЕРЬМО
Если вы выбрали вариант Б, велика вероятность, что вы разработчик. Вы понимаете, как накапливаются технические долги, и, если вы сначала не исправите суть продукта, в дальнейшем это будет большой головной болью.
Может быть, выбор базы данных был неправильным и именно поэтому возникают проблемы с сохранением? Или вы используете какой-то навороченный планировщик задач, который используют все, но процесс постоянно прекращается или заканчивается нехваткой памяти.
Иногда исправить это просто: Используйте crontab вместо планировщика.
Иногда исправление может быть сложным: Используйте лучшую базу данных и переместите данные в новую базу данных. Но это включает в себя план миграции, чтобы убедиться, что существующие клиенты не пострадают.
В зависимости от серьезности ошибки и проблем, которые могут возникнуть позже, вы должны расставить приоритеты для исправления. Но вы обязательно исправите их как можно скорее, потому что вы знаете о теории разбитого окна.
Теория разбитого окна
Теория разбитого окна - это теория о нормотворчестве и сигнальном эффекте вандализма и беспорядка, вызывающем рост преступности и антиобщественное поведение.
Представьте себе здание с несколькими разбитыми окнами. Если окна не ремонтировать, вандалы чаще всего разбивают еще несколько окон. В конце концов, они могут даже проникнуть в здание, а если в нем нет людей, возможно, станут скваттерами или зажгут внутри.
Или рассмотрим тротуар. Накапливается некоторый мусор. Вскоре помет накапливается. Со временем люди даже начинают оставлять там мешки с мусором из ресторанов на вынос или даже влезают в машины.
Многие психологи провели множество экспериментов по этому поводу, и они показывают, что если какое-то свойство не обслуживается должным образом, это станет нормой, и любые новые специалисты по обслуживанию также не будут так сильно заботиться об этом.
Это верно для любого фрагмента кода или продукта. Если вы недостаточно заботитесь о том, чтобы сначала исправить ошибки в продукте, новые сотрудники также могут подумать, что разработчики в этой компании недостаточно заботятся об исправлении ошибок. И когда они находят новые ошибки, они оставляют их не исправленными.
Не исправлять ошибки стало нормой.
Хорошие разработчики всегда стараются исправить ошибки, прежде чем писать новый код. Они понимают, как сложно построить что-то на плохо построенном / спроектированном коде. Точно так же, как ни один строитель не построит дом на плохом подвале.
Но мы не можем исправить все ошибки
Я слышал, вы жалуетесь: «Никто не может создавать программы без ошибок». Правда.
Если отладка - это процесс удаления ошибок, то программирование должно быть процессом их вставки. - Эдсгер В. Дейкстра
Я прошу сначала исправить известные ошибки, прежде чем добавлять новые функции. Даже в этом случае есть два вида ошибок:
- Вещи, которые, как вы знаете, ломаются изнутри, также известные как технический долг.
- Ваши клиенты знают, что они сломаны и продолжают жаловаться.
Вам необходимо отслеживать оба этих типа ошибок и убедиться, что вы обрабатываете ошибки, о которых знает заказчик. Много раз, если вы нацелены на клиента, сталкивающегося с ошибками, большинство внутренних ошибок также будет исправлено в качестве побочного эффекта.
Почему для бизнеса имеет смысл сначала исправлять ошибки
Если вы продолжите добавлять новые функции, а это означает больше ошибок, клиенты скоро устанут от использования вашего продукта и в конечном итоге уйдут. Сказать это понятным вам термином: Отток.
Клиенты перестанут использовать ваш продукт, так как он вызывает нежелательное разочарование при его использовании. Это повлияет на ваших ежемесячных активных пользователей (MAU), и в конечном итоге они перестанут платить за услугу, которой больше не пользуются.
Тогда они будут оставлять гневные отзывы и комментарии о вашем продукте, и будущие клиенты также не будут подписываться на вашу услугу. Это повлияет на рост вашего дохода. И, наконец, ваша оценка резко упадет, и будет практически невозможно привлечь новый раунд финансирования.
Все это произошло из-за того, что вы не дали разработчику времени исправить две ошибки.
Поэтому в следующий раз, прежде чем планировать / создавать новую функцию, обязательно исправьте все известные ошибки.
Первоначально опубликовано в Сринивасан Рангараджан.
