Возвращаясь к вопросу о метриках - на этот раз о продуктовых метриках. Можно иметь сотни графиков (и у нас есть), но они никого не сделают счастливым, если не дают простых ответов. А вопрос стоит только один - улучшило ли изменение продукт?

Что значит "улучшило"? Пойдем от обратного. Если мы сделали новую фичу и видим, что ей пользуются - стал ли продукт лучше? Вообще не факт. Мы видим только то, что фичей пользуются. Если в коридоре поставить дверь, то ее будут открывать и закрывать 100% пользователей, но стал ли коридор от этого лучше - мы не знаем.

"Лучше" определяется только через влияние на показатели продукта в целом. 1го порядка - выручка / аудитория / вовлеченность. 2го порядка - приток клиентов, текучка клиентов, средний чек, время жизни пользователя, удовлетворенность и тп. Можно строить 3й и более дальние порядки - нужно только в любой момент понимать, как дальняя метрика влияет обратно на более первичные. Чем чаще ходят в магазин - тем больше выручка, хорошо.

Соответственно, для построения метрики нужна гипотеза - что именно изменится и как. Но изменения тоже есть разных порядков. Скажем, у нас продукт и так растет на 1000 пользователей в месяц. Если мы что-то сделали и получили +1000 пользователей за месяц - то мы что-то улучшили? Нет, потому что это продолжение старой динамики. Значит надо смотреть на производную (в математическом смысле) - на ускорение прироста.

То есть, нужно выбрать метрику продукта в целом (1), понять ее текущий тренд(2) и предположить изменение следующего порядка (3). Для констант - абсолютный прирост. Для растущих показателей - ускорение роста. И т.д.

Это разумеется, касается, только задач развития продукта.  Если они не могут ничего изменить, то никакого развития не происходит. Может быть это был неверный шаг, а может быть уже нет и потенциала для развития - уперлись в стену, такое тоже бывает

В отношении "долгов" решается задача удержания - то есть предотвращения риска, что какая-то метрика вдруг ухудшится. Но измерить это наверное никак нельзя, кроме булевского "проблема случилась" или "не случилась"

Рубцовая ткань. Что это такое?  У нас один из партнеров написал скрипт, доводящий наш продукт “до ума” в недружелюбной для продукта среде. Видимо, в какой-то момент этот скрипт передавался от одного админа к другому и второй оставлял свои примечания, в основном в духе “WTF?!”. Там правда было очень много жутких и страшных извращенных приемов программирования. Но веселее всего то, что во многих местах продукт уже давно не требовалось допиливать скриптом, он давно уже научился сам нормально решать неприятные ситуации, а админ за админом продолжали поддерживать эту обвязку. Исправления в продукте вызывали поломку этой обвязки, и эти поломки чинились еще более жуткими обвязками, но все эти многие слои обвязок были НЕ НУЖНЫ, потому что в ее сердцевине уже давно не было проблемы. Это наиболее яркая иллюстрация того, что я называю РУБЦОВАЯ ТКАНЬ.   Это код, это обходные решения, построенные из-за невозможности решить суть проблемы. Хуже всего, что со временем суть проблемы вообще забывается и эта рубцовая ткань может стать вполне самостоятельным “организмом”, высасывающим силы из команды.  Рубцовая ткань это не всегда код. Это может быть процесс, или шаблоны поведения в команде. Сложившиеся когда-то давно под воздействием каких-то обстоятельств, которые уже могли давно пропасть, а рубец остался. Наилучшая иллюстрация это анекдот про “здесь так принято”
Клетка. В ней 5 обезьян. К потолку подвязана связка бананов. Под ними лестница.
Проголодавшись, одна из обезьян подошла к лестнице с явными намерениями достать банан. Как только она дотронулась до лестницы, вы открываете кран и из шланга поливаете ВСЕХ обезьян очень холодной водой. Проходит немного времени, и другая обезьяна пытается полакомитЬся бананом. Те же действия с вашей стороны. Третья обезьяна, одурев от голода, пытается достать банан, но остальные хватают ее, не желая холодного душа.

