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

А тут ещё и Летний Аналитический Фестиваль lafest.ru, где я аж в трех активностях: делаю доклад, участвую в круглом столе и провожу мастер-класс. Всё к одному. Ну и старые наработки буду понемногу выкладывать.

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

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

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