Управление ИТ

Методология agile приобретает все больше сторонников в корпоративной среде, но ряд заблуждений еще остаются – и хуже всего то, что они сохраняются у ИТ-руководителей. И эти стойкие заблуждения мешают более широкому распространению методологии.

Заблуждение 1: Методология agile вносит сложности в бюджет

Как рассказывает Джон Дусет, вице-президент по консультационной деятельности компании Magenic – поставщика заказного программного обеспечения, ИТ-директора весьма далеки от того, чтобы корректировать бюджеты капитальных затрат с учетом agile-проектирования.

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

«Вряд ли ИТ-директору понравится годовой бюджет ИТ-службы в размере 25 млн долл., из которых 15 млн долл. приходится на незавершенную разработку ПО, – подчеркнул Дусет. – Массовый переход на методологию agile можно только приветствовать, но, поскольку бюджеты по-прежнему верстаются исходя из методологии водопада, возникает много трудностей с продуктами и бюджетированием,. Для реального ускорения необходимо внедрять agile-подход, причем в отношении как мэйнфреймов и унаследованных приложений, так и современного ПО и новых продуктов».

Заблуждение 2: Переход к agile-методологии проводится по указанию сверху

«Я не раз сталкивался с ситуацией, когда ИТ-директор из компании, входящей в список Fortune 500, прочитав статью об agile-разработке, сразу загорается этой идеей, – говорит Мэнни Гонсалес, генеральный директор компании Scrum Alliance. – После того как соответствующее указание доходит до одного из ИТ-менеджеров, вызывают нас, приглашают нашего консультанта и пытаются проводить необходимые преобразования. Но это не agile-подход – это указание, исходящее сверху. Мы ощущаем разрыв в знаниях и определенное сопротивление: люди просто не понимают принципов методологии, которую предстоит внедрить в масштабах всей организации».

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

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

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

Заблуждение 3: Переход к agile-методологии прост

«Существует ошибочное представление о том, что переход к agile-методологии прост, – указывает Дэйв Уэст, владелец ресурса Scrum.org. – Принципы и постулаты agile-проектирования легки для понимания, но их сложно реализовать на практике. Необходимо полностью поменять в организации менталитет всех сотрудников снизу доверху, изменить их подход к выстраиванию своей карьеры, к оценке своей работы и своей роли».

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

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

– Sharon Florentine. 3 misconceptions CIOs have about agile. CIO. Apr 25, 2016

Неточность и неполнота данных отрицательно сказываются на бизнесе. Опрос 200 ИТ-директоров и представителей высшего руководства крупных предприятий, проведенный специалистами компании 451 Research, показал, что данные, не соответствующие стандартам качества, типичны для многих организаций. И объясняется это отрывом ИТ-директоров от отраслевых менеджеров. Одновременно возрастает роль директора по данным (chief data officer, CDO), который становится связующим звеном между ИТ-директором и бизнес-менеджерами и отвечает за качество данных.

«Только 40% руководителей высшего звена твердо уверены в качестве данных своей организации», – поясняется в отчете об исследовании 451 Research, которое выполнялось по заказу компании Blazent, поставляющей интеллектуальные платформы для сбора и обработки данных. Вместе с тем 94% ИТ-руководителей согласны с тем, что низкое качество данных снижает результаты бизнеса, приводит к потере доходов и принятию неверных стратегических решений.

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

Большие Данные + большие проблемы = большая головная боль

Компании TD Ameritrade, Navistar и Merck Animal Health занимаются интеграцией данных и управлением ими в интересах бизнеса, инициируя цифровые преобразования, о которых так любят рассуждать генеральные директора и другие представители высшего руководства. Но при этом качество большей части данных оставляет желать лучшего. В процессе переноса и интеграции данных зачастую возникают ошибки, порождающие информационные пробелы или дублирование информации.

Опрос показал, что только в половине организаций качество данных оценивают чуть выше, чем удовлетворительно, или «достаточно хорошо в целом». Естественно, о всеобщем одобрении в этом случае говорить не приходится. А 8,5% опрошенных сообщили, что никакой стратегии управления качеством данных у них нет вовсе. Вместо того чтобы заниматься этими вопросами, они просто «надеются на лучшее».

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

