Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Как это применить в "работе" ?
Итоговая оценка о заказчике и исполнителе. В самом процессе работы позвлят избежать споров и выяснения отношений. Оценка выдается в стандартной форме, буз субъективной интерпретации происходящего. Заказчик напишет, типа "что ты грубищь", исполнитель - "а что тыпишь" и понеслась... А здесь оценка в протокольной форме, на самом общении не отражается, позволят не скатиться к выяснению отношений. Но получил на очередной пост вместо пятерочки четверочку - есть повод задуматься.
Итоговая оценка о заказчике и исполнителе. В самом процессе работы позвлят избежать споров и выяснения отношений. Оценка выдается в стандартной форме, буз субъективной интерпретации происходящего. Заказчик напишет, типа "что ты грубищь", исполнитель - "а что тыпишь" и понеслась... А здесь оценка в протокольной форме, на самом общении не отражается, позволят не скатиться к выяснению отношений. Но получил на очередной пост вместо пятерочки четверочку - есть повод задуматься.
как по мне то вот тут очень хорошо это решено, я просидел на том сайте почти 2 года, и в принципе был доволен, правда есть у них и некоторые проблемы, но это другой разговор. Поэтому и предлагаю применить подобную систему оценок.
https://www.mql5.com/ru/forum/8700/page3#comment_356700
Здравствуйте. Ребята, не судите строго, так как я новичок на данном сервисе и хочу выразить свою мысль по данному поводу.
Проблема состоящая в недостаточной информативности на данном сервисе существует и безусловно необходимо что-то менять. Обо всех возможных «нечестностях» или необъективной оценки и заказчиков и исполнителей уже говорили выше - и это всегда будет, так как человеческий фактор влечет за собой множество составляющих (честность, пунктуальность, объективность и т.д.) и увы от этого не деться никуда. Предложенный вариант Рустамджаном - отличный. Но, хотел бы добавить – что, это удаленная работа и некоторые из исполнителей (возможно) часто затягивают сроки. Как мне кажется, это происходит как-то так: так, нужно сегодня доделать, а ладно разберусь на выходных. Ну, и т.д. После этого задается какой-то вопрос заказчику для уточнения. И такое поведение иногда превращается в цикличность - в итоге разработка затягивается на неопределенный срок. Исполнителю удобно, так как у него еще есть куча работы, а вот заказчик наоборот – находится в режиме ожидания и нервничает. Да, есть и другая сторона медали, когда заказчик пропадает куда-то или не может правильно выразить ответ или дать адекватное уточнение (тупит).
В данном случае (ОЧЕНЬ ВАЖНО), так как сроки на разработку только выставляются, то есть являются формальностью, а это никак не влияет на исполнение в срок. Я предложил бы вариант или хотя бы попросил Вас задуматься над этим:
Исполнителю нужно добавить график выполнения заказов, которые он берет (в его профиле).
В графике выполнения заказов после подтверждения ТЗ (еще до этой стадии исполнитель понял, с чем имеет дело и объявил заказчику сроки (уже с запасом) на разработку и стоимость) отмечается период разработки макета (подчеркиваю, именно макета).
Таким образом, исполнитель как и раньше может параллельно выполнять ряд заказов, но уже думает о том, стоит ли одновременно? Или при объявлении заказчику о цене и сроках говорит, с какого числа может приняться за работу. Тогда уже при соглашении сторон в календарном графике отмечается дата начала и окончания макета. А, такой подход уже является более прозрачным и правильным.
К такому решению наглядной организации труда программистов безусловно нужно прийти так как основная идея состоит в наглядности и прозрачности. Да, конечно, появятся масса вопросов и ситуаций, которые возникают и как их предусмотреть, но все можно продумать.
Спасибо за внимание!
Исполнителю нужно добавить график выполнения заказов, которые он берет (в его профиле).
В графике выполнения заказов после подтверждения ТЗ (еще до этой стадии исполнитель понял, с чем имеет дело и объявил заказчику сроки (уже с запасом) на разработку и стоимость) отмечается период разработки макета (подчеркиваю, именно макета).
детские мысли об упорядоченном мире.
график выполнения можно нарисовать разве что для вскапывания огорода.
95% заказов на эксперты MQL делается по такой схеме:
1. Составление ТЗ (до 3 дней) в зависимости от способностей обоих читать чужие мысли и объяснять свои.
2. Программирование эксперта (2-5 часов) в зависимости от уровня подготовки кодера. Особые случаи когда кодер называет цифру в неделю не беру. Это просто значит ему не до заказа.
3. Проверка эксперта на правильность - кодером до 60 минут, заказчиком - то уже не проблемы кодера.
Вы предлагаете создать график на время программирование 2-5 часов?
Ересь утопическая.
вы ж не боинг разрабатываете из отдельных модулей. В MQL - весь эксперт или индикатор - сам по себе один большой модуль, из которого ничего не выкинешь и нового не добавишь. какие могут быть графики? и думать тут даже нечего.
В графике выполнения заказов после подтверждения ТЗ (еще до этой стадии исполнитель понял, с чем имеет дело и объявил заказчику сроки (уже с запасом) на разработку и стоимость) отмечается период разработки макета (подчеркиваю, именно макета).
Я лично не понимаю что такое Макет и для чего он нужен? Одно дело когда разрабатывается сайт - там можно набросать макет, потому что сайты индивидуальны, а эксперт? в любом эксперте 90 % кода уже написано и отлажено грамотными программистами. Естественно индивидуальность есть у каждого заказчика, но это не проблема.
Вы думаете кодер будет писать сначала код построенный на алгоритме и состоящий из 10 строк (для тестера хватит) а потом это все уже кодить в нормальном виде? Зачем заниматься двойной работой?
Чтобы показать заказчику что-то, кодер сначала должен написать по ТЗ эксперта, а потом уже показывать картинки с тестера и так далее.
Другими словами, После получения ТЗ - время потраченной на эксперта, а именно в данном случае на макет - и есть время разработки эксперта, все остальные шаги - это лишь только показуха одного и того же в разных ракурсах.
2. Программирование эксперта (2-5 часов) в зависимости от уровня подготовки кодера. Особые случаи когда кодер называет цифру в неделю не беру. Это просто значит ему не до заказа.
Здесь стоит отметить что разработка индивидуальностей и тест работоспособности занимает такое время. Поэтому и цена адекватная. 5-10 $ в час в среднем - работа кодера по разработке алгоритма.
Если бы каждый программист, не пользовался своим отлаженным кодом и каждый раз начинал с чистого листа (0_о) Времени на программирование а потом и на тесты ушли бы неделями. Да и цена была бы соответствующая(300 - 400 долл за эксперта).
ИМХО.
Ну ребята, 2-5 часов это конечно здорово, но иногда задачи и посложнее бывают. так что не надо мерять всех по одной линейке. даже если предположить что я буду использовать свои готовые классы (а я их использую), то сверху них я все равно пишу в среднем 500 - 1000 строк кода, а чаще - больше. так что иногда времени уходит достаточно много, особенно если задуматься о оптимизации кода.
Я лично говорил о минимальном заказе , Индивидуальности у каждого свои, естественно бывают индивидуальности на новые функции- тогда и 1000 строк мало. Все относительно. Соответственно если заказ уж слишком индивидуальный - то требуется и 1 и два дня на код.
Также есть такой пункт как творчество. : Когда заказчик не точно описывает ТЗ, но говорит "Нужно как-то так"....