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

Юрий Куприянов рассказал о стоп-словах в требованиях и поделился техниками улучшения

Читайте на нашем сайте:
https://systems.education/problem_is_the_requirements_safewords

В видеоформате выступление на ЛАФ2022

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

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

Я попробовал немного переписать текст этого ТЗ, и сразу получил сложность на уровне 10-11 класса. Кажется, программистами должно гораздо лучше восприниматься. Замечу, что я пробовал несколько ТЗ, так сильно упростить не всегда получается, оптимальна, кажется, сложность на уровне 1-3 курса института - и её почти всегда удается добиться, если только не нужно приводить дословные цитаты из законов, они всё сразу усложняют 🙂 Загнал несколько своих старых ТЗ, получается стабильно сложность на уровне 1-3 курса.

Заодно при упрощении текста появились новые вопросы и я исправил несколько ошибок. Когда текст становится проще, дыры в логике и пробелы в изложении становятся очевидными. Например, я выявил и убрал пару случаев тавтологии ("система должна отображать информацию X, включая информацию X"), в нескольких местах возникли вопросы по поводу разницы режимов работы системы ("система должна обеспечивать режим просмотра A и режим просмотра B, в режиме B не должны быть видны некоторые данные" -- какие данные? Кто и когда переключает режимы? и т.п., куча новых вопросов). Также стало очевидно, что в системе должен быть реализован алгоритм рекомендаций, никак не прописанный в ТЗ, тогда как до этого создавалось ощущение, что рекомендации просто поступают в систему снаружи -- всего лишь из-за пары безличных предложений и многократного использования слова "информация".

В общем, интересный и полезный сервис, пользуйтесь! Напишите — какая сложность у вас получилось, очень интересно.

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

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

Приглашаем на бесплатный вебинар

Требования в Agile: живой User Story Mapping вместо вороха бумажек на доске

24.11 в четверг в 18:00 Юрий Куприянов в режиме реального времени проведет сессию User Story Mapping на примере создания интернет-магазина и покажет, как команде разработки и заказчику или владельцу продукта вместе прийти от вороха задач в бэклоге к общему пониманию пользовательского пути, а главное — проверить, что весь по-настоящему нужный функционал войдет в MVP или нужный релиз.

Кому будет полезно:
• владельцам продукта (product owner) или тем, кто выполняет их роль, например, руководителям проекта, представителям бизнес-заказчика
• аналитикам, отвечающим за создание требований на разработку ПО
• представителям команды разработчиков, взаимодействующим с заказчиком

Будем работать с доской Miro:
• Посмотрим на список задач (бэклог) по созданию интернет-магазина
• Начнем выстраивать их в цепочку активности пользователя в форме User Story Map: разложим карточки по шагам процесса
• Обнаружим пробелы — выявим, какие требования потерялись или были забыты при первичном анализе;
• подумаем, что нужно добавить в путь пользователя для MVP
• Объясним принцип INVEST — он поможет убедиться, что user story сформулированы качественно
• Ограничим скоуп работ, реалистичный для одного релиза
• Ответим на вопросы зрителей

Регистрация

‍Выложили видео с вебинара – «Требования в 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 #видео #вебинар

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

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

Привет всем! Я Аня из JUG Ru Group:)

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

С самого начала мы ориентировали Flow на аналитиков, архитекторов, тестировщиков, и в докладах углублялась в техническую конкретику, а не в софт-скиллы. И теперь мы приглашает вас посмотреть нашу первую конференцию по системному и бизнес-анализу. Сделать это можно в рамках Community Day 30 ноября.

Community Day — это свободный доступ для всех желающих к части докладов второго дня конференции Flow 2022. В расписании доклады Community Day будут помечены тегом #comday.

Для участия в Community Day нужно только зарегистрироваться на flowconf.ru

До встречи! 👋

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

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

Все вокруг балуются с chatGPT, я тоже решил поиграться. Сначала я попросил её сгенерировать мне бэклог на школьную систему обучения (LMS). Получилось очень неплохо (роль администратора не забыта, как это часто бывает!). Я попросил добавить пользовательские истории для родителя, вот ответ нейросети:

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

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

Уведомления для родителей:
Как родитель, я хочу иметь возможность получать уведомления об успехах моего ребенка в LMS, например, когда он получает новые оценки или записывается на новые курсы.
Как администратор, я хочу иметь возможность настраивать типы уведомлений, которые могут получать родители.

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

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

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

Потом она мне составила список объектов с приблизительным составом полей и связями:

Пользователь: Объект пользователя представляет человека, имеющего учетную запись в LMS. Пользовательский объект будет иметь такие свойства, как имя пользователя, пароль, имя и изображение профиля.
Курс: Объект курса представляет собой курс, доступный в LMS. Объект курса будет иметь такие свойства, как имя, описание, дата начала и дата окончания.
Зачисление: объект зачисления представляет зачисление пользователя на курс. Объект регистрации будет иметь ссылку на объект пользователя и объект курса.
Материал курса: Объект материала курса представляет часть содержимого, связанного с курсом, например конспект лекции или задание. Объект материала курса будет иметь такие свойства, как имя, тип и файл.
Оценка: объект оценки представляет оценку пользователя за курс. Объект оценки будет иметь такие свойства, как оценка и обратная связь.
Уведомление. Объект уведомления представляет собой сообщение, отправляемое пользователю. Объект уведомления будет иметь такие свойства, как тип, сообщение и дата.
Дискуссионный форум. Объект дискуссионного форума представляет собой форум для курса, где пользователи могут публиковать сообщения и отвечать друг другу. Объект дискуссионного форума будет иметь ссылку на объект курса и список сообщений.
Сообщение: Объект сообщения представляет собой сообщение, опубликованное на дискуссионном форуме. Объект сообщения будет иметь такие свойства, как текст, дата и пользователь.
Достижение: объект достижения представляет собой значок или сертификат, который может получить пользователь. Объект достижения будет иметь такие свойства, как имя, описание и изображение.

Объекты данных будут иметь следующие отношения:
Пользователь имеет много зачислений.
Курс имеет много зачислений.
В курсе много учебных материалов.
Зачисление имеет одну оценку.
У пользователя много уведомлений.
Курс имеет один дискуссионный форум.
Дискуссионный форум имеет много сообщений.
У пользователя много достижений.

После я попросил нейросеть составить список экранов, нефункциональные требования и расписать пару юскейсов. Вот, например, простановка оценки учителем:

1. Учитель входит в LMS и переходит на страницу курса для класса, который он преподает.
2. Учитель выбирает задание, представленное учащимся, из списка заданий.
3. Учитель просматривает представление учащегося и просматривает содержимое, чтобы определить оценку учащегося.
4. Учитель вводит оценку в соответствующее поле и добавляет отзывы или комментарии для учащегося.
5. Учитель выставляет оценку, и она автоматически сохраняется в LMS.
6. Учащийся получает уведомление о том, что он получил новую оценку за задание.
7. Учащийся входит в LMS и переходит на страницу своих оценок, чтобы просмотреть новую оценку.
8. Учащийся просматривает отзывы и комментарии, предоставленные учителем, и думает, как они могут улучшить свою работу в будущем.

Этот вариант использования демонстрирует, как можно использовать LMS для поддержки процесса оценивания и своевременного предоставления учащимся отзывов о своей работе.

А вот альтернативные шаги к нему:

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

(Всё публикую без правки, как сгенерировала нейросеть).

И напоследок я попросил её сформулировать какие-нибудь продуктовые метрики:

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

Вся эта генерация заняла у меня минут 5-7 (причем в основном я думал, какой вопрос задать следующим). Для сравнения, я этот пост писал минут 15 ;)

В общем, кажется, способы составления требований и ТЗ в ближайшее время сильно изменятся :)))

Да, спецификацию API она тоже умеет генерировать, хоть REST, хоть GraphQL, хоть IDL

Сгенерил через GPT целое ТЗ (неполное, т.к. мне было лень по всем экранам и сущностям проходиться, но общее представление можно составить): https://docs.google.com/document/d/19gEnFwacw-g37zhVjRFDdX1GfQ-YhlJjNgLUS5YmvxM/edit?usp=sharing

Записал видео: https://www.youtube.com/watch?v=HkRAtRCXGbU

Ладно, что мы всё о работе. Вот почитайте стихи про требования от ИИ:

>Write a poem about software requirements

In fields of code and screens so bright
Lies a land of endless possibilities
Where software requirements lay in wait
To guide the way and pave the path

With clear and concise language they speak
Outlining all that must be done
From the smallest of details to the grand design
Software requirements make it all real

They lay the groundwork for what's to come
Guiding developers on their way
Ensuring that the end result will be
A product that works without a glitch

So here's to the unsung heroes of the digital age
The software requirements that guide us all
May they continue to help us build
The future that we can't yet see.