В докладе хочется рассказать об опыте доточки TFS для нужд как аналитиков, так и проектных команд в большой компании, разрабатывающей продукты и сервисы. Команды используют как гибкие, так и не очень гибкие технологии, часть команд использует Enterprise Architect для создания требований.

Вместо эпиграфа:
До начала конференции меня раз сто предупреждали: 
- Главное - не обижайте Коржавина! 
- Почему я должен его обижать?! Я люблю стихи Коржавина, ценю его публицистику. Мне импонирует его прямота... 
- Коржавин - человек очаровательный. Но он человек резкий. Наверное, Коржавин сам вас обидит. 
- Почему же именно меня? 
- Потому что Коржавин всех обижает. Вы не исключение. 
- Зачем же вы меня предупреждаете? Вы его предупредите... 
- Если Коржавин вас обидит, вы не реагируйте. Потому что Коржавин - ранимый. 
- Позвольте, но я тоже ранимый! И Лимонов ранимый. И Алешковский. Все писатели ранимые! 
- Коржавин - особенно! Так что не реагируйте...
(Довлатов)

Случалось ли вам наблюдать, как продуктивность нескольких членов команды стремительно снижается из-за регулярных «наездов» вашего коллеги, имеющего славу человека эмоционального? Или как увольняют умного и талантливого разработчика только потому, что все устали от его экспрессии?

В рамках своего доклада я хочу поговорить о проблеме истерик, которые я наблюдаю в различных it-проектах как аналитик. Именно поговорить, потому что готовых рецептов у меня нет. Есть только наблюдения и информация, подчерпнутая из книжек по психологии (научно-популярной). Основная мысль моего доклада – что с эмоционально распущенным поведением члена команды в любом случае надо что-то делать, как надо что-то делать с регулярно «глючащим» сервером (потому что это попросту мешает работе). Сейчас я чаще всего наблюдаю бездействие в подобных случаях (руководители бездействуют, потому что легче уговорить более спокойных, более спокойные бездействуют – потому что легче отойти в сторону, замяв конфликт).

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

* Какие бывают нефункциональные требования и почему с ними так много путаницы?

* Как составлять шаблоны для определения нефункциональных требований

* Как выбирать методы и инструменты для определения нефункциональных требований

* Как нефункциональные требования связаны с функциональными

* Как нефункциональные требования связаны друг с другом

Всем, кто говорит: «Зачем писать правильно, мы же не на уроке русского языка», желаю встретить хирурга, который будет их оперировать со словами: «А зачем аккуратно резать и зашивать? Мы же не на курсах кройки и шитья».

Приведенная аналогия подходит и к правильному применению психологических знаний в работе аналитика. В своем докладе я расскажу:

• о негативных тенденциях, ошибках и опасностях применения примитивных психологических знаний в работе аналитика
• об основных иллюзиях и заблуждениях в понимании и применении на практике популярных  психологических терминов, которые используются  в докладах и различных статьях по аналитике ( например,  темперамент, дивергентное и конвергентное мышление, асимметрия полушарий, мотивация, мотивы, мотивирование сотрудников, смелая разработка авторских «психологических» классификаций)
• о результатах профессионального психологического эксперимента, проведенного среди IT-аналитиков отдельной компании, который  доказывает, что мотивация не является фактором профессиональной успешности аналитика,  и нет смысла осуществлять столь популярное  ее «повышение», «развитие» и «стимулирование»

Серпионова Е.И. кан.псих. наук, Екатеринбург

Коллеги, доброго времени суток.

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

О чем хочу рассказать:

• Где хранилась, как и кем разрабатывалась документация, каким образом осуществлялся обмен между проектной командой (без аналитика)?
• Что изменилось после того, как в команду пришел аналитик?
• Используемые приемы (примеры)
• Используемые инструменты (примеры)
• Совместная работа ресурса хранения документации и системы управления проектами (пример реализации)
• Интересные наблюдения и предложения

Формат выступления — доклад на 20 минут. Постараюсь сделать все максимально кратко и понятно.

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

Хочу показать новые тренды в области развития ПО для продацов турпродуктов и потребителей турпродуктов.

Выступление делится на 3 части:

1. Введение в предметную область. Этот раздел будет интересен тем, кто не имеет опыта работы и не знаком с терминологией и законодательством в этой области.

Кроме этого, я расскажу немного об истории развития GDS, вы узнаете, чем отличаются ARS от HRS и что такое PMS.

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

3. Здесь будет рассказано о новых трендах в туристском бизнесе, о перспективных сегментах в разработке туристского ПО.

Интернет проекты "правильно" вести с использованием итераций.

Планировать итерации удобно в "Сценариях использования" (Юзкейсах) и в "историях пользователей", который являются экземплярами юзкейсов или СИСов (сценариев использования системы)

в рамках мастер класса будет показано как "искать" СИСы из "потока сознания заказчика", а также как СИСы связаны с "Бизнес сценариями использования" - или с описаниями бизнес процессов, которые будут поддержаны разрабатываемой ИС. 

Будет обсуждена связь "историй пользователей" в которых ведется работа в agile/SCRUM разработках с СИСами. Показано, что выявление СИСов в таких проектах - это "большая подмога фронту".

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

Я расскажу о трёх интересных и немного нестандартных проектах, реализованных с помощью Cradle, тем не менее позволяющих увидеть некоторые преимущества использования данного инструмента.

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

Подробнее о Cradle:

• http://www.threesl.com/index_russia.php
• http://www.saturs.ru/index.php?r=block/plain&label=cradle

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

На AnalystDays 2013 коллеги хорошо приняли наш совместный с Ириной Суровой доклад «Идеальный аналитик и почему его не может быть» (отзыв Максима Цепкова). Однако коллеги правильно заметили, что в рамках доклада мы преимущественно осветили использование модели с позиции руководителя отдела, или специалиста ответственного за подбор аналитика в проекте.

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