Кто работает в фрилансе, поделитесь "критериями приёма" работы заказчиком
(из наболевшего)
Есть такая проблема, что заказчик давая ТЗ не описывает в нем как он будет принимать работу, а главное как он будет убеждаться в том, что эксперт выполняет блоки согласно его ожиданиям.
Заказчик не описывает ничего, что бы он хотел видеть на чарте или в логе, что позволяло бы ему убедиться в правильности работы эксперта. И что могло бы быть доказательством корректности работы эксперта.
И мало этого, он еще может упираться руками и рогами, когда начать пояснять ему важность и ответственность этой информации.
---
Кто имел положительный опыт, подскажите, какие критерии приема работы используют заказчики?
Какую информацию они просят. Чем в основном пользуются для показа и контроля (лог, чарт, графика, файлы)?
и т.д.
Напишите реальные примеры критерием и информации пожалуйста.
часто просят подробно комментировать код, вывод в лог сообщений об ошибках
маломальская индикация на чарте: объем, эквити, количество ордеров.
по большей части тестирование перекладываю на заказчика, потому как он заказчик и он должен принимать, принял - значит все соответствует
выявленные недочеты соответственно исправляются.
Кто имел положительный опыт, подскажите, какие критерии приема работы используют заказчики?
Какую информацию они просят. Чем в основном пользуются для показа и контроля (лог, чарт, графика, файлы)?
и т.д.
Напишите реальные примеры критерием и информации пожалуйста.
Если что-то не видит заказчик - нужно готовится к куче вопросов "а почему тут открылось?", " а почему тут не открылось?".
Заказчик не программист и дебажить код не будет - вся инфа должна быть на графике/логе и для программиста и для заказчика.
Например, если в советнике используется сигнал от кучи индикаторов - обязательно делаю вывод на график со значениями всех индикаторов. Да это доп работа, но она реально окупается т.к. куча вопросов может достать не менее. Если эта опция мешает заказчику в будущем - делаю отключение.
В лог вывожу разовые расчеты - например, расчет лота в зависимости от серии пред. ордеров каждый раз при открытии ордера. Заказчик то не может увидеть расчеты в коде (на то он и заказчик) и ему нужно знать что сверять. Так же, если что-то не будет совпадать в расчетах - сразу будет видно, не нужно прогонять эн раз в том числе и программисту.
Ну а как заказчики проверяют - то это уже кто на что гаразд, многие хотят сделать, но сами не представляют как проверить. Часто нужно каждый раз объяснять что такое лог, были случаи когда объясняла что такое тестер. В основном все адекваты и когда видят что соответствует ТЗ - принимают работу
Если что-то не видит заказчик - нужно готовится к куче вопросов "а почему тут открылось?", " а почему тут не открылось?".
Заказчик не программист и дебажить код не будет - вся инфа должна быть на графике/логе и для программиста и для заказчика.
Например, если в советнике используется сигнал от кучи индикаторов - обязательно делаю вывод на график со значениями всех индикаторов. Да это доп работа, но она реально окупается т.к. куча вопросов может достать не менее. Если эта опция мешает заказчику в будущем - делаю отключение.
В лог вывожу разовые расчеты - например, расчет лота в зависимости от серии пред. ордеров каждый раз при открытии ордера. Заказчик то не может увидеть расчеты в коде (на то он и заказчик) и ему нужно знать что сверять. Так же, если что-то не будет совпадать в расчетах - сразу будет видно, не нужно прогонять эн раз в том числе и программисту.
Ну а как заказчики проверяют - то это уже кто на что гаразд, многие хотят сделать, но сами не представляют как проверить. Часто нужно каждый раз объяснять что такое лог, были случаи когда объясняла что такое тестер. В основном все адекваты и когда видят что соответствует ТЗ - принимают работу
выводить на график, мне кажется, лишнее, достаточно сделать шаблон с индикаторами, и все значения смотреть окне данных
Все в лог, каждое действие советника можно объяснить по логу, почему он это сделал или не сделал.
Некоторые особо интересные данные на инфопанель.
В меню (по желанию) опция откл. лог. Это уже после того как советник много поработал и претензий к его работе нет.
выводить на график, мне кажется, лишнее, достаточно сделать шаблон с индикаторами, и все значения смотреть окне данных
осталось это объяснить заказчику, причем каждому
осталось это объяснить заказчику, причем каждому
нее, ну одно дело требует, другое дело эта информация ему вообще не нужна.
Все в лог, каждое действие советника можно объяснить по логу, почему он это сделал или не сделал.
Некоторые особо интересные данные на инфопанель.
Это ваше желание?
- тут интересует именно то, что просят сами заказчики. Какую инфу и куда.
- И как вы боретесь с упёртыми, которые не считают своей обязанностью контролировать работу.
Считаю, что наиболее правильно использовать трассировочный вывод.
У меня имеются макросы TRACE(), которые в релизе пустые, а в дебаге - раскрываются в написание сообщений в лог-файл.
Соответственно, в коде при "любом чихе" - вызываются эти макросы, и в лог-файл скидываются все-все-все маломальски важные рабочие моменты. Потом по лог-файлу - можно проследить, где и как были произведены те или иные действия.
- И как вы боретесь с упёртыми, которые не считают своей обязанностью контролировать работу.
Лично я - просто не беру заказы.
Проблем больше, чем заработка.
"Нет человека - нет проблемы".
нее, ну одно дело требует, другое дело эта информация ему вообще не нужна.
Доказать нужно что ему это еще нужно) Это те же самые пол пол часа за которые (или меньше) без него могу все вывести. Да хорошие все заказчики, но некоторые не используют те или иные опции терминала.
Это ваше желание?
- тут интересует именно то, что просят сами заказчики. Какую инфу и куда.
- И как вы боретесь с упёртыми, которые не считают своей обязанностью контролировать работу.
ничего не просят, а если просят то это обговорено в ТЗ и чаще управляющие элементы (кнопки для выставления ордеров, линий и т.д. Едиты для установки настроек прям на графике) или "сумма профита за день/неделю/месяц", состояние ордеров (напр, количество сеток, профит по каждой сетки)
никак, пусть принимают работу тогда как есть (я проверила на баги и хватит). За всю историю у меня был только один заказчик в стиле "проверьте все за меня".
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
(из наболевшего)
Есть такая проблема, что заказчик давая ТЗ не описывает в нем как он будет принимать работу, а главное как он будет убеждаться в том, что эксперт выполняет блоки согласно его ожиданиям.
Заказчик не описывает ничего, что бы он хотел видеть на чарте или в логе, что позволяло бы ему убедиться в правильности работы эксперта. И что могло бы быть доказательством корректности работы эксперта.
И мало этого, он еще может упираться руками и рогами, когда начать пояснять ему важность и ответственность этой информации.
---
Кто имел положительный опыт, подскажите, какие критерии приема работы используют заказчики?
Какую информацию они просят. Чем в основном пользуются для показа и контроля (лог, чарт, графика, файлы)?
и т.д.
Напишите реальные примеры критерием и информации пожалуйста.