СМ-Консалт
 

Оценка эффективности от внедрения и использования методологии и инструментальных средств IBM Rational

Статьи Аналитика

Оценка эффективности от внедрения и использования методологии и инструментальных средств IBM Rational

Александр Новичков, руководитель отдела внедрения и консалтинга, СМ-Консалт

Статья опубликована на сайте IBM  DeveloperWorks

 

«Теория ничего не доказывает, зато позволяет выиграть время и отдохнуть, если ты вконец запутался, стараясь найти то, что найти невозможно»,

Марк Твен

 

Оглавление

  • Введение
  • Цели и задачи внедрения. Зачем мы что-то внедряем?
  • Эффекты от внедрения. Стоит ли игра свеч?
  • Методики расчета эффекта от внедрения. Как оценить эффект?
  • Метод от снижения издержек
  • Сухой расчет
  • Статистические показатели на основе нескольких проектов
  • Количественный эффект
  • Качественный эффект
  • Почему желаемый ROI может НЕ быть достигнут?
  • Технология внедрения и автоматизации. Процесс или инструмент?
  • Место систем IBM Rational в ряду корпоративных информационных систем
  • Построение прозрачного процесса разработки
  • Подходы во внедрении.
  • Почему RUP?
  • Роль пилотных проектов во внедрении
  • Заключение
  • Дополнительные ресурсы
  • Об авторе

 

Введение

 

Return on Investment (ROI) возврат инвестиций - это значение, которое подсчитывает каждая компания при внедрении новых технологий или капитальной модификации существующих процессов. Перед началом проекта определяемое ROI всегда преподносится в лучшем свете, но в итоге на практике результат не подтверждается или про проверку выполненных расчетов спокойно забывают, т.к. проект закрыт и все стороны довольны. Цель данной статьи - показать основные  методы, с помощью которых можно достичь максимального коэффициента ROI. Конечно, данная методика может использоваться как вспомогательный материал, но необходимо обратить внимание на то, что в каждой организации есть свои нюансы. При внедрении необходимо обращать внимание на размер компании, ее географическое расположение, географическую распределение филиалов компании, возраст участников, культуру организации и т.д. Любая методика и технология, хороша при грамотном внедрении, с учетом всех специфических особенностей. Данный материал основывается на реальных проектах и отражает практическое применение описанных методов. В подготовке данного материала активное участие принимал Александр Шамрай - руководитель отдела перспективных технологий компании СМ-Консалт, за что автор выражает ему свою благодарность.

 

Цели и задачи внедрения. Зачем мы что-то внедряем?

 

Какие цели мы ставим перед собой перед внедрением какой-либо программной системы, будь то от компании IBM, Microsoft, HP или других компаний, которые предоставляют примерно похожие решения для автоматизации процессов разработки и сопровождения ПО? Чего мы хотим достичь, внедряя новые технологии? Результатом проекта внедрения должен быть прозрачный, четко регламентированный, документированный и автоматизированный процесс разработки и сопровождения. Прежде всего, можно выделить следующие цели:

  • Обеспечение стабильной повторяемости результатов с заданным качеством, что достигается за счет стандартизации, модификации, регламентации и документирования процессов;
  • Снижение квалификационных требований к участникам IT-проектов. Процесс должен быть настолько прозрачен и понятен, чтоб обеспечить вливание в него новых сотрудников за минимальный срок, не смотря на их практический опыт - это студент или профессионал;
  • Сокращение сроков выполнения IT-проектов. Каждый выполненный проект становится частью одной большой базы практик компании, которую могут использовать управленцы организации в своей дальнейшей работе. Управление каждым новым проектом базируется на основе статистических данных и типовых шаблонов прошлых проектов.

 

Кому необходимы технологии и методологии работ? Конечно, нужны они всем организациям. Все организации можно разбить на несколько групп:

1.      Заказчики - компании, которые не имеют своих групп разработки и для выполнения работ нанимают аутсорсинговые компании. Этим компаниям необходимы методологии для того, чтоб правильно составить техническое задание, правильно принять и протестировать поставляемый продукт.

2.      Разработчики - разрабатывающие ПО организации. Изначально все средства IBM Rational были направлены на эту группу организаций.

3.      Сопровождающие организации - существуют компании банковские, металлургические и т.д., которые имеют свой отдел разработки, но разработка ПО не является их основным направлением. Для этих компаний необходима технология автоматизации процесса сопровождения.

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

 

Эффекты от внедрения. Стоит ли игра свеч?

 

Эффекты можно разделить на две большие категории: эффект получаемый на стратегическом уровне, т.е. на уровне бизнеса, и тактический эффект, который получат все участники процесса:

1.      Стратегический эффект:

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

2.      Тактический эффект:

  • Уменьшение сроков и снижение стоимости обработки новых запросов, т.е. обработки новых требований, новых потребностей бизнеса и снижение себестоимости исправления дефектов.
  • Улучшение качества IT-услуг - это вовремя выполненные работы и с заранее определенным качеством.
  • Увеличение эффективности используемых ресурсов, хорошо организованный и формализованный процесс позволяет четко определить роли и ответственности каждого участника этого процесса.
  • Более четкое и реалистичное планирование, т.е. исключение формирования планов на основе «умножить на 2» и создание реальных плановых сроков, которым следуют все.
  • Значительное уменьшение времени на принятие решения. Доступ ко всей проектной информации, статистике и проектной документации обеспечивает возможность оперативно принимать решения необходимые для реализации возникших проблем или новых запросов.
  • Снижение влияния человеческого фактора. Автоматизация часто повторяемых операций позволит участникам проекта больше внимания уделять более важным задачам и в свою очередь обеспечит качественное и безошибочное выполнение этих операций.

 

