Единицы смысла

Больше десяти лет назад Артемий Лебедев писал про единицы смысла как показатель продуктивности дизайнера:

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

Кажется, такой показатель применим не только к дизайну:

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

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

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

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

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

@startwithease

Ваша команда сильнее, чем вы думаете

Сегодня обсуждали с коллегами гипотезу, которая может помочь повысить продуктивность команды разработки больше, чем в четыре раза. Если делать все правильно 😉

Гипотеза очень простая:

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

Сотрудник может сообщить о фишинговом сайте в один клик через браузерный плагин

2. У разработчиков больше половины рабочего времени может уходить на исправление багов — ошибок в продукте, когда он работает некорректно.

Баги — это отдельный тип задач. Их заводит команда контроля качества.

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

Не работает браузерный плагин

4. При такой формулировке возникает несколько нежелательных эффектов, которые снижают мотивацию и производительность команд разработки:

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

Да, где-то в глубине описания может найтись целевое, правильное поведение системы. Но туда еще нужно добраться.

— Из-за этого возникает эффект фрейминга, а также эффект Что видишь, то и есть, которые изучали Канеман и Тверски. По такому же принципу работает пропаганда и новости.

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

— Каждый баг в подобной формулировке осознается как опыт негативного взаимодействия внутри команды.

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

В результате у команды пропадает креативность, нарушается работа в потоке и снижается продуктивность.

Можно ли это исправить?

Да, и очень просто:

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

Браузерный плагин корректно устанавливается и работает в Яндекс Браузере последней версии

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

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

3. Позитивно настроенные команды начинают работать в 4.5 раза более эффективно.

Начните с простого: ставьте задачи правильно.

@startwithease

В тему:

ТРИЗ: сформулировать ИКР — идеальный конечный результат, — как первый шаг для решения изобретательской задачи.

Позитивное подкрепление как ключ к воспитанию животных, людей и самого себя.

Ясный образ целевого результата как первый пункт успешных изменений.

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

Я никогда не присоединюсь к движению против войны. Позовите меня, когда появится движение за мир

— Мать Тереза

Качественный продукт

За последние полгода мы с продуктовыми командами прошли тренинг Вани Замесина — и теперь учимся применять подходы и инструменты Advanced Jobs To Be Done в работе.

Что значит — применять в работе?

Например, делать правильные выводы из разговора с клиентом, которые помогут повысить качество и ценность продукта.
Клиент — крупная компания, больше 10 тысяч сотрудников, использует сразу два наших продукта.

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

Ехать можно, но какой шанс приехать туда, куда тебе (и клиенту) надо?

2. Разберись и опиши всю последовательность работ. Начни с самых первых по процессу.

3. Если у клиента проблемы в первых работах — решай их как можно раньше, все силы направь туда. Иначе продукт не доставит ценности, какие бы классные фичи ни были в продукте — до них просто не дойдут.

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

5. Мелкие баги выглядят ерундой для разработки, но не для клиента — потому что Job Security. Для вас — очередной баг, а меня и уволить могут, ага. Мелочей не бывает.

Качество продукта, как рыба — может быть только первой свежести.

@startwithease

PS. Если вы — программист или QA-инженер и вам кажется, что баги на проде у клиента — это нормально и так бывает у всех, почитайте про опыт своих коллег сорокалетней давности и подумайте, что можно улучшить в своей работе?

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

— Отчет ПРЕЗИДЕНТСКОЙ КОМИССИИ по катастрофе космического корабля “Челленджер” — Том 2: Приложение F — Личные наблюдения относительно надежности системы "Шаттл" Р. П. Фейнман

Как мы меняем мир. Часть 2.

Это серия постов — про главные мысли и идеи из книги Стефана Кляйна Как мы меняем мир. История развития человеческого разума через творчество, воображение, содружество и обмен идеями.

Начало:
Как мы меняем мир. Часть 1

Глава 3 — Коллективный мозг

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

Комбинирование — самая простая формат творчества.

Стив Джобс: «Творчество — просто в соединении вещей».
Что будет, если подключить цифровых помощников к компьютеру и позволить реагировать на нажатие пальца?

Интеллектуальный арбитраж — перенос известной связи в новую область (яблоко и земля = про планеты и Солнце, стоимость опционов = формула, по которой печь излучает тепло и т.п.)

Сила сообществ — сколько идей генерируем и закрепляем в коллективном мозгу.

Завести общий мозг, как в Студии Лебедева — с общими идеями, которыми обмениваемся

Концепты — инструменты мышления: право, лево, числа, цвета.

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

В тему: гипотеза лингвистической относительности и мой доклад на PHDays в тему про этот момент.

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

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

Новые вещи берутся из связи знакомых вещей, которыми люди обмениваются при встрече.

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

@startwithease

Мысли глобально — действуй локально

Сегодня обсуждали с коллегами вопросы качества продукта, и я заметил одно противоречие.

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

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

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

Но как именно и когда будут решены конкретные претензии клиентов — не понятно.

Когда я учился в школе и у меня были уроки программирования (на С++, между прочим!), меня тоже учили писать код абстрактно. Так, чтобы задача решалась в общем виде. Частные решения считались дурным вкусом — костылями.

Но мы уже давно не в школе, и я не программист, и скажу следующее:

1. Именно эти клиенты платят нам деньги, и не написать идеальный код, а решить их проблемы, сделать так, чтобы продукт прямо сейчас работал у них хорошо — главный результат нашей работы.

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

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

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

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

Дизайнеры это давно поняли и говорят об этом как о пользе ограничений.

Начни с простого: мысли глобально — действуй локально.

@startwithease

Компромисы

Есть рациональные аргументы, а есть ощущения: что ты на самом деле чувствуешь в той или иной ситуации.

1. Большая квартира, удобная кухня, есть льготная ипотека. А еще — большой микрорайон и сотни квартир напротив, стройка и парковка вдоль дороги.

Лично я хочу просыпаться и смотреть в это окно по утрам?

2. Офис в бизнес-центре рядом с метро, хорошая площадь, три интернет-провайдера на выбор. А еще — окна в атриум без солнечного света, потолки армстронг и туалет на этаже. Какое состояние будет у тебя к концу рабочего дня в таком офисе? Я работал в таком пять лет 😅

3. Нестарый седан С-класса, надежный, хороший дорожный просвет, недорогой в обслуживании. Но с каким ощущением ты будешь садиться в него каждый день? Я ездил семь лет, отличная была машина!

4. Большая продуктовая ниша, рынок сформирован, да еще попадает в тему импортозамещения. Но что ты почувствуешь, глядя в глаза своим людям и отвечая на вопрос — почему мы тратим время своей жизни, делая этот продукт?

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

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

@startwithease