Как проектировать

Критически важный сегодня навык работы с ёмкими смысловыми текстами

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

Об этом мне рассказывают и работодатели, уставшие от узких беспомощных исполнителей, и ректоры вузов, выпускающих специалистов, которых уже не берёт рынок.

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

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

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


https://ashapiro.ru/sim-book

Проектирование концепции и деталей инструмента

Про два масштаба рабочих историй и карт реализации историй на реальном примере. Вырезка из мини-курса КРИ

Отзыв ещё одной участницы мини-курса по КРИ.

Алла Тимофеевой, UX/UI-дизайнер:

Хотела бы сказать огромное спасибо Андрею за возможность пройти этот курс — он мне очень многое дал в понимании КРИ.

1. Структура

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

Плюс по каждому элементу есть правила и шпаргалка. И так, элемент за элементом, вуаля — к концу курса всё складывается в одну прекрасную карту, логичную и понятную.

Классно, что есть домашние задания — без практики пройденный материал не закрепится.


2. Понятность

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


3. Доступность

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

Освойте новое средство построения коммуникации о требованиях к проектируемым решениям.

Новый поток мини-курса по Карте реализации историй начинается уже в следующий вторник — приходите

Как проектировать pinned a photo

Как КРИ скрепляет проектирование и код-агентскую разработку

В моей личной практике работы, что с код-агентами, что с экспертными командами, рабочие истории — последний контракт и рубеж перед разработкой кода.

В это небольшом отрывке показываю их место в разработке прототипа для отрисовке КПО.

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

Сам использую и вам рекомендую

Только что закончился первый поток мини-курса по Карте реализации историй. И я рад тому, что курс состоялся и получилося максимально практичным.

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

Вот отзыв одного из участников первого потока:

Для меня главная проблема — как обсуждать с заказчиками, разработчиками и другими участниками сложные, абстрактные сущности. Прежние артефакты — персоны, жизненные ситуации, jobs, диалоговые сценарии, продуктовые матрицы и CJM — могут быть понятны аналитику, но их трудно сделать предметом общего обсуждения: заказчики редко внимательно читают длинные сценарии, а важное знание оказывается в разных документах.

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

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

Алексей Евстифеев, UX-исследователь Kaiten

Новый поток мини-курса стартует 15 сентября. Запись открыта.

Если вы хотите провести курс в уютно компании своей команды или компании, напишите мне.

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

Когда я работал в Бюро, там был Максим, которым все рисовали модный тогда скевоморфизм. Максим пережил многих дизайнеров в компании, потому что был послушными и усердными руками. Он был почти идеальным инструментом. Развись он чуть больше, и был бы неудобным, потому что у него бы появилось своё мнение на счёт запросов на правки.

Страшно перестать быть востребованным инструментом, но ещё страшнее обнаружить себя неспособным генерировать и развивать замысел. Особенно сегодня.

На картинке я объясняю Клоду, где ещё рисователь схем далёк от замысла. У этого процесса есть сходимость, качество потихоньку организуется. Почти идеальный исполнитель.

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

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

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

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

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

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

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

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

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

КНИГА

Потеря управляемости в проекта при работе с ИИ

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

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

Работая на сложных задачах с несколькими уровнями абстракции (какой, например, является проектирование инструмента для Карты процесса-опыта для интеллектуальной среды Социотех), я понял, как сильно мои прежние способы действия формировали моё понимание и пропитывали меня знанием. Да, двигая руками объекты в графическом редакторе или рисуя каракули на планшете, я думал глубже, а мысль или образ укреплялись прочнее.

Эта мысль не нова для человечества, но вряд ли кого-то затронет в эшелоне бизнеса. Оказавшись в ситуации нескольких кризисов (фазовый переход, экономическая рецессия) бизнес требует радикальных перестроений здесь и сегодня за счёт ИИ. Всё сообщество разработчиков говорит словами обладателя искусственного интеллекта из Интерстеллар: «Это невозможно». А бизнес отвечает ему: «Это необходимо!»

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

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

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

Надиктовка историй в паре с агентом

Вот так, голосом, через MCP Социотеха я правлю и добавляю новые рабочие истории в Карту реализации историй. Досмотрите до конца, это даст интуицию для других применений.

