Продукт от слова «продавать»

Вопросы рынка в планировании и проектировании программного обеспечения

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

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

Доход

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

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

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

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

Увеличение ценности

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

Поставщикам следует избегать создания продуктов, напрямую альтернативных решениям других производителей, поскольку экономия за счет массовости играет на руку тому поставщику, который контролирует большую долю рынка. Поставщики с упрочившимся положением на рынке имеют более высокий доход при сопоставимых затратах. Очевидно, что серьезное отличие от конкурентов по максимально большему числу параметров (таких как возможности, полезность, расходы на эксплуатацию) имеет решающее значение [4]. С другой стороны, компания, первой на рынке предложившая новую категорию продуктов или значительно улучшившая характеристики ПО из уже имеющейся категории, получает важное преимущество. Таким образом, при проектировании программного обеспечения в первую очередь следует уделять внимание полезным и выгодным для заказчиков новаторским решениям.

Сетевые эффекты. При наличии сетевых эффектов общее число пользователей, как правило, влияет на ценность программного продукта [4, 6]. Эти эффекты могут быть позитивными (например, ценность систем мгновенной передачи сообщений для каждого отдельного абонента увеличивается с ростом числа их пользователей) или негативными (ценность Internet при фиксированной пропускной способности уменьшается, если емкости каналов доступа не хватает для большего числа пользователей). Они могут быть прямыми (объем продаж продукта зависит от них напрямую) или косвенными (ценность зависит от некоторых дополнительных обстоятельств, таких как число программистов, владеющих данным языком, или наличие информационного наполнения для приложения, которое обеспечивает доступ к данным).

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

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

Архитектура распределенных приложений может серьезно повлиять на сеть. Например, увеличение числа пользователей сети с одноранговой архитектурой имеет решающее значение. С другой стороны, лишь первые абоненты сети в архитектуре клиент-сервер смогут в полной мере воспользоваться преимуществами этой системы (за исключением некоторых случаев, например если сайт пытается сформировать сообщество совместно работающих пользователей). Скажем, ценность Napster зависит от того, насколько быстро растет число ее пользователей, а всеми преимуществами iTunes, в сущности, пользуется только ее первый владелец. Такие возможности, как загрузка программного обеспечения с автоматической установкой или мобильный код, помогают преодолеть последствия прямых сетевых эффектов, с которыми сталкиваются первые пользователи (о чем свидетельствует работа с Napster или Skype), и позволяют внедрять приложения, что было бы невозможно в противном случае.

Увеличение ценности продукта за счет расценок. Составление расценок — это стратегический бизнес-процесс, позволяющий преобразовать ценность в больший доход [4] и определяющий многие из решений, которые принимаются на этапе проектирования. Альтернативные подходы к составлению расценок — такие как прямые переговоры о ценах (обычно для фирм, занимающихся аутсорсингом), определение платы за лицензию для каждой крупной новой версии или на основе существующей абонентской платы — напрямую влияют на процесс проектирования [3]. Например, продажа функций программного обеспечения как услуг ограничивает список платформ, на которых работает это ПО, тем самым упрощая проектирование и поддержку. Каждая ценовая схема требует своей идеологии проектирования, а некоторые предусматривают использование определенных компонентов мониторинга и генерации счетов, серверов лицензий и так далее.

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

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

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

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

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

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

Снижение затрат заказчиков

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

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

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

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

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

Поддержка сотрудничества производителей

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

Архитектура. Этот этап планирования проекта определяет рамки конкуренции и дополняемости [7, 8]. Кроме того, на данном этапе необходимо оценить большинство важнейших экономических параметров [9]. Поскольку внутри фирмы, как правило, существует «разделение» по известным интерфейсам (таким образом происходит своего рода сегментация), архитектурные ограничения также должны соотноситься с организацией фирм внутри отрасли ПО. Определяет ли отраслевая организация схематическую архитектуру или, наоборот, поддерживает архитектуру, определенную другими? Крупные фирмы, как правило, определяют архитектуру, а небольшие позиционируют себя в соответствующем «архитектурном» сегменте. Контроль над архитектурой может стать конкурентным преимуществом, поэтому то, каким образом поставщик приобретает или поддерживает ее, имеет важное стратегическое значение.

Программная архитектура высшего уровня

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

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

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

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

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

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

Затраты

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

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

Платформа и распространение

При распространении любого ПО круг потенциальных заказчиков определяется выбором инфраструктурной платформы (набора возможностей, которые должны присутствовать обязательно и всегда) и предполагаемого дополняющего ПО [3]. Перенос и поддержка программного обеспечения для многих платформ помогает увеличить доходы, но при этом возрастают расходы на разработку, обслуживание, тестирование и поддержку. Переносимость за счет выбора разных языков и платформ позволяет несколько снизить расходы. Однако это зависит больше от конкретной платформы (при условии наличия встроенной виртуальной машины) и гомогенизирует инфраструктуру, делая ее более сложной для внедрения новых инфраструктурных возможностей. Устранение зависимости от предполагаемого дополнительного ПО увеличивает круг потенциальных заказчиков, но подготовка корректных интерфейсов может привести к росту затрат на разработку и развитие продукта.

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

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

Текущие расходы

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

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

Повторное и множественное использование

