редакторов журнала «Открытые системы» отвечают Сергей Шведов, старший вице-президент компании Scala по исследованиям и разработкам, и Александр Станоткин, директор Московского центра разработок Scala, насчитывающего более 130 сотрудников.

Сергей Шведов: «В свое время у нас был офис разработчиков в Индии, однако он был закрыт, хотя его содержание было на 10% дешевле, чем в России: нерентабельно иметь два центра разработок. В Индии неплохие программисты, однако российские разработчики проповедуют более творческий подход, а их менталитет ближе к европейскому. Немаловажными оказались также дополнительные издержки: время на командировки, разница во времени и т.п.» Александр Станоткин: «Центр разработок был создан в Москве, поскольку соотношение цена / качество, обеспечиваемое российскими программистами применительно к нашему продукту, оказалось наилучшим»

Что собой представляет отдел разработок Scala? Какие проблемы он решает?

Отдел исследований и разработок компании состоит из группы менеджеров продукта, четырех Центров компетенции (два в Швеции и по одному в Швейцарии и Венгрии) общей численностью 55 сотрудников, в основном, бизнес-аналитиков, а также Московского центра разработок.

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

Проект по созданию очередной версии состоит из пяти основных этапов: сбора требований, их анализа, разработки (дизайн, программирование, внутреннее тестирование и документирование), приемки (внешнее или бета-тестирование) и продвижения продукта. Сбором требований занимается группа менеджеров продукта, определяющих список требований к новой версии, в том числе, и на основе проходящих два раза в год совещаний с участием ключевых клиентов. Центры компетенции проводят более глубокий анализ, детальное описание этих требований и оценивают их с точки зрения ресурсных затрат. К процессу оценки обязательно привлекаются разработчики. Окончательное решение о составе версии принимают менеджеры продукта на основе приоритетов требований и их оценок. Центры компетенции в дальнейшем занимаются внешним тестированием и приемкой продукта, причем клиент принимает участие в этой работе и на этапе сбора требований, а если большинство его предложений вошло в разрабатываемую версию, то и на этапе бета-тестирования. По статистике, только 10-15% клиентов рвутся вперед, интересуются инновационными технологиями. Именно такие клиенты участвуют в бета-тестировании, а основная масса заказчиков предпочитает дождаться стабилизации версии продукта.

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

Как сложилась именно такая структура? Почему Центр разработок оказался в Москве?

Исторически. Сначала в Швеции был создан продукт, который снискал партнеров по всему миру. Часть партнеров имела в своем составе подразделения разработок, которые влились в компанию. Так, в Швеции в одном из Центров компетенции собралась сильная команда, разработавшая в свое время модуль «Управление производством». Для работы с западными клиентами нужно обязательно иметь локальный офис, в котором работали бы специалисты, разбирающиеся в местной специфике ведения бизнеса, способные оперативно откликнуться на проблему, знакомые с менталитетом и языком. Однако Центр разработок был создан именно в Москве, поскольку соотношение цена/качество у российских программистов применительно к нашему продукту оказалось наилучшим. Кроме этого, российские программисты больше, чем программисты — это творцы и немного ученые-исследователи. В Центре работают программисты, тестеры, системные аналитики, архитекторы, технические писатели, системные администраторы и т.д. Практически все с высшим образованием. Кроме того, мы сотрудничаем с тремя аутсорсинговыми компаниями; две из них расположены в Москве и одна в Украине.

Сложно ли управлять «учеными» и не вредит ли их участие качеству программного обеспечения?

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

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

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

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

Как происходил отбор компаний, работающих с вами по аутсорсингу?

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

При отборе подрядчиков мы проводим оценочное тестирование, отдавая предпочтение компаниям, имеющим соответствующее аппаратно-программное оснащение, сбалансированную команду разработчиков и соблюдающих предусмотренные процедуры работ. Ничего уникального мы не требуем. Основа нашей технологии — продукты Microsoft (Visual Basic, Visual C++, Windows 2000), серверы, рабочие станции и т.д. При необходимости, заключив договор о нераспространении, мы передаем подрядчикам свое программное обеспечение — собственно систему демолицензией, средства автоматического тестирования, синхронизации данных и т.д. Конечно же, у нас имеются требования к оформлению и документированию кода, являющиеся составной частью QMS. Раз в квартал мы собираемся, обсуждаем недостатки, проводим своеобразную сертификацию подрядчиков на соответствие производимого ими продукта заданному уровню качества. Наличие у аутсорсинговой компании сертификатов качества желательно, но не обязательно — в конце концов, ведь это мы отвечаем за результат, а они выполняют конкретную работу по спецификациям.

Пожалуйста, несколько слов о технологии и инструментарии выполнения проектов.

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

Еще одна особенность нашей системы — поддержка 30 языков в рамках одной версии. Все языковые формы хранятся в базе данных в виде строк; при появлении новой версии сотрудник-переводчик вносит в нее только новые тексты — встроенная система управления переводом сама подскажет, что и с какими ограничениями (например, по длине) надо перевести, и автоматически сохранит результат. Система контроля перевода основана на Web-технологиях и позволяет переводчику работать удаленно. Каждая новая версия проходит техническое тестирование у специалистов-носителей определенного языка.

Как организована работа распределенных коллективов разработчиков?

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