Системный сдвиг

На индивидуальной консультации (а я провожу и такие, если что) сформулировал четкое понимание по видам метрик продукта: во-первых, с точки зрения уровня, метрики бывают внешние (относящиеся к деятельности, которую поддерживает и на которую должен влиять продукт; проверка — продукта нет, а метрику всё равно можно снять) и внутренние (описывающие использование самого продукта, например — востребованность отдельных функций); во-вторых, с точки зрения объекта измерения, бывают метрикипроцесса — измеряющие характеристики процессов в среднем (среднюю длительность, число [ручных] шагов, среднее время дохождения до определенного этапа процесса и т.п.), метрики результата — измеряющие качество результата процесса (насколько в среднем увеличилось качество проработки технических заданий, насколько уменьшилось число возвратов и т.п.); а в-третьих, с точки зрения способа измерения: метрики среднего (насколько в среднем по всем экземплярам улучшился показатель + медиану и разброс показателя, в общем — характер распределения) и метрики объема — когда мы не усредняем показатель, а считаем в штуках или в долях: сколько у нас процессов определенного вида, сколько пользователей, которые совершают такое-то действие, в скольки случаях качественные характеристики не соответствуют и т.п. Кажется, в такой раскладке можно измерить любой показатель. Интересно, что в продуктах, которые сами зарабатывают, обычно считают объемные и долевые показатели (юнит-экономику), а во внутренних продуктах — процессные метрики. А вот показатели качества результата вообще мало кто измеряет.

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

Выложили запись вчерашнего вебинара про User Story Mapping. Вроде прошло всё интересно, вопросам было отведено чуть ли не столько же времени, сколько самой демонстрации. Заодно поймал интересную мысль, пока готовился. Частый вопрос — про сравнение User Story и Job Story. "Я, как <роль>, хочу использовать <функцию>, чтобы достичь <цели>" или "Когда <ситуация>, я хочу <функцию>, чтобы достичь <цели>" — и даже на вебинаре его задавали. В дискуссии обычно обсуждают смещение фокуса с персоны пользователя и на ситуацию пользователя. Так вот User Story Map этот вопрос снимает, объединяя оба подхода: просто описание контекста и ситуации, вопрос "Когда" — уходит наверх, в бэкбон карты. А уже в деталях мы задаем даже более сильный вопрос: "как пользователь, что я хочу, когда я уже собрал заказ и собираюсь его оплатить?" — тут и роль, и ситуация. Мало того, мы можем спросить про ситуацию с точки зрения другой роли. "Как владелец магазина, чего я хочу, когда пользователь собирается оплатить заказ?" — и, очевидно, я тут много чего могу хотеть, например, чтобы пользователь использовал наличные, чтобы не платить комиссию банку-эквайеру. Такой анализ хорошо увеличивает глубину проработки системы.

‍Выложили видео с вебинара – «Требования в Agile: живой User Story Mapping вместо вороха бумажек» https://www.youtube.com/watch?v=vy_60LFvRNA Благодарим всех участников вебинара, с вами интересно! Удалось поработать командой. Было много крутых вопросов. Сделаем продолжение, следите за новостями. _____ В режиме реального времени провели сессию User Story Mapping на примере создания интернет-магазина. - Посмотрели на бэклог - Вспомнили принцип INVEST для пользовательских историй - Сделали User Story Map: разложили карточки бэклога по шагам - С помощью участников вебинара добавили шаги и user story - Доработали цепочку user story и проверили ее для другой роли пользователя - Выбрали скоуп работ для MVP ____ Познакомиться с Юрием Куприяновым можно на тренинге «Ручка» https://sysanschool.timepad.ru/event/2231306/ , а по-настоящему погрузиться в работу с User Stories вы сможете на курсе про Agile «Концептуальной проектирование – трансформация идеи в цифровой продукт» https://clck.ru/32mRsS #SystemsEducation#видео#вебинар

Приглашаем на бесплатный вебинар Требования в Agile: живой User Story Mapping вместо вороха бумажек на доске 24.11 в четверг в 18:00 Юрий Куприянов в режиме реального времени проведет сессию User Story Mapping на примере создания интернет-магазина и покажет, как команде разработки и заказчику или владельцу продукта вместе прийти от вороха задач в бэклоге к общему пониманию пользовательского пути, а главное — проверить, что весь по-настоящему нужный функционал войдет в MVP или нужный релиз. Кому будет полезно: • владельцам продукта (product owner) или тем, кто выполняет их роль, например, руководителям проекта, представителям бизнес-заказчика • аналитикам, отвечающим за создание требований на разработку ПО • представителям команды разработчиков, взаимодействующим с заказчиком Будем работать с доской Miro: • Посмотрим на список задач (бэклог) по созданию интернет-магазина • Начнем выстраивать их в цепочку активности пользователя в форме User Story Map: разложим карточки по шагам процесса • Обнаружим пробелы — выявим, какие требования потерялись или были забыты при первичном анализе; • подумаем, что нужно добавить в путь пользователя для MVP • Объясним принцип INVEST — он поможет убедиться, что user story сформулированы качественно • Ограничим скоуп работ, реалистичный для одного релиза • Ответим на вопросы зрителей Регистрация