Методики расчета эффекта от внедрения. Как оценить эффект?

 

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

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

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

3.      От снижения издержек. Это самый распространенный метод, который используют большинство компаний. Перед выполнением проекта выполняется оценка выполнения операций, для которых будут применяться новые технологии, например время, которое уходит на планирование или обработку входящих запросов. Далее, к собранным данным применяются коэффициенты, которые покажут прогнозируемое снижение трудозатрат на выполнение операций после внедрения системы автоматизации. Полученные результаты умножаются на ставку сотрудника, который выполняет обследуемые работы, и принимаются как оценка эффективности внедряемых технологий.

 

Метод от снижения издержек

 

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

  • Статистический метод, когда все оценки и коэффициенты, которые применяются, основываются в основном на статистических показателях ранее выполненных проектов внедряющей технологии компанией. Т.е. каждая компания, которая занимается внедрением, выполняет оценку уже проведенных проектов, формирует базу, в которой учитываются и все особенности проведенных проектов, т.е. учитываются отрасль организации, размещение, географическое разделение компании т.д. Далее эта база является источником основных показателей для следующих проектов.
  • Глубокий метод, т.е. перед проведением проекта выполняется тщательный анализ всех текущих процессов, которые происходят в компании. Выделяются и исследуются текущие задачи, определяется состав исполнителей, их процентное участие в исследуемых операциях. Кроме этого оцениваются возрастные характеристики персонала, его возможности к восприятию и применению новых технологий и.т.д. Соответственно, из-за такого глубокого обследования, этот метод является более трудоемким, чем предыдущий. Но также способ является более точным, так как базируется не на общеотраслевой статистике, а на реальных показателях конкретной компании.

 

Кроме понижающих коэффициентов учитывается также количество воспроизведений исследуемых операций в год и при умножении этого количества на сэкономленное время события получается общее рабочее время сотрудников, которое экономится в результате внедрения новых технологий. Для того, чтоб перейти от временных показателей к финансовым, необходимо умножить сэкономленное время на ставку сотрудника, выполняющего операцию, и определить количество людей, которые привлекаются к выполнению операций. В таблице (см. Таблица 1) показан небольшой пример анализа события.

 

Таблица 1. Анализ фактора

Событие

Обеспечивается

Составляющие

Финансовая оценка

Количественная оценка

Принятие решения о реализации нового запроса

Оперативным доступом и достоверностью полученной информации

Уменьшение времени на подготовку и анализ информации

Стоимость подготовки информации = время подготовки* ставка

Уменьшение в несколько раз

Уменьшение времени поиска информации

Стоимость поиска информации = время поиска * ставка

Уменьшение времени на согласование решений

Стоимость согласования решений = время согласования * ставка

 

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

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

 

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

При подсчете финансовой показателей повышения эффективности при выполнении событий необходимо руководствоваться следующими параметрами (см. Таблица 2):

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

 

Таблица 2. Подсчет возврата инвестиций для операции «Принятие решения о реализации нового запроса»

Составляющие

Время выполнения, в человеко-часах

Разница

Частота

Процент работ сотрудника, %

Итого, в человеко-часах

До внедрения

После внедрения

Уменьшение времени подготовки информации для принятия решения

6

2

4

44

10

17,6

Уменьшение времени поиска информации

4

1

3

40

10

12

Уменьшение времени согласования решений

24

8

16

22

10

35,2

Итого по операции

64,8

Итого в финансовом выражении  на сотрудника, у.е.

1101,6

 

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

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

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

 

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

 

Сухой расчет

 

Ниже приведен пример оценки возврата инвестиций при внедрении систем автоматизации. Представим заказчика, у которого 21 сотрудник. Представим среднего сотрудника, который работает 2016 часов в год, и имеет ставку 17 долларов в час, т.е. эта ставка включает в себя все: издержки на сотрудника, стоимость аренды рабочего места, стоимость аренды земли и т.д. Представим, что в компании работает следующее соотношение сотрудников:

  • Главный специалист - 30% от общего количества сотрудников в компании. К ним можно отнести аналитиков, менеджеров тестирования и архитекторов.
  • Ведущий специалист - 50%. Это разработчики, интеграторы.
  • Управленец - 20%. Это менеджеры, заместители и руководители отделов.

 

Для того чтоб рассчитать одноразовые затраты, необходимо выполнить расчет затрат связанных с приобретением лицензий и внедрением систем автоматизации. Каждый сотрудник использует свой набор инструментов для повседневной работы, т.е. это средства версионного контроля, управления изменениями, проектного управления и т.д. Гибкая система лицензирования IBM Rational на основе плавающих лицензий позволяет динамически распределить использование продуктов между сотрудниками и тем самым сэкономить на количестве лицензий. Результат подсчета стоимости лицензий и стоимости внедрения приведен в таблице (см. Таблица 2) и основывается на статистических показателях, которые были получены при проведении проектов внедрения инструментальных средств компанией «СМ-Консалт».

 

Таблица 3. Пример расчета стоимости затрат на проект внедрения методологии и технологии

Специалист/работа

Доля сотрудников в организации

Усредненная стоимость лицензий на сотрудника

Общая стоимость

Главный специалист

30%

7000$

44100$

Ведущий специалист

50%

3800$

39900$

Управленец

20%

4000$

16800$

Итого

100800$

Итого со стоимостью внедрения

155800$

 

Далее необходимо провести расчет ежегодных затрат (см. Таблица 3), которые состоят из поддержки системы и стоимости ежегодных услуг производителю. Внутренние затраты рассчитываются по следующим формулам:

