Normas en el trabajo - página 4
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
... Y luego añadió: "No sé si es correcto, pero personalmente creo que la RPT es secundaria y sólo es un anexo al contrato (solicitud)". Lo que comenté, con énfasis en las frases comentadas. La esencia del comentario: en determinadas condiciones, los TdR pueden ser autosuficientes (primarios en su terminología). Bueno es así, a una palabra, un tema para la disputa de hecho no hay :)
Así que en la vida real, el contrato/acuerdo es lo primero, nunca he conocido un TdR sin un acuerdo (y normalmente el TdR es sólo información técnica, mientras que el acuerdo es la esencia principal de la relación legal entre las partes).
Personalmente, estoy acostumbrado a la siguiente secuencia:
1. un acuerdo/contrato de trabajo (en el que se especifica el cliente, el contratista, la esencia principal del trabajo a realizar, el calendario del trabajo, el importe pagado por el cliente al contratista, la responsabilidad de las partes y la información adicional si es necesaria);
2. Términos de referencia (TdR) que describen en detalle la tarea en sí y proporcionan las características específicas del trabajo a realizar (el cliente no está obligado a entender los TdR);
Acto de finalización;
Pago de la obra o de sus etapas.
Sobre la base de lo anterior, creo que en circunstancias normales, el contrato (léase oferta) tiene un estatus más alto que los TdR (los TdR se forman sobre la base del contrato con la especificación detallada del trabajo o de una etapa específica).
Supongo que en la nuestra los desarrolladores (como organizadores del servicio) deben ser más detallados en el contenido de la solicitud, acercándola al contrato real.
También puede ser conveniente destacar el proceso de formación de los TdR, que permite al ejecutante recibir una determinada cantidad (especificada con precisión o como porcentaje del pedido), por supuesto, si el ejecutante ha preparado él mismo los TdR y el cliente está de acuerdo con ellos.
pronych:
А вообще, проще всего не мудрить с правилами, а просто, при вводе заявки добавить "снятую" галку, типа "хочу исходники" и отражать это в списке заданий. кому надо, тот отметит флажок. небольшой апдейт, а как приятно. и всем всё сразу понятно будет.
De hecho, usted plantea un requisito para que los clientes "decidan el tipo de expediente final", para decidir en la fase de cumplimentación de la solicitud. En consecuencia, este requisito para los clientes debería (desde un punto de vista formal) reflejarse en el Reglamento. Los clientes deben entender lo que se les pide.
Además, el contratista (en su propio interés) no debe dormirse en los laureles ante una solicitud, sino que debe conseguir que esta cuestión se acuerde directamente en el pliego de condiciones.
Y en general, la forma más fácil de no hacer un lío con las reglas, pero simplemente, cuando se introduce la solicitud de añadir "sin marcar", como "Quiero fuentes" y reflejarlo en la lista de puestos de trabajo. que lo necesita, se marcará la casilla de verificación. una pequeña actualización, pero lo bonito. y de una vez será claro.
En mi opinión, la "aplicación" en sí debe ser reelaborada con más detalle. No sólo eso, sino que debería haber muchos más. Por ejemplo, también puede comprobar las condiciones que permiten/prohíben al ejecutante utilizar algoritmos y código de programa en el futuro.
Aunque entiendo que estas cosas son muy difíciles de controlar.
PS
Es que como entiendo que al contrario que el cliente nadie interfiere para replicar la obra (sobre todo si hay código fuente) y el artista puede ponerla fácilmente en la tienda o revenderla a otro cliente.
De hecho, usted plantea un requisito para que los clientes "decidan el tipo de expediente final", para decidir en la fase de cumplimentación de la solicitud. En consecuencia, este requisito para los clientes debería (desde un punto de vista formal) reflejarse en el Reglamento. Para que entiendan lo que se requiere de ellos.
Además, el Contratista (en su propio interés) no debe confiarse ante una solicitud, sino que debe llegar a un acuerdo sobre esta cuestión directamente en el pliego de condiciones.
Para ser precisos, es más bien necesario hacer algún tipo de elección condicional. Si el cliente quiere necesariamente las fuentes, entonces no hay nada que hacer, de lo contrario el contratista tendrá que elegir.
En este caso, el cliente debe entender que las fuentes y la exclusividad de la obra (si la hay) tendrán un coste adicional.
Después de pensarlo, pienso esto. Si un programador escribe algo según los términos de referencia del cliente, también debe entregarle el código fuente. En primer lugar, es poco probable que los desarrolladores digan que nunca más habrá que recompilar una nueva compilación. En segundo lugar, es necesario resolver cualquier conflicto. Es posible que la RPT se haya formulado de forma incorrecta, que se haya entendido mal o que el programador simplemente se haya equivocado. En el primer caso, el cliente tiene que pagar la adaptación a unos nuevos términos de referencia o dejar al programador en paz. En el segundo y tercer caso, el programador tiene que corregir sus errores de forma gratuita. ¿Cómo puedo averiguar quién tiene razón sin el código fuente?
¿Qué hay en el código fuente que no pueda ser transmitido al cliente? Una buena idea de venta, que es el TOR, vale mucho más que algunos secretos de programador.
Si vendes un software escrito a partir de tus propias ideas, la transferencia del código fuente queda descartada.
En base a lo siguiente, creo que en circunstancias normales un contrato (léase solicitud) ...
Aquí hay un error fundamental. Un contrato es un acuerdo entre dos o más personas. Una solicitud es sólo una propuesta de una parte, que en sí misma no puede considerarse un contrato. De acuerdo con las normas en cuestión, la relación contractual (celebración de un contrato) sólo puede establecerse una vez redactado el pliego de condiciones. El pliego de condiciones pretende reflejar los detalles del trabajo acordado por las partes .
El planteamiento del Contrato de Obra que usted ha descrito puede denominarse "clásico", lo que no excluye la existencia de otras formas iguales de establecimiento de la relación contractual que hayan surgido. En sentido figurado, el capítulo 36 "Contrato-Acuerdo" del Código Civil es una clase madre con sus miembros públicos y protegidos y sus funciones virtuales, y la especificación de requisitos es una de las posibles clases descendientes. :)
Interesting:
De hecho, usted plantea un requisito para que los clientes "decidan el tipo de expediente final", para decidir en la fase de cumplimentación de la solicitud. En consecuencia, este requisito para los clientes debería (desde un punto de vista formal) reflejarse en el Reglamento. Los clientes deben entender lo que se les pide.
Además, el Contratista (en su propio interés) no debe confiarse ante una solicitud, sino que debe llegar a un acuerdo sobre esta cuestión directamente en el pliego de condiciones.
Para ser precisos, es más bien necesario hacer algún tipo de elección condicional. Si el cliente necesita necesariamente el código fuente, no hay nada que hacer, de lo contrario el artista tendrá que elegir.
En este caso, el cliente debe entender que las fuentes y la exclusividad de la obra (si la hay) tendrán un coste adicional.
Después de pensarlo, pienso esto. Si un programador escribe algo según los términos de referencia del cliente, también debe entregarle el código fuente.
¿Qué hay exactamente en el código fuente que no se puede pasar al cliente? Una buena idea de venta, es decir, la RPT, vale mucho más que algunos secretos de programación.
Si vendes un software que está escrito a partir de tus propias ideas, entregar el código fuente está fuera de lugar.
El código fuente puede ser una plantilla bien diseñada, con un montón de características adicionales, clases, etc. Puede consistir en un montón de bloques (inludes, por ejemplo) y sólo algunas de las condiciones en él pueden ser diferentes. ¿Está usted dispuesto a dar seis meses (en un caso sencillo) de trabajo, en el código fuente de una docena de archivos diferentes de un sistema (sistema, en el sentido de la interacción entre sí), en el que sólo el módulo de señal (una clase (archivo)) difiere?
Lo entiendo, podemos utilizar herramientas estándar para estrellar las máscaras, y no es una pena. Pero si se ponen grandes esfuerzos en la plantilla, ¿cómo podemos hacerlo? No, ¿estás listo?
Después de pensarlo, pienso esto. Si un programador escribe algo según los términos de referencia del cliente, también debe entregarle el código fuente. En primer lugar, es poco probable que los desarrolladores digan que nunca más habrá que recompilar una nueva compilación. En segundo lugar, es necesario resolver los posibles conflictos. Es posible que la RPT se haya formulado de forma incorrecta, que se haya entendido mal o que el programador simplemente se haya equivocado. En el primer caso, el cliente tiene que pagar la adaptación a unos nuevos términos de referencia o dejar al programador en paz. En el segundo y tercer caso, el programador tiene que corregir sus errores de forma gratuita. ¿Cómo puedo averiguar quién tiene razón sin el código fuente?
¿Qué hay en el código fuente que no pueda ser transmitido al cliente? Una buena idea de venta, que es el TOR, vale mucho más que algunos secretos de programador.
Si usted vende un software que ha sido escrito a partir de sus propias ideas, la transferencia del código fuente queda descartada.
1. la cesión obligatoria del código fuente es adecuada sólo cuando el trabajo a realizar es exclusivo, pero como comprenderá el precio será diferente (posiblemente varias veces superior).
La cuestión de la recompilación también se puede resolver desde el principio.
2. En cuanto a los TdR.
Bueno, no he visto ideas "buenas" en Forex, que costarían más que una "buena" implementación de software.
En respuesta a su pregunta - el código fuente tiene la capacidad de permitir al cliente argumentar que es el titular de los derechos y puede hacer cualquier cosa con el código (por ejemplo, venderlo).
Por tanto, lo más probable es que estemos hablando de la exclusividad de la obra (y aquí apoyo que los programadores no pretendan difundir el código fuente).