Решение по управлению разработкой
Главная / Решения / SBM для ИТ / Решение по управлению разработкой

Решение по управлению разработкой

Среди множества процессов управления ИТ деятельностью разработка и развитие программного обеспечения стоит особняком по ряду причин. Во-первых, в том или ином объеме управлять разработкой нужно практически всем компаниями, а не только профессиональным разработчикам. Во-вторых, существует огромное количество методологий, технологий и инструментов, «гарантирующих» решение большинства проблем разработки. В-третьих, требования к качеству работы у всех разные - где-то достаточно, чтобы все просто работало, где-то нужно отчитываться по ключевым показателям KPI и степени достижения целей проекта.С чем действительно сложно не согласиться, так это с тем, что разработка программного обеспечения - это процесс. И подходы к эффективному управлению разработкой нужно искать в области управления процессами или Business Process Management (BPM).

 

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

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

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

Если Вы хотите навести порядок в ИТ своей компании, начните с процесса Управления Изменениями. Это всегда дает быстрый положительный эффект. Как далеко вы зайдете в совершенствовании процесса, зависит только от Вас. Мы же хотели бы остановиться на наиболее существенных аспектах возможного совершенствования.

Выделение дополнительных процессов

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

Среди кандидатов на самостоятельный процесс в ИТ деятельности часто выделяют:

    Управление Формулярами или Релизами. Ответственный Исполнитель, завершая разработку и передавая следующему подразделению объект на тестирование, должен передать результат своего труда и, желательно, уведомить всех заинтересованных участников о завершении одного этапа и переходе ответственности за объект к другому специалисту. Этот результат часто называют Релиз, который обычно должен сопровождаться формуляром. Причем интеграция с системой контроля версий часто вовсе не обязательна, хотя бы потому что, не всякий результат разработки можно сохранить в среде версионного контроля исходных файлов. Есть возможность - отлично! Нет возможности - процесс должен работать и без этого. Если процесс внедрения Изменений в промышленную эксплуатацию подразумевает определенный документооборот, необходимость получения разрешений и различных согласований на установку, подписание акта у бизнес подразделения, «заказавшего» изменение, то стоит рассмотреть выделение этого процесса в отдельное приложение.
    Управление Замечаниями, дефектами, вопросами. Процесс, протекающий между тестировщиками и разработчиками, носит явно выраженный повторяющийся характер, где важно не потерять ни одного замечания, эффективно управлять коммуникациями, включая прикрепление переписки, добавление примечаний, прикрепление файлов, изменение ревизий файлов, но также и контролировать сроки. Существует великое множество решений, автоматизирующих этот процесс. Такой класс систем часто называют Bug Trackers.
    Управление Инцидентами или жалобами. Некоторые изменения появляются в результате обнаруженных при эксплуатации ИС дефектов. Конечный пользователь обращается с жалобой в службу технической поддержки, или сервис деск, или хелп-деск, и просит помочь в решении проблемы. Поскольку далеко не все жалобы пользователей объективно требуют немедленного привлечения высококвалифицированных специалистов, имеют разный приоритет и важность для бизнеса и могут являться следствием какой-то одной крупной проблемы, то, как правило, обработку Инцидентов выделяют в отдельный процесс. В сегменте систем управления инцидентами есть хорошо зарекомендовавшие себя «тяжелые» решения от HP, Remedy, которые являются стандартами де-факто в крупных финансовых и промышленных компаниях. Также процесс управления инцидентами очень подробно рассмотрен в ITIL. Как следствие может потребоваться интеграция между различными системами для организации взаимодействия процессов управления Инцидентами и процессом управления Изменениями. Если внешней системы Управления инцидентами нет, то будет эффективно реализовать его на одной платформе с решением для Управления Изменениями.
    Управление каталогом услуг. ITSM предполагает переход к ориентированному на сервис взаимодействию бизнес подразделений и ИТ. Такой «переход» может сам по себе стоить немалых инвестиций в консультационную составляющую разработки сопутствующих регламентов, требований, системы показателей и системы мотивации и т.д. А может оставаться лишь на уровне списка услуг, позволяющего систематизировать запросы и собирать статистику.
    Управление инфраструктурой - еще одна болевая точка управления ИТ деятельностью. Проблематика лежит на поверхности. Реализованные Изменения при внедрении могут сопровождаться определенными изменениями в инфраструктуре, например, обновить версию операционной системы, выделить дополнительное дисковое пространство, добавить оперативную память, открыть TCP/IP порты на файрволе и т.д. До внедрения Изменений на одном и том же сервере могли мирно существовать несколько бизнес приложений. Если не контролировать процесс внедрения Изменений с точки зрения совместимости с другими приложениями, то в результате получим как минимум вал жалоб и «конструктивных предложений по поводу работы ИТ». С точки зрения рекомендаций ITIL данная область относится к управлению конфигурационными единицами и ведению CMDB. Лидером среди поставщиков информационных систем в этом сегменте заслуженно считается HP. Однако продукт далеко не всем доступен по цене, а нужно еще учитывать стоимость внедрения и владения. Кроме того, есть опасность так увлечься моделированием и автоматизацией CMDB, что в какой-то момент совершенно потерять практический смысл всей деятельности - ведь важен не сам каталог серверов и версий системного ПО, а его связь с изменениями, инцидентами, релизами и т.д. На платформе Serena Business Mashups есть «тяжелые» решения реализации CMDB - IT Symphony компании Change Dynamics. Если это не ваш путь, то свой CMDB можно получить эволюционно по мере внедрения справочников CMDB и процессов управления инфраструктурой.
    Управление потребностями. Как только процесс управления запросами на изменение достигнет определенной степени зрелости, появится необходимость планирования сроков, очередности, финансовых затрат на каждый запрос. Появляются новые требования к соответствующему документообороту, контролю сроков, квартальному анализу результатов, бюджетированию, вовлечению в процесс представителей бизнес подразделений. Таким образом, эволюционно появляется новый информационный объект - потребность бизнеса. Потребность может привести к необходимости реализации определенных Изменений, а возможно и нет, например, бизнес откажется от своего запроса в силу изменившихся обстоятельств.

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

