Фёдор Борщёв

90% фич вылетает в трубу

Наверное, где-то в мире есть ребята, у которых гипотезы не выстреливают с вероятностью 80% или даже 75%. Но у нас с вами это не так. Фича, которую вы пилите прямо сейчас, улетит у трубу с вероятностью 90%. Пользователи не заметят новую кнопку, робот не сработает, потому что годится только для 0,1% заказов, а письмо, которое вы верстали неделю, никто не откроет.

Повторите про себя пару раз, и как только вы осознаете — вам сразу станет легче жить. Вы перестанете подходить к новым фичам с завышенными ожиданиями (вот сделаем и заживём!). Вы перестанете проектировать раздутое говно — зачем, если вы выкинете это с вероятностью 90%?

Вместо пиления фич вы начнёте проверять гипотезы. Ваш код тоже станет другим — вы начнёте тратить время не на фичи, а на скорость производства новых фич.

Помните мой совет со входом через Инстаграм? Зная о том, что этот вход не будет никому нужен с вероятностью 90%, вы сделаете интеграцию не с инстаграмом, а с auth0, чтобы в будущем сразу проверить 10 других способов входа, 1 из которых окажется рабочим.

Просто всегда помните, что ваша гениальная идея с вероятностью 90% — говно.

P.S. Сначала эта заметка вышла на моём телеграм-канале. Подписывайтесь.

Мне сказали — я копаю

В любой здоровой компании есть атмосфера критики. Кто бы ни пришёл с идеей: акционер, CEO или линейный сотрудник, его идею обязательно обсуждают и валидируют. Автору задают важные вопросы: «мы это делаем, чтобы что?», «если это не заработает, то из-за чего?» и тд. Такая резка фич, ещё до продакт-менеджера.

Почему-то внутри разработки такая практика обычно умирает. Какие бы странные задачи ни приходили, насколько бы очевидными упрощения в них ни были, программисты делают ровно то, что написано в требованиях. Это грустно, потому что часто программисты — самый большой центр затрат в компании. А что это за центр затрат, который не контролирует, куда он расходует ресурсы?

При этом программисты — прекрасные скептики: долгая работа с алгоритмами, которые описывают вещи из реального мира, приучает к критическому мышлению. Когда твои гениальные построения постоянно разбиваются о сложсочиненные системы в реальной жизни — скептиком становишься сам того не желая.

Давайте использовать скептицизм программистов — звать их на обсуждения, поощрять новые идеи, а самое главное — писать в задачах поменьше требований и побольше целей. Одно «чтобы что» стоит десяти «что сделать».

Feature flags

Фиче-флаги — это настройки, которые позволяют не трогая программистов менять поведение программы, к примеру включать и выключать фичи. Типа вот этому пользователю показываем общих в списке друзей, а тому — нет.

Чаще всего набор фиче-флагов формирует фронтенд, и отсылает на бекенд в момент каждого запроса. Так можно легко ставить a\b тесты — просто выбираем две когорты, одной добавляем фичу, а другой — нет, и смотрим на поведение.

Пример реализации — GitHub, который передает фиче-флаги в HTTP-заголовках. Прямо сейчас в API гитхаба таким образом включается-выключается одновременно 30 фич.

Есть ещё одно очень полезное применение фиче-флагов — полное отключение функций приложения в зависимости от среды. К примеру, у нас ЦРМ есть фича — уведомлять пользователя по СМС о статусе заказа. Но я не хочу, чтобы СМС уходили с тестовых стендов или из CI, даже если кому-то хватит ума прописать боевые ключи на них. Поэтому я делаю фиче-флаг ENABLE_NOTIFICATIONS и включаю его только в переменных окружения на проде. По умолчанию флаг выключен, поэтому где мы ни развернули мой бекенд — он никогда не пошлет сообдщений живым людям, если его явно об этом не попросить.

См. также:

  • Подробное объяснение пользы фиче-флагов от самого Мартина Фаулера
  • Launch Darkly — централизованное управление включенностью фич
  • Unleash — то же самое, но бесплатно и self-hosted

Давайте не любить новые фичи

Если вы работали с опытными продуктовыми менеджерами, то знаете, насколько они не любят новые фичи. Прежде, чем поставить фичу в план, продуктолог испробует все возможные способы от нее отказаться. У Интеркома даже целый мануал на эту тему есть.

