Публикую презентацию доклада про стоп-слова

Говорят, что доклад про стоп-слова оказался очень полезен тем, кто принимает работу аналитика - раньше смотришь на требования, понимаешь, что что-то не то, но не понимаешь, что именно. А теперь, говорят, после доклада - а вот как раз и понимаешь! :)

А вот презентация с мастер-класса по Impact Map

И полезные ссылки с сайта Гойко Аджича: 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

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

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

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

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

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

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