«В какой-то степени проблемы обусловлены отрывом ИТ-директоров, отвечающих за данные, от руководителей бизнес-подразделений, которые эти данные используют, – отметил Дэн Ортега, вице-президент по маркетингу компании Blazent, чье программное обеспечение такие организации, как Visa, Kaiser Permanente и CSC, применяют для повышения качества своих данных. – Взаимодействие тех представителей бизнеса, кому технологии нужны для более эффективного решения стоящих перед ними задач, и ИТ-специалистов, уделяющих в своей деятельности больше внимания перспективным тенденциям, чем ликвидации реальных проблем, по-прежнему оставляет желать лучшего».

Директор по данным в роли спасателя

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

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

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

Несмотря на то что во многих банках и других финансовых учреждениях должность директора по данным уже есть, в целом она по-прежнему относится к самым последним нововведениям. Признавая необходимость учредить должность руководителя, отвечающего за управление корпоративными информационными системами, 90% компаний планируют обзавестись директором по данным к концу 2019 года. «Человек этот должен будет решать сложные задачи по выработке информационной стратегии и определению критериев, помогающих увязать деятельность своей команды с измеримыми целями бизнеса», – пояснил Фариа.

– Clint Boulton. Disconnect between CIOs and LOB managers weakens data quality. CIO. Feb 5, 2016

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

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

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

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

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

Взаимодействие и координация

Еще одна особенность ИТ-службы будущего – более тесное взаимодействие с теми, кто пользуется созданными в ней технологиями как с внутренними, так и с внешними заказчиками.

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

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

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

Для ИТ-руководителей это крупная перемена, которая требует массы времени и терпения, но усилия окупаются благодаря повышению продуктивности и улучшению качества продукции.

За последние шесть-семь лет роль ИТ-директора полностью изменилась. Теперь руководитель ИТ-службы должен гораздо больше времени уделять прямому разъяснению подчиненным, чего именно хотят добиться заказчики. И есть свидетельства того, что благодаря таким разъяснениям ИТ-специалисты стремятся работать лучше. Многие даже решают служебные задачи в свое личное время – они увлечены, заинтересованы и полностью отдают себя работе. Результат – удовлетворенность заказчиков.

Главное – удовлетворенность пользователей

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

В компании Green Elephant, предоставляющей услуги управления результативностью технических и кадровых отделов, опросили около 100 тыс. ИТ-специалистов и пришли к выводу: от степени удовлетворенности пользователей напрямую зависит ценность ИТ-службы для бизнеса.

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

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

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

Что уготовано ИТ-службе в будущем

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

– Sharon Florentine. How to prepare for the IT department of the future. CIO. Feb 2, 2016

В 2015 году «Мечел» произвел миграцию существовавшей системы управления ИТ-сервисами на новую платформу LANDesk. Проект вызвал в ИТ-сообществе такой интерес, что стал победителем конкурса «Проект года», ежегодно организуемого Global CIO, в номинации «Управление сервисами и аутсорсинг».

«Решение о переходе можно назвать вымученным: выкорчевывать одну систему и внедрять другую – не самая приятная задача. Но у нас была безвыходная ситуация», – подчеркивает Андрей Кисляков, заместитель директора департамента ИТ-инфраструктуры компании «Мечел-БизнесСервис».

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

«Мы насчитали около десятка критичных проблем, с которыми не могли справиться. Эти проблемы затрудняли использование и развитие систем, а на их устранение требовались немалые деньги», – говорит Кисляков. Первой из проблем была недостаточная надежность системы. Иногда случались сбои, и каждый раз оставалось надеяться, что ничего критичного не произошло и ее работу удастся восстановить без внешней поддержки, которой не было.

Вторая по значимости причина – отсутствие гибкости. Система «закостенела», и своими силами ИТ-специалисты ничего не могли сделать. Стоимость же внешних доработок была столь высока, что тратить такие деньги не представлялось разумным.

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

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

Потребность в миграции

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

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

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

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