А теперь уберите одну обезьяну из клетки и замените ее новой обезьяной.
Она сразу же, заметив бананы, пытается их достать. К своему ужасу, она увидела злые морды остальных обезьян, атакующих ее.
После третьей попытки она поняла, что достать банан ей не удастся. Теперь уберите из клетки еще одну из первоначальных пяти обезьян и запустите туда новенькую. Как только она попыталась достать банан, все обезьяны дружно атаковали ее, причем та, которую заменили первой еще и с энтузиазмом.
И так, постепенно заменяя всех обезьян, вы придете к ситуации, когда в клетке окажутся 5 обезьян, которых водой вообще не поливали, но которые не позволят никому достать банан. Почему?

Потому что тут так принято...   И в коде, и в поведении убирать рубцовую ткань очень сложно, потому что в первую очередь нужно понять, что она рубцовая. Ведь она живая, люди работают, шестеренки крутятся. Просто она грубая и не гибкая. Но убирать надо, для чего надо приучаться смотреть все время в корень проблем

Сегодня напишу короткое про ПЛАНЫ. Нужни ли они и зачем?

Мало кто любит планы:
- во-первых, планы никогда не сбываются. Писал-писал, а вышло все по другому.
- во-вторых, классическая шутка про спросим у них оценку и выдадим ее за план - планы начинают восприниматься как commitment'ы и никто их делать, разумеется, не хочет

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

Я думаю, надо изменить свое отношение к плану. Откройте навигатор в машине, он построит вам маршрут. Вы по нему поедете. Что дальше? А дальше - сюрприз! - маршрут меняется. Вы едете быстрее или медленнее, поворачиваете не туда, встречаете пробки или навигатор собирает данные о пробках из других источников и маршрут меняется. У вас в любую минуту есть план (маршрут) и он в любую минуту может быть новый.

Маршрут от этих изменений не стал хуже, не стал чем-то эфемерным и уж точно не стал менее нужным. Точно также надо быть с планами
Некоторые пишут "план МОЖЕТ меняться, но план ДОЛЖЕН быть" - уточним, что план и ДОЛЖЕН ПОСТОЯННО МЕНЯТЬСЯ, чтобы оставаться АКТУАЛЬНЫМ. Именно жесткий план это ложный и эфемерный план. А постоянно меняющийся план как раз очень реален (покуда мы едем в тоже самое место).

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

потребителю плана (мне в частности) надо отказаться от идеи трясти людей за соблюдение сроков каждого этапа (слишком много переменных), а только трясти
1) за соблюдение фокуса (мы едем именно туда, куда хотим, а не катаем левый груз)
2) за поддержание плана в актуальном виде (не живем в мире иллюзий)

Новость дня. Hipchat - все. Slack выкупил его у Атлассиан и закроет.

Получается, что не всегда иметь в портфеле полный вертикальный стек решений - это путь к успеху. Через социальный фактор + открытые интеграции Слак смог объехать собственное интегрированное решение Атлассиан и сделать его бесперспективным. Походу Атлассиан дряхлеет и теряет хватку

https://techcrunch.com/2018/07/26/atlassians-hipchat-and-stride-to-be-discontinued-with-slack-buying-up-the-ip/

Предыдущий пост про сбер был по ошибке снесен. Если у кого-то сохранилось, то закиньте плз мне - верну в ленту

Итак, рукописи не горят, а вот сообщение в телеграм отлично удаляется по ошибке. Давно я ничего не писал, а теперь напишу два раза подряд одно и тоже.  

С мест поступают множественные сообщения, что Сбербанк переводит своих сотрудников из СберТеха в непосредственно бизнес-подраздления. То есть если человек работал над автоматизацией бухгалтерии, то его начальником и будет главный бухгалтер? Хорошо это или плохо?

Очень давно стоит проблема - кто должен руководить человеком?
Тот, кому его работа больше все нужна (заказчик)?
Или тот, кто можем им правильно управлять в профессиональном плане (супервизор)?

Как эффективнее распределить людей?
Раздать по местам конкретной работы?
Или собрать в единый "кулак"?

Первыми, и больше прочих, с этой проблемой столкнулись военные. Раздать танки по отдельным частям или собрать в танковый корпус? Кому должна подчиняться авиация ПВО - ПВО как заказчику или ВВС как специалисту по авиации?