1.      Стоимость поддержки:

  • Внутренняя поддержка - это поддержка систем автоматизации сотрудниками компании и определяется использованию 1,5 специалиста с загрузкой 30-35% рабочего времени;
  • Внедрение - 15-20% от стоимости контракта внедрения;

2.      Поддержка производителя обычно составляет 15-18% от стоимости лицензий;

 

Таблица 4. Ежегодные затраты

Специалист/работа

Расчет

Стоимость

Стоимость поддержки

Внутренняя поддержка: 1,5 специалиста * 30-35% рабочего времени

Внедрение: 15-25% стоимости контракта внедрения

31563$

Поддержка производителя

15-18%

15120$

Итого

46683$

 

На рисунке (см. Рисунок 1) отображены тенденции по возврату инвестиций. Как видно на этом рисунке, первый год будет затратным, т.к. происходит закупка лицензий и проводится основная масса работ по внедрению инструментов. Следующие же года будут иметь положительную тенденцию и прирост возврата инвестиций.

 

Возврат инвестиций по годам

Рисунок 1. Возврат инвестиций по годам

 

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

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

 

Статистические показатели на основе нескольких проектов.

 

Важно понимать, что возврат инвестиций есть сугубо финансовый показатель, очень важный для лиц, принимающих решение о финансировании работ. На тактическом уровне (уровне тех, кто будет работать с методологии) и уровне заказчика неплохо говорить не только о количественных показателях, но и КАЧЕСТВЕННЫХ.  То есть, что с точки зрения качества будет получено на выходе проекта по внедрению методологии.

Ниже представлены среднестатические выкладки  по нескольким проектам и показан именно качественный эффект. Хотя и количественному эффекту уделяется достаточно внимания.

 

Количественный эффект

 

На графике ниже (см. Рисунок 2) показан пример эффективного использования лицензий, который основан на фактических данных. У компании IBM есть возможность использовать лицензии плавающего типа Floating User - это лицензии, которые оговаривают количество подключений в один момент к серверу, то есть одновременное максимальное количество пользователей, которые могут работать с технологией. Суть эффекта заключается в том, что редко какие компании могут максимально эффективно применить закупленное количество лицензий. Зачастую случается так, что закупается количество лицензий одного продукта равное количеству сотрудников его использующих.

На графике по оси X идет рабочее время, а по оси Y находится количество лицензий, которое используется в один момент времени, т.е. график отражает активность работы специалистов с инструментом в течение дня. Измерения проводились в течение 3-х лет, и для снятия статистических данных был выбран один и тот же день, в котором предполагалось максимальное присутствие рабочего персонала.

 

Статистика использования лицензий

 

Рисунок 2. Статистика использования лицензий

 

Как видно на графике, в первый год использования инструмента, фактически это год внедрения и проведения пилотного проекта, пик активности приходился на начало рабочего дня, а далее лицензии фактически не используются. На следующий год в проекте увеличилось количество участников где-то на 50-60% и были приняты шаги по оптимизации лицензий, и как видно на графике количество лицензий в утреннее время увеличилась, но и в то же время использование в течение рабочего дня выровнялось. Основной принцип оптимизации, который применялся, - это регламентированное по отделам использование программных продуктов. В последний год, который отражен на графике, количество сотрудников увеличилось еще на 30%, но пик максимального количества используемых лицензий практически не изменился, а активность равномерно распределена в течение рабочего дня. Т.е. в результате за 3-и года работы получается прирост использования лицензий всего на 50%, при этом количество участников проекта увеличилось вдвое.

 

Качественный эффект

 

Качественный эффект - что можно получить? Ниже изображен график (см. Рисунок 3), который отражает количество нареканий от бизнеса той же компании за трехлетний период времени. Что такое нарекания от бизнеса? Нарекания от бизнеса - это получение официального письма или факса с выражением негодования в отношении продукта или проведенных работ директору IT-службы, которая занимается разработкой ПО. Эти нарекания связаны в основном с большим количеством ошибок, которые найдены в готовом продукте, несоответствием выполненных работ ожидаемым результатам бизнеса и т.д. При этом не учитываются обращения, которые были сделаны в личном порядке, т.е. в устной форме или в виде писем e-mail.

 

Количество нареканий от бизнеса

 

Рисунок 3. Количество нареканий от бизнеса

 

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

 

 

Рисунок 4. Количество тестов

 

На рисунке (см. Рисунок 4) отображено то количество тестов, которое выполнялось до и после внедрения технологий. Как видно на графике, в начале выполнялось около 50 тестов, и это были в ручные тесты, которые выполнялись 5-7 сотрудниками. Качеству выполняемого тестирования можно было только «позавидовать», т.к. тестировщики на самом деле не успевали провести полноценное регрессионное тестирование и тестировали в основном только последние реализованные функции. К концу проекта внедрения количество тестов выросло к 450 и это уже были не ручные тесты, а автоматические тесты, сложность, которых превосходила ручные, и они покрывали не только последний реализованный функционал, но проверяли соответствие продукта всем ранее поставленным требованиям.

Еще одним фактором уменьшения нареканий есть повышение эффективности обработки запросов от бизнеса. На рисунке (см. Рисунок 5) отображены графики, которые показывают статистику решения запросов от до и после проведения проекта внедрения. Как видно на графиках, наблюдается существенный рост как решаемых запросов, что говорит об эффективности обработки запросов, так и количество выполненных задач, что говорит о повышении эффективности планирования работ.

 

 

Рисунок 5. Статистика запросов различного типа

 

