USD 66.24 ЕВРО 75.71

Интервью с Игорем Беспальчуком, руководителем отдела технологического развития, группа компаний CUSTIS

Мнения

«Мы видим тренды расширения сферы заказной разработки.»

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

Когда мы говорим о заказной разработке, мы отделяем её от того, что называется «коробочным» продуктом, и от того, что называется “inhouse”. Ваш вопрос про второе различение. Если вы имеете дело с большим предприятием, с большой информационной системой, с серьёзным тяжёлым проектом, то разработка бывает весьма непростым делом. Даже не столько сама разработка, сколько организация большого коллектива, управление им, выдерживание долгосрочных аспектов качества, выстраивание процессов, которые помогут вам это качество в дальнейшем поддержать.

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

 Но всё же что обходится заказчику дороже или дешевле?

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

 А такой критерий, как стоимость владения?

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

 Используете ли вы в ваших разработках в качестве основы собственные «коробочные» продукты?

У нас есть опыт создания малотиражных информационных систем, например биллинговой системы для ЖКХ. Она внедрена в нескольких регионах Российской Федерации в достаточно крупных городах и служит информационным ядром для ЕИРКЦ. В некотором смысле ее можно считать коробочным продуктом.

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

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

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

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

На текущий момент это проектирование, разработка и сопровождение на полном жизненном цикле учётно-аналитических систем. Учёт мы трактуем максимально широко – это и бухгалтерский, и финансовый, и управленческий учёт, это может быть учёт товародвижения, потребления электричества и даже радиоактивных отходов. Тема учёта охватывает большой спектр отраслей – банки, ритейлеры, ЖКХ, госсектор…

 Кто в дальнейшем ведёт сопровождение – обученные люди заказчика или саппорт привязан к вам?

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

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

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

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

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

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

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

У нас был опыт, когда мы передавали клиентам технологии разработки и прекращали партнёрство, а их системы продолжали развиваться. Так было, например, в нескольких банках, где клиенты полностью забирали себе сопровождение и развитие АБС, и с системами для ЖКХ, когда организовывалось предприятие ЕИРКЦ и технический центр рядом с ним. Мы организовывали этот технический центр, обучали людей, передавали туда технологии, по которым была построена система, и, если наше партнёрство прекращалось, технический центр продолжал её развитие.

Любой программный продукт имеет определённый жизненный цикл. Как это происходит в вашей практике?

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

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

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

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

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

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

А как у вас решается вопрос с качеством кода? Как обстоят дела с соответствием каким-то общим и внутренним стандартам?

Когда мы говорим о заказной разработке, нужно рассматривать не только качество кода, но и качество услуги в целом. Качество кода может быть хорошим, а остальные аспекты услуги – не отвечать поставленным заказчиком задачам. У нас есть внутренние стандарты качества и процессы, направленные на его обеспечение, – CodeReview, автоматизированное и ручное тестирования и т. д. Если же говорить о стандартах – мы их знаем и стараемся соответствовать тем требованиям, которые предписываются признанными методологиями разработки ПО. Хотя мы никогда не проводили официальных оценок по методикам CMMI, ключевым требованиям третьего уровня мы соответствуем. Говоря о качестве, сложно опираться только на стандарты. Качество – это всегда ответ на представления потребителя о качестве, а эти представления нестандартны.

Сталкивались ли вы с сопротивлением персонала заказчика во время внедрения ваших систем?

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

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

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

 Какие тренды вы наблюдаете в России? Как обстоят дела с заказными разработками?

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