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

Интерфейс управления флотом самокатов Суперпедестриана

Илья Бирман — Fri, 18 Jul 2025 16:56:52 +0500

Рассказал о проекте, который делал больше трёх лет назад — интерфейс управления флотом самокатов Суперпедестриана:

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

Разбор дизайна навигации для поставщиков «Вайлдберрис»

Илья Бирман — Thu, 12 Jun 2025 23:53:40 +0500

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

00:00 Интро
03:16 Путь поставщика
07:30 Предыдущее светодиодное табло на складе
09:24 Табло.вб.ру
12:50 Портал поставщиков, инструкция для водителя и схемы складов
17:35 Банер и указатели ворот на складе
19:59 Улучшенное светодиодное табло
22:30 Аутро

Схема метро Самары

Илья Бирман — Mon, 09 Jun 2025 12:25:27 +0500

Илья Бирман:

С дизайнером Николаем Романовым сделали схему метро Самары:

Спасибо Серёге Чикину за герб и Леониду Мотовских за советы. Если вы из Самары, напишите, что мы где напутали.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подборка постов про управление

Артем Ушанов — Thu, 21 Nov 2024 22:42:21 +0500

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

Это подборка публиковавшихся постов про управление.

Про айти продукты — как делать продукт без роли аналитика?

Допустим, вы стали CPO. Какие ошибки не допускать на C-level и как не вылететь с позиции?

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

И еще философское — про взгляд дедушки менеджмента Питера Друкера на информационные технологии.

Навеянный сериалом The Bear текст про организацию кухни в ресторане.

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

Книга про компанию Pixar — одна из лучших, что я читал про известные компании. Из грязи в IPO, источник состояния Стива Джобса, жесткие переговоры с Диснеем.

Пост Вастрика про модерацию сообществ. Прям интересный домен — без модерации нельзя, но и напрямую всем запретить всё неправильное не получится. Приходится управлять не людьми (ну кроме модераторов), а набором правил или принципов, и никакой демократии.

Хайлайты с вебинара Анны Лубенченко про управление собственным ресурсом. Считайте часы, пользуйтесь помодоро.

Хайлайты с вебинара Алексея Каптерева про фидбек в образовании и бизнесе.

Про управление проектами

Пост про роли, чеклисты, проекты и как их обсуждать.

Обзор отчета CHAOS Report 2018 — факторы успеха в управлении проектами по разработке софта.

Обзор отчета CHAOS Report 2020 — последний (не в смысле крайний, а в смысле — больше не будет, всё) отчет группы. Факторы почти те же, авторы провозглашают конец эры проектов и начало новой эры «управления потоком».

Пост А. Турханова про вырождение понятия «проект»: раньше «проектами» считались временные предприятия с бюджетом от 20 млн долларов и штатом от 200 человек. Что потом пошло не так?

Элементы навигации для станции «Парус»

Илья Бирман — Mon, 11 Nov 2024 11:43:24 +0500

Илья Бирман:

Ещё проект, элементы навигации для водной станции «Парус»:

Навигация для поставщиков «Вайлдберрис»

Илья Бирман — Mon, 28 Oct 2024 14:03:25 +0500

Илья Бирман:

Рассказал об огромном проекте — навигации для поставщиков «Вайлдберрис».

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

Официальная схема метро Ташкента

Илья Бирман — Mon, 14 Oct 2024 11:28:33 +0500

Илья Бирман:

Наша новая версия схемы метро Ташкента принята в качестве официальной.

Блиц-редизайн сайта «Уникорн»

Илья Бирман — Mon, 08 Jul 2024 18:21:11 +0500

Илья Бирман:

Запилили блиц-редизайн сайта «Уникорн»:

Повысили конверсию на 20% среди новых покупателей и на 13% среди возвращающихся. Приходите тоже за блиц-редизайном.

Про юзкейсы (+ шаблон)

Артем Ушанов — Sun, 03 Mar 2024 01:07:39 +0500

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

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

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