Кроме повышения эффективности при работе с заказчиками можно определить и повышение внутренней эффективности, например, повышение эффективности на уровне разработки:

  • Улучшение качества документирования кода. Большинство компаний, в которые мы приходим, держат недокументированный код, т.к. большинство специалистов считают невозможным документировать все, что они пишут, потому что надо очень быстро писать, и времени на документацию нет. Но это ошибочное мнение, а что еще более страшно, недокументированный код может значительно «затормозить» работы при внесении изменений в ту часть программы, которая формировалась, например, год назад и сотрудником, который уже давно уволился. Поэтому для того, чтоб отсечь такие риски, выполняется одна простая метрика - одна строка комментария на 4 строки кода, которая внедряется в систему версионного контроля. И в дальнейшем в версионную систему разработчик просто не положит часть своего кода, если он не соответствует вышеприведенному правилу.
  • Улучшение читаемости кода. Есть также ряд метрик, которые показывают сложность кода, которые показывают сложности потока управления, сложности потока данных.
  • Повышение производительности труда разработчиков за счет возможности «ветвления». Т.е. если у заданной компании имеется ядро системы, которое потом ставится своим внутренним заказчикам, например, 20 внутренним заказчикам, и для каждого заказчика потом делается доводка этой системы для некоторого отличного от общего функционала, то эффективность возрастает с увеличением количества параллельных доработок. Чем больше параллельных доработок, тем выше эффективность от внедрения средств конфигурационного управления IBM Rational, которая основывается на уменьшении издержек поддержки различных конфигураций разрабатываемого ПО.
  • Сведено на нет количество повторных и забываемых ошибок. За счет автоматизированного регрессионного тестирования выполнение всех ранее написанных тестов позволяет исключить воспроизведение ранее исправленных ошибок или возникновение новых ошибок в функционале, который уже был проверен раньше.
  • Полное планирование релизов. Очень часто релиз во внутренних компаниях выпускается по факту, редко планируется с точной датой, т.к. часто существует мнение, что планы все равно поплывут.
  • Эффективное «введение» в проект новых сотрудников. Можно гораздо быстрее обучить нового сотрудника, в том числе в системах версионного управления есть возможность подачи аннотирования кода, т.е. всю версионную историю файлов система представляет в виде набора изменений с причинами принятия и отклонения тех или иных изменений. Например, разработчик 4 года назад делал локальный эксперимент по сортировке массива, взял для эксперимента 3 метода Шелл, Хор, Пузырек. В результате, было решено, что самый оптимальный метод Шелл, и вся информация по эксперименту помещается в версионнную сиситему. Новый разработчик, выполняя аннотацию кода, получает карту изменений файлов, где видно какие решения были заблокированы ввиду бесперспективности. Т.е. новый участник проекта не пытается повторить то, что уже было сделано, и то, что привело к нежелательным последствиям.

 

На рисунке ниже (см. Рисунок 6) отображена зависимость процента ручной деятельности от возрастающей сложности проектируемой системы. Увеличение сложности системы приводит к тому, что увеличивается ряд ручных операций для полноценной разработки данной системы. И соответственно, график показывает соотношение - каким образом эффективность повышается, каким образом эффективность позволяет то же самое сделать быстрее с использованием средств автоматизации, нежели чем их просто не будет.

 

Рисунок 6. Эффективность на уровне разработки

 

Компаний, которые не используют никаких средств автоматизации и управления, изменений управления, конфигураций практически не осталось, по крайней мере, их очень мало. Решений на рынке, которые позволяют вести управление изменениями достаточно большое количество от бесплатных, условно-бесплатных и до платных. Поэтому, когда идет вопрос выбора системы, то между бесплатными и платными системами нельзя поставить знак равенства. Т.к. не все делается одинаково эффективно в каждой системе и для каждого инструмента будет различная оценка эффективности, т.е. при использовании одной системы время на выполнение некоторых операций может существенно сократиться, а для других нет. Но данная модель ROI справедлива, как и для покупных средств, так и для условно-бесплатных и бесплатных. При практической реализации необходимо учитывать эффективность средств, а также скрытые расходы, которые могут сопровождать внедрение и поддержку. Это говорит о том, что ROI будет достигнут при любых инструментальных средствах, но за разный временной период и с разным качеством. Для тех, кто попытается на практике реализовать данный подход расчета, мы советуем использовать поправочный коэффициент для систем от разных производителей.

Таблица 4 обобщает всю полученную ранее информацию и показывает реальные статистические показатели нескольких проектов внедрения, в разрезе: как было до внедрения и как стало после.

 

Таблица 5. Таблица эффектов с замерами показателей до и после внедрения методологии и технологии

Эффект

До внедрения

После внедрения

Описание

1

Количество нареканий от бизнеса

32

6

Под нареканиями понимается серьезный сбой или недоработка системы после ее сдачи

2

Количество тестов

50

450

Автоматизация тестирования позволяет в разы увеличить эффективность тестирования

3

Количество принятых и выполненных запросов от бизнеса

374

2529

За счет построения эффективного процесса увеличивается объем решаемых задач

4

Количество внутренних задач, для решения запросов от бизнеса

680

7090

Сложность задач, поступивших от бизнеса

 

 

Почему желаемое может НЕ быть достигнуто?

 

Почему желаемые результаты от внедрения могут не быть достигнуты? Что может отрицательно повлиять на результаты проекта внедрения? Рассмотрим некоторые самые важные на наш взгляд моменты:

1.      Отсутствие политической воли руководства. Проект внедрения должен идти в составе приоритетных проектов. Если руководство не требует постоянно данных по проекту внедрения, то, скорей всего, проект внедрения идет медленно и фактически останавливается.

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

