Regras do Trabalho - página 4
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
... E depois acrescentou: "Não sei como é correcto, mas pessoalmente acredito que o RPT é secundário e é apenas um anexo ao contrato (candidatura)". Que comentei, com ênfase nas frases comentadas. A essência do comentário: sob certas condições, ToR pode ser auto-suficiente (primário na sua terminologia). Pois bem, a uma palavra, um assunto para disputa, de facto não há :)
Assim, na vida real, o contrato/acordo vem primeiro, nunca conheci um TdR sem um acordo (e normalmente o TdR é apenas informação técnica, enquanto o acordo é a essência principal da relação jurídica entre as partes).
Pessoalmente, estou habituado à seguinte sequência:
1. um acordo/contrato de trabalho (que especifica o cliente, o empreiteiro, a essência principal do trabalho a realizar, o calendário do trabalho, o montante pago pelo cliente ao empreiteiro, a responsabilidade das partes e informações adicionais, se necessário);
2. termos de referência (RPT) descrevendo em pormenor a tarefa em si e fornecendo características específicas do trabalho a ser realizado (o cliente não é obrigado a compreender os RPT);
Acto de Conclusão;
Pagamento do trabalho ou das suas fases.
Com base no acima exposto, acredito que, em circunstâncias normais, o contrato (lido licitação) tem um estatuto mais elevado do que o TOR (os ToR são formados com base no contrato com especificação detalhada do trabalho ou uma fase específica).
Presumo que no nosso, os criadores (como organizadores do serviço) precisam de ser mais detalhados no conteúdo da aplicação, aproximando-a do contrato real.
Pode também valer a pena destacar o processo de formação dos RPT, permitindo que o artista receba um determinado montante (especificado com precisão ou como percentagem da encomenda), claro, se o artista preparou ele próprio o RPT e o cliente concordou com o mesmo.
pronych:
А вообще, проще всего не мудрить с правилами, а просто, при вводе заявки добавить "снятую" галку, типа "хочу исходники" и отражать это в списке заданий. кому надо, тот отметит флажок. небольшой апдейт, а как приятно. и всем всё сразу понятно будет.
Este é o lado técnico da resolução de parte do problema. De facto, está a apresentar um requisito para os Clientes "decidirem sobre o tipo de ficheiro final", para decidir na fase de preenchimento da Aplicação. Consequentemente, tal exigência para os Clientes deve (de um ponto de vista formal) ser reflectida nas Regras. Os Clientes devem compreender o que lhes é exigido.
Além disso, o Empreiteiro (no seu próprio interesse) não deve tornar-se complacente à vista de um Pedido, mas deve conseguir que este assunto seja acordado directamente nos termos de referência.
E em geral, a maneira mais fácil de não mexer nas regras, mas simplesmente, ao entrar no pedido para acrescentar "não verificado", como "quero fontes" e reflecti-lo na lista de trabalhos. quem precisa, verificará a caixa de verificação. uma pequena actualização, mas que bom. e tudo de uma só vez será claro.
Na minha opinião, a própria "aplicação" precisa de ser retrabalhada em mais pormenor. Não só isso, mas deveria haver muito mais. Por exemplo, também pode verificar as condições que permitem/obrigam o executante a utilizar algoritmos e código de programa no futuro.
Embora compreenda que tais coisas são muito difíceis de controlar.
PS
É que, segundo sei, ao contrário do cliente, ninguém interfere para replicar a obra (especialmente se o código fonte) e o artista pode facilmente colocá-lo na loja ou revendê-lo a outro cliente.
Este é o lado técnico da resolução de parte do problema. De facto, está a apresentar um requisito para os Clientes "decidirem sobre o tipo de ficheiro final", para decidir na fase de preenchimento da Aplicação. Consequentemente, tal exigência para os Clientes deve (de um ponto de vista formal) ser reflectida nas Regras. Para que compreendam o que lhes é exigido.
Além disso, o Contratante (no seu próprio interesse) não deve tornar-se complacente à vista de um pedido, mas deve chegar a um acordo sobre esta questão directamente nos termos de referência.
Para ser mais preciso, é bastante necessário fazer algum tipo de escolha condicional. Se o cliente quiser necessariamente as fontes, então não há nada a fazer, caso contrário o empreiteiro terá uma escolha.
Neste caso, o cliente deve compreender que as fontes e a exclusividade do trabalho (se houver) custarão dinheiro extra.
Depois de ter pensado bem, penso o seguinte. Se um programador escrever algo de acordo com os termos de referência do cliente, deve também dar-lhe o código fonte. Em primeiro lugar, é improvável que os promotores alguma vez digam que nenhuma nova construção precisará de ser recompilada novamente. Em segundo lugar, é necessário resolver quaisquer disputas. É possível que o TOR tenha sido formulado incorrectamente, mal compreendido ou que o programador tenha simplesmente cometido um erro. No primeiro caso, o cliente tem de pagar pelo retrabalho a um novo ToR ou deixar o programador em paz. No segundo e terceiro casos, o programador tem de corrigir os seus erros de graça. Como posso descobrir quem está certo sem o código fonte?
O que está no código fonte que não pode ser passado para o cliente? Uma boa ideia de vendas, ou seja, o TOR, vale muito mais do que alguns segredos de programadores.
Se vender software que esteja escrito nas suas próprias ideias, então a transferência do código fonte está fora de questão.
Com base no seguinte creio que, em circunstâncias normais, um contrato (ler candidatura) . ..
Há aqui um erro fundamental. Um contrato é um acordo entre duas ou mais pessoas. Uma candidatura é apenas uma proposta de uma parte, que em si mesma não pode ser considerada como um contrato. Nos termos das regras em discussão, uma relação contratual (celebração de um contrato) só pode ser estabelecida após a elaboração dos Termos de Referência. Os termos de referência destinam-se a reflectir os pormenores do trabalho acordado pelas partes .
A abordagem Contrato a Obras que descreveu pode ser chamada "clássica", o que não impede a existência de quaisquer outras formas iguais de estabelecimento da relação contratual que tenham surgido. Figurativamente falando, o Capítulo 36 "Contrato-Acordo" do Código Civil é uma classe mãe com os seus membros públicos e protegidos e funções virtuais, e a especificação dos requisitos é uma das possíveis classes descendentes. :)
Interesting:
Este é o lado técnico da resolução de parte do problema. De facto, está a apresentar um requisito para os Clientes "decidirem sobre o tipo de ficheiro final", para decidir na fase de preenchimento da Aplicação. Consequentemente, tal exigência para os Clientes deve (de um ponto de vista formal) ser reflectida nas Regras. Os Clientes devem compreender o que lhes é exigido.
Além disso, o Contratante (no seu próprio interesse) não deve tornar-se complacente à vista de um pedido, mas deve chegar a um acordo sobre esta questão directamente nos termos de referência.
Para ser mais preciso, é bastante necessário fazer algum tipo de escolha condicional. Se o cliente precisar necessariamente do código fonte, então não há nada a fazer, caso contrário o artista terá uma escolha.
Neste caso, o cliente deve compreender que as fontes e a exclusividade do trabalho (se houver) custarão dinheiro extra.
Depois de ter pensado bem, penso o seguinte. Se um programador escrever algo de acordo com os termos de referência do cliente, deve também dar-lhe o código fonte.
O que há exactamente no código fonte que não pode ser transmitido ao cliente? Uma boa ideia de vendas, ou seja, o TOR, vale muito mais do que alguns segredos de programação.
Se estiver a vender software escrito com base nas suas próprias ideias, a entrega do código fonte está fora de questão.
O código fonte pode ser um modelo bem desenhado, com muitas características extras, classes, etc... Pode ser constituído por um monte de blocos (inlúdios, por exemplo) e apenas algumas das condições nele existentes podem ser diferentes. Está pronto para dar seis meses (num caso simples) de trabalho, no código fonte de uma dúzia de ficheiros diferentes de um sistema (sistema, no sentido de interacção entre si), em que apenas o módulo de sinal (uma classe (ficheiro)) difere?
Compreendo, podemos usar ferramentas padrão para bater com as máscaras, e não é uma pena. Mas se forem investidos grandes esforços no modelo, como o podemos fazer? Não, está pronto?
Depois de ter pensado bem, penso o seguinte. Se um programador escreve algo de acordo com os termos de referência do cliente, deve também dar-lhe o código fonte. Em primeiro lugar, é improvável que os promotores alguma vez digam que nenhuma nova construção precisará de ser recompilada novamente. Em segundo lugar, é necessário resolver quaisquer disputas. É possível que o TOR tenha sido formulado incorrectamente, mal compreendido ou que o programador tenha simplesmente cometido um erro. No primeiro caso, o cliente tem de pagar pelo retrabalho a um novo ToR ou deixar o programador em paz. No segundo e terceiro casos, o programador tem de corrigir os seus erros de graça. Como posso descobrir quem está certo sem o código fonte?
O que está no código fonte que não pode ser passado para o cliente? Uma boa ideia de vendas, ou seja, o TOR, vale muito mais do que alguns segredos de programadores.
Se vende software que foi escrito com base nas suas próprias ideias, então a transferência do código fonte está fora de questão.
1. a transferência obrigatória do código fonte só é apropriada quando o trabalho a ser feito é exclusivo, mas como se entende o preço será diferente (possivelmente várias vezes superior).
A questão com a recompilação também pode ser resolvida logo no início.
2. Em relação aos ToR.
Bem, não tenho visto "boas" ideias sobre Forex, o que custaria mais do que uma "boa" implementação de software.
Em resposta à sua pergunta - o código fonte tem a capacidade de permitir ao cliente afirmar que é o titular dos direitos e pode fazer qualquer coisa com o código (por exemplo, vendê-lo).
Portanto, é muito provável que estejamos a falar da exclusividade do trabalho (e aqui apoio programadores que não queiram distribuir o código fonte).