В апреле на Analyst Days широкой аналитической общественности был презентован первый открытый BDD проект в рамках #NoBA инициативы: http://analystdays.com/ru/talk/33417 Число волонтёров растёт.

Предлагаю встретиться спустя два месяца и посмотреть, что у нас успело получиться.

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

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

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

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

Некоторые разделы доклада:

·         Адаптация жизненного цикла пожеланий и задач под потребности команды.

·         О том, как мы планируем релизы.

·         О работе с требованиями и документами.

·         О работе с тестовой документацией.

·         Полезные привычки проектной работы в Devprom (и не только).

Без нудной теории. Только практика. Кратко. Без воды. Что-то может показаться очевидным. Обсуждение по результатам доклада приветствуется.

• План проекта и мир наших фантазий.
• Роль аналитика в укреплении или разрушении мира фантазий.
• Какие команды наиболее успешны - гетерогенные или гомогенные по отношению к риску?
• Учет гендерного фактора при планировании проекта.
• Особенности кросскультурных коммуникаций.
• Манипуляции командой или менеджером при сообщении о риске.
• Текущее состояние человека и восприятие им риска.
• Конфликты и управление риском.
• Доверие и управление риском.
• Чек-лист гарантированных когнитивных искажений.
• Как влияют автоматы, групповая динамика и игры на мир фантазий.
• Секретный блок.

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

Вспомним первый ЛАФ. Какие темы были в ходу? Как писать требования и что такое Use Case. Потом мы с интересом обсуждали управление изменениями и организацию работ команд аналитиков, а в прошлом году уже начали затрагивать тему Enterprise Architecture.

Хотелось бы продолжить развитие этих тем, углубившись в понятие IT-стратегии.

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

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

Не существует проектов, где на все вопросы имелись бы полные и однозначные ответы. Мы всегда вынуждены работать в условиях неопределенности. Чем крупнее компания, чем сложнее её бизнес и IT-структура, чем масштабнее проект, тем больше неопределённости. Аналитика можно сравнить с сапером на минном поле - цена ошибки может быть непомерно высока.

Часто неопытные специалисты закрывают неопределенности предположениями, сформированными на интуитивном уровне, без достаточной аналитический проработки. Риски, которые могут вызвать неверные (или не сбывшиеся) предположения, не документируются, не оценивается их влияние на успех проекта. Ограничения, разработанные как ответы на риски и предположения, явно не документируются и не доводятся до заинтересованных лиц. Все это может привести к печальным результатам. Не надо идти через «минное поле» без разведки! Давайте научимся эффективно работать в этих условиях!

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

К счастью, в отличие от сапера, аналитик может ошибаться не один раз... Я расскажу, на каких «минах» мне и моим коллегам приходилось «подорваться».

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

Юлия Фокина, Сергей Калинов

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

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

Что нужно знать и помнить, чтобы гарантированно прийти к успеху?

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

Более того, мы покажем, как использование архитектуры предприятия позволяет решать нечётко сформулированные задачи и вносит элемент творчества в нашу работу.

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