Возьмем совсем недавнее прошлое. В Сonstructor Tech у нас не было юзкейсов, мы использовали такую иерархию, от крупного к мелкому:

Capability → User scenario → Epic → User Story → Task

Epic, User Story и Task — это описания для разработчиков, разного уровня детализации. User scenario используется в рудиментарном виде: «Юзер создает структуру курса». Capability просто описывает функциональный кусок продукта — Video conference, User registration, Notes taking и т. п.

Вопрос: список каких сущностей из представленных позволит понять (и объяснить), а что за систему мы делаем? Список Capabilities не дает понимания ценности — это просто список фич. Сценарии лежат в правильном направлении, но малоинформативны и лишены формальности. Юзер-стори — это вообще однострочная напоминалка для аналитика «надо бы обсудить с разработчиками», в них почти ноль информации.

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

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

https://queue.acm.org/detail.cfm?id=3631182

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

Что такое «юзкейс»

Вот пример юзкейса:

Покупка автобусного билета

Главный актор: пассажир автобуса

Основной сценарий:

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

Альтернативные сценарии
1а. У пассажира на устройстве нет подключения к сети: система выводит предупреждение.
2а. Есть предыдущий билет: система предлагает воспользоваться предыдущим билетом.
3а. У Пассажира нет подключенных методов оплаты: предложить привязать карту или оплатить со счета на мобильном.
3б. На выбранном средстве оплаты недостаточно средств: система выводит уведомление и предлагает использовать другой платежный метод.
3в. У пассажира пропала связь во время покупки билета: система выводит предупреждение и автоматически продолжает процесс после восстановления связи.

В юзкейсе есть следующие обязательные элементы:

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

«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

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

https://queue.acm.org/detail.cfm?id=2912151

С учетом слайсов, реализация строилась так:

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

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

Сравнение с другими подходами

Теперь сравним юзкейсы с другими упомянутыми форматами.

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

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

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

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

Можно еще вспомнить Concept of Operations или PRD, но они все равно состоят из каких-то атомарных элементов, которые придется подобрать.

Преимущества юзкейсов

Два главных плюса юзкейсов — их легко писать и читать. Они написаны естественным языком, в них используется минимум абстракций (актор и система), формат пошагового сценария интуитивно понятен почти любому.

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

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

Еще юзкейсы хорошо комбинируются с JTBD: конкретные «работы» из дерева работ становятся целями акторов и названиями для юзкейсов. «Работы» отвечают на вопрос «зачем», а юзкейсы — на вопрос «как».

А еще юзкейсы, будучи абстрагированными от конкретных технологий или методов реализации (они определяются в слайсах и спеках), подходят для описания требований к не-софтверным системам — физическим изделиям и организациям.

А устаревшими они кажутся потому, что придумали их в 1986 году.

Вывод и шаблон

Юзкейсы лучше других форматов помогают создать промежуточный уровень требований. Они хорошо подходят для согласования «вверх» с внешними проектными ролями и «вниз» для трассировки на детальные технические требования.

Я собрал шаблон юзкейса на табличках в Coda — пользуйтесь: https://coda.io/d/_doQsmLCExBJ/Readme-txt_suWOA

Шаблон предполагается использовать для создания и трекинга юзкейсов в рамках одного проекта.

Ссылки

Use Cases are Essential — https://queue.acm.org/detail.cfm?id=3631182
Use-Case Foundation — https://ss-usa.s3.amazonaws.com/c/308454236/media/245965ce1f5b9890898305669066035/Use%20Case%20Foundation.pdf
Use-Case 2.0 — https://queue.acm.org/detail.cfm?id=2912151
Use Cases are Essential — Essence for Agility MeetUp November 2023 (with Dr. Alistair Cockburn) — https://www.youtube.com/watch?v=QqKcuXB8PDo

Отчет CHAOS Report 2020

Артем Ушанов — Sat, 03 Feb 2024 13:47:27 +0500

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

Обзор отчета, на который я наткнулся в блоге Хенни Портмана.

