Обсуждение статьи "Как составить Техническое задание при заказе индикатора" - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Вынос мозга. Можно посмотреть, что в итоге имелось в виду? Заказчик представил изначально картинки или все только на словах было поначалу?
Рашид, там много страниц обсуждения - здесь оно лишнее, а индикатор я ещё не сделал - срок ещё не горит, да и другие дела важнее.
На мой взгляд в статье слишком много технических подробностей, которые заказчик никогда не осилит.
Сделаем для статьи ссылки, как у нас принято. Можно будет сразу увидеть нужный раздел и перепрыгнуть на него - даже не читая всю статью
Пример - MQL5.community - Памятка пользователя
1. Настройка профиля
2. Редактор сообщений
3. Избранное
4. Личные сообщения
5. Сервисдеск
6. Работа и расчеты
7. Маркет
8. Сигналы
9. RSS
10. Рейтинг
11 MQL5 Storage
Главное для самого заказчика, это четко представлять то, что он хочет на самом деле. Что бы получить это представление, заказчику не плохо было бы перед тем, как идти в фриланс, самому попробовать составить упрощенную схему работы индикатора/эксперта в Excel и снабдить свою схему скриншотами: как тот или иной сигнал выглядит на графике.
Хорошее пожелание. Хотя мне кажется, никто из Заказчиков этого не делает.
Хорошее пожелание. Хотя мне кажется, никто из Заказчиков этого не делает.
в том и проблема.
никто из них не думает в логике функций, формализаций и что там за чем вызывается. Как говорится если б у бабушки были, то она была бы дедушкой...
Заказчик воспринимают чарт 100% визуально. Даже понятие буфера для них темный лес.
Заказчик смотри на чарт и хочет, чтоб у него вот тут рисовалась линия, вот такой высоты, вот такой ширины. Подходы и пояснения очень конкретные
Вот на этой базе Рашид надо оставаться. Не стараться даже пытаться расширить его кругозор, ибо он загрузится и ничего не сделает что ты от него пытаешься, ибо ему надо пересмотреть взгляды на жизнь, а это долго, а нужно индикатор еще на вчера.
---
Нужно оставить заказчика сугубо в рамках его понятий (которые он уже себе придумал при обращении в фриланс).
И как раз не заказчику, а кодеру дать этот шаблонный вопросник, по которму он выспросит у заказчика данные по пунктам и впишет их по твоему стандарту.
А все что сверх этого - чистое общение которое (в отличии от написания торговых экспертов) не формализуешь никак.
то есть предлагаю так
- меняй подход к понятию ТЗ.
Теперь это не переписка или txt или doc с картинками, а неубиваемый аттрибут самой заявки. Это не приложенный документ, а компонент сервиса (в виде генерируемого xml документа).
Именно ТЗ в заявке, оформленное с помощью твоего мастера и подписанное обеими сторонами будет документом.
Отношение заказчика
- если ты уж очень хочешь чуток пригрузить заказчика инфой про возможности МТ, то при создании заявки не надо сразу требовать от заказчика заполнений всех полей. Достаточно получить от него, что там он смог в голове идентифицировать в рамках алгоритмических и MQL понятий. Отметить галками какие-то опции стилей, графики и т.д..
Отношение кодера
- ответственность за составление полного ТЗ и формализация всех функций заказчика лежит на кодере.
Он общается с заказчиком, заполняет компонент ТЗ детально, прописывает точные алгоритмы и понятия, чтоб их воспринял заказчик и утвердил. То есть создание ТЗ это процесс общения и утверждения. ТЗ - это часть заявки.
Даже если кодер откажется от работы - то наработанное ТЗ остается в заказе и с ним может продолжить работать другой исполнитель. Новый исполнитель не будет видеть переписки, но убдет видеть её результат - ТЗ.
---
Вот тогда и овцы целы, и заказчику мозг не сломаешь.
Заказчик доволен - его понял кодер и составил для него ТЗ.
Кодер доволен - он сделал утвержденное ТЗ с помощью мастера, и оно открытое, не корявое.
Арбитраж доволен - не надо вчитываться в сторонние доки, а только просматривать заполненный документ ТЗ в заявке.
По этим докам в будущем можно будет вообще статистику собрать, так как само ТЗ теперь формальный документ.
---
Нужно оставить заказчика сугубо в рамках его понятий (которые он уже себе придумал при обращении в фриланс).
И как раз не заказчику, а кодеру дать этот шаблонный вопросник, по которму он выспросит у заказчика данные по пунктам и впишет их по твоему стандарту.
А все что сверх этого - чистое общение которое (в отличии от написания торговых экспертов) не формализуешь никак.
Нужно попытаться. В процессе обсуждения этой ветки, кажется, начинаю немного менять концепцию статьи. Будет добавлен упор на составление поясняющих рисунков, будут даны несколько примеров ТЗ, а потом уже текущий контент пойдет. Для тех кто осилит первые два пункта.
то есть предлагаю так
- меняй подход к понятию ТЗ.
Теперь это не переписка или txt или doc с картинками, а неубиваемый аттрибут самой заявки. Это не приложенный документ, а компонент сервиса (в виде генерируемого xml документа).
Именно ТЗ в заявке, оформленное с помощью твоего мастера и подписанное обеими сторонами будет документом.
Сомневаюсь, что так получится загнать человечество в рай. Переиначивая классика:
Сомневаюсь, что так получится загнать человечество в рай. Переиначивая классика:
как мы не отмазываем кодера от составления ТЗ, но в конечном итоге его верифицирует именно кодер. И сложность его верификации закладывается в бюджет.
То есть платит за него в конечном итоге заказчик (платит за время кодера), думая что это такое программирование дорогое, а не формализация его ТЗ )
Будет добавлен упор на составление поясняющих рисунков, будут даны несколько примеров ТЗ, а потом уже текущий контент пойдет. Для тех кто осилит первые два пункта.
да, побольше скринов или микро gif.
особенно в мастере для принятия решения со стороны заказчика - какой тип индикатора указать в ТЗ, или какой вид линий. Чтоб не просто слова, а как это будет выглядеть. Ибо именно так он рассужает - что в итоге буду видеть и соответствует ли это его представлению
особенно в мастере для принятия решения со стороны заказчика - какой тип индикатора указать в ТЗ, или какой вид линий. Чтоб не просто слова, а как это будет выглядеть. Ибо именно так он рассужает - что в итоге буду видеть и соответствует ли это его представлению
Мастер ТЗ пока не планируется. Тут статью бы сначала полезную сделать и оценить результат её появления
Мастер ТЗ пока не планируется. Тут статью бы сначала полезную сделать и оценить результат её появления
да, пока под мастером подразумевал подсказочную статью.