Как получить "деньги вперед" за разработку софта?

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

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

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

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

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

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

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

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

"Силуэт" исходного когда программы. Например, (автоматически, разумеется) заменить все маленькие буквы в исходном коде на "х", все большие - на "Х", все цифры - на "9" и т.д. Заказчик сможет оценить стиль, структурированность, сравнить объем кода с ожидаемым и т.д. Некритичные части кода можно оставить нескрытыми.

Обфусцированный исходный код. Обфускацией называют замену мнемонических имен переменных (например, accountBalance, lastDate, timeModified и т.д.) на ничего не значащие (а1, а2, а3, например, или x, y, z). Вариант - использовать идентификаторы на языке или сленге заведомо неизвестном заказчику. Представляет наименьшую степень защиты и применим далеко не во всех случаях. Однако, если качественный поддерживаемый код для заказчика - в числе наивысших приоритетов, объем кода достаточно велик, а использованные алгоритмы сложны, данный метод может с успехом использоваться.

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

Автор: SmilingBuddha