Products | People | Process

⁠Часть 1. Нет, это не “просто грипп”.
Часто еще звучит, что “от гриппа умирают 500 тыс, а от коронавируса всего-то 4 тысячи, а столько шуму!”
Почему это ошибочное мнение:
3) Всякая инфекция характеризуется двумя числами - заразностью и смертельностью.
4) От заразности зависит сколько человек будет инфицировано. К примеру, грипп не очень уж заразный, и в США им в год болеют 30-50 млн человек. То есть где-то каждый 6-10й.
5) От смертельности зависит сколько умрут. Обычный грипп убивает 0.1% (одного из тысячи). Испанка убивала каждого 10го. Бубонная чума убивает 9 из 10. Грипп убивает в мире 300-700 тысяч человек в год (это основное исследование и ВОЗ пользуется тоже им).
ВОЗ оценивает смертность SARS-CoV-2 в 3.4%
6) SARS-CoV-2 сейчас считается примерно в два раза заразнее гриппа и в 34 раза смертельнее (оценки смертности разнятся и об этом ниже)
7) Таким образом, если бы SARS-CoV-2 заразил столько же людей, сколько грипп (порядка 600 миллионов человек), то в год умрут не 300-700 тыс как от гриппа, а 10-23 млн человек, что приближается к масштабам легендарной “испанки” 1918 года
8) Вся “пустая шумиха в СМИ” вызвана опасением последствий, если вирус поразит значительные массы людей
9) Это усугубляется тем, что 1% больных нужно для выживания очень серьезная поддерживающая терапия. Доступность которой ограничена. Например в США такую терапию можно предоставить примерно 1000 человек одновременно. Если тяжелых больных будет больше и сил не хватит - каждый избыточный тяжелый случай будет умирать. Отсюда есть движение FlattenTheCurve - сдержать распространение, чтобы одномоментно тяжелых больных было немного
10) https://coronainfo.xyz тут можно наглядно увидеть, что SARS-CoV-2 распространяется и убивает намного быстрее чем свиной грипп или атипичная пневмония до него. Картина ниже
11) После вспышки в Италии ощущение ложной победы уже наверное подвыветрилось, но даже ранее https://coronainfo.xyz показывал, что кажущаяся стабилизация это чисто китайский результат. Его масштаб (еще недавно больший, чем весь остальной мир) скрывал, что за пределами Китая число случаев стремительно росло

Совершенно непрофильный пост о коронавирусе. Воспринимайте его как braindump и игнорируйте

Ежедневно сталкиваюсь с двумя полярными мнениями
А. “Это просто грипп!”
Б. “Мы все умрем!”
Оба мнения считаю ошибочными (и, разумеется, получу сейчас лещей с обеих сторон)

Теперь ссылки и факты
1) вирус официально называется SARS-CoV-2 (а до того часто называли 2019-nCoV, что означало “новый коронавирус); Болезнь называется Covid-19; Просто чтобы не путаться
2) он близкий родственник прошлой атипичной пневмонии (SARS)

Далее разберем пункт А

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

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

Дело в том, что действительно часто встречается проблема культуры "у матросов нет вопросов". Спрашивать стремно, можешь показаться глупым, так что ну его нафиг. Как результат будем делать что-то не то и получим неправильный результат. Поэтому важно поддерживать культуру, где непонятное принято спрашивать.

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

И тут встает сложный выбор - на какой из двух стульев стул сесть и как быть?

1) Ни в коем случае не возвращаться к культуре "у матросов нет вопросов". Это нижний уровень пирамиды. Обсмеять вопрос или автора вопроса - и мы скатились вниз.
2) Аккуратно вернуть ответственность за ответы, которые вообще-то в компетенции вопрошающего. "А как же я буду ...? - Это твоя область. Тебе и решать. Подумай как и обсудим предложенные тобой варианты"
3) Аккуратно приучить самим разбираться с большей частью домыслов о крайних случаях. "А что если я выйду за сигаретами в июле и тут же наступит зима?". "Запиши свои вопросы и наиболее логичные ответы к ним с твоей точки зрения. Потом сверимся". Почти всегда переход к рациональному мышлению демонстрирует, что все эти вопросы не имеют особого смысла, а такие ситуации или решаются на месте или реально невероятны.
4) аккуратно приучить предполагать наиболее вероятные ответы на простые вопросы за пределами основной области компетентности. По той же схеме, что и №3. Недавно этот прием позволил одной из команд сделать фичу, не дожидаясь ответов от временно отсутствующего менеджера. Хоть у них и не было всего объема информации о стоящих требованиях, но на широкий пласт вопросов об ожиданиях пользователя можно ответить из здравого смысла и имеющегося опыта. Чем лучше люди понимают область, в которой они работают, чем легче решать вопросы за пределами своей узкой функции.

