Заместитель генерального директора компании «ИнтерТраст» по разработке программного обеспечения Александр Савельев: «Главный приоритет - это тиражируемые программные продукты»

 Как вы пришли в ИТ-отрасль и с чего начиналось ваше сотрудничество с компанией «ИнтерТраст»?

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

Позднее, в 1993 году, я перешел на работу в один из российских коммерческих банков. Именно там я впервые познакомился с продуктом Lotus Notes/Domino, тогда еще версии 2.1, занимался администрированием этой платформы и разработкой специализированных приложений. Затем была работа в одной из первых российских компаний-интеграторов, а в 1996 году я принял предложение Андрея Линева и перешел в «ИнтерТраст». К тому моменту у меня уже сформировалось собственное понимание того, как строить серьезные решения на основе платформы Lotus Notes/Domino. Можно сказать, что мы нашли друг друга, ведь «ИнтерТраст» был на тот момент единственной компанией в Москве, бизнес которой был основан на разработке приложений на этой платформе.

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

 Какие проекты вы считаете наиболее значимыми и интересными для себя с профессиональной точки зрения? Как они повлияли на эволюцию CompanyMedia?

 - На момент моего прихода в компании уже был тиражируемый продукт OfficeMedia, но он позиционировался как система для внедрений с небольшим числом пользователей. Существовало понимание того, что необходима система, которая обеспечивала бы потребности крупных территориально распределенных компаний. Во многом это понимание сформировалось благодаря проекту для компании «ЛУКОЙЛ». Я стал руководителем этого проекта практически с первого дня работы в «ИнтерТраст». Разработки, которые мы вели для этой известной на весь мир нефтяной компании, определили основные направления развития системы CompanyMedia и всей компании «ИнтерТраст» на многие годы вперед. Нужно отдать должное команде ИТ-специалистов на стороне заказчика: Аркадий Иванов и Анатолий Захаров не только формировали требования, но и весьма активно участвовали в создании архитектуры системы вместе со мной, руководителем разработки программного обеспечения «ИнтерТраст», и Владимиром Пановым, нашим главным архитектором. И хотя проект для «ЛУКОЙЛ» был заказным, именно он стал тем фундаментом, на котором мы смогли реализовать свое решение CompanyMedia. Проект изначально ориентировался на создание корпоративной системы документооборота, функционально расширяемой, масштабируемой и территориально распределенной. При этом всем было ясно, что решение, которое работает в компании уровня «ЛУКОЙЛ», будет востребовано и другими корпоративными заказчиками. Время подтвердило наши идеи - система успешно развивается вот уже 18 лет, а ее архитектура не устарела и мы постоянно расширяем ее возможности.

Пожалуй, один из самых значимых и постоянно развивающихся проектов последнего десятилетия - внедрение CompanyMedia в ВТБ. Если говорить о банковской сфере, то значительный импульс развития система получила благодаря проектам для таких финансовых организаций, как «Внешэкономбанк», «Уралсиб», «ЮниКредит Банк», Газпромбанк, Росбанк, «Связь-Банк» и «Россельхозбанк». Банки традиционно входят в число наиболее технологичных организаций, в этом секторе нововведения получают быстрое распространение. Так, например, «ЮниКредит Банк» еще в 2002 году перешел на полностью электронный внутренний документооборот, одним из первых в России отказавшись от привычной «бумаги». Кроме того, в банках существует развитая конкурентная среда - практически для всех вендоров этот сегмент представляет огромный интерес, и это держит нас, что называется, в тонусе.

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

Мы много работаем с органами государственной власти, и среди наиболее масштабных внедрений в этом секторе можно назвать проект для ЯНАО.

 Существует ли разница между государственными заказчиками и клиентами корпоративного сектора? Каковы приоритеты в каждом случае?

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

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

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

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

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

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

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

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

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

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

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

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

 А как быть с уникальными требованиями заказчика?

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

 Что в большей степени определяет основные направления развития системы - видение «ИнтерТраст» как разработчика или требования заказчиков? Как найти баланс?

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

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

Таким образом, система развивается в пространстве с двумя «осями координат»: первая - функциональные требования заказчиков, вторая - архитектурное совершенствование системы. Мощная архитектура - это и серверная мультиплатформенность, и наличие различных типов клиентов системы, и масштабируемость по функциям, по числу пользователей, по объему данных, по числу площадок.

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

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

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

 В 2011 году стартовал проект разработки принципиально нового программного продукта - CompanyMedia Java. Что повлияло на это решение - начать создание системы на базе открытых стандартов?

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

Поэтому в 2010-2011 годах было принято решение о том, что компания будет параллельно развивать две линейки CompanyMedia. Одна - на базе IBM Notes/Domino, вторая - на основе Java. Разработка на Java - это возможность создавать универсальные решения, относительно недорогие по себестоимости, гибко расширяемые и совместимые с платформами всех вендоров, представленных на рынке.

Для CompanyMedia Java мы обозначили несколько ключевых принципов. Первый - мультиплатформенность, второй - сохранение всех функциональных возможностей, реализованных на базе IBM Notes/Domino, третий - возможность параметрических настроек при минимальном объеме программирования, и четвертый - наличие современного, эргономичного, и мультиязычного интерфейса для браузерного и мобильного клиентов системы.

Все перечисленные принципы реализованы в текущей четвертой версии CompanyMedia, первый релиз которой состоялся в конце 2012 года. Мы постепенно движемся в сторону полной независимости от базовой платформы. В актуальном варианте системы вся клиентская часть реализована исключительно на Java, а вот серверная составляющая пока остается на платформе IBM Domino.

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

 Каковы нынешние приоритеты разработки «ИнтерТраст»?

 - Главный приоритет - это развитие тиражируемой системы CompanyMedia, именно на этом направлении сосредоточены основные ресурсы. Четвертая версия в несколько раз сложнее предыдущей, и если для «тройки» мы могли себе позволить значительный объем заказной разработки, то сейчас такие возможности у нас минимальны. Мы концентрируемся на создании максимально полной функциональности в рамках типового тиражируемого продукта, а индивидуальные потребности заказчиков должны реализовываться с помощью настроек.

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

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

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

 Какими критериями вы руководствуетесь, подбирая людей в команду и как подходите к развитию сотрудников?

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

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

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

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

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