Выбор платформы:

С уверенностью можно сказать, что идеального решения для автоматизации всех процессов управления ИТ деятельностью не существует. Кроме того, необходимо учитывать текущее состояние зрелости процессов предприятия. Есть признанные лидеры в отдельных областях, есть относительно универсальные платформы. Мы используем и рекомендуем в качестве такого инструмента платформу Serena Business Mashups потому что:

    • Продукт ориентирован на Процесс и относится к классу Business Process Management, являясь универсальным инструментом для различных предметных областей. Создавая свое решение на платформе, Вы, прежде всего, отталкиваетесь от процесса, моделируя его в графическом редакторе. Процессы можно связывать друг с другом и на уровне данных и на уровне потоков работ.
    • Это современный технологический Продукт. Масштабируемый, гибкий, быстрый, без ограничений на количество приложений и пользователей, с поддержкой стандартов SOAP, позволяет строить современные решения для компаний любого масштаба и вписываться в сложные условия действующей инфраструктуры предприятия.
    • Это хорошо зарекомендовавшая себя платформа с историей развития более 15 лет. Если надежность и успешность производителя, наличие внедрений в России и за рубежом для Вас не пустой звук, то нам есть, что рассказать о Serena Business Mashups.
Критерии ITSM

Состав одного из наших решений:

В решении реализованы следующие связанные процессы:

  • Управление изменениями (Change management)
change request
  • Управление релизами (Release management)
Release Management

 

  • Управление замечаниями (Defect Tracking)
Defect and Issue Management

 

  • Управление внедрением (Deployment management)
Deployment management
  • Управление каталогом услуг
Service Catalog Management

 

Модель взаимодействия процессов:

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

На рисунке представлены основные сценарии обработки Заявки, Формуляра и Ведомости доработок в проекции на шкалу времени с указанием состояний взаимодействия процессов, параллельного течения процессов и их синхронизации:

В момент перехода Заявки в состояние «Ожидание тестирования» создается новый объект Формуляра в состоянии «Новый формуляр». Далее объект Заявка полностью управляется объектом Формуляр;

При переходе Формуляра в состояние «Первичное рассмотрение» соответствующая Заявка меняет состояние на «ПСИ»;

При переходе Формуляра в состояние «Внедрение» соответствующая Заявка меняет состояние на «Пром. эксплуатация»;

При переходе Формуляра в состояние «Закрыто» соответствующая Заявка меняет состояние на «Внедрено»;

Записи Ведомости доработок могут создаваться, когда Формуляр находится в состоянии «Тестирования» При этом формуляр меняет состояние на «Ожидание исправления»;

Формуляр может изменить состояние на «Тестирование завершено» только тогда, когда все Записи ведомости доработок будут закрыты; 

Process Management