Задавать вопросы должно быть нормальным. Но одновременно должно быть нормальным сохранять ответственность за свою область, делать "домашнюю работу" и "ориентироваться на местности".

📌 тестировщики

Из тестеров получаются одни из лучших ПМов, что я встречал. Думаю, так происходит по двум причинам:

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

Ребята безукоризненно следуют принятым процессами разработки и классно делают "по книжке". Изредка это играет с ними злую шутку, когда нужно выйти за рамки, принять нестандартное решение.

Минутка славы всех ПМов, кто вышли из тестировщиков. Согласен с оценкой @pm_god (скромно - потому что я сам из "этих"!). Там есть и про ПМов иного происхождения в соседних постах

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

самая лучшая школа это имхо поддержка (впитать боль), тестирование (важность порядка) и потом ПМ

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

(вынесено из комментов)(осторожно, может подгореть)
У меня трудные отношения с Agile. С одной стороны я двумя руками за всякое эффективное "местное самоуправление", гибкость и ориентацию на результат. Так действительно проще и удобнее жить.

С другой стороны, под видом agile часто происходит откровенный хаос и бардак. Возникает дефицит анализа, продумывания, структурирования, правил и прочего "старорежимного барахла". Возникает господство "и так сойдет".

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

Но были проекты, слишком сложные и неопределенные для все продумать заранее, и одновременно умные и компетентные люди успешно преодолевали возникающую сложность. Для таких высокопрофессиональных команд и был предложен Agile Manifesto. В нем это прямо не написано, но это следует из контекста его создания.

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

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

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

Привет, совместно с @skoloskov написали заметку про базовые особенности работы с гипотезами в B2B. Тема управления продуктами за последние несколько лет сделала большой шаг вперед в России, но на продуктовых конференциях b2b-шники часто огорчаются, что "хорошо в там в b2c, у вас эксперименты, гипотезы; а как же нам? нам так нельзя". но при определенных условиях и со своей спецификой все-таки можно.

Превью заметки ниже, а полный текст по ссылке
https://telegra.ph/Osobennosti-B2B-custdev-v-SaaS-01-08

Ссылка на канал коллеги @skoloskov - https://t.me/FreshProductGo

8. Вечером понедельника совет директор Рамблера принял решение, что следует прекратить уголовное разбирательство

8.1 Технически уголовные дела по тяжким преступлениям (данный случай) не прекращаются по заявлению “я передумал”. Ущерб был оценен выше 1 млн - особо крупный, а значит максимальное наказание составляет свыше 5 лет и это тяжкое преступление. Однако, поскольку дело заводилось в отношении “неустановленного круга лиц”, то можно его закрыть процедурно по истечении сроков давности. Стоит ожидать, что "пойдут навстречу"

8.2. Одновременно в том же заявлении сказано, что Rambler от претензий не отказывается

Просуммирую несколько важных фактов о деле Rambler vs Nginx:

1. на прошлой неделе по заявлению компании, связанной с Rambler (но технически не самого Rambler) открыто уголовное дело против “неустановленного круга лиц”, которыми подразумеваются основатели Nginx Игорь Сысоев и Михаил Коновалов с претензией, что права на open source веб сервер Nginx на самом деле принадлежат Rambler, в котором Игорь Сысоев работал в 2004, когда создал Nginx link

2. по этому заявлению были задержаны (позже отпущены) сами основатели, проведен обыск, вызывали на долгую дачу показаний (10 часов) свидетелей. link

3. Из 15 лет существования Nginx, все случилось по странному стечению обстоятельств спустя 9 месяцев после покупки компании nginx компанией F5 за 670 млн долларов link. сложно поверить, что и при последней покупке и при промежуточных инвестициях юристы никак не проверяли законность обладания правами на nginx

4. В комментариях о законности этой претензии есть много утверждений происходящих от неправильного понимания как регулируется область авторских прав

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

4.2. И есть исключительные права на воспроизведение (распространение). Это то, на что Рамблер претендует

4.3. Непонимание связано с тем, что многие из нас привыкли к формулировке “в рабочее время и на оборудовании работодателя” из своих (старых) рабочих договоров - но она не соответствует требованиям закона

