당신의 논리에 따르면 프로그래머는 손실을 내는 Expert Advisor에 대해 고객에게 추가 비용을 지불해야 합니까? :-))
절대적으로 틀렸다. :)
고문이 주문형으로 작성된 경우 프로그래머에게는 이것이 작업이며 비용은 복잡성(볼륨)과 topicstarter가 표시한 요소(지역의 생활 수준 등)에 의해서만 결정됩니다. 프로그래머는 결과(전문가 고문의 수익성)에 대한 책임이 없으며 그의 임무는 고객의 요구 사항을 코드로 변환하는 것입니다. 동시에 고객은 상업적 위험(수익성 부족 가능성)을 스스로 부담하지만 동시에 출력이 Grail 인 경우 자신의 재량에 따라 다음을 포함하여 자유롭게 처분할 수 있습니다. 그리고 그것이 옳다고 생각하는 어떤 가격에라도 그것을 판다. 이것은 사업가와 직원 사이의 일반적인 관계입니다.
프로그래머 자신이 go의 생성자라면 그는 Grail의 소유자이기도 합니다. 실연자가 최종 제품에 대한 권리를 가질 수 있는 경우 중간 옵션도 가능합니다. 어쨌든 그런 고문의 가격은 인건비보다 성과에 훨씬 더 많이 좌우될 것이라고 생각합니다. 사실, 대화는 아무 것도 IMHO에 관한 것이 아닙니다. :)
아, 이 질문에 답할 수 있을지도 모릅니다. 나는 필요와 충분의 관점에서 참조 조건이 간결하고 명확하게 작성된 클라이언트를 만났습니다. 당신은 그러한 기술적 작업을 열고 그것을 읽고 한 사람에게 단 하나의 질문도 묻지 않습니다. 기술적 작업은 그가 원하는 것을 정확히 수행하기에 충분합니다.
사람들. 이러한 참조 조건을 구성하는 사람은 원칙적으로 이를 수행하기 전에 거래 시스템을 세심하게 검토하고 디버그하고 연마하여 완벽하게 만듭니다. 그들은 머리를 돌렸다. 그들의 결론은 가설이 아니라 정당합니다.
아, 이 질문에 답할 수 있을지도 모릅니다. 나는 필요와 충분의 관점에서 참조 조건이 간결하고 명확하게 작성된 클라이언트를 만났습니다. 당신은 그러한 기술적 작업을 열고 그것을 읽고 한 사람에게 단 하나의 질문도 묻지 않습니다. 기술적 작업은 그가 원하는 것을 정확히 수행하기에 충분합니다.
사람들. 이러한 참조 조건을 구성하는 사람은 원칙적으로 이를 수행하기 전에 거래 시스템을 세심하게 검토하고 디버그하고 연마하여 완벽하게 만듭니다. 그들은 머리를 돌렸다. 그들의 결론은 가설이 아니라 정당합니다.
이것은 드물게 발생하지만 발생합니다.
그 중 몇 개만 있습니다 :) 거래 아이디어가 몇 번이나 발생했는지 스스로 알고 차트에서 시각적으로 검사했습니다. 모든 것이 훌륭합니다. 그런 다음 그는 방법에 따라 지표를 작성하고 처음에 (완전히 의도하지 않게) "보고 싶지 않은"다른 경우를 알아 차리기 시작했습니다. 음, 고문 - 마침내 환상을 제거합니다. :)
당신의 논리에 따르면 프로그래머는 손실을 내는 Expert Advisor에 대해 고객에게 추가 비용을 지불해야 합니까? :-))
절대적으로 틀렸다. :)
고문이 주문형으로 작성된 경우 프로그래머에게는 이것이 작업이며 비용은 복잡성(볼륨)과 topicstarter가 표시한 요소(지역의 생활 수준 등)에 의해서만 결정됩니다. 프로그래머는 결과(전문가 고문의 수익성)에 대한 책임이 없으며 그의 임무는 고객의 요구 사항을 코드로 변환하는 것입니다. 동시에 고객은 상업적 위험(수익성 부족 가능성)을 스스로 부담하지만 동시에 출력이 Grail 인 경우 자신의 재량에 따라 다음을 포함하여 자유롭게 처분할 수 있습니다. 그리고 그것이 옳다고 생각하는 어떤 가격에라도 그것을 판다. 이것은 사업가와 직원 사이의 일반적인 관계입니다.
프로그래머 자신이 go의 생성자라면 그는 Grail의 소유자이기도 합니다. 실연자가 최종 제품에 대한 권리를 가질 수 있는 경우 중간 옵션도 가능합니다. 어쨌든 그런 고문의 가격은 인건비보다 성과에 훨씬 더 많이 좌우될 것이라고 생각합니다. 사실, 대화는 아무 것도 IMHO에 관한 것이 아닙니다. :)
절대적으로 틀렸다. :)
오토즈.. :-))
그리고 수익성 / 비수익성의 특정 매개 변수를 사용하여 프로그래머에게 고문 (전략)을 주문하는 것은 일반적으로 유토피아입니다. :-))
xeon :
그리고 수익성 / 비수익성의 특정 매개 변수를 사용하여 프로그래머에게 고문 (전략)을 주문하는 것은 일반적으로 유토피아입니다. :-))
나는 이것에 대해 어디에도 쓰지 않았다. TK의 구현에 관한 것이었습니다.
프로그래머는 결과(전문가 고문의 수익성)에 대한 책임이 없으며 그의 임무는 고객의 요구 사항을 코드로 변환하는 것 입니다.
그리고 수익성 / 비수익성의 특정 매개 변수를 가진 프로그래머에게 고문 (전략)을 주문하는 것은 일반적으로 유토피아입니다. :-))
라는 말이 있습니다...
시장에는 두 명의 바보가 있고, 하나는 팔고 다른 하나는 사
--
평균적으로 코드당 1000달러를 지불하면 가격을 인하하지 않습니다.
나는 적절한 수의 클라이언트를 제공하고 지원 인건비를 보상할 최소한의 코드를 판매할 것입니다.
--
여기서 일회성 주문과 스트리밍 판매를 분리할 가치가 있습니다!
사람이 개별적으로 무언가를 주문하면 일반적으로 그러한 물건이 유통되지 않기 때문에 가격이 더 높습니다.
또한 - 개발의 개성으로 인해, 읽어보십시오 - (타는 거래 전략의 오해로 인해 신청할 수 없습니다)
그리고 그 이유 때문에 - 고객은 기밀을 요구합니다 ..
이틀 동안 일회성 주문을 작성한 다음 일주일 동안 가져 와서 $ 100에 판매 할 수 있습니다. 그러나 이것은 수행자 입장에서 어리석은 일입니다.
--
스트리밍 방법을 판매하십시오. $100 코드는 괜찮습니다. $500 또는 $1000에 한 사본을 판매하는 것보다 $100에 20개 사본을 판매하는 것이 좋습니다.
판매는 경제적으로 실행 가능해야 합니다
---
당신의 일에 가치를 두지 않는 사람들을 위해:
합리적이지 않음 = $5 -20에 대한 각 주문에 대해 마당 개처럼 실행, $5에 대해 쓰는 주제가 있었습니다 ... 누군가가 $10에 대해 썼습니다 t p p
누군가는 일반적으로 자유롭습니다 ... 이타주의자는 항상 ... 그러나 그들의 지원은 자유 노동과 동일합니다
--
$5에 20개 주문하는 것보다 $100에 하나를 작성하는 것이 좋습니다.
--
가격은 시장에 의해 결정된다고 생각하기 때문에 - 상점의 소시지 가격, 저녁의 택시 가격 ...
상점의 보드카 가격, 임대 아파트 가격 및 기타 경제 지표, 아파트에 화장실 설치 가격
한 시간 안에 코드를 작성한다면! 코드를 $100에 판매합니다. 괜찮습니다!!!
결국 배관공이 변기를 설치하러 오면 5달러가 아니라 최소 200달러에 설치하고 설치하는 데 2시간도 채 걸리지 않습니다.
한 푼에 판매를 위해 코드를 작성하는 녀석들! 배관공보다 더 멍청합니까? 당신은 당신의 학습에 시간과 에너지를 보냈다
당신은 고등 교육을 받았습니다 ... 원칙적으로 ... 그들은 200 달러에 몇 시간 만에 변기를 넣어 ... 그리고 당신은 5 달러를 씁니다?
시장은 이 상황을 바로잡을 것입니다... 최초의 변기로!
...
결국 배관공이 변기를 설치하러 오면 5달러가 아니라 최소 200달러에 설치하고 설치하는 데 2시간도 채 걸리지 않습니다.
사용자의 눈으로 본다면 변기는 몇 년은 갈지 모르지만 구입한 Advisor 는 어떻게 될지 아무도 모른다는 것이 차이점입니다.
사용자의 눈으로 보면 변기는 몇 년은 가는데, 구입한 어드바이저는 어떻게 될지 아무도 모른다는 차이가 있다.
EA는 다음과 같이 작동합니다 - 사용자가 주문한 대로
(물론 그 - 참조 조건의 사용자가 적절하지 않은 경우)
바로 말하겠습니다 ... 좋은 인연을 가진 녀석들이 만나요!
그리고 나서 ... 그것은 그에게 달려 있습니다 ...
추신
비교는 물론 과장된 것입니다 ... 그러나 여기서 문자 그대로 비교할 필요는 없지만 본질 만
EA는 다음과 같이 작동합니다 - 사용자가 주문한 대로
(물론 그 - 참조 조건의 사용자가 적절하지 않은 경우)
바로 말하겠습니다 ... 좋은 인연을 가진 녀석들 만나요!
그리고 나서 ... 그것은 그에게 달려 있습니다 ...
"좋은 사양"의 특징은 무엇입니까?
"좋은 사양"의 특징은 무엇입니까?
아, 이 질문에 답할 수 있을지도 모릅니다. 나는 필요와 충분의 관점에서 참조 조건이 간결하고 명확하게 작성된 클라이언트를 만났습니다. 당신은 그러한 기술적 작업을 열고 그것을 읽고 한 사람에게 단 하나의 질문도 묻지 않습니다. 기술적 작업은 그가 원하는 것을 정확히 수행하기에 충분합니다.
사람들. 이러한 참조 조건을 구성하는 사람은 원칙적으로 이를 수행하기 전에 거래 시스템을 세심하게 검토하고 디버그하고 연마하여 완벽하게 만듭니다. 그들은 머리를 돌렸다. 그들의 결론은 가설이 아니라 정당합니다.
이것은 드물게 발생하지만 발생합니다.
아, 이 질문에 답할 수 있을지도 모릅니다. 나는 필요와 충분의 관점에서 참조 조건이 간결하고 명확하게 작성된 클라이언트를 만났습니다. 당신은 그러한 기술적 작업을 열고 그것을 읽고 한 사람에게 단 하나의 질문도 묻지 않습니다. 기술적 작업은 그가 원하는 것을 정확히 수행하기에 충분합니다.
사람들. 이러한 참조 조건을 구성하는 사람은 원칙적으로 이를 수행하기 전에 거래 시스템을 세심하게 검토하고 디버그하고 연마하여 완벽하게 만듭니다. 그들은 머리를 돌렸다. 그들의 결론은 가설이 아니라 정당합니다.
이것은 드물게 발생하지만 발생합니다.
그 중 몇 개만 있습니다 :) 거래 아이디어가 몇 번이나 발생했는지 스스로 알고 차트에서 시각적으로 검사했습니다. 모든 것이 훌륭합니다. 그런 다음 그는 방법에 따라 지표를 작성하고 처음에 (완전히 의도하지 않게) "보고 싶지 않은"다른 경우를 알아 차리기 시작했습니다. 음, 고문 - 마침내 환상을 제거합니다. :)