Как продавать роботов

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

«Ты кто такой, давай техзадание!
Ты кто такой, давай техзадание!
Он все тебе объяснить старается,
Отчет-аудит показать пытается,
Знаещщ, где рэальний дэло начинается?
Только там, где ТЗ появляется!

А теперь, товарищ, внимание!
Нет ТЗ — Давай Досвидания!» ©

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

Вам надо четко выделить 4 этапа, чтобы написать качественный код:

1) Бизнес-анализ. Вы должны получить (часто) абстрактные пожелания клиента о том, что он хочет. И превратить их в четкое техническое задание. Да, это должны сделать именно Вы! А не Заказчик. Вы должны предоставить Заказчику настолько четкий шаблон, чтобы ему пришлось там указать всё, что нам надо.
Это — основа дальнейшей работы, и исключение большого количества конфликтов и отрицательных отзывов о работе.
Хороший исполнитель, с высоты своего опыта, еще и сам может подсказать Заказчику, что именно ему надо, если понятно, что Заказчик хочет что-то бесполезное. Но это уже по желанию.

2) Разработка. Тут углубляться не буду. Ведем аккуратно код, отслеживаем версионность, при фиксации очередной версии (commit) подробно пишем, что и почему поменяли, кто это просил, даты, заказчик, причины. Это все потом очень понадобится, чтобы найти причины проблем. И даже, возможно, предъявить Заказчику претензии.
Отсутствие этих записей — переход от работы над кодом к разборкам «я этого не говорил». А этим Заказчики, бывает, очень грешат.
Зарабатывающих роботов мало, и когда Заказчик осознает что его алгоритм не приносит прибыли, возможно, он захочет найти виноватых. Вот тут все записи и пригодятся.

3) Тестирование. Прогоните робота на собственном счете. Избавьте его хотя бы от детских ошибок. Заказывал я тут у одного «как бы (простигосподи) программиста» код, он не запустился. И началось: «ой, да я вам библиотеку не ту дал, вот другая», «ой, я поправил, попробуйте еще раз», и так далее. Отвратительное ощущение от общения. Человек накидал код «на авось», и бросил Заказчику — «а, пусть запускает, там ошибки и вылезут».
Нет, тестируйте код у себя.
Если это HFT, то нужно будет не только функциональное тестирование, но и нагрузочное, чтобы дать четкие диапазоны параметров работы робота, и сразу сказать — что он может, а что уж нет.

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

Ну и дополнительные комментарии:

1) Цените конфиденциальность клиента и его данных. Малейшее подозрение, что код может слить наружу хоть какие-то данные (пусть даже бесполезные обезличенные логи, по которым Вы хотите посмотреть работу кода для отлова ошибок) — потеряете клиента навсегда, и многих других тоже.
2) Оформите хоть какой-то узнаваемый бренд для своих разработок. Это поможет в будущем лучше, чем «написано Уасей Пупковым в 2015 году».
3) Озаботьтесь механизмом мониторинга работоспособности своего кода. В код желательно встроить модули, которые тем или иным способом будут сигналить Заказчику о свой неработоспособности. Плохая практика — код остановился, клиент об этом узнал через сутки, когда (возможно) уже слил из-за этого кучу бабла. Код не только должен работать как заказывали, но и сигнализировать, если вдруг что-то пошло не так.
4) Нарабатывайте собственную библиотеку кода. Вы должны создавать «конструктор» сами для себя и для последующих доработок. Любый универсальные функции выносите в отдельные библиотеки.
5) Логи и сообщения об ошибках должны быть понятны, а не «Error 459-af, обратитесь к разработчику».
6) Обрабатывайте все exception. Проверяйте диапазоны значений. Не давайте дураку сломать работу. Если дурак сможет вписать ".Й" в поле, где должно быть число и код от этого рухнет, предъявят — Вам. Сделайте проверку «Тут.Й писать нельзя» :)
7) Хоть это и будет звучать как фраза из сраных «книжек по успеху» — делайте для Заказчика чуть больше, чем он ожидает. Нет ничего хуже, когда клиент видит, что работают с ним «на отъе*ись» (ага, опять привет «какбы кодеру»). Такой клиент не вернется.
8) Из предыдущего пункта: не занижайте цену, чтобы можно было спокойно сделать то, что хочет Заказчик, и немного больше, и при этом Вас не отвлекали голодные дети и бесшубная жена :) Для этого, конечно, по началу придется наработать авторитет и базу. Поверьте, многие клиенты готовы платить больше, за гарантию качественного результата.
9) Снабжайте код документацией, но не сложной. Плюс к этому нарабатывайте на своем сайте (а он, коню понятно, должен быть) «базу знаний» с описанием часто встречающихся ошибок.

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

Понятно, что абсолютно все вышеперечисленное никто не соблюдает на 100%. Но ...

p.s. Ничего не продаю, семинаров не веду, каналов нет.