4.4. В современной статье 1295 ГК РФ для передачи исключительных прав работодателю требуется, чтобы произведение было “трудовой обязанностью” сотрудника и есть еще несколько формальных требований

4.5. Бывшие сотрудники Рамблера, включая Ашманова, прямо и открыто утверждали и были готовы свидетельствовать в суде, что никто не поручал и не обязывал Сысоева писать Nginx в Рамблер, и что даже давали ему некое письменное разрешение на это

4.6. В 2004м действовали другие законы: «О правовой охране программ для электронных вычислительных машин и баз данных» (1992) и закон «Об авторском праве и смежных правах» (1993), он же ЗоАП. ЗОАП требовал, чтобы служебное произведение было “в пределах установленных для работника (автора) трудовых обязанностей» или «в порядке выполнения служебных обязанностей или служебного задания». Но закон “о правовой охране” имел более слабое утверждение “в связи с выполнением трудовых обязанностей или по заданию работодателя”. Возможно, что именно на “в связи” рассчитывал Рамблер - технические поддержание работоспособности сайта как-то связано с веб сервером.

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

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

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

(в следующем посте окончание)

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

Например, провели исследование во сколько люди оценят отказ от ряда бесплатных онлайн сервисов (https://www.pnas.org/content/116/15/7250#T1).
Получилось интересно:
- Поисковики (все вместе) $17530/год
- Электронная почта (все вместе) $8414/год
- Карты (все вместе) $3648/год
- Видео (все вместе) $1173/год
- интернет магазины (все вместе) $842/год
- соцсети (все вместе) $322/год
- музыка (все вместе) $168/год
- мессенджеры (все вместе) $155/год

В Европе опрос был другой и баланс тоже другой
- WhatsApp 536 eur/месяц
- Facebook 97 eur/месяц
- Карты 59 eur/месяц
- Instagram 6.79 eur/месяц
- Snapchat 2.17 eur/месяц
- Linkedin 1.52 eur/месяц
- Skype 0.18 eur/месяц
- Twitter 0 eur/месяц

Высокая цена whatsapp объясняется тем, что он заявлен основным месседжером для связи с семьей, друзьями, одноклассниками и тп

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

3.3) если поддержка должным образом организована, то должны быть публичные или хотя бы внутренние knowledge base статьи. Простой способ устранить типичные проблемы - ликвидировать причину заглядывать в самые цитируемые/посещаемые. С одной стороны это каннибализация труда тех.поддержки, а с другой стороны - это гарантированная отдача. Низковисящий фрукт. Пробовали и имели хорошие результаты.

Что не очень работало в моей практике -

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

4.1) при аутсорсе обеспечить соблюдение этого правила сложно. Нужны постоянные проверки и контроль качества. Это дорого. А неправильно расставленные категории бесполезны

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

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

Disclaimer. Текст записан по мотивам кухонной мини-лекции коллегам, и на полноту рассмотрения не претендует.

Немного расскажу про работу с технической поддержкой - это те, прикованные к пулемету люди, которые прикрывают разработчиков от неприятных слов со стороны клиентов. И затыкают собой все дырки в customer experience.

Масштабируется техническая поддержка трудно и дорого. Неудовлетворенный клиент - это весьма вероятно потерянный клиент. Один сотрудник может обработать только фиксированное число входящих запросов. А много сотрудников это дорого. Итого: проблемный продукт делает удержание клиента дорогим.

Есть в индустрии широко известный показатель CAC = Customer Acquisition Cost, сколько стоит привлечение клиента в бизнес. Например, KupiVip рассказывал, что им привлечение клиента стоит 2000р и зарабатывать магазин начинает только после 3й покупки однажды привлеченного клиента. А есть несколько менее известная метрика CRC = Customer Retention Cost, сколько стоит удержать клиента. Вот туда надо посчитать расходы на тех. поддержку. Например, в хостинге одно обращение в поддержку в год может вывести лишить компанию дохода от этого клиента и оставить один убыток. В нашем бизнесе такое же произойдет для самых маленьких и дешевых клиентов. Поэтому мы боремся за низкое число инцидентов в поддержке даже исходя из чисто экономических соображений, а не только из любви к клиентам.

Что можно сделать для снижения числа инцидентов? Из очевидного, что можно сделать заранее:

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

> Заходит однажды тестировщик в бар.
> и заказывает:
> кружку пива,
> 2 кружки пива,
> 0 кружек пива,
> 999999999 кружек пива,
> ...
> После всего этого в бар заходит первый реальный пользователь и спрашивает, где тут туалет. Бар взрывается.

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