В какой-то момент корпорации пришли к консенсусу матричного управления. Каждый входит одновременно в две группы. Горизонтально - в отдел специалистов данного типа. Например - разработчики. Под командой "линейного менеджера". И вертикально - специалисты разного титпа входят в какой-то проект. Под командой "проектного менеджера". Более-менее хорошо работало для больших организаций и сейчас, как я понимаю, работает в аутсорсовых компаниях типа ЕПАМ или Люксофт.

В какой-то момент индустрия столкнулась с тем, что стало непонятно что надо делать дальше и ответила на этот вызов аджайлом. Вместо штабов, продумывающих планы на будущее, и огромных команд иерархично это исполняющих, появились множественные независимые микрокоманды, каждая отвеччающая за свое направление. Аджайл. Историй таких трансформаций и переходу к продуктовым командам очень много на конференциях. Фокус на командах привел к значительному перевесу вертикальной связи. Это компенсировали "гильдиями" - связью специалистов одного типа между командами.

Но при любой форме организации ИТ - обычно сам ИТ в организации оставался единым в силу своей особости.

Впервые про распил ИТ на части я услышал от Wildberries. У них была проблема донесения нужд бизнеса до ИТ, создать класс аналитиком/менеджеров для решения этих задач у них не вышло. Тогда они распределили инженеров по бизнес-отделам и возрадовались. Ценой этого было некоторое увеличение числа инженеров (потому что статическое распределение по задачам менее эффективно по ресурсам, чем динамическое) и некоторая утрата качества управления. Дело в том, что главный бухгалтер и остальные "обычные" бизнес-отделы слабо понимают ИТ-специфику со специфичным планированием и необходимостью как-то помнить про технический долг.  Им надо здесь и сейчас. Лидер разработчиков может недолюбливать аналитиков/менеджеров за разногласия между их хотелками и своим перфекционизмом, за неточность и сумбурность передачи бизнес-трембований. Но без них легко обнаружить, что бизнес еще более безкомпромисен, чем аналитики, еще более игнорирует технический долг и прочие неосязаемые понятия, еще более противоречив и сумбурен. То есть искажения от слоя аналитиков/менеджеров пропадают, но пропадает и привносимое ими сглаживание. Вертикальная связь заказчик-исполнитель становится короткая и жесткая. А горизонтальная связь исполнителей между собой сильно размывается, может даже стать совсем неформальной.

Именно это сейчас происходит со СберБанком. Само  по себе это не хорошо и не плохо - это как два типа подвески, мягкая и жесткая. Но на жесткой подвеске по неровной дороге кататься будет некомфортно.

Про инновации

Я последнее время на собеседованиях встречал много людей, который беспокоил застой в их компаниях, тогда как эти компании декларируют на публику высочайшую инновационность. У меня самого был такой период в работе, когда контора декларировала агрессивную гонку за инновациями, но при этом оказалось, что за период «гонки» мы прилично отстали в ряде областей. Как так могло получиться?

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

Но что если у нас классическая top down контора с агрессивными целями? Все для фронта, все для победы. Значит, вся деятельность подчинена этим целям. Значит, все, что не ради их достижения - это плохо. Отсюда последствие первого порядка - это нетерпимость к ошибкам. ошибка это потеря. А если нельзя ошибаться, то резко сокращается пространство для экспериментов. На запланированные эксперименты воля ещё остаётся. «Верхи» могут агрессивно инвестировать в какой-то запланированный сверху экспериментальный проект . А вот сумбурный эксперимент снизу, «на попробовать» пропадает. Всякая гипотеза может дать два ответа, но в этой среде ответ «не получилось» уже не приемлем. «Не получилось» будет понят как «плохо старался». Поэтому лучше не рисковать. Снижение числа таких сумбурных экспериментов неизбежно отсекает какие-то потенциально выгодные пути, поскольку не распробовав не оценишь

Из «плохо старался» происходит последствие второго порядка - неприятие возражений. Кто-то «сверху» уже подписался под будущим результатом и не готов признавать, что получилось не очень. Люди осознанно применяют заведомо неэффективный инструмент. «Низы» все понимают. «Середина» тоже. Но наверх шлются победные сводки, иначе «подстава», которую не простят. Общая эффективность операций ползёт вниз