Андрей Кисляков, заместитель директора департамента ИТ-инфраструктуры компании «Мечел-БизнесСервис»: «У меня это третья система управления ИТ-сервисами. Я постарался правильно выстроить в ней весь тот функционал, реализация которого не устраивала меня на протяжении десяти лет в предыдущих»

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

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

«Мы составили список из 87 требований и обратились к поставщикам и интеграторам, имеющим опыт реализации подобных проектов», – рассказывает Кисляков. На основании требований была составлена таблица, и три победителя – LANDesk, Altiris и CA – были приглашены к участию в закупочной процедуре. По цене был выбран LANDesk. Таким образом, на первом этапе по техническим параметрам отсеяли слабейших, а прошедшим на второй этап – предложили посоревноваться в цене.

Без смены коней

Выбор системного интегратора в таких проектах весьма критичен: от него зависит многое, если не все. Именно поэтому поставщиков приглашали к участию в обсуждении проекта только совместно с партнерами статусом не ниже Gold. Что касается продукта LANDesk, то единственным серьезным интегратором был Arbyte. При проведении аудита был отмечен профессионализм команды. «Они отвечали на вопросы не задумываясь, без тайм-аутов, не делая вид, что не поняли вопроса», – говорит Кисляков.

Когда в Arbyte началась реорганизация, команда, реализующая проект, сама обратилась к заказчику: они попросили подождать разрешения ситуации. Проблему удалось решить почти без потерь: команда практически в полном составе перешла в SmartServiceDesk – бизнес-подразделение Tronic. Было подписано трехстороннее соглашение о передаче обязанностей по договору от одного интегратора другому.

Проект состоял из пяти этапов. Первые два заключались в установке и настройке системы, ее интеграции и обучении администраторов. Третий этап – реализация процессов «Управление инцидентами» и настройка модуля управления уровнем сервиса (Service Level Management, SLM). В ходе четвертого этапа выстроены процессы «Управление проблемами» и «Управление изменениями». На пятом этапе были реализованы процессы «Управление активами» и «Управление запросами пользователей», а также осуществлена миграция системы Service Desk.

Функционал LANDesk Management Suite внедрялся первым, потому что он сложнее при внедрении, чем Service Desk. Именно такую последовательность рекомендовали консультанты.

Следует отметить гибкость и функциональность внедренного решения. «Лучшей детализации собираемой информации, чем в Management Suite, я не видел. Например, серийные номера мониторов в штатном функционале системы я больше не встречал нигде», – говорит Кисляков. Система Service Desk настолько гибкая, что ее можно использовать во многих процессах. Например, в старом решении система оценки пользователями качества обработки обращений была реализована в виде дополнительного, внешнего решения. На новой платформе это оказалось сделать очень просто, причем не где-то «сбоку», а внутри основного решения. У других производителей, по их признанию, при реализации этого функционала возникли бы проблемы.

Система с возможностью развития

В результате реализации проекта была построена единая интегрированная комплексная система: от инвентаризации и удаленного управления рабочими местами пользователей до автоматизации процессов управления ИТ-услугами и ИТ-активами.

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

Постепенно расширяется функционал системы. «Благодаря гибкости платформы периодически возникают задачи, которые изначально не связаны с системой, но которые мы стараемся решить с помощью LANDesk, потому что так быстрее и проще», – подчеркивает Кисляков.

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

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

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

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

Решение, основанное на опыте

«У меня это третья система управления ИТ-сервисами. Я постарался правильно выстроить в ней весь тот функционал, реализация которого не устраивала меня на протяжении десяти лет в предыдущих», – заявляет Кисляков.

Первую систему Кисляков построил в «Норильском никеле», будучи менеджером проекта и администратором системы HP Service Desk. Затем, придя в компанию «Мечел», участвовал в опытной эксплуатации HP Service Manager. Благодаря имевшемуся опыту, Кисляков активно участвовал в выборе новой системы не только как управленец, но и как специалист, имеющий глубокие знания о системе.

Интерес к реализованному проекту со стороны ИТ-сообщества уже вылился в два референс-визита, были и неформальные беседы с коллегами.

«Мы готовы к референс-визитам, так как сами через это проходили. Если бы нам не показали возможности других систем, выбор мог быть другим и не столь успешным», – признает Кисляков. Примерно теми же мотивами руководствовались, выставляя построенное решение на конкурс «Проект года»: это благодарность коллегам, которые делились опытом и рассказывали о своих системах.

