Все люди ошибаются… Но могут ли быть ошибки, допущенные аналитиком, полезны компании? Иногда могут! Я расскажу, как это может быть, если идет заказной проект, риски ошибок в ТЗ поделены с заказчиком, а ошибки обнаруживаются уже при установке тестовой версии у заказчика. Так же я поясню:

1. Каким образом создаются предпосылки для таких ошибок.

2. Как ведутся такие проекты.

3. И кто их ведет.

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

Эдуард Галиаскаров

Игры, в которые следует играть, чтобы лучше понять требования

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

Денис Казика

Внедрение ITIL/ITSM

1. общее описание компании

2. описание ситуации (назревших проблем) и предпринятые меры для ее изменения (улучшения)

3. описание того, как внедряли процессы согласно ITIL/ITSM

4. риски при внедрении и как их устраняли

Байкин Александр

Автомир, Ведущий Аналитик

bas_4all@inbox.ru

Мастер класс “Варианты использования (use-case) в действии”

Варианты Использования (use cases) - это наиболее популярный метод описания пользовательских требований в последние нескольких лет. Но только единицы владеют этим <<искусством>>. Да-да, не побоюсь этого слова, т.к. при правильном применении варианты использования дают неоспоримые преимущества: интуитивно понятны заказчикам и разработчикам; помогают выявить функциональные требования; диаграмма

помогает представить требования в целом; Аналитик фокусируется на потребностях Пользователя, а не на Системе и т.д.

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

Доклад “Типичные вопросы Аналитика”.

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

Денис Бесков

Как вариант — можно устроить на эти темы круглые столы, на каждом из которых я готов высказаться на 10 минут

КС “Методики расчёта эффективности системного аналитика”

Предположительный порядок обсуждения:

1. На какие показатели продукта и проекта влияет отсутствие/присутствие аналитика в проекте и его плохая/хорошая работа

2. Как эти показатели можно измерять и сравнивать

3. Как посчитать экономическую отдачу от работы конкретного аналитика в проекте

КС “Сравнение подходов к изменению требований — классический и agile-подходы”

КС “Планирование рентабельной глубины восстановления требований”

КС “Организация обмена практиками в отделе”

Корнипаев Илья

Требования к ПО и использование творческих методов

