Два фронта разработки ПО: тираж или заказ?

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

Для большинства мировых компаний — производителей программного обеспечения сегодня является нормой ситуация, когда сопровождение включает в себя поставку обновлений системы (патчей и версий) и довольно скромный объем консультаций. Состав обновлений определяется внутренними планами развития продукта, потребности клиентов лишь регистрируются, обобщаются и используются при принятии решений о дальнейших направлениях развития. Адаптация под клиента выполняется фирмами-распространителями, и производитель не несет ответственности за поддержку сделанных ими доработок. Подобная схема работы позволяет обеспечить высокую устойчивость обновлений (установка патча, как правило, не приводит к возникновению серьезных ошибок), характеризуется низкой себестоимостью инсталляции и последующего сопровождения и позволяет качественно управлять развитием продукта. Цена же лицензий на использование системы (т.е. стоимость проекта внедрения без учета услуг) определяется торговой политикой производителя.

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

3 модели работы производителя ПО

Источник: CNews Analitics

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

Использование тиражного продукта (модели 1 и 3) привлекательно для клиента тем, что он сразу получает некоторый объем функциональности, работоспособность которого проверена на других пользователях, и в дальнейшем может рассчитывать на его бесплатное расширение в рамках сопровождения. Новые модули могут докупаться со значительной скидкой в порядке расширения лицензионного соглашения.

Риски и преимущества

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

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

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

Модель для российских условий

На отечественном рынке разработки ПО получила широкое распространение указанная выше модель 3. Долгое время впечатляющее развитие этого сектора базировалось на сочетании высокого интеллектуального потенциала отечественных разработчиков и низкого уровня оплаты. Но годы экономического подъема, когда ставки специалистов росли опережающими темпами по отношению к росту производительности труда, заметно уменьшили значимость этого фактора, а увеличившиеся масштабы производства усилили конкуренцию с иностранными производителями. Многие секторы рынка близки к насыщению: первичная автоматизация завершена, и новые проекты возникают в основном как результат реорганизации. Но и сейчас важным конкурентным преимуществом остается готовность работать по третьей модели. Кроме того, стимулом продвижения на рынке становится стандарт де-факто для отечественных ИТ-компаний — расширенный набор услуг по сопровождению. Сюда входят такие сервисы, как своевременная поддержка изменений законодательства в рамках закупленной функциональности без дополнительной оплаты; исправление ошибок в жестко оговоренные сроки (обычно регламентируются соглашением о приоритетах); выполнение доработок по ограниченной поддержке изменений бизнес-процессов клиента (объем может быть зафиксирован в договоре сопровождения).

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

Потребность в интеграции средств разработки

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

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

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

Дмитрий Музалев / CNews

Владимир Рахтеенко: Многие тиражные продукты начинаются как заказные разработки

На вопросы CNews отвечает Владимир Рахтеенко, генеральный директор компании «Заказные ИнформСистемы».

CNews: Как бы вы охарактеризовали ключевые отличия заказного ПО от тиражного?

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

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

Полный текст интервью