Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Темы - bas

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 »
271
Обучение / [Конференция] SECR 2008
« : 01 Июля 2008, 13:47:54 »
Народ,

Скоро большое событие - Конференция SECR 2008. Мы по традиции будем информационными партнерами SECR.

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

272
xP Xd Agile ICONIX пр. / Статьи по Agile
« : 30 Июня 2008, 19:56:30 »
Данная ветка будет пополняться интересными статьями про Agile.
Вся дискуссия должна уходить в подтемы.

Вот первые из них:
* Статс Калканов пишет о "Distributed agile"
* Алексей Тигарев пишет про "Традиционные роли и роли в Agile"

274
О Сайте и Форуме / Новости Форума
« : 17 Июня 2008, 11:54:46 »
Сегодня немного перетрес разделы форума. Что сделал:
1. Разбил Управление Проектом и Методология на два форума
2. Методология перенес в "Общий раздел"
3. Сделал подфорум MDA и CMMI в форуме "Методология"
4. Добавил в подфорум RUP еще такие названия - EUP, AUP, OpenUP
5. Немного переместил темы с соответствующими тематиками в новые подфорумы

Что скажите?

З.Ы. Кстати, у нас появились новые активисты, которые буду курировать тему MDA. Благодаря им появилась возможность залить к нам старые сообщения с форума www.mda-delphi.ru

275
Столкнулся с проблемой убедить начальство\заказчика\маму\папу ... в том, что нормально выстроенный Процесс Управления Требованиями (ПУТ) это действительно нужно. Или как говорят небезызвестные нам консультанты -- what is the value of requirements management process?

Попытался сформулировать преимущества и риски, которые дает выстроенный ПУТ, но и они не дали результата. Давайте вместе подумаем, что можно придумать еще и переформулировать что есть.

4.   Преимущества внедрения процесса и средства Управления  Требованиями.
Ниже описаны все преимущества дающие внедрение процесса и средств Управления Требований.
4.1.   Внедрение регламентов по управлению требованиями позволит уменьшить время, требуемое на процесс анализа и всю разработку ПО в целом.
4.2.   Применение внедряемых техник сбора, анализа и документирования требований позволит разрабатывать ПО, наиболее полно отвечающее всем требованиям Заказчика. Что в итоге позволит сократить время разработки ПО
4.3.   Правильная организация требований позволит использовать требования и разработанные решения вторично, что сильно сократит время разработки .
4.4.   Полное описание требований и правильная их организация позволит более точно планировать разработку ПО.
4.5.   Полная база знаний (требования) ПО позволит делать более правильные стратегические решения по совершенствованию существующего ПО, разработки нового или интеграции ПО, имеющегося в наличии.
4.6.   Организация доступа, сохранности и версионности требований с помощью СУТ позволит уменьшить время разработки ПО и избежать ситуации работы с неактуальными требованиями. Кроме того, будет всегда известно – кто и по какой причине сделал изменения в требованиях, что увеличит контроль над процессом анализа.
4.7.   Совершенствование процессов целеполагания позволит разрабатывать ПО, которое будет помогать конечному Заказчику в достижении бизнес цели и автоматизировать наиболее необходимые и трудоемкие задачи.
4.8.   Правильное документирование и организация требований позволит легко и быстро ввести нового человека (Аналитика, Архитектора, Разработчика и Тестировщика) в проект.
4.9.   Правильное документирование и организация требований позволит улучшить качество требований, чтобы они стали более понятные, однозначные и тестируемые. Что в конечном итоге повысит качество создаваемого ПО.
4.10.   Правильное документирование и организация требований позволит улучшить взаимопонимание между Аналитиками и конечными Заказчиками. Что в итоге уменьшит время, требуемое на согласование требований.
4.11.   Правильное документирование и организация требований позволит улучшить взаимопонимание между Аналитиками и всеми членами команды разработки (Архитекторы, Разработчики и Тестировщики). Что в итоге позволит уменьшить время разработки и повысит качество ПО.
4.12.   Организация трассировки позволит понять – как одно требование влияет на другие и обнаружить ситуацию, когда требования определены не полностью. Данное преимущество позволит уменьшить время, требуемое на изменение требований, и описывать требования наиболее полно.
4.13.   Визуализация требований (моделирование) позволяется облегчить процесс понимания требований в целом и в деталях.
4.14.   СУТ позволит оптимально распределить права и обязанности между всеми задействованными лицами в проекте и обеспечит работу множества участников над многими проектами.