(По мотивам тренинга Нила Мейдана:

http://www.softwarepeople.ru/2011/speakers/maiden/)

9 апреля 2011 в рамках проведения конференции SoftwarePeople 2011 состоялся тренинг Нила Мейдена " Креативные техники сбора требований", на котором мне удалось побывать. Нил поднял интересную тему - сочетание классических подходов для понимания того что же нужно сделать, с креативными подходами при разработке новых решений. Основной задачей применения креативных техник, по мнению автора, является создание принципиально новых решений, тех, которые уже невозможно получить с помощь классически методов сбора требований. Его метод предусматривает проведение специальных семинаров (workshops). На семинарах Нил применяет следующие методики - мозговой штурм, удаление или обход ограничений, применение аналогий из других предметных областей, комбинирование идей и различные способы визуализации. В рамках своего доклада я хотел бы освятить свою точку зрения на применения творческих подходов для сбора требований, а также обменяться с коллегами мнениями по данному вопросу.

Цепков Максим

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

«DDD для корпоративных систем — модель вместо требований»

В докладе я расскажу про Domain Driven Design, который является эффективным и развивающимся подходом к проектированию. DDD говорит о построении модели, которая рождаясь как модель предметной области, развивается в модель системы. Модель заменяет традиционные требования, которые в этом процессе служат лишь для построения и изменения модели, после чего теряют актуальность. Модель строится на Едином языке, которой является основой общения всех участников процесса — от стейкхолдеров и пользователей заказчика до разработчиков и службы поддержки, включая, естественно, и аналитиков, которые вырабатывают этот язык совместно с остальными.

Теоретические подходы будут иллюстрированы практическим опытом применения моделей для проектирования корпоративных систем. У нас в компании (CUSTIS) сформировался шаблон модели корпоративной системы, включающий в себя объектную модель описания структуры предметной области, необъектную учетную модель и связь между ними. Применение модели для проектирования обеспечивает эффективное развитие системы на протяжении многих лет вслед за развитием бизнес-процессов заказчика.

«Концепция балансового учета и ее применение для предприятий»

Концепции балансового учета служат основой бухгалтерского учета предприятий и банков. Но представление о них полезно иметь не только аналитикам, проектирующим бухгалтерские системы, но и аналитикам, работающим над корпоративными системами и разработчикам. Потому что вся деятельность предприятия тем или иным образом отражается в учете и представляет для бухгалтеров интерес, аналитики должны хорошо понимать бухгалтеров. Однако, изложение балансового учета, начинающее от концепций и показывающее, как на их основе строится учет, в свободном доступе отсутствует, во всяком случае — не я его не встречал. В лучшем случае в начале изложения идет перечисление принципов и исторический экскурс, после чего переходят к конкретным правилам бухгалтерского учета, которые «нельзя понять, а надо просто запомнить». Я рассказывал концепции балансового учета и обобщенную схему учета деятельности предприятия, которая получается на их основе во внутреннем курсе нашей компании (CUSTIS) и готов изложить их в виде доклада в первый день или просто рассказать во второй день для интересующихся.

«Психология взаимодействия — типология Майерс-Бриггс и командные роли Белбина»

Коммуникации играют очень важную при работе в группе, а в работе аналитика играют критическую роль. Есть много различных теорий и исследований, касающихся взаимодействия людей и работе в группах и командах. Две из них — типология Майерс-Бриггс и командные роли Белбина в свое время произвели на меня большое впечатление. Я рассказывал о них на внутренних семинарах компании готов поделиться на конференции, в первый или второй день. Может быть, есть и другие интересующиеся различными психологическими теориями, которым было бы интересно поделиться своими знаниями или поучаствовать в обсуждении, и можно устроить круглый стол

Попов Алексей Игоревич

Должность: Бизнес-аналитик

Компания: Новая Афина

Форма выступления: Доклад (Презентация)

Все гениальное просто. Лучшие практики в разработке ПО.

Описание выступления: Доклад посвящен такой теме как использование

различных практик при разработке программного обеспечения вне

зависимости от методологии разработки программного обеспечения, будь то

RUP, MSF, Agile или Водопад. Я хочу сделатьь очень небольшой доклад о

тех вещах, которые мы используем в компании и которые действительно

улучшают результаты разработки и позволяют добиться повышения

удовлетворенности наших заказчиков. Доклад планирую сделать небольшим,

только ключевые пункты по шагам, как мы ими пользуемся и какой от них

эффект, то есть очень кратко и по сути.

Карабанова Галина

Карабанова Г.Д., г. Санкт-Петербург, ведущий аналитик, руководитель проекта

Новичков А.Н., г. Москва, руководитель отдела внедрения, СМ-Консалт

Аналитик как проводник изменений в компании Заказчика

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

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

Продолжительность доклада: 20-30 мин.

Векленко Ирина Юрьевна

Мастер-класс "Анализируй это: Жизнь как Проект"

Мастер-класс посвящен профессиональным навыкам бизнес-аналитиков и ... применению их навыков не только на рабочем месте. Может ли Жизнь рассматриваться как Проект? Являются ли Повседневные действия Бизнес-процессами? Возможен ли реинжениринг процесса Совмещение работы и Личной жизни? Ответы на эти и еще многие вопросы ждут вас на мастер-классе. Готовьте вопросы!

форма выступления и его продолжительность: Мастер-класс, 1,5 часа (второй день?)

должность, название компании: Раскрашиваю жизнь

контактные данные: тел. +7 (906)0954338, mailto: i.veklenko@gmail.com, skype: mouse_i

Веденин Юрий

Круглый Стол "Оценка работы аналитика: качество через количество"

могу выступить с мини-докладом (5-10 мин) по этой теме для того, что "запустить" дискуссию круглого стола.

Собственно, суть в том, что оценить работу аналитика (хоть и не всю) можно, оценивая качество, производимых этим аналитиком артефактов: ТЗ, ТП, SRS, FRS, Vision&Scope, RFP, Proposal (КП) и т.д. Но что значит оценить качество артефактов? Сказать "ну, это такой, неплохой документ" или "отвратительно" недостаточно. Любая оценка должна давать нам что-то полезное: что в этом артифакте хорошо, что именно плохо, чтобы это "плохо" поправить. В ВВС США для пилотов создают т.н. Checklists, которые пилоты используют в полете для того, чтобы проверить, что они ничего не забыли (объемы и скорость обработки информации, с которыми им приходится работать в полёте, чаще всего превышают те, с которыми обычно работаем мы, да и степень ответственности чаще всего побольше). Что из себя представляет Checklist? Проще всего представить его как набор пунктов (требований) к оцениваемому объекту, на каждый из которых можно сказать либо "да", либо "нет":

- есть ли у документа История Изменений?

- подписаны ли все рисунки и графики?

- есть ли у документа Глоссарий?

- все ли "непонятные" термины помещены в Глоссарий?

- есть ли в документе орфографические, грамматические или синтаксические ошибки?

- и т.д.

На этом Круглом Столе (КС) предлагается:

1) попробовать составить 2-3 таких чек-листа на самые распространённые документы: SRS, Vision&Scope, Proposal (список документов можно варьировать).

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

