소스 코드는 많은 추가 기능, 클래스 등이 포함된 잘 설계된 템플릿이 될 수 있습니다. 여러 블록(예: 포함)으로 구성될 수 있으며 일부 조건만 다를 수 있습니다. 신호 모듈만 다른 한 시스템(서로 상호 작용의 의미에서 시스템)의 12가지 다른 파일의 소스 코드에서 반년(간단한 경우) 작동 시간을 제공할 준비가 되셨습니까? 하나의 클래스(파일))?
나는 당신이 체커의 교차점을 강타하기 위해 표준 수단을 사용할 수 있다는 것을 이해하며 유감스럽지 않습니다. 그리고 템플릿에 엄청난 작업이 투자된다면 어떻게 될까요? 아니, 준비됐어?
이러한 경우 고객의 재량에 따라 템플릿을 컴파일된 파일과 신호 모듈로 제공하는 것이 좋습니다. 이 옵션(이미 언급됨)이 모든 사람에게 적합합니까?
... 그러나 이 경우 "신규 구축"의 위험은 고객에게 전가되며 이러한 위험을 제거한다는 보장은 오직 계약자의 양심에 달려 있습니다.
여기에 근본적인 실수가 있습니다. 계약은 둘 이상의 사람 간의 계약입니다. 신청서는 한 당사자의 제안일 뿐이며 그 자체로는 계약으로 간주될 수 없습니다. 논의중인 규칙의 본질에 따라 계약 관계의 출현 (계약 체결)은 약관의 실행 후에 만 판단 할 수 있습니다. 양 당사자가 합의한 작업의 모든 세부 사항을 반영하기 위한 것은 참조 조건입니다.
나는 우리의 경우 애플리케이션이 계약이라고 주장하지 않았고, 애플리케이션이 계약에 가깝고(즉, 애플리케이션에 내 의견으로는 일부 필수 필드/체크 표시가 있어야 함) TOR이 수행 된 작업의 기능을 더 자세히 설명하고 수행자가 준수해야 할 특정 사항을 결정합니다.
동시에 프로그래머가 아닌 거래자의 최소 60%는 TOR의 절반을 무시할 것이라고 확신합니다.
동시에 프로그래머가 아닌 거래자의 최소 60%는 TOR의 절반을 무시할 것이라고 확신합니다.
그렇기 때문에 계약서 작성 시 (특정 규칙에 비추어) 계약자가 작업의 세부 사항에 동의하고 문서에 반영하는 데 과감하게 주도해야 한다고 주장하고 계속 주장합니다. 이 경우 고객의 클레임을 제기해야 하는 것은 계약자이기 때문입니다. 그리고 계약자의 잘못으로 서투르게 작성된 참조 조건은 불필요한 분쟁의 출현에만 기여할 것입니다.
Yedelkin : 이러한 경우 고객의 재량에 따라 템플릿을 컴파일된 파일과 신호 모듈로 제공하는 것이 좋습니다. 이 옵션(이미 언급됨)이 모든 사람에게 적합합니까?
모두에게 해당되는 것은 아닙니다.)) 하지만, 물론 이것도 선택사항입니다... 저에게는 미리 만들어진 파일이 하나 있는 것이 더 편리합니다. 이것은 작업을 복잡하게 만듭니다('비용' 읽기). 그러나 대화는 그것에 대한 것조차 아닙니다. 그러한 접근 방식은 아이디어를 분기하고 고객은 그런 점에서 더듬거리지 않습니다(또는 더듬거릴 수 있습니다! 그들은 다를 수 있습니다. 비록 그가 바보는 아니지만)) "나는 소스 코드를 원합니다" 체크박스로 충분하다고 생각합니다. 계약 tz 전에 대부분의 문제를 해결할 것입니다. 이 질문이 명확하면 작업에 대해 더 논의할 수 있습니다. 풀은 자라지 않지만 완전히 다른 단계입니다.
pronych : 모두에게 해당되는 것은 아닙니다.)) 하지만, 물론 이것도 선택사항입니다... 저에게는 미리 만들어진 파일이 하나 있는 것이 더 편리합니다. 이것은 작업을 복잡하게 만듭니다('비용' 읽기). 그러나 대화는 그것에 대한 것조차 아닙니다. 그러한 접근 방식은 아이디어를 분기하고 고객은 그런 점에서 더듬거리지 않습니다(또는 더듬거릴 수 있습니다! 그들은 다를 수 있습니다. 비록 그가 바보는 아니지만)) "나는 소스 코드를 원합니다" 체크박스로 충분하다고 생각합니다. 계약 tz 전에 대부분의 문제를 해결할 것입니다. 이 질문이 명확하면 작업에 대해 더 논의할 수 있습니다. 풀은 자라지 않지만 완전히 다른 단계입니다.
Yedelkin : 그렇기 때문에 계약서 작성 시 (특정 규칙에 비추어) 계약자가 작업의 세부 사항에 동의하고 문서에 반영하는 데 과감하게 주도해야 한다고 주장하고 계속 주장합니다. 이 경우 고객의 클레임을 제기해야 하는 것은 계약자이기 때문입니다. 그리고 계약자의 잘못으로 서투른 위임 조건은 불필요한 분쟁의 발생에만 기여할 것입니다.
응. 이것은 가능성이 있습니다. 그럼 바로 (조용히, 개발자들이 잠든 사이에) 생각해보자)), '작업' 섹션에서 어떤 추가 사항을 요청하고 싶나요? 하지만 내가 먼저!
제 생각에는 또 다른 대안이 있습니다. 특정 중개자(우리의 경우 MQ)가 계약자와 고객 사이에 있는 반면 계약자는 전체 자료 패키지 + 소스 코드를 중개자(누가 확인하는지 확인합니다. TOR 준수를 위해), 그 후 고객은 중개자로부터 작업 완료에 대해 통지를 받고 비용을 지불해야 합니다.
작업의 독점성과 초기 계약에 따라 지불 후 고객은 가장 오픈 소스 코드를 받거나 그냥 컴파일된 파일을 받습니다.
그리고 여기에 문제를 해결하기 위한 개념적으로 다른 접근 방식이 있습니다. :)
소스 코드는 많은 추가 기능, 클래스 등이 포함된 잘 설계된 템플릿이 될 수 있습니다. 여러 블록(예: 포함)으로 구성될 수 있으며 일부 조건만 다를 수 있습니다. 신호 모듈만 다른 한 시스템(서로 상호 작용의 의미에서 시스템)의 12가지 다른 파일의 소스 코드에서 반년(간단한 경우) 작동 시간을 제공할 준비가 되셨습니까? 하나의 클래스(파일))?
나는 당신이 체커의 교차점을 강타하기 위해 표준 수단을 사용할 수 있다는 것을 이해하며 유감스럽지 않습니다. 그리고 템플릿에 엄청난 작업이 투자된다면 어떻게 될까요? 아니, 준비됐어?
이러한 경우 고객의 재량에 따라 템플릿을 컴파일된 파일과 신호 모듈로 제공하는 것이 좋습니다. 이 옵션(이미 언급됨)이 모든 사람에게 적합합니까?
... 그러나 이 경우 "신규 구축"의 위험은 고객에게 전가되며 이러한 위험을 제거한다는 보장은 오직 계약자의 양심에 달려 있습니다.
여기에 근본적인 실수가 있습니다. 계약은 둘 이상의 사람 간의 계약입니다. 신청서는 한 당사자의 제안일 뿐이며 그 자체로는 계약으로 간주될 수 없습니다. 논의중인 규칙의 본질에 따라 계약 관계의 출현 (계약 체결)은 약관의 실행 후에 만 판단 할 수 있습니다. 양 당사자가 합의한 작업의 모든 세부 사항을 반영하기 위한 것은 참조 조건입니다.
나는 우리의 경우 애플리케이션이 계약이라고 주장하지 않았고, 애플리케이션이 계약에 가깝고(즉, 애플리케이션에 내 의견으로는 일부 필수 필드/체크 표시가 있어야 함) TOR이 수행 된 작업의 기능을 더 자세히 설명하고 수행자가 준수해야 할 특정 사항을 결정합니다.
동시에 프로그래머가 아닌 거래자의 최소 60%는 TOR의 절반을 무시할 것이라고 확신합니다.
나는 우리의 경우 응용 프로그램이 계약이라고 말하지 않았습니다 ...
... 정상적인 조건에서 계약 (응용 프로그램 읽기) ...
동시에 프로그래머가 아닌 거래자의 최소 60%는 TOR의 절반을 무시할 것이라고 확신합니다.
이러한 경우 고객의 재량에 따라 템플릿을 컴파일된 파일과 신호 모듈로 제공하는 것이 좋습니다. 이 옵션(이미 언급됨)이 모든 사람에게 적합합니까?
모두에게 해당되는 것은 아닙니다.)) 하지만, 물론 이것도 선택사항입니다... 저에게는 미리 만들어진 파일이 하나 있는 것이 더 편리합니다. 이것은 작업을 복잡하게 만듭니다('비용' 읽기). 그러나 대화는 그것에 대한 것조차 아닙니다. 그러한 접근 방식은 아이디어를 분기하고 고객은 그런 점에서 더듬거리지 않습니다(또는 더듬거릴 수 있습니다! 그들은 다를 수 있습니다. 비록 그가 바보는 아니지만)) "나는 소스 코드를 원합니다" 체크박스로 충분하다고 생각합니다. 계약 tz 전에 대부분의 문제를 해결할 것입니다. 이 질문이 명확하면 작업에 대해 더 논의할 수 있습니다. 풀은 자라지 않지만 완전히 다른 단계입니다.
그러면 어떻게 될까요? 문제에 대한 작업 솔루션은 다음과 같습니다.
1. 형식적인 측면에서 - 규칙의 새로운 단락 ;
2. 기술적인 측면에서 - 신청서 양식에 "소스 코드 필요" 옵션을 기본 "필수 아님"으로 입력합니까?
그렇기 때문에 계약서 작성 시 (특정 규칙에 비추어) 계약자가 작업의 세부 사항에 동의하고 문서에 반영하는 데 과감하게 주도해야 한다고 주장하고 계속 주장합니다. 이 경우 고객의 클레임을 제기해야 하는 것은 계약자이기 때문입니다. 그리고 계약자의 잘못으로 서투른 위임 조건은 불필요한 분쟁의 발생에만 기여할 것입니다.
응. 이것은 가능성이 있습니다. 그럼 바로 (조용히, 개발자들이 잠든 사이에) 생각해보자)), '작업' 섹션에서 어떤 추가 사항을 요청하고 싶나요? 하지만 내가 먼저!
나는 도우를 원한다! '소스'
:))
그러면 어떻게 될까요? 문제에 대한 작업 솔루션은 다음과 같습니다.
1. 형식적인 측면에서 - 규칙의 새로운 단락 ;
2. 기술적인 측면에서 - 신청서 양식에 "소스 코드 필요" 옵션을 기본 "필수 아님"으로 입력합니까?
제 생각에는 또 다른 대안이 있습니다. 특정 중개자(우리의 경우 MQ)가 계약자와 고객 사이에 있는 반면 계약자는 전체 자료 패키지 + 소스 코드를 중개자(누가 확인하는지 확인합니다. TOR 준수를 위해), 그 후 고객은 중개자로부터 작업 완료에 대해 통지를 받고 비용을 지불해야 합니다.
작업의 독점성과 초기 계약에 따라 지불 후 고객은 가장 오픈 소스 코드를 받거나 그냥 컴파일된 파일을 받습니다.
동시에, 당신이 이해하는 바와 같이, 중개자는 일정한 보수를 받습니다.
추신
MQ는 별로 내 취향은 아닌 것 같지만...