“… british scientists proved…”
Привет, Хабр. Меня зовут Сергей Сапегин, я работаю PHP-разработчиком в DataArt. Но сегодня я хочу поговорить не о PHP.
Работники IТ, вне зависимости от области специализации, в последнее время все чаще сталкиваются с интересным феноменом мира ПО — ITIL. Поскольку общемировая тенденция не миновала и DataArt, мы предприняли небольшое исследование, дабы понять, что и как следует знать нашим разработчикам, чтобы некоторые процессы заказчиков не ставили в тупик всю команду. Представляем вам, что из этого получилось…
Куда девается софт?
Производя разнообразные фичи и исправляя многочисленные баги, доводя разрабатываемые компоненты до уровня релиза мы, как правило, не задумываемся, куда это все потом девается. Фактически, софт для нас — нечто, лежащее на
Большинство методик и приемов, направленных на достижение качества ПО, вытекают из этого взгляда на мир. Безусловно, стройная архитектура, объектный подход, MVC, соглашения об оформлении кода и комментарии… Мы так много уделяем этому внимания, что совершенно непонятно, откуда вылезают очередные уродливые чудовища, которые так дороги пользователям, что обязательно надо привести их в порядок. Красота должна была давно уже править миром.
И, говоря откровенно, она правит. В мире существуют миллионы разновидностей прекрасного, очаровательного, вдохновляющего ПО! Другое дело, что мы, разработчики, оцениваем красоту программных изделий по большей части со своей профессиональной точки зрения, примерно также, как
Как же нам прикоснуться к этому непростому взгляду всего мира? Мир уже нашел способ привести красоту IT к стандарту — он предлагает нам ITIL!
Идея британской короны
Как заставить программистов писать не просто качественный, но полезный для пользователей софт? Много кто пытался ответить на этот вопрос, но наиболее успешный результат пока получился у британского правительства. Идея, положенная в его основу, была довольно простой: собрать информацию по достаточно большому количеству проектов, выделить среди них успешные и неуспешные, разбить по критериям, извлечь из этого набор правил. А проектов автоматизации различных организации у оного правительства уже накопилось хоть отбавляй.
Собралась группа экспертов (предварительно пообещав всем раздачу розовых слонов), тщательно обработала статистику — и возникла библиотека ITIL. Сейчас она становится все популярнее, пережила уже третью инкарнацию (самая свежая и популярная версия — ITIL V3), а самое главное — она, по сути, объясняет, что пользователю нужно, как ему организовать эксплуатацию всей его IT-инфраструктуры, как оценить, что приносит пользу, что вредно, а что бесполезно. Самое пикантное, что оценка работает вне зависимости от того, действительно ли пользователь знает свои реальные желания, может или нет их сформулировать. Если он, конечно, вообще заинтересован в использовании IT в своем бизнесе.
Основа ITIL
Первое, с чего начинается знакомство с ITIL, — общие понятия и термины, которые могут весьма отличаться от ожиданий. Сама ITIL — библиотека (сборник) рецептов, применимых для организации процесса эксплуатации IT. Способ управления организацией IT-услуг на основе рецептов этой библиотеки называется ITSM (IT Service Management). Библиотека 3-й версии (ITIL v3) состоит из нескольких основополагающих книг, освещающих последовательно вопросы организации различных сфер работы с IT-инфраструктурой предприятия.
Ключевое понятие ITIL, на базе которого разворачивается вся остальная идеология, — понятие сервиса. В ITIL v3 сервисом называется «способ предоставления заказчику ценностей (values), очищенных от рисков и затрат, присущих действиям, по получению этих результатов» (A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks). Обратите внимание, что под ценностями в контексте работы организации, как правило, подразумевается достижение работником каких-либо промежуточных целей в процессе выполнения своих профессиональных обязанностей. Это определение достаточно сильно отличается от того интуитивного понятия «сервиса», которое присуще разработчикам. (Имеется в виду «развернутый в сети набор функциональности, который можно использовать»).
Сервис ITIL — это:
- Не только и не обязательно набор программной функциональности. Грубо говоря, мы постоянно считаем новую модель ружья способом охоты. Хотя на деле, чтобы оно было способом, его надо распаковать, пристрелять, зарядить, доставить на место, направить на цель и дать в руки охотнику. Все это, с точки зрения ITIL, — составные части сервиса.
- Способ предоставления заказчику ценностей. Разработанный софт используется пользователем не потому, что его легко и удобно использовать, он имеет тщательно продуманную архитектуру и т. д., а потому, что он доставляет пользователю ценности, причем набор этих ценностей ограничен рамками производственного процесса, категориями которого и мыслит пользователь. Проверьте себя, ответьте, какой алгоритм сортировки лучше — традиционный «пузырек» или Quicksort? А если речь идет не более чем о десяти элементах? А если он нужен вообще чтобы объяснить человеку принцип сортировки?
- «…очищенных от рисков и затрат» — тоже важное дополнение. Всю производительность разработчиков, которую так трудно определить и нормировать с точки зрения процесса разработки, пользователь оценивает со своей точки зрения по одной простой и безотказной шкале — очищенности своего рабочего процесса от рисков и трудозатрат. Давно ли вы сами писали гневные сообщения на форумах об отсутствии кнопки «Пуск» в новой версии Windows? Задумывались ли тогда о несомненных улучшениях в функциональности и надежности этой ОС? Часто ли вы входите в положение сервисных служб, когда у вас падает интернет или отключают электричество?
Получается, как у поэта: мы говорим «ITIL» — подразумеваем «сервисы», говорим «сервисы» — подразумеваем «доставленные ценности, очищенные от рисков и затрат».
Структура и место ITIL
В качестве иллюстрации той области, которую охватывают методики ITIL (а конкретнее — ITIL 3), можно посмотреть на следующую картинку:
Основная задача ITIL, таким образом — извлечение выгоды для рабочего процесса из существующей инфраструктуры. Однако, поскольку существующего в реальности никогда не бывает достаточно, процессы ITIL охватывают область формирования требований к новому ПО и включают процессы его приемки, тестирования и ввода в эксплуатацию.
Структура ITIL в 3-й редакции состоит из пяти основополагающих книг и выглядит таким образом:
Рассмотрим их содержание подробнее…
Service Design
Книга, посвященная проектированию сервисов, детализирует принципы, которые должны использоваться при грамотном развитии IТ-инфраструктуры. В процессе проектирования сервисов, помимо всего прочего, определяется потребность в новом ПО, определяется набор первоначальных требований к нему, выбирается исполнитель — и тут уже в дело вступают разработчики. Выбор исполнителя и характер проекта обычно определяется путем нахождения баланса между:
- функциональностью сервиса (бизнес- и системной);
- его стоимостью (включая финансовые, производственные и кадровые ресурсы);
- временем, за которое надо запустить сервис в эксплуатацию.
Кроме требований к ПО, при проектировании сервиса обычно прорабатываются вопросы запуска его в эксплуатацию, дальнейшего управления и т. д. Сам процесс проектирования обычно организуется на основе матрицы RACI (Responsible, Accountable, Consulted, Informed), согласно методу которой, участие каждого участника в задаче может быть следующих типов:
- Responsible – участник может участвовать в работе над задачей.
- Accountable — ответственный за задачу (только один на каждую).
- Consulted — участвует в работе в качестве консультанта.
- Informed — должен следить за ходом работ и получать информацию о прогрессе.
В более специфичных случаях используют расширенную матрицу RACI-VS, в которой добавляются следующие роли:
- Verifies — человек или группа людей, проверяющих соответствие результатов работы заданным критериям.
- Signs off — человек, фиксирующий достижение цели и принимающий решение о выпуске продукта (роль совместима с ролью A).
Существует еще одна вариация этой матрицы, т. н. RASCI, в которой предусмотрено наличие роли Supportive — для людей, обеспечивающих поддержку основного потока работ.
Service Transition
Собственно говоря, обычно мы достаточно мало знаем об ITIL еще и потому, что библиотека никак не формализует сам процесс разработки. Для нас он предстает в виде Agile, водопада или еще чего похитрее, а с точки зрения пользователей это — черный ящик, куда кладутся требования, что-то там внутри шуршит и работает – и на выходе выезжает
Основная цель процесса передачи сервисов — развертывание и введение в эксплуатацию новых версий сервисов в общей информационной среде предприятия. Основа процесса — обычно формальное соглашение, составленное в документальном виде и используемое во всех случаях ввода сервиса в эксплуатацию. Важность этого связана, прежде всего, с тем, что процесс некорретного ввода сервиса в эксплуатацию может принести серьезные убытки эксплуатирующему его предприятию. Почему я подчеркиваю этот факт? Для нас обычно ценна именно функциональность ПО, то, что мы делаем: алгоритмы, структуры таблиц БД. А для пользователя наибольшую ценность представляют ДАННЫЕ. В руках у пользователя структуры данных заполняются не абстрактными “123”, “test”, “privet”, “helloworld”, “test again”, а вполне конкретными фактами из реальной жизни, имеющими значение (выражаемое в деньгах!) для деятельности компании. А поскольку, как я уже говорил выше, софт всегда приходит на смену чему-либо, проблемам адаптации старых данных под новые модели следует уделять самое пристальное внимание. По возможности – с самого начала разработки, а не когда уже сделали готовое изделие.
Когда разработанное ПО запускается в эксплуатацию, интересы пользователя уязвимы больше всего: он доверяет вашему продукту самое ценное, что у него есть – ИНФОРМАЦИЮ.
Передача ПО в эксплуатацию обычно сопряжена с несколькими этапами тестирования, часто связана с использованием каких-либо технических средств, регламентирующих процесс (CI – continuous Integration), а результат ее… тут де-факто есть небольшое расхождение результатов.
Для разработчика конечные результаты — подписанный акт о передаче и финальный платеж.
Для заказчика конечный результат — факт использования программного средства по назначению. Совместное достижение этих результатов и есть желаемый итог проекта. Многие сейчас подумали о вариантах, когда «разработчик сдал программу и исчез, а пользователь с ней мучается и не может толком работать» — справедливости ради, есть и другие варианты, когда «пользователь поставил старую версию и работает, а всякие левые баги не замечает, от новых фич отказывается». Оптимум — где-то посередине.
Главная задача организации процесса передачи сервисов — избежание затяжных антагонистических конфликтов между командами, причины которых — непонимание и, скорее всего, различные корпоративные интересы. Для предотвращения и решения конфликтов используются и формальные документы (SLA, ТЗ и т.д.), и неформальные инициативы, направленные на устранение непонимания и расширение общего понятийного контекста между группами разработки и эксплуатации сервисов.
Service Operation
«Использование сервисов» — внутреннее чтиво наших клиентов, из которого, однако, можно почерпнуть немало полезного. С нашей точки зрения особый интерес представляет не сам комплекс методов организации работы пользователей с IТ-обеспечением, а его выходные регламенты и документы.
Например, улыбку могут вызвать регламентированные рецепты обхода багов, которые разработчики так и не удосужились исправить. Однако главная цель анализа информации о реально происходящем в компании во время ее работы — понять, насколько внедренное ПО было удачным, насколько оно полезно, где у него есть узкие места… где есть узкие места в работе сотрудников компании вообще (и что мы можем сделать за деньги, чтобы это исправить).
Книга в целом интересная и полезная, в особенности в части понимания, где как и что из IТ-обеспечения используется в реальной работе.
Continual Service Improvement
Последняя книжка ITIL 3-й версии посвящена организации саморефлексии — отслеживания, какие процессы идут в организации, попыток улучшения качества используемых сервисов. Самый главный постулат книги — процесс усовершенствования корпоративной ИС должен проходить постоянно и непрерывно. Ну, а методики, используемые для этого, могут быть чрезвычайно разнообразны.
Например, широко используются различные способы измерения технической производительности IТ-сервисов, эффективности их работы во взаимодействии с пользователем, способы общей оценки работы сервисов, фазы их жизненного цикла и т. д. (цикл Деминга и матрица SWOT).
Знание принципов CSI позволяет анализировать, что происходит в IТ-инфраструктуре наших клиентов, подсказывать им решения, завоевывать доверие и делать предложения, от которых трудно отказаться. Естественно, если организация-заказчик регулярно делится данными постоянного мониторинга своей IТ-инфраструктуры.
В итоге?
Все это, конечно, занятно (хотя и несколько умозрительно), но зачем разработчику-практику знать об этих низменных, юзерских концепциях? Наше дело — заботиться о качестве кода!
Может быть, оно так и должно быть, но практика показывает иное. Большинство холиваров о «прямых руках» и «кривых архитектурах» пользователю безразличны. Более того, между пользователями и разработчиками, оказывается, существует действительно большое пространство, успешно пересечь которое под силу не каждому программному продукту. И, как мне кажется, пора задуматься, как дать своему программному детищу больше шансов стать полезным для конечного пользователя. А помочь в этом может взгляд на разработку с позиции ITIL.
