Обсуждение статьи "Как составить Техническое задание при заказе индикатора"
По результатам обсуждений в нескольких ветках начал писать для Заказчиков статью, которая была бы неким опросником при заказе робота или индикатора. Прошел только часть про заказ индикатора, оказалось уже больше 7 страниц. Поэтому решено вместо одной большой статьи сделать две поменьше - одна про заказ индикаторов и вторая про заказ робота.
Прошу всех заинтересованных высказывать здесь предложения/пожелания/критику текущей версии. На мой взгляд статья уже на 95-99% готова, но вполне допускаю, что какие-то моменты забыл, а какие-то искуственно притянул.
Не закончен последний пункт - Приемка и проверка индикатора - пока особых мыслей на этот счет нет. После обсуждения статья будет опубликована штатным образом, чтобы ею могли пользоваться Заказчики и Разработчики торговых приложений. Это еще не конструктор по составлению ТЗ, но уже попытка сделать простую понятную для Заказчика Инструкцию.
наверно толковей и лиричнее чем https://www.mql5.com/ru/articles/235 еще не видел
Тут в первом посте чет не очень план и суть просматривается
- 2011.03.30
- Andrey Khatimlianskii
- www.mql5.com
Странная структура статьи - никогда не было проблем (в заказах разумеется) со стилями индикаторов, цветами и пр. оформлением, с выводом нужных настроек, со стилями оформления скринов в ТЗ, перерисовками (если логика того что заказывают подразумевает перерисовки то ясное дело заказчик должен быть вкурсе), вычислениями на каждом тике (и зачем это знать юзеру?) - и так понятно что если можно сократить вычисления, то нужно именно так и делать.
Самое частое что путают - нумерация баров, что такое буфферы и чем они отличаются от граф.объектов, почему не нужно делать на граф.объектах (если это возможно, конечно), в какую папку ложить полученный файл, чем отличается исходник от исполняющего файла, хорошо бы чтоб еще примеры панели что нужна рисовали где-то в пейнте, а то в основном звучит "мне нужны три кнопки чтоб открывало, закрывало и чет еще".
При возникновении ошибки необходимо понять причину её появления. А значит, нужно попытаться получить все детали для расследования. В этом случае нужно не только показать ситуацию с помощью скриншотов или видео, но и предоставить разработчику логи программы и самого терминала. Поэтому вы должны не только знать, где находятся Журналы платформы, но и заранее в Техническом задании определить что именно должна выводить программа и в каком формате должны быть сообщения о её работе.
Не, для начала бы писали "что ожидалось. почему именно это ожидалось" и "вот что получилось - на каком-то баре какое-то значение не так" + на скриншоте дата и символ еще часто затертые + сет бы к этому всему... Но главное первые две вещи, а потом можно и попросить заказчика прислать еще лог и сет и т.д., иногда этого не нужно. А если еще заказывали несколько недель назад и только увидели что-то не так - ссылку на заказ. Часто вообще в сообщениях один скриншот вылазит и догадайся что не так и что за заказ вообще.
И там где "слишком мелкие рисунки" - я бы сказала, если бы увидела в ТЗ, "к чему эти рисунки?", но никак мне не мешает их оформление. Часто бывает в ТЗ вот так и нарисованные вершины, впадины и т.д. и заказчики надеяться что каким-то магическим образом программист все четко определит как в них в голове, нет определений как это искать.
Имею ввиду что в ТЗ не должно быть абстрактных понятий которые могут трактоваться двояко - это главное, а что там чет мелкое - совсем не мешает
наверно толковей и лиричнее чем https://www.mql5.com/ru/articles/235 еще не видел
Тут в первом посте чет не очень план и суть просматривается
Лирика не нужна - нужен достаточно сухой текст, который сможет дочитать Заказчик.
Я старался писать кратко, но все равно достаточно много получилось.
Лирика не нужна - нужен достаточно сухой текст, который сможет дочитать Заказчик.
Я старался писать кратко, но все равно достаточно много получилось.
если эта статья попытка систематизировать для будущего "мастера mql5" составления ТЗ, то надо убирать и убирать
если это чтоб пояснить заказчику что нужно, то добавлять и добавлять.
сейчас из текста непонятна конечная цель. Вид такой, вроде куски с экранов "мастера" достали, подсказочный стиль.
А для поясняющей статьи это не подходит вообще
Странная структура статьи - никогда не было проблем (в заказах разумеется) со стилями индикаторов, цветами и пр. оформлением, с выводом нужных настроек, со стилями оформления скринов в ТЗ, перерисовками (если логика того что заказывают подразумевает перерисовки то ясное дело заказчик должен быть вкурсе), вычислениями на каждом тике (и зачем это знать юзеру?) - и так понятно что если можно сократить вычисления, то нужно именно так и делать.
Идея была в том, что приходит Заказчик и говорит - "хочу индикатор чтобы:
- рисовал две красные линии и одну гистограмму
- гистограмма меняет цвет по такому то алгоритму
- индикатор должен использовать такие то цены и такой-то индикатор
- вычисления делать только на открытии бара
- состав и имена входных параметров такие-то
- при смене цвета отправлял мне Push
- писал в лог то-то
- для управления нужна панель с такими-то параметрами
- вот картинки с объяснениями"
Посмотрит потенциальный Исполнитель, прикинет быстренько трудозатраты и выдаст начальную стоимость работы без долгого изучения текста ТЗ.
То есть, облегчить и для Исполнителя обработку потенциальных заказов. Представьте, как в Макдональдсе делаете заказ.
Посмотрит потенциальный Исполнитель, прикинет быстренько трудозатраты и выдаст начальную стоимость работы без долгого изучения текста ТЗ.
То есть, облегчить и для Исполнителя обработку потенциальных заказов. Представьте, как в Макдональдсе делаете заказ.
Вот как и исполнитель говорю что это бесполезно, другие проблемы у заказчиков. А там как считаете нужным.
Что главное в индикаторе? Не линии, гитограмы, цвета, как считать (это должен знать программист, а не заказчик), не алерты или пуши, а ЛОГИКА именно что заказчик пытается вложить в индиатор, что он хочет получить с помощью индикатора, какие функции должен выполнить индикатор. Чтоб это заказчик мог адекватно объяснить, а остальное уже можно и потом согласовать. Разве что наличие и функции панели нужно заранее знать, а какой у нее там будет вид можно и потом узнать.
А у вас прям все наоборот, за логику совсем не сказано...
если это чтоб пояснить заказчику что нужно, то добавлять и добавлять.
Боюсь, что в итоге никто не прочитает. Большинство не дойдет до финиша
Что главное в индикаторе? Не линии, гитограмы, цвета, как считать (это должен знать программист, а не заказчик), не алерты или пуши, а ЛОГИКА именно что заказчик пытается вложить в индиатор, что он хочет получить с помощью индикатора, какие функции должен выполнить индикатор.
А у вас прям все наоборот, за логику совсем не сказано...
Логика - тут уже трудно придумать шаблон. Вот по вашему опыту - как это формализовать?
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Опубликована статья Как составить Техническое задание при заказе индикатора:
Трейдеры ищут закономерности в поведении рынка, указывающие на благоприятные моменты для совершения торговых сделок. Чаще всего первым шагом при разработке торговой системы является создание технического индикатора, который помогает увидеть на графике цен нужную ему информацию. Статья поможет вам составить Техническое задание для заказа индикатора во Фрилансе.
Формулировка Технического задания в виде Алгоритма
Каждый индикатор отражает какую-то идею. Поэтому сначала необходимо описать идею — словами и картинками, если это возможно. Без объяснения идеи понять, чего именно хочет Заказчик, будет намного сложнее.
Теперь можно приступать к описанию самого алгоритма работы/вычисления/отображения индикатора. Описывайте в виде последовательных операций, в виде алгоритма. Ведь только при наличии алгоритма Разработчик сможет написать код по нему. Если в описании идеи или алгоритма есть термины — четко опишите их, чтобы быть уверенными в том, что обе стороны одинаково понимают их значение.
По возможности четко нумеруйте и выстраивайте этапы алгоритма в той последовательности, как это будет потом работать. Не перескакивайте с одной части Технического задания на другую, не описав цельный законченный блок/модуль/этап Технического задания.
Для описания терминов лучше использовать списки, например:
Для обозначения этапов можно использовать цифры, списки и жирный шрифт.
Постарайтесь выстроить описание Технического задания в виде ряда действий, проистекающих последовательно одно за другим — в том же порядке, в котором будет исполняться программа, реализующая ваш индикатор. Ниже даны несколько примеров Технического задания.Автор: MetaQuotes Software Corp.