Что можно сделать после (продукт уже вышел)?

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

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

Почему не всегда легко узнать о типовых простых проблемах? Если поддержка передана в аутсорс, то аутсорс часто оплачивается за объем. Или за объем и скорость решения. Как легче всего набить объем? На массовом решении инцидентов с типовым известным рецептом. Никакого интереса сообщать о таких инцидентах в разработку аутсорсер не испытывает. Но это не обязательно проблема корыстного интереса. Даже бескорыстный человек не запоминает то, что не было для него проблемой. Вы не помните в каком порядке чистили зубы и какой ботинок застегнули первым. А применить легкое известное решение это не проблема. С какой стороны подступиться?

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

3.2) взять выборку в 100-500 входящих инцидентов и поискать повторы в причинах. Кажется страшным, но это вполне реально сделать.

Очень интересно следить за достижениями на стыке технологий и нейронаук. Прогресс местами пугающий

https://medium.com/@bilb02/adversarial-examples-attacks-against-natural-neural-networks-524b654450e2
Существует способ незаметно для человеческого глаза изменить изображение так, что ИИ ее классифицирует совсем иначе. Например, исследователи обманули ИИ Теслы несколькими наклейками на дорогу и направили его на встречку. НО оказалось, что и человека можно также незаметно обмануть. Тест довольно синтетический - людям давали выбрать между двумя картинками, и ИИ смог незаметными глазу изменениями изменить статистическое распределение в человеческом выборе.

https://www.roadtovr.com/researchers-exploit-natural-quirk-of-human-vision-saccade-hidden-redirected-walking-vr-gtc-2018/amp/
Человеческий глаз смотрит прерывисто (называется “саккады”). И если в момент прерывания картинку сместить, то мозг автоматически и неосознанно подстраивается как будто так было всегда. VRщики придумали пододвигать картинку в эти прерывания и тем менять незаметно для человека его направление движения. Можно в итоге гонять человека по небольшой комнате в полной уверенности, что он идет долго и прямо. Более того, есть видео, где по небольшой комнате гоняют несколько человек, там стоят разные препятствия. А люди ни о соседях, ни о препятствиях не догадываются. Практическое применение само очевидно - для симуляции бесконечных миров в конечных площадках

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

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

Ну и все уже наверное знают, что в Amazon формат презентаций для запрещен c 2004, и надо всегда писать текстом. Каждый год про это пишут как новость, но это 15 лет уже не новость.

Тем не менее, всякий инструмент это только инструмент.

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

Если план или предложение выглядит пустышкой и банальщиной как слайды, то в форме текста он ... вобщем-то тоже будет пустышкой и банальщиной. НО на осознание этого уйдет больше времени - поскольку читать текст будет в 3-6 раз дольше. На слайд норм тратить 5-10 сек. На страницу текста - уже 30-60 сек. Выигрыш в чтении.

Слайды это не зло само по себе, зло это не умение ясно выражать свою мысль

Обычно я не пишу про новости, но тут уж очень хороший повод
Компания Grammarly достигла оценки в $1 млрд, что дает ей статус "единорога"

Я сам пользуюсь grammarly уже год и очень ее рекомендую тем, кому английский по работе нужен (клиенты, заказчики, коллеги и тп), кто его учил-учил, но не доучил. Grammarly интегрируется с браузером, с текстовыми редакторами, и тп - и предлагает вам более правильный текст. В каком-то смысле это робот - частный учитель. Подсказки довольно разумные. Следуя этим правкам, постепенно приучаешься писать лучше, писать правильнее.

Почему это важно:
1) каждый ESL (English as a Second Language) притаскивает в английский гору шаблонов родного языка, которые в английском жутко неправильны
2) есть "эффект Джумшута" - человек, который говорит неправильно, воспринимается второсортным, умственно ущербным. мы смеемся и смотрим сверху вниз на гастарбайтеров с их "начальника..." не в последнюю очередь из-за их языка. и теперь на секунду подумайте, как воспринимается ваша собственная речь и насколько это поможет вашей работе
3) даже без №2, неграмотная фраза затрудняет понимание. какая бы умная мысль не была в голове, что бы умного мы не хотели сказать, все это резко обесценивается тем, что вас просто не понимают.

Вобщем, очень рекомендую

https://vc.ru/finance/87511-it-kompaniya-s-ukrainskimi-kornyami-grammarly-privlekla-90-mln-pri-ocenke-vyshe-1-mlrd?fbclid=IwAR2WCapNvkyN_u3JrBEfyQ4MY8T9KKveNbdqmjzrO9PWhD2goaoCsoQsHg0

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

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

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

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

