Блоги: заметки с тегом спорю с интернетом

Об ошибках

Артем Ушанов — Tue, 13 May 2025 10:48:07 +0500

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

Из этой точки зрения следует другая точка зрения — что в работе, в рабочем контексте, нужно давать новичкам совершать ошибки, даже стремиться к этому, и тогда они быстро научатся правильной работе. Марк Цукерберг, не последний человек в мире, даже ввел рабочее мотто «move fast and break things» в одной экстремистской организации.

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

Википедия:

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

Словарь Ожегова:

Неправильность в действиях, мыслях.

То есть, существует норма или правило, и отклонение от них — это и есть ошибка. В бизнесе это может быть отклонением от правил исполнения процесса или отклонением от нормы (качества) результата.

В ситуациях, где нет нормы, не может быть и отклонений от нормы. В этой ситуации исполнитель выбирает одну из нескольких стратегий, исполняет ее, получает результат и оценивает его значимость. Такой подход вполне можно назвать экспериментальным — это шаг в неизвестность, разведка боем, прыжок веры. Именно о таких экспериментах говорил Эдисон журналисту в известной байке про пять тысяч способов, которые не сработали. Определение из Википедии в конце упоминает ожидаемую и реальную величину — но это ближе к ошибке в математическом смысле, чем в управленческо-бытовом, поэтому несоответствие ожидаемого результата эксперимента реальному в рамках этого текста мы ошибкой считать не будем.
Так что к ситуациям без нормы и правил понятие «ошибка» будем считать неприменимым.

В ситуациях, где есть нормы или правила, могут возникать отклонения — ошибки. Но их наличие нежелательно. В идеале — их вообще не должно быть. При этом мотто «не нужно бояться ошибок, нужно их поощрять» применяется именно к таким ситуациям, и нередко именно в контексте работы/бизнеса. Почему так? Предложу свою интерпретацию, но сначала оговорка.

Нельзя просто разделить все жизненные и деловые ситуации на имеющие или не имеющие нормы. «Норма» и «правило» — ментальные объекты, абстракции, которые имеют смысл и хождение только среди хомо сапиенс, а потому не универсальны и субъективны. В одной компании «продажи» могут быть чисто интуитивным занятием, в котором нет норм и правил; в другой компании такого же размера, на том же рынке и с похожим продуктом, продажи могут быть максимально зарегулированы — там будут процессы, правила, проверочные чек-листы. Просто в одной компании решили так, в другой — иначе. Поэтому степень формальности правил (и степень тяжести отклонения от них) будет удобнее определять не по бинарной шкале «есть норма/нет нормы», а, например, по шкале типов доменов из фреймворка Cynefin: понятный, сложный, комплексный, хаотичный, неопределенный. В «понятном» домене можно вычислить оптимальные алгоритмы для большинства ситуаций, зарегулировать и получить максимальный выигрыш от следования алгоритмам. В «сложном» это сделать сложнее (pun intended), ну и так далее. Конец оговорки.

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

Тут есть пара важных допущений.

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

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

Следствие из второго допущения: ошибки должны фиксироваться и разбираться/корректироваться сразу после обнаружения. Для этого в компании должны существовать какие-то практики или процессы, помогающие обнаруживать и корректировать ошибки. Без них от ошибок никакой пользы нет, исходное утверждение неверно.

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

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

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

Предположу, что дело в экономической близорукости. Если в штат наняли 10 сотрудников, то это десять источников ошибок, каждый со своим характером и особенностями. За каждым надо отследить ошибки, объяснить, в чем отклонение от нормы, и описать правильный курс действий. Это МНОГО работы. Это дорого.

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

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

Толерантность к ошибкам, подход «move fast and break things» может быть оправдан только в ситуациях, когда цена ошибки ниже цены построения плана действий, исключающего допущение ошибки. При этом бывают такие виды деятельности, в которых цена ошибки слишком высока. Пилоты авиалайнеров все серьезные ошибки обкатывают на тренажерах, а не в реальных рейсах — и как пассажир, я это полностью поддерживаю.

А Цукерберг в 2014 поменял мотто на «move fast with stable infrastructure». Интересно, почему?

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

Комментирую статьи о продуктовом подходе (видео)

Артем Ушанов — Tue, 11 Mar 2025 10:46:32 +0500

Артем Ушанов:

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

Я записал спонтанное видео с разбором нескольких статей. Если вам не видно плеер ютуба — мотайте вниз, там ссылки на другие каналы.

