Сейчас системный архитектор в Рoscredit.
Название Конференция Описание | Автор |
---|---|
Занимательная картография и археология для аналитиков | |
ЛАФ-2023 [Подробно...][Скрыть] Частая ситуация в проекте:
И тут кто-то решает нанять аналитика или усилить команду аналитиков… Я расскажу, почему без картографии и археологии невозможно жить ни секунды, что бы там ни подгорало у пользователей и разработки. Поделюсь применением инструментов быстрого восстановления знаний, которые помогли мне в нескольких проектах:
| Сергей Нужненко |
Практика картографии и археологических раскопок для аналитиков | |
ЛАФ-2023 [Подробно...][Скрыть] Мастер-класс (4 часа) и 12-15 человек Частая ситуация в проекте:
И тут кто-то решает нанять аналитика или усилить команду аналитиков… В докладе я расскажу, почему без картографии и археологии невозможно жить ни секунды, что бы там ни подгорало у пользователей и разработки. А на мастер-классе мы попрактикуемся в применении инструментов быстрого восстановления знаний, которые помогли мне в нескольких проектах:
| Сергей Нужненко |
Концепция обновления профстандарта РФ Системный аналитик | |
ЛАФ-2022 [Подробно...][Скрыть] В 2022 году подошел срок плановой актуализации профстандарта (ПС) Системный аналитик. Я координирую экспертную группу от индустрии, участвующую в обновлении профстандарта. Нам предстоит решить ряд вопросов: - какую работу над ошибками нам необходимо сделать с уже имеющимся текстом ПС?
- претерпела ли профессия системного аналитика существенную трансформацию с момента утверждения ПС?
- как провести водоораздел между системным аналитиком, тестировщиком, менеджером по продажам, специалистом по техподдержке и др.? - как отделить от системного аналитика профессии бизнес-аналитика и аналитика в разработке программных средств (что бы это ни значило :)?
Я расскажу, какие ответы уже имеются на эти вопросы и приглашу на серию открытых обсуждений, которые состоятся после ЛАФ в формате онлайн.
| Сергей Нужненко |
Практика работы с требованиями для сложного сервиса | |
ЛАФ-2021 [Подробно...][Скрыть] Мастер-класс на 4 часа, основанный на однодневном тренинговом модуле, который мы с коллегами второй год ведём для студентов Высшей Школы Экономики. Тренинг в свою очередь основан на нашем опыте работы со сложными системами, где каждое требование к продукту влечет согласованную работу нескольких команд. Что такое АГИЛ - это Agile, когда есть нюанс (как в анекдоте), а то и несколько. То есть, когда итерации короткие, требования изменчивые, команды самоорганизованы в бандитские шайки из-за тупого и ленивого менеджмента, а вот всё остальное - как придётся. Всё то же самое применимо и в Agile, но там обчно есть Agile Coach, который обязательно внедрит SAFe, LeSS и много других страшных слов. Вся теория к мастер-классу и полное описание проблематики находится в докладе "Требования в АГИЛ для сложного сервиса (теория) - можно посмотреть описание доклада отдельно. На мастер-классе я хочу показать вариант целостного процесса превращения творческих идей по сервису в конечные тикеты на каждого разработчика. Сам процесс включает в себя практики, с которыми полезно познакомиться любому аналитику: - Отображение продуктовых требований с помощью бизнес-канваса и связанных с ним инструментов - Поиск точек изменения с помощью карты и эскиза процессов - Двумерный мапинг историй для выявления требований - Применение карт влияния (Impact mapping) совместно с двумерным мапингом или без него - Изображение системного ландшафта и архитектуры в стиле 4Context - Сценарии или диаграммы взаимодействия - И снова карты влияния для раздачи задач системам, командам и отдельным исполнителям - Согласованная нарезка бэклогов команд на итерации и осознанное - с учётом архитектуры - расщепление историй для максимально раннего получения бизнес-ценности - Реверс процесса - что мы получим, если (не) сделаем эти задачи Максимальное число работающих руками - 2 команды по 6 человек. Остальные могут быть зрителями и присоединиться к обсуждению. | Сергей Нужненко |
Требования в АГИЛ для сложного сервиса (теория) | |
ЛАФ-2021 [Подробно...][Скрыть] Что такое АГИЛ - это Agile, когда есть нюанс (как в анекдоте), а то и несколько. То есть, когда итерации короткие, требования изменчивые, команды самоорганизованы в бандитские шайки из-за тупого и ленивого менеджмента, а вот всё остальное - как придётся. Всё то же самое применимо и в Agile, но там есть Agile Coach, который обязательно внедрит SAFe, LeSS и много других страшных слов. В чём проблема - она во всём. Если работу быстро развивающегося сервиса поддерживают две и более команды разработки, то ни одной из них не подойдут ни продуктовые требования, ни бизнес-требования, ни требования к сумме ИТ-систем. Очень часто им не подойдут даже требования к их отдельной системе, выделенной из окружения. Так как тим-лидов и менеджеров проекта ломает писать по 50 тикетов в неделю и заниматься координацией между всеми, кого нужно координировать. Итог печален. После некоторого периода неразберихи на два-четыре квартала причиной провала называют плохие требования. Если в этот момент в компании нет аналитика, его нанимают, и цикл повторяется с тем же итогом. А если аналитик ещё и подходит с классическими процессами, срисованными из заказной разработки, то получается ещё хуже. Кроме этих проблем есть и такие явления, как поиск, что мы сможем быстро сделать, где на основе оценок от разработки возникает бесконечный дрейф продуктовых требований. Следом ползет архитектура и постановки задачи. В такой ситуации система требований в жестком шаблоне рассыпается карточным домиком. Бывает обратная задача: монетизация имеющихся технических возможностей у системы, которая развивается под действием технологической, а не продуктовой стратегии. В этом случае классические подходы часто заканчиваются фатальным конфликтом между аналитиком и командой. Понимание качественных требований при переходе из длинных итерациий в короткие меняется. Полнота и непротиворечивость теряют свои позиции, зато становятся важны нужность, эффективность и прослеживаемость. Уходят задачи заложить верный бюджет и сроки, а потом доказать заказчику, что всё сделано. Возникает задача удержать в балансе это "ведро с гайками", чтобы система собралась в единое целое и заработала уже в этой итерации, принося пользу. А еще важно уберечь команды от лишних действий (но главное - лишнего кода), не работающих на итоговую цель. В докладе я раскрою описанные проблемы. Обсудим, куда смотреть, чтобы понять, что они есть, и расскажу свои предложения, как с ними бороться. Мы увидим, что неизбежно придется влезть на все уровни от продуктовых требований до архитектуры и постановок задач программистам, иначе не работает. Придется договариваться о разделении полномочий и заглядывать с фонарём туда, куда не все хотят смотреть. Обсудим, как поделить с остальной командой зоны ответственности: где мы ставим на учёт принятые решения, где фасилитируем, где проектируем сами, а где выполняем координацию. Из этого обсуждения так же вытекает вариант ответа, куда развиваться аналитику и как ему жить в Agile и приравненных к нему ситуациях. Я покажу быстрые, грязные и дешевые инструменты визуализации, выявления и анализа требований для таких ситуаций. Среди них: - Бизнес канвас - Карты и эскизы процессов - Двумерный мапинг историй - Карты влияния (Impact mapping) - Изображение системного ландшафта и архитектуры в стиле 4Context - CQRS и другие паттерны, дополняющие и заменяющие CRUD+ - Сценарии или диаграммы взаимодействия для систем и компонентов К докладу есть мастер класс "Практика работы с требованиями для сложного сервиса", где желающие смогут увидеть или даже попробовать вариант быстрого процесса работы от продуктовых требований до бэклогов спринта в действии. | Сергей Нужненко |