Программный директор ЛАФ, автор и ведущий курсов для аналитиков
Ранее: проектирование, разработка и внедрение ИТ-систем для крупных промышленных предприятий и финтеха, опыт работы во всех ролях команды разработки
Интересы
Основные подходы
Деятельность в профессиональном сообществе
Название Конференция Описание | Автор |
---|---|
Отдел системного анализа: создать, развить, расширить. Дорожная карта и путевые заметки | |
ЛАФ-2022 [Подробно...][Скрыть] В докладе расскажу о путях создания и развития подразделений системных аналитиков в ИТ-компании. На основе своего опыта - о проблемах, поиске решений, пробах и ошибках, и о результатах. Рассмотрю вопросы:
Если эти вопросы у вас тоже возникают - приходите обсудить наболевшее! | Ирина Гертовская |
Найти и обезвредить: работа аналитика с рисками и риски в работе аналитика | |
ЛАФ-2020 [Подробно...][Скрыть] Поговорим о рисках: проектных, межпроектных, иных: что говорит теория и что на практике. На практических примерах покажу как аналитику выявлять риски и что с ними делать. | Ирина Гертовская |
Гадание на BABOK | |
ЛАФ-2019 [Подробно...][Скрыть] Работа аналитика и интуиция: есть ли связь между этими понятиями? Должен ли аналитик рассматривать только логически обоснованные решения? Случались ли у вас в работе случаи, когда внутренний голос утверждает нечто, вроде бы противоречащее аргументам и доводам? Должен ли аналитик в процессе работ обращать внимание на интуитивные ощущения? В докладе расскажу о своем подходе к принятию решений на основе интуитивной "правильной первой мысли" и применения методов бизнес-анализа. На примерах рассмотрим, за какие бизнес-аналитические ниточки потянуть интуицию, чтобы раскрыть источники интуитивной догадки, подтвердить или опровергнуть "первую мысль". | Ирина Гертовская |
От нуля и под ключ | |
ЛАФ-2018 [Подробно...][Скрыть] Длительность - 2 часа. На мастер-классе рассмотрим задачи аналитика на каждом этапе разработки программного обеспечения, от предпроектного обследования до внедрения и сопровождения. Поговорим о том, какие источники информации используются аналитиком на каждом этапе, какие результаты получает аналитик и как они применяются в дальнейшем. Какие задачи нельзя упустить, на что следует обратить внимание, что учесть для успешной разработки, внедрения, эксплуатации. Рассмотрим типичные проблемные точки и пути разрешения. Мы не сможем за два часа рассмотреть подробно все работы аналитика, но успеем выделить основные задачи, обсудить цели и результаты каждого этапа. | Ирина Гертовская |
Плох тот солдат, который не мечтает... | |
ЛАФ-2018 [Подробно...][Скрыть]
Игра-симуляция. Время - 3 часа. "Начальник отдела - это не профессия" Из разговоров программистов 90-х годов Кто лучше других аналитиков должен обладать компетенциями отдела? Кто чаще других вынужден разбираться одновременно в ворохе разноплановых задач? Кто обязан «держать руку на пульсе», знать, предвидеть, предотвращать?
И при этом - оставаться нормальным человеком, понимать, сочувствовать, переживать, помогать, утешать... | Ирина Гертовская |
Начерти на карте план (с) - поговорим о планировании работ аналитиков | |
ЛАФ-2017 [Подробно...][Скрыть] На круглом столе поговорим о планировании работ аналитиков, об оценке трудозатрат, сроках выполнения. Как Вы расчитываете трудозатраты? Как определяете сроки выполнения? Есть ли методики расчета или используете экспертные оценки? Какова необходимая точность расчетов? Что делаете, если работы растягиваются, сроки нарушаются, возникают дополнительные работы? Почему аналитики не любят оценку трудозатрат? Почему не любим указать сроки? Можно ли превратить оценку трудозатрат и сроков из дамоклова меча в помощника? Рассмотрим наиболее распространенные методики оценки трудозатрат. И поделюсь успешным опытом (около 10 лет) планирования работ аналитиков.
| Ирина Гертовская |
И разработать, и внедрить. Проблемы внедрения с точки зрения аналитика | |
ЛАФ-2016 [Подробно...][Скрыть] Поговорим о том, что может и должен предпринять аналитик, чтобы разрабатываемое ПО было внедрено в срок. Рассмотрим организационные и иные мероприятия, их подготовку, особенности выполнения при внедрении взаимодействующих информационных систем. Основные разделы доклада: план внедрения, регламенты работ пользователей, использование НСИ при внедрении смежных систем, миграция данных из систем-предшественников, интерфейсы обмена данными при внедрении смежных систем.
| Ирина Гертовская |
"МЫ ВЫБИРАЕМ, НАС ВЫБИРАЮТ...". КАК ВЫБРАТЬ АНАЛИТИКА | |
ЛАФ-2016 [Подробно...][Скрыть]
Проблемы подбора аналитиков... Методы отбора, как правило, специфичны с учетом потребностей проектов, условий работы и предпочтений тех, кто выбирает. Суть проведения круглого стола - услышать мнение не одного, а нескольких компетентных специалистов, обменяться мнениями. Обсудить принципы, предложить методику, подход, к определению требований к кандидату. Обменяться опытом по оценке кандидатов.
| Ирина Гертовская |
Управление требованиями и автоматизация подготовки проектных документов | |
ЛАФ-2015 [Подробно...][Скрыть] Уважаемые представители оргкомитета! Выполняя просьбу Александра о наиболее подробном описании темы и с учетом вопросов по докладу Минска, многое (не все) написано не в формате тезисов, а в формате доклада и с заметками для слайдов (курсивом). Но, конечно, это не окончательный доклад. Если читать долго (много буквов!) - сообщите, напишу короче. Методика выработана для крупной многофункциональной корпорати вной системы, состоящей из нескольких подсистем (учетных, транспортно-логистических, отчетных) и обеспечивающей интеграцию Корпорации с клиентами и партнерами. Характерна сложная зависимость и влияние информационных объектов и операций по ним на другие информационные объекты/операции как внутри одной подсистемы, так и другие подсистемы и системы Корпорации и внешние системы. Приостановка работы системы является по определению недопустимой. Существенно: некоторые проектные документы (Альбомы ТФФ - Альбомы требований к интерфейсам обмена), которые готовим мы в рамках проектных работ, Заказчик передает владельцам и разработчикам внешних систем за строго определенное время до начала эксплуатации версии, для того, чтобы внешние системы успели разработать и установить новую версию своего ПО. По заявкам, поступающим от Заказчика (на основании изменений к нормативно-правовых актов (далее - НПА, проекты НПА) или для оптимизации работ) в системе учета JIRA регистрируются доработки для каждой подсистемы отдельно в разрезе заявки и подсистемы. После предварительного анализа и определения трудозатрат и в соответствии со сроком вступления в действие НПА доработки включаются в версию, передаваемую Заказчику к заранее определенной дате. Версия содержит изменения по всем ПО в зоне ответственности Исполнителя. Доработки, по различным заявкам Заказчика (имеющие разные основания для включения в версию), входящим в одну версию, часто затрагивают одну и ту же функциональность или влияют на смежные функции системы. Т.е. в версии могут содержаться разные доработки, влекущие изменение одних и тех же функций одного и того же документа. Но в процессе работ по доработкам версии от Заказчика могут поступить изменения к проектам НПА, поступившим первоначально или перенос сроков вступления в действие НПА или новые заявки (которые нужно реализовать в те же сроки), влияющие на ту же функциональность. Система достаточно большая, сроки проектирования, разработки, подготовки проектных документов очень жесткие. Зачастую изменения проектов НПА поступает уже после начала не только проектирования, но и разработки. Поэтому отследить все изменения в оперативном режиме, вовремя перепроектировать, передать в разработку по всем подсистемам и не сломать решения по доработкам, связанным с другими заявками Заказчика, но по этой же функциональности - задача не совсем простая. При этом проектную документацию нужно передать в установленные сроки по версии и строго описывающую доработки с учетом поступивших изменений. Количественно по одной версии (периодичность версий - 2-3 месяца): - доработок в версии по одной подсистеме: 150-250; - изменяемых интерфейсов - 50-70; - изменяемых подсистем: обычно 3, бывает до 6; - (продумать еще количественные показатели). Мой рассказ о том, как мы формируем требования к интерфейсам обмена на основании доработок, контролируем синхронность функциональных изменений в разных подсистемам (учетной, транспортной, отчетной) и по связанной функциональности. Что нам помогает: 1. Договоренность с Заказчиком о сроках поступления заявок и включении доработок в версию. Конечно, сроки далеко не всегда выдерживаются в т.ч. по причинам, не зависящим от Заказчика. 2. Инструментарий 2.1. JIRA с высокой степенью кастомизации, единый подход: – требования НПА/запросы Заказчика, связь НПА и доработок; - доработки в разрезе подсистем ПО; - интерфейсы обмена (ТФФ) и Альбомы, содержащие их описание; - обращения, ошибки. Настроены типы связей и стараемся их отражать. Показать описание доработки. 2.2. Subversion, хранилище документации: - поддержка версионности; - структуризация хранения документов; - обязательность использования; - централизованное решение для распределенной команды. Показать структуру Альбома ТФФ, версионность, ревизии. 2.3. Система ведения требований к интерфейсов обмена (ТФФ), единое хранилище состояния интерфейсов (ТФФ), программы формирования Альбома с учетом отражения артефактов в разных разделах Альбома и контроля непротиворечивости. Хранимые значения: - наименование, назначение, маршрутизация; - мнемоника, тип данных, длина; - комментарии (условия контроля реквизита в ПО); - версия ТФФ, дата начала действия версии, дата окончания действия предыдущей версии, - шаблон, пример. Особенности изменения версионности ТФФ. 3. Методика, обязательная к выполнению, разработки для внутреннего использования: - регистрация сущностей в JIRA; - контроль взаимосвязанных элементов, синхронизация; - разнообразные отчеты, контроль выполнения. Показать зависимости функциональности ПО и изменений интерфейсов. Пример зависимости изменения интерфейса и ПО. Показать связи отражения изменений ПО и интерфейсов на разных этапах работ с указанием зоны ответственности бизнес анализа, системного анализа, разработки. Показать схему ЖЦ доработок этапов анализа и проектирования с указанием точек контроля: - полнота регистрации доработок по подсистемам, наличие зарегистрированных изменений интерфейсов; - включение доработок в версию, изменений интерфейсов в ближайшую версию Альбома ТФФ; - проверка изменяемых функций ПО по доработкам и изменяемых интерфейсов; - подготовка бизнес требований по изменяемым интерфейсам; - согласование бизнес требований внутри бизнес аналитиков по смежным функциям ПО; - внесение изменений в систему ведения ТФФ; - формирование Альбома ТФФ; - согласование Альбома со стороны бизнес аналитиков, системных аналитиков (технических архитекторов) всех подсистем; - согласование с Заказчиком, через Заказчика - с разработчиками внешних систем. При поступлении новых заявок от Заказчика, изменении ранее поступивших, поступлении внутренних и/или внешних замечаний к интерфейсам обмена весь цикл выполняется в полном объеме, с обязательным отражением изменений в JIRA, проверкой доработок (при необходимости - их корректировкой), внесением изменений в систему ведения ТФФ, формирования Альбома ТФФ, обязательным пересогласованием. Автоматизация позволила быстро вносить изменения и переформировывать Альбом, исключить ручное дублирование одних и тех же сведений в разных разделах Альбома (и соответственно, технические ошибки, особенно по срочным изменениям Альбома перед самой публикацией). И конечно, снижение трудозатрат, снижение стрессовости работ. Также можно рассказать и про автоформирование смысловой части ТЗ. Но не будет ли это много для 40-минутного доклада? Чтобы не получилось как в Минске - элементарно не хватило времени и доклад получился скомканный и непонятный. | Ирина Гертовская |
Показатели назначения. Их роль и место в проектной и пользовательской документации | |
ЛАФ-2015 [Подробно...][Скрыть] Формат выступления - блиц-доклад или круглый стол (если будет желание публики). Возможно изменение лектора или ведение доклада с содокладчиком (ФИО укажу позже). Рассматриваем показатели назначения к уже разработанной и эксплуатируемой системе. Как правило, показатели назначения определны при разработке и не изменяются в процессе изменений функциональности. Т.е. в соответствующих разделах ТЗ указываем - изменений не требуется (стандартной фразой). Нобывают случаи, когда не рассмотренное влияние показателей назначения может пагубно сказаться на работоспообности системы. Деление показателей назначения на: - функциональные - Технологические - Технические Рассматриваемые вопросы: - Как избежать случаев, когда показатели назначения изменяются, а мы отделались стандартной фразой. - Как эффективно оценить показатели назначения (рекомендации). - Как не преувеличить объемы бедствия. - Всегда ли аналитик имеет возможность оценить показатели назначения. - Какие именно показатели назначения входят в зону ответственности аналитика. - Какие показатели назначения не входят в зону ответственности аналитика и кто отвечает за них. - Где и как должны быть отражены показатели назначения. - Место работ по показателям назначения при работах аналитиков по шаблонам проектирования.
Презентация доклада направлена 18.06.2015 почтой. | Ирина Гертовская |