Ирина Гертовская

В докладе расскажу о путях создания и развития подразделений системных аналитиков в ИТ-компании. На основе своего опыта - о проблемах, поиске решений, пробах и ошибках, и о результатах. Рассмотрю вопросы: 

• Как не потонуть в ворохе задач? (цели отдела, задачи сотрудников)
• Как оценить результаты? ( критерии успеха)
• Менеджер проекта: друг или враг? (как взаимодействовать с проектами не враждуя)  
• Как взаимодействовать с другими подразделениями? (кто виноват в ошибке и как искать не виноватых, а причину)
• Сотрудники – основа отдела: по каким принципам отбирать, как развивать, оценивать, как снизить риски ухода? 
• Что есть локомотив развития? (триада технологического развития: технологии, база знаний, обучение)

Если эти вопросы у вас тоже возникают - приходите обсудить наболевшее!

Работа аналитика и интуиция: есть ли связь между этими понятиями? Должен ли аналитик рассматривать только логически обоснованные решения? Случались ли у вас в работе случаи, когда внутренний голос утверждает нечто, вроде бы противоречащее аргументам и доводам? Должен ли аналитик в процессе работ обращать внимание на интуитивные ощущения?

В докладе расскажу о своем подходе к принятию решений на основе интуитивной "правильной первой мысли" и применения методов бизнес-анализа. На примерах рассмотрим, за какие бизнес-аналитические ниточки потянуть интуицию, чтобы раскрыть источники интуитивной догадки, подтвердить или опровергнуть "первую мысль".

Игра-симуляция. Время - 3 часа.

Соведущий - Юлия Смирнова.

"Начальник отдела - это не профессия"

Из разговоров программистов 90-х годов

Кто лучше других аналитиков должен обладать компетенциями отдела?

Кто чаще других вынужден разбираться одновременно в ворохе разноплановых задач?

Кто обязан «держать руку на пульсе», знать, предвидеть, предотвращать?

И при этом - оставаться нормальным человеком, понимать, сочувствовать, переживать, помогать, утешать...

В игре-симуляции рассмотрим наболевшие проблемы руководителя подразделения аналитиков, поищем решения, обсудим результаты с участниками. Игра поможет взглянуть на проблемы под другим углом, получить совет от коллеги, найти неординарное решение и просто хорошо провести время. А еще - позволить аналитикам увидеть своего начальника изнутри, понять его. 
Надеемся, что игра будет интересна не только руководителям отделов (подразделений), тим-лидам, главным аналитикам, но и всем, кто в своем росте стремиться к этим позициям.

Поговорим о том, что может и должен предпринять аналитик, чтобы разрабатываемое ПО было внедрено в срок. Рассмотрим организационные и иные мероприятия, их подготовку, особенности выполнения при внедрении взаимодействующих информационных систем. Основные разделы доклада: план внедрения, регламенты работ пользователей, использование НСИ при внедрении смежных систем, миграция данных из систем-предшественников, интерфейсы обмена данными при внедрении смежных систем.

Уважаемые представители оргкомитета!

Выполняя просьбу Александра о наиболее подробном описании темы и с учетом вопросов по докладу Минска, многое (не все) написано не в формате тезисов, а в формате доклада и с заметками для слайдов (курсивом). Но, конечно, это не окончательный доклад.

Если читать долго (много буквов!) - сообщите, напишу короче.

Методика выработана для крупной многофункциональной корпорати вной системы, состоящей из нескольких подсистем (учетных, транспортно-логистических, отчетных) и обеспечивающей интеграцию Корпорации с клиентами и партнерами.  Характерна сложная зависимость и влияние информационных объектов и операций по ним на другие информационные объекты/операции как внутри одной подсистемы, так и другие подсистемы и системы Корпорации и внешние системы. Приостановка работы системы является по определению недопустимой. Существенно: некоторые проектные документы (Альбомы ТФФ - Альбомы требований к интерфейсам обмена), которые готовим мы в рамках проектных работ, Заказчик передает владельцам и разработчикам внешних систем за строго определенное время до начала эксплуатации версии, для того, чтобы внешние системы успели разработать и установить новую версию своего ПО.

По заявкам, поступающим от Заказчика (на основании изменений к нормативно-правовых актов (далее - НПА, проекты НПА) или для оптимизации работ) в системе учета JIRA регистрируются доработки для каждой подсистемы отдельно в разрезе заявки и подсистемы. После предварительного анализа и определения трудозатрат и в соответствии со сроком вступления в действие НПА доработки включаются в версию, передаваемую Заказчику к заранее определенной дате. Версия содержит изменения по всем ПО в зоне ответственности Исполнителя. Доработки, по различным заявкам Заказчика (имеющие разные основания для включения в версию), входящим в одну версию, часто затрагивают  одну и ту же функциональность или влияют на смежные функции системы.  Т.е. в версии могут содержаться разные доработки, влекущие изменение одних и тех же функций одного и того же документа.  Но в процессе работ по доработкам версии от Заказчика могут поступить изменения к проектам НПА, поступившим первоначально или перенос сроков вступления в действие НПА или новые заявки (которые нужно реализовать в те же сроки), влияющие на ту же функциональность.

Система достаточно большая, сроки проектирования, разработки, подготовки проектных документов очень жесткие. Зачастую изменения проектов НПА поступает уже после начала не только проектирования, но и разработки. Поэтому отследить все изменения в оперативном режиме, вовремя перепроектировать, передать в разработку по всем подсистемам и не сломать решения по доработкам, связанным с другими заявками Заказчика, но по этой же функциональности - задача не совсем простая. При этом проектную документацию нужно передать в установленные сроки по версии и строго описывающую доработки с учетом поступивших изменений.

Количественно по одной версии (периодичность версий - 2-3 месяца):

- доработок в версии по одной подсистеме: 150-250;

- изменяемых интерфейсов - 50-70;

- изменяемых подсистем: обычно 3, бывает до 6;

- (продумать еще количественные показатели).

Мой рассказ о том, как мы формируем требования к интерфейсам обмена на основании доработок, контролируем синхронность функциональных изменений в разных подсистемам (учетной, транспортной, отчетной) и по связанной функциональности.   

Что нам помогает:

1. Договоренность с Заказчиком о сроках поступления заявок и включении доработок в версию. Конечно, сроки далеко не всегда выдерживаются в т.ч. по причинам, не зависящим от Заказчика.  

2. Инструментарий

2.1. JIRA с высокой степенью кастомизации, единый подход:  

– требования НПА/запросы Заказчика, связь НПА и доработок;

- доработки в разрезе подсистем ПО;

- интерфейсы обмена (ТФФ) и Альбомы, содержащие их описание;

- обращения, ошибки.

Настроены типы связей и стараемся их отражать.

Показать описание доработки.

2.2. Subversion, хранилище документации:

- поддержка версионности;

- структуризация хранения документов;

- обязательность использования;

- централизованное решение для распределенной команды.

Показать структуру Альбома ТФФ, версионность, ревизии.

2.3. Система ведения требований к интерфейсов обмена (ТФФ), единое хранилище состояния интерфейсов (ТФФ), программы формирования Альбома с учетом отражения артефактов в разных разделах Альбома и контроля непротиворечивости. Хранимые значения:

- наименование, назначение, маршрутизация;

- мнемоника, тип данных, длина;

- комментарии (условия контроля реквизита в ПО);

- версия ТФФ, дата начала действия версии, дата окончания действия предыдущей версии,

- шаблон, пример.

Особенности изменения версионности ТФФ.

3. Методика, обязательная к выполнению, разработки для внутреннего использования:

- регистрация сущностей в JIRA;

- контроль взаимосвязанных элементов, синхронизация;

- разнообразные отчеты, контроль выполнения.

Показать зависимости функциональности ПО и изменений интерфейсов.

Пример зависимости изменения интерфейса и ПО.

Показать связи отражения изменений ПО и интерфейсов на разных этапах работ с указанием зоны ответственности бизнес анализа, системного анализа, разработки.  

Показать схему ЖЦ доработок этапов анализа и проектирования с  указанием точек контроля:

- полнота регистрации доработок по подсистемам, наличие зарегистрированных изменений интерфейсов;

- включение доработок в версию, изменений интерфейсов в ближайшую версию Альбома ТФФ;

- проверка изменяемых функций ПО по доработкам и изменяемых интерфейсов;

- подготовка бизнес требований по изменяемым интерфейсам;

- согласование бизнес требований внутри бизнес аналитиков по смежным функциям ПО;

- внесение изменений в систему ведения ТФФ;

- формирование Альбома ТФФ;

- согласование Альбома со стороны бизнес аналитиков, системных аналитиков (технических архитекторов) всех подсистем;

- согласование с Заказчиком, через Заказчика - с разработчиками внешних систем.

При поступлении новых заявок от Заказчика, изменении ранее поступивших, поступлении внутренних и/или внешних замечаний к интерфейсам обмена весь цикл выполняется в полном объеме, с обязательным отражением изменений в JIRA, проверкой доработок (при необходимости - их корректировкой), внесением изменений в систему ведения ТФФ, формирования Альбома ТФФ, обязательным пересогласованием.

Автоматизация позволила быстро вносить изменения и переформировывать Альбом, исключить ручное дублирование одних и тех же сведений в разных разделах Альбома (и соответственно, технические ошибки, особенно по срочным изменениям Альбома перед самой публикацией). И конечно, снижение трудозатрат, снижение стрессовости работ.   

Также можно рассказать и про автоформирование смысловой части ТЗ. Но не будет ли это много для 40-минутного доклада? Чтобы не получилось как в Минске - элементарно не хватило времени и доклад получился скомканный и непонятный.