Об этом проекте будет сделан подробный доклад на XIII Российском форуме по управлению ИТ – ITMF 2016, который состоится 7 июня 2016 года. Вы сможете пообщаться вживую с проектной командой.

Наблюдая изменения, произошедшие в теории и практике проектного управления с 1970-х годов до нынешнего времени, можно увидеть, что различные методологии управления проектами следуют за динамикой изменения той среды, для которой эти проекты реализуются. В 70-е годы – весьма стабильную эпоху – родились ГОСТы. Это не были управленческие документы, их особенностями были ориентация на разработку ИТ-систем с нуля и каскадность проектов. В конце 80-х – начале 90-х годов они модернизировались, заменив или дополнив более ранние стандарты. На рубеже веков ГОСТы сменились западными методиками.

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

От платформ к готовым решениям

Управление проектами в нынешнем понимании возникло в России на рубеже 90-х и 2000-х годов, когда на российский рынок начали выходить зарубежные поставщики ERP-систем и стали проповедовать западную проектную идеологию. С ее помощью вендоры внедряли свои продукты, адаптируя их к российским реалиям. Иногда даже речь шла о создании некой собственной методологии, превосходящей остальные и гарантирующей больший успех проекта. Все внедренцы пытались работать по этим весьма громоздким рекомендациям, и какое-то время у них получалось неплохо.

Однако чем дальше, тем более турбулентной будет становиться бизнес-среда, причем скорость изменений будет нарастать. Это объективный фактор, и с ним бороться бесполезно.

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

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

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

С другой стороны, заметно изменяется и рынок ПО. Насколько огромным стал сдвиг от заказной разработки в сторону ИТ-платформ, настолько значим сейчас переход от этих платформ к готовым решениям. На рынке появляется масса стандартных предложений – в том числе облачных. Многие этапы проектной методологии становятся просто неактуальными.

Еще одна тенденция – повышение уровня владения технологиями со стороны бизнес-заказчиков, консьюмеризация ИТ. Бизнес-руководители привыкли, что приобретаемые ими решения начинают работать буквально «из розетки». У каждого есть планшет, за пять минут настройки становящийся полноценным рабочим инструментом. Подобные требования предъявляются и к корпоративным ИТ. Особенно – на что указывают психологи – это выражено у поколения Y.

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

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

Облачный пазл

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

Вторая: компании пытаются увидеть в кризисе для себя новое «окно возможностей». Для этих компаний максимально быстрая реализация проектов, включая развитие ИТ-инструментов, становится жизненно необходимой. Ради скорости они готовы пойти на риски, связанные с не совсем отлаженными – то есть сделанными по методологии и многократно протестированными – решениями. Зато такие решения действительно соответствуют потребностям бизнеса и способны поддержать скорость его изменений. Особенно это касается сегмента B2C, где конечный заказчик голосует рублем.

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

«Salesforce – один из хороших примеров по-настоящему эффективной платформы. Я знаю компании, которые действительно использовали ее в своей работе без каких-либо изменений», – говорит Петров. Если вести речь о российских решениях, то очень многие компании весьма успешно используют бизнес-сервисы Mail.ru (облачное хранение, календари, средства планирования и корпоративного взаимодействия), «Битрикс24», различные облачные продукты для бухгалтерского учета.

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

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

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

Минимизировать бюрократию

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

Первое, что необходимо, – определить бизнес-заказчика проекта и поставить задачу, обеспечив управление изменениями. Критерии целеполагания SMART (specific, measurable, attainable, relevant, time-bounded) не теряют своей актуальности. Цель должна быть конкретной, измеримой, достижимой, значимой и соотноситься с конкретным сроком.

«Следует уделить повышенное внимание проработке бизнес-требований: лучше дольше запрягать на этом этапе, чем потом медленно ехать не совсем понятно куда», – рекомендует Петров.

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

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

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

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

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

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

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

ИТ-активы любят счет

