Тренажер баланса

Вейксерфинг — это катание на доске за катером‑буксировщиком. Катер разгоняется и создает за собой волну, на которой можно кататься.

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

А что сработает? Что сделать, чтобы вейксерф помог прокачать навыки, полезные в океане?

Начните с простого:

1. Вместо короткой доски для вейксерфа возьмите океанский лонгборд 🏄‍♂️

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

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

@startwithease

Позаботьтесь о людях, продукте и прибыли — именно в таком порядке

Так Бен Хоровиц в своей книге Легко не будет писал о приоритетах, которые стоит выбирать директору компании.

Логика простая:

1. Мотивированные и вовлеченные сотрудники создают лучший продукт на рынке.

2. Клиенты покупают лучший продукт.

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

Но что значит — позаботиться о людях?

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

Людям в работе гораздо важнее иметь ясные цели, которые вдохновляют и имеют смысл.

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

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

Важны ли нам клиенты и прибыль? Конечно, ведь именно от них мы получаем зарплату.

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

Но своим приоритетом на этой неделе, как и в другие, я выбираю мою команду.

@startwithease

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

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

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

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

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

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

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

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

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

@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 — Личные наблюдения относительно надежности системы "Шаттл" Р. П. Фейнман