Ссылки:
Ютуб
ВК
Рутуб

Спорю с постом «Почему проектный подход больше не работает?»

Артем Ушанов — Wed, 05 Feb 2025 19:09:58 +0500

Артем Ушанов:

Пост попался мне в Сетке и у меня бомбануло.
Вот он целиком:

Почему проектный подход больше не работает? 🚀

У нас есть клиенты, с которыми всё началось с одного проекта. Потом подключилась поддержка, развитие, и вот ты оглядываешься — а вы уже работаете вместе 5+ лет. 😳

Казалось бы, всё идёт хорошо: команда знакома с продуктом, клиенту нравится, что у нас вся экспертиза под рукой, а на вникание в процессы не тратится лишнее время. Зачем что-то менять?
❗️Но вот интересный момент: проектный подход в таких случаях уже не работает. Более того, он становится причиной большинства проблем.

📌Почему проектный подход перестает работать?

Проект — это конкретный объем задач, результат которых можно измерить в конце: «Вот вам ТЗ, вот разработанный проект». Но когда вы с клиентом вместе годами, задачи никогда не заканчиваются.

Вот что происходит:

🔹 Потеря знаний.
За 5 лет состав команды неизбежно меняется. Люди уходят, приходят, а вместе с ними уходит и накопленная экспертиза.
🔹Растущая сложность.
Продукт клиента развивается, в нём появляются новые компоненты системы, зависимости, интеграции, требования. А проектный подход слишком жёсткий, чтобы успевать за изменениями.
🔹Изменение приоритетов.
Когда вы планируете один проект, всё более-менее стабильно. Но за несколько лет потребности бизнеса клиента могут полностью измениться. Тут становится очевидно: чтобы развивать такой продукт, нужно работать по-другому.

📌Продуктовый подход: в чём разница?
Проект — это работа на результат в рамках фиксированных сроков.
Продукт — это процесс постоянного развития, где главное — ценность для пользователя.

Если совсем упростить: проект заканчивается, продукт — никогда.

📌Ключевые отличия:
• Команда. В проекте может быть временная группа специалистов, а в продукте — стабильная кросс-функциональная команда.
• Цели. Проект нацелен на выполнение конкретного объёма задач, продукт — на достижение бизнес-результатов.
• Процессы. В проекте есть начало и конец, в продукте — циклы постоянного улучшения.

📌Как мы трансформируем команды из проектных в продуктовые?

У меня есть несколько советов, которые показали себя максимально эффективными:

🔹 Создайте единую базу знаний с клиентом по продукту.
Фиксируйте всё: архитектуру, процессы, фичи. База знаний спасёт в случае ухода ключевых специалистов. И заведите туда обязательно клиента — это повысит доверие >и упростит совместную работу. Кстати, за её ведение не стесняйтесь брать деньги: это полезно всем.

🔹Стирайте границы между командами.
Чем больше точек соприкосновения, тем лучше. Приглашайте ключевых сотрудников клиента на свои внутренние церемонии: планирование спринта, координации, ретро. >Это сделает работу прозрачной и укрепит партнёрство.

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

🔹Создайте обучающий курс и проверяйте знания регулярно.
Разработайте внутренний обучающий курс. Включите в него тесты и регулярно проводите экзамены, которые будут проходить не только новички, но и «старички» >команды. Это помогает сохранять актуальность знаний, вовлекать всех в процесс и держать команду в отличной форме.

🔹Инициируйте воркшопы и церемонии для улучшений.
Включите в свой процесс регулярную задачу: раз в заранее определенный период проводите внутренний воркшоп, на котором команда генерирует идеи по улучшению >продукта. Затем структурируйте предложения и обсуждайте их с клиентом. Это не только прокачает продукт, но и покажет вашу вовлечённость и экспертность.

📌Почему это работает?

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

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

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

И начинается он с кликбейта:

«Почему проектный подход больше не работает?»

Но он работает; утверждение автора сродни следующему: «я купил машину — ходьба пешком больше не работает 🙅‍♂️». Чтобы объяснить, почему конкретно в деятельности автора проектный подход не работает, нужен контекст: что за отрасль, что за клиенты, какие проекты/продукты вы делаете. Тогда — да, можно обсуждать состояние проектной деятельности в конкретной отрасли, или с конкретным типом компаний/заказчиков, и т. п.

«проект — это конкретный объем задач»

