Название Конференция Описание | Автор |
---|---|
Утилизация аналитиков в крупных компаниях во время кризиса | |
ЛАФ-2016 [Подробно...][Скрыть] Расскажу об организации рабочего времени сотрудников в крупных компаниях (в компаниях - интеграторах и компаниях - клиентах ) в период кризисов. Рассмотрим два направления: внутренняя организация рабочего времени (внутреннее обучение) и внешняя организация рабочего времени (смартстаффинг). Обсудим как извлечь пользу рядовым сотрудникам и организациям во время кризиса.
| Олег Кузьмин |
Визуализируй это! | |
ЛАФ-2016 [Подробно...][Скрыть] Ходят легенды о том, что бОльшая часть людей визуалы и лучше воспринимают информацию, когда она представлена в визуальной форме. А ещё хотят легенды о том, что научиться рисовать очень сложно.. Знающие люди говорят, что визуализировать и рисовать – это немного разные вещи. В течение этого короткого воркшопа участники узнают, зачем и когда можно использовать визуализацию, увидят, что этому можно легко научиться и потренируются это делать прямо на воркшопе. Этот воркшоп будет полезен как начинающим, так и продолжающим бизнес-аналитикам.. а вообще, он будет полезен всем, кто ещё не использует визуализацию в своей работе в полной мере. Кстати, теории на нем почти не будет. А вот практики... | Юрий Веденин |
Волшебное путешествие от аналитика к менеджеру по продукту и обратно | |
ЛАФ-2016 [Подробно...][Скрыть] В докладе хочу поделиться своим недавним опытом на одном проекте, в котором я был сначала аналитиком и проектировщиком, потом взял на себя роль менеджера по продукту и продюссера выпуска продукта. Продукт был выпущен, но в какой-то момент перестал быть продуктом, а стал, фактически, проектом внутренней автоматизации. Менеджер по продукту здесь перестал быть нужен, и фактически сейчас я опять выполняю роль аналитика и владельца бэклога. В докладе хочу расказать - как происходят метаморфозы проекта, в какой момент проекту нужен аналитик. а в какой - менеджер продукта, когда они нужны оба и как они делят ответственность, и как выжить во всей этой катавасии. | Юрий Куприянов |
Выявление и оценка компетенций аналитиков | |
ЛАФ-2016 [Подробно...][Скрыть] В нестабильные и кризисные времена руководству компании как никогда важно знать возможности своих сотрудников, их потенциал, вектор развития. А фраза «экономика должна быть экономной» приобретает больше смысла и становится лозунгом многих директоров. Каждый руководитель задавался следующими вопросами: · Что можно сделать, чтобы снизить текучку кадров и сопутствующие расходы? · Как экономить время дорогих сотрудников на проведение собеседований? · Как оптимизировать расходы на обучение и тратиться только на те курсы, которые действительно нужны сотруднику? · Как понять, что сотрудник находится на своём месте и занимается тем, что ему интересно? · Как понять, кто в случае форс-мажора сможет заменить уникального специалиста? Наша компания столкнулась с подобными проблемами около 5 лет назад в период роста и повышения эффективности работы. И решение этих проблем было найдено во внедрении четких и прозрачных процессов оценки персонала, выполняющейся на регулярной основе. Внедрение оценки компетенций оказалось очень непростой задачей, которая решалась нами в несколько этапов. Для начала нам достаточно было анкет в MS Excel для выявления общих компетенций сотрудников, но в дальнейшем при увлечении количества сотрудников, при специализации анкет под различные роли сотрудников и их позиции в компании, стало понятно, что без полноценной автоматизации оценка компетенций становится очень сложным и дорогим процессом. В докладе я расскажу об опыте разработки анкет оценки компетенций аналитиков, проведения подобных оценок, проблемах и сложностях, с которыми мы столкнулись и к каким результатам пришли.
| Юлия Ерина |
Работа с требованиями при создании программного обеспечения бортовой радиоэлектронной аппаратуры | |
ЛАФ-2015 [Подробно...][Скрыть] В докладе представлены основные положения, которые касаются работы с требованиями при создании программного обеспечения бортовой радиоэлектронной аппаратуры с учетом использования стандарта RTCA DO-178C (Software Considerations in Airborne Systems and Equipment Certification), фактически являющегося основным руководящим документом при создании программного обеспечения различных уровней критичности, разрабатываемого для бортовой аппаратуры. Целью доклада является ознакомление слушателей с типом требований, уровнями критичности программного обеспечения, методами выявления требований, методами проверки требований на основании документа. В докладе рассмотрены основные виды документов и их назначение, выпускаемых в процессе разработки аппаратуры. В дополнении представлены другие документы подмножества RTCA DO-178С, для примера:
Приведены ошибки и их последствия в процессе неправильно спланированного бизнес процесса и создания некачаственных требований. | Лалетин Сергей |
Экспресс-погружение команды в бизнес заказчика | |
ЛАФ-2015 [Подробно...][Скрыть] Все мы знаем, что бизнес-аналитик стоит на передовой общения с заказчиком. Он много времени проводит в тесном контакте, в регулярных встречах и совещаниях и, волей-неволей, впитывает бизнес-цели, стратегии и принципы работы, многое ему начинает казаться простым и очевидным. Затем все это нужно донести до команды разработки и тестирования. Желательно без искажений, желательно полно, желательно понятно. Иногда еще быстро и эффективно, чтобы минимизировать число итераций и дефектов при разработке. Наш случай был такой же. Около 2 месяцев ушло на выявление требований к системе Билинга по учету оплаты за содержание лабораторных животных. Это миллионный оборот клеток, десятки комнат, сотни полок и тарифов, учет особого питания и ежедневный подсчет наличия клеток на конкретном месте; поддержка 8 видов потоков, интеграция с 3 финансовыми системами. И простая задача – сдать проект генерации счетов через 2 месяца, что допускало только один прогон на реальных данных для проверки правильности наших расчетов. Сначала я попробовала идти обычным путем через спецификации, диаграммы и схемы, но когда это не сработало, люди не успевали переваривать и вникать, я стала искать другой путь. О нем я и хочу рассказать. Я уверена, что применять его можно адаптировано на любых проектах, особенно когда нужно быстро и четко погрузить команду в новый бизнес-домен. | Екатерина Канаева |
Контроль юридической значимости справочника, ведущегося по заявкам/событиям | |
ЛАФ-2015 [Подробно...][Скрыть] Как обеспечить юридическую значимость при работе по схеме "Заявка- документ-выгрузка"? Ситуация: справочник/реестр, информация в который добавляется в результате поступления информации из нескольких источников. Процесс внесения изменений выглядит так: Источник (клиент, сотрудник, организация) подает Заявку на включение в справочник, заверенную электронной подписью, на основании заявки создается запись в справочнике. Запись в справочнике - новая сущность с новыми дополнительными реквизитами, такими, как дата включения записи в справочник, уникальный код и другими. Иногда для включения записи в справочник требуется заключение эксперта по первоначальной заявке, то есть поводом для включения записи в справочник становятся две подписи разных людей с разными полномочиями. Далее запись справочника может быть выгружена для использования другими информационными системами. Описание возможных методов обработки электронных подписей: настройка множественных схем подписи, сохранение информации об источнике (визированная копия) и другие. Возможные варианты реализации в зависимости от бизнес-потребностей и требований заказчика | Юлия Копылова |
Финансовые отчеты в режиме онлайн как инструмент диагностики бизнес-процессов. | |
ЛАФ-2015 [Подробно...][Скрыть]
| Алексей Залезский |
Методика оценки коллектива и выбора мотивации | |
ЛАФ-2015 [Подробно...][Скрыть]
Успех компании складывается из результативной работы всего коллектива.
| Чернова Анна |
Использование Jira Agile как инструмент для контроля гибкой разработки | |
ЛАФ-2015 [Подробно...][Скрыть] Добрый день. Есть желание поделиться опытом использования Sсrum на базе Jira 6. Расскажу как настроить плагин, проведу обзор основных возможностей и покажу слайды с примерами. Тезисно план доклада: 1. Как создать первый «дашборд»? 2. Основные параметры настройки «дашборда» (добавление цветовых индикаторов, быстрых фильтров). 3. Планирование с использованием плагина. Версии и спринты. 4. Реализация и мониторинг работ. 5. Закрытие спринта. Ретроспектива и отчеты.
| Алексей Тихонович |
Описание и моделирование бизнес-процессов | |
ЛАФ-2015 [Подробно...][Скрыть] Я расскажу о том, какие нотации моделирования бизнес-процессов могут использоваться при моделировании бизнес-процессов. Расскажу об основных шагах моделирования бизнес-процессов. Приведу как пример несколько форматов описания бизнес-процесса, форматов документов, которые являются исходными для описания и моделирования бизнес-процесса, и документов, которые описывают сам бизнес-процесс. Это будет скорее семинар, чем круглый стол. Точнее, это будет очередной мастер-класс. Участники смогут задавать вопросы по ходу дела. | Наталья Желнова |
Разговоры — это тоже работа! | |
ЛАФ-2015 [Подробно...][Скрыть] Сталкивались ли вы с ситуацией, когда сотрудники заказчика старательно затягивали проект и вставляли палки в колеса? Или когда кто-то из коллег саботировал работу над задачей и игнорировал ваши замечания? Что можно сделать для решения проблемы, кроме эскалации к руководителям? Что важнее? Сбор требований и рисование схем или коммуникации? Разговоры это важная часть работы аналитика. Поговорим о том, почему им надо уделять еще больше внимания и почему их следует относить к профессиональным компетенциям аналитика. | Ольга Самарина |
Как из ХЗ сделать ТЗ: 10 простых шагов к визуализации документов | |
ЛАФ-2015 [Подробно...][Скрыть] Несколько лет назад мне по наследству от старой команды достался волшебный пакет ГОСТовых ТЗ на продуктовые решения компании (общим объемом порядка 2000 листов). Вся пикантность ситуации состояла еще и в том, что документы эти читались заказчиками довольно часто и превратили мои рабочие дни в день сурка (много проектов -> много разных заказчиков -> много слёз). Когда закончилось терпение и появилось немного времени, я решила расправиться со своим наследством, покончить с ГОСТ и поработать над документом с точки зрения User Experience. Об основных приемах визуализации и восприятия, которые могут быть использованы при написании ТЗ, я и расскажу в своем докладе. | Юлия Ерина |
Личная эффективность системного аналитика | |
ЛАФ-2015 [Подробно...][Скрыть] Профессиональный успех специалиста по системному и бизнес-анализу зависит не только от уверенного знания предметной области, владения формальными нотациями и вооруженности инструментами. Немалую часть своего рабочего времени мы проводим в общении с заинтересованными сторонами проекта. И здесь становится явным то, о чем многие начинающие практики лишь догадываются: системный, а особенно бизнес-анализ в ИТ — это не о "компьютерах", а о "людях". Аналитик, пришедший в профессию со студенческой скамьи, из области разработки или контроля качества (QA), обнаруживает, что не сможет состояться в новой для себя роли, если не станет эффективно коммуницировать с каждым, в чьих интересах или чьими силами выполняется соответствующий проект. В рамках мероприятия, которое пройдёт в формате "круглого стола" или мастер-класса для ограниченного числа участников, мы сосредоточим свое внимание на эффективной коммуникации как одном из краеугольных камней "эффективного аналитика", поделимся личными секретами мастерства, заглянем в те области человеческой деятельности, где во главе угла также стоит общение, и уясним, что ценного для ежедневной практики системного и бизнес-анализа можно в них почерпнуть. | Алексей Петров |
#NoBA: Продолжение следует | |
ЛАФ-2015 [Подробно...][Скрыть] В апреле на Analyst Days широкой аналитической общественности был презентован первый открытый BDD проект в рамках #NoBA инициативы: http://analystdays.com/ru/talk/33417 Число волонтёров растёт. Предлагаю встретиться спустя два месяца и посмотреть, что у нас успело получиться. | Вадим Мустяца |
Хорошие истории | |
ЛАФ-2015 [Подробно...][Скрыть] Работая с командами, часто приходится сталкиваться с различного рода карго-суррогатами пользовательских историй, применение которых приносит ощутимый вред и продукту, и процессу разработки. Хуже всего то, что неправильное использование историй не позволяет получать те колоссальные преимущества, которые даёт этот подход. И заодно серьёзно его дискредитирует. Обычно для исправления ситуации в команде уходит одна-две итерации. Посмотрим, хватит ли нам полтора часа концентированных обсуждений, чтобы смасштабировать этот эффект для всех заинтересованных участников фестиваля. | Вадим Мустяца |
Как добиться успешного решения задачи в срок. | |
ЛАФ-2015 [Подробно...][Скрыть]
1) Как добиться решения задачи в срок?
2) Как избежать ответа типа «Не успел решить, был сильно занят»
3) Как избежать ответа типа «Не понял задачу» или «Понял задачу по-другому»
4) Как проверить утверждение типа «Я не мог работать потому, что…»
5) Как увидеть вовлеченность сотрудника в проект?
| Мария Ушакова |
Опыт внедрения Devprom на проекте поддержки и развития ИС | |
ЛАФ-2015 [Подробно...][Скрыть] В 2013 году я рассказывал об организации, учете и совместном использовании проектной документации. В том докладе была затронута тема взаимодействия хранилища документов SharePoint с системой управления проектами Devprom. На этот раз расскажу о внедрении и способах использования системы управления проектами Devprom распределенной командой на проекте поддержки и развития информационной системы одной из московских энергетических компаний. Покажу основные кейсы, которые используем в своей работе. Некоторые разделы доклада: · Адаптация жизненного цикла пожеланий и задач под потребности команды. · О том, как мы планируем релизы. · О работе с требованиями и документами. · О работе с тестовой документацией. · Полезные привычки проектной работы в Devprom (и не только). Без нудной теории. Только практика. Кратко. Без воды. Что-то может показаться очевидным. Обсуждение по результатам доклада приветствуется. | Сафин Павел |
Deadline как иллюзия. Посвящение в проектный агностицизм | |
ЛАФ-2015 [Подробно...][Скрыть]
| Анатолий Суздальцев |
Модели данных с динамическим набором атрибутов. Особенности реализации | |
ЛАФ-2015 [Подробно...][Скрыть]
При разработке информационных систем, особенно в случае быстро изменяющихся бизнес-процессов, нередко возникает ситуация, когда набор сущностей и их атрибутов заранее неизвестен. Возникает необходимость добавлять новые сущности и их свойства не только в процессе разработки, но и в ходе эксплуатации системы. Как это сделать без привлечения команды программистов? В докладе рассматриваются возможные технологические решения данного вопроса.
| Марина Липатова |
BI роскошь для богатых или суровая правда жизни | |
ЛАФ-2015 [Подробно...][Скрыть]
Так уж получилось, что компании накопили и хранят огромные объемы различных данных - о нас, о наших покупках, интересах и всяком-прочем.
И знакома ли Вам ситуация, когда Ваш Заказчик годами собирал данные о своих посетителях и наконец-то решил с Вами поделиться этими тайными знаниями, а Вы, к сожалению, не знаете что с ними делать?
Если да, то у нас для Вас есть пара хороших идей.
В настоящее время нас окружает великое множество мест, где реклама ждет своего часа. Если раньше мы терпели атаки ТВ, то сейчас даже просмотр видео на ютюбе опошлили впихнув туда аж по 4-5 рекламных пауз!!!!
А если ты СЛУЧАААЙНО зашел на какой-то неприличный сайт, то благодаря контекстной рекламе все друзья об этом узнают и хорошо, если только они…
Нам пытаются продать самые различные товары в самых, казалось бы, неожиданных местах!
При просмотре видео про корпоративную архитектуру я был удостоен просмотра клипа про подгузники, губную помаду, а она мне очень нужна… и тд
Вот было бы круто, если бы мне показали ролик про новый Нексус или ноутбук HP Pro, когда я искал подарок на Новый год для себя любимого.
Что же мне такого сделать, чтобы этим ребятам стали известны мои реальные нужны и интересы? Я даже сам готов им о них рассказать, раз уж они не знают, как использовать то, что уже и так обо мне знают!
Благо, что IT не стоит на месте и имеет уже готовые ответы на эти вопросы.
Мой доклад как раз о том, как понять своих клиентов, будучи на другой стороне баррикад - на стороне бизнеса, которому надо избавиться от залежавшегося товара, понять почему хороший товар не берут, что закупать, что нет, какую маркетинговую акцию спланировать, как стать привлекательнее для своих клиентов и т.д.
Если раньше хватало просто описания и люди сами выбирали что им нужно, то сейчас покупатель капризный, он требователен к рекламе и быстро забывает о ней, если товар ему не нужен. Казалось бы, преодоление этой проблемы - вотчина UX, но вот только знания, на основании которых осуществляется это проектирование, берутся путем суровых усилий BI специалистов, которые провели множество часов анализируя гигантский объем информации.
И это далеко не единственный пример применения BI, благодаря которому хранящиеся данные можно превратить в бесценный информационный ресурс и принимать как основу ответной стратегии на суровые реалии современного мира.
Я расскажу вам о своем опыте такого превращения. Покажу на примерах, как, понимая бизнес, его потребности и особенности, увидеть возможности и превратить рабочие данные в ценные знания.
| Семен Тарара |
Какое дело аналитику до IT-стратегии? | |
ЛАФ-2015 [Подробно...][Скрыть] Наша отрасль стремительно развивается, что нам с вами (как представителям гордой профессии бизнес-аналитик) сулит сложные и масштабные задачи, при том, что и оценивают нас теперь уже по другим меркам. Как не крути, а жить становится все сложнее и сложнее =)
Вспомним первый ЛАФ. Какие темы были в ходу? Как писать требования и что такое Use Case. Потом мы с интересом обсуждали управление изменениями и организацию работ команд аналитиков, а в прошлом году уже начали затрагивать тему Enterprise Architecture.
Хотелось бы продолжить развитие этих тем, углубившись в понятие IT-стратегии. Ведь сегодняшний Бизнес все больше и больше зависит от IT, а IT-службы перестают быть просто инструментом, они становятся способом достижения конкурентных преимуществ. В таких условиях бизнес и IT просто обязаны действовать синхронно, да-да, как в плавании.
И если компания ставит перед собой цель, то чтобы следовать намеченным курсом, ей нужна бизнес-стратегия и поддерживающая ее IT-стратегия. Вот она наша карта сокровищ! Пакуем наработки по корпоративной архитектуре и готовимся к увлекательному погружению в мир, в котором аналитик должен неустанно выполнять свою наиважнейшую функцию - спасать бизнес от всех преград. | Михаил Глазунов |
Проверено - мин нет! Эффективная работа с предположениями и ограничениями | |
ЛАФ-2015 [Подробно...][Скрыть] Не существует проектов, где на все вопросы имелись бы полные и однозначные ответы. Мы всегда вынуждены работать в условиях неопределенности. Чем крупнее компания, чем сложнее её бизнес и IT-структура, чем масштабнее проект, тем больше неопределённости. Аналитика можно сравнить с сапером на минном поле - цена ошибки может быть непомерно высока.
Часто неопытные специалисты закрывают неопределенности предположениями, сформированными на интуитивном уровне, без достаточной аналитический проработки. Риски, которые могут вызвать неверные (или не сбывшиеся) предположения, не документируются, не оценивается их влияние на успех проекта. Ограничения, разработанные как ответы на риски и предположения, явно не документируются и не доводятся до заинтересованных лиц. Все это может привести к печальным результатам. Не надо идти через «минное поле» без разведки! Давайте научимся эффективно работать в этих условиях!
Я хочу поделиться своим опытом в области работы с предположениями, рисками и ограничениями. Расскажу, на каких этапах проекта какие предположения и ограничения появляются, в зону ответственности каких ролей проекта они попадают. К счастью, в отличие от сапера, аналитик может ошибаться не один раз... Я расскажу, на каких «минах» мне и моим коллегам приходилось «подорваться».
| Сергей Рассамакин |
Бизнес-аналитик? Как это работает? Взгляд с высоты корпоративной архитектуры | |
ЛАФ-2015 [Подробно...][Скрыть] Юлия Фокина, Сергей Калинов
Все мы знаем, что система должна соответствовать ожиданиям и потребностям Заказчика, повышать эффективность его бизнеса, гармонично вписываться в его ИТ среду, и т.п., и т.п. Все мы понимаем, как важно знать окружение системы и бизнес, в котором она будет использоваться. Все мы понимаем, как важно правильно понять поставленную задачу. И всегда осознаем важность нашей инициативы в разработке требований.
Но раз так, то как выходит, что, берясь за новый проект, мы начинаем метаться в попытках понять, с чего начать? Как так получается, что Заказчик, увидев наши артефакты, делает удивленное лицо, заставляющее нас неловко пожимать плечами? Как так получается, что правильная структура требований, грамотно выбранная методология и соответствующие задаче нотации моделирования в совокупности дают грамотно оформленный результат, который не отвечает на вопрос - что нужно разработать и как это должно работать?
Что нужно знать и помнить, чтобы гарантированно прийти к успеху?
В своем докладе мы попытаемся ответить на этот вопрос. Мы покажем, как важно знать архитектуру предприятия для того, чтобы правильно понять поставленную задачу и организовать ее выполнение. Ведь это знание позволяет нам красиво смоделировать контекст проектируемого решения, и мы покажем, как это происходит.
Более того, мы покажем, как использование архитектуры предприятия позволяет решать нечётко сформулированные задачи и вносит элемент творчества в нашу работу.
Т.е. мы хотим показать, что корпоративная архитектура может быть превращена из артефакта большой стратегической разработки в эффективный инструмент решения аналитических задач. | Юлия Фокина |
Управление требованиями и автоматизация подготовки проектных документов | |
ЛАФ-2015 [Подробно...][Скрыть] Уважаемые представители оргкомитета! Выполняя просьбу Александра о наиболее подробном описании темы и с учетом вопросов по докладу Минска, многое (не все) написано не в формате тезисов, а в формате доклада и с заметками для слайдов (курсивом). Но, конечно, это не окончательный доклад. Если читать долго (много буквов!) - сообщите, напишу короче. Методика выработана для крупной многофункциональной корпорати вной системы, состоящей из нескольких подсистем (учетных, транспортно-логистических, отчетных) и обеспечивающей интеграцию Корпорации с клиентами и партнерами. Характерна сложная зависимость и влияние информационных объектов и операций по ним на другие информационные объекты/операции как внутри одной подсистемы, так и другие подсистемы и системы Корпорации и внешние системы. Приостановка работы системы является по определению недопустимой. Существенно: некоторые проектные документы (Альбомы ТФФ - Альбомы требований к интерфейсам обмена), которые готовим мы в рамках проектных работ, Заказчик передает владельцам и разработчикам внешних систем за строго определенное время до начала эксплуатации версии, для того, чтобы внешние системы успели разработать и установить новую версию своего ПО. По заявкам, поступающим от Заказчика (на основании изменений к нормативно-правовых актов (далее - НПА, проекты НПА) или для оптимизации работ) в системе учета JIRA регистрируются доработки для каждой подсистемы отдельно в разрезе заявки и подсистемы. После предварительного анализа и определения трудозатрат и в соответствии со сроком вступления в действие НПА доработки включаются в версию, передаваемую Заказчику к заранее определенной дате. Версия содержит изменения по всем ПО в зоне ответственности Исполнителя. Доработки, по различным заявкам Заказчика (имеющие разные основания для включения в версию), входящим в одну версию, часто затрагивают одну и ту же функциональность или влияют на смежные функции системы. Т.е. в версии могут содержаться разные доработки, влекущие изменение одних и тех же функций одного и того же документа. Но в процессе работ по доработкам версии от Заказчика могут поступить изменения к проектам НПА, поступившим первоначально или перенос сроков вступления в действие НПА или новые заявки (которые нужно реализовать в те же сроки), влияющие на ту же функциональность. Система достаточно большая, сроки проектирования, разработки, подготовки проектных документов очень жесткие. Зачастую изменения проектов НПА поступает уже после начала не только проектирования, но и разработки. Поэтому отследить все изменения в оперативном режиме, вовремя перепроектировать, передать в разработку по всем подсистемам и не сломать решения по доработкам, связанным с другими заявками Заказчика, но по этой же функциональности - задача не совсем простая. При этом проектную документацию нужно передать в установленные сроки по версии и строго описывающую доработки с учетом поступивших изменений. Количественно по одной версии (периодичность версий - 2-3 месяца): - доработок в версии по одной подсистеме: 150-250; - изменяемых интерфейсов - 50-70; - изменяемых подсистем: обычно 3, бывает до 6; - (продумать еще количественные показатели). Мой рассказ о том, как мы формируем требования к интерфейсам обмена на основании доработок, контролируем синхронность функциональных изменений в разных подсистемам (учетной, транспортной, отчетной) и по связанной функциональности. Что нам помогает: 1. Договоренность с Заказчиком о сроках поступления заявок и включении доработок в версию. Конечно, сроки далеко не всегда выдерживаются в т.ч. по причинам, не зависящим от Заказчика. 2. Инструментарий 2.1. JIRA с высокой степенью кастомизации, единый подход: – требования НПА/запросы Заказчика, связь НПА и доработок; - доработки в разрезе подсистем ПО; - интерфейсы обмена (ТФФ) и Альбомы, содержащие их описание; - обращения, ошибки. Настроены типы связей и стараемся их отражать. Показать описание доработки. 2.2. Subversion, хранилище документации: - поддержка версионности; - структуризация хранения документов; - обязательность использования; - централизованное решение для распределенной команды. Показать структуру Альбома ТФФ, версионность, ревизии. 2.3. Система ведения требований к интерфейсов обмена (ТФФ), единое хранилище состояния интерфейсов (ТФФ), программы формирования Альбома с учетом отражения артефактов в разных разделах Альбома и контроля непротиворечивости. Хранимые значения: - наименование, назначение, маршрутизация; - мнемоника, тип данных, длина; - комментарии (условия контроля реквизита в ПО); - версия ТФФ, дата начала действия версии, дата окончания действия предыдущей версии, - шаблон, пример. Особенности изменения версионности ТФФ. 3. Методика, обязательная к выполнению, разработки для внутреннего использования: - регистрация сущностей в JIRA; - контроль взаимосвязанных элементов, синхронизация; - разнообразные отчеты, контроль выполнения. Показать зависимости функциональности ПО и изменений интерфейсов. Пример зависимости изменения интерфейса и ПО. Показать связи отражения изменений ПО и интерфейсов на разных этапах работ с указанием зоны ответственности бизнес анализа, системного анализа, разработки. Показать схему ЖЦ доработок этапов анализа и проектирования с указанием точек контроля: - полнота регистрации доработок по подсистемам, наличие зарегистрированных изменений интерфейсов; - включение доработок в версию, изменений интерфейсов в ближайшую версию Альбома ТФФ; - проверка изменяемых функций ПО по доработкам и изменяемых интерфейсов; - подготовка бизнес требований по изменяемым интерфейсам; - согласование бизнес требований внутри бизнес аналитиков по смежным функциям ПО; - внесение изменений в систему ведения ТФФ; - формирование Альбома ТФФ; - согласование Альбома со стороны бизнес аналитиков, системных аналитиков (технических архитекторов) всех подсистем; - согласование с Заказчиком, через Заказчика - с разработчиками внешних систем. При поступлении новых заявок от Заказчика, изменении ранее поступивших, поступлении внутренних и/или внешних замечаний к интерфейсам обмена весь цикл выполняется в полном объеме, с обязательным отражением изменений в JIRA, проверкой доработок (при необходимости - их корректировкой), внесением изменений в систему ведения ТФФ, формирования Альбома ТФФ, обязательным пересогласованием. Автоматизация позволила быстро вносить изменения и переформировывать Альбом, исключить ручное дублирование одних и тех же сведений в разных разделах Альбома (и соответственно, технические ошибки, особенно по срочным изменениям Альбома перед самой публикацией). И конечно, снижение трудозатрат, снижение стрессовости работ. Также можно рассказать и про автоформирование смысловой части ТЗ. Но не будет ли это много для 40-минутного доклада? Чтобы не получилось как в Минске - элементарно не хватило времени и доклад получился скомканный и непонятный. | Ирина Гертовская |
Показатели назначения. Их роль и место в проектной и пользовательской документации | |
ЛАФ-2015 [Подробно...][Скрыть] Формат выступления - блиц-доклад или круглый стол (если будет желание публики). Возможно изменение лектора или ведение доклада с содокладчиком (ФИО укажу позже). Рассматриваем показатели назначения к уже разработанной и эксплуатируемой системе. Как правило, показатели назначения определны при разработке и не изменяются в процессе изменений функциональности. Т.е. в соответствующих разделах ТЗ указываем - изменений не требуется (стандартной фразой). Нобывают случаи, когда не рассмотренное влияние показателей назначения может пагубно сказаться на работоспообности системы. Деление показателей назначения на: - функциональные - Технологические - Технические Рассматриваемые вопросы: - Как избежать случаев, когда показатели назначения изменяются, а мы отделались стандартной фразой. - Как эффективно оценить показатели назначения (рекомендации). - Как не преувеличить объемы бедствия. - Всегда ли аналитик имеет возможность оценить показатели назначения. - Какие именно показатели назначения входят в зону ответственности аналитика. - Какие показатели назначения не входят в зону ответственности аналитика и кто отвечает за них. - Где и как должны быть отражены показатели назначения. - Место работ по показателям назначения при работах аналитиков по шаблонам проектирования.
Презентация доклада направлена 18.06.2015 почтой. | Ирина Гертовская |
Как ставить задачу на проектирование интерфейса | |
ЛАФ-2015 [Подробно...][Скрыть] Поговорим о общем опыте постановки задачи на проектирование интерфейса. Какие документы помогают проектировщикам в работе? Кто их может готовить? Должны ли аналитики прикладывать скетчи к документам? Нужно ли вообще разговаривать с проектировщиком о задаче? | Ольга Самарина |
Теория ограничений как основная схема для бизнес-анализа | |
ЛАФ-2015 [Подробно...][Скрыть]
Теория ограничений как основная схема для бизнес-анализа | Андрей Степенко |
Почему хорошая разработка это не всегда рост фирмы? | |
ЛАФ-2015 [Подробно...][Скрыть]
Почему хорошая разработка это не всегда рост фирмы?
По жизни оказывается, что на роли аналитиков ставят не очень квалифицированных людей, а квалифицированные быстро теряют квалификацию потому, что нужно много задач и разных областей, много общения с коллегами из других фирм. В этом случае можно быстро набирать опыт. | Андрей Степенко |
Бизнес идея как яйца фирмы | |
ЛАФ-2015 [Подробно...][Скрыть]
Бизнес идея, как яйца фирмы
Известный факт, что труднее всего копируются огранизационная эффективность. Это касается обычно зрелости моделей управления, качества коммуникации и вовлеченности. Простые вещи, типа отельных бизнес-процессов копируются легко. А что не копируется в приниципе? Или что поздно копировать, когда уже понятно? Что это? | Андрей Степенко |