Regole sotto Lavoro - pagina 4
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
... E poi ha aggiunto: "Non so come sia giusto, ma personalmente credo che la RPT sia secondaria e sia solo un allegato al contratto (domanda)". Che ho commentato, con un'enfasi sulle frasi commentate. L'essenza del commento: in certe condizioni, ToR può essere autosufficiente (primario nella vostra terminologia). Beh, è così, a una parola, un argomento di discussione in realtà non c'è :)
Quindi nella vita reale, il contratto/accordo viene prima, non ho mai incontrato un ToR senza un accordo (e di solito il ToR è solo un'informazione tecnica, mentre l'accordo è l'essenza principale della relazione legale tra le parti).
Personalmente, sono abituato alla seguente sequenza:
1. un accordo/contratto di lavoro (che specifica il cliente, l'appaltatore, l'essenza principale del lavoro da fare, i tempi del lavoro, l'importo pagato dal cliente all'appaltatore, la responsabilità delle parti e informazioni aggiuntive se necessario);
2. Termini di riferimento (TOR) che descrivono in dettaglio il compito stesso e forniscono caratteristiche specifiche del lavoro da eseguire (il cliente non è obbligato a capire il TOR);
Atto di completamento;
Pagamento del lavoro o delle sue fasi.
Sulla base di quanto sopra, credo che in circostanze normali, il contratto (leggi offerta) ha uno status più alto del TOR (i ToR sono formati sulla base del contratto con la specifica dettagliata del lavoro o una fase specifica).
Suppongo che nel nostro gli sviluppatori (come organizzatori del servizio) devono essere più dettagliati nel contenuto della domanda, avvicinandolo al contratto reale.
Può anche valere la pena di evidenziare il processo di formazione delle RPT, permettendo all'esecutore di ricevere una certa somma (specificata con precisione o come percentuale dell'ordine), naturalmente, se l'esecutore ha preparato lui stesso la RPT e il cliente l'ha accettata.
pronych:
А вообще, проще всего не мудрить с правилами, а просто, при вводе заявки добавить "снятую" галку, типа "хочу исходники" и отражать это в списке заданий. кому надо, тот отметит флажок. небольшой апдейт, а как приятно. и всем всё сразу понятно будет.
Questo è il lato tecnico della soluzione di una parte del problema. In effetti, tu stai proponendo un requisito per i clienti di "decidere il tipo di file finale", per decidere nella fase di compilazione dell'applicazione. Di conseguenza, un tale requisito per i clienti dovrebbe (da un punto di vista formale) essere riflesso nelle regole. I clienti devono capire cosa viene loro richiesto.
Inoltre, l'appaltatore (nel suo stesso interesse) non dovrebbe diventare compiacente alla vista di una domanda, ma dovrebbe far concordare la questione direttamente nei termini di riferimento.
E in generale, il modo più semplice per non fare un casino con le regole, ma semplicemente, quando si inserisce la richiesta di aggiungere "deselezionato", come "Voglio fonti" e rifletterlo nella lista dei lavori. chi ne ha bisogno, egli controllerà la casella di controllo. un piccolo aggiornamento, ma che bello. e tutto in una volta sarà chiaro.
A mio parere, la "domanda" stessa ha bisogno di essere rielaborata in modo più dettagliato. Non solo, ma dovrebbero essercene molti di più. Per esempio, potete anche controllare le condizioni che permettono/impediscono all'esecutore di usare algoritmi e codice di programma in futuro.
Anche se capisco che queste cose sono molto difficili da controllare.
PS
È che come ho capito che in contrasto con il cliente nessuno interferire per replicare il lavoro (soprattutto se c'è il codice sorgente) e l'artista può facilmente mettere in negozio o rivendere ad un altro cliente.
Questo è il lato tecnico della soluzione di una parte del problema. In effetti, tu stai proponendo un requisito per i clienti di "decidere il tipo di file finale", per decidere nella fase di compilazione dell'applicazione. Di conseguenza, un tale requisito per i clienti dovrebbe (da un punto di vista formale) essere riflesso nelle regole. In modo che capiscano ciò che è richiesto loro.
Inoltre, il contraente (nel suo stesso interesse) non dovrebbe diventare compiacente alla vista di una domanda, ma dovrebbe raggiungere un accordo su questo tema direttamente nei termini di riferimento.
Per essere precisi, è piuttosto necessario fare una sorta di scelta condizionata. Se il cliente vuole necessariamente le fonti, allora non c'è niente da fare, altrimenti l'appaltatore avrà una scelta.
In questo caso, il cliente deve capire che le fonti e l'esclusività del lavoro (se c'è) avranno un costo extra.
Dopo averci pensato su, penso questo. Se un programmatore scrive qualcosa secondo i termini di riferimento del cliente, deve anche dargli il codice sorgente. In primo luogo, è improbabile che gli sviluppatori dicano che nessuna nuova build avrà mai bisogno di essere ricompilata di nuovo. In secondo luogo, è necessario risolvere eventuali controversie. È possibile che il TOR sia stato formulato in modo errato, che sia stato frainteso o che il programmatore abbia semplicemente commesso un errore. Nel primo caso, il cliente deve pagare la rielaborazione in un nuovo ToR o lasciare il programmatore da solo. Nel secondo e terzo caso, il programmatore deve correggere i suoi errori gratuitamente. Come posso capire chi ha ragione senza codice sorgente?
Cosa c'è nel codice sorgente che non può essere passato al cliente? Una buona idea di vendita, cioè la TOR, vale molto di più di alcuni segreti dei programmatori.
Se vendi un software che è scritto su tue idee, allora il trasferimento del codice sorgente è fuori questione.
Sulla base di quanto segue credo che in circostanze normali un contratto (leggi applicazione) . ..
Qui c'è un errore fondamentale. Un contratto è un accordo tra due o più persone. Una domanda è solo una proposta di una parte, che di per sé non può essere considerata un contratto. In termini di regole in discussione, una relazione contrattuale viene in essere (conclusione di un contratto) solo dopo che i Termini di Riferimento sono stati emessi. I termini di riferimento sono destinati a riflettere i dettagli del lavoro concordato dalle parti .
L'approccio del Contratto d'opera che lei ha descritto può essere chiamato "classico", il che non esclude l'esistenza di altre forme uguali di costituzione della relazione contrattuale che sono sorte. In senso figurato, il capitolo 36 "Contratto-Accordo" del Codice Civile è una classe madre con i suoi membri pubblici e protetti e le funzioni virtuali, e la specifica dei requisiti è una delle possibili classi discendenti. :)
Interesting:
Questo è il lato tecnico della soluzione di una parte del problema. In effetti, tu stai proponendo un requisito per i clienti di "decidere il tipo di file finale", per decidere nella fase di compilazione dell'applicazione. Di conseguenza, un tale requisito per i clienti dovrebbe (da un punto di vista formale) essere riflesso nelle regole. I clienti devono capire cosa viene loro richiesto.
Inoltre, il contraente (nel suo stesso interesse) non dovrebbe diventare compiacente alla vista di una domanda, ma dovrebbe raggiungere un accordo su questo tema direttamente nei termini di riferimento.
Per essere precisi, è piuttosto necessario fare una sorta di scelta condizionata. Se il cliente ha necessariamente bisogno del codice sorgente allora non c'è niente da fare, altrimenti l'artista avrà una scelta.
In questo caso, il cliente deve capire che le fonti e l'esclusività del lavoro (se c'è) avranno un costo extra.
Dopo averci pensato su, penso questo. Se un programmatore scrive qualcosa secondo i termini di riferimento del cliente, deve anche dargli il codice sorgente.
Cosa c'è esattamente nel codice sorgente che non può essere passato al cliente? Una buona idea di vendita, cioè la TOR, vale molto di più di alcuni segreti di programmazione.
Se state vendendo un software scritto sulla base delle vostre idee, consegnare il codice sorgente è fuori questione.
Il codice sorgente può essere un template ben progettato, con un sacco di funzioni extra, classi, ecc. Può consistere in un mucchio di blocchi (inlude, per esempio) e solo alcune delle condizioni in esso possono essere diverse. Siete pronti a dare sei mesi (in un caso semplice) di lavoro, nel codice sorgente di una dozzina di file diversi di un sistema (sistema, nel senso di interazione con l'altro), in cui solo il modulo segnale (una classe (file)) differisce?
Capisco che possiamo usare strumenti standard per mandare in crash le maschere, e non è un peccato. Ma se si mettono enormi sforzi nel modello, come si può fare? No, sei pronto?
Dopo averci pensato su, penso questo. Se un programmatore scrive qualcosa secondo i termini di riferimento del cliente, deve anche dargli il codice sorgente. In primo luogo, è improbabile che gli sviluppatori dicano che nessuna nuova build avrà mai bisogno di essere ricompilata di nuovo. In secondo luogo, è necessario risolvere eventuali controversie. È possibile che il TOR sia stato formulato in modo errato, che sia stato frainteso o che il programmatore abbia semplicemente commesso un errore. Nel primo caso, il cliente deve pagare la rielaborazione a un nuovo ToR o lasciare il programmatore da solo. Nel secondo e terzo caso, il programmatore deve correggere i suoi errori gratuitamente. Come posso capire chi ha ragione senza codice sorgente?
Cosa c'è nel codice sorgente che non può essere passato al cliente? Una buona idea di vendita, cioè la TOR, vale molto di più di alcuni segreti dei programmatori.
Se vendi un software che è stato scritto sulla base delle tue idee, allora il trasferimento del codice sorgente è fuori questione.
1. il trasferimento obbligatorio del codice sorgente è appropriato solo quando il lavoro da fare è esclusivo, ma come capite il prezzo sarà diverso (eventualmente più volte superiore).
Anche la questione della ricompilazione può essere risolta all'inizio.
2. Per quanto riguarda i ToR.
Beh, non ho visto idee "buone" su Forex, che costerebbero più di una "buona" implementazione del software.
In risposta alla tua domanda - il codice sorgente ha la capacità di permettere al cliente di sostenere che lui è il legittimo proprietario e può fare qualsiasi cosa con il codice (per esempio, venderlo).
Quindi, molto probabilmente stiamo parlando dell'esclusività del lavoro (e qui sostengo che i programmatori non cercano di diffondere il codice sorgente).