Финансовая группа «БКС» представляет собой сложную структуру – у нее много разнородных видов бизнеса, действующих по сильно отличающимся принципам. Все дивизионы функционируют относительно самостоятельно. Это накладывает ограничения на подходы к организации ИТ, которые построены по матричной структуре: есть функции, централизованные в рамках группы, а есть – работающие в своих дивизионах.

В результате сложился очень разношерстный ИТ-ландшафт. Если в традиционном банке достаточно просто стандартизовать используемые решения, то в БКС это сложнее – существуют решения, наиболее подходящие для каждого вида бизнеса. Кроме того, в силу специфики бизнеса ИТ-активы сильно распылены: много оборудования находится не на территории группы и даже не всегда на территории России – в ЦОД различных бирж и брокеров. Есть и оборудование, арендуемое на коммерческих площадках.

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

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

Это сказывалось как на управляемости огромным парком техники и ПО, так и на взаимоотношениях с внешним миром. Кроме того, для любого CIO важна прозрачность ИТ для бизнеса, потому что чем выше сложность ИТ, тем больше к нему возникает вопросов: куда уходят бюджетные деньги и зачем надо закупать новое оборудование.

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

Когда практика важнее теории

Любой проект приходится «продавать» как внутри ИТ, так и вовне – руководителям бизнес-направлений. Например, предложение «внедрить CMDB» (Configuration Management Database, хранилище информации обо всех ИТ-объектах компании) бизнес просто не поймет и отнесется к идее скептически.

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

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

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

В итоге партнерами по проекту стали специалисты компании «Инфраменеджер». «Общаясь с ними и уточняя методологию, мы жарко спорили: у нас – свое видение, у них – проектный опыт. Они отстаивали свою методологию, привнося свои взгляды, что было очень полезно», – говорит Корчуганов.

Бюджет в разрезе сервисов

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

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

Сейчас в компании обсуждается бюджет 2016 года, и ИТ-департамент уже чувствует принципиальные изменения. Раньше бюджет составлялся по типам затрат, и их влияние на реальное качество ИТ-сервисов не просматривалось. Теперь появилась возможность создавать бюджет именно в разрезе сервисов – не затрат на оборудование и лицензии, а стоимости владения той или иной системой. Это становится основой для принятия взвешенных решений. На инфраструктуру надо тратить ровно столько средств, сколько она заслуживает. «Я надеюсь, в следующем году мы не будем приобретать дорогостоящие сервисные контракты на оборудование, которое поддерживает работу некритичных систем», – выражает свой оптимизм Алексей Шлепнев, начальник управления методологии ИТ-процессов финансовой группы «БКС».

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

«Многим ИТ-директорам не хватает инструментов управления: кроме телефонного справочника и вороха разрозненной и не всегда актуальной документации, у них зачастую ничего нет», – сетует Шлепнев.

Нужна ли прозрачность ИТ-департамента

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

«Если топ-менеджмент понимает, на что тратит деньги, он начинает сам принимать решения. И это не всегда означает исключительно экономию», – уверен Корчуганов. Бывает и другой эффект: бизнес видит, что он получает адекватное качество сервисов, и начинает инвестировать в них, понимая, что за это получает.

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

Почти 15 лет назад был представлен Agile Manifesto, в котором в качестве альтернативы традиционному управлению проектами создания программных систем предлагалась радикально измененная методология. Согласно принципам скорой (agile) разработки, требования к проекту и решения менялись посредством организации в цикле разработки взаимодействия, при котором все задачи разбиваются на небольшие составляющие. Такая методология помогает бизнесу управлять непредсказуемостью и требует для успешного решения задач изменения менталитета участников проекта.

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

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

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

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

Если жизненный цикл разработки систем в вашей организации отлажен и дает ожидаемые результаты, то никаких изменений вносить не надо!

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

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

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

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

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

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

