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

  1. Аватар b34rcava1ry
    Ребят, вы про ЕСПД серьезно сейчас? Там госты 78-79 г.в., и только два из 90х. Сейчас я их записками капитана очевидность называл бы.
    Лично я руководствуюсь старым, добрым «Половина правильного ответа содержится в вопросе». Нужно долго и мучительно рожать ФЗ, из него рожать ТЗ. И все это не работа программиста, аналитик должен этим заниматься. От хорошего ТЗ всегда тошнит и читать его тяжко и нудно, зато у погромиста не останется места для маневра. Ну и проверки тоже нельзя забывать, а то напишут вам софт и будут кормить вас «проблема на вашей стороне» пока не отвалите.
    Если нравятся стандарты ищите компании работающие по ГОСТ Р ИСО 9001-2015.
  2. Аватар 42
    Сейчас сотрудничаю по написанию скриптов с тремя программистами. Один из Русалго (отличная контора!), второй на вольных хлебах (ценит клиента!), а третья контора тут всем известна и пока называть я ее не буду. ТЗ простое, написать интерфейс для готового (и самое главное рабочего) скрипта для Квика. Договорились, порешали по цене, ПРЕДОПЛАТА 100% (я конечно прих… ел от такого), я перевел деньги, через неделю получил прогу и… началось… ничего не работает, на мои МОЛЬБЫ И ПРОСЬБЫ (за мои же с… ка деньги, которые сразу работают!!!) ответы однотипные… доделаем, разберемся проверим и т.д. Попросил уточнить сроки и тут беда… оказывается их вообще нет! Вся переписка в почте сохранена, если ребята меня дальше динамить будут видимо придется тут пост со всеми доказательствами выложить, что бы страна героев знала.

    В общем сплошное недопонимание между нами… я дал четкое и понятное задание, по которому вопросов не возникло и после согласования цены контора получила мои деньги, после чего интерес ко мне почти пропал… Что за люди… Потом жалуются, клиентов нет, денег нет, страна не такая, президент не такой...
  3. Аватар Ибрагим
    Печаль какая. «Формальное изучение технического задания разработчиком;» — это корень всех проблем. Если такой пункт есть — дальше можно вообще ничего не обсуждать. Нет мотивации — ничего не будет. Даже если Вы обложитесь ГОСТами. И потом — создание бота — это очень творческий процесс, но вы предлагаете программисту за Вас додумывать компоненты системы. Первое — не все это могут. Второе. Опять к пункту о мотивации. А вообще проще самому написать, а то что не смог — отдать на сторону.
  4. Аватар Tesseract
    Каждый разработчик и аналитик проходят этот путь) В результате, критичные вещи прописываются в документах, но ко всему подготовиться невозможно. 
  5. Аватар ves2010
    rbkm, разработка тз это отдельная работа… и за нее надо брать отдельные деньги…
    кстати внесение измений в готовое тз и всякие доработки оплачиваются тож  отдельно… крути клиента на бабосы!!! 
  6. Аватар rbkm
  7. Аватар rbkm

    У каждого своего понимания «копеечного заказа», для кого-то 100 000 рублей не деньги, для кого и 1000 уже много. По поводу стоимости, сумма от которой беремся за исполнения заказа выше, и конечная стоимость всегда рассчитывается на основании предоставленного технического задания. Выполняю заказы только по созданию торговых роботов. Уже как несколько лет не разрабатываем скрипты на луа и qpile. Сейчас только C#.

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

  8. Аватар Евгений
    ves2010, посмотрите на сайт автора. Исполнитель копеечных заказов. Какие госты, побойтесь бога. Вы ни разу не заказывали скрипты для луа за 5000 рублей. Закажите, деньги не большие. Узнаете много нового для себя.
  9. Аватар rbkm
    ves2010, вы пишите все правильно по поводу ГОСТ. 
    В плане разработки роботов, если это пишется с нуля программа для какого-то конкретного терминала, то так и должно быть (и заказчик должен быть готов платить за эти все пункты). Ну если все же разработка торгового робота ведется уже под какую-то готовую платформу, то часть пунктов можно опустить.
  10. Аватар ves2010
    Евгений, гост всего 10 страниц… там все толково и по-уму… все кто программируют не по гост — быдлокодеры… таких надо избегать...
    основные требования гост
    1 наличие ТЗ (тз обычно пишет сам программер по пожеланиям заказчика оно согласуется и за него идет отдельная оплата)
    2 словесного описания программы что каждый кусок делает… описание типов данных и глобальных переменных... 
    3 блок схемы главного алгоритма
    4 коменты к каждой 4-5ой строке кода на русском языке
    5 отдельно среда разработки + инструкция по установке
    6 исходники к проекту + инструкция по компиляции
    7 инструкция по эксплуатации 
    8 инструкция по тестированию + тестовые данные
    9  описание протоколов обмена данных и типа файловых данных

    это крайне важно и для самого программиста, т.к обычно ведутся несколько проектов 5-6 (и ты прикинь что это может быть не комп, а несколько типов различных микроконтроллеров с разной архитектурой и ассемблером) и иногда приходится вносить изменения в проект 2-3 летней давности и никуя уже помнишь что там было… открыл документацию — почитал — вспомнил… доработал...

    кроме того программер может уйти в отпуск, декрет, уволится… а на его место наймут доругого кодера который сможет налету подхватить проект

    самому прогеру такое тоже выгодно, т.к за каждый пункт отдельная оплата
  11. Аватар Евгений
    ves2010, вот сразу видно человека, ни разу не общавшегося с айтишниками :-) Не повезет кому-то с вами
  12. Аватар rbkm
    В идеале да. Но даже имея огромный опыт в разработке, и сталкиваясь с новым типом анализа, можно много чего не учесть, не зная, что такое может быть. Из последнего это было — закрытие за определённое время до конца свечи, и потом восстановление позиции, оказалось очень много ситуаций, который должны влиять на восстановление позиции.
  13. Аватар Artem
    rbkm, в идеале нужен какой-то «конструктор систем» — тогда заказчик будет сразу вынужден формулировать свои запросы в рамках какого-то стандарта. Но ввиду недостаточной еще массовости рынка, самое эффективное — это действительно некое интервью/обсуждение с заказчиком
  14. Аватар rbkm

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

  15. Аватар ves2010
    надо требовать оформление конструкторской документации на программный продукт в соответствии с требованиями гост… и 90% проблем сразу отвалится…  а кто гостов не читал или не готов по гостам работать сразу идет нах… неадекватов надо отсекать сразу
  16. Аватар Artem
    Спасибо автору! Статья описывает самое тяжелое и неприятное для заказчика — формулировать ТЗ.
    Вообще, есть подозрение, что большинство неудач заказчиков в процессе эксплуатации любых средств автоматизации торговли обусловлено именно небрежностью в точном формулировании своей изначальной идеи.
  17. Аватар rbkm
    Если есть знания и время, то почему бы не сделать самому. А что если нет хотя бы одного из этих пунктов? Вот тогда и приходится обращаться за реализацией к знающим людям и в этом случае нужно максимально подробно описать техническое задание и желательно с примерами, чтоб в готовом роботе получить все свои «хотелки».
  18. Аватар Kyani
    Из своего опыта хочу сказать, что мне иногда проще самому написать программу, чем составить такое ТЗ, чтобы у стороннего програмиста получилось именно то что хотелось. :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

В итоге:

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

Чтобы купить акции, выберите надежного брокера: