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

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

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

Поговорим о рисках: проектных, межпроектных, иных: что говорит теория и что на практике. На практических примерах покажу как аналитику выявлять риски и что с ними делать.

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

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

Длительность - 2 часа.

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

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

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

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

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

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

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

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

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

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

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

На круглом столе поговорим о планировании работ аналитиков, об оценке трудозатрат, сроках выполнения.

Как Вы расчитываете трудозатраты? Как определяете сроки выполнения? Есть ли методики расчета или используете экспертные оценки? Какова необходимая точность расчетов? Что делаете, если работы растягиваются, сроки нарушаются, возникают дополнительные работы?

Почему аналитики не любят оценку трудозатрат? Почему не любим указать сроки? Можно ли превратить оценку трудозатрат и сроков из дамоклова меча в помощника?

Рассмотрим наиболее распространенные методики оценки трудозатрат. И поделюсь успешным опытом (около 10 лет) планирования работ аналитиков. 

 

 

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Формат выступления - блиц-доклад или круглый стол (если будет желание публики).

Возможно изменение лектора или ведение доклада с содокладчиком (ФИО укажу позже).

Рассматриваем показатели назначения к уже разработанной и эксплуатируемой системе.

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

Т.е. в соответствующих разделах ТЗ указываем - изменений не требуется (стандартной фразой).

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

Деление показателей назначения на:

- функциональные

- Технологические

- Технические

Рассматриваемые вопросы:

- Как избежать случаев, когда показатели назначения изменяются, а мы отделались стандартной фразой. 

- Как эффективно оценить показатели назначения (рекомендации).

- Как не преувеличить объемы бедствия.

- Всегда ли аналитик имеет возможность оценить показатели назначения.

- Какие именно показатели назначения входят в зону ответственности аналитика.

- Какие показатели назначения не входят в зону ответственности аналитика и кто отвечает за них. 

- Где и как должны быть отражены показатели назначения.

- Место работ по показателям назначения при работах аналитиков по шаблонам проектирования. 

 

Презентация доклада направлена 18.06.2015 почтой.