Доклад  "Токсичный драйвер".

Токсичный  драйвер (со стороны клиента) обычно редкость на проекте.

Стиль его работы: фонтанировать идеями, настаивать, обижаться, забывать договоренности и требовать исполнения сиюминутных желаний.

Поделюсь опытом, как приходится с таким работать, как чувствует себя команда, как планировать и сдавать доработки проекта.

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

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

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

Основные вопросы: как объяснить сложное просто на примере моделирования данных и интеграции информационных систем

Уровень слушателей: буду рад видеть всех

Рассказать подробно о том, как правильно и быстро привлечь новых участников проекта с участием более 30 человек

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

1) Как коммуницировать и разделять ответствености с продактом. Как проводить встречи с продактом - на первой встрече знакомстве, на встречах 1-1, на встрече обратной связи.

2) Как работать с беклогом. Что делать аналитику, если пустой беклог или слишком перегруженный или слишком быстро меняем приоритеты. Как в этом случае поможет построение CJM и MVP.

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

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

Инфраструктура - как выглядит у нас и в чем сложность взаимодействия между командами:

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

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

3. Ошибки при взаимодействии. С чем столкнулись и как пришли к чек-листу.

4. Инструмент или панацея? Что изменилось с введением чек-листа, ограничились только им и нужны ли еще какие-то изменения.

5. Выводы и рекомендации, опыт команды.

Продолжительность ~40 минут.

На КС обсудим - что случилось с проектированием в разработке ПО и ИС?

Вопросы на КС:

1. Действительно ли так нужны требования, а не проект системы?

2. Кто и как может делать проект системы?

3. Нужны ли индустрии проектировщики?

4. Где взять проектировщиков?

5. Что нужно знать и делать аналитику, чтобы он смог делать проект системы?

• Прокрастинация…
• А нужна ли задача?
• А вдруг подобное уже реализовали?
• Как собрать воедино этот хаос?
• Как вписать в архитектуру?
• Когда, что и с кем согласовывать?
• А что от меня ждут на выходе?