{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Блоги: заметки с тегом спорю с интернетом",
    "_rss_description": "Автоматически собираемая лента заметок, написанных в блогах на Эгее",
    "_rss_language": "ru",
    "_itunes_email": "",
    "_itunes_categories_xml": "",
    "_itunes_image": false,
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/blogengine.ru\/blogs\/tags\/sporyu-s-internetom\/",
    "feed_url": "https:\/\/blogengine.ru\/blogs\/tags\/sporyu-s-internetom\/json\/",
    "icon": false,
    "authors": [
        {
            "name": "Илья Бирман",
            "url": "https:\/\/blogengine.ru\/blogs\/",
            "avatar": false
        }
    ],
    "items": [
        {
            "id": "135807",
            "url": "https:\/\/artemushanov.ru\/?go=all\/ob-oshibkah\/",
            "title": "Об ошибках",
            "content_html": "<p>Есть такая распространенная точка зрения, что ошибки — это нормально, на ошибках учатся и нужно не бояться их совершать.<\/p>\n<p>Из этой точки зрения следует другая точка зрения — что в работе, в рабочем контексте, нужно давать новичкам совершать ошибки, даже стремиться к этому, и тогда они быстро научатся правильной работе. Марк Цукерберг, не последний человек в мире, даже ввел рабочее мотто «move fast and break things» в одной экстремистской организации.<\/p>\n<p>Хочу на эту тему немного порассуждать, применительно именно к рабочему или деловому контексту. Но сначала определим понятия.<\/p>\n<p>Википедия:<\/p>\n<blockquote>\n<p>Ошибка — непреднамеренное, случайное отклонение от правильных действий, поступков, мыслей, разница между ожидаемой или измеренной и реальной величиной.<\/p>\n<\/blockquote>\n<p>Словарь Ожегова:<\/p>\n<blockquote>\n<p>Неправильность в действиях, мыслях.<\/p>\n<\/blockquote>\n<p>То есть, существует норма или правило, и отклонение от них — это и есть ошибка. В бизнесе это может быть отклонением от правил исполнения процесса или отклонением от нормы (качества) результата.<\/p>\n<p>В ситуациях, где нет нормы, не может быть и отклонений от нормы. В этой ситуации исполнитель выбирает одну из нескольких стратегий, исполняет ее, получает результат и оценивает его значимость. Такой подход вполне можно назвать экспериментальным — это шаг в неизвестность, разведка боем, прыжок веры. Именно о таких экспериментах говорил Эдисон журналисту в известной байке про пять тысяч способов, которые не сработали. Определение из Википедии в конце упоминает ожидаемую и реальную величину — но это ближе к ошибке в математическом смысле, чем в управленческо-бытовом, поэтому несоответствие ожидаемого результата эксперимента реальному в рамках этого текста мы ошибкой считать не будем.<br \/>\nТак что к ситуациям без нормы и правил понятие «ошибка» будем считать неприменимым.<\/p>\n<p>В ситуациях, где есть нормы или правила, могут возникать отклонения — ошибки. Но их наличие нежелательно. В идеале — их вообще не должно быть. При этом мотто «не нужно бояться ошибок, нужно их поощрять» применяется именно к таким ситуациям, и нередко именно в контексте работы\/бизнеса. Почему так? Предложу свою интерпретацию, но сначала оговорка.<\/p>\n<blockquote>\n<p>Нельзя просто разделить все жизненные и деловые ситуации на имеющие или не имеющие нормы. «Норма» и «правило» — ментальные объекты, абстракции, которые имеют смысл и хождение только среди хомо сапиенс, а потому не универсальны и субъективны. В одной компании «продажи» могут быть чисто интуитивным занятием, в котором нет норм и правил; в другой компании такого же размера, на том же рынке и с похожим продуктом, продажи могут быть максимально зарегулированы — там будут процессы, правила, проверочные чек-листы. Просто в одной компании решили так, в другой — иначе. Поэтому степень формальности правил (и степень тяжести отклонения от них) будет удобнее определять не по бинарной шкале «есть норма\/нет нормы», а, например, по шкале типов доменов из фреймворка Cynefin: понятный, сложный, комплексный, хаотичный, неопределенный. В «понятном» домене можно вычислить оптимальные алгоритмы для большинства ситуаций, зарегулировать и получить максимальный выигрыш от следования алгоритмам. В «сложном» это сделать сложнее (pun intended), ну и так далее. Конец оговорки.<\/p>\n<\/blockquote>\n<p>Моя интерпретация такова: в описываемой ситуации есть норма, есть правила, но с первого раза освоить их сложно и потому ошибки для новичков простительны. Чем быстрее новички эти ошибки совершат — тем быстрее они усвоят правила и начнут работать как надо. В этом и есть постулируемая польза совершения ошибок.<\/p>\n<p>Тут есть пара важных допущений.<\/p>\n<p>Первое и самое важное: ошибка и ее корректировка рассматриваются как способ привести новичка к норме. То есть, задача — освоить норму и работать по ней. Норма — цель, а ошибки — необходимое зло на пути к ней.<\/p>\n<p>Второе допущение: важна не сама ошибка, а ее разбор и корректировка. То есть, ошибка — это повод разобраться, а как надо было на самом деле поступать в норме. Делать это надо обязательно по горячим следам, иначе эффект будет слабый, либо вообще обратный — у исполнителя успеет закрепиться ошибочный подход к задаче.<\/p>\n<p>Следствие из второго допущения: ошибки должны фиксироваться и разбираться\/корректироваться сразу после обнаружения. Для этого в компании должны существовать какие-то практики или процессы, помогающие обнаруживать и корректировать ошибки. Без них от ошибок никакой пользы нет, исходное утверждение неверно.<\/p>\n<p>Следствие из следствия: если мы утверждаем, что есть норма\/правило — мы должны уметь проверять процесс или результат на отклонение от них. Иначе мы не сможем обнаружить ошибки и в наличии нормы\/правил нет никакого смысла.<\/p>\n<p>Теперь зафиксируем ситуацию целиком: для некоторых процессов и видов деятельности в компании существуют правила и нормы. Они закрепляют требования к рабочему продукту — результату работы, и оптимальный процесс для его получения. Этот процесс многократно проверен практикой, следование ему — самый верный способ получить рабочий продукт нужного качества. Когда кто-то отклоняется от процесса — качество рабочего продукта или способ его достижения отклоняются от оптимума и становятся менее выгодными для компании.<br \/>\nКогда в компанию приходит новый сотрудник, нужно добиться от него следования правилам и нормам в максимально сжатые сроки — чтобы он начал приносить компании прогнозируемую выгоду. Один из способов сделать это — обучить сотрудников, после чего отправить их на рабочие места, наблюдать за их работой, отслеживать совершенные ошибки и корректировать их в моменте. Тогда сотрудники со временем освоят следование норме и начнут выдавать результат с целевой маржинальностью.<\/p>\n<p>С точки зрения экономической эффективности, между двумя ситуациями — «сотрудник допускает ошибки и учится» и «сотрудник сразу работает правильно, без ошибок», — нужно выбрать вторую. Почему же тогда исходный постулат звучит как «ошибки совершать можно и нужно», а не «надо сразу нормально делать»?<\/p>\n<p>Предположу, что дело в экономической близорукости. Если в штат наняли 10 сотрудников, то это десять источников ошибок, каждый со своим характером и особенностями. За каждым надо отследить ошибки, объяснить, в чем отклонение от нормы, и описать правильный курс действий. Это МНОГО работы. Это дорого.<\/p>\n<p>Какая может быть альтернатива? Корректировка обучения и онбординга. Со временем — еще и адаптация под любой стиль обучения и восприятия информации. Поиск и внедрение эффективных методов обнаружения ошибок на учебных данных, до вывода сотрудников на реальные задачи.<\/p>\n<p>Пока кажется, что условный «бизнес» видит первый способ — через совершение и корректировку ошибок — более оптимальным (дешевым), чем осознанный масштабируемый подход к обучению.<\/p>\n<p>Толерантность к ошибкам, подход «move fast and break things» может быть оправдан только в ситуациях, когда цена ошибки ниже цены построения плана действий, исключающего допущение ошибки. При этом бывают такие виды деятельности, в которых цена ошибки слишком высока. Пилоты авиалайнеров все серьезные ошибки обкатывают на тренажерах, а не в реальных рейсах — и как пассажир, я это полностью поддерживаю.<\/p>\n<p>А Цукерберг в 2014 поменял мотто на «move fast with stable infrastructure». Интересно, почему?<\/p>\n<p>P.S. Вопросы психологической безопасности на рабочем месте, растяжимость понятия «совершение ошибки» от ситуации «совершил ошибку, нанес ущерб» до ситуации «совершил ошибку, распознал ее, быстро исправил, ущерба нет» в эссе не попали, но в голове мелькали. Возможно, сделаю второй пост с подробностями.<\/p>\n",
            "date_published": "2025-05-13T10:48:07+05:00",
            "date_modified": "2025-05-13T10:46:04+05:00",
            "tags": [
                "post",
                "бизнес",
                "менеджмент",
                "ошибки",
                "спорю с интернетом"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Tue, 13 May 2025 10:48:07 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "135807",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "135202",
            "url": "https:\/\/artemushanov.ru\/?go=all\/kommentiruyu-statyi-o-produktovom-podhode-video\/",
            "title": "Комментирую статьи о продуктовом подходе (видео)",
            "content_html": "<p>Некоторое время назад я наткнулся на пост про смерть продуктового подхода и <a href=\"https:\/\/artemushanov.ru\/?go=all\/sporyu-s-postom-pochemu-proektny-podhod-bolshe-ne-rabotaet\/\">разобрал его<\/a>. Автор поста проявлял поразительную неграмотность в базовых понятиях, и я решил поразбираться, а что вообще пишут о продуктовом подходе.<\/p>\n<p>Я записал спонтанное видео с разбором нескольких статей. Если вам не видно плеер ютуба — мотайте вниз, там ссылки на другие каналы.<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/MRTbB4V0NZo?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n<p>Ссылки:<br \/>\n<a href=\"https:\/\/www.youtube.com\/watch?v=MRTbB4V0NZo\">Ютуб<\/a><br \/>\n<a href=\"https:\/\/vkvideo.ru\/video2131309_456239147\">ВК<\/a><br \/>\n<a href=\"https:\/\/rutube.ru\/video\/a1c75e08cac85e693095dfcd153338cb\/\">Рутуб<\/a><\/p>\n",
            "date_published": "2025-03-11T10:46:32+05:00",
            "date_modified": "2025-03-11T10:47:31+05:00",
            "tags": [
                "post",
                "видео",
                "Создание продукта",
                "спорю с интернетом"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Tue, 11 Mar 2025 10:46:32 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "135202",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "133979",
            "url": "https:\/\/artemushanov.ru\/?go=all\/sporyu-s-postom-pochemu-proektny-podhod-bolshe-ne-rabotaet\/",
            "title": "Спорю с постом «Почему проектный подход больше не работает?»",
            "content_html": "<p>Пост попался мне в Сетке и у меня бомбануло.<br \/>\nВот он целиком:<\/p>\n<blockquote>\n<p><b>Почему проектный подход больше не работает?<\/b> 🚀<\/p>\n<\/blockquote>\n<blockquote>\n<p>У нас есть клиенты, с которыми всё началось с одного проекта. Потом подключилась поддержка, развитие, и вот ты оглядываешься — а вы уже работаете вместе 5+ лет. 😳<\/p>\n<\/blockquote>\n<blockquote>\n<p>Казалось бы, всё идёт хорошо: команда знакома с продуктом, клиенту нравится, что у нас вся экспертиза под рукой, а на вникание в процессы не тратится лишнее время. Зачем что-то менять?<br \/>\n❗️Но вот интересный момент: проектный подход в таких случаях уже не работает. Более того, он становится причиной большинства проблем.<\/p>\n<\/blockquote>\n<blockquote>\n<p>📌Почему проектный подход перестает работать?<\/p>\n<\/blockquote>\n<blockquote>\n<p>Проект — это конкретный объем задач, результат которых можно измерить в конце: «Вот вам ТЗ, вот разработанный проект». Но когда вы с клиентом вместе годами, задачи никогда не заканчиваются.<\/p>\n<\/blockquote>\n<blockquote>\n<p>Вот что происходит:<\/p>\n<\/blockquote>\n<blockquote>\n<p>🔹 Потеря знаний.<br \/>\nЗа 5 лет состав команды неизбежно меняется. Люди уходят, приходят, а вместе с ними уходит и накопленная экспертиза.<br \/>\n🔹Растущая сложность.<br \/>\nПродукт клиента развивается, в нём появляются новые компоненты системы, зависимости, интеграции, требования. А проектный подход слишком жёсткий, чтобы успевать за изменениями.<br \/>\n🔹Изменение приоритетов.<br \/>\nКогда вы планируете один проект, всё более-менее стабильно. Но за несколько лет потребности бизнеса клиента могут полностью измениться. Тут становится очевидно: чтобы развивать такой продукт, нужно работать по-другому.<\/p>\n<\/blockquote>\n<blockquote>\n<p>📌Продуктовый подход: в чём разница?<br \/>\nПроект — это работа на результат в рамках фиксированных сроков.<br \/>\nПродукт — это процесс постоянного развития, где главное — ценность для пользователя.<\/p>\n<\/blockquote>\n<blockquote>\n<p>Если совсем упростить: проект заканчивается, продукт — никогда.<\/p>\n<\/blockquote>\n<blockquote>\n<p>📌Ключевые отличия:<br \/>\n• Команда. В проекте может быть временная группа специалистов, а в продукте — стабильная кросс-функциональная команда.<br \/>\n• Цели. Проект нацелен на выполнение конкретного объёма задач, продукт — на достижение бизнес-результатов.<br \/>\n• Процессы. В проекте есть начало и конец, в продукте — циклы постоянного улучшения.<\/p>\n<\/blockquote>\n<blockquote>\n<p>📌Как мы трансформируем команды из проектных в продуктовые?<\/p>\n<\/blockquote>\n<blockquote>\n<p>У меня есть несколько советов, которые показали себя максимально эффективными:<\/p>\n<p>🔹 Создайте единую базу знаний с клиентом по продукту.<br \/>\nФиксируйте всё: архитектуру, процессы, фичи. База знаний спасёт в случае ухода ключевых специалистов. И заведите туда обязательно клиента — это повысит доверие >и упростит совместную работу. Кстати, за её ведение не стесняйтесь брать деньги: это полезно всем.<\/p>\n<p>🔹Стирайте границы между командами.<br \/>\nЧем больше точек соприкосновения, тем лучше. Приглашайте ключевых сотрудников клиента на свои внутренние церемонии: планирование спринта, координации, ретро. >Это сделает работу прозрачной и укрепит партнёрство.<\/p>\n<p>🔹Проводите онбординг.<br \/>\nПри смене сотрудников новый специалист должен быстро войти в контекст. Онбординг — это обязательный этап, где вы рассказываете о проекте, продукте и его целях, >знакомите с процессами, продуктом.<\/p>\n<p>🔹Создайте обучающий курс и проверяйте знания регулярно.<br \/>\nРазработайте внутренний обучающий курс. Включите в него тесты и регулярно проводите экзамены, которые будут проходить не только новички, но и «старички» >команды. Это помогает сохранять актуальность знаний, вовлекать всех в процесс и держать команду в отличной форме.<\/p>\n<p>🔹Инициируйте воркшопы и церемонии для улучшений.<br \/>\nВключите в свой процесс регулярную задачу: раз в заранее определенный период проводите внутренний воркшоп, на котором команда генерирует идеи по улучшению >продукта. Затем структурируйте предложения и обсуждайте их с клиентом. Это не только прокачает продукт, но и покажет вашу вовлечённость и экспертность.<\/p>\n<p>📌Почему это работает?<\/p>\n<p>Продуктовый подход — это не просто новый формат работы, это возможность построить с клиентом долгосрочное партнёрство.<\/p>\n<p>Такой подход создаёт доверие. Клиент видит, что вы не просто выполняете задачи, а действительно заботитесь о его продукте.е просто новый формат работы, это возможность построить с клиентом долгосрочное партнёрство.<\/p>\n<\/blockquote>\n<p>К автору поста не имею никаких претензий, наверняка он прекрасный человек; ниже я критикую исключительно суть и содержание поста в его исходном виде.<\/p>\n<p>И начинается он с кликбейта:<\/p>\n<blockquote>\n<p>«Почему проектный подход больше не работает?»<\/p>\n<\/blockquote>\n<p>Но он работает; утверждение автора сродни следующему: «я купил машину — ходьба пешком больше не работает 🙅‍♂️». Чтобы объяснить, почему конкретно в деятельности автора проектный подход не работает, нужен контекст: что за отрасль, что за клиенты, какие проекты\/продукты вы делаете. Тогда — да, можно обсуждать состояние проектной деятельности в конкретной отрасли, или с конкретным типом компаний\/заказчиков, и т. п.<\/p>\n<blockquote>\n<p>«проект — это конкретный объем задач»<\/p>\n<\/blockquote>\n<p>Вообще не везде и совсем не всегда; в общем виде «проект» — это организованные усилия команды по достижению результата. Если вы придете к заказчику и скажете «вот, мы выполнили все описанные задачи, дайте денег», то он закономерно спросит вас о результате. И если его нет — назовет вас плохими словами и денег не даст.<br \/>\nЦель проекта — достижение некоторого результата, обычно оговариваемого заранее. Какие для этого нужно выполнить задачи и в каком объеме — вопрос технический и нормального заказчика волновать не должен.<\/p>\n<blockquote>\n<p>«когда вы с клиентом вместо годами — проект никогда не заканчивается»<\/p>\n<\/blockquote>\n<p>В таких ситуациях это скорее серия или программа проектов, просто автор почему-то предлагает перестать к ним так относиться. Серия проектов — это когда «выход» одного проекта становится «входом» другого, программа — это когда проекты явно не связаны, но работают на выполнение единой стратегической задачи. У программы есть свои эк. показатели и ресурсы, которые распределяются между проектами; часть проектов не доживает до финиша, но эффект от реализации программы должен в целом работать на стратегическую цель заказчика. У программы свой руководитель, у каждого проекта внутри — свои, они подчиняютcя руководителю программы.<\/p>\n<blockquote>\n<p>«потеря знаний\/растущая сложность\/изменение приоритетов»<\/p>\n<\/blockquote>\n<p>Знания нужно фиксировать на любом проекте, потому что ключевой сотрудник может уйти в любой момент — в жизни всякое случается; про растущую сложность и «жесткость» проектного подхода не понял — на самом деле правила можно менять, если изменились обстоятельства, в том числе правила проектной работы и взаимодействия с заказчиком.<br \/>\nПро изменение приоритетов тоже вода какая-то: они и в процессе выполнения первого проекта могут поменяться несколько раз. Нужно работать со спонсором проекта и вовремя отслеживать изменения. См. <a href=\"https:\/\/artemushanov.ru\/?go=all\/pro-proekty-i-roli\/#:~:text=%D0%9A%D0%B0%D0%BA%C2%A0%D0%B6%D0%B5%20%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D1%82%D1%8C%20%D1%81%C2%A0%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8%20%D0%B8%C2%A0%D0%B7%D0%B0%D1%87%D0%B5%D0%BC%20%D0%BD%D0%B0%D0%BC%20%D1%80%D0%BE%D0%BB%D0%B8%2D%D1%87%D0%B5%D0%BA%D0%BB%D0%B8%D1%81%D1%82%D1%8B%3F%20%23\">фреймворк OMG Essence<\/a>, там на верхнем уровне есть три области интересов: стейкхолдеры(=заказчики), решение, управление. Приоритеты «висят» в области стейкхолдеров.<\/p>\n<blockquote>\n<p>«Продукт — это процесс постоянного развития, где главное — ценность для пользователя.»<\/p>\n<\/blockquote>\n<p>Тут у меня подгорело седалище из-за пренебрежительного отношения к определениям. «Продукт — это процесс», серьезно?<br \/>\nДля заказчика продукт — это <mark>предсказуемый способ зарабатывать деньги на рынке<\/mark>. Продукт можно придумать один раз, а продать — много раз, разным покупателям. Его для этого и делают. И именно в этом разница продуктового и проектного подходов: проект — каждый раз уникальное мероприятие, каждый раз новый набор требований и ограничений, продукт — один раз сделали, много раз продали. Продукт делать дороже и дольше, потом его нужно улучшать и менять — это сложнее с физическими продуктами и проще с софтом. По-прежнему справедливо мое утверждение, что продукт разрабатывается путем реализации серии проектов.<br \/>\nПродукт нужен, чтобы зарабатывать деньги, а не «предоставлять ценность для пользователя». Простая проверка: из пары стратегий «давать ценность и не зарабатывать деньги» и «зарабатывать деньги и не давать ценности» предприниматель выберет последнюю.<\/p>\n<blockquote>\n<p>«Проект заканчивается, продукт — никогда»<\/p>\n<\/blockquote>\n<p>Всем так хочется, но так не всегда бывает. Продукты могут устаревать, утрачивать конкурентные позиции и т. п. — вполне себе заканчиваются. Проверка: попробуйте составить план получения выручки за счет «продукта, который никогда не заканчивается» — получите бесконечное количество денег. Неплохо, но в жизни не встречается.<\/p>\n<blockquote>\n<p>Команда\/Цели\/Процессы...<\/p>\n<\/blockquote>\n<p>В проектах тоже может быть стабильная кросс-функциональная команда, все ок. Цели — снова ошибка про «конкретный объем задач», а не достижение цели проекта. Про продукт верно, цель — достижение бизнес-результатов, если конкретнее, то — прибыль на жизненном цикле.<\/p>\n<blockquote>\n<p>Переход из проекта в продукт...<\/p>\n<\/blockquote>\n<p>...возможен, если клиент строит продуктовую компанию и понимает, что это значит. База знаний тут абсолютно ни при чем, ее можно создать и в рамках любого проекта. «Границы между командами», онбординг и прочее — все справедливо и для проектов.<\/p>\n<blockquote>\n<p>«Включите в свой процесс регулярную задачу: раз в заранее определенный период проведите внутренний воркшоп, на котором команда генерирует идеи по улучшению продукта... (это) прокачает продукт и покажет вашу вовлеченность и экспертность»<\/p>\n<\/blockquote>\n<p>«Прокачать продукт» — значит, улучшить общую продуктовую экономику. Для этого нужно посчитать, какую прибыль на жизненном цикле продукт принесет компании, и принять это за базовый сценарий. После этого любые предлагаемые командой идеи должны эту прибыль увеличить — путем изменения одного из влияющих на нее факторов. Делать это нужно, в идеале, во время разработки продукта, именно в этот период можно существенно повилять на продуктовую экономику. Когда продукт на рынке — возможностей гораздо меньше и они обойдутся дороже.<\/p>\n<blockquote>\n<p>«Продуктовый подход — это... возможность построить с клиентом долгосрочное партнерство.»<\/p>\n<\/blockquote>\n<p>Вообще, рыночная продуктовая компания никогда не отдаст основную компетенцию — делать и улучшать продукт — на подряд. Это просто очень рискованно: подрядчик почему-то решает прекратить сотрудничество — и привет, продуктовая работа закончилась, нас сожрали конкуренты. Продуктовая компания действительно может отдавать кусочки работы или даже фрагменты продукта на аутсорс — но ни в коем случае не весь продукт, и тем более не весь продуктовый процесс. Или такая компания быстро закончится.<\/p>\n<blockquote>\n<p>«Клиент видит, что вы не просто выполняете задачи, а действительно заботитесь о его продукте.»<\/p>\n<\/blockquote>\n<p>Все еще справедливо в отношении проекта. Хороший проектный подрядчик беспокоится не за состав работ и их выполнение, а за получение требуемого результата. Для этого нужно хорошо понимать, а как именно в рабочую цепочку заказчика встроится результат проекта. А это как раз хороший первый шаг к пониманию того, что такое продукт ;-)<\/p>\n<p><b>Вывод<\/b>: автору поста было бы здорово получше изучить проектный подход и применяемые в нем методики. Проекты и проектный подход никуда не денутся, по-прежнему работают и в жизни встретятся не раз.<br \/>\nМне нравятся подходы и инструменты Ивара Якобсона — конкретно под проекты подходит OMG Essence, про него есть доклады на ютубе. Продуктовый подход — сложная штука и сильно отличается от того, что описывает в посте автор.<\/p>\n<p>Немного в защиту автора — из поста сложилось ощущение, что речь идет все-таки не о проектном подходе в целом, а о какой-то отраслевой\/доменной специфике, или даже конкретно о специфике подхода в компании автора. Чтобы это было очевидно — нужно было исходный пост обогатить фактурой, дать контекст и конкретные примеры. Тогда пост стал бы полезным, можно было бы за что-то зацепиться, что-то обсудить, а не только до понятий и незнания матчасти докопаться, как я сделал в этом посте.<\/p>\n",
            "date_published": "2025-02-05T19:09:58+05:00",
            "date_modified": "2025-04-30T18:33:52+05:00",
            "tags": [
                "post",
                "проекты",
                "Создание продукта",
                "спорю с интернетом"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Wed, 05 Feb 2025 19:09:58 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "133979",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "133825",
            "url": "https:\/\/artemushanov.ru\/?go=all\/chto-ne-tak-v-poste-prodakt-menedzhera\/",
            "title": "Что не так в посте продакт-менеджера?",
            "content_html": "<p>В одном продуктовом канале прочитал следующий пост:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/image-83.png\" width=\"828\" height=\"995\" alt=\"\" \/>\n<\/div>\n<p>Вопрос: что не так в финальном утверждении автора?<\/p>\n<p>Начнем с первого спорного утверждения:<\/p>\n<blockquote>\n<p>Хорошее подтверждение тому, что люди по всему миру примерно одинаковые и хотят похожих вещей\/развлечений\/цифровых продуктов.<\/p>\n<\/blockquote>\n<p>Давайте попробуем среверсинжинирить логику автора:<\/p>\n<div style=\"border-radius: 25px; border:1px solid #DCDCDC;padding:20px;margin:20px;\"><blockquote>\n<p>Люди в Дубае делают снежных ангелов (наблюдение)<br \/>\n↓<br \/>\nавтор поста не ожидал этого увидеть — люди в Дубае не должны уметь делать снежных ангелов, т. к. там пустыня и жара<br \/>\n↓<br \/>\nно все-таки делают — значит, умеют и хотят это делать<br \/>\n↓<br \/>\nзначит, у всех людей в мире есть общая потребность — делать снежных ангелов<br \/>\n↓<br \/>\nвсе люди похожи друг на друга.<\/p>\n<\/blockquote>\n<\/div><p>Во-первых, логика страдает. Утверждение после каждой стрелки в построении выше требует дополнительных допущений и предположений, чтобы быть истинным. В идеале, нужно проверить каждую пару «причина — следствие» в построении на соблюдение принципа MECE\/ВИСИ. Без этого логическая цепочка кривая и неполная.<\/p>\n<p>Во-вторых, тезис автора начинается с «я не ожидал такого увидеть» — то есть, речь об анекдотическом свидетельстве, которое аргументом вообще считать нельзя.<\/p>\n<p>В-третьих — плохой по форме вывод. На основе вышеприведенной цепочки автор делает вывод, что «все люди похожи». Вывод негодный: продакт должен оперировать не персональными психологическими или поведенческими свойствами людей, а их потребностями и джобами (из JTBD). Не говоря уже о том, что квантификаторы типа «все\/никто», «всегда\/никогда» слабо применимы в продуктовой работе.<\/p>\n<p>Ну ок, допустим я тут доебался до формулировок и автор имел в виду джобы — просто криво выразился. Тогда получается, что речь идет о каком-то джобе, скорее всего развлекательного характера, который выполняется практикой «делать снежного ангела». И такие джобы есть у людей по всему миру, а не там, где бывает снегопад. Но мы по-прежнему не знаем, какие еще решения могут выполнять эту «работу», утверждение по-прежнему неверное.<\/p>\n<p><mark>Вывод 1: автор выдвигает спорный тезис с очень слабыми аргументами, я бы в него не верил.<\/mark><\/p>\n<p>Четвертый серьезный косяк поста — автор на основе единичного наблюдения делает общий вывод. Так нельзя.<br \/>\n«Я один раз видел, как чуваки в Молл оф Эмирейтс делают снежного ангела в специальном павильоне → все люди одинаковы, т. к. делают снежных ангелов».<br \/>\nА если я ни разу не видел, как делают снежного ангела в Дубае — это считается за валидный контр-аргумент тезису «все люди одинаковы»? А достаточно ли одного наблюдения про снежных ангелов, чтобы утверждать, что «все люди это делают, следовательно — похожи»? А откуда мы знаем, что люди за пределами Дубая вообще делают снежных ангелов? — и так далее.<\/p>\n<p>Разложив схематично тезис и аргумент, даже не хочется ничего писать про выборку и прочие статистические штуки — и так понятно, что это булшит.<\/p>\n<p>Теперь перейдем к финальному предложению:<\/p>\n<blockquote>\n<p>Если ваш продукт строится на гипотезе «люди в нашей стране привыкли делать так, этим мы отличаемся от страны Х» — это довольно слабая гипотеза<\/p>\n<\/blockquote>\n<p>Во-первых, приведенное в кавычках слабо тянет на гипотезу, она криво выражена, у нее нет критериев проверки. Ну ладно, пусть это будет гипотеза в первом приближении, на уровне идеи, для реальной проверки надо докручивать.<br \/>\nТогда у нас есть во-вторых: для какого продукта и для какой продуктовой ситуации гипотеза справедлива? Я навскидку вижу одну: продакт обосновывает маленькость рынка тем, что продукт решает джоб некоторым специфическим для этой страны образом и не может масштабироваться только с помощью маркетинга. Такие продукты и такие потребности действительно могут существовать, то есть на уровне интенции автор тут скорее прав.<br \/>\nВ-третьих, предлагается эту спорную гипотезу считать «слабой» на основе того, что автор видел пингвинов и снежных ангелов в Молл оф Эмирейтс. Тут у нас продуктовое соломенное чучело: автор придумал гипотезу, которую можно опровергнуть с помощью его наблюдения про пингвинов и ангелов, и решительно ее опроверг.<\/p>\n<p>Семь серьезных косяков на маленький пост твиттерского формата.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/chto-ne-tak-v-poste-prodakt-menedzhera.png\" width=\"1658\" height=\"873\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Дядя Джун лучше всех <a href=\"https:\/\/www.youtube.com\/watch?v=86P8SnEnF0g\">выражает правильное отношение<\/a> к таким ситуациям<\/div>\n<\/div>\n<p>На самом деле, ситуация простая донельзя.<br \/>\nАвтор давно не выпускал посты, как он сам и пишет, и решил в качестве инфоповода притянуть свое наблюдение к продуктовой теме. Притянул, сделал из этого практический совет, получилось предсказуемо плохо.<\/p>\n<p>Теперь кратко, тоже в твиттерском формате, ответим на вопрос из начала поста: что же не так с последним утверждением в посте автора? Вот что: <mark>там дается неправильный и вредный совет, обоснованный примерно ничем<\/mark>. Надеюсь, теперь понятно, почему.<\/p>\n<p>Осторожнее с выбором экспертов, которым вы доверяете. Снежных ангелов делать можно, а выводы как у автора в посте — нет.<\/p>\n",
            "date_published": "2025-01-29T15:55:49+05:00",
            "date_modified": "2025-01-29T15:54:18+05:00",
            "tags": [
                "post",
                "Создание продукта",
                "спорю с интернетом"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Wed, 29 Jan 2025 15:55:49 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "133825",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        }
    ],
    "_e2_version": 4079,
    "_e2_ua_string": "Aegea 11.0 (v4079e)"
}