В любой здоровой компании есть атмосфера критики. Кто бы ни пришёл с идеей: акционер, CEO или линейный сотрудник, его идею обязательно обсуждают и валидируют. Автору задают важные вопросы: «мы это делаем, чтобы что?», «если это не заработает, то из-за чего?» и тд. Такая резка фич, ещё до продакт-менеджера.
Почему-то внутри разработки такая практика обычно умирает. Какие бы странные задачи ни приходили, насколько бы очевидными упрощения в них ни были, программисты делают ровно то, что написано в требованиях. Это грустно, потому что часто программисты — самый большой центр затрат в компании. А что это за центр затрат, который не контролирует, куда он расходует ресурсы?
При этом программисты — прекрасные скептики: долгая работа с алгоритмами, которые описывают вещи из реального мира, приучает к критическому мышлению. Когда твои гениальные построения постоянно разбиваются о сложсочиненные системы в реальной жизни — скептиком становишься сам того не желая.
Давайте использовать скептицизм программистов — звать их на обсуждения, поощрять новые идеи, а самое главное — писать в задачах поменьше требований и побольше целей. Одно «чтобы что» стоит десяти «что сделать».
Фиче-флаги — это настройки, которые позволяют не трогая программистов менять поведение программы, к примеру включать и выключать фичи. Типа вот этому пользователю показываем общих в списке друзей, а тому — нет.
Чаще всего набор фиче-флагов формирует фронтенд, и отсылает на бекенд в момент каждого запроса. Так можно легко ставить a\b тесты — просто выбираем две когорты, одной добавляем фичу, а другой — нет, и смотрим на поведение.
Пример реализации — GitHub, который передает фиче-флаги в HTTP-заголовках. Прямо сейчас в API гитхаба таким образом включается-выключается одновременно 30 фич.
Есть ещё одно очень полезное применение фиче-флагов — полное отключение функций приложения в зависимости от среды. К примеру, у нас ЦРМ есть фича — уведомлять пользователя по СМС о статусе заказа. Но я не хочу, чтобы СМС уходили с тестовых стендов или из CI, даже если кому-то хватит ума прописать боевые ключи на них. Поэтому я делаю фиче-флаг ENABLE_NOTIFICATIONS и включаю его только в переменных окружения на проде. По умолчанию флаг выключен, поэтому где мы ни развернули мой бекенд — он никогда не пошлет сообдщений живым людям, если его явно об этом не попросить.
См. также:
Подробное объяснение пользы фиче-флагов от самого Мартина Фаулера
Launch Darkly — централизованное управление включенностью фич
Если вы работали с опытными продуктовыми менеджерами, то знаете, насколько они не любят новые фичи. Прежде, чем поставить фичу в план, продуктолог испробует все возможные способы от нее отказаться. У Интеркома даже целый мануал на эту тему есть.
Ненавидеть фичи — работа не только продуктолога, но и всей команды — дизайнеров, программистов, менеджеров и тестировщиков. Особенно важно ненавидеть фичи в стартапах.
Между простым и сложным, влюбленный в фичу программист всегда выбирает сложное. Он будет рефакторить код, менять архитектуру и делать другие программистские штуки только ради того, чтобы новой фиче приятнее жилось в системе. Не важно, что фичу не внедрят или забудут — программист любит свою работу и сделает ее хорошо.
Когда программист не любит фичи, все наоборот — он пишет код, не касаясь участков приложения, которые можно не трогать. Если фича заработает — плохой код перепишут, не страшно. Если не заработает — ну и хрен с ней, сделаем реверт.
Менеджер, который любит фичи, не жалеет инвестиций, — выделяет время команды и стейкхолдеров, нанимает больше программистов, и вообще превращается в трудолюбивого идиота.
Менеджер, который любит фичи, превращается в трудолюбивого идиота
Трезвый менеджер, наоборот, думает про цифры — на какую метрику бизнеса эта фича влияет? А что считать показателем успеха внедрения? Если ответов нет — фича режется.
«А давайте ограничим длину обзора до 140 символов? Ну, вдруг мы захотим их в СМС рассылать, да и вообще нечего перегружать людей длинными обзорами. Это же 5 минут всего?».
Нет.
Большинство кодеров с вашей работы оценит эту задачу в 5 минут — чего там, надо только атрибут maxlength добавить. Но если вы — менеджер, который борется за качество своего продукта, то все гораздо сложнее.
Давайте поступим как агентства, которые заранее прописывают стоимость услуг в договоре, и учат менеджеров задавать кучу вопросов на брифе.
Что будет, если пользователь отправил обзор длиннее 140 символов? Просто обрежем, или покажем сообщение об ошибке? Если сообщение об ошибке, то где? Что напишем в сообщении? Нужен ли копирайтер? Сможем ли мы доступно объяснить пользователям, что нельзя отправлять больше 140 символов? Есть ли у нас в гайдах стили для таких ошибок? Нет? А кто нарисует?
Ворд целиком состоит из небольших доработочек
Еще вопросы
Окей, побегали пару часиков и нашли ответы. Тогда углубимся в детали реализации. Начнем с того, что просто обрабатывать ошибку на сервере — плохо, лучше бы предупреждать клиента до отправки. Заморочимся валидацией на стороне клиента — появятся еще вопросы.
Есть ли свободные фронтендеры? Должно ли сообщение об ошибке повторять текст, который мы написали для сервера? Если нет, то кто напишет новое сообщение? Как нам сделать, чтобы в будущем любое изменение к «правилу 140» внедрялось одновременно и на сервере, и на клиенте?
Давайте не забывать про посетителей — люди раздражаются от непривычных и непонятных ограничений. Мы же не заставим их угадывать, сколько символов они набрали? Вот мы и дошли до счетчика символов.
Счетчик символов
Кто запилит счетчик? Кто проверит работоспособность на IE9 (вдруг мы — сайт банка)? Где мы его расположим? Как он будет выглядеть? Есть ли свободные дизайнеры?
Наверное внешний вид должен меняться по мере приближения к 140 символам. Ой, а что мы будем делать, когда пользователь упрется в лимит? Перестанем принимать ввод? А что делать, если пользователь вставит длинную портянку из буфера обмена? Разрешить обрезать текст или выдать ошибку?
NYSE TWTR: 140 символов — не всегда хорошо
А как мы объясним посетителям, что раньше было можно писать длинные обзоры, а теперь нельзя? Наверное, нужно научить саппорт отвечать на такие вопросы. А еще нужно обновить API и оба мобильных приложения. А что делать с уже написанными обзорами? Обрезать до 140 символов? Если обрезать, то по границе слов или предложений? А что, если граница предложения будет намного больше 140 символов?
Выводы
У качественных продуктов не бывает небольших доработок.
Объем работ прирастает очень быстро. То, что при планировании кажется 5 минутами, моментально превращается в неделю.
Пропихнуть фичу в следующий спринт — легко. Написать — сложно. Поддерживать всю жизнь — заебешься.
Эта заметка написана по мотивам поста из блога компании Интерком. Я сделал перевод, чтобы повысить вероятность того, что этот текст осилит менеджер занятый пропихиванием жизненно важной фичи в релиз.
Потратил 3 недели на «Теорию Игр». Книга учит принимать стратегические решения на основе одноименной теории — раздела прикладной математики, изучающего оптимальные стратегии (см. википедию).
Книга скорее похожа на институтский учебник, чем на привычную бизнес-литературу. Авторы, видимо под влиянием преподавательского прошлого, наполнили книгу выдуманными примерами, сложными настолько, что не держатся в памяти — пока дочитаешь доказательство, забываешь, что оно доказывает, приходится возвращаться назад.
Несмотря на заумный формат и канцелярский перевод, книга бьет в цель. Уже после первых глав вы начнете обдумывать повседневные решения как ходы в шахматах — смотреть наперед и предугадывать ходы противника. Противник — не обязательно враг, это кто угодно: ваша жена или босс, клиент, компания-конкурент или вы сам в будущем.
Полиция допрашивает двух подозреваемых отдельно друг от друга. Каждому предлагают сознаться и обещают гораздо более суровый приговор, если он не успеет сознаться первым. Таким образом, каждый из заключенных считает для себя более выгодным признаться в совершении преступления, хотя обоим было бы лучше если бы они молчали.
Трумен Капоте приводит наглядный пример дилеммы заключенных в своей книге «Хладнокровное убийство». Дик Хикок и Перри Эдвард Смит арестованы за бессмысленное убийство семьи Клаттеров. Свидетелей не было, однако тюремный осведомитель назвал полиции их имена. Во время допроса полиция настроила их друг против друга. Капоте позволяет нам проникнуть в мысли Перри:
…Это, как и выдуманный «свидетель», было сказано просто для того, чтобы заставить его подергаться. Этого не может быть. Или они имеют в виду… Эх, если бы он только мог поговорить с Диком! Но их держали порознь; Дик сидел в камере на другом этаже.
…А Дик? Возможно, они и с ним провернули такой же трюк. Дик был умным убедительным актером, но стержня в нем нет, слишком легко поддается панике.
…«И прежде чем уйти из этого дома, вы убили всех, кто там был». Очень может быть, что каждому из бывших заключенных в Канзасе они поют одну и ту же песенку. Они, наверное, допросили сотни людей и многих из них обвинили в этом убийстве; мы с Диком просто еще двое таких же…
И Дик тоже не спал в своей камере ниже этажом и, как он вспоминал позже, так же жаждал поговорить с Перри — выяснить, что этот урод им рассказал.
В итоге признался сначала Дик, а затем и Перри. Такова природа этой игры.
Дилемма заключенных проецируется почти на все ситуации, где нужно принимать решения — ценовые войны, выборы, переговоры, и даже на семейные отношения.
Уверен, что про математические стратегии возможно рассказать гораздо проще, и без институтской зауми, но пока «Теория Игр» — единственная известная мне книга на русском. Если хотите почувствовать себя похмельным студентом и заодно прокачать стратегическое мышление — смело покупайте на озоне.
