{
    "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.me\/blogs\/tags\/proekty\/",
    "feed_url": "https:\/\/blogengine.me\/blogs\/tags\/proekty\/json\/",
    "icon": false,
    "authors": [
        {
            "name": "Илья Бирман",
            "url": "https:\/\/blogengine.me\/blogs\/",
            "avatar": false
        }
    ],
    "items": [
        {
            "id": "136675",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/superpedestrian\/",
            "title": "Интерфейс управления флотом самокатов Суперпедестриана",
            "content_html": "<p>Рассказал о проекте, который делал больше трёх лет назад — интерфейс управления флотом самокатов Суперпедестриана:<\/p>\n<div class=\"e2-text-picture\">\n<a href=\"https:\/\/ilyabirman.ru\/superpedestrian\/\" class=\"e2-text-picture-link\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/superpedestrian-cover.jpg\" width=\"920\" height=\"607\" alt=\"\" \/>\n<\/a><\/div>\n<p>Очень люблю такие интерфейсные задачки, когда надо разобраться в каких-то замороченных процессах.<\/p>\n",
            "date_published": "2025-07-18T16:56:52+05:00",
            "date_modified": "2025-07-18T16:51:04+05:00",
            "tags": [
                "пользовательский интерфейс",
                "проекты",
                "релиз"
            ],
            "author": {
                "name": "Илья Бирман",
                "url": "https:\/\/ilyabirman.ru\/meanwhile\/",
                "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
            },
            "_date_published_rfc2822": "Fri, 18 Jul 2025 16:56:52 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "136675",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "136280",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/razbor-dizayna-navigacii-dlya-postavschikov-vayldberris\/",
            "title": "Разбор дизайна навигации для поставщиков «Вайлдберрис»",
            "content_html": "<p>Зимой опубликовал проект <a href=\"https:\/\/ilyabirman.ru\/wb\/suppliers\/\">навигации для поставщиков «Вайлдберрис»<\/a>. Наконец-то снял видеообзор этого проекта. Рассказываю о сценарном подходе к навигационным проектам и что нужно было учесть именно в этом случае. Видео будет полезно дизайнерам и тем, кто думает, не заказать ли мне дизайн:<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/qQCtZet0jbE?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<p>\n00:00 Интро<br \/>\n03:16 Путь поставщика<br \/>\n07:30 Предыдущее светодиодное табло на складе<br \/>\n09:24 Табло.вб.ру<br \/>\n12:50 Портал поставщиков, инструкция для водителя и схемы складов<br \/>\n17:35 Банер и указатели ворот на складе<br \/>\n19:59 Улучшенное светодиодное табло<br \/>\n22:30 Аутро<br \/>\n<\/p>\n<\/div>\n",
            "date_published": "2025-06-12T23:53:40+05:00",
            "date_modified": "2025-06-13T00:04:46+05:00",
            "tags": [
                "видео",
                "дизайн",
                "навигация",
                "проекты"
            ],
            "author": {
                "name": "Илья Бирман",
                "url": "https:\/\/ilyabirman.ru\/meanwhile\/",
                "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
            },
            "_date_published_rfc2822": "Thu, 12 Jun 2025 23:53:40 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "136280",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "136232",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/samara-metro-map\/",
            "title": "Схема метро Самары",
            "content_html": "<p>С дизайнером Николаем Романовым <a href=\"https:\/\/ilyabirman.ru\/samara\/\">сделали схему метро Самары<\/a>:<\/p>\n<div class=\"e2-text-picture\">\n<a href=\"https:\/\/ilyabirman.ru\/samara\/\" class=\"e2-text-picture-link\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/samara-metro.png\" width=\"2000\" height=\"870\" alt=\"\" \/>\n<\/a><\/div>\n<p>Спасибо Серёге Чикину за герб и Леониду Мотовских за советы. Если вы из Самары, напишите, что мы где напутали.<\/p>\n",
            "date_published": "2025-06-09T12:25:27+05:00",
            "date_modified": "2025-06-09T12:25:20+05:00",
            "tags": [
                "проекты",
                "релиз",
                "Самара",
                "схемы метро",
                "транспортные схемы"
            ],
            "author": {
                "name": "Илья Бирман",
                "url": "https:\/\/ilyabirman.ru\/meanwhile\/",
                "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
            },
            "_date_published_rfc2822": "Mon, 09 Jun 2025 12:25:27 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "136232",
            "_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": "132891",
            "url": "https:\/\/artemushanov.ru\/?go=all\/podborka-postov-i-paragrafov-pro-upravlenie\/",
            "title": "Подборка постов про управление",
            "content_html": "<p class=\"foot\">Это подборка публиковавшихся постов про управление.<\/p>\n<p>Про айти продукты — <a href=\"https:\/\/artemushanov.ru\/?go=all\/chto-ya-uznal-v-aprele-2024\/#:~:text=%D0%92%D0%B8%D0%B4%D0%B5%D0%BE%20%C2%AB%D0%9A%D1%81%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%A8%D0%BA%D0%BE%D0%BB%D0%B0%20%E2%80%9C%D0%9A%D0%B0%D0%BA%20200%20%D1%87%D0%B5%D0%BB%D0%BE%D0%B2%D0%B5%D0%BA%20%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D1%8E%D1%82%20%D0%B1%D0%B5%D0%B7%C2%A0%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%BE%D0%B2%E2%80%9D%C2%BB\">как делать продукт без роли аналитика?<\/a><\/p>\n<p>Допустим, вы стали CPO. <a href=\"https:\/\/artemushanov.ru\/?go=all\/chto-ya-uznal-v-aprele-2024\/#:~:text=%D0%92%D0%B8%D0%B4%D0%B5%D0%BE%20%C2%ABYou%E2%80%99re%20a%C2%A0First%20time%20CPO!%20Now%20What%3F%C2%BB\">Какие ошибки не допускать на C-level и как не вылететь с позиции?<\/a><\/p>\n<p>Философское <a href=\"https:\/\/artemushanov.ru\/?go=all\/mysli-pro-cifrovuyu-transformaciyu-2019\/\">про цифровую трансформацию<\/a>. В высококонкурентных областях софт из инструмента в помощь бизнесу становится фреймворком, основой того, как бизнес должен работать.<\/p>\n<p>И еще философское — <a href=\"https:\/\/artemushanov.ru\/?go=all\/glava-iz-knigi-drukera-menedzhment-vyzovy-21-veka\/\">про взгляд дедушки менеджмента Питера Друкера на информационные технологии<\/a>.<\/p>\n<p>Навеянный сериалом The Bear текст <a href=\"https:\/\/artemushanov.ru\/?go=all\/chto-ya-uznal-v-oktyabre-2023\/#:~:text=Система%20Kitchen%20Brigade\">про организацию кухни в ресторане<\/a>.<\/p>\n<p><a href=\"https:\/\/artemushanov.ru\/?go=all\/kniga-pro-fabrichnyh-rabochih-sboi-i-polomki\/\">Книга про работу на заводе<\/a> и размышления о производственном менеджменте.<\/p>\n<p><a href=\"https:\/\/artemushanov.ru\/?go=all\/pro-knigu-pixar-perezagruzka-genialnaya-kniga-po-antikrizisnomu\/\">Книга  про компанию Pixar<\/a> — одна из лучших, что я читал про известные компании. Из грязи в IPO, источник состояния Стива Джобса, жесткие переговоры с Диснеем.<\/p>\n<p><a href=\"https:\/\/artemushanov.ru\/?go=all\/chto-ya-uznal-v-iyule-2023\/#moderation\">Пост Вастрика<\/a> про модерацию сообществ. Прям интересный домен — без модерации нельзя, но и напрямую всем запретить всё неправильное не получится. Приходится управлять не людьми (ну кроме модераторов), а набором правил или принципов, и никакой демократии.<\/p>\n<p>Хайлайты с <a href=\"https:\/\/artemushanov.ru\/?go=all\/chto-ya-uznal-v-marte-2024\/#:~:text=%D0%92%D0%B5%D0%B1%D0%B8%D0%BD%D0%B0%D1%80%20%D0%90%D0%BD%D0%BD%D1%8B%20%D0%9B%D1%83%D0%B1%D0%B5%D0%BD%D1%87%D0%B5%D0%BD%D0%BA%D0%BE%20%D0%BF%D1%80%D0%BE%C2%A0%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5%20%D1%81%D0%B2%D0%BE%D0%B8%D0%BC%20%D1%80%D0%B0%D0%B1%D0%BE%D1%87%D0%B8%D0%BC%20%D1%80%D0%B5%D1%81%D1%83%D1%80%D1%81%D0%BE%D0%BC\">вебинара Анны Лубенченко про управление собственным ресурсом<\/a>. Считайте часы, пользуйтесь помодоро.<\/p>\n<p>Хайлайты с <a href=\"https:\/\/artemushanov.ru\/?go=all\/chto-ya-uznal-v-marte-2024\/#:~:text=%D0%92%D0%B5%D0%B1%D0%B8%D0%BD%D0%B0%D1%80%20%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B5%D1%8F%20%D0%9A%D0%B0%D0%BF%D1%82%D0%B5%D1%80%D0%B5%D0%B2%D0%B0%20%D0%BF%D1%80%D0%BE%C2%A0%D1%84%D0%B8%D0%B4%D0%B1%D0%B5%D0%BA\">вебинара Алексея Каптерева<\/a> про фидбек в образовании и бизнесе.<\/p>\n<h3>Про управление проектами<\/h3>\n<p><a href=\"https:\/\/artemushanov.ru\/?go=all\/pro-proekty-i-roli\/\">Пост про роли, чеклисты, проекты и как их обсуждать<\/a>.<\/p>\n<p><a href=\"https:\/\/artemushanov.ru\/?go=all\/otchet-chaos-report-2018\/\">Обзор отчета CHAOS Report 2018<\/a> —  факторы успеха в управлении проектами по разработке софта.<\/p>\n<p><a href=\"https:\/\/artemushanov.ru\/?go=all\/otchet-chaos-report-2020\/\">Обзор отчета CHAOS Report 2020<\/a> — последний (не в смысле крайний, а в смысле — больше не будет, всё) отчет группы. Факторы почти те же, авторы провозглашают конец эры проектов и начало новой эры «управления потоком».<\/p>\n<p><a href=\"https:\/\/artemushanov.ru\/?go=all\/chto-ya-uznal-v-dekabre-2021\/#projects\">Пост А. Турханова<\/a> про вырождение понятия «проект»: раньше «проектами» считались временные предприятия с бюджетом от 20 млн долларов и штатом от 200 человек. Что потом пошло не так?<\/p>\n",
            "date_published": "2024-11-21T22:42:21+05:00",
            "date_modified": "2025-01-06T17:13:19+05:00",
            "tags": [
                "post",
                "менеджмент",
                "подборка",
                "проекты"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Thu, 21 Nov 2024 22:42:21 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "132891",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "132641",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/parus-wayfinding\/",
            "title": "Элементы навигации для станции «Парус»",
            "content_html": "<p>Ещё проект,  <a href=\"https:\/\/ilyabirman.ru\/parus\/\">элементы навигации для водной станции «Парус»<\/a>:<\/p>\n<div class=\"e2-text-picture\">\n<a href=\"https:\/\/ilyabirman.ru\/parus\/\" class=\"e2-text-picture-link\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/parus-map.jpg\" width=\"920\" height=\"651\" alt=\"\" \/>\n<\/a><\/div>\n",
            "date_published": "2024-11-11T11:43:24+05:00",
            "date_modified": "2024-12-18T20:09:58+05:00",
            "tags": [
                "навигация",
                "проекты",
                "релиз"
            ],
            "author": {
                "name": "Илья Бирман",
                "url": "https:\/\/ilyabirman.ru\/meanwhile\/",
                "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
            },
            "_date_published_rfc2822": "Mon, 11 Nov 2024 11:43:24 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "132641",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "132444",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/wb-suppliers-wayfinding\/",
            "title": "Навигация для поставщиков «Вайлдберрис»",
            "content_html": "<p>Рассказал об огромном проекте — <a href=\"https:\/\/ilyabirman.ru\/wb\/suppliers\/\">навигации для поставщиков «Вайлдберрис»<\/a>.<\/p>\n<div class=\"e2-text-picture\">\n<a href=\"https:\/\/ilyabirman.ru\/wb\/suppliers\/\" class=\"e2-text-picture-link\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/wb-wall-kl@fx.jpg\" width=\"1500\" height=\"1002\" alt=\"\" \/>\n<\/a><\/div>\n<p>Почитайте. Там главное — сам подход. Навигация — это не таблички нарисовать, а придумать весь сценарий, как человек что-то находит, и даже как он вообще понимает, что ему надо искать. В проект вошли и таблички, и схемы, и печатные инструкции, и мобильный сайт, и светодиодное табло, и банер. И это всё — системно для кучи разных складов.<\/p>\n",
            "date_published": "2024-10-28T14:03:25+05:00",
            "date_modified": "2024-10-28T14:06:01+05:00",
            "tags": [
                "Вайлберрис",
                "навигация",
                "проекты",
                "релиз"
            ],
            "author": {
                "name": "Илья Бирман",
                "url": "https:\/\/ilyabirman.ru\/meanwhile\/",
                "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
            },
            "_date_published_rfc2822": "Mon, 28 Oct 2024 14:03:25 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "132444",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "131939",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/tashkent-metro-official-map\/",
            "title": "Официальная схема метро Ташкента",
            "content_html": "<div class=\"e2-text-picture\">\n<a href=\"https:\/\/ilyabirman.ru\/tashkent-metro\/map-2\/\" class=\"e2-text-picture-link\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/tashkent-metro-girls.jpg\" width=\"1200\" height=\"800\" alt=\"\" \/>\n<\/a><\/div>\n<p>Наша новая версия схемы метро Ташкента <a href=\"https:\/\/ilyabirman.ru\/tashkent-metro\/map-2\/\">принята в качестве официальной<\/a>.<\/p>\n",
            "date_published": "2024-10-14T11:28:33+05:00",
            "date_modified": "2024-10-14T11:28:21+05:00",
            "tags": [
                "проекты",
                "релиз",
                "схемы метро",
                "Ташкент"
            ],
            "author": {
                "name": "Илья Бирман",
                "url": "https:\/\/ilyabirman.ru\/meanwhile\/",
                "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
            },
            "_date_published_rfc2822": "Mon, 14 Oct 2024 11:28:33 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "131939",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "129230",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/unicorn-blitz\/",
            "title": "Блиц-редизайн сайта «Уникорн»",
            "content_html": "<p>Запилили <a href=\"https:\/\/ilyabirman.ru\/unicorn\/\">блиц-редизайн сайта «Уникорн»<\/a>:<\/p>\n<div class=\"e2-text-picture\">\n<a href=\"https:\/\/ilyabirman.ru\/unicorn\/\" class=\"e2-text-picture-link\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/unicorn-blitz-cover.jpg\" width=\"1200\" height=\"936\" alt=\"\" \/>\n<\/a><\/div>\n<p>Повысили конверсию на 20% среди новых покупателей и на 13% среди возвращающихся. Приходите тоже за блиц-редизайном.<\/p>\n",
            "date_published": "2024-07-08T18:21:11+05:00",
            "date_modified": "2024-07-08T18:20:24+05:00",
            "tags": [
                "веб-дизайн",
                "дизайн",
                "проекты",
                "работа"
            ],
            "author": {
                "name": "Илья Бирман",
                "url": "https:\/\/ilyabirman.ru\/meanwhile\/",
                "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
            },
            "_date_published_rfc2822": "Mon, 08 Jul 2024 18:21:11 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "129230",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "126127",
            "url": "https:\/\/artemushanov.ru\/?go=all\/pro-yuzkeysy\/",
            "title": "Про юзкейсы (+ шаблон)",
            "content_html": "<p>Юзкейсы — отличный инструмент для верхнеуровневого описания требований к системе. Проектники\/продакты постарше считают их устаревшими, помладше — слышали само слово, но значения не знают. Попробуем исправить ситуацию.<\/p>\n<p>В софтверной разработке я не встречал лучшего метода описания требований к системе, однозначно понимаемого и бизнесом, и инженерами. Отсутствие такого метода мешает работать сразу в двух направлениях: «вверх» — утрясти требования в очень кратком виде со спонсором и другими внешними ролями; и «вниз» — передать согласованные требования системным аналитикам для разработки детальных спецификаций и сценариев.<\/p>\n<p>Возьмем совсем недавнее прошлое. В Сonstructor Tech у нас не было юзкейсов, мы использовали такую иерархию, от крупного к мелкому:<\/p>\n<p><tt>Capability → User scenario → Epic → User Story → Task<\/tt><\/p>\n<p><i>Epic<\/i>, <i>User Story<\/i> и <i>Task<\/i> — это описания для разработчиков, разного уровня детализации. <i>User scenario<\/i> используется в рудиментарном виде: «Юзер создает структуру курса». <i>Capability<\/i> просто описывает функциональный кусок продукта — Video conference, User registration, Notes taking и т. п.<\/p>\n<p>Вопрос: список каких сущностей из представленных позволит понять (и объяснить), а что за систему мы делаем? Список Capabilities не дает понимания ценности — это просто список фич. Сценарии лежат в правильном направлении, но малоинформативны и лишены формальности. Юзер-стори — это вообще однострочная напоминалка для аналитика «надо бы обсудить с разработчиками», в них почти ноль информации.<\/p>\n<p>Вот и приходилось для общения с топ-менеджерами либо изобретать методы описания на ходу, либо пользоваться какими-то из перечисленных выше сущностей, со всеми сопутствующими проблемами.<\/p>\n<p>Так что вот мой хот тейк: ничего лучше юзкейсов для упомянутых целей не придумали. Функциональная конфигурация системы хорошо описывается набором юзкейсов, а для взгляда сверху можно нарисовать UML-диаграммы с двумя сущностями (акторы и юзкейсы) и одним типом отношения «инициирует»:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reinkarnaciya-yuzkeysov-1.png\" width=\"771\" height=\"696\" alt=\"\" \/>\n<div class=\"e2-text-caption\"><a href=\"https:\/\/queue.acm.org\/detail.cfm?id=3631182\">https:\/\/queue.acm.org\/detail.cfm?id=3631182<\/a><\/div>\n<\/div>\n<p>Юзкейсы — довольно простой метод описания, он будет понятен не-экспертам. При этом он достаточно емкий, чтобы из него можно было вывести детальные требования и тест-кейсы. Это меня поначалу отпугивало: казалось, что такая простота не принесет пользы. Это оказалось не так, да и вообще мне пришлось сменить парадигму — простые инструменты обычно работают лучше, чем сложные. Но это история для <a href=\"https:\/\/artemushanov.ru\/?go=all\/sila-prostoty\/\">отдельного поста<\/a>.<\/p>\n<h3>Что такое «юзкейс»<\/h3>\n<p>Вот пример юзкейса:<\/p>\n<div style=\"border-radius: 25px; border:1px solid #DCDCDC;padding:20px;margin:20px;\"><p><b>Покупка автобусного билета<\/b><\/p>\n<p>Главный актор: пассажир автобуса<\/p>\n<p><i>Основной сценарий:<\/i><\/p>\n<ol start=\"1\">\n<li>Пассажир запускает приложение для покупки билетов<\/li>\n<li>Система проверяет наличие предыдущего билета<\/li>\n<li>Пассажир заказывает и оплачивает билет<\/li>\n<li>Система подтверждает покупку и показывает купленный билет внутри приложения<\/li>\n<\/ol>\n<p><i>Альтернативные сценарии<\/i><br \/>\n<tt>1а.<\/tt> У пассажира на устройстве нет подключения к сети: система выводит предупреждение.<br \/>\n<tt>2а.<\/tt> Есть предыдущий билет: система предлагает воспользоваться предыдущим билетом.<br \/>\n<tt>3а.<\/tt> У Пассажира нет подключенных методов оплаты: предложить привязать карту или оплатить со счета на мобильном.<br \/>\n<tt>3б.<\/tt> На выбранном средстве оплаты недостаточно средств: система выводит уведомление и предлагает использовать другой платежный метод.<br \/>\n<tt>3в.<\/tt> У пассажира пропала связь во время покупки билета: система выводит предупреждение и автоматически продолжает процесс после восстановления связи.<\/p>\n<\/div><p>В юзкейсе есть следующие обязательные элементы:<\/p>\n<ol start=\"1\">\n<li>Название юзкейса — должно отражать цель основного актора<\/li>\n<li>Основной актор — тот, кто инициирует сценарий<\/li>\n<li>Описание сценария — короткое описание шагов к цели с указанием акторов<\/li>\n<li>Описание альтернатив — короткое описание альтернативных под-сценариев в случае, когда что-то идет не как задумано.<\/li>\n<\/ol>\n<p class=\"note\">«This is the approach taken by Use-Case 2.0, where the use cases are sliced up to provide suitably sized work items, and where the system itself evolves slice by slice.» — Ivar Jacobson, Ian Spence, and Brian Kerr<\/p>\n<p>Позже, в <a href=\"https:\/\/queue.acm.org\/detail.cfm?id=2912151\">Use Case 2.0<\/a>, были добавлены «слайсы» — сущности, описывающие полную или частичную реализацию конкретного шага сценария из юзкейса. Для удобства их можно считать юзерсторями или спеками на разработку. Они должны содержать детальные сценарии, макеты интерфейса и системные требования для однозначного понимания разработчиками.<br \/>\nСлайсы собираются в продуктовые инкременты:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reinkarnaciya-yuzkeysov.png\" width=\"720\" height=\"585\" alt=\"\" \/>\n<div class=\"e2-text-caption\"><a href=\"https:\/\/queue.acm.org\/detail.cfm?id=2912151\">https:\/\/queue.acm.org\/detail.cfm?id=2912151<\/a><\/div>\n<\/div>\n<p>С учетом слайсов, реализация строилась так:<\/p>\n<ol start=\"1\">\n<li>Определяем акторов — в этом нам поможет заранее составленный список ролей<\/li>\n<li>Пишем юзкейсы; вычитываем их — продумываем корнер кейсы, ветвления и т. п.<\/li>\n<li>Придумываем тест-кейсы<\/li>\n<li>Выводим слайсы, мапим их на шаги юзкейсов<\/li>\n<li>Ищем такие слайсы, которые способны доставить ценность, будучи разработанными и внедренными; приоритезируем, запускаем в работу.<\/li>\n<\/ol>\n<p>В итоге получаем список юзкейсов, который легко представить в виде диаграммы, и список продуктовых инкрементов, составленных из слайсов.<\/p>\n<h3>Сравнение с другими подходами<\/h3>\n<p>Теперь сравним юзкейсы с другими упомянутыми форматами.<\/p>\n<p>Эпики — это просто «большие юзер-стори», не влезающие в один спринт, они в основном служили аггрегатором сторей. У них нет общепринятого формата и понятных рамок, зато они неплохо подходят как агрегаторы для юзер-сторей. Юзкейсы со слайсами легко заменяют эпики, так как описывают понятный кусок ценности и точно так же служат источником детальных требований.<\/p>\n<p>Юзер-стори — это, как пишет сам изобретатель юзкейсов Ивар Якобсон, «просто напоминалка обсудить задачу с разработчиками». Как и многие артефакты из скрама, они подразумевают плотное взаимодействие членов команды и приоритет рабочих продуктов над документацией. В «Констракторе» использовался <a href=\"https:\/\/www.wunderdog.io\/blog\/scrum-or-scrumbut\">скрамбат<\/a>, каждая продуктовая команда писала юзер стори в своем формате, и обычно они содержали краткое описание, сценарий и набор требований. Такой формат слишком подробен для спонсора проекта и других внешних ролей. Юзкейсы работают на пару уровней абстракции выше и потому дают возможность окинуть систему орлиным взором.<\/p>\n<p>«Сценарии» не были формализованы, хотя теоретически они лучше всего подходили для такой роли. Описание вида «юзер регистрируется в системе» или «автор добавляет в курс ричтекст-документ» позволяло понять систему в целом, но в то же время оставляло много пространства для интерпретаций внешними проектными ролями и не помогало аналитику разработать детальные требования.<\/p>\n<p>Capabilities — это способ описать функциональность продукта через укрупнение, т. е. мы рассовываем все функции по некоторым блокам по принципу схожести и эти блоки обзываем «функциональностями». В таком методе описания нет ничего про цели и задачи пользователя.<\/p>\n<p>Можно еще вспомнить <a href=\"https:\/\/en.wikipedia.org\/wiki\/Concept_of_operations\">Concept of Operations<\/a> или <a href=\"https:\/\/en.wikipedia.org\/wiki\/Product_requirements_document\">PRD<\/a>, но они все равно состоят из каких-то атомарных элементов, которые придется подобрать.<\/p>\n<h3>Преимущества юзкейсов<\/h3>\n<p>Два главных плюса юзкейсов — их легко писать и читать. Они написаны естественным языком, в них используется минимум абстракций (актор и система), формат пошагового сценария интуитивно понятен почти любому.<\/p>\n<p>Из легкости восприятия следует третий важный плюс: юзкейсы можно использовать для согласования требований с внешними проектными ролями. Любой из них читается за пару минут и детально понимается еще за пять-семь. Потом так же легко правится — можно убрать, добавить или поменять шаги сценария, дописать альтернативные подсценарии, поменять акторов.<\/p>\n<p>Ну и четвертый важный плюс — юзкейсы служат хорошей основой для разработки тест-кейсов и детальных требований. Альтернативные подсценарии отлично помогают предварительно оценить корнер-кейсы — юзер-стори такого предложить точно не могут.<\/p>\n<p>Еще юзкейсы хорошо комбинируются с JTBD: конкретные «работы» из дерева работ становятся целями акторов и названиями для юзкейсов. «Работы» отвечают на вопрос «зачем», а юзкейсы — на вопрос «как».<\/p>\n<p>А еще юзкейсы, будучи абстрагированными от конкретных технологий или методов реализации (они определяются в слайсах и спеках), подходят для описания требований к не-софтверным системам — физическим изделиям и организациям.<\/p>\n<p>А устаревшими они кажутся потому, что придумали их в 1986 году.<\/p>\n<h3>Вывод и шаблон<\/h3>\n<p>Юзкейсы лучше других форматов помогают создать промежуточный уровень требований. Они хорошо подходят для согласования «вверх» с внешними проектными ролями и «вниз» для трассировки на детальные технические требования.<\/p>\n<p>Я собрал шаблон юзкейса на табличках в Coda — пользуйтесь: <a href=\"https:\/\/coda.io\/d\/_doQsmLCExBJ\/Readme-txt_suWOA\">https:\/\/coda.io\/d\/_doQsmLCExBJ\/Readme-txt_suWOA<\/a><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/reinkarnaciya-yuzkeysov-2.png\" width=\"1666\" height=\"856\" alt=\"\" \/>\n<\/div>\n<p>Шаблон предполагается использовать для создания и трекинга юзкейсов в рамках одного проекта.<\/p>\n<h3>Ссылки<\/h3>\n<ol start=\"1\">\n<li>Use Cases are Essential — <a href=\"https:\/\/queue.acm.org\/detail.cfm?id=3631182\">https:\/\/queue.acm.org\/detail.cfm?id=3631182<\/a><\/li>\n<li>Use-Case Foundation — <a href=\"https:\/\/ss-usa.s3.amazonaws.com\/c\/308454236\/media\/245965ce1f5b9890898305669066035\/Use%20Case%20Foundation.pdf\">https:\/\/ss-usa.s3.amazonaws.com\/c\/308454236\/media\/245965ce1f5b9890898305669066035\/Use%20Case%20Foundation.pdf<\/a><\/li>\n<li>Use-Case 2.0 — <a href=\"https:\/\/queue.acm.org\/detail.cfm?id=2912151\">https:\/\/queue.acm.org\/detail.cfm?id=2912151<\/a><\/li>\n<li>Use Cases are Essential — Essence for Agility MeetUp November 2023 (with Dr. Alistair Cockburn) — <a href=\"https:\/\/www.youtube.com\/watch?v=QqKcuXB8PDo\">https:\/\/www.youtube.com\/watch?v=QqKcuXB8PDo<\/a><\/li>\n<\/ol>\n",
            "date_published": "2024-03-03T01:07:39+05:00",
            "date_modified": "2025-09-04T19:43:42+05:00",
            "tags": [
                "post",
                "методика",
                "проекты"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Sun, 03 Mar 2024 01:07:39 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "126127",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "125746",
            "url": "https:\/\/artemushanov.ru\/?go=all\/otchet-chaos-report-2020\/",
            "title": "Отчет CHAOS Report 2020",
            "content_html": "<p>Обзор отчета, на который я наткнулся <a href=\"https:\/\/hennyportman.wordpress.com\/2021\/01\/06\/review-standish-group-chaos-2020-beyond-infinity\">в блоге Хенни Портмана<\/a>.<\/p>\n<p>Отчет называется «<a href=\"https:\/\/standishgroup.myshopify.com\/collections\/frontpage\/products\/copy-of-chaos-report-beyond-infinity-digital-version\">CHAOS 2020: Beyond Infinity<\/a>», и судя по всему — это последний отчет группы такого формата.<\/p>\n<h3>Факторы успешности<\/h3>\n<p>Основными факторами успешности (Factors of success) в версии 2020 являются <i>хороший спонсор<\/i>, <i>хорошая команда<\/i> и «<i>хорошее место<\/i>». На самом деле это мета-факторы, внутри которых по десятку более мелких принципов:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/project-success-qrc-standish-group-chaos-report-2020-(1).png\" width=\"1920\" height=\"1080\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Картинка из поста <a href=\"https:\/\/hennyportman.wordpress.com\/2021\/01\/06\/review-standish-group-chaos-2020-beyond-infinity\">Хенни Портмана<\/a><\/div>\n<\/div>\n<p><i>Хороший спонсор (The Good Sponsor)<\/i><br \/>\nДуша проекта (так и пишут!) и обязательное условие для существования проекта. Спонсор существует на стороне заказчика проекта или выгодополучателя проектных результатов, его задача — предоставлять необходимые ресурсы и поддержку проекту и проектной команде. Спонсор отвечает за выделение бюджета и других ресурсов, контроль исполнения проекта, соответствие проектных целей стратегическим задачам компании-заказчика. Спонсор у команды проекта может быть всего один — но <a href=\"https:\/\/artemushanov.ru\/?go=all\/pro-proekty-i-roli\/#:~:text=%D0%92%D0%B0%D0%B6%D0%BD%D0%BE%20%D1%83%D0%BC%D0%B5%D1%82%D1%8C%20%D0%BE%D1%82%D0%BB%D0%B8%D1%87%D0%B0%D1%82%D1%8C%20%D0%B0%D0%BA%D1%82%D0%B5%D1%80%D0%B0%20%D0%BE%D1%82%C2%A0%D1%80%D0%BE%D0%BB%D0%B8%2C%20%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%83%D1%8E%20%D0%BE%D0%BD%20%D0%B8%D0%B3%D1%80%D0%B0%D0%B5%D1%82\">поскольку это роль<\/a>, следует понимать, что представлен спонсор может быть целой группой людей.<\/p>\n<blockquote>\n<p>Пример: если вы занимаетесь внедрением и доработкой CRM-систем, то в проекте внедрения новому клиенту вашим спонсором может быть, например, директор по продажам. Он кровно заинтересован в том, чтобы CRM-система отвечала требованиям отдела продаж и помогала лучше работать, поэтому готов тратить силы и время на выбивание бюджета, тормошение службы безопасности и своих айтишников ради того, чтобы проектные задачи решались вовремя.<\/p>\n<\/blockquote>\n<p>Я бы определил спонсора как точку входа, некую оптическую призму. Проектная группа пуляет в спонсора лучом своего запроса — спонсор раскладывает запрос на составляющие «цвета» и отправляет, к примеру, бюджетный запрос — в финансовый отдел, айтишные вопросы — к айтишникам, вопросы согласования требований — к будущим пользователям. И трясет всех, пока те не ответят.<\/p>\n<p><i>Хорошая команда (The Good Team)<\/i><br \/>\nКоманда — это производители проектного результата. ПМ, разработчики, инженеры по требованиям, служба контроля качества, и так далее. Команда должна быть маленькой (см. предыдущий пост), работать по аджайлу, быть профессиональной и в выборе метода, и в прикладных вопросах.<\/p>\n<p><i>Хорошее место (The Good Place)<\/i><br \/>\nПод «хорошим местом» подразумевается «человеческое пространство», в котором существует проект. Это — все люди, которые так или иначе касаются проекта в процессе его жизни и при этом не являются частью команды или спонсором. Задача компании — улучшать навыки тех, кто представляет собой это «хорошее место», чтобы проекты в компании имели больший шанс на успех.<\/p>\n<p>Из трех факторов самым простым в управлении считается спонсор, на втором месте — команда, на третьем — «хорошее место». Decision latency находится в ведении спонсора и «места».<\/p>\n<h3>Развенчанные мифы<\/h3>\n<p><i>Myths and illusions<\/i> — интересный раздел, я его уже упоминал в блоге. В нем группа развенчивает популярные в проектной среде мифы, подкрепляя свои тезисы данными из собственных исследований.<\/p>\n<p>Хенни приводит в пример четыре мифа, в которые пора перестать верить:<\/p>\n<ul>\n<li>В успешных проектах обязательно участвует высококвалифицированный менеджер проекта<\/li>\n<li>Инструменты управления проектами способствуют успеху проекта<\/li>\n<li>Все проекты должны иметь четкие бизнес-цели<\/li>\n<li>Неполные требования являются причиной проблемных и неудачных проектов.<\/li>\n<\/ul>\n<h3>Эпилог<\/h3>\n<p>Это такой пункт в отчете — <i>The Epilogue<\/i>. В нем рассматривается история проектных подходов в разработке софта в четырех периодах:<\/p>\n<ol start=\"1\">\n<li>«Дикий Запад» (1960-80) — методик нет или все изобретают свои, проекты ведутся «как-то».<\/li>\n<li>«Водопад» (1980-2000) — выполнение перечня работ с разбивкой на явные последовательные фазы, строго по порядку.<\/li>\n<li>«Эджайл» (2000 и скоро закончится) — проекты разбиваются на маленькие управляемые кусочки,  фокус на гибкость и возможность поменять ход разработки в любой момент.<\/li>\n<li>«Бесконечный поток» (Infinite Flow Period) — еще не начался, но уже вот-вот. Продлится тоже около 20 лет.<\/li>\n<\/ol>\n<p>Метод потока подразумевает отказ от проектов в принципе. Новые фичи и функции в виде описаний запускаются в некий «конвейер разработки», на выходе из которого — продуктовые инкременты в готовом виде. Проектов и сопутствующих им ролей больше нет — ни проектных менеджеров, ни требований в привычном виде, ни стори поинтов, ни планирований с релизами. Разработка из «development» превращается в «manufacturing». Если раньше проект был бутылкой воды, то в режиме потока вода просто льется из крана.<\/p>\n<p>Утверждается, что подобная организация работы позволит сократить до 90% накладных расходов при сохранении результата.<\/p>\n<p>Идея смелая и очевидная, но если по чесноку — даже аджайл не везде еще прижился. Такой подход, с краном вместо ящика бутылок, могут потянуть гранды вроде Амазона (35 тыс. разработчиков) или молодые компании, начинающие с нуля и живущие без легаси.<\/p>\n<h3>Видео <a href=\"https:\/\/youtu.be\/W4tmgk2QZBw\">CHAOS 2020: Beyond Infinity<\/a><\/h3>\n<p>Есть еще вот такое ↑ видео трехлетней давности, там один из участников Standish Group Ганс Малдер раскрывает некоторые детали из отчета. Приведу пару моментов.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/otchet-chaos-report-2020.png\" width=\"1530\" height=\"1118\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Аджайл круче водопада<\/div>\n<\/div>\n<p>Любопытные подробности: мелкие проекты в два раза чаще проваливаются, если работать по водопадной модели, а крупные — всего в полтора; средние проекты, сделанные по аджайлу, в три раза чаще завершаются успехом, чем сделанные по водопаду.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/otchet-chaos-report-2020-1.png\" width=\"1946\" height=\"1378\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Move fast<\/div>\n<\/div>\n<p>Good Decision Latency — это когда решения принимаются быстро, а Poor — когда долго, <a href=\"https:\/\/artemushanov.ru\/?go=all\/otchet-chaos-report-2018\/#:~:text=Factors%20of%C2%A0Success-,Decision%20Latency%20Theory,-%D0%9A%D0%BB%D0%B8%D0%BA%D0%B1%D0%B5%D0%B9%D1%82%3A%20%D1%87%D1%82%D0%BE%D0%B1%D1%8B%20%D1%83%D0%BB%D1%83%D1%87%D1%88%D0%B8%D1%82%D1%8C\">было в прошлом отчете<\/a>. Разница поразительная : быстрые решения <b>в десять раз<\/b> уменьшают вероятность зафейлить проект и почти <b>в четыре раза<\/b> увеличивают вероятность успешно завершить проект.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/otchet-chaos-report-2020-2.png\" width=\"2024\" height=\"1368\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Сколько стоят задержки принятия решений<\/div>\n<\/div>\n<p>Разница в накладных расходах на принятие решений у команд с High-скиллом и Poor-скиллом примерно десятикратная.<\/p>\n",
            "date_published": "2024-02-03T13:47:27+05:00",
            "date_modified": "2024-02-03T18:18:21+05:00",
            "tags": [
                "post",
                "методика",
                "проекты"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Sat, 03 Feb 2024 13:47:27 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "125746",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "125724",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/tashkent-metro-map\/",
            "title": "Схема метро Ташкента",
            "content_html": "<p>Запилили с Тимуром Репиным <a href=\"https:\/\/ilyabirman.ru\/tashkent-metro\/\">схему метро Ташкента<\/a>:<\/p>\n<div class=\"e2-text-picture\">\n<a href=\"https:\/\/ilyabirman.ru\/tashkent-metro\/\" class=\"e2-text-picture-link\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/tashkent-metro-train.jpg\" width=\"1200\" height=\"900\" alt=\"\" \/>\n<\/a><\/div>\n",
            "date_published": "2024-02-01T20:27:59+05:00",
            "date_modified": "2024-02-01T20:27:55+05:00",
            "tags": [
                "дизайн",
                "проекты",
                "релиз",
                "транспортные схемы"
            ],
            "author": {
                "name": "Илья Бирман",
                "url": "https:\/\/ilyabirman.ru\/meanwhile\/",
                "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
            },
            "_date_published_rfc2822": "Thu, 01 Feb 2024 20:27:59 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "125724",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "125640",
            "url": "https:\/\/artemushanov.ru\/?go=all\/otchet-chaos-report-2018\/",
            "title": "Отчет CHAOS Report 2018",
            "content_html": "<p>Каждые два года исследовательская группа <a href=\"https:\/\/www.standishgroup.com\/about\">Standish Group<\/a> публикует отчет по проектной деятельности в разработке софта под названием <i>CHAOS Report<\/i>. Аббревиатура расшифровывается как Comprehensive Human Appraisal for Originating Software — т. е. все про человеческий фактор в проектах.<\/p>\n<p>Отчет строится на основе собственных исследований: группа собирает данные с большого количества проектов в разных отраслях (я встречал цифру в 50&#8239;000 проектов), проводит интервью с проектными командами, руководителями и клиентами, и делает выводы.<\/p>\n<p>В отчете проекты обычно делятся на три группы: successful, challenged, failed — успешные, проблемные и неудачные. «Успешный» — это проект, который завершен в срок и в рамках бюджета, с реализацией всех заявленных возможностей и функций. Проект «с проблемами» завершен, но его сроки и бюджет превышены и он реализовал не все заявленные возможности. «Неудачный» проект отменяется в какой-то момент в процессе разработки.<\/p>\n<p>Каждый новый отчет проверяет существующие и выявляет новые факторы, влияющие на успешность проекта. Отчет, вышедший в 2018, называется «Decision Latency Theory: It’s all about interval», значительная его часть посвящена теории задержки принятия решений.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/otchet-chaos-report-2018-2.png\" width=\"600\" height=\"600\" alt=\"\" \/>\n<\/div>\n<p>Я этот отчет не покупал (400 евро 🥲), а прочитал и посмотрел несколько его обзоров, начал с <a href=\"https:\/\/hennyportman.wordpress.com\/2020\/01\/03\/review-chaos-report-2018\/\">поста в блоге<\/a> Хенни Портмана.<\/p>\n<p>В отчете пять разделов:<\/p>\n<ol start=\"1\">\n<li>Decision Latency Theory<\/li>\n<li>Winning Hand<\/li>\n<li>Classic CHAOS<\/li>\n<li>Factors of Success,<\/li>\n<li>Skills of the Factors of Success<\/li>\n<\/ol>\n<h3>Decision Latency Theory<\/h3>\n<p>Кликбейт: чтобы улучшить состояние проекта на 25%, нужно научиться быстро принимать решения (примерно об этом же пишет и <a href=\"https:\/\/artemushanov.ru\/?go=tags\/pd-flow\/\">Рейнертсен<\/a>).<\/p>\n<p>Основной тезис раздела звучит так:<\/p>\n<p class=\"loud\">The value of the interval is greater than the quality of the decision.<\/p>\n<p>Я это понимаю так: если мы принимаем решения быстро и умеем не менее быстро понять, что какое-то решение было плохое, то мы можем перебрать больше решений за единицу времени. «Быстро понять, что какое-то решение было плохое» — это второй важный навык внутри первого, потому что нет смысла перебирать много решений, если мы не понимаем, какое из них — хорошее, а какое — нет.<\/p>\n<p>Группа Стендиш предлагает прикольную эмпирическую метрику: <mark>проект порождает одно решение на тысячу долларов проектных трудозатрат<\/mark>. Если в проекте на одно решение приходится не одна, а две тысячи трудозатрат — значит, решения принимаются дольше, чем это возможно.<\/p>\n<p>«Решением» здесь может быть любой выбор из какого-то количества альтернатив, способный повлиять на дальнейший ход проекта, его «выхлоп» или метод работы.<\/p>\n<p>В остальном советы все те же, что и у Рейнертсена: децентрализовать принятие решений, придумать фреймворк для быстрой проверки их качества (деньги!), устранить ненужные активности — эскалацию любого вопроса на начальство, митинги и созвоны по любому поводу и т. д.<\/p>\n<h3>Winning Hand<\/h3>\n<p>Winning hand — это выигрышная комбинация из покера, только в случае отчета она состоит из набора факторов, характерных для успешных проектов.<\/p>\n<p>Факторы по версии предыдущего отчета (2016) следующие, в порядке уменьшения значимости:<\/p>\n<ul>\n<li>Проект должен быть небольшим; чем меньше проект — тем он более управляемый и понятный, тем меньше требуется усилий для его координации;<\/li>\n<li>Спонсор проекта должен быть опытным и грамотным; «спонсор» — это роль над проектной командой, его область ответственности — помогать команде с ресурсами, взаимодействовать с некоторыми внешними ролями и «женить» курс проекта со стратегией компании;<\/li>\n<li>Процесс должен быть по аджайлу (в общем смысле); аджайл лучше приспособлен для частой смены приоритетов и для быстрого добавления кусочков ценности к продукту;<\/li>\n<li>Команда должна хорошо уметь и в аджайл, и в технологии — т. е. уметь всесторонне отвечать на вопрос «как сделать?»;<\/li>\n<li>Организация должна быть «эмоционально зрелой»: уметь справляться с конфликтами, неопределенностью и стрессом.<\/li>\n<\/ul>\n<p>Чем больше факторов из списка вы можете обнаружить в своем проекте — тем лучше.<\/p>\n<p>В новом отчете на первом месте decision latency, на втором месте — небольшой проект, на третьем — сильный спонсор. В новых проектах следует в первую очередь работать именно над ними.<\/p>\n<h3>Classic CHAOS<\/h3>\n<p>У отчета изначально было три фактора, определяющих успешность проекта: вовремя, в рамках бюджета, выполнено все задуманное.<br \/>\nРазбивка по исследованным проектам за 2017 была такая:<\/p>\n<ul>\n<li>36% — успешные<\/li>\n<li>45% — проблемные<\/li>\n<li>19% — провалившиеся.<\/li>\n<\/ul>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/otchet-chaos-report-2018.png\" width=\"1342\" height=\"964\" alt=\"\" \/>\n<\/div>\n<p>В отчете вводится новая градация успешности проекта — pure success, «чистый успех». Это комбинация высокого уровня удовлетворенности клиента и высокого возврата инвестиций у исполнителя.<\/p>\n<p>Там пропорция другая:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/artemushanov.ru\/pictures\/otchet-chaos-report-2018-1.png\" width=\"1658\" height=\"964\" alt=\"\" \/>\n<\/div>\n<p>В отчете приводится разбивка проектов по отраслям, самый высокий процент успешных в банках, самый низкий — в телекоме.<\/p>\n<h3>Factors of Success и Skills of the Factors of Success<\/h3>\n<p>Факторов обычно десять, три главных в отчете — все те же decision latency, размер проекта и сильный спонсор.<\/p>\n<p>Для каждого фактора приводится набор из пяти практик (навыков, способностей), способствующих его развитию.<\/p>\n<p>К примеру, для уменьшения задержки принятия решений практики следующие: уменьшение времени между решениями, быстрое принятие решений, распределение решений (децентрализация), быстрый консенсус (умение быстро договаривать между собой разных стейкхолдеров), конвейер решений.<\/p>\n<h3>Заключение<\/h3>\n<p>Мне самым полезным в отчете показались факторы, характерные для успешных проектов — задержка решений, маленький проект, сильный спонсор. Если бы меня спросили про факторы успешности проекта, до прочтения обзора я бы точно назвал другие — что-то вроде «хорошей команды», «точных требований» и прочих банальностей.<\/p>\n",
            "date_published": "2024-01-26T02:55:10+05:00",
            "date_modified": "2024-02-03T02:30:17+05:00",
            "tags": [
                "post",
                "методика",
                "проекты"
            ],
            "author": {
                "name": "Артем Ушанов",
                "url": "https:\/\/artemushanov.ru\/",
                "avatar": "https:\/\/artemushanov.ru\/pictures\/userpic\/userpic@2x.jpg?1722359928"
            },
            "_date_published_rfc2822": "Fri, 26 Jan 2024 02:55:10 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "125640",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "125602",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/alfa-medical-video\/",
            "title": "Разбор дизайна сайта компании «Альфа-Медикал»",
            "content_html": "<p>Недавно я выложил на сайте рассказ <a href=\"https:\/\/ilyabirman.ru\/alfa-medical\/\">о дизайне сайта компании «Альфа-Медикал»<\/a>. Теперь снял про него более подробное видео. Рассказываю о том, почему он именно такой, что нужно было в нём учесть. Видео будет полезно дизайнерам и интернет-предпринимателям:<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/xaEn82FX64A?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<p>\n00:00 Интро и что за компания «Альфа-Медикал»<br \/>\n03:46 Схема «Вы — Мы» — визуализация роли компании<br \/>\n04:24 Информативное главное меню сайта<br \/>\n05:02 Приёмы управления вниманием в большой текстовой странице<br \/>\n05:57 В основе сайта — ситуации<br \/>\n07:44 Этаж про деньги<br \/>\n11:06 Работа над текстом и согласование с клиентом<br \/>\n11:51 Котекстные отзывы как ещё один способ разнообразить  подачу<br \/>\n12:49 Этаж про компетентность<br \/>\n13:23 Плавающая кнопка с телефоном<br \/>\n14:02 Страница ситуации<br \/>\n19:24 Шаблонизация и переиспользование текста в ситуациях<br \/>\n21:36 Зачем каждой ситуации нужна своя страница: забота и сео в одном<br \/>\n23:01 Страница «Команда» тоже не про команду, а про клиента<br \/>\n24:52 Страница «Контакты» помогает решиться обратиться в компанию<br \/>\n26:10 Мобильная версия — полноценная, и даже меню не спрятано<br \/>\n26:54 Итоги и как поработать со мной<br \/>\n<\/p>\n<\/div>\n",
            "date_published": "2024-01-24T00:26:52+05:00",
            "date_modified": "2024-01-24T00:29:38+05:00",
            "tags": [
                "веб-дизайн",
                "видео",
                "дизайн сайтов",
                "проекты",
                "студентам"
            ],
            "author": {
                "name": "Илья Бирман",
                "url": "https:\/\/ilyabirman.ru\/meanwhile\/",
                "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
            },
            "_date_published_rfc2822": "Wed, 24 Jan 2024 00:26:52 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "125602",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "125304",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/likely-3-2\/",
            "title": "Лайкли 3.2",
            "content_html": "<p>Лайкли — клёвые социокнопки. В версии 3.2 добавилась поддержка соцсети «Икс» — это так переименовался твиттер (<tt>&lt;div class=&quot;xcom&quot;&gt;<\/tt>).<\/p>\n<p>Мы долго думали, что делать, ведь «Икс» — тупейшее название, и все говорят «Твиттер»! Решили просто: мы поддерживаем «обе соцсети». То есть вы можете на свой вкус выбрать, ставить ли себе твиттеровскую птичку или иксовый икс. Можно даже и то, и другое. Работает в любом варианте.<\/p>\n<p>Подробности:<\/p>\n<ul>\n<li><a href=\"http:\/\/ilyabirman.ru\/projects\/likely\/\">О проекте<\/a> и зип-архив<\/li>\n<li><a href=\"https:\/\/github.com\/NikolayRys\/Likely\/releases\/tag\/v3.2.0\">Гитхаб<\/a><\/li>\n<\/ul>\n<p>Лайкли ведёт <a href=\"http:\/\/linkedin.com\/in\/nikolay-rys\">Николай Рысь<\/a> (Линкед-Ин).<\/p>\n",
            "date_published": "2024-01-03T16:42:52+05:00",
            "date_modified": "2024-01-03T16:42:50+05:00",
            "tags": [
                "Лайкли",
                "продукты",
                "проекты",
                "релиз"
            ],
            "author": {
                "name": "Илья Бирман",
                "url": "https:\/\/ilyabirman.ru\/meanwhile\/",
                "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
            },
            "_date_published_rfc2822": "Wed, 03 Jan 2024 16:42:52 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "125304",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "125286",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/alfa-medical-website\/",
            "title": "Сайт «Альфа-Медикал»",
            "content_html": "<div class=\"e2-text-picture\">\n<a href=\"https:\/\/ilyabirman.ru\/alfa-medical\/\" class=\"e2-text-picture-link\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/alfa-medical-website.jpg\" width=\"1920\" height=\"960\" alt=\"\" \/>\n<\/a><\/div>\n<p><a href=\"https:\/\/ilyabirman.ru\/alfa-medical\/\">Зацените сайт для медтуроператора «Альфа-Медикал»<\/a>, задизайненный год назад. Это большая содержательная работа. Задача — помочь людям, оказавшимся в беде, разобраться в услугах компании и доверить ей своё здоровье. Проект про глубокое погружение в тему, работу с сомнениями и опасениями, заботу и внимательность к человеку.<\/p>\n",
            "date_published": "2024-01-01T20:05:48+05:00",
            "date_modified": "2024-01-01T20:05:46+05:00",
            "tags": [
                "дизайн сайтов",
                "проекты",
                "текст"
            ],
            "author": {
                "name": "Илья Бирман",
                "url": "https:\/\/ilyabirman.ru\/meanwhile\/",
                "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
            },
            "_date_published_rfc2822": "Mon, 01 Jan 2024 20:05:48 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "125286",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "123022",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/moscow-metro-map-2023-2030-23-sep\/",
            "title": "Обновление нашей схемы московского метро — сентябрь 2023",
            "content_html": "<p>В декабре 2022 года мы с Ромой Мочаловым, Никитой Дубровиным и Ди Логвиновым выпустили <a href=\"https:\/\/ilyabirman.ru\/moscow\/metro\/map\/2023\/\">нашу схему московского метро<\/a>, включающую планы до 2030 года. За прошедшие месяцы и реальность, и планы слегка изменились, поэтому нашу перспективную схему пришлось подкрутить:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/moscow-metro-map-2023-2030-23-sep-30.jpg\" width=\"1200\" height=\"1706\" alt=\"\" \/>\n<\/div>\n<p>У будущих линий 16, 17, 18 поменялись планируемые цвета:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/moscow-metro-map-2023-2030-23-sep-colors@2x.jpg\" width=\"280\" height=\"197\" alt=\"\" \/>\n<\/div>\n<p>Появилась пересадка Бутырская — Останкино:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/moscow-metro-map-2023-2030-23-sep-ostankino@2x.jpg\" width=\"800\" height=\"305\" alt=\"\" \/>\n<\/div>\n<p>Запланировалась пересадка с Аэроэкспресса на D5 на станции «Домодедово», не являющейся аэропортом (обожаю):<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/moscow-metro-map-2023-2030-23-sep-dme@2x.jpg\" width=\"400\" height=\"332\" alt=\"\" \/>\n<\/div>\n<p>Последние московские открытия в нашем случае потребовали «включения» большего числа линий на нашей схеме. Что-то, что раньше было строящимся, теперь стало работающим:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/moscow-metro-map-2023-2030-23-sep.jpg\" width=\"1200\" height=\"1706\" alt=\"\" \/>\n<\/div>\n<p>Со Внуковом у нас сразу порядок был:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/moscow-metro-map-2023-2030-23-sep-vko@2x.jpg\" width=\"400\" height=\"400\" alt=\"\" \/>\n<\/div>\n",
            "date_published": "2023-09-14T20:26:58+05:00",
            "date_modified": "2023-11-14T01:08:04+05:00",
            "tags": [
                "дизайн",
                "метро",
                "московское метро",
                "проекты",
                "релиз",
                "схема метро Москвы",
                "схемы метро"
            ],
            "author": {
                "name": "Илья Бирман",
                "url": "https:\/\/ilyabirman.ru\/meanwhile\/",
                "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
            },
            "_date_published_rfc2822": "Thu, 14 Sep 2023 20:26:58 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "123022",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "122206",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/chelyabinsk-transit-reform-communication\/",
            "title": "Информационное сопровождение Челябинской транспортной реформы",
            "content_html": "<p>Рассказал об одном из этапов <a href=\"https:\/\/ilyabirman.ru\/chelyabinsk\/reform\/\">информационного сопровождения Челябинской транспортной реформы<\/a> — информировании об изменениях маршрутов с 1 января 2022 года:<\/p>\n<div class=\"e2-text-picture\">\n<a href=\"https:\/\/ilyabirman.ru\/chelyabinsk\/reform\/\" class=\"e2-text-picture-link\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/chelyabinsk-transit-reform-communication.jpg\" width=\"1200\" height=\"600\" alt=\"\" \/>\n<\/a><\/div>\n",
            "date_published": "2023-08-08T16:06:52+05:00",
            "date_modified": "2023-08-08T16:05:30+05:00",
            "tags": [
                "дизайн",
                "проекты",
                "релиз",
                "транспорт",
                "Челябинск"
            ],
            "author": {
                "name": "Илья Бирман",
                "url": "https:\/\/ilyabirman.ru\/meanwhile\/",
                "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
            },
            "_date_published_rfc2822": "Tue, 08 Aug 2023 16:06:52 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "122206",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "122024",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/dom-toma-video\/",
            "title": "Разбор дизайна интернет-магазина «Дом Тома»",
            "content_html": "<p>Недавно я выложил на сайте рассказ <a href=\"https:\/\/ilyabirman.ru\/dom-toma\/\">о дизайне интернет-магазина «Дом Тома»<\/a>. Теперь снял про него более подробное видео. Рассказываю о том, почему он именно такой, что нужно было в нём учесть. Видео будет полезно дизайнерам и интернет-предпринимателям:<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/fuiOIJDT2aQ?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<p>\n00:00 Интро<br \/>\n02:33 Подробное главное меню: навигация и вовлечение<br \/>\n03:55 Внесение разнообразия в списки<br \/>\n06:29 Фотографии товаров в разном стиле<br \/>\n07:48 Товар представляет себя и свой отдел<br \/>\n10:03 Акции и банеры распределены по странице<br \/>\n11:56 Как показать намного больше товаров: этажи отделов<br \/>\n13:57 Строчка того, что люди ищут<br \/>\n15:20 Нестрогое разделение товаров по отделам<br \/>\n16:15 «Новые товары декабря»<br \/>\n17:11 Ещё про меню и подвал<br \/>\n18:40 Дизайн подходит для разработки<br \/>\n19:58 Инстаграм<br \/>\n20:50 Мобильная версия олжна быть полноценной, а не урезанной<br \/>\n22:17 Как поработать со мной<br \/>\n<\/p>\n<\/div>\n",
            "date_published": "2023-08-03T10:19:41+05:00",
            "date_modified": "2024-01-23T21:29:38+05:00",
            "tags": [
                "веб-дизайн",
                "видео",
                "дизайн сайтов",
                "проекты",
                "студентам"
            ],
            "author": {
                "name": "Илья Бирман",
                "url": "https:\/\/ilyabirman.ru\/meanwhile\/",
                "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
            },
            "_date_published_rfc2822": "Thu, 03 Aug 2023 10:19:41 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "122024",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        },
        {
            "id": "120953",
            "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/dom-toma-website\/",
            "title": "Сайт «Дома Тома»",
            "content_html": "<div class=\"e2-text-picture\">\n<a href=\"https:\/\/ilyabirman.ru\/dom-toma\/\" class=\"e2-text-picture-link\">\n<img src=\"https:\/\/ilyabirman.ru\/meanwhile\/pictures\/dom-toma-cover.jpg\" width=\"1200\" height=\"600\" alt=\"\" \/>\n<\/a><\/div>\n<p>Выложил рассказ о проекте, который сделал в 2019 году — <a href=\"https:\/\/ilyabirman.ru\/dom-toma\/\">дизайн интернет-магазина «Дом Тома»<\/a>. Почитайте, там надо было исхитриться и разнообразие коллекции показать, и индивидуальность товаров. Репостните везде и приходите за хорошим дизайном!<\/p>\n",
            "date_published": "2023-06-25T15:52:19+05:00",
            "date_modified": "2023-06-25T15:52:09+05:00",
            "tags": [
                "дизайн",
                "дизайн сайтов",
                "проекты"
            ],
            "author": {
                "name": "Илья Бирман",
                "url": "https:\/\/ilyabirman.ru\/meanwhile\/",
                "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764"
            },
            "_date_published_rfc2822": "Sun, 25 Jun 2023 15:52:19 +0500",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "120953",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": null,
                "og_images": []
            }
        }
    ],
    "_e2_version": 4079,
    "_e2_ua_string": "Aegea 11.0 (v4079e)"
}