Arbitrato - regole, regolamenti, scadenze. - pagina 5
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
Mi scusi, può citare esattamente dove è avvenuto l'incidente? Oppure dammi la data e l'ora del messaggio.
Così posso tenerlo a mente per il futuro! Perché, si sa, non ci si vede da fuori!
Mi scusi, può citare esattamente dove è avvenuto l'incidente? Oppure dammi la data e l'ora del messaggio.
Così posso tenerlo a mente per il futuro! Perché, si sa, non ci si vede da fuori!
Tutto è comunque online:
http://novikov.dp.ua/fortrader/sovetniki/sovetnik-pomoshhnik-assistant.html
e il dialogo senza gli ultimi battibecchi _http://novikov.dp.ua/news/dialog-s-programmistom.html
Ho letto la corrispondenza (ne è bastato solo un terzo). Sembra che sia stato l'appaltatore ad agitare le acque.
D'altra parte, un certo numero di requisiti del cliente sono ingiustificati. Per esempio, il ToR non dice che il codice deve essere commentato.
Un ruolo importante è stato giocato anche dall'aggressività del cliente nei confronti dei bug rilevati.
Dobbiamo capire che un programma su misura è un complesso sforzo di collaborazione. E dobbiamo distinguere tra un bug, un'incoerenza con il TOR, un'incomprensione del TOR. Inoltre, l'enfasi dovrebbe essere spostata un po' perché il cliente non sta testando il prodotto per i bug, ma sta conoscendo il suo funzionamento e la sua funzionalità e controllando la conformità con i termini di riferimento. E, sì, identifica gli insetti allo stesso tempo.
Non c'è niente di male negli insetti. La cosa principale è essere in grado di ripararli. Inoltre, nessuno sviluppatore sano di mente garantirà mai che non ci siano bug nel suo prodotto.
Ho letto la corrispondenza (ne è bastato solo un terzo). Sembrava che fosse l'appaltatore ad agitare le cose.
D'altra parte, alcuni requisiti del cliente sono illegali. Per esempio, il ToR non dice che il codice deve essere commentato.
Un ruolo importante è stato giocato anche dall'aggressività del cliente nei confronti dei bug rilevati.
Dobbiamo capire che un programma su misura è un complesso sforzo di collaborazione. E dobbiamo distinguere tra un bug, incoerenza con i termini di riferimento, incomprensione dei termini di riferimento. Inoltre, l'enfasi dovrebbe essere spostata un po' perché il cliente non sta testando il prodotto per i bug, ma sta conoscendo il suo funzionamento e la sua funzionalità e controllando la conformità con i termini di riferimento. E, sì, identifica gli insetti allo stesso tempo.
Non c'è niente di male negli insetti. La cosa principale è essere in grado di ripararli. Inoltre, nessuno sviluppatore sano di mente garantirà mai che non ci siano bug nel suo prodotto.
Se contate il numero di volte che l'implementatore ha detto "è fatto, chiudete il lavoro" o qualcosa del genere, potete stancarvi di contare!
Ed è ancora più esasperante quando si trova un altro bug.
E sono completamente d'accordo che non c'è niente di male nei bug, a patto che l'esecutore reagisca adeguatamente ai commenti e li corregga!
E tutti i nuovi bug sono stati trovati! Ho appena letto gli ultimi commenti (2014.04.08 16:54) dell'implementatore sul bug che ho identificato.
Anche se l'esecutore (2014.04.01 10:57) ha detto: "Beh, questo è tutto. Portatelo via, guardate! Se c'è qualcosa che non va, scrivetemi".
Basta leggere gli ultimi commenti ...
Scrivi come se tu e l'interprete foste interessati alla tua biancheria intima. C'è un thread chiuso e non c'è bisogno di prendere argomenti dal nulla. C'è l'arbitraggio per sistemare le cose, c'è il feedback.
E non è serio e degno di avere una resa dei conti pubblica. Il cliente non si preoccupa della sua reputazione.
Chi ha portato la spazzatura in pubblico dovrebbe essere colpevole - se l'arbitrato è equo, dovrebbe finire a favore dell'appaltatore.
Ho deciso di non creare un nuovo argomento e continuare con uno già esistente.
Quali sono le scadenze dell'arbitrato?
Attualmente sono in arbitrato. Non è la prima volta che questo accade. Un nuovo arrivato è venuto sul mio sito e ha deciso che era possibile chiedere miglioramenti gratuiti illimitati e ricattarlo con denaro. Dicono che se vi rifiutate di finalizzare ciò che chiedo - non avrete i soldi. E non importa che questo non sia nel TOR. Mi piace anche quando il cliente dice: "La mia strategia è provata e funziona. L'ho usato per 2 settimane e scambiato sul lato positivo. Quindi non vi darò i soldi fino a quando il programma ha fatto un guadagno stabile per 3-5 anni! E poi un sacco di lavoro gratuito, altrimenti "non ti darò i soldi".
Ora passiamo all'arbitraggio. Quando ho iniziato l'arbitraggio, il nuovo arrivato ha improvvisamente cambiato la sua strategia. Ha iniziato a scrivere che tutto non funzionava bene e che non era stato fatto nulla, e in un messaggio privato si è offerto di comprare un codice sorgente per il 50% del prezzo, perché ha detto che avrebbe comunque preso i soldi da me. L'arbitrato si trascina da un mese. L'amministratore si è presentato 2 volte alla settimana all'inizio e ha cercato di occuparsene, poi ha smesso di rispondere di persona e ha scritto nell'oggetto. Poi un altro amministratore è venuto e si è scusato per il ritardo nel risolvere le cose. Poi è arrivato un altro amministratore e si è scusato per il ritardo. Non scrive nulla e non risponde nello spogliatoio.
È normale? I programmatori si fanno pagare il 10% del loro lavoro per cosa? Sono d'accordo che la commissione deve essere e il sito di questo livello non dovrebbe essere mantenuto sull'entusiasmo degli amministratori, ma voglio e servizio per tale piccolo, come per me, percentuale?
Si prega di consigliare, consigliare. admins - unsubscribe, altrimenti in un ramo di silenzio e non rispondere in persona :((((
Nessuno è interessato a questo argomento? O nessuno ha avuto a che fare con l'Arbitraggio?
Non si tratta di chiudere il lavoro il più rapidamente possibile. Si tratta della lunghezza del tempo e dell'ignorare un paio di loro. Perché non ci sono scadenze o regole di arbitrato? Chi deve cosa a chi?
Il mio lavoro è fondamentalmente chiuso 50/50. E questo dopo più di un mese. Perché ci vuole così tanto? Ho avvertito il cliente cinque volte e mi hanno rimproverato che è per questo che ho ricevuto solo la metà del denaro.
Ora ho ricevuto il 40% dell'importo originale, e questo cliente insolente pretende ora di fornirgli il codice sorgente del lavoro! :-О
Quindi forse abbiamo bisogno di un regolamento sull'arbitrato? Chi lo sosterrà? Quali sono le vostre opinioni?
Abbiamo un accordo con il cliente, ma non abbiamo un accordo con il sito. Quindi il sito ci fa pagare tutte le commissioni che vuole e può bloccare i soldi dopo il lavoro, e gli artisti non hanno diritti?
Non possiamo pretendere nulla per i nostri soldi che paghiamo dall'ordine? :((
È difficile dire cosa sia successo veramente lì.
Non c'è bisogno di capirlo. La situazione è dolorosamente semplice e diretta.
Se lei, come sviluppatore, avesse giustificato in modo chiaro e inequivocabile, punto per punto, di aver rispettato tutte le disposizioni del TOR, il cliente non avrebbe potuto assillarla - e l'arbitrato non avrebbe avuto motivi per risolvere l'accordo contro di lei - e l'arbitrato non sarebbe durato più di un mese.
Se il cliente richiede qualcosa che non è nei ToR, è facilmente giustificabile. Se non si poteva giustificare che i requisiti del cliente erano al di fuori dei ToR, allora si doveva rispettare tali disposizioni.
Mi sembra che l'arbitrato non debba nulla né al cliente né allo sviluppatore. Se lo sviluppatore vuole vincere l'arbitrato, deve fornire la giustificazione che i ToR sono stati rispettati. Se non c'è questa giustificazione, allora il compito non è stato portato a termine.
Mi sembra che nell'arbitrato freelance ci debba essere:
a) la presunzione di innocenza del cliente
b) la presunzione di colpevolezza del committente
Il cliente potrebbe non sapere molte cose, potrebbe non essere in grado di esprimersi in modo storto, o potrebbe non essere in grado di spiegare le cose chiaramente.
Il cliente non si impone allo sviluppatore. È lo sviluppatore che accetta di fare il lavoro. È lo sviluppatore che valuta il TOR per la fattibilità e confronta le loro capacità. Lo sviluppatore è più competente del cliente.
Se si verifica un arbitrato, è responsabilità dello sviluppatore giustificare una cosa, che i ToRs sono soddisfatti.
Se lo sviluppatore non può giustificare che i termini di riferimento sono soddisfatti, il lavoro deve essere terminato al 100% a favore del cliente.
Scioglimento "a metà" -- questo è di fatto -- una perdita netta del 50% dei soldi del cliente -- che il cliente sta in qualche modo pagando per il lavoro non fatto -- per lo sviluppatore che lo prende e non lo finisce -- per il cliente che deve ricominciare da zero. Nessuno vuole il tuo codice sorgente incompiuto.
C'è solo un criterio: i ToR soddisfatti. Se i termini di riferimento sono soddisfatti, giustificatelo. Se non si può giustificare, se i termini di riferimento non sono stati rispettati, restituite i soldi al cliente e toglietevi di mezzo.