Особенно полезно, когда предстоит множество преобразований, массовые импорты/экспорты или рефакторинги досок.

Кстати, ближайший мини-курс по КРИ будет именно в Социотех. С ним не нужно тратить время на вёрстку карты и, так как все карты связаны единой моделю данных, работать с код-агентами с ними милое дело.

Я глаголю — ты верши

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

А какие вы интересные примеры применения код-агентов в проектировании встретили за последнее время?

Вышло официальное видео доклада про связку ТРИЗ и Социотех. В нём приведён пример как можно придумывать идеи с ТРИЗ и доводить их до реализации с помощью технологий и методов Социотеха

Один из каверзных вопросов из зала: что вы понимаете под рутиной юриста в контексте автоматизации его работы

💎 Видео доклада
💎 Материалы к докладу
💎 Среда Социотех

Сложные системы не прощают мутных историй

Пятнадцать лет я формулирую рабочие истории — сначала нащупывая метод сам, потом обучая ему коллег и специалистов из разных компаний. Категории рабочей истории — Носитель, Ситуация, Действие, Объекты, Цель, Форма реализации, Интерфейсная структура — появились не сразу: это результат многолетнего разбора того, что идёт не так, когда команда работает с требованиями. Готовые категории в шаблоне — уже большая часть работы: с ними уже не перепутать цель с деталью реализации.

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

Это умение приходит только через практику: черновик истории многократно переписывается, лишнее счищается, ёмкие формулировки стягиваются к самой сути.

Ремесло сплетения историй заметно в любой роли, где вообще имеют дело с инженерией требований.

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

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

⚫️ В сборе требований — хотелка заказчика превращается в задачу для разработки без ответов на вопросы «зачем делать вообще» и «зачем именно так».

⚫️ В командной работе — аналитик, дизайнер и разработчик обсуждают «одну» историю на разных диалектах, и смысл теряется на стыке.

⚫️ В цифровых сервисах для госсектора и НКО — услугу чаще проектируют от формы и регламента, а вопрос, зачем человек вообще сюда пришёл, звучит в последнюю очередь, если звучит вообще; тогда и вскрывается, что часть процедуры не нужна вовсе, и она мешает потребителю.

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

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

На курсе по Карте реализации историй я учу этому ремеслу — технике сплетения истории, шаг за шагом, поверх шаблона из семи категорий.

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

Программа и запись

Ну, и лучшим средством структурирования беседы о требованиях и проектировании остаётся КРИ. Про это я написал отдельную книгу и её всё ещё можно приобрести в отличии от книги про КПО.

https://ashapiro.ru/sim-book

Вышло официальное видео доклада про техники структурирования беседы с конференции UWDC. Получше стали видео и звук.

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

Все дополнительные материалы к докладу на его странице

Карта реализации историй на примере за 12 минут

Разбирались вместе с Галой Янке. Это первая часть встречи, где я коротко ввожу КРИ и показываю её не только в шаблоне, но и на примере пары рабочих историй. КРИ здесь строится для инструмента поиска связи между стратегией и операционной деятельностью. Это когда высшее руководство хочет проверить а тем ли вообще занимаются сотрудники компании

А вот и запись вебинара по Карте Реализации Историй (КРИ) с Андреем Шапиро (автором подхода).

Дополнительная информация по Карте Реализации Историй
Инструмент, в котором мы рисовали карту

А вот ссылки на видео:
RUTube
VKVideo

Запись вчерашнего эфира о Карте реализации историй

Новый отзыв о книге «Рабочие истории»

Никита Максимов, QA-инженер:

❞
Классная книга про КРИ и в целом про проектирование. Нашёл для себя много полезного с первых глав. С JTBD,  User Story и Acceptance Criteria сталкивался, но постоянно было ощущение неопределённости, так как не был понятен ответ на вопрос «чтобы что?».

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

Есть в сфере QA, такое поверие, что если наладить практику «Три амиго», то получится собрать все N контекстов, оформить их в самые современные формы записи, договориться о критериях приёмки и тогда качество услуги продукта получится таким высоким, что конкуренты будут завидовать.


Как одно с другим связано мне было совершенно не понятно. А вчера, после прочтения первых глав,
всё стало на свои места)

отдельное спасибо за закладку-ляссе
❝

Как проектировать pinned a photo