5.   Риски внедрения процесса Управления Требованиями.
Ниже представлен список возможных рисков при внедрении процесса Управления Требований. Данных рисков можно избежать, если правильно выстроить предлагаемый процесс.
5.1.   Требования должны быть известны всем участникам проекта
5.2.   В процесс анализа не должно быть вложено слишком много усилий
5.3.   Не следует быть через чур формальным с требованиями и спецификациями
5.4.   Не следует быть слишком не формальным
5.5.   Требования не должны быть слишком длинные и скучные для всех заинтересованных лиц, участвующих в процессе создания ПО

З.Ы. Следующим шагом должен быть описанный регламент УТ.

276
На семинаре «Как заставить регламенты работать и приносить пользу» была поднята проблема о том, что для эффективной разработки регламентов нужно как-то ее автоматизировать.

Одним из хороших примеров может служить Aris, если правильно его применить. Т.е. рисуем модель БП, добавляем туда мета информацию, настраиваем скрипты и на основе данной модели получаем и регламенты и должностные инструкции и ТЗ для разработки и ...
Но данное решение дорогое, даже слишком.
Что можно еще использовать для автоматизации регламентации?

Ждем здесь оппонентов, чтобы обосновать свои т.з.

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

Докладчик семинара высказала мнение что это не целесообразно, т.к. теряется общая нить БП и потом могут возникнуть коллизии.

Ждем здесь оппонентов, чтобы обосновать свои т.з.

278
На семинаре «Как заставить регламенты работать и приносить пользу» была поднята проблема о том, что при неустойчивом БП может происходить частое изменение бизнеса, что влечет за собой изменения в регламентации, если таковая деятельность производится.

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

Докладчик семинара предложил вносить изменения в регламенты и должностные инструкции не чаще чем 1 раз в квартал.

Ждем здесь оппонентов, чтобы обосновать свои т.з.

279
На семинаре «Как заставить регламенты работать и приносить пользу» была поднята проблема о том, что аудит при внедрении регламентов должен выполняться внешними (по отношению к отделу) специалистами по качеству\аудиту.

Ждем здесь оппонентов, чтобы обосновать свои т.з.

280
Вчера состоялся замечательный семинар «Как заставить регламенты работать и приносить пользу»

Мне очень понравилось. Все было просто супер:
* доклад очень содержательный и познавательный
* во время уложились точь в точь
* аудитория очень активная, была продуктивная дискуссия - 3 раза по 30 минут
* ну и конечно же докладчик - был на высоте, сразу видно преподаватель и практик со стажем. Еще раз спасибо Анастасии Воронковой.
* как всегда все отлично организовал УЦ Люксофт, спасибо им огромное

В связи с ограниченностью по времени остались следующие не разрешенные вопросы:
* Как следует проводить аудит выработанных регламентов: внутренний аудит vs внутренний?
* Что делать если БП меняется быстро и надо менять и внедрять изменения в регламенты?
* Целесообразно ли вводить регламенты не по всем БП, а только по одному или двумя?
* Средства автоматизации для разработки регламентов

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

281
По традиции начнем здесь записывать все ссылки на интересные источники информации о BI, ERP, CRM и т.д.

Блог про Oracle Business Intelligence

282
29 мая 2008 г. в 18:00 пройдет Семинар – круглый стол «Как заставить регламенты работать и приносить пользу»

Место проведения: Центр обучения Люксофт

Регистрация: на сайте livents.ru. Указывайте свое ФИО в профиле вашего логина на livents.ru, иначе Вы не пройдете на Семинар

Условие участия: БЕСПЛАТНО

Предисловие к представленному анонсу
Для систем автоматизации, в которых задействовано много пользователей с различными ролями написание хорошего ТЗ (работа системного аналитика) недостаточно для обеспечения работоспособности системы.
В многопользовательской системе необходима работа бизнес-аналитика, результатом которой будет, как минимум, схема процесса TO BE для написания ТЗ. В реальности большую многопользовательскую систему невозможно внедрить без регламентации деятельности людей вокруг системы. Львиная доля рисков внедрения системы для групповой работы сосредоточена именно в процессе создания регламентов (если угодно, технологии применения средств автоматизации), а так же в процессе внедрения созданных регламентов. Технические риски в таких проектах отходят на второй план, работоспособность или не работоспособность принятой (и зафиксированной в системе) организационной схемы полностью решает дальнейшую судьбу ИТ системы.
Семинар раскрывает сторону, которую ИТшники вообще никогда не считали своими activity, на деле же, из за отсутствия этих вещей терпят крушение многие проекты внедрения больших систем. При этом часты случаи, когда акты закрытия этапов подписаны, система пуско-налажена, но никто в ней не работает.