3.      На протяжении внедрения не производились замеры показателей и не выполнялась корректировка проекта. Большинство организаций, когда хотят работать с подрядной организацией по внедрению каких-то процессов, хотят получить фиксированный проект с заранее оговоренными сроками, с оговоренной суммой контракта. Наибольшая сложность начинается на этапе обследования, т.к. этап обследования - это первый этап после того, как заключен контракт. Соответственно все, что написано было в контракте, составлялось до обследования организации. После обследования может возникнуть ряд моментов, которые могут повлиять на уже зафиксированные пункты контракта. Т.е. нужно быть готовыми к тому, что возможно придется пересмотреть какие-то позиции, либо, как обычно, разбивать на 2 этапа - обследование отдельно, а после него отчет, и тогда становится ясно, как завершится проект.

4.      Завышенный объем проекта. Заявлен тот объем работ, который фактически не может быть выполнен в течение проекта. Т.е. достаточно часто бывает желание, например, если это банковская компания, у которой есть автоматизированная банковская система с большим количеством подсистем, модулей и т.д., взять самый проблематичный внутренний проект и на нем испытать новые технологии. Это один из путей неудачного внедрения, потому что если в этом проекте чувствуется напряжение, то это явно не место для того, чтобы можно было внедрять какую-то новую технологию.

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

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

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

8.      Неясность концепции. Если бизнес-факторы изменений неясны, сотрудников трудно убедить в необходимости действий по внедрению изменений. Чтобы внедрение получило прочный фундамент, люди должны знать, почему организация должна быть изменена и к чему ведут эти изменения.

 

Технология внедрения и автоматизации. Процесс или инструмент?

В данном разделе расставляются приоритеты над вечным вопросом: что важно, инструмент или методология?

Место систем IBM Rational в ряду корпоративных информационных систем.

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

 

Рисунок 7. Возможные связи IBM Rational со смежными системами

 

На рисунке (см. Рисунок 7) отображена связь между системами заказчика и инструментальными средствами IBM Rational:

  • Системы документооборота, где хранятся все договора, где хранятся контракты, где хранятся нормативные акты, распоряжения высшего руководства и т.д. Любая разработка не может возникнуть из ничего, т.е. причиной проводимых работ должен быть договор или прямое распоряжение и т.д. Что показано на рисунке? На рисунке показан ряд внешних систем, которые должны быть для получения максимального эффекта как-то проинтегрированы, чтобы процесс разработки был прозрачен, можно было взять любую часть, например, исходного кода и понять все первоначальные причины, которые привели к появлению требований, к появлению запроса и т.д.
  • Service Desk. Вся служба поддержки использует отдельную систему, в которой документируются все обращения пользователей. Обращения, которые касаются каких-то софтверных доработок, ошибок, которые автоматически попадают в отдел разработки через интеграцию систем, а результат их обработки автоматически отсылается обратно. Что это дает? Во-первых, обеспечивает единый источник для всех входящих запросов от пользователей системы. Во-вторых, снимает необходимость установки на рабочие места двух систем сразу для обеспечения синхронизации софтверных запросов из среды управления разработкой в среду управления сервисами и обратно.
  • Система SAP. Т.к. с помощью систем IBM Rational ведется управление изменениями, управление требованиями, управление версиями, сбор и публикация метрик, проектное управление, то можно предположить, что большая часть активной деятельности каждого участника проекта так или иначе оставляет следы в этих системах, которые можно замерить, посчитать и конечно «выгрузить». Результаты «выгрузки» можно применить в системе SAP как дополнительный источник данных для модуля управления персоналом при расчете зарплаты и мотивации сотрудников.
  • Внешние организации. Системы IBM Rational предоставляют возможность организации распределенной разработки с помощью своих встроенных средств, т.е. организовать работу филиалов компании или иных подрядных организаций в едином информационном пространстве. Кроме этого, с помощью партнерских решений можно организовать взаимодействие с другими система в случае, если подрядная организация не использует инструменты IBM Rational.

 

Построение прозрачного процесса разработки

На рисунке (см. Рисунок 8) показан набор подсистем Rational и некоторых смежных систем, которые связаны между собой для получения максимального эффекта. В этот набор входят:

  • Системы проектного управления - IBM Rational Portfolio Manager или, возможно, MS Project Server. Система используется для календарного планирования и оценки загрузки персонала.
  • Система управления изменениями - IBM Rational ClearQuest. Здесь регистрируются и отслеживаются задача, дефекты и запросы на расширение.
  • Система версионного контроля - IBM Rational ClearCase. В этой системе находятся все исходные коды проектируемых программных продуктов, документация и т.д., а также используется для ассоциации внесенных изменений исходные коды и документацию с запросами на изменение.
  • Система управления требованиями - IBM Rational RequisitePro. Используется для формирования и отслеживания требований, формирования документов требований.
  • Система тестирования - IBM Rational TestManager, Robot и т.д. Система используется дл написания, запуска и просмотра результатов запуска тестов.
  • Система сервисных служб - HP Service desk. В этой системе регистрируются все запросы от пользователей программных продуктов.
  • Средства разработки ПО, офисные приложения и т.д.

 

Рисунок 8. Интеграция система IBM Rational

 

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

Рассмотрим небольшой пример поэтапной обработки запроса направленного сервисным службам и касающегося проектируемого программного продукта:

1.      Регистрируется новый сервисный запрос в системе Service desk, который классифицируется как софтверный.

2.      Автоматически этот создается в системе управления изменений СlearQuest. На основании этого запроса собрался комитет контроля изменений, на котором принимается решение о его реализации.