Ненавидеть фичи — работа не только продуктолога, но и всей команды — дизайнеров, программистов, менеджеров и тестировщиков. Особенно важно ненавидеть фичи в стартапах.

Туду-лист хорошего продуктолога

Между простым и сложным, влюбленный в фичу программист всегда выбирает сложное. Он будет рефакторить код, менять архитектуру и делать другие программистские штуки только ради того, чтобы новой фиче приятнее жилось в системе. Не важно, что фичу не внедрят или забудут — программист любит свою работу и сделает ее хорошо.

Когда программист не любит фичи, все наоборот — он пишет код, не касаясь участков приложения, которые можно не трогать. Если фича заработает — плохой код перепишут, не страшно. Если не заработает — ну и хрен с ней, сделаем реверт.

Менеджер, который любит фичи, не жалеет инвестиций, — выделяет время команды и стейкхолдеров, нанимает больше программистов, и вообще превращается в трудолюбивого идиота.

Менеджер, который любит фичи, превращается в трудолюбивого идиота

Трезвый менеджер, наоборот, думает про цифры — на какую метрику бизнеса эта фича влияет? А что считать показателем успеха внедрения? Если ответов нет — фича режется.

Давайте экономить деньги и не любить фичи.

Небольшие доработочки

«А давайте ограничим длину обзора до 140 символов? Ну, вдруг мы захотим их в СМС рассылать, да и вообще нечего перегружать людей длинными обзорами. Это же 5 минут всего?».

Нет.

Большинство кодеров с вашей работы оценит эту задачу в 5 минут — чего там, надо только атрибут maxlength добавить. Но если вы — менеджер, который борется за качество своего продукта, то все гораздо сложнее.

Давайте поступим как агентства, которые заранее прописывают стоимость услуг в договоре, и учат менеджеров задавать кучу вопросов на брифе.

Что будет, если пользователь отправил обзор длиннее 140 символов? Просто обрежем, или покажем сообщение об ошибке? Если сообщение об ошибке, то где? Что напишем в сообщении? Нужен ли копирайтер? Сможем ли мы доступно объяснить пользователям, что нельзя отправлять больше 140 символов? Есть ли у нас в гайдах стили для таких ошибок? Нет? А кто нарисует?

Ворд целиком состоит из небольших доработочек
Ворд целиком состоит из небольших доработочек

Еще вопросы

Окей, побегали пару часиков и нашли ответы. Тогда углубимся в детали реализации. Начнем с того, что просто обрабатывать ошибку на сервере — плохо, лучше бы предупреждать клиента до отправки. Заморочимся валидацией на стороне клиента — появятся еще вопросы.

Есть ли свободные фронтендеры? Должно ли сообщение об ошибке повторять текст, который мы написали для сервера? Если нет, то кто напишет новое сообщение? Как нам сделать, чтобы в будущем любое изменение к «правилу 140» внедрялось одновременно и на сервере, и на клиенте?

Давайте не забывать про посетителей — люди раздражаются от непривычных и непонятных ограничений. Мы же не заставим их угадывать, сколько символов они набрали? Вот мы и дошли до счетчика символов.

Счетчик символов

Кто запилит счетчик? Кто проверит работоспособность на IE9 (вдруг мы — сайт банка)? Где мы его расположим? Как он будет выглядеть? Есть ли свободные дизайнеры?

Наверное внешний вид должен меняться по мере приближения к 140 символам. Ой, а что мы будем делать, когда пользователь упрется в лимит? Перестанем принимать ввод? А что делать, если пользователь вставит длинную портянку из буфера обмена? Разрешить обрезать текст или выдать ошибку?

А как мы объясним посетителям, что раньше было можно писать длинные обзоры, а теперь нельзя? Наверное, нужно научить саппорт отвечать на такие вопросы. А еще нужно обновить API и оба мобильных приложения. А что делать с уже написанными обзорами? Обрезать до 140 символов? Если обрезать, то по границе слов или предложений? А что, если граница предложения будет намного больше 140 символов?

Выводы

  • У качественных продуктов не бывает небольших доработок.
  • Объем работ прирастает очень быстро. То, что при планировании кажется 5 минутами, моментально превращается в неделю.
  • Пропихнуть фичу в следующий спринт — легко. Написать — сложно. Поддерживать всю жизнь — заебешься.

Эта заметка написана по мотивам поста из блога компании Интерком. Я сделал перевод, чтобы повысить вероятность того, что этот текст осилит менеджер занятый пропихиванием жизненно важной фичи в релиз.