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

Вообще этот доклад про тексты и доклад с ЛАФ'2018 про проверку полноты требований — это своего рода дилогия, первая и вторая серия одной идеи — как проверить набор требований снаружи — на полноту, и изнутри — на содержание. Видео того доклада про выявление требований вот здесь, на сайте ЛАФ. А вот тут мы со Школой системного анализа выпустили тот же материал, но в виде статьи (и чек-листа), зацените: https://systems.education/requirements-never-changes

В виде статьи: https://systems.education/requirements-never-changes

Буду рад отзывам и обратной связи

Почему-то бытует представление о том, что в agile требований либо вообще нет, либо работа с ними очень облегчена. На самом деле, там примерно всё то же самое, только работа ведется не сразу со всем массивом требований, а с требованиями к каждому релизу (на каждом спринте). Причем работа с требованиями, например, в виде пользовательских историй, очень похожа на то, про что я в докладе и статье про техники проверки требований рассказывал. Эта "невидимая" работа скрывается в agile под практикой backlog grooming. Когда про неё рассказывают, обычно фокусируются на приоритезации и реприоритезации, и одной фразой упоминают некую детализацию историй. Вот в этой фразе про детализацию историй, или разбиение (story splitting), или декомпозицию - и кроется большая работа. В которой не только истории разбиваются на несколько более детальных, но и появляются новые (например, когда в наборе историй пропущены какие-то шаги пользовательского сценария). Паттернов декомпозиции историй очень много, и много статей на эту тему. И то, что там описано, близко к моему рассказу про техники проверки. Можно с теми же критериями подходить и к декомпозиции пользовательских историй.

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

Всем привет! Отпуск мой оказался длиннее, чем я думал, но, как обычно, осенью вся деловая активность оживает, возвращаюсь и я к этому каналу, к тренингам, статьям и консультациям. И первый тренинг в этом сезоне будет уже в конце сентября, это легендарная "Ручка", с которого, собственно, началась история школы Systems.Education. Все, наверное, слышали про задание на собеседовании специалистов по продажам: "продайте мне эту ручку". А как вам задание для системного аналитика — "напишите техническое задание на эту ручку"? Ох, далеко не все справляются с таким заданием, и по ошибкам или упущениям можно многое сказать о навыках человека. А если к выполненному заданию добавить обсуждение — можно на таком примере поднять почти все процессы системного анализа, хороший способ структурировать подход к составлению требований.

Как, блин, заниматься работой, когда вокруг какой-то ад творится?! Но, тем не менее: обсуждение новой версии профстандарта системного аналитика выходит на финишную прямую. С одной стороны, практика показала, что не особо он кому-то нужен, с другой — для составления должностных инструкций и положений о подразделениях мне был полезен. Кроме того, говорят, ссузы и вузы смотрят на него для своих программ, ну может. Насколько я понимаю, системных аналитиков так нигде ни не учат, есть только абстрактная "Бизнес-информатика".

В новой версии стандарта мне нравится, что цель деятельности и набор задач удалось повернуть в сторону проектных решений, а не требований. Это в продолжение круглого стола на ЛАФе — что же делает в своей работе аналитик на самом деле? Как показывает практика — далеко не только требования собирает, программисты же хотят видеть сразу "постановку", максимально конкретную, вплоть до физической модели БД. Значит, на аналитика ложится задача проектирования, или, как минимум, фиксации принятых проектных решений. Вот эту деятельность по проектированию сейчас предлагается зафиксировать в стандарте, обобщенные трудовые функции получаются такими:
- Разработка технических требований к элементу поставки
- Оформление, согласование, управление изменениями и коммуникация разработанных требований, проектных решений и изменений в них
- Сопровождение и надзор за дальнейшим проектированием и реализацией разработанных требований и проектных решений
- Логическое и техническое проектирование ИТ-системы/продукта
- Поиск, выявление и анализ исходных данных для концептуально-логического, логического и технического проектирования ИТ-системы/продукта
- Концептуально-логическое проектирование ИТ-системы/продукта
- Управление работами системных аналитиков на всем жизненном цикле ИТ-системы/продукта

То есть, фиксируем, что аналитик, несмотря на название, всё-таки занимается проектированием. Мне это очень нравится.

Если что — можно ещё присоединиться к обсуждению стандарта вот тут: https://news.1rj.ru/str/profstandart_SA , а вот здесь оставить комментарии к стандарту: https://docs.google.com/spreadsheets/d/1BPTpxVaNZ9ySYlfGPgNPRS5HLBaSlwJ-V5WrSYhm8w4/edit#gid=1495016461

В канале "Анализ и проектирование ИТ-систем" спросили — как аналитику не выглядеть "душнилой" при общении с пользователями и стейкхолдерами. Написал кое-что из своего опыта и пару историй. Интересуйтесь людьми! Вы делаете системы для них, а не чтобы их эксплуатировать. Аналитик — это помогающая профессия.

