Как продать свою программу

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

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

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

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

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

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

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

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

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

Большинство пользовательских приложений сейчас пишется на языках, работающих c объектами (Borland Delphi, Visual Basic) в том числе и с графическими. Эти языки позволяют без особых временных затрат создавать приложения, в которых ввод данных можно упростить до "клика" мышью. В классических языках программирования создание удобного интерфейса - задача достаточно трудоемкая. Эти свойства нынешних сред разработки рекомендуется использовать как можно шире. Ведь в системе человек/компьютер ошибаться может только человек. А попробуйте засадить оператора за работу с приложением, в которое за день приходиться вводить до тысячи длинных названий и кодов более чем из двадцати символов. В скольких из них он сделает ошибки?

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

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

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

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

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

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

То же самое относится к надписям, заголовкам, меню и панелям инструментов. Это особенно важно для Windows-подобных приложений.

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

• Название программного продукта (большими красивыми буквами).
• Номер версии программного продукта.
• Информацию об изготовителе.
• Сообщение об авторских правах.

Если в заставке используется рисунок, постарайтесь, чтобы он соответствовал функции приложения. Классический пример в этом случае - заставка от Word 6.0: ручка и лист бумаги.

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

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

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

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

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

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

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

Кирилл Кириллов