Ни в одном случае мы не упарывались с формальными нотациями типа BPMN, UML и другими. Для ясности хватало просто обозначить блоки, их группировку и связи между ними.

Продолжительное время внедрению диаграмм в оборот препятствовало отсутствие инструмента. Word'ом мы для внутренней документации давно не пользуемся, а в wiki-подобных онлайн системах диаграмма обычно импортировалось как скриншот из другой системы - то есть править ее мог только автор, что сильно ограничивает обычные сценарии совместной работы на требованиями и дизайном. Вначале это решали плагином для draw.io. Сейчас чаша весов начинает склоняться в пользу Miro (которые Realtime Board)

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

Мой совет - чертите!

​​А давайте еще раз проиллюстрирую про вред многозначности на пальцах

Я обустраиваю себе дачу за городом и это очень много работы. А если точнее, то это очень много всяких разных работ. Каждая из работ требует массы материалов и инструментов. И замыслов вагон и все хочется успеть. Знаете что меня сильнее всего тормозит? Меня тормозит именно этот вагон.

Типовая ситуация:
- Ох, какая у меня классная новая идея возникла! Привезу-ка я под нее инструмент, материалы и начну… нет, не начну. Я же еще прошлое дело не закончил и мне нету места начать новое дело. Давай-ка я закончу старое… ох, но для этого надо вначале убрать все незаконченное новое…замкнутый круг

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

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

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

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

Надеюсь, мой анти-пример позволит вам действовать лучше

О важности usability. Помните смешной случай, когда на Гаваях объявили ракетную тревогу по ошибке? Потом говорили, что в интерфейсе было легко перепутать учебную тревогу и реальную. Или пару лет назад эсминец Джон Маккейн протаранил танкер, погибли 10 человек и были ранены 58. Оказалось, что новые сенсорные пульты управления были не до конца понятны экипажу и оператор перепутал полный ход обоими двигателями с полным ходом только одной стороной - в итоге эсминец резко развернуло. И теперь ВМФ США хочет вернуться к старым добрым механическим крутилкам-вертелкам от всего этого дижитала.

Вынужден признать, что digital интерфейсы оказываются очень неудобны. Приведу пачку примеров (картинка ниже). На старом водонагревателе я мог сменить температуру нагрева одним движением. На новом я должен нажимать и держать кнопки больше/меньше. Ладно, водонагреватель редко трогать надо. Возьмем новую микроволновку. Раньше я в два движения горил "греть сильно в течении 5 минут". Теперь надо долго ее "программировать" цифрами. Совсем плохо с чайником. Там не всегда нужно кипятить воду, часто ее надо просто подогреть. И раньше я это делал в одно движение, а теперь там 4 кнопки, с кучей режимов, я должен их нажать и держать пока там что-то на экране не появится. Но самое веселое, что впервые я с адом этого тренда столкнулся 20 лет на военном устройстве. У старого была очень удобная двойная крутилка - ладонью крутишь для большого изменения, а пальцем одновременно подкручиваешь тонкую настройку. Одно тактильное удовольствие. Но отечественное радио-конструкторы выпустили цифровой прибор, где вместо комфортного лампового кручения влево-вправо (секунды) я должен непрерывно набирать на тумблерах 0001, 0002, ..., 9999 - понимаете сколько времени и сил уходило?

Давайте еще анти-примеров "ux прогресса" приведу. В одном продукте, чтобы пользователь лучше понимал, что он вводит IP адрес, его разбили на 4 поля. Тренд такой был в начале 2000х. Но НИКТО не вводит IP адреса из головы - все их копируют откуда-то. И вот копировать в 4 отдельных поля пользователям стало намного сложнее. аналогично решили постпить с телефонами. Пройдет свыше 10 лет прежде чем индустрия обратно научится представлять телефоны и IP адреса нормально.

В одном продукте виновен был и я сам. В нем список сущностей был представлен большой text area. Дописываешь туда новое - оно создается. Стираешь одну из строк - оно удаляется. Это же не профессионально, решили мы. И переделали на табличный список с кнопками "создать" и "удалить". Конечно же, на нас потом ругались, потому что было очень удобно раньше делать copy-paste из письма пользователя, и стало совершенно невозможно потом. Примитивная text area как раз вполне удовлетворяла идеалам Джефа Раскина, что интерфейс должен быть текстом.

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