© Елена Сливко-Кольчик
Материал опубликован на сайте
Сетевой журнал №3.2002

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

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

Участники круглого стола:
Виктор Вайнштейн, вице-президент по заказным разработкам компании "АйТи"
Булат Гайфуллин, председатель совета директоров компании Interface Ltd.
Марина Аншина, директор отдела разработок компании TopS BI
Алексей Чеканов, зам. директора отделения системной интеграции компании ЛАНИТ
Сергей Королев, начальник отдела интернет-технологий компании LUXOFT
Николай Васильченко, директор отдела консалтинга компании ФОРС
Сергей Еремин, зам. директора отделения системной интеграции компании ЛАНИТ

От "Сетевого журнала" в круглом столе принимали участие:
Константин Зимин, издатель
Елена Сливко-Кольчик, обозреватель

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

М. Аншина: Понятия, о которых вы сказали, не имеют четких границ. Даже когда мы говорим о разработке ПО, значительная часть программного продукта приходится на готовые элементы; к ним можно отнести, например, платформу промежуточного программного обеспечения, базы данных, серверы приложений, готовые компоненты (в частности, EJB), библиотеки классов. Все эти элементы являются тиражируемыми решениями. Мы предлагаем заказчику необходимые элементы и уже на их основе делаем индивидуальный программный продукт "под ключ". Такой процесс можно назвать "развертыванием", "доводкой", разработкой. Вместе с тем и любые готовые системы, например класса ERP или CRM, нуждаются в индивидуальной настройке и обычно в доработке. Таким образом, происходит сближение процессов и соответственно понятий настройки и разработки. Критерием заказного ПО, разрабатываемого под конкретного клиента, могут служить, на мой взгляд, права на этот продукт, приобретаемые заказчиком. Покупая настраиваемое ПО, компания получает лишь лицензию на его использование, заказывая индивидуальную разработку - все права на продукт.

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

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

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

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

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

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

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

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

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

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

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

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

Булат Гайфуллин: "Определяя критерии выбора, важно учитывать, что конкурентным преимуществом на российском рынке является стандартизация бизнес-процессов и внедрение стандартных продуктов."

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

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

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

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

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

В. Вайштейн: Я бы добавил еще один критерий. Надо рассматривать не просто стоимость продукта, но и total cost of ownership - всю совокупность элементов. Например, заказчик может приобрести ПО, но неверно настроить его. Кроме того, постоянно выходят новые версии, которые могут нарушить его настройки. Здесь крайне важным становится вопрос поддержки. С другой стороны, если заказчик заказывает ПО, вся поддержка оказывается только ему, и соответственно стоимость ее существенно возрастает. Это важно учитывать при принятии решения.

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

		Васильченко: Мне кажется, что, обобщив вышесказанное, можно выделить следующие критерии выбора: готовность к изменению бизнес-процессов; цена поставляемого решения; положительный опыт внедрения подобных систем у других заказчиков; репутация компании-поставщика; гарантируемый результат внедрения системы, гарантии качества поставляемого решения. Б. Гайфуллин: Определяя критерии выбора, важно учитывать, что конкурентным преимуществом на российском рынке является стандартизация бизнес-процессов и внедрение стандартных продуктов.
Марина Аншина: "Внедрение программного обеспечения определенной функциональности будет состоять из установки нескольких интегрированных друг с другом платформ, на каждой из которых развертываются готовые тиражируемые компоненты. Подобный подход обеспечивает комбинацию достоинств как заказного метода, так и тиражируемого."		М. Аншина: Крайне важно и участие самого заказчика в процессе внедрения готовой системы. В противном случае процесс заканчивается крахом. Клиенты должны быть готовы пройти вместе с нами непростой путь внедрения как готовых тиражируемых систем, так и заказных разработок. Мы не можем сделать заказчику идеальную систему, не выяснив прежде его потребностей и желаний. Мы можем поделиться опытом реализации подобных проектов, но без участия заказчика успех конкретного проекта невозможен. С. Еремин: Действительно, очень важна готовность заказчика участвовать в проекте вместе с компанией, либо разрабатывающей, либо внедряющей систему. Причем в рамках заказной разработки интенсивное участие заказчика чрезвычайно важно. Ведь при неудаче заказной разработки может оказаться, что ни одна бизнес-функция правильно не реализована. Чем более "готовая" система выбрана, тем меньше вероятность оказаться "у разбитого корыта". При этом заказчик не обязан знать, как следует действовать, главное - активное сотрудничество. Задача квалифицированной компании-разработчика - направлять взаимодействие в правильное русло и получить всю необходимую информацию на соответствующих этапах проекта.

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

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

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

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

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

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

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

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