Организационный подход к сокращению затрат на разработку — это повторное использование кода (использование или модификация кода, написанного для другого проекта, [10, 11]). Повторное использование не столь распространено, как кажется, поскольку создание кода, который можно легко использовать повторно, требует значительных дополнительных усилий. А это противоречит целям и задачам руководителей проекта, стремящихся закончить его в срок и в рамках выделенного бюджета. Изменения в коде, которые приходится делать в следующем проекте, также ставят под угрозу возможную экономию на поддержке и модернизации, усложняют процесс ликвидации обнаруженных позднее изъянов в защите.

К счастью, поставщик может минимизировать объем необходимого кодирования следующими способами. Первый подход заключается в расширении инфраструктуры, позволяющем удовлетворить требования множества приложений (например, универсальная аутентификация). Второй подход — купить или лицензировать модули или компоненты, создав цепочку поставки программного обеспечения [12]. Компоненты — это модули, рассчитанные на множественное использование, которые поставщик может конфигурировать и объединять в разных контекстах без каких-либо внутренних модификаций. Такой подход позволяет:

• распределить затраты на ресурсы и разработку между большим числом пользователей;
• повысить качество за счет аккумуляции опыта;
• получить дополнительные стимулы к снижению сложности и повышению полезности при удовлетворении требований множества приложений.

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

Риск

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

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

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

На уровне проекта

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

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

Анализ чистой стоимости (упрощенная методология оценки возврата инвестиций) позволяет определить отклонения путем вычисления среднего возврата инвестиций. Реальные возможности — это техническая методология, предлагаемая финансовыми экономистами, которая является теоретической основой для поэтапных необратимых инвестиций [14, 15]. Она повышает чистую стоимость за счет беспристрастной оценки отклонений на каждом этапе, позволяет откладывать решения об инвестициях на каждом этапе на максимально возможный срок и предусматривает систематический сбор информации для роста качества таких решений и обеспечения количественного описания получаемых преимуществ.

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

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

Еще один риск состоит в том, что другие поставщики могут присвоить идеи, украсть код или выдвинуть обвинения в нарушении их патентов. Эти риски может минимизировать адекватное использование прав на интеллектуальную собственность [17]. Что же касается идеи (новой и полезной), реализованной в программном продукте, то ее можно сделать общедоступной (бесплатно или в виде копирайта), сохранить ее как торговый секрет или запатентовать.

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

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

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

На уровне организации

Организации имеют инструментальные средства управления рисками, которые недоступны на уровне проекта. К ним относятся многообразие и повторное использование в разных проектах (смягчается необратимость инвестиций). Что касается последнего, пакет продуктов позволяет добиться более серьезных прибылей — при условии, что неотъемлемые риски, связанные с этим пакетом, строго коррелируются [19]. Типичная организация использует разделяемые ресурсы при управлении несколькими проектами на различных этапах выполнения. Она сталкивается с необходимостью принимать компромиссные решения, выбирая между эффективностью на уровне организации или на уровне проекта. Возможность распределять имеющиеся ресурсы между доступными инвестиционными возможностями, — еще один важный момент, связанный с управлением рисками на уровне организации.

На уровне отрасли

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

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

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

Литература

Девид Дж. Мессершмит (messer@eecs.berkeley.edu) — профессор электротехники и информатики университета штата Калифорния (Беркли). К области его научных интересов относится влияние бизнеса и экономики на технологию.

Клеменс Жиперски (cszypers@microsoft.com) — программный архитектор компании Microsoft. К области его научных интересов относится компонентное программное обеспечение.

David G. Messerschmitt, Clemens Szyperski. Marketplace Issues in Software Planning and Design. IEEE Software, May/June 2004. IEEE Computer Society, 2004, All rights reserved. Reprinted with permission.

Дополнительная литература

Pricing of Complementary Goods and Network Effects, Nicholas Economides and V. Brian Viard, tech. report 1812, Graduate School of Business, Stanford Univ., 2003; http://gobi.stanford.edu/researchpapers/ detail1.asp?Document_ID=1951.

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

«Software Economics: A Roadmap,» Barry W. Boehm and Kevin J. Sullivan, Proc. Conf. The Future of Software Engineering, ACM Press, 2000; http://portal.acm.org/citation.cfm?id=336584&coll=Portal&dl=ACM&CFID=19273781& CFTOKEN=53125957.

Эта книга, выпущенная вместе со сборником International Conference on Software Engineering, The Future of Software Engineering (издание 2000 года), включает в себя актуальные материалы о перспективах развития многих дисциплин программного инжиниринга. Боэм и Салливан помогают читателю получить представление о направлениях исследований и остающихся открытыми вопросах, касающихся экономики ПО. Они критикуют традиционный подход, который отличается излишним вниманием к структурным свойствам программного обеспечения и средствам обеспечения его корректности, и отмечают недооценку важности формулирования требований и описания рисков. Традиционно при управлении программным проектом в качестве приоритета воспринимаются затраты и мало внимания уделяется ценности создаваемых продуктов, которую можно определить только с учетом того, насколько хорошо в данном проекте определены требования и насколько им соответствует продукт. По мнению авторов, в перспективе, разработка ПО превратится в дисциплину, ориентированную именно на ценность продукта, для чего будет использоваться методология реальных возможностей.

Software Ecosystem: Understanding an Indispensable Technology and Industry, David G. Messerschmitt and Clemens Szyperski, MIT Press, 2003.

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