Из принятия плохого за хорошее идёт последствие третьего порядка - двоемыслие. Все всё понимают, но говорить вслух нельзя. Между собой ещё можно, но официально - нет. Только иногда. Кому-то. В подходящем контексте. Например, подготовить практически спектакль с гипер-наглядной демонстрацией проблем на встрече, проходящей раз в год - чтобы показать непригодность одного такого проекта. Это требует таких значительных вложений, что в системе проходят только небольшое число сверхсильных сигналов. Это как голова, которая слепа и глуха ко всему извне и только живет в мире собственных идей.

Эти идеи могут быть очень инновационными, но ход их реализации уже таким не будет.

Как мы сами пытаемся вырваться из этой ловушки, когда гонка за «инновацией сверху» убивает «инновацию снизу» (что потом убьёт и «инновацию сверху» тоже)?
Не факт, что этого достаточно, но
- Выделяем время на эксперименты «просто так». Иногда технологию надо пробовать, даже если на неё нет бизнес-потребности. Потому что технология может внезапно создать бизнес-возможности, который заранее видны не были.
- Выделяем время на тех.долг. Мы чистим зубы каждое утро не дожидаясь кариеса. Так и здесь не надо ждать, когда этот долг начнёт стрелять на уровне бизнеса.
- Стараемся внимательно слушать, если люди говорят, что есть проблема
- Ещё не регулярно, но уже часто спрашиваем, есть ли проблемы, которые почему-то не решаются

Про японское “да”

В учебнике японского языка отмечено, что японское «да» («хай») отражает не столько согласие с вашими словами, сколько то, что собеседник вас слышит и признает ваше право на высказанное мнение

Но и в русском языке есть «японское да» и с ним надо быть осторожным. Вот вы увлечённый человек и что-то пытаетесь донести собеседнику, а он кивает и поддакивает. Вы выходите с убеждением, что собеседник вас понимает, поддерживает и мысль оценил положительно. А потом - сюрприз! - он делает что-то прямо поперёк.

Где с этим можно столкнуться?

Наивный продакт менеджер рассказывает идею клиенту, а тот поддакивает. «Клиентам наша фича нравится!» делается вывод, а они не покупают потом.

Руководитель команды доносит до сотрудника его оценку и перспективы, тот кивает. Руководитель полагает, что есть взаимопонимание, а потом сотрудник уходит - он себя оценивал иначе и перспективы видел и искал другие.

В продажах или bizdev у меня нет личного опыта, но со стороны наблюдателя  проблема выглядит так же. Очень легко принять свою убежденность за свою убедительность.

Что можно сделать?

Самое простое упражнение на проверку понимания и взаимопонимания - это когда говорит второй собеседник.

Например, в отношениях с пользователями custdev учит спрашивать об объеме вложений в решение этой проблемы текущими средствами - это выводит вопрос из гипотетической плоскости. Если люди что-то пытаются сделать с проблемой, то этим практически подтверждают интерес.

В отношении сотрудников ситуация осложняется тем, что проблема не очевидна. Про неё ещё не так много говорят, как про пользователей. Поэтому первый шаг - это проблему показать. Мы делали специальный анонимный опрос на всех сотрудников и это показало, сколько человек на самом деле оценивают ситуацию не так, как полагал их лидер. После этого лидеры команд постепенно научатся больше слушать и прислушиваться.

У Sales есть в частности практика уточнять KPI покупателя в организации, чтобы понимать, что предлагаемое решение действительно выгодно для покупателя. Если нет выгоды, то нет и реального интереса. bizdev это почти как sales в этом смысле.

Вобщем, переспрашивайте.

Оказывается, существуют исследования о эффективности переработок, которые в разное время проводили такие титаны индустрии как Proctor&Gamble,  Bureau of Labour Statistics of the U.S. Army Department o

