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