시장: 빌드 업데이트 후 제품이 실패하면 상황이 어떻게 해결됩니까?
...
추신. 지금까지 좋은 소식은 회사가 자체적으로 시장과 MQL5 제품의 판매를 개발하고 조직하고 지원한다는 것입니다. 결과적으로 품질에 대한 투쟁이 있을 것입니다. 그러나 누가 명성과 루블로 그 대가를 치르겠습니까?
질문은 매우 관련이 있습니다. 그리고 해결책을 찾아야 합니다. 이미 제안이 있습니다.
예를 들어 이렇게 할 수 있습니다. 거래 단말기 에 대한 다음 업데이트(빌드)를 설치하려면 사용자가 설치 여부를 결정합니다. 즉, 그가 새 빌드에 대해 알고 있는지 확인해야 하지만 언제 완료할 수 있는지는 그가 스스로 결정할 수 있습니다. 그런 다음 응용 프로그램 개발자는 두 가지 버전의 터미널을 설치해야 합니다. 이전 빌드가 있는 한 버전과 최신 빌드가 있는 두 번째 버전입니다. 제품 사용 시 새 빌드에서 버그가 발견되지 않으면 판매자는 해당 제품이 최신 빌드와 호환됨을 마켓에 메모합니다. 마지막 빌드의 제품이 "실패"하기 시작하면 표시를 설정하지 않고 사용자는 새 빌드를 설치하기에는 너무 이르다는 것을 알게 됩니다.
옵션같은데 그래도 생각해야지...
- 2011.01.05
- MetaQuotes Software Corp.
- www.mql5.com
사실 이 질문은 오래전부터 제기되어 왔습니다.
3당은 이제 어떻게 해야 할까요?
둘. 프로그래머는 그것과 아무 관련이 없습니다. 그리고 구매자는 새로운 시장 ex를 다운로드할 수만 있으면 됩니다. 편지, 요청, 보안 문자, 확인 알림 등이 없습니다.
물론, 그것이 이미 서있는 철에만.
제품에는 일반 버전이 있으며 https://www.mql5.com/ru/articles/385 기사에서 이에 대해 읽을 수 있습니다.
새 버전이 출시되면 프로그램 업데이트를 위한 자동 제안이 제공됩니다. 이 옵션은 2.xx와 같은 부 버전을 업데이트하는 데 적합합니다.
주요 릴리스는 기존 고객을 위한 자동 무료 업그레이드를 통해 이전 등록에 따라 새 버전을 재판매하거나 계속 릴리스하려면 새 제품을 등록해야 합니다.
- 2012.04.17
- MetaQuotes Software Corp.
- www.mql5.com
제품에는 정기적인 버전 관리가 있으며 https://www.mql5.com/en/articles/385 기사에서 이에 대해 읽을 수 있습니다.
새 버전이 출시되면 프로그램 업데이트를 위한 자동 제안이 제공됩니다. 이 옵션은 2.xx와 같은 부 버전을 업데이트하는 데 적합합니다.
주요 릴리스는 기존 고객을 위한 자동 무료 업그레이드를 통해 이전 등록에 따라 새 버전을 재판매하거나 계속 릴리스하려면 새 제품을 등록해야 합니다.
예, 이것은 제품의 새 버전에 관한 것입니다.
그러나 이것은 질문의 내용과 약간 다릅니다.
터미널의 새 빌드가 소프트웨어의 정상적인 작동을 차단하는 경우 수행할 작업에 관심이 있습니까?
예상대로 빌드는 한 달에 두 번 정도 나옵니다. 터미널을 업데이트하면 구매자는 몇 주 동안 제품을 사용할 기회를 잃게 됩니다. 여기에서 우리가 이야기하고 있는 것이 있습니다.
뿐만 아니라. 프로그래머는 현재 직장을 그만두고 버그를 잡기 시작해야 합니다. 그리고 시장에 여러 제품이 있다면?
누구나 치질에 걸립니다.
그러나 무엇이 해결책이 될 수 있습니까?
그러나 무엇이 해결책이 될 수 있습니까?
해결책이 없습니다.
수정된 새 빌드가 나타날 때까지 제품은 유휴 상태가 됩니다(또는 구매자에게 손실을 입히거나 이익을 줄 수 있습니다. 누가 알겠습니까? - 터미널 버그를 수정한 후 많은 사용자가 버그를 터미널 백?).
제품 사용 시 새 빌드에서 버그가 발견되지 않으면 판매자는 해당 제품이 최신 빌드와 호환됨을 마켓에 메모합니다 . 마지막 빌드의 제품이 "실패"하기 시작하면 표시를 설정하지 않고 사용자는 새 빌드를 설치하기에는 너무 이르다는 것을 알게 됩니다.
저것들. 판매자가 새 빌드에서 버그를 잡을 책임이 여전히 있습니까? 실제로 구매자가 제품을 사용하고(그리고 버그를 발견하면) MQ의 잘못으로 인해 문제가 발생하고(설명된 주제 내) 판매자가 랩을 가져가야 합니까?
...
옵션같은데 그래도 생각해야지...
이상적으로는 다음 솔루션이 표시됩니다(문제는 구현 가능한 정도입니다).
1- 터미널에서 업데이트 옵션의 자동 설치를 비활성화하고 가용성에 대한 메시지만 표시하고 사용자가 직접 결정합니다(이는 이미 어딘가에서 제안된 바 있음).
2- 터미널에서 "빌드 번호로 롤백 ..." 기능.
그러면 새 빌드의 글리치로 인한 EA 글리치의 경우 해당 빌드의 상황이 해결될 때까지 쉽게 임시 조치를 취할 수 있습니다. 특히 신중한 사람들은 추가 예방 조치로 휴일에 업데이트를 설치하고 테스터에서 Expert Advisor를 실행할 수 있습니다. 이전 빌드와 비교하여 히스토리를 작업하는 것이 적절하거나 적절하지 않음에 대해 업데이트 롤백을 선택하는 최종 결정을 내립니다.
어드바이저를 개발(판매)할 때 성능을 테스트한 빌드가 표시됩니다.
이상적으로는 다음 솔루션이 표시됩니다(문제는 구현 가능한 정도입니다).
1- 터미널에서 업데이트 옵션의 자동 설치를 비활성화하고 가용성에 대한 메시지만 표시하고 사용자가 직접 결정합니다(이는 이미 어딘가에서 제안된 바 있음).
2- 터미널에서 "빌드 번호로 롤백 ..." 기능.
그러면 새 빌드의 글리치로 인한 EA 글리치의 경우 해당 빌드의 상황이 해결될 때까지 쉽게 임시 조치를 취할 수 있습니다. 특히 주의하는 사람은 추가 예방 조치로 쉬는 날 업데이트를 설치하고 테스터에서 Expert Advisor를 실행할 수 있습니다. 이전 빌드와 비교하여 히스토리를 작업하는 것이 적절하거나 적절하지 않음에 대해 업데이트 롤백을 선택하는 최종 결정을 내립니다.
어드바이저를 개발(판매)할 때 성능을 테스트한 빌드가 표시됩니다.
예, 이것은 또한 합리적인 제안인 것 같습니다(유사한 tol64에서 즉시 제안한 대로).
주문형 빌드를 설치하는 것은 논리적인 방법입니다. 판매자와 구매자를 개발자로부터 보호합니다. :)
판매자는 새 빌드에서 제품을 보다 쉽게 테스트하고 필요한 경우 변경 사항과 새 버전을 제출할 수 있습니다.
플랫폼 개발자에 대한 요청 - 특히 이 주제와 이 제안에 대해 생각하십시오.
회사가 문제와 솔루션에 대한 고유한 비전을 갖고 있는 것은 아닐까요?
사실 이 질문은 오래전부터 제기되어 왔습니다.
상황은 다음과 같습니다. 아주 현실적입니다.소프트웨어를 테스트한 프로그래머와 시장 통제자는 그것을 시장에 내놓았습니다.
물론 이 상황에서 가장 짜증나는 것은 회사가 아닌 프로그래머의 평판이 훼손될 것이라는 점이다. 빌드의 문제는 여전히 식별되고 입증되어야 하기 때문입니다.일정 금액을 지불한 구매자는 새 빌드에서 얼마 후 제품이 작동을 멈췄음을 발견합니다.
확인. 프로그래머는 새 빌드에서 문제가 발생한 것을 확인했지만 버그가 있는 위치를 식별하고 현지화할 방법이 없습니다.
이제 3당은 어떻게 해야 할까요?
새로운 개발에 이미 투자되었을 수 있는 구매자에게 자금을 반환합니까?
구매자를 터미널 개발자에게 보내 문제가 빌드에 있으며 프로그래머의 잘못이 아니라고 말합니까?
아니면 다른 옵션?
이 기간 동안 제품은 많은 부정적인 리뷰를 받게 되며 선반에서 제거해야 할 수도 있습니다.
MQL 프로그래머는 플랫폼 개발자에 의존한다는 것이 밝혀졌습니다. 게다가 그들은 빌드의 어떤 속임수라도 새싹에서 평판을 망칠 수 있거나 미래의 주문이나 다른 계획을 방해할 수 있는 정도로 의존합니다.
일반적으로이 상황에서 어떤 방법이 계획되어 있으며 회사는 어떻게 해결할 수 있습니까?
추신. 지금까지 좋은 소식은 회사가 자체적으로 시장과 MQL5 제품 판매를 개발하고 조직하고 지원한다는 것입니다. 결과적으로 품질에 대한 투쟁이 있을 것입니다. 그러나 누가 명성과 루블로 그 비용을 지불할 것입니까?