Заказная разработка как услуга

Ссылки сюда (1) →

Игорь Беспальчук, руководитель отдела технологического развития, в интервью для PC Week/RE рассказал об особенностях средств и методов заказной разработки, о сервисном подходе и новом уровне аутсорсинга ИТ-услуг.

PC Week: Какие средства и методологии разработки отличают создание заказной прикладной системы от тиражируемой?

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

В низкоуровневом проектировании, разработке и тестировании для нас нет каких-либо заметных отличий от тиражной разработки. Мы используем вполне обычные и распространенные IDE-среды (Microsoft Visual Studio для систем на базе Microsoft .NET и IntelliJ IDEA для Java), системы контроля версий (Subversion), баг-трекеры (Bugzilla). С другой стороны, иногда сотрудники организации-заказчика имеют непосредственный доступ к нашему трекеру задач, в котором осуществляется и фиксируется довольно интенсивный поток общения на проектные темы. Это позволяет выстроить более оперативное и прозрачное взаимодействие с заказчиком.

PC Week: Достаточно ли заказному разработчику и в частности вашей компании имеющихся на рынке коммерческих инструментальных средств или вам приходится создавать для себя и собственные инструменты?

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

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

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

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

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

Специфические отличия иного рода возникают на более поздних стадиях работы. Тесно взаимодействуя с заказчиками в решении их бизнес-задач, мы нередко берем на себя часть деятельности по внедрению, сопровождению и администрированию разработанных нами программных продуктов — в духе популярной сегодня концепции DevOps. При этом регулярно приходится заниматься масштабными инсталляциями или обновлениями ПО и БД (десятки и сотни серверов и рабочих мест). Выполнять эту работу вручную невозможно, поэтому мы разработали собственный инструмент CUSTIS Patcher, позволяющий централизованно управлять накатом обновлений с контролем ошибок и запретом на работу в некорректных состояниях. Часто этим инструментом пользуются и специалисты заказчика, устанавливая очередные версии нашего ПО самостоятельно. Полноценных аналогов этого инструмента на рынке мы не встречали.

PC Week: В последнее время в ИТ все большую популярность приобретает сервисный подход. Находит ли он применение в разработке ПО, в частности заказного?

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

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

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

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

PC Week: Можно ли называть это передачей разработки ПО на аутсорсинг?

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

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

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

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

---

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Заказная разработка как услуга»