Règles sous le travail - page 4
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
... Et d'ajouter : "Je ne sais pas si c'est juste, mais je pense personnellement que les TDR sont secondaires et ne sont qu'une annexe au contrat (demande)". Que j'ai commenté, en insistant sur les phrases commentées. L'essentiel du commentaire : sous certaines conditions, le RdR peut être autosuffisant (primaire selon votre terminologie). Et bien c'est ainsi, à un mot près, un sujet de dispute ; en fait il n'y en a pas :)
Je n'ai jamais rencontré de cahier des charges sans accord (et généralement le cahier des charges n'est qu'une information technique, alors que l'accord est l'essence même de la relation juridique entre les parties).
Personnellement, j'ai l'habitude de la séquence suivante :
1. un accord/contrat de travail (qui spécifie le client, l'entrepreneur, l'essence principale du travail à effectuer, le calendrier des travaux, le montant payé par le client à l'entrepreneur, la responsabilité des parties et des informations supplémentaires si nécessaire) ;
2. des termes de référence (TOR) décrivant en détail la tâche elle-même et fournissant les caractéristiques spécifiques du travail à effectuer (le client n'est pas obligé de comprendre les TOR) ;
Acte d'achèvement ;
Paiement de l'ouvrage ou de ses étapes.
Sur la base de ce qui précède, je pense que dans des circonstances normales, le contrat (lire l'offre) a un statut plus élevé que les TDR (les TDR sont formés sur la base du contrat avec une spécification détaillée des travaux ou une étape spécifique).
Je suppose que dans le nôtre, les développeurs (en tant qu'organisateurs du service) doivent être plus détaillés dans le contenu de la demande, en la rapprochant du contrat réel.
Il peut également être intéressant de souligner le processus de formation des TDR, permettant à l'artiste-interprète de recevoir un certain montant (spécifié précisément ou en pourcentage de la commande), bien sûr, si l'artiste-interprète a préparé lui-même les TDR et que le client l'a accepté.
pronych:
А вообще, проще всего не мудрить с правилами, а просто, при вводе заявки добавить "снятую" галку, типа "хочу исходники" и отражать это в списке заданий. кому надо, тот отметит флажок. небольшой апдейт, а как приятно. и всем всё сразу понятно будет.
Il s'agit de l'aspect technique de la résolution d'une partie du problème. En fait, vous proposez une exigence pour que les clients "décident du type de dossier final", à décider au stade du remplissage de la demande. Par conséquent, une telle exigence pour les Clients devrait (d'un point de vue formel) être reflétée dans les Règles. Les clients doivent comprendre ce que l'on attend d'eux.
En outre, le contractant (dans son propre intérêt) ne doit pas se reposer sur ses lauriers à la vue d'une demande, mais doit obtenir un accord direct sur cette question dans les termes de référence.
Et en général, la façon la plus simple de ne pas faire un gâchis avec les règles, mais simplement, lorsque vous entrez la demande d'ajouter "non coché", comme "Je veux des sources" et le refléter dans la liste des emplois. qui en a besoin, il va cocher la case. une petite mise à jour, mais comment agréable. et tout à la fois il sera clair.
À mon avis, la "demande" elle-même doit être retravaillée plus en détail. Non seulement cela, mais il devrait y en avoir beaucoup plus. Par exemple, vous pouvez également vérifier les conditions qui permettent/interdisent à l'interprète d'utiliser des algorithmes et du code de programme à l'avenir.
Bien que je comprenne que de telles choses sont très difficiles à contrôler.
PS
C'est que, si je comprends bien, contrairement au client, personne n'interfère pour reproduire l'œuvre (surtout s'il y a un code source) et l'artiste peut facilement la mettre dans la boutique ou la revendre à un autre client.
Il s'agit de l'aspect technique de la résolution d'une partie du problème. En fait, vous proposez une exigence pour que les clients "décident du type de dossier final", à décider au stade du remplissage de la demande. Par conséquent, une telle exigence pour les Clients devrait (d'un point de vue formel) être reflétée dans les Règles. Pour qu'ils comprennent ce que l'on attend d'eux.
En outre, le contractant (dans son propre intérêt) ne doit pas se laisser aller à la complaisance à la vue d'une demande, mais doit parvenir à un accord sur cette question directement dans le cahier des charges.
Pour être précis, il est plutôt nécessaire de faire une sorte de choix conditionnel. Si le client veut nécessairement les sources, alors il n'y a rien à faire, sinon l'entrepreneur aura le choix.
Dans ce cas, le client doit comprendre que les sources et l'exclusivité de l'œuvre (le cas échéant) coûteront un supplément.
Après y avoir réfléchi, je pense ceci . Si un programmeur écrit quelque chose selon le cahier des charges du client, il doit également lui remettre le code source. Tout d'abord, il est peu probable que les développeurs affirment un jour qu'aucune nouvelle version ne devra jamais être recompilée. Deuxièmement, il est nécessaire de résoudre les éventuels litiges. Il est possible que le RPT ait été mal formulé, mal compris ou que le programmeur ait simplement fait une erreur. Dans le premier cas, le client doit payer pour le remaniement en fonction d'un nouveau cahier des charges ou laisser le programmeur tranquille. Dans le deuxième et le troisième cas, le programmeur doit corriger ses erreurs gratuitement. Comment puis-je savoir qui a raison sans code source ?
Qu'y a-t-il dans le code source qui ne peut pas être transmis au client ? Une bonne idée de vente, c'est-à-dire le RPT, vaut beaucoup plus que certains secrets de programmeurs.
Si vous vendez un logiciel écrit à partir de vos propres idées, le transfert du code source est hors de question.
Sur la base des éléments suivants, je pense que dans des circonstances normales, un contrat (lire la demande) . ..
Il y a une erreur fondamentale ici. Un contrat est un accord entre deux ou plusieurs personnes. Une demande n'est qu'une proposition d'une partie, qui ne peut être considérée en soi comme un contrat. Selon les règles en question, une relation contractuelle n'existe (conclusion d'un contrat) qu'après l'émission des termes de référence. Les termes de référence sont destinés à refléter les détails du travail convenu par les parties .
L'approche du contrat d'entreprise que vous avez décrite peut être qualifiée de "classique", ce qui n'exclut pas l'existence d'autres formes égales d'établissement de la relation contractuelle qui se sont présentées. Au sens figuré, le chapitre 36 "Contrat-Accord" du Code civil est une classe mère avec ses membres publics et protégés et ses fonctions virtuelles, et la spécification des exigences est une des classes descendantes possibles. :)
Interesting:
Il s'agit de l'aspect technique de la résolution d'une partie du problème. En fait, vous proposez une exigence pour que les clients "décident du type de dossier final", à décider au stade du remplissage de la demande. Par conséquent, une telle exigence pour les Clients devrait (d'un point de vue formel) être reflétée dans les Règles. Les clients doivent comprendre ce que l'on attend d'eux.
En outre, le contractant (dans son propre intérêt) ne doit pas se laisser aller à la complaisance à la vue d'une demande, mais doit parvenir à un accord sur cette question directement dans le cahier des charges.
Pour être précis, il est plutôt nécessaire de faire une sorte de choix conditionnel. Si le client a nécessairement besoin du code source, il n'y a rien à faire, sinon l'artiste aura le choix.
Dans ce cas, le client doit comprendre que les sources et l'exclusivité de l'œuvre (le cas échéant) coûteront un supplément.
Après y avoir réfléchi, je pense ceci . Si un programmeur écrit quelque chose selon le cahier des charges du client, il doit également lui remettre le code source.
Qu'y a-t-il exactement dans le code source qui ne peut pas être transmis au client ? Une bonne idée de vente, c'est-à-dire le RPT, vaut beaucoup plus que quelques secrets de programmation.
Si vous vendez un logiciel écrit à partir de vos propres idées, il est hors de question de remettre le code source.
Le code source peut être un modèle bien conçu, avec de nombreuses fonctionnalités supplémentaires, des classes, etc. Il peut être constitué d'un ensemble de blocs (inludes, par exemple) et seules certaines des conditions qu'il contient peuvent être différentes. Êtes-vous prêt à donner six mois (dans un cas simple) de travail, dans le code source d'une douzaine de fichiers différents d'un système (système, dans le sens d'interaction entre eux), dans lequel seul le module de signal (une classe(fichier)) diffère ?
Je comprends que l'on puisse utiliser des outils standards pour planter les masques, et ce n'est pas dommage. Mais si d'énormes efforts sont déployés pour le modèle, comment pouvons-nous faire ? Non, tu es prêt ?
Après y avoir réfléchi, je pense ceci . Si un programmeur écrit quelque chose selon le cahier des charges du client, il doit également lui remettre le code source. Tout d'abord, il est peu probable que les développeurs affirment un jour qu'aucune nouvelle version ne devra jamais être recompilée. Deuxièmement, il est nécessaire de résoudre les éventuels litiges. Il est possible que le RPT ait été mal formulé, mal compris ou que le programmeur ait simplement fait une erreur. Dans le premier cas, le client doit payer pour le remaniement en fonction d'un nouveau cahier des charges ou laisser le programmeur tranquille. Dans le deuxième et le troisième cas, le programmeur doit corriger ses erreurs gratuitement. Comment puis-je savoir qui a raison sans code source ?
Qu'y a-t-il dans le code source qui ne peut pas être transmis au client ? Une bonne idée de vente, c'est-à-dire le RPT, vaut beaucoup plus que certains secrets de programmeurs.
Si vous vendez un logiciel qui a été écrit sur la base de vos propres idées, le transfert du code source est hors de question.
1. le transfert obligatoire du code source n'est approprié que lorsque le travail à effectuer est exclusif, mais comme vous le comprenez, le prix sera différent (peut-être plusieurs fois plus élevé).
La question de la recompilation peut également être résolue au tout début.
2. Concernant les TdR.
Eh bien, je n'ai pas vu de "bonnes" idées sur le Forex, qui coûteraient plus cher qu'une "bonne" mise en œuvre logicielle.
Pour répondre à votre question - le code source a la capacité de permettre au client de faire valoir qu'il est le propriétaire légitime et qu'il peut faire n'importe quoi avec le code (par exemple, le vendre).
Par conséquent, nous parlons très probablement de l'exclusivité de l'œuvre (et je soutiens ici les programmeurs qui ne veulent pas distribuer le code source).