Б. Гайфуллин: Напрашивается интересный вывод о том, что надо вовремя и правильно оставить заказчика с его "ответственностью", предлагая в то же время поддержку, консалтинг и т. д.

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

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

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

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

С. Еремин: Процесс коммуникации с заказчиком и обеспечение качества ПО - вещи взаимосвязанные. Разных заказчиков можно разделить на две категории. Первая - бизнес-категория, когда заказчик - это компания, все сотрудники которой в большей или меньшей степени заинтересованы в решении стоящей перед компанией проблемы, ради которой ставится ПО. Вторая категория - заказчики, как ни странно, не заинтересованные в создании ПО. Нередко в крупных структурах лишь один руководитель или небольшая группа сотрудников заинтересованы в создании ПО, остальные по тем или иным причинам не заинтересованы или нейтральны. Для заказчиков из двух описанных категорий методология разработки будет иметь свои особенности. Так, например, сегодня в мире наблюдается тенденция все более интенсивного применения "проворных" (Agile) методов разработки. Эти методы могут давать хороший результат, однако одним из необходимых условий их применения является высокая степень взаимодействия разработчика и заказчика и соответственно высокая степень заинтересованности заказчика. Обратный пример - известный мне случай, когда руководство компании запретило собственным внутренним разработчикам взаимодействие с подразделениями-заказчиками в любых ситуациях, за исключением сбора требований и сдачи системы. В ситуации, подобной этой, "проворные" методы практически не работают. При отсутствии взаимодействия с заказчиком обычно применяются более тяжелые традиционные методологии, например, созданные на базе Rational Unified Process.

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

Б. Гайфуллин: В компании помимо непосредственных разработчиков - кодировщиков есть системные аналитики и бизнес-консультанты, которые и обеспечивают тот самый необходимый интерфейс между разработчиком и заказчиком.

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

Алексей Чеканов: "Представитель топ-менеджмента заказчика - в идеальном случае CIO - должен контролировать процесс создания информационной системы и определять требования к выполняемым ею функциям. На практике же выдвигаемые заказчиком требования зачастую оказываются совершенно не критичными для решения его бизнес-задач."

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

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

К. Зимин: Каким образом заказчик может оценить качество тиражируемого ПО? Какими способами обеспечивается должное качество?

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

М. Аншина: Понятие качества заказного ПО следует разделить на качество продукта и качество процесса. Качество процесса можно посмотреть, оценить, обсудить с клиентами. Качество продукта надо определить, это понятие измеримое. Следует также помнить, что обычно чем выше требования по качеству, тем дольше срок разработки.

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

Б. Гайфуллин: Я согласен с предыдущими высказываниями. Однако статистика, вероятность - это одно, а каждый конкретный случай - другое. Так, известно, что внедрение информационных систем на Западе только в 30% случаев заканчивается успешно. Заказчик всегда оказывается прав. Из-за неуспешного проекта в большинстве случаев заказчик теряет больше, чем исполнитель.

Недавно на одном из семинаров прозвучала вполне здравая, на мой взгляд, мысль, что на самом деле уровень качества определяется показателем стабильности деятельности компании. Если мы открыто говорим о том, что выпускаем продукцию с 90% брака - это нормально. Заказчику лучше иметь дело с той компанией, работая с которой он будет знать, что 5% продукции гарантированно будет качественной, а на остальные 95% надо поставить системы дополнительной проверки. Лучше работать с таким поставщиком, чем с тем, который в одном месяце обеспечивает 100% качественной продукции, а в другой 100% брака. Качество - это прежде всего гарантия стабильности.

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

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

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

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

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

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

К. Зимин: Каковы основные тенденции российского рынка заказного ПО? Каков этот рынок на Западе?

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

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

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

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

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

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

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

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

Я полагаю, в ближайшее время будет наблюдаться расслоение рынка программного обеспечения на ниши заказного и тиражируемого ПО. Тиражируемые решения будут распределяться по небольшим утилитам и, напротив, крупномасштабным решениям (например, корпоративным информационным системам), являющимся ядром, которое будет дополняться различным прикладным ПО, созданным с учетом специфики заказчика. Здесь будет очень много заказной и интегрирующей работы.

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

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

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

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

Дополнительная информация

Что день грядущий нам готовит...

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Обсудить на форуме
Отправить ссылку на страницу по e-mail