Оказывается, существуют исследования о эффективности переработок, которые в разное время проводили такие титаны индустрии как Proctor&Gamble,  Bureau of Labour Statistics of the U.S. Army Department of Labor,  American Association of Cost Engineers, Construction Industry Institute, The National Electrical Contractors Association. Несмотря на всю заинтересованность в выжимке соков из трудящихся, исследования показали падение эффективности работы по мере превышения стандартной 40-часовой рабочей недели.
Хотя абсолютные показатели существенно отличаются между исследованиями, а в некоторых даже были примеры, когда удлиненная неделя не приводила к падению производительности, но в большинстве случаев видно, что уже даже 50 часовая неделя существенно снижает отдачу (92% и ниже). Наиболее интересны графики, построенные на основе данных Proctor&Gamble (на картинке), где оценивается не просто падение производительности, а комплексный вклад от <все потраченные часы> * <производительность> c поправкой на длящийся эффект (сколько недель уже продолжается overtime). Здесь мы видим, что уже на 6й неделе труда по 50 часов отдача от дополнительных часов полностью исчезает и дальше уже начинается сплошной вред (то есть дополнительный час не только не дает прибавки, но и наносит вред). Там, к сожалению, не рассмотрен вопрос восстановления до 100% эффективности после отмены сверхурочной работы. По моему личному опыту, 12 недель  работы по 80 часов приводят к последующим 6 неделям эффективности чуть выше нуля. В смысле, что на почту человек отвечает и простые фиксы делать может.
По этой причине я не поощряю сверхурочную работу у нас.
https://revay.com/revayreports/en/vol20no3.php

На неделе громко прогремела новость про утечку исходников Аэрофлотовских сервисов по небрежности (просто доступ не закрыли) - https://habr.com/post/424625/

Это породило довольно много тредов со стебом всего, что можно - от Аэрофлота в частности, до докера и девопса вообще. Я тем временем поучаствовал в немного более полезном практическом треде, где народ каялся в собственных подобных косяках. Реальность такова, что сколько бы "матерые админы" не стебали "любителей докера", а уязвимости есть у всех, и даже у Cisco.

Компании делятся не на "с уязвимостями" и "без", а на тех, кто узнает про свои уязвимости вперед новостей и тех, кто после.

Есть практика, которая помогает быть первым - это наладить работу с внешними "белыми хакерами". Это могут быть как выделенные пен-тестеры, так и "bug bounty". Bug Bounty это когда вы готовы платить за сообщения о своих уязвимостях. Есть довольно много народу, кто этим промышляет.

Чтобы bug bounty заработал, надо
1) завести у себя людей, которые им будут заниматься
2) объявить если не условия (мы публично условия не объявляли), то хотя бы канал, куда можно с этим обращаться - например security@abc.tld
3) научиться пользоваться стандартной CVSS шкалой уязвимости и прикинуть сколько вы готовы платить за взломы разного уровня
4) научиться платить людям (для россиян с нашими бухгалтерскими заморочками это вообще настолько не тривиально - что по честному наверное даже невозможно)

Сейчас мы получаем несколько подобных репортов в неделю и потому не становимся героями новостей

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

Поговорить про уязвимости можно тут https://t.me/joinchat/B-bfYQrvBssyBCf4D2YjhQ

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

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

Или вот свежий пример, упорядоченный по убыванию прогрессивности и возрастанию времени игры одновременно:
- в Китае рынок мобильных платежей вырос в 15 раз за 2 года (!) и достиг 15 млрд долларов
- в России при этом население в основном пользуется переводами с карты на карту и терминалами оплаты (qiwi наше национаольное достояние)
- в Германии основной инструмент это банковские переводы (direct debit)
- а в США до сих пор в ходу бумажные чеки

Кто позже всех начал, тот дальше всех ушел.

В тексте выше был замечен косячок - в реальности рынок мобильных платежей в Китае не миллиарды, а триллионы. Тысячекратненько ошибся

Хотел бы поделиться одной довольно хорошо работающей у нас практикой.

Вот ездят в компании сотрудники на конференции, слушают, мотают на ус... а дальше? Если на конференции окажется "лицо, принимающее решения", да прямо на нужной сессии, да услышит какой-то полезный рецепт - то все хорошо. Но конференции сейчас большие, многопоточные, самих конференций много, всем везде не успеть.

Поэтому применяем простую практику - ретроспектива конференции. После поездки надо заполнить простую таблицу - какой доклад | какая оценка полезности | чем интересен | что хотелось бы применить; Таблицу потом обсуждаем, чтобы дополнить упущенное