3.      Аналитик используя RequisitePro вводит ряд требований, которые необходимы при реализации нового запроса, и ассоциирует их с этим запросом в СlearQuest.

4.      На основании требований с помощью интеграции RequisitePro и MS Project создается базовый календарный план работ.

5.      Далее календарный план работ детализируется и результаты планирования регистрируются в СlearQuest в виде задач на исполнителей.

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

7.      Когда разработка закончена, выполняется тестирование результатов работ. Если возникают ошибки в процессе тестирования, то они документируются в СlearQuest.

 

На картинке ниже (см. Рисунок 9) отображен тот же пример, только немного в другом разрезе - в виде дерева запросов и артефактов, которые появляются в процессе работы над новым запросом. Представим это дерево в последовательности возникновения артефактов:

1.    Новый запрос в Service desk, который определяется как софтверный.

2.    Новый запрос в ClearQuest, который создается автоматический.

3.    Требования по новому запросу.

4.    Детальный план работ, которые основывается на результатах работ по требованиям.

5.    Строки исходного кода в системе версионного контроля.

6.    Тестовые скрипты для тестирования разрабатываемых функциональных возможностей.

 

Рисунок 9. Трассировка и полная прозрачность работ по документированию, обработке и реализации нового требования

 

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

 

Подходы во внедрении.

 

Как правильно и эффективно внедрить новую технологию? Что и в какой последовательности делать? Что сначала внедрить инструмент или процесс? Может сначала установить инструмент и посмотреть, что он может, или описать процесс и потом заняться внедрением инструмента? Это наверно самые частые вопросы, которые могут возникнуть перед проектом внедрения. На рисунке ниже (см. Рисунок 10) отображена так называемая пирамида значимости составляющих процесса, которая поможет ответить на эти вопросы.

 

Рисунок 10. Пирамида значимости процесса

 

Как и при постройке дома, так и при внедрении процесса всегда нужно сначала заложить фундамент, основу, на которой будет держаться все остальное. Фундаментом являются стандарты, т.е. любой процесс внедряется на основе какого-то стандарта или методологии. Обязательно вначале определяются цели и задачи процесса. Далее описываются роли и виды деятельности, которые будут использоваться во внедряемом процессе. Потом определяются метрики и отчеты и только после этого определяются средства реализации, с которыми будут работать участники процесса. Но самое главное, что все это должно стоять на подложке осознания необходимости внедрения и политической воли руководства, т.к. если не будет этих составляющих, то добиться максимального эффекта от проводимых работ не получится. Т.е. даже если сам проект внедрения пройдет удачно, то добиться чтоб новые технологии полноценно применялись участниками процесса и давали положительный эффект в реальной работе будет сложно.

После того как уже определено в какой последовательности будет выполняться внедрение, станет вопрос: что и какую методологию внедрять? Можно конечно применять RUP, MSF или любую другую методологию, но кто гарантирует, что она «ляжет» и не будет противоречить сложившимся процессам, культуре производства организации? Поэтому, если говорить о внедрении какого-то процесса, то лучше говорить о его адаптации к выбранной организации, т.е. выполнять внедрение процесса адаптированного под потребности организации.

Рисунок 11. Составляющие внедрения

 

Для того чтоб получить работающий в организации процесс, мы используем следующие компоненты (см. Рисунок 11):

1.      За основу выбирается методология RUP.

2.      Помимо методологии используются стандартные процессы жизненного цикла, допусти, ISO 12207.

3.      Конечно же, неплохо, чтоб результирующий процесс отвечал каким-то требованиям, поэтому к нему можно применить модель качества процессов CMMI.

4.      Можно также при необходимости применить следующие компоненты:

1)     Отраслевые стандарты, если внедрение происходит в отраслевой организации.

2)     ГОСТы, также если это необходимо.

 

В результате получается некая адаптация, т.е. процесс, который включает те работы и задачи используемых методологий и стандартов, которые свойственны выбранной организации, плюс описание уникальных для этой организации работ. И такая адаптация уже применятся на организацию. Существует два типа внедрения горизонтальное и вертикальное (см. Рисунок 12):

  • Горизонтальное внедрение. При этом типе внедрения выбирается один небольшой внутренний проект и на него применяются все дисциплины, которые внедряются, т.е. управление проектом, моделирование, управление требованиями и т.д. После удачного завершения внедрения технологий выполняется анализ результатов, если необходимо, корректировка процессов и далее эти же дисциплины применяются на подразделение. И последним шагом выполняется внедрение процессов уже в целом на организацию. Этот метод не очень оптимален, т.к. применение всех технологий на одном малом проекте слишком дорогое удовольствие.
  • Вертикальное внедрение. Это тип внедрения, в котором выбирается одна дисциплина, допустим управление проектом, и применяется на всю организацию. После внедрения первой дисциплины, выбирается вторая и также внедряется на всю организацию и так до тех пор, пока все дисциплины не будут внедрены.

 

Рисунок 12. Горизонтальное и вертикальное внедрение

 

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

 

Почему RUP?

Почему используется RUP? На самом деле RUP используется в качестве той методологии, которая позволяет в широком диапазоне менять степень формализации и итерационности процесса. RUP покрывает все, RUP можно адаптировать под водопад, RUP можно адаптировать под итерацию. Т.е. к RUP необходимо относиться как к методологии, которую можно в широком спектре адаптировать и гибко менять. Методик в принципе много, это Agile, Scrum, XP, MSF и т.д. и все они покрываются с помощью RUP. Например, MSF и RUP говорят об одном и том же, но разными словами. Если необходимо использовать Agile, то в зависимости от того, какой тип проекта, можно выбрать тип формализации в RUP и «отсечь» все ненужное.

 

