Domanda:
Come dovrei dividere [eticamente] il mio tempo fatturabile, quando il mio lavoro è reciprocamente vantaggioso per più clienti?
RLH
2012-07-17 22:59:02 UTC
view on stackexchange narkive permalink

Considera la circostanza in cui qualcuno lavora per più clienti e addebita loro una tariffa oraria. Questo è abbastanza comune. Tuttavia, in che modo un lavoratore a contratto con frequenza oraria dovrebbe fatturare i propri clienti quando, nella rara circostanza in cui possono lavorare una sola volta, ciò è reciprocamente vantaggioso per più clienti?

In altre parole, supponi che qualcuno abbia due clienti , A e B. Il cliente A e B non hanno rapporti tra loro. Tuttavia, dopo aver iniziato a lavorare su entrambi i progetti, ti rendi conto che puoi consolidare circa il 20% del lavoro per entrambi i progetti. Completa il lavoro una volta e il 100% (del 20%) può essere condiviso reciprocamente tra i due progetti?

Qual è il modo etico di dividere la fatturazione di questo lavoro tra i tuoi clienti? La risposta iniziale e viscerale è che potresti / dovresti far conoscere ai tuoi clienti la circostanza e addebitarli solo metà tempo, ciascuno. Tuttavia, non tutti i clienti apprezzano questo modello: vogliono che il 100% del tuo lavoro appartenga a loro.

Ad esempio, immagina di essere un ingegnere del software e scrivere codice freelance. Alcuni clienti vogliono che tu scriva il tuo codice, rigorosamente per loro. Posso capirlo, soprattutto se il tuo codice è di proprietà contrattuale e di proprietà del tuo cliente. Tuttavia, questo non è sempre plausibile. C'è una grande differenza tra il riutilizzo del layout di un sito, della struttura del database o del back-end, del codice del server e la condivisione di una base di codice di livello molto basso che si occupa di semplici attività che la piattaforma di sviluppo sottostante avrebbe potuto includere, ma non ha. Questa è una circostanza comune e riscrivere lo stesso codice è considerevolmente ridondante e, francamente, non realistico.

Un altro avvertimento è che l'esempio di due clienti, con un requisito di divisione è un po 'semplice.

Di nuovo, prendi il mio esempio di codifica. Potreste rendervi conto che per un particolare insieme di progetti software, potreste consolidare requisiti simili in un "framework" di codice. Nessuno dei due progetti dei clienti utilizzerà il tuo framework al massimo del suo potenziale. Tuttavia, c'è abbastanza somiglianza tra i due, che metterli insieme ha senso e, a lungo termine, potrebbe far risparmiare un po 'di tempo a entrambi i clienti.

Qual è il modo etico di gestire questo tipo di situazioni ? Non sono un libero professionista, ma devo registrare orari per varie società interne per cui lavoro. Non è un grosso problema per me tenerne traccia perfettamente (perché tutte queste società sono di proprietà della stessa società), tuttavia, questo è qualcosa che ho sempre messo in dubbio. Soprattutto considerando che potrebbe arrivare il giorno in cui diventerò un lavoratore freelance per queste aziende e dovrò trovare un modo per suddividere eticamente il lavoro per la fatturazione.

Sei risposte:
Justin Cave
2012-07-17 23:20:21 UTC
view on stackexchange narkive permalink

Questo è qualcosa che dovrebbe essere specificato nel contratto che hai con i clienti. Se il cliente vuole possedere assolutamente ogni riga di codice, deve pagare per la sua produzione, devi reimplementare la stessa funzionalità per l'altro client e non puoi usare un framework comune. Se il cliente desidera un costo inferiore, non può possedere ogni riga di codice, puoi sfruttare il codice e i framework dei clienti precedenti e in genere sarebbe appropriato dividere la fatturazione 50/50.

acolyte
2012-07-18 00:46:25 UTC
view on stackexchange narkive permalink

Alcuni clienti vogliono che tu scriva il tuo codice, rigorosamente per loro. Posso capirlo, soprattutto se il tuo codice è di proprietà contrattuale e di proprietà del tuo cliente. Tuttavia, questo non è sempre plausibile.

