글쎄, 그것은 분명하다. 일반적으로 어떤 형태로 제품을 주문했는지 신청서에 즉시 표시하면 더 편리 할 것이라고 생각합니다. 두 번째 글에 대한 답변입니다.
불행히도, 우리는 고객이 프로그래머 작업의 특정 미묘함(특히 파일 확장자 기능)을 자세히 이해하도록 요구할 수 없습니다. 그들 모두가 이러한 문제에 가깝지는 않습니다. 그리고 당사자들은 TOR에 동의하는 데 동등하기 때문에 계약자가 작업의 특정 세부 사항을 제시하는 데 앞장서야 할 수 있습니다.
프니치 :
그리고 첫 번째 항목 (규칙 1.5-1.6및 1.9, 2.3-2.8 단락) 에 대해서는 솔직히 말해서 이해하지 못했습니다. 어떤 규칙을 말씀하시는 건가요?
사실, 나는 이해하지 못한다. 이것 에 대해 2.8이 없다면 ... 어떤 다른 규칙이 존재합니까? 링크를 제공하십시오.
규칙은 동일합니다. 나는 당신이 시작 메시지에서 섹션 번호의 표시를 사용하지 않은 것을 방금 보았고 똑같이 했습니다. 물론 전체 링크는 다음과 같아야 합니다.
입찰자가 작업 수행에 대한 제안서(규칙 섹션 I 의 1.5-1.6항)에서 주문 실행에 대한 자신의 기능을 명확하게 지정한 다음 섹션 I의 1.9절, 규칙 섹션 III 의 2.3-2.8절은 참조 약관에서 이러한 세부 정보를 수정합니다.
pronych : 그게 다야 당신은 '이론적으로'라고 말합니다. 이것은 내가 말하는 것입니다. 이와 관련하여 규칙을 더 명확하게 할 필요가 있습니다. 그렇지 않으면 많은 논란이 있을 수 있습니다. 저는 개인적으로 주문서 작성에 대해 생각하고 있는데, 이에 대해 이견이 있으면 요점을 잘 모르겠습니다. 내 소스를 공유하고 싶지 않습니다.
그러니 가능하면 버리지 마세요.
TK를 논의할 때 작업의 가격과 소스 코드의 이전을 즉시 명시합니다. 고객이 소스 코드 없이 동의하면(또는 연도의 최소 공개로) 모든 것이 소스 코드 없이 배치될 수 있습니다. 원하는 경우 향후 SHOP을 사용할 수 있습니다(물론 작업에 가치가 있고 수요가 있는 경우는 제외).
그러나 여기에는 소스 코드와 함께 좋은 프로젝트 가 10배(또는 2배) 더 많은 비용이 들 수 있다는 트릭이 있습니다.
알렉세이FX :
소스 코드 없이 밝혀질 때까지.
거의 모든 새 빌드에는 재컴파일이 필요합니다.
이는 구직 지원서 또는 TOR에서 직접 지정할 수도 있습니다. 시간이 지나면 ex5에 대한 변경 사항이 너무 작아져 큰 문제를 일으키지 않을 것입니다.
Yedelkin : 예, 나는 논쟁하지 않습니다. 나는 단지 이 상황에서 벗어날 수 있는 길이 있고 그 탈출구가 아주 명백하다고 말하고 싶습니다(제 생각에는).
그래, 난 동의. 출구가 있습니다. 그는 항상 거기에 있습니다. 먹힌 경우에도 항상 두 개의 출구를 찾을 수 있습니다(프로그래머의 경우 Nout = Nin * 2).
내 말은, 고객이 $ 20에 대해 말하는 경우 응용 프로그램을 조사하는 것은 의미가 없습니다. 모든 소스 파일을 원합니다(A4 용지 50매). 예, 물론 TK에 대한 논의에서 이 점을 논의할 수 있습니다. 하지만 상상해보세요. 당신은 한 고객과 협상하지만, 이 시점에서 당신은 동의하지 않고 헤어졌습니다. 다른 사람들과 협상하십시오. 여기에서도 마찬가지입니다. 그리고...
고객이 완성된 제품을 어떤 형태로 받기를 원하는지 즉시 알면 왜 시간을 낭비합니까?
실제로 응용 프로그램을 컴파일할 때 "소스 코드를 원합니다."와 같은 확인란을 선택하는 것이 더 쉽습니다. 우리는 이것을 볼 것이며, 누가 그것을 제공할 준비가 되어 있지 않고 목욕을 하지 않을 것입니다. 또는 가격과 수량에 따라 달라집니다.
그러한 계획을 사용하면 대부분 그렇습니다. 그러나 제 생각에는 TK 외에 다른 것이 필요합니다 (예: 작업 수행 계약).
어떻게 맞는지는 모르겠지만 개인적으로 TK는 부차적 인 것이고 계약서(어플리케이션)의 부록일 뿐이라고 개인적으로 생각합니다.
"계약"이란 무엇입니까? - 이것은 특정 필수 조건에 대한 당사자의 합의일 뿐입니다. 이 경우 문서 자체를 "계약"이라고 하지 않을 수 있습니다. 그리고 서면으로도 안됩니다. 상점에서 물건을 구입할 때 수표 외에는 아무것도 받지 않습니다. 이 경우 수표는 서면으로 공식화하지 않고 판매 계약의 체결을 확인하기 때문입니다.
규칙에 따르면 참조 약관에는 고객과 계약자 간의 계약의 모든 필수 조건이 포함되어야 합니다. 법적 성격에 따른 참조 조건(용어 죄송합니다)은 근로 계약입니다(러시아 연방 민법 702조). 단순히 그러한 서면 문서의 특성 때문에 그들은 참조 약관이라고 부르기로 결정했습니다.
그래, 난 동의. 출구가 있습니다. 그는 항상 거기에 있습니다. 먹힌 경우에도 항상 두 개의 출구를 찾을 수 있습니다(프로그래머의 경우 Nout = Nin * 2).
내 말은, 고객이 $ 20에 대해 말한 경우 응용 프로그램을 조사하는 것은 의미가 없습니다. 모든 소스 파일을 원합니다(A4 용지 50매). 예, 물론 TK에 대한 논의에서 이 점을 논의할 수 있습니다. 하지만 상상해보세요. 당신은 한 고객과 협상하고 있지만, 이 시점에서 당신은 동의하지 않고 헤어졌습니다. 다른 사람들과 협상하십시오. 여기에서도 마찬가지입니다. 그리고...
고객이 완성된 제품을 어떤 형태로 받기를 원하는지 즉시 알면 왜 시간을 낭비합니까?
실제로 응용 프로그램을 컴파일할 때 "소스 코드를 원합니다."와 같은 확인란을 선택하는 것이 더 쉽습니다. 우리는 이것을 볼 것이며, 누가 그것을 제공할 준비가 되어 있지 않고 목욕을 하지 않을 것입니다. 또는 가격과 수량에 따라 달라집니다.
나는 그런 daw를위한 것입니다. 모두가 소스 코드가 훨씬 더 비싸다는 것을 알고 있습니다 ...
다시 말하지만, 나는 논쟁하지 않을 것이다. 그러나 이미 앞에서 언급했듯이 계약자는 "작업 수행에 대한 제안 "을 배치하기 때문에 그러한 관계에서 수동 당사자가 아닙니다. 잠재적 계약자가 제안서에서 즉시 "소스 코드 비용이 15배 더 든다"라는 문구를 표시하지 못하도록 하는 이유를 이해할 수 없습니다. 또는 "나는 소스 코드를 거래하지 않습니다". 더 이상 시간 낭비가 없을 것입니다. 고객은 동의하고 그러한 신청자를 선택하거나 그를 잊어 버립니다.
... 이해했다. 제안을 제출하기 전에 "지원서 이해"에 소요된 시간에 대해 이야기할 수 있습니다. 그러나 아무도 사전에 고객과 이러한 세부 사항을 명확히하는 것을 금지하지 않습니다 (이해에 실제로 심각한 시간 투자가 필요한 경우).
소스 코드 없이 밝혀질 때까지.
거의 모든 새 빌드에는 재컴파일이 필요합니다.
글쎄, 그것은 분명하다. 일반적으로 어떤 형태로 제품을 주문했는지 신청서에 즉시 표시하면 더 편리 할 것이라고 생각합니다. 두 번째 글에 대한 답변입니다.
불행히도, 우리는 고객이 프로그래머 작업의 특정 미묘함(특히 파일 확장자 기능)을 자세히 이해하도록 요구할 수 없습니다. 그들 모두가 이러한 문제에 가깝지는 않습니다. 그리고 당사자들은 TOR에 동의하는 데 동등하기 때문에 계약자가 작업의 특정 세부 사항을 제시하는 데 앞장서야 할 수 있습니다.
그리고 첫 번째 항목 (규칙 1.5-1.6 및 1.9, 2.3-2.8 단락 ) 에 대해서는 솔직히 말해서 이해하지 못했습니다. 어떤 규칙을 말씀하시는 건가요?
사실, 나는 이해하지 못한다. 이것 에 대해 2.8이 없다면 ... 어떤 다른 규칙이 존재합니까? 링크를 제공하십시오.
규칙은 동일합니다. 나는 당신이 시작 메시지에서 섹션 번호의 표시를 사용하지 않은 것을 방금 보았고 똑같이 했습니다. 물론 전체 링크는 다음과 같아야 합니다.
입찰자가 작업 수행에 대한 제안서(규칙 섹션 I 의 1.5-1.6항)에서 주문 실행에 대한 자신의 기능을 명확하게 지정한 다음 섹션 I의 1.9절, 규칙 섹션 III 의 2.3-2.8절은 참조 약관에서 이러한 세부 정보를 수정합니다.
그게 다야 당신은 '이론적으로'라고 말합니다. 이것은 내가 말하는 것입니다. 이와 관련하여 규칙을 더 명확하게 할 필요가 있습니다. 그렇지 않으면 많은 논란이 있을 수 있습니다. 저는 개인적으로 주문서 작성에 대해 생각하고 있는데, 이에 대해 이견이 있으면 요점을 잘 모르겠습니다. 내 소스를 공유하고 싶지 않습니다.
그러니 가능하면 버리지 마세요.
TK를 논의할 때 작업의 가격과 소스 코드의 이전을 즉시 명시합니다. 고객이 소스 코드 없이 동의하면(또는 연도의 최소 공개로) 모든 것이 소스 코드 없이 배치될 수 있습니다. 원하는 경우 향후 SHOP을 사용할 수 있습니다(물론 작업에 가치가 있고 수요가 있는 경우는 제외).
그러나 여기에는 소스 코드와 함께 좋은 프로젝트 가 10배(또는 2배) 더 많은 비용이 들 수 있다는 트릭이 있습니다.
소스 코드 없이 밝혀질 때까지.
거의 모든 새 빌드에는 재컴파일이 필요합니다.
이는 구직 신청서 또는 TOR에서 직접 지정할 수도 있습니다.
불행히도, 우리는 고객이 프로그래머 작업의 특정 미묘함(특히 파일 확장자 기능)을 자세히 이해하도록 요구할 수 없습니다. 그들 모두가 이러한 질문에 가깝지는 않습니다.
IMHO, 고객을위한 그런 사소한 일은 만들 가치가 있습니다. 그는 보이는 것만큼 바보가 아닙니다.
그리고 멋진 트롤을 주문하면 100달러라고 해도 침착하게 다시 해서 바로 팔기 시작합니다(!) 반 루블, 심지어 금 조각이라도 너무 멋져? 그땐 우리가 어떻게 될지 궁금..
요컨대, 주제는 연결되고 관련성이 있습니다. 투표할 생각입니다. 지금 알았다면 투표하세요.
추신. 용서해줘 아카데미아! 아멘))
작동하지 않았습니다. 투표를 만드는 방법을 이해하지 못합니다.))
IMHO, 고객을위한 그런 사소한 일은 만들 가치가 있습니다. 그는 보이는 것만큼 바보가 아닙니다.
확실히 TK에서. 섹션 III의 2.4-2.5 단락 참조 규칙.
그러한 계획을 사용하면 대부분 그렇습니다. 그러나 제 생각에는 TK 외에 다른 것이 필요합니다(예: 작업 수행 계약).
어떻게 맞는지는 모르겠지만 개인적으로 TK는 부차적인 것이고 계약서(어플리케이션)의 부록일 뿐이라고 개인적으로 생각합니다.
예, 나는 논쟁하지 않습니다. 나는 단지 이 상황에서 벗어날 수 있는 길이 있고 그 탈출구가 아주 명백하다고 말하고 싶습니다(제 생각에는).
그래, 난 동의. 출구가 있습니다. 그는 항상 거기에 있습니다. 먹힌 경우에도 항상 두 개의 출구를 찾을 수 있습니다(프로그래머의 경우 Nout = Nin * 2).
내 말은, 고객이 $ 20에 대해 말하는 경우 응용 프로그램을 조사하는 것은 의미가 없습니다. 모든 소스 파일을 원합니다(A4 용지 50매). 예, 물론 TK에 대한 논의에서 이 점을 논의할 수 있습니다. 하지만 상상해보세요. 당신은 한 고객과 협상하지만, 이 시점에서 당신은 동의하지 않고 헤어졌습니다. 다른 사람들과 협상하십시오. 여기에서도 마찬가지입니다. 그리고...
고객이 완성된 제품을 어떤 형태로 받기를 원하는지 즉시 알면 왜 시간을 낭비합니까?
실제로 응용 프로그램을 컴파일할 때 "소스 코드를 원합니다."와 같은 확인란을 선택하는 것이 더 쉽습니다. 우리는 이것을 볼 것이며, 누가 그것을 제공할 준비가 되어 있지 않고 목욕을 하지 않을 것입니다. 또는 가격과 수량에 따라 달라집니다.
나는 그런 daw입니다. 모두가 소스 코드가 훨씬 더 비싸다는 것을 알고 있습니다 ...
그러한 계획을 사용하면 대부분 그렇습니다. 그러나 제 생각에는 TK 외에 다른 것이 필요합니다 (예: 작업 수행 계약).
어떻게 맞는지는 모르겠지만 개인적으로 TK는 부차적 인 것이고 계약서(어플리케이션)의 부록일 뿐이라고 개인적으로 생각합니다.
"계약"이란 무엇입니까? - 이것은 특정 필수 조건에 대한 당사자의 합의일 뿐입니다. 이 경우 문서 자체를 "계약"이라고 하지 않을 수 있습니다. 그리고 서면으로도 안됩니다. 상점에서 물건을 구입할 때 수표 외에는 아무것도 받지 않습니다. 이 경우 수표는 서면으로 공식화하지 않고 판매 계약의 체결을 확인하기 때문입니다.
규칙에 따르면 참조 약관에는 고객과 계약자 간의 계약의 모든 필수 조건이 포함되어야 합니다. 법적 성격에 따른 참조 조건(용어 죄송합니다)은 근로 계약입니다(러시아 연방 민법 702조). 단순히 그러한 서면 문서의 특성 때문에 그들은 참조 약관이라고 부르기로 결정했습니다.
그래, 난 동의. 출구가 있습니다. 그는 항상 거기에 있습니다. 먹힌 경우에도 항상 두 개의 출구를 찾을 수 있습니다(프로그래머의 경우 Nout = Nin * 2).
내 말은, 고객이 $ 20에 대해 말한 경우 응용 프로그램을 조사하는 것은 의미가 없습니다. 모든 소스 파일을 원합니다(A4 용지 50매). 예, 물론 TK에 대한 논의에서 이 점을 논의할 수 있습니다. 하지만 상상해보세요. 당신은 한 고객과 협상하고 있지만, 이 시점에서 당신은 동의하지 않고 헤어졌습니다. 다른 사람들과 협상하십시오. 여기에서도 마찬가지입니다. 그리고...
고객이 완성된 제품을 어떤 형태로 받기를 원하는지 즉시 알면 왜 시간을 낭비합니까?
실제로 응용 프로그램을 컴파일할 때 "소스 코드를 원합니다."와 같은 확인란을 선택하는 것이 더 쉽습니다. 우리는 이것을 볼 것이며, 누가 그것을 제공할 준비가 되어 있지 않고 목욕을 하지 않을 것입니다. 또는 가격과 수량에 따라 달라집니다.
나는 그런 daw를위한 것입니다. 모두가 소스 코드가 훨씬 더 비싸다는 것을 알고 있습니다 ...
다시 말하지만, 나는 논쟁하지 않을 것이다. 그러나 이미 앞에서 언급했듯이 계약자는 "작업 수행에 대한 제안 "을 배치하기 때문에 그러한 관계에서 수동 당사자가 아닙니다. 잠재적 계약자가 제안서에서 즉시 "소스 코드 비용이 15배 더 든다"라는 문구를 표시하지 못하도록 하는 이유를 이해할 수 없습니다. 또는 "나는 소스 코드를 거래하지 않습니다". 더 이상 시간 낭비가 없을 것입니다. 고객은 동의하고 그러한 신청자를 선택하거나 그를 잊어 버립니다.
... 이해했다. 제안을 제출하기 전에 "지원서 이해"에 소요된 시간에 대해 이야기할 수 있습니다. 그러나 아무도 사전에 고객과 이러한 세부 사항을 명확히하는 것을 금지하지 않습니다 (이해에 실제로 심각한 시간 투자가 필요한 경우).