Недопонимания между разработчиком торговых роботом и заказчиком

Недопонимания между разработчиком торговых роботом и заказчиком

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

Основные камни преткновения при сдаче робота или программы заказчику:

1. В процессе согласования технического задания не были учтены отдельные моменты, которые требуют значительных временных затрат на их реализацию;
2. Последующее обсуждение работы через переписку или разговор, которое не вносится в конечное техническое задание;
3. Формальное изучение технического задания разработчиком;
4. Одностороннее или полное отсутствие согласования технического задания до этапа разработки;
5. Двойное толкование написанной фразы;
6. Выполнение работы строго по указанному Техническому заданию, без внесение важных правок на этапе разработки – тупая сдача проекта «как было написано»;
7. Закрытость кода для заказчика и оставление единоличных прав разработчиком;
8. Отсутствие знаний у заказчика в понимании написанного кода и необходимость пояснения кода, что не входит в Техническое задание;
9. Наличие в техническом задании отдельных блоков из уже созданных ранее систем, доступных в свободном доступе.

Определив основные преграды, которые могут возникнуть на этапах от идеи создания робота до ее воплощения, предлагаю разобрать их по отдельности.

В процессе согласования не были учтены некоторые моменты, которые требуют значительных затрат времени на их реализацию.

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

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

Все дополнительные временные затраты нужно обсуждать с заказчиком

Часто идет обсуждение голосом или переписке, и не вноситься в конечное техническое задание

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

Если же идет переписка, то лучше это сразу включить в техническое задание, а если все же включили, то переписку всегда можно поднять и посмотреть до чего договорились.

Невнимательное прочтение технического задания разработчиком

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

Не было согласовано техническое задание

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

Что может скрывать данная фраза под собой:

1. Для входа в лонг, быстрая должна пересечь снизу-вверх или сверху вниз медленную?
2. Пересечение оценивается по сформированным свечам или в моменте?
3. Скользящие средние будут построены на одном таймфрейме?
4. Рыночная или лимитная заявка на открытие?
5. Что делать если пропадет связь? Что делать после восстановления связи?
6. Что делать если заявка не прошла в систему, не хватило лимитом или что-то еще?

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

Разное понимание написанной фразы

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

Сделал точно по техническому заданию

Слышал от заказчика, с которым работал, заказал небольшую информационную панель для инструмента. Разработчик сделал ее быстро и недорого. Заказчик получил в итоге не совсем то что хотел. Как написано в техническом задании сделать информационную панель чтоб выводила значения, например, «Открытия и закрытия», разработчик так и сделал, как написано для одного инструмента, а в итоге заказчику нужна была возможность выводить несколько инструментов.  Ввиду этого нужно было доплатить за модернизацию, т.к. первоначально цена была просчитана именно для отображения цен для одного инструмента. В этом случае вины со стороны разработчика я считаю нет.

Не дают открытый код

Часто видел обсуждение на форумах, что будет после разработки торгового робота, разработчик не хочет отдавать открытый код. По этому поводу нужно сразу договариваться перед разработкой робота. Заказчик платит за работу и получает в итоге готовый продукт, если же не было оговорено что будет также передаваться исходный код, то это уже отдельная статья расходов, которую нужно будет согласовать с разработчиком. «Я заплатил и хочу получить все что касается моего робота» или иные интерпретации – мое мнение такое, заказчик платит за работу, исходных код это опыт и наработки разработчика (а это дорого стоит).

Необходимо объяснить код робота

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

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

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

В итоге:

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