• Фиксация выделяемого времени и ресурсных рамок проекта. Это ограничение лишает команду гибкости. При каскадной модели менеджеры проектов чувствуют себя достаточно комфортно, направляя запросы на изменения при необходимости скорректировать конкретные часы и задачи. При гибком проектировании в случае изменений разработчики постоянно добавляют новые элементы в портфель заказов, не меняя при этом границы проекта и расписание. И хотя требования при скорой разработке могут меняться, сроки всегда остаются теми же самыми.
• Определение сроков для всех итераций и задач заранее. Желание начинающих менеджеров проектов, придерживающихся скорой методологии, заранее спланировать все требования, задачи и тексты для каждого спринта (итерации разработки) вполне естественно. Но это же и мешает самоорганизации команды и поиску оптимальных темпов, формирует нереальные ожидания в части сроков.
• Навязывание единых темпов разработки всем командам. Каждая команда придерживается собственных темпов, использует собственные методы преодоления трудностей и решает задачи с присущей ей скоростью. Менеджерам не стоит пытаться сравнивать скорость, с которой работают разные команды. Позвольте людям обучаться и усваивать новое в своем темпе.
• Ощущение потери контроля. Если переход к скорой разработке осуществляется правильно и в нужных масштабах, руководители проектов и программ лучше понимают ежедневный ход работ, точно знают, что еще осталось сделать, и находятся в курсе всех пробуксовок.
• Отказ от привлечения специалистов по тестированию в процессе планирования и реализации спринтов. Закладывая в планы проверку качества, вы формируете направления для тест-планов и определяете, что понимается под «правильной работой» программы. Это требует от организации привлекать специалистов по тестированию значительно раньше, что уже становится отходом от каскадной методологии, при которой тестирование выполняется в конце. На практике реализовать эту идею очень сложно, поскольку в каскадных проектах тестирование и проверка качества закладываются в бюджет ближе к концу проекта.

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

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

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

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

Джек Уолсер – менеджер компании AIM Consulting по обслуживанию клиентов, более 17 лет руководит работами, связанными с обеспечением непрерывных улучшений, разработкой ПО и реализацией проектов по трансформации стратегии.

– Jack Walser. Agile development: Adopt gradually or dive in? Network World (US). 01/22/2015

Хотя принципы скорой (agile) разработки изначально были предложены создателями программного обеспечения, сегодня они применимы практически в любой сфере. В их основе лежат сотрудничество, открытые коммуникации, доверие и независимость, эффективность и непрерывная выдача результатов. Все это способно сформировать долгосрочный позитивный эффект почти в каждой структурной части вашей организации. На прошедшей недавно в Вашингтоне конференции Agile Alliance 2015 старший консультант компании Industrial Logic Тим Оттингер изложил шесть принципов концепции скорой разработки, которые можно использовать фактически повсеместно.

Помните: иногда работа выглядит не так, как вы привыкли

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

«Работа заключается в том, чтобы думать, а не стучать по клавишам, – указал Оттингер. – Мозговые штурмы, обсуждение и даже простое пребывание вместе с членами команды – все это часть работы. Иногда самые удачные идеи и решения приходят в голову не во время многочасового написания кода, а во время прогулки. Нужно считать не время, в течение которого пальцы бьют по клавишам, а время, когда остаются в игре».

Формируйте ценности как можно раньше и как можно чаще

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

«Временны’е ограничения скорого подхода снижают вероятность аварий, ошибок, выбора неверного направления и прочих проблем, – подчеркнул Оттингер. – Рамки сужаются. Будучи разработчиками, мы не знаем достоверно, что на самом деле нравится людям в нашем продукте и как они собираются его использовать, потому что у людей в голове свои тараканы и люди постоянно меняют свое мнение. Нужно преподнести им какой-либо вариант как можно раньше, чтобы у них была возможность сказать “да”, “нет” или “почти”. На протяжении нескольких месяцев вы постоянно разочаровываете заказчиков ради того, чтобы в конечном итоге сделать их счастливыми».

Делите все на части – пусть даже со стороны это напоминает хаос

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

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

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

Еще одно частое заблуждение заключается в том, что agile-методология способствует ускорению работы команды. В какой-то степени это действительно так, но суть в другом. Команда разработчиков полнее реализует свои возможности, выдавая жизнеспособный продукт, а это уже приводит к увеличению скорости.

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

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

Будьте готовы к вечному совершенствованию

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

Учитывайте эмпирический характер скорых методов

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

– Sharon Florentine. 6 agile principles that apply to everything. CIO.