Вообще не везде и совсем не всегда; в общем виде «проект» — это организованные усилия команды по достижению результата. Если вы придете к заказчику и скажете «вот, мы выполнили все описанные задачи, дайте денег», то он закономерно спросит вас о результате. И если его нет — назовет вас плохими словами и денег не даст.
Цель проекта — достижение некоторого результата, обычно оговариваемого заранее. Какие для этого нужно выполнить задачи и в каком объеме — вопрос технический и нормального заказчика волновать не должен.

«когда вы с клиентом вместо годами — проект никогда не заканчивается»

В таких ситуациях это скорее серия или программа проектов, просто автор почему-то предлагает перестать к ним так относиться. Серия проектов — это когда «выход» одного проекта становится «входом» другого, программа — это когда проекты явно не связаны, но работают на выполнение единой стратегической задачи. У программы есть свои эк. показатели и ресурсы, которые распределяются между проектами; часть проектов не доживает до финиша, но эффект от реализации программы должен в целом работать на стратегическую цель заказчика. У программы свой руководитель, у каждого проекта внутри — свои, они подчиняютcя руководителю программы.

«потеря знаний/растущая сложность/изменение приоритетов»

Знания нужно фиксировать на любом проекте, потому что ключевой сотрудник может уйти в любой момент — в жизни всякое случается; про растущую сложность и «жесткость» проектного подхода не понял — на самом деле правила можно менять, если изменились обстоятельства, в том числе правила проектной работы и взаимодействия с заказчиком.
Про изменение приоритетов тоже вода какая-то: они и в процессе выполнения первого проекта могут поменяться несколько раз. Нужно работать со спонсором проекта и вовремя отслеживать изменения. См. фреймворк OMG Essence, там на верхнем уровне есть три области интересов: стейкхолдеры(=заказчики), решение, управление. Приоритеты «висят» в области стейкхолдеров.

«Продукт — это процесс постоянного развития, где главное — ценность для пользователя.»

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

«Проект заканчивается, продукт — никогда»

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

Команда/Цели/Процессы...

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

Переход из проекта в продукт...

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

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

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

«Продуктовый подход — это... возможность построить с клиентом долгосрочное партнерство.»

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

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

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

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

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

Что не так в посте продакт-менеджера?

Артем Ушанов — Wed, 29 Jan 2025 15:55:49 +0500

Артем Ушанов:

В одном продуктовом канале прочитал следующий пост:

Вопрос: что не так в финальном утверждении автора?

Начнем с первого спорного утверждения:

Хорошее подтверждение тому, что люди по всему миру примерно одинаковые и хотят похожих вещей/развлечений/цифровых продуктов.

Давайте попробуем среверсинжинирить логику автора:

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

Во-первых, логика страдает. Утверждение после каждой стрелки в построении выше требует дополнительных допущений и предположений, чтобы быть истинным. В идеале, нужно проверить каждую пару «причина — следствие» в построении на соблюдение принципа MECE/ВИСИ. Без этого логическая цепочка кривая и неполная.

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

В-третьих — плохой по форме вывод. На основе вышеприведенной цепочки автор делает вывод, что «все люди похожи». Вывод негодный: продакт должен оперировать не персональными психологическими или поведенческими свойствами людей, а их потребностями и джобами (из JTBD). Не говоря уже о том, что квантификаторы типа «все/никто», «всегда/никогда» слабо применимы в продуктовой работе.

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

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

Четвертый серьезный косяк поста — автор на основе единичного наблюдения делает общий вывод. Так нельзя.
«Я один раз видел, как чуваки в Молл оф Эмирейтс делают снежного ангела в специальном павильоне → все люди одинаковы, т. к. делают снежных ангелов».
А если я ни разу не видел, как делают снежного ангела в Дубае — это считается за валидный контр-аргумент тезису «все люди одинаковы»? А достаточно ли одного наблюдения про снежных ангелов, чтобы утверждать, что «все люди это делают, следовательно — похожи»? А откуда мы знаем, что люди за пределами Дубая вообще делают снежных ангелов? — и так далее.

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

Теперь перейдем к финальному предложению:

Если ваш продукт строится на гипотезе «люди в нашей стране привыкли делать так, этим мы отличаемся от страны Х» — это довольно слабая гипотеза

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

Семь серьезных косяков на маленький пост твиттерского формата.

Дядя Джун лучше всех выражает правильное отношение к таким ситуациям

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

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

Осторожнее с выбором экспертов, которым вы доверяете. Снежных ангелов делать можно, а выводы как у автора в посте — нет.