Рисунок 13. Спецификация Software Process Engineering Metamodel

 

Спецификация Software Process Engineering Metamodel (см. Рисунок 13) описывает структуру RUP. То есть в RUP есть стадии, жизненный цикл, процессы, они же дисциплины, которые состоят из работ. Работы в свою очередь состоят из задач. Задачи выполняют определенные роли. На выходе и на входе подаются какие-то артефакты. Есть инструментальная поддержка и шаблоны. Многие боятся RUP, говорят то, что внедрением в RUP заниматься не целесообразно, потому что он очень большой, сложный и для нашей организации не подходящий. Но это не так, потому что RUP как энциклопедия всех лучших практик и методик. И использовать все конечно не стоит, необходимо выбрать только то, что подходит организации. Поэтому и RUP поставляется изначально в двух вариантах - для больших и малых проектов. В таблице ниже (см. Таблица 5) представлены количественные показатели RUP.

 

Таблица 6. Сравнительный анализ количественных показателей RUP для проектов разного масштаба

 

RUP для небольших проектов

RUP для больших проектов

Дисциплин

9

9

Задачи

68

160

Роли

26

6 типов, 35 подтипов

Рабочие продукты (артефакты)

50

10 типов, 105 продуктов (артефактов)

 

Ниже (см. Таблица 6) представлен еще один пример, в котором выделена одна дисциплина «Управление конфигурацией» для «небольшого» и для «большого» RUP. В таблице можно увидеть, что есть основные задачи, которые применяются в дисциплине и присутствуют в «коротком» Rational Unified Process и в «длинном» RUP. И в свою очередь присутствуют задачи, которые рекомендуются для применения только в «больших» проектах.

 

Таблица 7. Состав задач дисциплины RUP «Управление конфигурациями» для проектов разного масштаба

Наименование Задачи

RUP для небольших проектов

RUP для больших проектов

Подтвердить повторный или отклонённый запрос на изменение

Да

Да

Создать базовые версии

Нет

Да

Создать единицу развертывания

Нет

Да

Создать рабочие пространства разработки

Нет

Да

Создать рабочие пространства интеграции

Нет

Да

Применить изменения

Нет

Да

Наладить процесс управления изменениями

Нет

Да

Установить политику управления конфигурацией (УК)

Нет

Да

Внести изменения

Нет

Да

Провести аудит конфигурации

Нет

Да

Продвигать базовые версии

Нет

Да

Создать отчёт о состоянии конфигурации

Нет

Да

Рассмотреть запросы на изменения

Да

Да

Настроить среду управления изменениями

Да

Да

Внести запрос на изменение

Да

Да

Обновить запрос на изменение

Нет

Да

Обновить рабочее пространство

Нет

Да

Подтвердить изменения в сборке

Нет

Да

Написать план управления конфигурацией (УК)

Нет

Да

 

Такие же тенденции (см. Таблица 7) прослеживаются и в отношении ролей процессов в RUP для проектов различных масштабов.

 

Таблица 8. Состав ролей  RUP для проектов разного масштаба

Тип роли

Роль

RUP для небольших проектов

RUP для больших проектов

Аналитики

Бизнес архитектор

Нет

Да

Бизнес проектировщик

Нет

Да

Аналитик бизнес-процессов

Нет

Да

Ответственный за спецификацию требований

Да

Да

Инвестор

Да

Да

Системный аналитик

Да

Да

Разработчики

Системный архитектор

Нет

Да

Разработчик базы данных

Да

Да

Разработчик

Да

Да

Конструктор

Да

Да

Интегратор

Да

Да

Программный архитектор

Да

Да

Разработчик пользовательского интерфейса

Да

Да

Общие роли

Любая Роль

Да

Да

Координатор рецензирования

Да

Да

Рецензент

Да

Да

Инвестор

Да

Да

Технический рецензент

Да

Да

Менеджеры

Менеджер по управлению изменениями

Да

Да

Менеджер конфигурации

Да

Да

Менеджер развёртывания

Нет

Да

Рецензент менеджмента

Да

Да

Менеджер проекта

Да

Да

Системный администратор

Да

Да

Менеджер тестирования

Да

Да

Производство и поддержка

Разработчик курса

Нет

Да

Графический художник

Нет

Да

Инженер процессов

Да

Да

Системный администратор

Да

Да

Технический писатель

Нет

Да

Специалист по инструментам

Нет

Да

Тестеры

Аналитик тестов

Да

Да

Разработчик тестов

Да

Да

Тестер

Да

Да

Менеджер по тестам

Да

Да

 

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

Кроме того, также как и IT-технологии, RUP как методология постоянно совершенствуется. Из года в год появляются некоторые новые методы, улучшаются и оптимизируются старые на основе их применения в реальных проектах. Возьмем, к примеру, задачу «Create Project (CM) Environments» (см. Рисунок 14) из дисциплины «Управления конфигурациями». Т.е. изначально в ней принимало участие три роли и использовалось четыре артефакта. Прошло пять лет,  RUP немного упростился, некоторые позиции были удалены или изменены, потому что в проектах на практике их никто не использовал или использовал частично (см. Рисунок 15). В результате адаптации в реальном проекте получается задача, которая немного отличается от описанной в RUP (см. Рисунок 16).

 

Рисунок 14. Задача «Create Project (CM) Environments», оригинальный RUP 2001 год.

 

Рисунок 15. Задача «Create Project (CM) Environments», оригинальный RUP 2007 год.

 