Теперь польза:
1) участники выделяют и формулируют главное в услышанном. это очень важный этап в усвоении объемной информации, но мало кто достаточно дисциплинирован чтобы делать это самостоятельно
2) участники обсуждают свои оценки полезности доклада. это вскрывает разность взглядов, создает поле для дискуссии и расширения кругозора
3) не-участники видят какие доклады были наиболее полезны и чем, и могут выбрать какие доклады стоит посмотреть, как только появятся записи (а записи докладов выкладывать сейчас общепринято)
4) отдельное выделение "что хотелось бы применить" позволяет возвращаться к итогам конференции позже и оценивать, а не свалились ли мы в пассивное слушание, когда все всё понимают, но никто ничего не делает

поспорить за пользу/бесполезность конференций можно тут https://t.me/joinchat/B-bfYQrvBssyBCf4D2YjhQ

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

Такие интервью интересны возможностью как-то "сверить часы" с  общим трендом. Из интересных мыслей:
1) поощряйте "соревнование" между продукт менеджером и дизайнером. каждый должен пытаться сделать лучше, бросая некоторый вызов второй стороне.

У нас принцип такой "соревновательности" между сторонами тоже является основопологающим. Это не всегда находит понимание. К примеру, когда мы хотели научить стороны лучше и конструктивнее спорить, один известный тренер сказал, что надо не учить людей спорить, а определить им всем такие полномочия и зоны ответственности, чтобы спорить было не о чем. Иванов сказал, Петров сделал. Пришлось отказаться от его услуг.

2) в дизайне нет места догмам. все правила работают в каких-то ситуацих, и вредны в каких-то других

Думаю, это не только в дизайне так.

3) все время следите за своим пониманием зачем что-то делается, чтобы не завязнуть в ненужных деталях и вернуться к реальности.

У нас в ходу с легкой руки одного менеджера вопрос "Чтобы ЧТО?". Сам факт, что прозвучал такой вопрос, это сигнал проснуться и вернуться в реальность

4) метрики и их оптимизация склонны загонять дизайн в зону локальных минимумов, когда нельзя улучшить ситуацию без того, чтобы ее временно не ухудшить. поэтому метрики-метриками, а иногда требуются воля и вера.

Интересный пример, что дизайн команда в яндексе обходила правила метрик тем, что накапливала запас невнедренных улучшений, который применяли совместно с резким поворотом и тем его "подслащивали" - компенсировали провал от резкого изменения. Видимо, воли и веры не хватало.

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

Горский приводит примеры Амазона и Букинга, которые метрически заоптимизированы до упора, но выглядят ужасно. Но работают и генерируют гору денег. Но выглядят ужасно. Трудный выбор

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

https://www.youtube.com/watch?v=kZz8dJwmH48&index=4&list=WL&t=0s

И как обычно - если кто-то хочет высказаться за Горского, то в чатике https://t.me/joinchat/B-bfYQrvBssyBCf4D2YjhQ

Хорошая статья про разработку CLI интерфейсов.

UX в UI уделяется очень много внимания, но в силу специфики нашего продукта (техническая вещь для инженеров) в какой-то момент мы даже ставили лозунгом, что CLI (и API) также важен, как UI. Не могу похвастаться, что мы достигли небывалых высот, но мы стараемся.

https://medium.com/@jdxcode/12-factor-cli-apps-dd3c227a0e46

​​Закрытие Google+ иллюстрирует подход к решению ситуаций типа «нести тяжело, а бросить жалко».

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

У нас тоже есть древняя система (магазин подписок), из которого небольшая часть пользователей так и не ушли, какие-то небольшие деньги они продолжали приносить (не лишнее же), сил она не потребляла особо, но сама система была сплошным риском, который нас беспокоил. Устранять риски дорого и чинить их, когда случатся, тоже дорого.

В итоге пришли к соломонову решению под названием «план эвакуации при пожаре». Решили ничего не предотвращать, не улучшать и даже не чинить, а просто стричь купоны до часа Х. Пока не бомбанет. Как только бомбанет, должны были распечатать заготовленный «ПЛАН ЭВАКУАЦИИ». Где заранее расписано, что делать по шагам. Но восстановления в этих шагах нет, есть отправка пользователей в новую систему.

Планом, правда, в чистом виде воспользоваться не пришлось. Не бомбануло, но в итоге всё-таки приняли «политическое» решение о сворачивании сервиса.