И полезные ссылки с сайта Гойко Аджича: https://www.impactmapping.org/intro-resources.html

Вообще карты влияний — тема не новая, но почему-то не очень популярная, хотя инструмент-то мощный. В России про Impact Mapping первым активно начал говорить Александр Бындю, и выпустил даже несколько статей на эту тему. Вот первая, очень хорошая: https://blog.byndyu.ru/2014/12/impact-mapping.html

А вот свежая — про то, как придумывать идеи влияния: https://habr.com/ru/post/652577/

Сразу после ЛАФа я ушел в небольшой отпуск, и почти не заметил, что мой доклад про стоп-слова по оценкам слушателей занял первое место! 😲 Это очень приятно и ценно, спасибо за высокую оценку!

Теперь хочется превратить материалы этого доклада во что-то более 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) Есть ли атрибуты у самого этого атрибута? Тогда, скорее всего, это отдельная сущность. Например, часто за атрибут принимают договор. Но у договора есть собственный номер, дата заключения, срок действия, состав услуг, и т.д. и т.п. Возможно, стоит рассмотреть его, как отдельную сущность.