Спрашивать о человеке, его чувствах и состоянии, а не о системе. "А что в этом процессе для вас самое неприятное, что меньше всего хочется делать?", "И когда с первого раза получается эту форму заполнить, это наверное, вообще... круто, да?"

Тут же можно "присоединяться" к эмоциям собеседника: "Да, это ужасно бесит!", "Ого, как у вас круто устроено, практически всё автоматизировано! "

Ещё можно не просто спрашивать про процесс, абстрактно, а попросить рассказать какой-то конкретный кейс: "А можете вспомнить, когда в последний раз вы...? Как это было, можете рассказать?" и лучше, если бы это был какой-то кейс, где человек был молодцом.

В начале беседы можно рассказать — зачем это всё, и что вы собираетесь делать.

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

А когда я уже набрался опыта, я с другого начинал: пришел к начальнице отдела, рабочую систему которого мы хотели модернизировать, и говорю: Люба, я пришел вам помочь и сделать вашу жизнь легче! Расскажите о своих проблемах. — смотрю, а у неё слезы на глазах. Юра! — говорит. Я тут работаю 10 лет, и никто никогда не спрашивал, какие у меня проблемы и уж тем более не предлагал их решить. Даже если у вас не получится — всё равно спасибо!

При обсуждении профессионального стандарта каждый пытается осмыслить суть и цель работы системного аналитика, и вариантов высказывается много. Как и критериев оценки качества работы СА. Зачем он вообще на проекте? Один из показателей, которые я для себя вывел — это число вопросов, заданных системным аналитиком, на которые получен ответ "О! Об этом мы как-то не подумали!.."
То есть, аналитик — это такая роль, которая позволит _заранее_ выяснить максимально большое число аспектов будущей системы, о которых стоит подумать, и по которым стоит принять решение. Сами решения не должен принимать системный аналитик, это пусть делают заказчик, владелец продукта, менеджер проекта (или команда реализации в целом), архитектор... Системный аналитик может быть при этом фасилитатором — акушеркой при рождении решения. Может и свои решения предлагать, если есть опыт. Может для предложенного решения задать следующие вопросы, которые нужно будет продумать при реализации этого решения. И, конечно, может потом зафиксировать принятые решения. Таким образом, задача аналитика — заранее раскрыть объем будущей системы. А то обычно его недооценивают в 2-3 раза. И указать наиболее рискованные места — рискованные именно с точки зрения неопределенности, тени, в которых скрываются огромные пространства.
Говорят, аналитиков не любят за занудство. Но не нужно быть занудой и цепляться к мелочам. Наоборот — показывайте ширину и глубину системы, весь объем и сложность! Любой менеджер, который осознает, что благодаря системному аналитику удалось не ввязаться в проект, зарезанный вдвое по срокам из-за неучтенной функциональности, будет вас на руках носить :)

Должен ли аналитик проектировать БД? В спорах про профессиональный стандарт системного аналитика самой жаркой темой оказалось знание программирования — вот уж где копий было сломано! Кто-то даже на Хабр статью написал. А я вот задумался про проектирование баз данных. Уже на нескольких проектах последних лет я сталкивался с тем, что эта тема оказывается пограничной — и программисты за неё не хотят браться, и аналитик останавливается на концептуальной модели. Аргументы с обоих сторон: у аналитика — я не специалист в тонкой настройке СУБД, и даже не знаю, какую вы выберете. А программисты либо боятся этой темы, потому что (моя гипотеза) — выросли из веб-разработки, может быть даже из фронтенда, и базы эти в глаза не видели, ведь всё сделает инструмент ORM автомагически. А какая там реляционная алгебра и как тюнить запросы — это всё очень сложно.
Другой релевантный аргумент — ведь всё равно мы к тебе придём с вопросами, и тебе придется выяснять, так может ты сразу всё выяснишь и нам расскажешь. И действительно, резон в этом есть — чтобы хорошо спроектировать базу данных, нужно хорошо понимать про предметную область и про сценарии использования системы. А это область ответственности аналитика, если он есть на проекте.
Итак, какие же вопросы нужно выяснить, чтобы качественно спроектировать БД?
Во-первых, разбивку на сущности и атрибуты (ну или на классы объектов и их свойства, если вы работаете в объектной парадигме). Вопрос не такой простой, и часто возникает в том числе на тренингах. Мы нашли упоминание какого-то существительного в документах — это указание на объект или на атрибут? Простейший пример — адрес. Это сложный атрибут, или это самостоятельный объект? Вообще говоря, зависит от целей системы и сценариев использования. Я предлагаю следующие вопросы для проверки:
1) может ли этот "кандидат в объекты" существовать независимо от других объектов? Вот никаких клиентов нет, а адрес, как сущность, есть, и мы можем захотеть его заранее хранить, отдельно от всего?
2) (косвенный вопрос, связанный с предыдущим) существует ли потребность когда-нибудь выгружать, просматривать, передавать или наоборот — получать список всех возможных значений объекта, в отрыве от других объектов? Вот так, чтобы список всех имеющихся адресов посмотреть или куда-то передать? Интересный вопрос, между прочим, из него можно новую функциональность выявить, и даже смежные системы, о которых раньше не подумали. Если да — возможно, речь идет как минимум о справочнике, а может быть и о полновесном объекте.
3) Есть ли у этого предполагаемого объекта естественный идентификатор? Какой-нибудь номер или код? (у адреса такого, пожалуй, нет — адрес сам по себе такой идентификатор. Впрочем, сталкивались ли вы с домами, у которых есть несколько адресов?..). Для некоторых значений такой вопрос очевидно не имеет смысла, например, для фамилии, отчества или даты рождения. А в некоторых случаях не всё так очевидно.
4) Есть ли атрибуты у самого этого атрибута? Тогда, скорее всего, это отдельная сущность. Например, часто за атрибут принимают договор. Но у договора есть собственный номер, дата заключения, срок действия, состав услуг, и т.д. и т.п. Возможно, стоит рассмотреть его, как отдельную сущность.