Или вот в этот четверг тоже

30 ноября меня можно послушать вот здесь: https://flowconf.ru/talks/af19937287c14b36b7e21fd3a22a84a1/

Вот в таком виде сервис выдает отчет о сложности текста

У Ивана Бегтина есть отличный (и несправедливо недооцененный!) проект "Простым языком" — https://www.plainrussian.ru/ — оценка сложности текстов на русском языке. Изначально он задуман для оценки понятности текстов государственных сайтов и законопроектов, но я попробовал запихнуть в него кусок ТЗ на информационную систему из одной госзакупки, ну просто для примера. Получилось, ожидаемо, "Очень сложно читать, уровень аспирантуры, второго высшего или PhD". Ну, это ещё ничего, бывает и сложнее. Вообще я эту ситуацию у всех наблюдаю - от школьников до опытных аналитиков: устно все очень понятно говорят, что должна делать система, а как только нужно записать - появляются монструозные конструкции и наукообразные тексты. Кто был у меня на тренингах, наверняка слышал от меня "вы очень хорошо сейчас сказали, просто запишите это! нет, нет, просто запишите дословно, что вы сказали!" Я попробовал немного переписать текст этого ТЗ, и сразу получил сложность на уровне 10-11 класса. Кажется, программистами должно гораздо лучше восприниматься. Замечу, что я пробовал несколько ТЗ, так сильно упростить не всегда получается, оптимальна, кажется, сложность на уровне 1-3 курса института - и её почти всегда удается добиться, если только не нужно приводить дословные цитаты из законов, они всё сразу усложняют 🙂 Загнал несколько своих старых ТЗ, получается стабильно сложность на уровне 1-3 курса. Заодно при упрощении текста появились новые вопросы и я исправил несколько ошибок. Когда текст становится проще, дыры в логике и пробелы в изложении становятся очевидными. Например, я выявил и убрал пару случаев тавтологии ("система должна отображать информацию X, включая информацию X"), в нескольких местах возникли вопросы по поводу разницы режимов работы системы ("система должна обеспечивать режим просмотра A и режим просмотра B, в режиме B не должны быть видны некоторые данные" -- какие данные? Кто и когда переключает режимы? и т.п., куча новых вопросов). Также стало очевидно, что в системе должен быть реализован алгоритм рекомендаций, никак не прописанный в ТЗ, тогда как до этого создавалось ощущение, что рекомендации просто поступают в систему снаружи -- всего лишь из-за пары безличных предложений и многократного использования слова "информация". В общем, интересный и полезный сервис, пользуйтесь! Напишите — какая сложность у вас получилось, очень интересно.

Юрий Куприянов рассказал о стоп-словах в требованиях и поделился техниками улучшения Читайте на нашем сайте: https://systems.education/problem_is_the_requirements_safewords В видеоформате выступление на ЛАФ2022

Выступление на ЛАФ про стоп-слова оформили в статью, спасибо коллегам из Systems.Education. Для тех, кому удобнее почитать, чем посмотреть.

Кстати, пока готовлю большой пост-продолжение про модели данных: очевидно, что объектно-ориентированный подход совсем не отражает "объекты реального мира", стоит копнуть чуть глубже простого хранения данных. Если взять классическую задачу описания ситуации "человек пьет кофе из кружки" — всё время забываю, кто её предложил, кто-то из великих — то кто кому должен посылать сообщение (вызывать метод)? Кружка вызывает метод человека "пить_из(кружки)", или человек вызывает метод кружки, эээ, "поить(меня) "? И так, и так получается криво. Хорошее решение, которое часто предлагают — сделать отдельный класс-контроллер, который представляет процесс питья. Вот вам и отражение объектов реального мира! Уже спокойно выпить кофе не можем, какой-то внешний контроллер нужен! Паттерны проектирования вообще все полны такими абстракциями, которых в реальном мире нет. Какая-нибудь там абстрактная фабрика сосудов для питья. И ладно бы это был искусственный пример, так в практике такое сплошь и рядом: подписание договора — это метод договора или контрагента? Ах, опять контроллера "процесса подписания" (небось ещё и оформленного в виде паттерна "стратегия", чтобы универсализовать все шаги и все частные случаи подписантов и документов). В общем, очередной миф про удобство и отражение реального мира :)