Отчет называется «CHAOS 2020: Beyond Infinity», и судя по всему — это последний отчет группы такого формата.

Факторы успешности

Основными факторами успешности (Factors of success) в версии 2020 являются хороший спонсор, хорошая команда и «хорошее место». На самом деле это мета-факторы, внутри которых по десятку более мелких принципов:

Картинка из поста Хенни Портмана

Хороший спонсор (The Good Sponsor)
Душа проекта (так и пишут!) и обязательное условие для существования проекта. Спонсор существует на стороне заказчика проекта или выгодополучателя проектных результатов, его задача — предоставлять необходимые ресурсы и поддержку проекту и проектной команде. Спонсор отвечает за выделение бюджета и других ресурсов, контроль исполнения проекта, соответствие проектных целей стратегическим задачам компании-заказчика. Спонсор у команды проекта может быть всего один — но поскольку это роль, следует понимать, что представлен спонсор может быть целой группой людей.

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

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

Хорошая команда (The Good Team)
Команда — это производители проектного результата. ПМ, разработчики, инженеры по требованиям, служба контроля качества, и так далее. Команда должна быть маленькой (см. предыдущий пост), работать по аджайлу, быть профессиональной и в выборе метода, и в прикладных вопросах.

Хорошее место (The Good Place)
Под «хорошим местом» подразумевается «человеческое пространство», в котором существует проект. Это — все люди, которые так или иначе касаются проекта в процессе его жизни и при этом не являются частью команды или спонсором. Задача компании — улучшать навыки тех, кто представляет собой это «хорошее место», чтобы проекты в компании имели больший шанс на успех.

Из трех факторов самым простым в управлении считается спонсор, на втором месте — команда, на третьем — «хорошее место». Decision latency находится в ведении спонсора и «места».

Развенчанные мифы

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

Хенни приводит в пример четыре мифа, в которые пора перестать верить:

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

Эпилог

Это такой пункт в отчете — The Epilogue. В нем рассматривается история проектных подходов в разработке софта в четырех периодах:

«Дикий Запад» (1960-80) — методик нет или все изобретают свои, проекты ведутся «как-то».
«Водопад» (1980-2000) — выполнение перечня работ с разбивкой на явные последовательные фазы, строго по порядку.
«Эджайл» (2000 и скоро закончится) — проекты разбиваются на маленькие управляемые кусочки, фокус на гибкость и возможность поменять ход разработки в любой момент.
«Бесконечный поток» (Infinite Flow Period) — еще не начался, но уже вот-вот. Продлится тоже около 20 лет.

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

Утверждается, что подобная организация работы позволит сократить до 90% накладных расходов при сохранении результата.

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

Видео CHAOS 2020: Beyond Infinity

Есть еще вот такое ↑ видео трехлетней давности, там один из участников Standish Group Ганс Малдер раскрывает некоторые детали из отчета. Приведу пару моментов.

Аджайл круче водопада

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

Move fast

Good Decision Latency — это когда решения принимаются быстро, а Poor — когда долго, было в прошлом отчете. Разница поразительная : быстрые решения в десять раз уменьшают вероятность зафейлить проект и почти в четыре раза увеличивают вероятность успешно завершить проект.

Сколько стоят задержки принятия решений

Разница в накладных расходах на принятие решений у команд с High-скиллом и Poor-скиллом примерно десятикратная.

Схема метро Ташкента

Илья Бирман — Thu, 01 Feb 2024 20:27:59 +0500

Илья Бирман:

Запилили с Тимуром Репиным схему метро Ташкента:

Отчет CHAOS Report 2018

Артем Ушанов — Fri, 26 Jan 2024 02:55:10 +0500

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

Каждые два года исследовательская группа Standish Group публикует отчет по проектной деятельности в разработке софта под названием CHAOS Report. Аббревиатура расшифровывается как Comprehensive Human Appraisal for Originating Software — т. е. все про человеческий фактор в проектах.