No. Se il tuo contratto stabilisce che devi scrivere il tuo codice, rigorosamente per loro, allora scrivi il tuo codice, rigorosamente per loro. Se non lo fai e riutilizzi il codice / usi il codice che hai creato altrove per loro, puoi (e sarai, e dovresti) essere citato in giudizio per violazione del contratto.

Ora, se questo non è il caso, e puoi riutilizzare i segmenti di codice e il codice è applicabile alle esigenze di entrambi i clienti, non avrei problemi a caricarli completamente per entrambi. Ti farebbe risparmiare tempo, il che fa risparmiare loro denaro. Caricare loro meno del prezzo pieno per quel tempo condiviso in realtà ti imbroglia molto di più di quanto potrebbe sembrare.

Pensala in questo modo, se possiedi una segheria e avevi un contratto per fornire assi di legno e un altro per fornire trucioli di legno, non taglierai alcune assi e poi butterai via il legno avanzato. utilizzerai quel legno avanzato per ridurre la quantità di forniture che devi utilizzare per soddisfare le richieste del contratto di cippato. Non gli farai pagare di meno perché alcuni dei loro trucioli provenivano da pezzi avanzati, sarebbe sciocco. Alla fine, ti ritroverai con un po 'più di rifornimenti di quanto avresti normalmente, sei stato pagato di più e non hai addebitato ai clienti più di quanto si aspettassero inizialmente. Entrambe le parti sono felici.

Quando scrivi il codice, il tuo "rifornimento" è il tuo tempo.

Ora, si presume che questo codice si applichi a 2 client contemporaneamente, mentre lo si scrive. Dopo il fatto, non dovresti addebitare il prezzo intero al secondo cliente per utilizzare codice che hai già sviluppato qualche tempo in passato. In tal caso, stai addebitando il codice stesso (non il lavoro) e i costi di manutenzione.

Questo non è tecnicamente sempre plausibile. Non sto parlando di un contratto solido come una roccia per una domanda importante per qualcuno come la NASA. Invece, la maggior parte dei progetti viene completata utilizzando framework software di terze parti (la maggior parte dei quali sono spesso gratuiti e open source). Se ti ritrovi a scrivere un metodo di stringa che inverte l'ordine del testo e capitalizza ogni altro carattere per 10 progetti separati, non dovresti aggiungi qualcosa del genere al tuo framework e lo riutilizzi? Questo è il contesto di cui sto cercando di discutere. Questi dettagli raffinati non sono sempre discussi tra un libero professionista e una piccola impresa.
come ho detto, se il tuo contratto prevede che stai scrivendo il codice per il client, rigorosamente per il client, non puoi riutilizzare tutto ciò che scrivi. roba open-source ... è un'area grigia. Personalmente chiarirei l'uso di materiale open source con il client (non chiedere nemmeno se puoi usare componenti open source, chiedi solo se puoi usare un componente specifico e menzionalo è gratuito).
davvero, sembra che non dovresti accettare contratti che prevedono di scrivere codice "rigorosamente per loro". Capisco che sia una seccatura, ma se non sei disposto a rispettare questi termini, avresti dovuto provare per un contratto più flessibile. Non ti biasimerei per averci provato
Informazioni sul riutilizzo del codice: esiste una definizione formale di quale quantità di codice è considerata riutilizzo? Sono sicuro che se ho "i ++;" nel mio codice per un client, non mi è proibito usare mai più quel segmento di codice. Come evitare il paradosso dell'heap?
@vsz Come linea guida generale, se copi / incolli testo o file nel nuovo progetto, probabilmente sei nei guai. Se riscrivi il codice da zero, sulla base delle idee che ricordi dal tuo ultimo progetto, probabilmente stai bene. Se disponi di una vasta libreria di codice personale e riutilizzabile, potresti prendere in considerazione di concederlo esplicitamente in licenza separatamente dal codice prodotto come lavoro su commissione (possibilmente open source, forse no; dipende dalla tua situazione). Se hai bisogno di una risposta più specifica di quella, allora devi consultare un avvocato.
dotancohen
2014-07-06 12:54:51 UTC
view on stackexchange narkive permalink