Рисунок 16. Задача «Create Project (CM) Environments», один из вариантов адаптации.

 

Роль пилотных проектов во внедрении

 

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

  • Определение пилотных проектов, которые могут использовать выбранные процессы. Данные пилотные проекты должны быть выбраны на основе приоритетных работ, которые с высокой вероятностью приведут к значительному улучшению результатов и от которых ожидают быструю реальную отдачу.
  • Выбор группы добровольцев для сопровождения пилотных проектов с последующим пропагандированием и вознаграждением их усилий.
  • Обучение всех вовлеченных в процесс. Повышению знаний обучаемых можно способствовать путем регулярного уведомления их о развитии процесса внедрения в дополнение к официальным курсам обучения.
  • Планирование пилотных проектов и определение критических факторов достижения успеха.
  • Включение выбранного адаптированного процесса в план управления проектом для каждого пилотного проекта.
  • Реализация пилотного проекта, отслеживание и документирование хода его выполнения по критическим факторам успеха реализации. Навыки документирования осваивают в ходе пилотного проекта(ов). Полученные уроки должны быть учтены при совершенствовании процессов.

 

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

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

  • Подтвердить достоверность результатов оценки и выбора.
  • Показать, действительно ли технология годится для использования в данной организации;
  • Представить информацию, необходимую для разработки плана практического внедрения;
  • Помочь пользователю приобрести собственный опыт использования технологий.

 

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

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

 

Заключение

 

Экономическое обоснование - это основное требование к любому проекту, которое ставиться перед его выполнением. Если нет экономической выгоды, то какой смысл производить какие-то изменения, внедрять новые технологии? В данной статье мы попытались показать один из методов подсчета экономического эффекта при внедрении новых технологий на основе продуктов IBM Rational, который основывается на уменьшении издержек на выполнение основных операций и автоматизации часто повторяющихся работ. Однако следует понимать, что подсчеты, выполненные на бумаге перед проведением проекта, - это одно; выполнение работ на практике для того, чтоб подтвердить выполненные расчеты, - это уже более сложная задача. Достижение поставленных целей зависит от многих факторов, но можно выделить несколько главных: готовность самой организации к изменениям, т.е. осознание руководства и сотрудников компании, что эти изменения нужны, и политическая поля руководства при проведении проекта внедрения, выделение этого проекта как приоритетного внутри организации. Адаптация процесса - это еще один ключ к его успеху. Адаптация основана на использовании давно зарекомендовавших себя методологий, таких как RUP, в виде основы процесса с применением к ним стандартов процессов и моделей качества. Адаптация позволяет не использовать весь набор описанных в методологии методов и задач, а выбирать только те, которые наиболее важны и актуальны для организации, в которой применяются новые технологии, что позволяет повыситься экономическую эффективность от внедрения. Использование пилотных проектов позволит «обкатать» новые процессы без применения их во всей организации, что позволяет уменьшить возможные потери и издержки, которые могут возникнуть в случае, если что-то сначала пошло не согласовано.


23.12.2009

Комментарии

  • Могут отчислить из за реферата
    Автор:   ·  07.04.2017 20:46:15
    Я скачал с сайта http://delayreferat.ru/ себе реферат, информация в реферата содержала кучу ошибок, в итоге я опозорился не получил зачет теперь надо мной висит угроза отлисления. Владельци сайта редкасные мудаки.

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО: 
E-mail: 
Тема: 
Комментарий: 
Оценка:   
 
 
 
 
 
Код подтверждения:
   

Новости СМ-Консалт

Мастер-класс для тренеров и руководителей "Работа в аудитории". 1 ступень уже в марте

Обновлено расписание тренингов до марта 2017 года

Бесплатный вебинар 14 декабря в 14 00 по Мск - «Секреты управления ИТ-командой: 10 важных практик, которые сделают команду эффективной»

Новые статьи в библиотеке

Примеры отраслевых решений на основе BIPULSE

Практика реализации модуля интеграции для Rational Software Architect, позволяющего преобразовывать низкоуровневое представление процесса из IBM Rational ClearQuest в UML

Что удивляет в русских менеджерах иностранцев

Разработка ПО с использованием лучших мировых практик и инструментов на Иркутском авиационном заводе

Презентация доклада для IT Global Meetup Санкт-Петербург: "Почему Agile так популярен? Взгляд циника и психолога"

Отчет, презентация и видео доклада для Октябрьской встречи Петербургского клуба менеджеров проектов в IT - SPM Meetup #36

Заказчики и истории успеха

Наши тренинги, семинары, курсы

Дружите с нами на FaceBook

Проверить настройки
Компания
Сделано в СМ-Консалт
Услуги 
Компетенция
  • CMC-TotalTest (скоро)
    уникальная разработка автоматизации функционального тестирования. Альтернатива HP UFT, IBM RFT и Microsoft!
  • CMC-Bisquiter
    автоматизированное тестирование АБС "Бисквит"
  • CMC-Formater
    тестирование печатных и экранных форм
  • CMC-TerminalTest
    тестирование терминальных приложений
  • ProjectTracker
    интеграция ALM и MS Project
  • GanttChart
    модуль управления проектами для IBM Rational ClearQuest и TeamConcert
    Все разработки СМ-Консалт >
  • ИТ-консалтинг
  • Автоматизированное тестирование
  • Ручное тестирование
  • Аутсорсинг тестирования
  • Оптимизация бизнес-процессов
  • Внедрение методологии и инструментов ALM
  • Обучение и коучинг
  • Разработка ПО
  • Интеграция
ООО СМ-Консалт (СМК), 2004-2016.
Карта сайта