Сервис Работа: Нужен ли ТОП разработчиков в существующем формате - страница 29
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
С Новым Годом!
Было бы хорошо, если бы ТЗ был обязан написать или отредактировать именно программист. Сейчас тоже есть шаг "прототип", на котором программист может чётко показать клиенту: что именно будет разработано. Иногда, имея туманное или даже непонятное ТЗ, предлагаю клиенту согласиться, что чёткое ТЗ будет обеспечено мной на шаге "прототип - макет". Если клиент после корректировки ТЗ соглашается, что я понял его правильно, то подтверждает 3-й шаг. А если всё-таки ясность не внесена - договор должен быть разорван. Получается, корректируя ТЗ, хотя бы вижу, что клиент не пытается заставить меня работать бесплатно, ведь сумма договора уже заблокирована. Конечно тот факт, что клиент подтвердил таким образом 3-й шаг, не даёт никаких гарантий, что он будет доволен. Обращение клиента в арбитраж будет для программиста сплошной нервотрёпкой, поскольку ТЗ прикреплено старое (нечёткое). Идеальным вариантом была бы возможность замены ТЗ на 3-м этапе: после подтверждения программистом 3-го шага, но только до момента подтверждения 3-го шага заказчиком. После этого момента ТЗ должно быть уже неизменным. У программиста будет мотивация [работать над ТЗ]. По действующим сейчас правилам программист не обязан работать над ТЗ, или может это делать бесплатно.
То есть, проще говоря, мысль такая: 2-й шаг - предоставление ТЗ заказчиком с возможностью замены; 3-й шаг - обеспечение ТЗ программистом в его редакции и так же с возможностью замены.
(Ещё заметил, что некоторые пользователи дают ТЗ простым комментарием или прикреплённым файлом, категорически отказываясь подтверждать при этом 2-й шаг. Они говорят, якобы в правилах написано, что программист обязан ознакомиться с ТЗ и дать ответ, а только потом заказчик будет подтверждать 2-й шаг, на котором кстати становится видна его платёжеспособность. В таких случаях "ТЗ" всегда представляет собой список из нескольких сотен вопросов на многих листах. Такие пользователи весьма категоричны: "ты обязан дать мне подробнейшие разъяснения - обязан ответить на все мои вопросы - только тогда я поверю, что ты способен выполнить проект". При этом они "доказывают" наличие у них на счёте необходимой суммы при помощи скрин-шотов.)
Ренат! (С Н.Г., с Новым Счастьем Вас персонально).
Поскольку всем известно, что Заказчики (впрочем как и Исполнители) не читают Правила https://www.mql5.com/ru/job/rules. А именно в Парвилах выписано кратко и ёмко содержание конкретного этапа.
Может на странице в ветке заказа - над кнопкой "Далее" с подтверждением этапа - дублировать содержание текущего этапа из правил?
Также есть некоторое противоречие. После того как обе стороны подтвердили этап Согласование ТЗ - расторгнуть соглашение можно только через Арбитраж. Вы собираетесь публиковать соотношение арбитражных ситуаций в рейтинге. Это совершенно правильно. НО.
Поскольку известно, что у заказчика нет ТЗ, то должный разбор ТЗ на этапе Согласовение ТЗ сопряжён с риском отказа Заказчика от соглашения.
И окончательный разбор с ТЗ происходит фактически уже на этапе Прототип/Макет. Но именно на этом этапе выясняется, что ТЗ сложней чем виделось изначально, что ТЗ невыполнимо и т.д. и т.п.
Напрашивается "сам собой" вывод, что у Исполнителя должны быть самостоятельная способность расторгнуть соглашение - либо его не подписать на этапе Предоставление ТЗ - либо его расторгнуть на этапе Прототип/Макет.
Другими словами - в этапах должен быть реализован момент - когда Заказчик в рамках блокированной суммы - не может отказаться от соглашения, а Исполнитель может. Как это реализовать и с каким регламентом - это детали.
А что делать со временем, потраченным на разбор первоначального ТЗ? И кто компенсирует затраченные усилия?
Была такая ситуация, когда в ТЗ было написано сделать несколько окошек с некоторыми данными по некоторым парам и всё. А входе обсуждения ТЗ (договорились на 80 кр.) оказалось, что необходимо сделать полноценный шаблон с возможностью визуальной работы с лёгким и быстрым изменением любых данных в этих окнах, возможностью изменения их взаимного расположения в пару кликов и пр. и пр. Да ещё и обучить его вносить собственноручно изменения в исходник.
После полумесячного составления ТЗ, мы так надоели друг другу, что расторгли договор, но ... теперь у него имеется гораздо более продуманное ТЗ и более глубокое понимание того, что же на самом деле ему хотелось. Денег я от него не получил, но и за другие заказы не брался. Кто вернёт? А ведь я уже обязан был выполнить задание за 80. Хорошо, что арбитраж быстро разорвал нашу договорённость.
Это как-то необходимо учитывать. Либо возможность повышения стоимости после полного разбора ТЗ, либо работа по первоначальному ТЗ без повышения стоимости, либо быстрый разрыв договорённости.
А что делать со временем, потраченным на разбор первоначального ТЗ? И кто компенсирует затраченные усилия?
Отлично. Тоже архи-важный момент.
Типичная ситуация - разобрал Исполнитель ТЗ "по косточкам" - а Заказчик выбрал другого и предоставил этому "другому" уже понятное ТЗ. Причём часто первый Исполнитель ещё и представлен непрофессионалом другому разработчику.
Но на текущий момент - в том же Арбитраже - рассогласование на этапе обсуждения ТЗ - не учитывается.
Но в случае, когда разрыв через Арбитраж из-за ТЗ - Исполнитель попадает в негативную арбитражную статистику по себе - это тоже в корне неверно.
Арбитражная статистика должна классифицироваться по причинам арбитражных ситуаций.
А что делать со временем, потраченным на разбор первоначального ТЗ? И кто компенсирует затраченные усилия?
Была такая ситуация, когда в ТЗ было написано сделать несколько окошек с некоторыми данными по некоторым парам и всё. А входе обсуждения ТЗ (договорились на 80 кр.) оказалось, что необходимо сделать полноценный шаблон с возможностью визуальной работы с лёгким и быстрым изменением любых данных в этих окнах, возможностью изменения их взаимного расположения в пару кликов и пр. и пр. Да ещё и обучить его вносить собственноручно изменения в исходник.
После полумесячного составления ТЗ, мы так надоели друг другу, что расторгли договор, но ... теперь у него имеется гораздо более продуманное ТЗ и более глубокое понимание того, что же на самом деле ему хотелось. Денег я от него не получил, но и за другие заказы не брался. Кто вернёт? А ведь я уже обязан был выполнить задание за 80. Хорошо, что арбитраж быстро разорвал нашу договорённость.
Это как-то необходимо учитывать. Либо возможность повышения стоимости после полного разбора ТЗ, либо работа по первоначальному ТЗ без повышения стоимости, либо быстрый разрыв договорённости.
это риски, их Вы можете покрывать включая в стоимость следующих заданий.
это риски, их Вы можете покрывать включая в стоимость следующих заданий.
это риски, их Вы можете покрывать включая в стоимость следующих заданий.
Эти риски можно и нужно снижать. Этап согласования ТЗ должен быть безопасным для Исполнителя - с точки зрения рисков одностороннего расторжения со стороны Заказчика.
Если реализовать такую возможность, то количество обращений в Арбитраж по причине "расторжения от исполнителя", по причине "подводных камней ТЗ" и т.п. - сократится на треть.
Эти риски можно и нужно снижать. Этап согласования ТЗ должен быть безопасным для Исполнителя - с точки зрения рисков одностороннего расторжения со стороны Заказчика.
Если реализовать такую возможность, то количество обращений в Арбитраж по "расторжению от исполнителя", по "подводным камням ТЗ" и т.п. - сократится процентов на 30.
в таком случае если видно что ТЗ не формализовано, нужно указать на это заказчику и предложить услуги по составлению ТЗ(хотя бы до понятного для себя уровня), соответственно взять за это предоплату и спокойно работать.
ЗЫ: либо спихнуть какому-нибудь монстру что бы этот заказчик ему моск вынес )
в таком случае если видно что ТЗ не формализовано, нужно указать на это заказчику и предложить услуги по составлению ТЗ(хотя бы до понятного для себя уровня), соответственно взять за это предоплату и спокойно работать.
ЗЫ: либо спихнуть какому-нибудь монстру что бы этот заказчик ему моск вынес )
Сложившаяся практика показывает, что практически всегда в задании написано очень просто, легко, на час работы. При переговорах в обсуждении ТЗ оказывается, что всё совсем не так-то легко и просто - всплывают дополнительные условия, на эти условия накладываются следующие условия и так по-нарастающей. А цену исполнитель уже назначил. Приходится договариваться о повышении цены. Хорошо, когда заказчик это понимает и делает предоплату напрямую на счёт исполнителя, минуя этот сервис, а по окончании работы первоначальная цена за заказ переводится в виде кредитов в данном сервисе. Но, большинство же не соглашаются на повышение цены, мотивируя это тем, что раз я её уже назначил - делай. Мол он, заказчик, зная бы о более высокой цене, выбрал бы другого исполнителя, не потеряв со мной столько времени на объяснение мне (тупому) такого простейшего задания...
Такие ситуации имеют место быть и нужно как-то это регулировать.
Ещё мысль - зачастую, чтобы хоть чуть приподняться в ТОПпе, приходится прибегать к таким ситуациям. Работаю не только в этой системе. Нашёл стороннего заказчика, беру предоплату в 50 долларов, отсылаю его сюда и прошу сделать персональную заявку. Он делает, но далее, после получения заказа и перевода оставшейся суммы на мой счёт в данном сервисе, он ко мне более не возвращается - цены-то тут аховые и делает следующий заказ за 20, нежели ранее за 100. Думаю, нужно повышать нижнюю планку.
это риски, их Вы можете покрывать включая в стоимость следующих заданий.
Мне кажется, что повышение стоимости следующего задания - не панацея и, более того, весьма негативный фактор, сказывающийся как на заказчике (почему он должен нести дополнительные расходы за предыдущего заказчика), так и на исполнителе (повышая цену на заказ - мог сделать за 100, а предлагает за 120 - самостоятельно уменьшает собственные шансы быть выбранным в кач-ве исполнителя).
Скорее, нужно ввести изначально плату за составление чёткого ТЗ. Нужно заказчику, чтобы за него профессионал составил техзадание - отмечает галочку и автоматически платит больше (плюс к стоимости заказа, которую предложил исполнитель), если же у него есть чёткое ТЗ - отказывается от сторонней помощи в составлении ТЗ и получает работу по своему ТЗ. Я не говорю об элементарных уточняющих вопросах при разборе любого ТЗ.
Как-то так...
Сложившаяся практика показывает, что практически всегда в задании написано очень просто, легко, на час работы. При переговорах в обсуждении ТЗ оказывается, что всё совсем не так-то легко и просто - всплывают дополнительные условия, на эти условия накладываются следующие условия и так по-нарастающей. А цену исполнитель уже назначил. Приходится договариваться о повышении цены. Хорошо, когда заказчик это понимает и делает предоплату напрямую на счёт исполнителя, минуя этот сервис, а по окончании работы первоначальная цена за заказ переводится в виде кредитов в данном сервисе. Но, большинство же не соглашаются на повышение цены, мотивируя это тем, что раз я её уже назначил - делай. Мол он, заказчик, зная бы о более высокой цене, выбрал бы другого исполнителя, не потеряв со мной столько времени на объяснение мне (тупому) такого простейшего задания...
Такие ситуации имеют место быть и нужно как-то это регулировать.
Именно по этому сервису просто необходимо поставить дополнительный фильтр для определения уровня квалификации разработчика(кодера)
,,,что-бы заказчик имел перед глазами чёткую картину: к кому и с чем обращаться(с пересечением МА к Пете,с мульти к Васе, ну а с нейронной сеткой к Моисею конечно.)-(пример).
,,,и тогда необходимость с ТОПом отпадёт сама собой за не надобностью.