Название Конференция Описание | Автор |
---|---|
Роли бизнес и системного аналитика в создании продукта | |
ЛАФ-2015 [Подробно...][Скрыть] | Dmitry Bezuglyy |
Детали реализации в требованиях | |
ЛАФ-2014 [Подробно...][Скрыть] Описание деталей реализации в требованиях вызывает отторжение у аналитиков, в то время как тестировщики и разработчики часто хотят видеть в требованиях не только «что» нужно сделать, но и «как». Если таких столкновений много, значит пора уделить внимание процессам управления требованиями и разработки. В докладе будет предложено несколько способов разрешения этих противоречий. Совсем избавиться от деталей реализации в требованиях в большинстве случаев не удастся, но можно свести их к необходимому минимуму. | Анна Сергеевна Абрамова |
Дисциплины(перспективы) бизнес-анализа и корпоративная архитектура | |
ЛАФ-2014 [Подробно...][Скрыть] С 12 мая 2014 года международный институт бизнес-анализа IIBA проводит публичное обсуждение следующей версии свода знаний по бизнес-анализу BABOK Guide v3. Одним из отличий этой версии от предыдущих является появления раздела «Perspectives», обсуждающего использование общих практик и методик анализа для частных дисциплин, востребованных в той или иной области деятельности организации. В текущей редакции документа список перспектив включает:
Тем самым дисциплина бизнес-анализа выходит за пределы практики управления требованиями в рамках ИТ-проекта и становится полноценнвм инструментом управления изменениями в организации. Похожая трансформация в свое время произошла с ИТ архитектурой, выросшей из практики проектирования ИТ-решений в инструмент управления продуктами, процессами, структурой и стратегией организации. Дискуссионный стол будет посвящен обсуждению перечисленных выше перспектив. | Максим Смирнов |
Дьявольский аккорд. Карьера как по нотам | |
ЛАФ-2014 [Подробно...][Скрыть] Регулярно наблюдаем следующую картину: приходит человек устраиваться на работу. Ты его спрашиваешь - ну хорошо, хочешь быть аналитиком. А что дальше? Что после того, как станешь крутым аналитиком? Ответ стандартный: дорастем - увидим. Развиваясь и не задумываясь о том, к чему стремиться, специалист попадает в ловушку. Да, он становится сильным специалистом, способным решать достаточно сложные задачи. А с другой стороны ставшие привычными задачи выполнять уже не интересно и человек достигает некоторой точки принятия решения о том, что пора бы что-то изменить в своей жизни, сместить вектор профессионального развития. Но ему тяжело это сделать, поскольку в эту точку он пришел без того задела, который позволил бы быстро скорректировать профессиональные интересы (поскольку он изначально не задумывался о том, что этот вектор будет меняться и что к этому надо готовиться). Что в итоге имеем? Непонимание перспектив, неудовлетворенность и депрессию. Избежать всей этой ситуации не так и сложно. Для этого на каждом шаге профессионального роста необходио понимать, какие навыки и зачем необходимо развивать и какой эффект благодаря этому должен быть достигнут. А еще нужно уметь оценивать свои возможности и исходя из этого принимать решение о последующих шагах развития. В своем докладе мы покажем варианты профессионального развития бизнес-аналитика, выделим ключевые экспертизы, определяющие развитие, обозначим точки принятия решения, в которых аналитик доллжен быть способным оценить свой реальный уровень и исходя из этого принять решение о дальнейшем развитии. Мы попытаемся дать вам советы, на основе которых вы сможете строить свою карьеру предельно самостоятельно. | Sergey Kalinov |
Использование TFS для оздоровления требований | |
ЛАФ-2014 [Подробно...][Скрыть]
В проектах, получающих большое количество запросов от разных заказчиков, бывает сложно понять, какие из запросов были отражены в требованиях а какие были сразу реализованы в коде без дополнительных обсуждений. В результате требования перестают быть актуальными, а аналитик не видит картину на проекте в целом и начинает чаще привлекаться к "тушению пожаров", чем к разработке требований.
В докладе будет рассмотрено, как можно использовать MS TFS для задач «оздоровления» требований – приведения их в соответствие с реализацией.
Будет рассказано о:
| Никита Казаков |
Как превратить меняющиеся требования клиента в надежный результат для бизнеса | |
ЛАФ-2014 [Подробно...][Скрыть] Компьютер и программное обеспечение – лишь средство автоматизации информационного обмена. Они могут существенно ускорить и упростить его там, где он есть. Но технические средства не могут создавать информационного обмена.
В рамках круглого стола будет представлена методика, которую участники смогут опробовать на нескольких примерах. | Алексей Залезский |
Когнитивные искажения мешающие аналитику | |
ЛАФ-2014 [Подробно...][Скрыть] Наш мозг имеет определенные особенности. Сами того не осознавая мы воспринимаем мир не таким, каков он есть. Вот например, одно из изображений воспринимаемых неправильно:
Часть беых точек мы не воспринимаем. Глаза видят, но постобработка мозга дает нам неверную картину. Это один из вариантов "ложной слепоты". Кроме "ложной слепоты" существует множество других особенностей мозга, препятствующих объективному восприятию мира. Для того, чтобы воспринимать мир более объективно требуется во первых знать об особенностях нашего мышления, во вторых знать приемы нивелирования искажений. | Сергей Мартыненко |
Модель требований в корпорации | |
ЛАФ-2014 [Подробно...][Скрыть] Большие компании и корпорации имеют сложную Орг структуру, множество Бизнес-процессов (БП), Систем, Данных. Все это очень тесно переплетно и сильно влияет друг на друга. Изменили структуру отдела или заменили людей, забыли про БП - получили проблему. Изменили Систему, забыли про другую Систему - получили проблему. Поменяли БП, забыли про людей и Системы - получили проблему. И т.д.... Чтобы все это увязать и управлять придумано много фреймворков - Zachman, TOGAF, FEA и т.д. И везде требования ставятся во главу угла. Но нужны ли все практики и такие сложные фреймвоки? В каких российских компаниях они внедрены? Мне кажется, что можно взять из этих фреймворков все самое лучше и необходимо и построить свой подход по управлению корпоративной архитектурой. В докладе будет представлены основные проблемы связанные с изменениями в больших компаниях, подход по управлению требованиями и изменениями в них. | Александр Байкин |
О чем врут вакансии, и что я жду от аналитика как руководитель проекта. | |
ЛАФ-2014 [Подробно...][Скрыть] Вакансии врут. Компании ищут аналитиков с навыками, которые им потом не требуются. Аналитики продают компаниям опыт, который потом не пригодится в проектах. Кто кого обманывает понять уже невозможно.
В рамках доклада я расскажу какие из навыков и знаний аналитиков оказались самыми важными на моих проектах и какую непоправимую пользу они наносили, а что оказалось бесполезным хламом. Разберемся, почему иногда руководители проектов и аналитики могут не понимать, что именно эти скиллы важны, почему не задействуют их в проектах, почему при формировании команды отбирают аналитиков по совершенно другим критериям. | Иван Потапов |
Опыт создания сообщества аналитиков в отдельно взятой компании | |
ЛАФ-2014 [Подробно...][Скрыть] Каждая активно развивающаяся компания переживает момент, когда сотрудники перестают узнавать друг друга в лицо. Мы такой момент пережили не просто в своей компании, но и в отделе аналитики, когда его численность перевалила за 30 сотрудников, а количество офисов, в которых эти сотрудники работали, существенно увеличилось.
Увеличилось и количество проблем в коммуникациях между аналитиками:
В результате анализа возникших проблем было принято решение о создании сообщества аналитиков внутри компании.
В своем докладе я хочу рассказать об опыте создания такого сообщества, включая:
| Юлия Ерина |
Практика управления требованиями совместно с заказчиком | |
ЛАФ-2014 [Подробно...][Скрыть] В проектах по разработке и внедрению управленческого программного обеспечения с точки зрения работы с требованиями есть два ключевых вопроса:
Есть способ решить эти вопросы методично и с низкой себестоимостью – с помощью специализированной проектной коммуникационной системы. | Алексей Залезский |
RUP or Agile. Выбор подхода в IT проекте | |
ЛАФ-2014 [Подробно...][Скрыть] Аналитический мир огромен и неоднороден. Нас разделяют расстояния, разница во времени, в культуре, языковый барьер. Но, ничто не разделяет нас так, как приверженность к различным подходам. Главный водораздел проходит между двумя, порой, непримиримыми лагерями: приверженцами классического подхода и приверженцами идеологии Agile. Кто же из них прав? Под чьи знамена встать, что бы не ошибиться в жизненном выборе? А нужно ли вообще выбирать? Данный доклад - это результат долгого спора с поклонниками и оппонентами этих двух полярных подходов. В докладе будет рассказано, что существуют вполне понятные и формализованные признаки проекта, анализ которых и позволит нам выбрать наилучший подход для каждого отдельного проекта. | Александр Белин |
Системный подход: Модель Предметной области, модель Бизнес-системы и модель Информационной системы – строим вместе | |
ЛАФ-2014 [Подробно...][Скрыть] мастер класс Кумсков ЛАФ-2014 Системный подход: Модель Предметной области, модель Бизнес-системы и модель Информационной системы – строим вместе.
На мастер классе будет разобрана три примера (за 90 минут) - один пример показывается по шагам на слайдах. Строятся три модели: модель ИС (прототип модели сценариев использования), модель бизнеса (прототип модели бизнес сценариев использования) и модель предметной области. Второй и третьи примеры слушатели строят в группах по 3-5 человек и публикуют на листах флип-чарта (развешанных на стенке), затем проводится «разбор полета». Мастер класс показывает внутреннюю взаимосвязи и синергию трех представлений задачи – трех моделей. | Кумсков Михаил |
Создание программного обеспечения. Взгляд со стороны разработки | |
ЛАФ-2014 [Подробно...][Скрыть] При создании программного обеспечения нередко возникает непонимание между различными группами заинтересованных лиц (заказчиками, аналитиками, разработчиками и другими). Это неизбежно вызывает расхождение между пожеланиями заказчика и готовым продуктом. Особенно много недоразумений обычно связано с реализацией, т.к. для участников проекта, не являющихся программистами, код представляет собой ‘чёрный ящик’ и почти не поддаётся контролю. Что системному аналитику делать с чёрным ящиком? В докладе рассматриваются некоторые приёмы, способствующие организации эффективного взаимодействия с разработчиками. | Марина Липатова |
Тренды в бизнес и системном анализе. От Specification к Requirements Engineering | |
ЛАФ-2014 [Подробно...][Скрыть]
С одной стороны область связанная с работой с требованиями постепенно институализируется и область становится все более и более консервативной. И практика и стандарты становятся более зрелыми. С другой стороны мир и индустрия разаротки ПО не стоит на месте. Даже гибкие методологии, не так давно казавшиеся пределом мечтаний, похоже перевалили пик своей популярности. Наступает очередная смена парадигмы в роли ИТ и Requirements Engineering в частности.
В докладе будут рассмотрены
- Значимые события и тренды в смежных дисциплинах
- Ключевые вызовы стоящие перед дисциплиной и аналитиками в частности
- Уже наметившиеся тренды и возможные изменения в процессах и методологии работы с требованиями
| Dmitry Bezuglyy |
Управление изменениями требований | |
ЛАФ-2014 [Подробно...][Скрыть] Нет предела совершенству! И как только более-менее стабилизируется процесс разработки требований, начинаются вопросы - а что же делать, если требования меняются? Такой вопрос возникал и у меня на разных проектах. В ходе размышлений и опытов родился некоторый подход, которым хотелось бы поделиться и развить с учетом мнения коллег в ходе этого доклада. Вопросы: 1) постановка задачи: какие же проблемы мы хотим решить? 2) варианты реализации управления изменениями: в рамках одной версии, в рамках нескольких версий 3) цикл жизни артефактов проекта - а за всеми ли изменениями нужно следить? В целом доклад базируется на моем вебинаре https://www.webursitet.ru/article/versionirovanie-trebovanii--zapis-vebinara.html , поэтому буду рада вопросам, которые покажут, в какую сторону надо развить тему. | Ирина Сурова |
UX-дизайнер? Подвинься, детка, тут поляна бизнес-аналитика | |
ЛАФ-2014 [Подробно...][Скрыть] Постановка задачи
Ну вот кто с этим не знаком? Нужно там, ну не знаю, сервис на мобилу подключить. Лезешь на портал, а там просят указать «Ваш звонок очень важен для нас, оператор освободится через 10 минут, очередь — 20 входящих», «Ой, у нас нет вашего письма», «Нет, ну вы нам не писали, нет заявки», «Я не могу Вам ответить, сейчас соединю со специалистом»,
«Кто, я в этом специалист? чо они там несут??? звоните им снова и пусть Вас пошлют
И вот если отбросить уголовно наказуемые желания по отношению к тем, кто все это придумал, остается одно: глядя этим людям в глаза спросить — ну как так вышло, что вышло ну никак?
Уверены, что это не со зла. И задумка то была благородная, и на бумаге все срасталось. Но почему в
Не, ну вы конечно скажете — тут UX нужен. А факт ли? Положим, есть инструменты, позволяющие спроектировать удобную для клиента услугу. Один из наиболее эффективных — это Customer Journey Map (CJM).
Что будетЦелью воркшопа является ознакомление слушателей с теоретическими основами CJM и получение практических навыков ее разработки.
В теоретической части будет раскрыта общая идея CJM, показаны подходы к ее разработке, даны рекомендации по формату представления CJM. Кроме того, будет уделено внимание зависимостям между В практической части участникам воркшопа будут предложены задания по проектированию новых сервисов или оптимизации существующих. Результаты выполнения практических заданий будут вынесены на коллективное обсуждение. ЗаключениеВ результате участия в воркшопе участники получат в свою копилку ещё один инструмент, который поможет более системно подходить к локальным улучшениям и видеть не только разрабатываемое ПО, но и услугу (а то и весь бизнес) вокруг этого ПО. | Sergey Kalinov |
Верните аналитика в бизнес! | |
ЛАФ-2014 [Подробно...][Скрыть] | Максим Смирнов |
Верю — не верю | |
ЛАФ-2014 [Подробно...][Скрыть] 1. Все лгут 2. Где брать информацию? 3. Чему доверять? 4. Что делать с недостоверными данными? 5. Когда нужно, чтобы информация достоверной? | Евгений Гаврилов |
Вовлечение заказчика в работу с требованиями. Как и зачем? | |
ЛАФ-2014 [Подробно...][Скрыть] Основные тезисы доклада:
| Ольга Самарина |
Здесь танцуют, и всё будет хорошо | |
ЛАФ-2014 [Подробно...][Скрыть]
Что движет вами, когда вы начинаете работу над очередным проектом? Чего вы ожидаете от своей деятельности и почему посвящаете ей так много времени и внимания? Это элементарное желание заработать, жажда славы и успеха, которые так любят приписывать другим цинники и пессимисты, или всё-таки нечто иное, лежащее вне рамок капиталистических ценностей?
Альберт Эйнтштейн говорил, что истинная ценность человека определяется тем, насколько он освободился от эгоизма и какими средствами он этого добился. Поскольку аналитик является частным случаем человека, думаю, вы не станете спорить, что это определение абсолютно применимо и к нам с вами +)
Чтобы подробно проиллюстрировать данную мысль, я покажу новую обобщающую метафору с участием полюбившегося многим Человека-батарейки. О том, против чего сражаются инженеры, и что движет лично мной в ежедневной деятельности. То, что я называю Altruism Driven Development: ADD [VALUE].
| Вадим Мустяца |
Треугольник управления требованиями: люди, процессы, инструменты | |
ЛАФ-2013 [Подробно...][Скрыть] Многие начинающие аналитики и менеджеры делают огромную ошибку, возлагая большие надежды на инструменты управления требованиями и проектом. На самом деле нужно сначачала найти (сделать) хороших людей, потом наладить процессы, а далее уже искать способы автоматизации рутинных операций (инструменты). В докладе я покажу и расскажу:
| Александр Байкин |
К вопросу об обучении пользователей и формированию пользовательской документации | |
ЛАФ-2013 [Подробно...][Скрыть] Если вы делаете продукт, сложный и динамически развиваемый и при этом достаточно узкоспециализированный, то вам вряд ли удасться отдать вопрос обучение и документирование системы на аутсорсинг. Скорее всего вы сами будете обучать пользователей тем или иным способом. Способы могут быть разные. Один отсылает пользователей к техническим инструкциям или справке и предполагает ответы на вопросы по мере их возникновения. Другой может быть ориентирован на построение неформального сообщества пользователей этого продукта, которые обмениваются опытом и знаниями. Третий опирается на системном подходе и предполагает выстраивание целостной системы обучения. Мой доклад посвящен третьей позиции. Я хочу поделится своими соображениями и шишками, которые я набил, выстраивая учебный центр в нашей компании. Особое внимание хочу уделить практическим соображениям. Обзору (краткому) продуктов, в частности Viewlet Builder и moodle, как средствам или среде построения образовательного контента и образовательной системы, центрилизирущей процесс цивилизованного общения с пользователями клиентов. Опыт небольшой, потому одна из задач получить добрую обратную связь. | Эдуард Галиаскаров |
Опыт использования объектно ориентированного подхода в бизнес анализе, или говорим с разработчиками на одном языке | |
ЛАФ-2013 [Подробно...][Скрыть] Позиция бизнес аналитика (БА) в проекте - это позиция особая. БА - это представитель заказчика в проектной команде и представитель технической команды в глазах заказчика. Мы знаем, что научиться говорить на языке бизнеса - это одна из главных задач БА. Но, при этом мы зачастую забываем, что БА, это еще и технический специалист, это IT специалист. В то время, когда весь IT-шный мир, т.е. разработчики, специалисты по контролю качества (QA, тестировщики), свободно "говорят" на языке UML и используют объектно -ориентированнный подход, аналитики имеют достаточно слабое представление в этих областях. Как результат: собственно процесс бизнес-анализа проводится спонтанно и непоследовательно, достаточно большие области знаний о бизнесе остаются "за бортом" внимания аналитика, не покрываются и не описываются, разработанные аналитиком документы скорее похожи на документ исследование бизнеса, чем на документацию, написанную для технических потребителей, т.е. требуют проведения достаточно болшой работы на стороне разработки для "перевода" на технический язык, что приводит к неоднозначности или неверной трактовке требований. В данном докладе, я расскажу об опыте использования объектно-ориентированного подхода в бизнес анализе. В рамках использованного подхода, шаг за шагом, последовательно переходя от дного этапа (модели) к другой, были проведены работы по бизнес анализу и, какрезультат, разработке требований. При использовании данного последовательного и ясного подхода, мы были гарантированны от "белых" пятен в проведенном этапе бизнес-анализа, и разработанные требования не требовали дополнительного "перевода" на язык разработки. | Александр Белин |
Опыт онлайн-преподавания разработки требований | |
ЛАФ-2013 [Подробно...][Скрыть] Я хочу рассказать о своём опыте проведения 4-хмесячного онлайн-курса «Разработка требований к ПО».
| Денис Бесков |
Топ менеджмент как ограничение системы | |
ЛАФ-2013 [Подробно...][Скрыть] Заявка на второй день. Ориентировочное время 30 минут. Во многом повторяет выступление Ашманова в августе 2011 http://vimeo.com/26868924 , но кризис роста организации рассматривается с точки зрения теории ограницений, известных когниктивных искажений и теории Адизеса. PS. Мои доклады зачастую рассчитаны подготовку выше среднего. Возможно, для лучшего понимания и более полного участия в диалоге стоит посмотреть дополнительные материалы указанные тут: http://softwarepeople.ru/2013/docs/11_2_05_SergeY_Martynenko_Vlijanie_variacij_na_hod_proekta_i_metody_protivodejstvija_uvelicheniju_sroka.pdf | Sergey Martynenko |
Бокс vs Айкидо или о том как правильно задавать вопросы | |
ЛАФ-2013 [Подробно...][Скрыть]
Я бы хотел поговорить о разных стилях общения с клиентом на этапе сбора и обсуждения требований. | Шишаев Кирилл |
Стандарт OMG Essence - в чем польза для аналитика? | |
ЛАФ-2013 [Подробно...][Скрыть]
Консорциум OMG, известный, в первую очередь, разработкой языка UML, в рамках инициативы SEMAT выпускает новый стандарт по методологии программной инженерии - OMG Essence - Kernel and Language for Software Engineering Methods. Зачем ИТ-сообществу еще один профессиональный стандарт? Чем он отличается от уже имеющихся пары десятков стандартов и методологий разной степени признанности? Есть ли от него конкретная польза системным и бизнес-аналитикам, и что вообще нужно про него знать?
Обо всем этом - в докладе.
| Юрий Куприянов |
Практика применения методологии ARIS при разработке требований: взлёты и падения | |
ЛАФ-2013 [Подробно...][Скрыть]
В нашей компании разработка требований к информационной системе ведется в следующих условиях: | Алексей Шемис |
Бизнес-анализ наоборот | |
ЛАФ-2013 [Подробно...][Скрыть] Как говорит ТРИЗ "в случае, если сложно произвести необходимое действие с объектом, производят противоположное действие: например, сделать движущуюся часть объекта или среды неподвижной, а неподвижную движущейся или повернуть объект "вверх ногами", вывернуть его.". Сложно у нас в работе аналитика бывает не всегда, но я предлагаю не ждать сложностей и попробовать вместе повыворачивать бизнес-анализ наизнанку заблаговременно (: Сперва я приведу несколько примеров того, как этот принцип ("наоборот") работает в жизни, где он уже успешно применяется и какие получаются результаты. А потом совместно с залом попытаемся повыворачивать так горячо любимый нами бизнес-анализ. Результат доклада в большей степени будет зависеть не от докладчика, а от слушателей, их активности и креативности. | Юрий Веденин |