Отчет строится на основе собственных исследований: группа собирает данные с большого количества проектов в разных отраслях (я встречал цифру в 50 000 проектов), проводит интервью с проектными командами, руководителями и клиентами, и делает выводы.

В отчете проекты обычно делятся на три группы: successful, challenged, failed — успешные, проблемные и неудачные. «Успешный» — это проект, который завершен в срок и в рамках бюджета, с реализацией всех заявленных возможностей и функций. Проект «с проблемами» завершен, но его сроки и бюджет превышены и он реализовал не все заявленные возможности. «Неудачный» проект отменяется в какой-то момент в процессе разработки.

Каждый новый отчет проверяет существующие и выявляет новые факторы, влияющие на успешность проекта. Отчет, вышедший в 2018, называется «Decision Latency Theory: It’s all about interval», значительная его часть посвящена теории задержки принятия решений.

Я этот отчет не покупал (400 евро 🥲), а прочитал и посмотрел несколько его обзоров, начал с поста в блоге Хенни Портмана.

В отчете пять разделов:

Decision Latency Theory
Winning Hand
Classic CHAOS
Factors of Success,
Skills of the Factors of Success

Decision Latency Theory

Кликбейт: чтобы улучшить состояние проекта на 25%, нужно научиться быстро принимать решения (примерно об этом же пишет и Рейнертсен).

Основной тезис раздела звучит так:

The value of the interval is greater than the quality of the decision.

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

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

«Решением» здесь может быть любой выбор из какого-то количества альтернатив, способный повлиять на дальнейший ход проекта, его «выхлоп» или метод работы.

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

Winning Hand

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

Факторы по версии предыдущего отчета (2016) следующие, в порядке уменьшения значимости:

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

Чем больше факторов из списка вы можете обнаружить в своем проекте — тем лучше.

В новом отчете на первом месте decision latency, на втором месте — небольшой проект, на третьем — сильный спонсор. В новых проектах следует в первую очередь работать именно над ними.

Classic CHAOS

У отчета изначально было три фактора, определяющих успешность проекта: вовремя, в рамках бюджета, выполнено все задуманное.
Разбивка по исследованным проектам за 2017 была такая:

36% — успешные
45% — проблемные
19% — провалившиеся.

В отчете вводится новая градация успешности проекта — pure success, «чистый успех». Это комбинация высокого уровня удовлетворенности клиента и высокого возврата инвестиций у исполнителя.

Там пропорция другая:

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

Factors of Success и Skills of the Factors of Success

Факторов обычно десять, три главных в отчете — все те же decision latency, размер проекта и сильный спонсор.

Для каждого фактора приводится набор из пяти практик (навыков, способностей), способствующих его развитию.

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

Заключение

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

Разбор дизайна сайта компании «Альфа-Медикал»

Илья Бирман — Wed, 24 Jan 2024 00:26:52 +0500

Илья Бирман:

Недавно я выложил на сайте рассказ о дизайне сайта компании «Альфа-Медикал». Теперь снял про него более подробное видео. Рассказываю о том, почему он именно такой, что нужно было в нём учесть. Видео будет полезно дизайнерам и интернет-предпринимателям:

00:00 Интро и что за компания «Альфа-Медикал»
03:46 Схема «Вы — Мы» — визуализация роли компании
04:24 Информативное главное меню сайта
05:02 Приёмы управления вниманием в большой текстовой странице
05:57 В основе сайта — ситуации
07:44 Этаж про деньги
11:06 Работа над текстом и согласование с клиентом
11:51 Котекстные отзывы как ещё один способ разнообразить подачу
12:49 Этаж про компетентность
13:23 Плавающая кнопка с телефоном
14:02 Страница ситуации
19:24 Шаблонизация и переиспользование текста в ситуациях
21:36 Зачем каждой ситуации нужна своя страница: забота и сео в одном
23:01 Страница «Команда» тоже не про команду, а про клиента
24:52 Страница «Контакты» помогает решиться обратиться в компанию
26:10 Мобильная версия — полноценная, и даже меню не спрятано
26:54 Итоги и как поработать со мной