В соглашениях об уровне обслуживания (Service Level Agreement, SLA) регламентируется ожидаемый уровень результативности работы поставщика услуг. При аутсорсинге разработки и сопровождения приложений само по себе SLA успеха не гарантирует, но является одним из многих инструментов по управлению взаимоотношениями с поставщиком услуг.

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

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

Насколько важны SLA для сделок разработки и сопровождения приложений?

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

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

Важно, чтобы пользователи услуг аутсорсинга рассматривали SLA как «живой» документ, эволюционирующий на всем протяжении сотрудничества

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

Какие ошибки совершают заказчики при составлении SLA для разработки и сопровождения приложений?

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

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

Стивен Кирц, управляющий директор по трансформации бизнеса, Pace Harmon

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

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

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

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

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

Какие виды эффективных SLA для разработки и сопровождения приложений можно порекомендовать ИТ-руководителю?

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

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

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

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

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

– Stephanie Overby. How to build better SLAs for more strategic applications outsourcing. CIO. August 21, 2015

Принятие на работу сотрудников, которые когда-то покинули организацию, уже не считается абсолютно неприемлемым, как раньше. Отчет, подготовленный консультационно-исследовательской фирмой WorkplaceTrends.com и подразделением Workforce Institute компании Kronos, показывает, что довольно часто организации принимают «возвращающихся бумерангом» работников обратно.

В опросе «Сотрудники-бумеранги и оставленные ими организации», проведенном в июле 2015 года, принимали участие 1807 представителей кадровых служб, менеджеров и рядовых работников. Почти половина опрошенных кадровиков утверждают, что ранее в их организациях не разрешалось принимать на работу бывших сотрудников (даже если они оставались на хорошем счету). Сейчас же 76% из них свидетельствуют о вполне лояльном отношении предприятий к сотрудникам-бумерангам.

С этим согласны и менеджеры. Почти две трети готовы принять на работу бывших коллег. Правда, только 15% опрошенных сотрудников сообщили о своем возврате к прежнему работодателю. Вместе с тем почти 40% в перспективе готовы рассмотреть такую возможность.

Эффективные бывшие в цене

За последние пять лет 85% кадровиков получали от бывших сотрудников обращения с просьбой о приеме на работу, и в 40% случаев эти обращения были удовлетворены. В том, что доля столь высока, нет ничего удивительного, поскольку и представители кадровых служб (56%), и менеджеры (51%) говорят о приоритетном рассмотрении заявлений от бывших сотрудников, с которыми у них сохранились хорошие отношения.

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

Продуманный выбор

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

Сокращение адаптационного периода

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

Снижение рисков

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

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

Правильный посыл

Культура и профессионализм играют для бизнеса важную роль, однако сотрудники-бумеранги сулят им и еще одно преимущество: моральный подъем. «Когда ведущие таланты уходят, у оставшихся сотрудников возникает беспокойство, – отметил Алмеда. – Они начинают искать причину: возможно, грядут увольнения или положение компании неустойчиво. Когда таланты возвращаются, все остальные получают дополнительное подтверждение того, что на их рабочем месте все в порядке».

Стратегия альма-матер

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

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

Кадровики приводят несколько стратегий, помогающих поддерживать связь с бывшими высокоэффективными сотрудниками: 45% респондентов используют новостные рассылки по электронной почте, 30% действуют через кадровые агентства, 27% формируют группы бывших сослуживцев. При этом 42% выбирают в качестве платформы для создания таких групп Facebook, а электронную почту и LinkedIn используют соответственно 39 и 33%.

Ранний старт

Доверительные контакты с сослуживцами нужно устанавливать задолго до того, как они станут бывшими, и здесь важная роль должна отводиться взаимоотношениям между менеджерами и сотрудниками.

«Я постараюсь сформировать среду, которую люди не захотят покидать, но если они все-таки сделают это, мы не собираемся разрывать с ними контакты, – признался Алмеда. – Если между менеджером и сотрудником установились правильные взаимоотношения и они проявляют друг к другу искренний интерес, уважение, доверие, то велика вероятность того, что в один прекрасный день ушедший из организации сотрудник захочет туда вернуться».

– Sharon Florentine. 7 reasons to hire back the right former employees. CIO. September 22, 2015