Целевая аудитория:
1.   Бизнес-аналитики.
2.   Системные аналитики.
3.   Руководители проектов внедрения ПО.
4.   Любой другой заинтересованный сотрудник любой Компании.

Что дает семинар:
Теоретические и практические знания по:
1.   определению критичных для описания бизнес-процессов;
2.   моделированию бизнес-процессов разного уровня;
3.   формированию текстов регламентов на основе схем бизнес-процессов;
4.   быстрому и неформальному согласованию регламентов;
5.   построение мотивации сотрудникам, участвующих в бизнес-процессах.

Уровень подготовки: понимание необходимости регулярного управления с помощью разработки и поддержания в актуальном состоянии бизнес-процессов Компании.

План:
1.   Вводная часть. Цели регламентации с учетом автоматизации деятельности. Основные определения.
2.   Взаимоотношения бизнес-аналитика и программиста при автоматизации деятельности.
3.   Технология регламентации деятельности с учетом автоматизации
Теоретическая часть:
Технология регламентации деятельности через моделирование бизнес-процессов.
Определение приоритетных мест для моделирования процессов.
Построение схем бизнес-процессов и поиск мест для автоматизации.
Создание ТЗ (форма, ответственность за составление и исполнение, сроки исполнения тестирование).
Построение регламента понятного для разработчика и исполнителя.
Создание документа для пользователя.
Внедрение процесса с учетом введения нового/измененного программного обеспечения. Эксплуатация и решения проблем при введении регламента с учетом автоматизации деятельности.
Как часто необходимо изменять созданные регламенты, в случае наличия изменений?
Практическая часть:
Отработка технологии построения регламентов.
Создание регламентов для пользователя на 1 странице?
4.   Построение мотивации на основе построенных бизнес-процессов
Теоретическая часть:
Взаимосвязь результатов процесса и мотивации персонала. Определение ключевых показателей деятельности сотрудников, участвующих в процессе.
Практическая часть:
Совместная работа по определению мотивации для участников процесса (для данной работы берется уже сформированный регламент, см. п. 3).

Длительность: Семинар – круглый стол рассчитан не более 4 рабочих часа. 1 перерыв на 15 минут.

283
28 июня 2008 года в Москве пройдёт первая конференция, посвященная обучению в области разработки программного обеспечения - Training Labs 2008.

Интересуетесь обучением в области Software Engineering?
Ищете куда отправить сотрудников на обучение?
Являетесь учебным центром или независимым тренером в данной области?

Тогда это мероприятие — для вас!

Формат: тренинговый марафон, 8 секций, в каждой из которых по 4 мини-тренинга/мастер-класса длительностью 1.5 часа каждый.

Цель мероприятия: сблизить заказчиков и провайдеров обучения.

Это уникальная возможность для учебных центров и независимых тренеров, специализирующихся в области разработки ПО, показать "товар лицом", а для участников - посетить максимальное количество тренингов за 1 день, "пощупать тренеров в деле".

К тому же, мы все будем просто общаться на волнующие нас темы в данной области. Приходите, будет интересно!

Мы с нетерпением ждем:
    * учебные центры и независимых тренеров провести мини-тренинг/мастер-класс по одной из 8-ми тем;
    * спонсоров и инфо-спонсоров, готовых взять на себя часть наших расходов и поведать миру о нашем начинании;
    * и конечно же, участников, ради которых все это и организовывается.

Регистрируемся

Подробнее про конференцию

284
Представим себе ситуацию. Есть компания, большая компания, бизнес которой связан или не связан с ИТ, типа Лукойла, Роснефти, МТС, Люксофт и т.д.
Так вот у них много подрядчиков, в том числе на разработку ПО и в частности на разработку ТЗ и требований. Так же есть свое подразделение Разработки, которая пишет ПО, разрабатывает требования. Компания хочет ревьюировать внешние ТЗ и создавать у себя базу знаний требований, чтобы была возможность безболезненного смены подрядчика и следовательно чтобы у них всегда была актуальная база требований.

Как в таком случае можно управлять требованиями, а скорее кучей приходящих ТЗ??

Есть три варианта:
1. Принимать ТЗ и складировать их у себя в проектных папках. Но тогда встает вопрос про связывание требований, их синхронизации и прав доступа
2. Принимать ТЗ из вне и тупо перебивать их в СУТ (система управления требований). Тогда быстро произойдет рассинхронизация
3. Заставить подрядчиков работать во внутренней СУТ. Вариант хороший, но какие есть подводные камни??


285
Вот тут журнал IT+ФИНАНСЫ №3 2007 г. представил данные по некоторые внедрения ERP-систем российскими компаниями:
http://www.finansmag.ru/47938

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 »