3) обсудить возможность применения такого подхода на практике

Заборов Михаил

Компания:

ООО "Заказные ИнформСистемы" (CustIS)

Должность: Руководитель направления «Торговые сети»

О себе

В компании Заказные ИнформСистемы (CustIS) с 2002 года. С 2003 – руководитель направления «Биллинг для ЖКХ – ПТК Радей». С 2006 года - руководитель направления «Торговые сети».

Опыт: разработка архитектурных решений для учетно-аналитических программных комплексов, руководство проектами заказной разработки и реинжиниринга сложных программных систем.

Доклад

Заказная разработка. Системная архитектура вместо требований

Проблематика доклада:

Современное программное обеспечение представляет собой очень сложный объект. Кроме того ПО - это очень абстрактный (виртуальный) объект. Его очень сложно увидеть, пощупать, почувствовать, обозреть, померить. Какие обычно есть артефакты, глядя на которые можно «увидеть» систему:

документация на систему

экранные формы

исходный код

исполняемые модули...

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

Во время доклада Михаил поделится своим видением на решение проблемы.

Мочалoв Михаил

Доклад “Подготовка молодых кадров на должность системного аналитика”

Доклад “Планирование работ аналитика”

Ирина Левенец

Управление ожиданиями

Хочу рассказать об управлении требованиями с точки зрения управления ожиданиями

Сурова Ирина

Доклад “Сравнение форматов требований (на 2 день или в резерв)”

За последний год мне посчастливилось поработать со спецификациями требований в нескольких возможных видах: от word-овых документов до excel-таблиц и макетов GUI.

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

Программа ЛАФ 2011

Время	1-й поток (Конференц зал)	2-й поток (Галерея)
9-00	Регистрация
9-30
9-30	Открытие
9-50
10-00
10-45
10-55
11-40
11-40	Перерыв
12-00
12-00
12-45
12-55
13-40
13-40	Обед
14-40
14-40
15-25
15-35
16-20
16-20	Перерыв
16-40
16-40
17-25
17-35
18-20
18-20	Закрытие
19-00

Программа прошлого года для образца

Программа на 1ый день конференции ЛАФ 2010.

Время	1-й поток (Конференц зал)	2-й поток (Галерея)
9-00	Регистрация
9-30
9-30	Открытие
9-50
10-00	Ведение требований на несколько версий продукта Сурова Ирина (Москва)	Диаграммы планов счетов Цепков Максим (Москва)
10-45
10-55	Жизнь замечательных ТЗ Печенкин Григорий (Москва)	Как написать хорошее Коммерческое Предложение Веденин Юрий (Минск)
11-40
11-40	Перерыв
12-00
12-00	Свой среди чужих Байкин Александр (Москва)	Тестирование требований: Зачем - понятно, а вот Как? Нечаева Юлия (Москва)
12-45
12-55	Управление командой аналитиков Корнипаев Илья (Москва)	Написание тестов, как вид тестирования требований Мартыненко Сергей (Москва)
13-40
13-40	Обед
14-40
14-40	Бесконтактное обследование Левенец Ирина (Иваново)	Кросс-платформенное моделирование Иванов Денис (Санкт-Петербург)
15-25
15-35	Сценарное планирование Безуглый Дмитрий (Москва)	Инженерия требований на практике. Проблемы и решения Булуй Юрий (Москва)
16-20
16-20	Перерыв
16-40
16-40	Практика работы с требованиями в иностранной компании, или In Wiegers We Trust Белин Александр (Москва)	Спецификация программных систем Иванов Денис (Санкт-Петербург)
17-25
17-35	Специфика управления требованиями при разработке корпоративных коробочных решений Бредюк Константин (Москва)
18-20
18-20	Закрытие
19-00