Название Конференция Описание | Автор |
---|---|
Интерактивный круглый стол "Успешный успех аналитика в ИТ - в чем он?" | |
ЛАФ-2021 [Подробно...][Скрыть] Интерактивный круглый стол с элементами командной игры, с призами и наградами Ведущие Марина Давыдова и Ирина Гертовская Стремление к успеху является неотъемлемой ценностью человеческого общества. Очевидно, что в разных профессия и сферах деятельности это понятие разнится, но есть и общие критерии, такие как заработная плата, признание профессионального сообщества, признание окружения и т.д. В рамках дискуссии мы поговорим с несколькими экспертами, узнаем мнение команд. Попробуем найти ответ на вопрос: "Кто он такой, успешный аналитик и как им стать?" Попытаемся вместе ответить на, по сути, бесконечный вопрос: "Что делает человека Аналитиком?" Свой взгляд на проблему осветят четыре специалиста из разных концов нашей аналитической галактики и сравним их мнение с заключением команд. А в конце объявим конкурс. | Марина Давыдова |
Круглый стол обсуждеие Проектной и Продуктовой Парадигмы | |
ЛАФ-2021 [Подробно...][Скрыть] d докладе сформированы достаточно провокационные тезисы которые хотелось бы обсудить в первый или второй день фестиваля | Dmitry Bezuglyy |
Можно ли научиться читать мысли заказчика | |
ЛАФ-2021 [Подробно...][Скрыть] Дискуссия о том, возможно ли предугадывать "желания заказчика", какие можно пр именять инструменты и как готовится к встрече с заказчиком | Анна Белянина |
Наставничество: тратить ли время и деньги? | |
ЛАФ-2021 [Подробно...][Скрыть] В различных дискуссиях о применении в компании наставничества (менторинга) я часто наблюдаю, что наставничество рассматривается строго, как синоним слова «обучение», вследствие чего считается применимым исключительно к новичкам в компании или профессии. На деле же, наставничество куда более мощный инструмент, который может использоваться для достижения различных целей и решения широкого круга задач – от повышения квалификации персонала (в том числе "точечной"), развития позитивного отношения к работе и лояльности к компании, до сокращения длительности адаптационного периода и экономии времени руководителей. Мне посчастливилось поработать в компаниях с разным подходом к наставничеству, побывать и подопечным, и, собственно, наставником, поэтому с удовольствием поделюсь собственным опытом и взглядами. В ходе доклада поговорим о том: - как может быть выстроена система наставничества; - какие цели и задачи может преследовать; - какую непоправимую пользу наносить; - какие требования могут выдвигаться к наставникам; - как поддерживать дальнейшее развитие сотрудников, прошедших период наставничества. Если вы задаётесь вопросом, нужно ли организовывать систему наставничества в вашей компании - приходите за аргументами в пользу и за практическими советами. Также, доклад будет интересен и новичкам, которые увидят реальные примеры существования подобных программ, как таковых, и смогут в дальнейшем обращать на это внимание при поиске работы. | Валентина Писанова |
Роль аналитика в управлении изменениями | |
ЛАФ-2021 [Подробно...][Скрыть] Как использовать методологию управления изменения при планировании работ по бизнес-анализу и внедрению систем.
Многие компании тратят огромные деньги на приобретения современного ПО, внедрение новых технологий, на столь модные сейчас проекты цифровой трансформации.
Внедрение многих технологий это не только про технологические изменения, но в первую очередь про изменения рабочих привычек и поведения сотрудников. Особенно это касается проектов цифровой трансформации, когда людей пугает непонимание технологических изменений и боязнь замены людей этими технологиями.
По статистики формула успех любого проекта - это 40% про правильные технологии и управление проектов и 60% про изменения сотрудников и их быстрая адаптация к новых решениям.
Про управление проектами известно очень много, а вот тема управления изменениями является относительно новой. Однако известно, что более 80% проектов сталкиваются с сопротивлением сотрудников и именно это является одной из главных причин не соблюдения сроков и выхода за бюджеты.
Управление изменениями - это методология направленная на управление поведением сотрудников для снижения уровня сопротивления и повышения вероятности успеха проекта.
В рамках доклада вы узнаете:
1. почему управление изменения важно
2. Методология PROSCI для управления изменениями 3. Ключевые персоны в управлении изменениями 4. Модель ADKAR в управлении изменениями 5. Основные этапы управления изменениями
Докладчик сертифицированный специалист по управлению изменениями методологии PROSCI.
| Аркадий Золотовицкий |
Почему спустя 30 лет психбольница все еще в руках пациентов и что с этим делать ? (Продуктовая парадигма) | |
ЛАФ-2021 [Подробно...][Скрыть] Слабонервным и начинающим аналитикам просьба не читать дальше …
“Заказчик всегда просит не то что он хочет, Я даже не могу вспомнить когда я первый раз ее услышал, и сколько раз пропускал ее между ушей. И это было тогда когда задача у IT систем по сути была одна, хранение и передача данных. А стоило бы задуматься. В конце 2020 года IIBA выпустило брошюру в которой, просто, открытым текстом написано: “большинство компаний переходят на продуктовую модель разработки”,”давайте посмотрим что из BABOK может вам пригодится”... Это говорит о том, что в тренд исхода с проектной парадигмы на продуктовую охватил позднее большинство. Что особенно удручает, что с точки зрения IIBA полезного нашлось немного. В рамках доклада рассмотрим плюсы и минусы перехода предлагаемого IIBA и здоровую альтернативу “психбольнице”. | Dmitry Bezuglyy |
Проектируем микросервисное приложение на схемах | |
ЛАФ-2021 [Подробно...][Скрыть] Осенью на прошлой Analyst Days я начал рассказывать о модели, которая позволяет эффективно представить современное приложение, состоящее из интегрированного множества сервисов, обменивающихся сообщениями и вызывающими друг друга (https://mtsepkov.org/Multyparadigm-AD). Такая модель соответствует коду и позволяет проектировать изменения при развитии приложения и оценивать их по сложности изменения самой модели. Тема развивалась в нескольких докладах, а этой весной на SQAdays и Analyst Days я провожу мастер-классы с разбором кейсов участников по этой модели. На ЛАФ я совместно с Анной Абрамовой повторю этот мастер класс с учетом полученного опыта. Формат мастер-класса - после краткого рассказа модели участники заявляют свои кейсы, а затем я и участники разбирают наиболее интересные один или два кейса. | Максим Цепков |
Роль аналитика в e-comm на примере Lamoda | |
ЛАФ-2021 [Подробно...][Скрыть] Я - тимлид быстрорастущей группы системных аналитиков в Lamoda. За последний год мы выросли в 3 раза с 3 системных аналитиков до 9. За это время я была на 60+ собеседованиях, в процессе которых я знакомлюсь с разными системными и бизнес аналитиками, а также подходами к системному анализу в разных компаниях.
В рамках своего доклада я хочу поделиться своими мыслями о роли системного аналитика в Lamoda и распространить общие подходы на e-comm в целом. Мой доклад поможет слушателям понять о специфике e-comm и определиться, подходит ли им эта сфера с точки зрения профессионального развития в системном анализе. Также в рамках доклада я расскажу, какие навыки нужны системному аналитику в e-comm и дам советы, как эти навыки развивать. Если после доклада слушатели четко поймут, какие навыки нужны, чтобы быть системным аналитиком в e-comm и как этого достигнуть, то доклад я буду считать удачным. Но я считаю, что эти навыки пригодятся абсолютно каждому системному аналитику. Я работаю в системном анализе 10 лет. 5 лет работала в ЛАНИТ на проектах ЕМИАС, с проектами РСА (единая база ОСАГО, электронный ОСАГО, бюро страховых историй), ЦБ, крупных банков. Вторые 5 лет я работаю в Lamoda. В Lamoda помогала запускать новые сервисы, связанные с различными методами оплаты, рефакторила процесс возврата денежных средств, запускали систему доставки в Казахстане и многое другое. Сейчас занимаюсь развитием нашего отдела и немного проектной деятельностью. В личной жизни обожаю проводить время с дочкой и мужем. Люблю искусство в любом его проявлении и спорт. Опыт спикера: 2 доклада внутри Lamoda (ссылки кидать не могу), 1 доклад в 2020 году на конференциях Knoleadge conf и ЛАФ: https://knowledgeconf.ru/2020/abstracts/6758 https://conf.uml2.ru/index.php?all_classes&class_id=kak-pisat-kachestvennyi-tekst | Александра Камзеева |
Роль и место аналитика в цифровой трансформации предприятий СГ | |
ЛАФ-2021 [Подробно...][Скрыть]
С 2016 года я в роли корпоративного архитектора и методолога занимаюсь цифровой и Agile-трансформацией Альфа-Банка (Беларусь), сотрудничая с коллегами из холдинга ABH Holdings S. A. (АБ Россия, АБ Беларусь, АБ Украина, АБ Казахстан). Параллельно этому, мы с коллегой из РФ (экс - Youta, ныне - стартап Humans) ведём научную работу по теме цифровой трансформации предприятий Союзного государства (СГ).
Хочу поделиться с участниками Фестиваля нашим текущим пониманием темы цифровой трансформации (что это такое и зачем она нужна предприятиям СГ), а также конкретными наработками по роли и месту аналитика в процессе её реализации:
- роль аналитика в микросервисной трансформации;
- роль аналитика в продуктовых скрам-командах;
- роль аналитика в BDD-процессе;
- роль аналитика в экосистеме производственных цифровых сервисов.
| Вадим Мустяца |
Садо-эстафета 3 часа | |
ЛАФ-2021 [Подробно...][Скрыть]
В 2017 году Перчинки и Ко (сборная), Восточный экспресс (Иваново), (Нижний Новгород) успешно справились с помощью заказчику: заказчик был удовлетворён представленными решениями, а некоторые возжелал увидеть и получить немедля! Подробности по ссылке: https://www.facebook.com/groups/let.an.fest/permalink/1721066081254337/
В этом году С.А.Д.О. эстафета возвращается. В рамках игры участники будут:
Для кого: для аналитиков любого уровня.
Формат игры: С.А.Д.О. эстафета - это командная игра. В одной команде 4 человека. Можно взять с собой пятого - он всё запишет и сохранит для истории, но игровые задания выполнять не будет. Игра состоит из частей:
Будет организована запись на эстафету. Количество мест ограничено. Для участия вы можете собрать команду заранее или объединиться перед стартом. | Ирина Векленко |
Сказ о том как документацию лечили да автоматизировали | |
ЛАФ-2021 [Подробно...][Скрыть] Жил был продукт для больших компаний. С хорошей документацией, которую команда вела в конфлюенс. Продукт рос, документация пухла, но оставалась хорошей. Число заказчиков тоже увеличивалось, а под каждого заказчика появлялось новое пространство с описанием продукта — с одной стороны, унаследованном от общей документации, а с другой — описывающее специфичные для заказчика доработки и настройки. В какой-то момент выросшая документация выросла настолько, что вышла из-под родительского контроля команды:
Но команда не растерялась и отправила документацию на лечение. О проведенном процессе исцелении я и расскажу в докладе:
| Павел Абдюшев |
Собрать хронометр времени. Встреча клуба анонимных трудоголиков | |
ЛАФ-2021 [Подробно...][Скрыть]
Аналитическая мастерская с щепоткой рефлексии — 1.5 часа Аннотация Вы знаете наизусть все Джедайские техники, с точностью до минуты определяете оставшееся время на поммодоро-таймере, списки и чек-листы подготовлены на все случаи жизни... но что-то идет не так, и времени в сутках все еще не хватает, списки дел пухнут и пухнут? Двери нашего клуба открыты для вас. Вы не знаете ни одной техники тайм-менеджмента, но лавина дел накрывает с головой, а вокруг все такие эффективные и супер-деятельные….и вам добро пожаловать в наш клуб!
Мы вместе попробуем найти причины нехватки времени. А может вы поймете, что вы уже все успеваете? Разберем различные техники тайм-менеджмента и выясним, когда они не работают, а когда приносят результат. Спойлер — на утюге можно жарить яичницу, но предназначен он для глажки белья) Так и с техниками. Пример, не надо ждать от блока помодорро результатов для творческих и исследовательских задач, потому что нельзя сказать мозгу «вот тебе 3 раза по 25 минут, быстренько выдай гениальную идею, а то мне пора переходить к следующей задаче».
Что вас ждет:
Предварительная подготовка. Эти материалы только для вас. Мне или всем их показывать не надо. Но они помогут понять вам, где и что пошло не так:
| Бунто Татьяна |
Создание системы публичного API с ограниченным внешним доступом | |
ЛАФ-2021 [Подробно...][Скрыть] Мой доклад о моем опыте создания интересного интеграционного решения, в котором я участвовала на протяжении последних полутора лет в качестве аналитика. Я расскажу, какие именно подходы мы применяли, и, почему решили создать API, зачем наше API пользователям, и какие преимущества оно им дает. А также, об особенностях работы и возможных трудностях аналитика при участии в таком интеграционном проекте. | Светлана Астанина |
Планирование трудозатрат в условиях неизвестности | |
ЛАФ-2021 [Подробно...][Скрыть]
Проблематика оценки трудозатрат и планирования работ в рамках проектирования и реализации ИС. Как получить максимально точную оценку предстоящих работ и определить необходимый состав команды проекта. Для решения данной проблемы, мы разработали методику предварительного расчета трудозатрат и реализовали ее в инструменте в таблицах ексель. Методика опирается на декомпозицию процессов на единичные информационные объекты и определение списка основных работ, выполняемых при проектировании и реализации данных информационных объектов.
В докладе будет детально рассказано:
- что такое информационный объект и основные подходы по их выявлению
- основные работы по реализации информационных объектов и регламентация описания постановок для реализации
- сбор статистической информации в разрезе работ для определения трудозатрат
- разработка и реализация инструмента по расчету трудозатрат
| Метелева Ирина |
Тестовый мастер-класс | |
ЛАФ-2021 [Подробно...][Скрыть] Тестовый мастер-класс | Гриша - проверка |
Требования к обслуживанию больших данных: опыт первых 2300 лет эксплуатации | |
ЛАФ-2021 [Подробно...][Скрыть] Существует пять универсальных требований, применимых к любым информационным системам, работающим с большими данными. За 20 минут посмотрим, что это за требования, почему они не важны пока данные «маленькие», но стремительно поднимаются в приоритете с переходом к парадигме Big Data. Аналитики, осваивающие работу с Big Data, смогут добавить их в свой чек-лист для проверки полноты требований. А опытным специалистам, работающим с большими массивами данных не первый год, будет любопытно узнать, что бета-версия этого набора требований была сформулирована еще в Древнем Риме. | Дмитрий Волгин |
Практика работы с требованиями для сложного сервиса | |
ЛАФ-2021 [Подробно...][Скрыть] Мастер-класс на 4 часа, основанный на однодневном тренинговом модуле, который мы с коллегами второй год ведём для студентов Высшей Школы Экономики. Тренинг в свою очередь основан на нашем опыте работы со сложными системами, где каждое требование к продукту влечет согласованную работу нескольких команд. Что такое АГИЛ - это Agile, когда есть нюанс (как в анекдоте), а то и несколько. То есть, когда итерации короткие, требования изменчивые, команды самоорганизованы в бандитские шайки из-за тупого и ленивого менеджмента, а вот всё остальное - как придётся. Всё то же самое применимо и в Agile, но там обчно есть Agile Coach, который обязательно внедрит SAFe, LeSS и много других страшных слов. Вся теория к мастер-классу и полное описание проблематики находится в докладе "Требования в АГИЛ для сложного сервиса (теория) - можно посмотреть описание доклада отдельно. На мастер-классе я хочу показать вариант целостного процесса превращения творческих идей по сервису в конечные тикеты на каждого разработчика. Сам процесс включает в себя практики, с которыми полезно познакомиться любому аналитику: - Отображение продуктовых требований с помощью бизнес-канваса и связанных с ним инструментов - Поиск точек изменения с помощью карты и эскиза процессов - Двумерный мапинг историй для выявления требований - Применение карт влияния (Impact mapping) совместно с двумерным мапингом или без него - Изображение системного ландшафта и архитектуры в стиле 4Context - Сценарии или диаграммы взаимодействия - И снова карты влияния для раздачи задач системам, командам и отдельным исполнителям - Согласованная нарезка бэклогов команд на итерации и осознанное - с учётом архитектуры - расщепление историй для максимально раннего получения бизнес-ценности - Реверс процесса - что мы получим, если (не) сделаем эти задачи Максимальное число работающих руками - 2 команды по 6 человек. Остальные могут быть зрителями и присоединиться к обсуждению. | Сергей Нужненко |
Требования в АГИЛ для сложного сервиса (теория) | |
ЛАФ-2021 [Подробно...][Скрыть] Что такое АГИЛ - это Agile, когда есть нюанс (как в анекдоте), а то и несколько. То есть, когда итерации короткие, требования изменчивые, команды самоорганизованы в бандитские шайки из-за тупого и ленивого менеджмента, а вот всё остальное - как придётся. Всё то же самое применимо и в Agile, но там есть Agile Coach, который обязательно внедрит SAFe, LeSS и много других страшных слов. В чём проблема - она во всём. Если работу быстро развивающегося сервиса поддерживают две и более команды разработки, то ни одной из них не подойдут ни продуктовые требования, ни бизнес-требования, ни требования к сумме ИТ-систем. Очень часто им не подойдут даже требования к их отдельной системе, выделенной из окружения. Так как тим-лидов и менеджеров проекта ломает писать по 50 тикетов в неделю и заниматься координацией между всеми, кого нужно координировать. Итог печален. После некоторого периода неразберихи на два-четыре квартала причиной провала называют плохие требования. Если в этот момент в компании нет аналитика, его нанимают, и цикл повторяется с тем же итогом. А если аналитик ещё и подходит с классическими процессами, срисованными из заказной разработки, то получается ещё хуже. Кроме этих проблем есть и такие явления, как поиск, что мы сможем быстро сделать, где на основе оценок от разработки возникает бесконечный дрейф продуктовых требований. Следом ползет архитектура и постановки задачи. В такой ситуации система требований в жестком шаблоне рассыпается карточным домиком. Бывает обратная задача: монетизация имеющихся технических возможностей у системы, которая развивается под действием технологической, а не продуктовой стратегии. В этом случае классические подходы часто заканчиваются фатальным конфликтом между аналитиком и командой. Понимание качественных требований при переходе из длинных итерациий в короткие меняется. Полнота и непротиворечивость теряют свои позиции, зато становятся важны нужность, эффективность и прослеживаемость. Уходят задачи заложить верный бюджет и сроки, а потом доказать заказчику, что всё сделано. Возникает задача удержать в балансе это "ведро с гайками", чтобы система собралась в единое целое и заработала уже в этой итерации, принося пользу. А еще важно уберечь команды от лишних действий (но главное - лишнего кода), не работающих на итоговую цель. В докладе я раскрою описанные проблемы. Обсудим, куда смотреть, чтобы понять, что они есть, и расскажу свои предложения, как с ними бороться. Мы увидим, что неизбежно придется влезть на все уровни от продуктовых требований до архитектуры и постановок задач программистам, иначе не работает. Придется договариваться о разделении полномочий и заглядывать с фонарём туда, куда не все хотят смотреть. Обсудим, как поделить с остальной командой зоны ответственности: где мы ставим на учёт принятые решения, где фасилитируем, где проектируем сами, а где выполняем координацию. Из этого обсуждения так же вытекает вариант ответа, куда развиваться аналитику и как ему жить в Agile и приравненных к нему ситуациях. Я покажу быстрые, грязные и дешевые инструменты визуализации, выявления и анализа требований для таких ситуаций. Среди них: - Бизнес канвас - Карты и эскизы процессов - Двумерный мапинг историй - Карты влияния (Impact mapping) - Изображение системного ландшафта и архитектуры в стиле 4Context - CQRS и другие паттерны, дополняющие и заменяющие CRUD+ - Сценарии или диаграммы взаимодействия для систем и компонентов К докладу есть мастер класс "Практика работы с требованиями для сложного сервиса", где желающие смогут увидеть или даже попробовать вариант быстрого процесса работы от продуктовых требований до бэклогов спринта в действии. | Сергей Нужненко |
Управление требованиями в Agile-парадигме: мифы, реальность и преспективы | |
ЛАФ-2021 [Подробно...][Скрыть] На своем опыте построения и запуска команд разработки я расскажу об основных заблуждениях, связанных с аналитикой и проработкой требований в гибких подходах. Расскажу о проблемах встраивания аналитики в agile-команду (ограничиваясь фреймворком Scrum) и о возможных способах решения этих проблем. Тезисно история выглядит следующим образом: 1. Работающий продукт важнее... (Откуда взялся миф о том, что в аджайле нет аналитики и аналитиков, и что с этим мифом делать) 2. Здесь вас не стояло... (Роль и место аналитика в командной работе. Как не построить водопад внутри гибкой разработки) 3. Проработка как риск-менеджмент... (Работа с требованиями в парадигме потока создания ценности. Взаимосвязь между глубиной проработки и толерантностью к рискам). 4. Все только начинается... (аналитика зависимостей, связь проработки требований с архитектурой решений и еще несколько областей где рассказанная история имеет ограниченное применение и не отвечает в полной мере на все вопросы) | Павел Капусткин |
Управление временем. Как получить место под солнцем без кровавой грызни. | |
ЛАФ-2021 [Подробно...][Скрыть]
Аналитик - центральный игрок ИТ-проекта. Он может, как ускорить проект так и замедлить его. Все дёргают его по разным вопросам, но при этом хотят чтобы он делал свою работу хорошо. А он такой один. Он не может делать свою работу хорошо и при этом отвечать на все вопросы. Попытки привести свой распорядок дня в норму ни к чему не приводят. Такой график превращает работу в ад и нужно с боем выгрызать себе спокойный режим работы.
В докладе расскажу о способах получения места под солнцем без кровавой грызни.
Те, кто был на моем докладе на ЛАФ в 2019 году, найдут практические инструменты управления своим временем.
| Алексей Васильев |
Узнать неизвестное или как восстанавливать требования для мобильных приложений | |
ЛАФ-2021 [Подробно...][Скрыть] Язык подачи доклада: Русский Тип презентации: Секционный доклад (40 мин) Уровень аудитории: Начинающий Тема: Узнать неизвестное или как восстанавливать требования для мобильных приложений Аннотация Я - аналитик, который работает в компании, занимающейся заказной разработкой мобильных приложений. На проекте, котором я работаю, при старте не было никакой документации по приложению, и все требования приходилось восстанавливать практически с нуля. В своём докладе я расскажу, как мы восстанавливали требования и какой результат у нас на текущий момент. Также расскажу про некоторые лайфхаки при восстановлении требований, которыми мы пользовались. Доклад будет интересен аналитикам и проджектам, которые хотят работать в сфере разработки мобильных приложений на заказ, также будет интересен аналитикам из других сфер. План доклада:
| Алексей Глазунов |
Я не умею пилотировать вертолет или как успешно использовать ГОСТ-ы в работе | |
ЛАФ-2021 [Подробно...][Скрыть] В докладе будет обзор использования ГОСТ-ов 2.105, 34.603, 34.602. Многие считают ГОСТ-ы полной ерундой. Пусть считают. Я вот не умею пилотировать вертолет. Значит я должен считать, что они не могут летать? Что это полная ерунда? Но они летают. Это очень неожиданно. А ничего, что пилотированию надо учить? И без этого они не летают. А еще их надо заправлять топливом. Внезапно, без этого они тоже не летают. С ГОСТ-ами ровно тоже самое. Это великолепные инструменты. Просто их использованию надо учить. И тогда они позволят вам "летать". Например, они позволяют резко повысить точность расчета продолжительности проекта, точность расчета бюджета проекта. Допустить меньше переделок после выхода в эксплуатацию, уменьшить стресс и переработки проектной команды. И, наконец, уменьшить число мата со стороны заказчика. Сказка? Вовсе нет. Просто кроме UML, BPML, ER и прочего аналитик должен еще знать и владеть правилами оформления текста и создания структуры аналитической документации. Это резко снижает риск что нибудь пропусть. Кто-то спросит, а какже юзерстори? Коллеги, юзерстори это про ПО. А ГОСТ-ы это про системы. Совершенно другой зверь. Это как болонка рядом с кавказкой овчаркой. И никто вам не мешает использовать юзерстори как один из разделов ТЗ по 34.602. А 2.105 резко снижает вариации в большом коллективе. "Все дело в уменьшении вариаций" говорил великий Деминг. Для кого доклад. В первую очередь для аналитиков, технических писателей, процессных менеджеров и руководителей проектов. | Сергей Мартыненко |
Как (не) сделать фичу без фичи. Непридуманная история | |
ЛАФ-2020 [Подробно...][Скрыть] В 2019 году мы выпустили большую критическую фичу для бизнеса... без самой фичи. Интересно? На докладе расскажу - что произошло, - как мы до этого докатились - и самое важное - какие уроки из этого извлекли. Будет полезно владельцам продукта, менеджерам проектов, аналитикам. | Олег Нестёркин |
Идеальный бэклог для Scrum-команды | |
ЛАФ-2020 [Подробно...][Скрыть] Как должен выглядеть идеальный бэклог в scrum? Мы рассмотрим эволюцию работы с бэклогом от неупорядоченного списка задач к системной работе с гипотезами и участию команды в процессах приоритезации. Разберёмся, на каком уровне стоит остановиться, в зависимости от размера команды, уровня профессиональных навыков её участников и степени их вовлеченности. | Дмитрий Туфанов |
От хаоса к порядку: как создать шаблон описания сервисов и к нему перейти | |
ЛАФ-2020 [Подробно...][Скрыть] Из доклада вы узнаете, как неструктурированное описание системы может усложнить жизнь командам разработки в части: ● аналитики и разработки проекта; ● знакомства новичков, других команд с системой. А также о том, как шаблон может помочь решить эти проблемы и каким он должен быть. На реальных примерах наших систем рассмотрим его применение. | Александра Камзеева |
Дырка от бублика как системный интерфейс (про ошибки в понимании интерфейса как концепта) | |
ЛАФ-2020 [Подробно...][Скрыть]
В чем аналитики, разработчики, тимлиды и руководители проектов выиграют, если станут думать об интерфейсах как системные инженеры? | Александр Турханов |
Аналитик в компании пост-стартапного периода | |
ЛАФ-2020 [Подробно...][Скрыть] Это история о внедрении системного и бизнес анализа в молодой компании, где раньше никто не работал с аналитиками. Я расскажу о боли и страданиях, которые ждали нас на пути к светлому будущему, проблемах и задачах, которые мы решали. ● Как определить место аналитика в пищевой цепочке agile-процессов? ● Как найти оптимальный формат и степень детализации требований? ● Как разработать полноценную документацию к системе или продукту, живя в agile-вселенной? | Андрей Бураков |
Краткий обзор существующих систем управления процессами: многострадальные BPM | |
ЛАФ-2020 [Подробно...][Скрыть] Так бывает, что потратив время на сравнение BPM-систем, чтобы найти подходящую для себя, мы испытываем разочарование, когда начинаем ее использовать: BPM-система не соответствует ожиданиям, не подходит для Вашего использования или получается дорого. Поэтому в выступлении я хочу затронуть вопросы, на которые стоит обратить внимание при принятии решения о внедрении у себя BPM-системы. А тем, кто только начинает поиск своей идеальной BPM-системы, я приведу список популярных BPM-систем и их краткое сравнение по основным параметрам. | Tory Piliptsevich |
Найти и обезвредить: работа аналитика с рисками и риски в работе аналитика | |
ЛАФ-2020 [Подробно...][Скрыть] Поговорим о рисках: проектных, межпроектных, иных: что говорит теория и что на практике. На практических примерах покажу как аналитику выявлять риски и что с ними делать. | Ирина Гертовская |
Доктор на работе. Что делают полмиллиона врачей во время эпидемии коронавируса | |
ЛАФ-2020 [Подробно...][Скрыть] Я расскажу вам о плюсах коронавируса. А именно — о том, какие проекты появились в нашей компании благодаря эпидемии. "Доктор на работе" — это интернет-платформа для врачей. Как вы знаете, три последних месяца медики активно спасали жизни пациентов от ковида. Мы, как IT-компания, помогали врачам информационно: предоставляли свежие данные и регламенты лечения, связывали с волонтёрами и даже создали мемориальный проект в память погибших медработников. Сориентироваться в быстро меняющейся обстановке и сделать верный прогноз было непросто, это стало одной из ключевых сложностей. О том, как мы решали проблемы, и подробнее о проектах с точки зрения аналитики я расскажу вам в докладе. | Мария Савонина |