Лайкли 3.2

Илья Бирман — Wed, 03 Jan 2024 16:42:52 +0500

Илья Бирман:

Лайкли — клёвые социокнопки. В версии 3.2 добавилась поддержка соцсети «Икс» — это так переименовался твиттер (<div class="xcom">).

Мы долго думали, что делать, ведь «Икс» — тупейшее название, и все говорят «Твиттер»! Решили просто: мы поддерживаем «обе соцсети». То есть вы можете на свой вкус выбрать, ставить ли себе твиттеровскую птичку или иксовый икс. Можно даже и то, и другое. Работает в любом варианте.

Подробности:

О проекте и зип-архив
Гитхаб

Лайкли ведёт Николай Рысь (Линкед-Ин).

Сайт «Альфа-Медикал»

Илья Бирман — Mon, 01 Jan 2024 20:05:48 +0500

Илья Бирман:

Зацените сайт для медтуроператора «Альфа-Медикал», задизайненный год назад. Это большая содержательная работа. Задача — помочь людям, оказавшимся в беде, разобраться в услугах компании и доверить ей своё здоровье. Проект про глубокое погружение в тему, работу с сомнениями и опасениями, заботу и внимательность к человеку.

Обновление нашей схемы московского метро — сентябрь 2023

Илья Бирман — Thu, 14 Sep 2023 20:26:58 +0500

Илья Бирман:

В декабре 2022 года мы с Ромой Мочаловым, Никитой Дубровиным и Ди Логвиновым выпустили нашу схему московского метро, включающую планы до 2030 года. За прошедшие месяцы и реальность, и планы слегка изменились, поэтому нашу перспективную схему пришлось подкрутить:

У будущих линий 16, 17, 18 поменялись планируемые цвета:

Появилась пересадка Бутырская — Останкино:

Запланировалась пересадка с Аэроэкспресса на D5 на станции «Домодедово», не являющейся аэропортом (обожаю):

Последние московские открытия в нашем случае потребовали «включения» большего числа линий на нашей схеме. Что-то, что раньше было строящимся, теперь стало работающим:

Со Внуковом у нас сразу порядок был:

Информационное сопровождение Челябинской транспортной реформы

Илья Бирман — Tue, 08 Aug 2023 16:06:52 +0500

Илья Бирман:

Рассказал об одном из этапов информационного сопровождения Челябинской транспортной реформы — информировании об изменениях маршрутов с 1 января 2022 года:

Разбор дизайна интернет-магазина «Дом Тома»

Илья Бирман — Thu, 03 Aug 2023 10:19:41 +0500

Илья Бирман:

Недавно я выложил на сайте рассказ о дизайне интернет-магазина «Дом Тома». Теперь снял про него более подробное видео. Рассказываю о том, почему он именно такой, что нужно было в нём учесть. Видео будет полезно дизайнерам и интернет-предпринимателям:

00:00 Интро
02:33 Подробное главное меню: навигация и вовлечение
03:55 Внесение разнообразия в списки
06:29 Фотографии товаров в разном стиле
07:48 Товар представляет себя и свой отдел
10:03 Акции и банеры распределены по странице
11:56 Как показать намного больше товаров: этажи отделов
13:57 Строчка того, что люди ищут
15:20 Нестрогое разделение товаров по отделам
16:15 «Новые товары декабря»
17:11 Ещё про меню и подвал
18:40 Дизайн подходит для разработки
19:58 Инстаграм
20:50 Мобильная версия олжна быть полноценной, а не урезанной
22:17 Как поработать со мной

Сайт «Дома Тома»

Илья Бирман — Sun, 25 Jun 2023 15:52:19 +0500

Илья Бирман:

Выложил рассказ о проекте, который сделал в 2019 году — дизайн интернет-магазина «Дом Тома». Почитайте, там надо было исхитриться и разнообразие коллекции показать, и индивидуальность товаров. Репостните везде и приходите за хорошим дизайном!