Так, с сущностями и атрибутами разобрались. Ну, мы с ними и так разбираемся, если составляем концептуальную модель, на чем обычно аналитик и останавливается. Но для проектирования нужно пойти дальше. Это у нас будет
во-вторых:
Домены атрибутов. Кропотливая работа, которую никто не любит. Домен = тип данных + ограничения. Ну, какие-то типы в лучшем случае накидаем, и самые очевидные ограничения пропишем, типа маски для телефона. Но и тут есть много подводных камней. Ограничения работают не только на ограничения, извините за тавтологию, но и на расширение. Не нужно вводить их искусственно. Особенно это касается длин текстовых полей, и оказывается довольно печальным, когда в них не влезают тексты, характерные для предметной области (примеры реальных текстов крайне важны и для дизайна, но тут почти все вопросы имеют двойное назначение — и для структуры данных, и для их корректного представления в интерфейсах). Неожиданностью могут стать длинные имена файлов. Да даже и имена и фамилии! В совсем, казалось бы простых случаях вы можете столкнуться со значением, вылезающим за рамки типичных значений домена. В институте в моей группе училась студентка с испанским традиционным ФИО из трех или четырех имен и двух фамилий. Уместит ли ваша БД такое и сможет ли она это вывести? (Дальше всех, кажется, в деле формального определения именования человека пошли с стандарте обмена медицинской информацией HL7 — там имя описывается структурой из 7 полей, три из которых являются списками и одно — ссылкой на контексты использования данного имения в отношении данного человека, которых тоже семь разных вариантов. Итого, у одного человека может быть 7 различных имен для использования в разных контекстах, и каждое "имя" представляет собой сложную структуру с суффиксами, префиксами, личными и семейными именами и их порядком следования. Да, и всё это в привязке к временному периоду, когда это имя являлось актуальным).
Другой пример определения домена — даты. Вот, скажем, дата регистрации компании. Иногда может понадобиться для расчета льгот, скоринговой оценки или какого-нибудь контроля. Какой домен у этой даты? Ну, она не должна быть в будущем. А в прошлом? Знаете ли вы, что в Microsoft SQL Server минимальное значение для типа datetime — 1 января 1753 года? И когда в одну компанию пришла карточка досточтимого контрагента — частной компании с датой основания где-то в XVII веке, её просто не смогли ввести в базу данных? (Пример из реального проекта). Или вот при анализе образования московских учителей мы нашли как аксакалов, окончивших московский педагогический университет в первые века нашей эры (в 198, 203 и даже просто в 3 годах!), так и гостей из будущего, окончивших его же в 2201 или в 2118. Очень радостно за многотысячелетнюю историю московского педа, но, кажется на домен можно было бы и наложить какие-то ограничения и проверки при вводе.
Даже с простыми типами данных иногда возникают вопросы. Какой тип должен иметь атрибут "число комнат в квартире"? Вроде бы очевидно, что это целое число, большее 0. Однако мы сразу же упираемся в понятие "свободная планировка", где и комнат-то никаких пока нет. И вроде не скажешь, что их 0. А если думать про ограничение сверху, то вроде разумно допустить 20... или 100... ну точно же не 1000?.. и тут выясняется, что это понятие "число комнат" вообще не очень четко определено. Если это число помещений, то их и в обычной двушке штук 6-8, и не все из них комнаты. Но это, кроме БТИ, мало кого интересует. А если это для поиска потенциальным покупателем, то в большой квартире ему, в общем-то, всё равно - 10 комнат или 11. И оказывается, что это вовсе и не целое число, а справочник из значений "свободная планировка", "1", "2", "3", "4", "5 и больше"...

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

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

Выступление на ЛАФ про стоп-слова оформили в статью, спасибо коллегам из 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 не должны быть видны некоторые данные" -- какие данные? Кто и когда переключает режимы? и т.п., куча новых вопросов). Также стало очевидно, что в системе должен быть реализован алгоритм рекомендаций, никак не прописанный в ТЗ, тогда как до этого создавалось ощущение, что рекомендации просто поступают в систему снаружи -- всего лишь из-за пары безличных предложений и многократного использования слова "информация".

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