Sono un po 'in ritardo per questa risposta, ma c'è un lato che non vedo affrontato: manutenzione”.

Anche se puoi riutilizzare le stesse idee / algoritmi (che richiedono più tempo per essere evocati di quanto sia necessario per sbattere fuori il codice), suggerisco di fatturare il tempo pieno per la loro creazione a entrambi i clienti poiché il codice divergerà e qualsiasi processo di pensiero che è stato necessario per crearlo la prima volta verrà rivalutato la prossima volta che compilerai quella classe.

Questo non "strappa" il cliente, ma è una pratica accettata in ogni campo. Il tuo imprenditore edile paga per il legno meno di te perché acquista legno per te e per altri 20 clienti ogni anno. Allo stesso modo, la tua materia prima (il tuo cervello) viene utilizzata in blocco anche per più clienti e questo è tuo vantaggio per loro, non da loro . Ecco perché vengono da te!

Michael
2012-07-17 23:31:10 UTC
view on stackexchange narkive permalink

La mia opinione sarebbe diversa in base al contratto che hai con i clienti.

Se ti viene assegnato un prezzo fisso per un determinato prodotto, non c'è niente di eticamente sbagliato nel perfezionare i tuoi processi per aumentare il tuo profitto. Ad esempio, se hai costruito, ad esempio, un tavolino da caffè e venduto ciascuno per $ 100, ma hai trovato un modo per ridurre il costo per realizzarli del 20%, non sei tenuto a trasferirli al cliente a un prezzo scontato. È solo un buon affare e tu intascerai il profitto.

Se hai un contratto per una stima di ore a una tariffa oraria, dividerei il tempo tra i due clienti. Il problema con questo pensiero, tuttavia, è come fatturare i futuri clienti che utilizzano questo stesso framework? O lo ottengono gratuitamente?

Tendo a usare il tipo di approccio "bleeding edge", il che significa che il cliente con la prima esigenza del framework riceverà i costi (supponendo che sia nell'accordo comunque) e i futuri clienti ne trarranno vantaggio. Eticamente, questo funziona bene nella mia mente perché alla fine il secondo cliente prenderà il "margine sanguinante" su una funzionalità diversa mentre il primo cliente ne trarrà i benefici. Inoltre, rende la fatturazione meno complicata perché non ti ritrovi a dover dividere i costi per un numero infinito di funzionalità create in precedenza.

IDrinkandIKnowThings
2012-07-17 23:22:35 UTC
view on stackexchange narkive permalink

Se il codice appartiene a te, puoi addebitare ai tuoi clienti ciò che sono disposti a pagare.

Se stai creando un'opera su commissione e il codice appartiene a loro, condividere il codice sarebbe una violazione dell'etica. Il codice che hai scritto per la società A appartiene alla società A. Potresti riuscire a convincere la società A a darti una liberatoria per quella sezione del codice che ti permetterebbe di condividerlo con l'altro cliente. Molte aziende sono disposte a fare una licenza FOSS per sistemi non critici. Ma alcune aziende sono fortemente proprietarie del loro lavoro su commissione. Inoltre, se il tuo prodotto di lavoro appartiene alla società A, potresti essere limitato nella tua capacità di riscrivere quel codice per la società B.

mckenzm
2017-09-14 02:55:52 UTC
view on stackexchange narkive permalink

È molto comune in alcune professioni fatturare lo stesso tempo e materiale a più clienti. Soprattutto la legge, dove taxi e voli possono essere prenotati per più casi come se fossero l'unico caso. Dovresti basare il tuo comportamento sulle aspettative di fatturazione generalmente accettate per la tua regione. Un approccio basato sul listino prezzi è prudente in quanto ci sarà una minore variazione rispetto alla stima. E se hai torto e vieni pagato in base alla "Percentuale di completamento"? Fin dal medioevo sono stati fissati i prezzi per l'utilizzo di risorse condivise (come l'unico forno in città) indipendentemente dal numero di utenti. C'è la certezza nel non scherzare con i prezzi.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...