17 февраля 2018
с 10:00 до 18:30

Точка сборки

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

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

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

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

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

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

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

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

Я 3 года назад приняла для себя непростое решение уйти из профессии аналитика в развитие компании. И за 3 года сделала для себя много выводов, связанных с плюсами и минусами наличия в Департаменте развития бывших производственников.

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

В процесс создания программного продукта — сайта, приложения, корпоративной системы — вовлечено множество специалистов. Это владельцы продуктов, аналитики, эксперты предметной области, проектировщики, дизайнеры, программисты, тестировщики. Все они стремятся сделать продукт как можно лучше, заботятся о пользователях… но, как говорится, «у семи нянек дитя без глазу».

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

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

Рассмотрим основные проблемы, касающиеся того, что бизнесу (в рамках организации) на самом деле может быть нужно и полезно от Data Science в целом и технологий искусственного интеллекта (AI-технологий). Рассмотрим примеры вариаций Data Science в бизнесе: AI in Product, AI for Business Ops, а также AI for Engineering.

Практические советы по тому: на какие метрики можно повлиять непосредственно использованием машинного обучения (ML), кому и как лучше всего стоит его продавать, как сформировать правильные ожидания.

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

В ходе мастер-класса мы обсудим основные критерии качества карты продукта (Lean Product Canvas) и карты ценностного предложения (Value Proposition Canvas), после чего совместно подготовим практические примеры и оценим результаты их выполнения.

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

Посмотрим на работу ИТ-компании глазами СЕО и владельцев бизнеса.

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

Расскажу про общий тренд — к какому ключевому показателю сейчас приходят продуктовые ИТ компании.

На мастер-классе будет много интерактива с ведущим, брейншторма и общения друг с другом. Будьте к этому готовы ;о)

«Зачем что-то менять с видами требования, когда Вигерс уже все придумал и описал?» — думала я четыре года назад, перейдя работать с приложений для клиентов на утилиты для внутреннего использования и сервисы. Но жизнь показала, что не все так просто, и то, что подходит для продуктового проекта, может быть избыточным и/или неудобным для команды высоконагруженного облачного сервиса или утилиты поддержки разработки.

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

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