Управление требованиями, фиксация и реализация изменений, необходимых бизнес-пользователям в отдельных ИТ-системах, — это важнейшая область взаимоотношений с бизнесом и один из самых проблемных элементов данного «интерфейса». Если же речь идет о развитии и поддержке ПО собственной разработки, то задача становится особенно интересной: теоретически в таких системах можно реализовать всё что угодно. В компании все основные операции и бизнес-процессы, весь технологический цикл от приема заказа до выставления счета обеспечивает приложение, созданное собственными силами. Как совладать в этом случае с валом пользовательских желаний и выстроить эффективный «интерфейс» с бизнесом? О своем опыте рассказывает Елена Шадрина, директор информационных технологий DPD в России.

Intelligent Enterprise: Какие структуры в вашей компании отвечают за доработку и развитие ПО? Какие подходы вы используете для управления требованиями пользователей?

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

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

Расскажите, каким образом происходит сбор и формализация запросов на изменения.

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

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

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

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

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

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

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

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

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

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

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

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

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

Участвуют ли бизнес-пользователи в тестировании?

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

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

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

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

При этом надо понимать, что собственная разработка — не дешевая затея, особенно если серьезно заниматься формализацией и документированием. И дело не быстрое, так как всё нужно предварительно взвешивать, тщательно обдумывать; но как результат мы действительно можем управлять своей внутренней разработкой.

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

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

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

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

О компании

DPD в России (ЗАО «Армадилло» и ЗАО «Армадилло Бизнес Посылка») является признанным лидером на российском рынке экспресс-доставки посылок и грузов. Компания предоставляет полный комплекс транспортно-логистических услуг и осуществляет доставку в 3500 городов и населенных пунктов России, а также в 220 стран и территорий мира. Все основные производственные процессы поддержаны ИТ-системой собственной разработки, продукт эксплуатируется с 2004 года.