Come dovremmo citare contratti di dimensioni diverse in un ambiente SCRUM

4

Sto cercando di implementare un approccio agile alla nostra azienda. In questo momento abbiamo un approccio molto simile alla progettazione, alla codifica, al test e al rilascio. Uno dei problemi principali a cui non abbiamo trovato risposta è l'idea di quotare. Permettiamo ai nostri clienti di richiedere piccole e grandi modifiche nel sistema e di pagare per quelle modifiche individuali tramite un ordine di lavoro. Ad esempio, un cliente può richiedere che un campo venga spostato di un millimetro in alcuni dei suoi report, mentre un altro cliente richiede un'estensione di centinaia di ore al software di base. Il modo in cui citiamo ora è piuttosto inefficiente. Fondamentalmente noi, io e il mio capo, guardiamo il codice e indovina quante ore uomo ci vogliono per finire. A volte chiediamo allo sviluppatore che ci lavorerebbe, a volte no. A volte abbiamo tutti i requisiti, a volte no. È una supposizione molto educata al meglio. Noi addebitiamo al cliente il numero di ore moltiplicato per una tariffa predeterminata una volta che abbiamo una stima. Puoi immaginare quante volte superiamo le nostre stime con il lavoro effettivo.

Dal momento che consentiamo modifiche e contratti di tale portata diversa, come possiamo fare un preventivo efficacemente in un processo SCRUM o Agile? Mi piace l'idea di quotare per punti anziché ore e utilizzare le pratiche di stima SCRUM per determinare i punti, ma il mio capo non è un fan perché pensa che abbiamo bisogno di avere le nostre citazioni fatte e pagate prima che entrino in qualsiasi tipo di prodotto arretrato. La sua convinzione è che non possiamo citare in alcun altro modo perché abbiamo bisogno di bloccare il cliente in un contratto specifico per evitare modifiche lungo la linea.

Ultimamente, ci siamo imbattuti in molti problemi con i clienti che hanno cambiato le specifiche all'ultimo minuto e si sono arrabbiati con noi per avergli addebitato i cambiamenti o aver negato le modifiche. Mi piace guardare il manifesto agile e pensare alla collaborazione sui contratti, ma nessun altro nella mia azienda è ancora venduto.

Esiste un modo per quotare efficacemente in un processo SCRUM in cui non abbiamo contratti regolari a tempo, ma invece abbiamo un diverso grado di richieste di modifica pagate da clienti diversi?

Se hai bisogno di ulteriori informazioni fammi sapere. Apprezzo l'intuizione.

    
posta Carson 04.05.2016 - 22:53
fonte

4 risposte

1

'my boss's' belief is that we cannot quote any other way because we need to lock the customer into a specific contract to avoid changes down the line.

sembra essere confutato da

Lately, we have run into many issues with customers changing specs last minute

Questo non è un problema univoco. La negoziazione del contratto favorisce quelli con gli avvocati più costosi. Altrimenti è meglio lavorare con clienti flessibili, capire di cosa è agile e in realtà vogliono software di lavoro alla fine del progetto, piuttosto che qualcuno esterno da incolpare quando il progetto fallisce.

Capisco che non ti sia molto utile ora, quindi ti suggerisco di consultare gli orari. Fatele fuori per un numero prestabilito di ore in anticipo e sincerate con loro che questa è una stima iniziale per far partire le cose e che potete perfezionarle più tardi. Se poi lavori a stretto contatto con un rappresentante del cliente per dare la priorità al tuo arretrato, puoi sempre lavorare su ciò che il cliente pensa sia il più importante. A un certo punto decideranno di aver affrontato tutto il lavoro ad alta priorità e non avranno bisogno di pagare altre ore, le storie lasciate sul backlog non erano ovviamente così importanti per loro, qualunque cosa avessero detto all'inizio. Hai bisogno di un po 'di prevedibilità, quindi ti suggerisco di fatturare in blocchi, 1 ora, 5 ore, 10 ore, 1 settimana, 1 mese, qualunque sia il caso, quindi hai un'idea di quanti soldi ci saranno e potrai pianificare il tuo stipendio.

Per quanto riguarda le stime del tempo, devi sempre coinvolgere le persone che effettivamente faranno il lavoro altrimenti ti stai chiedendo dei problemi. E se riesci a tenere traccia delle tue stime e quindi a tenere traccia del tempo necessario, dovresti essere in grado di costruire un modello per stimare meglio in futuro.

    
risposta data 05.05.2016 - 11:43
fonte
0

Se lavori in modo agile, ciò dovrebbe riflettersi anche nei tuoi prezzi.

Ie. Invece di stimare, quotare e soddisfare un ordine per un prezzo stabilito. Dovresti citare per sprint.

Esegui e stimati come al solito, ma sii sincero con il cliente che se lo sprint viene eseguito, o se vogliono aggiungere altre funzionalità, dovranno pagare di più.

Sebbene suoni fuori posto, sta diventando un modo abbastanza comune di quotare. La vendita è che quel cliente non deve assumersi lo sforzo e il rischio di specificare il progetto in anticipo.

Lavori con loro in modo collaborativo e paga per il tempo / risorsa che usano durante il corso del progetto.

Sebbene esista il rischio che il progetto esaurisca il budget prima del completamento nel modello aglie. Questo è bilanciato dal rischio evitato di mis, o dalla speculazione del progetto nel modello a cascata.

Inoltre, è possibile aggiungere che nei contratti a prezzo fisso il venditore avrà un prezzo in media superata e "mantenendo il cliente soddisfatto". Quindi il pagamento con il modello sprint può risultare più economico se non si esegue un overrun o si apportano modifiche alle specifiche. (che nessun cliente pensa che faranno mai)

    
risposta data 04.05.2016 - 23:48
fonte
0

Ci sono 2 modi principali per affrontare questo:

  1. cita come prima - non è responsabilità del cliente considerare come funzionano i tuoi processi interni, pagano, consegnano. La sua parte di fare affari ti consente di ottenere le tue quotazioni abbastanza alte da ottenere un profitto e abbastanza basso da ottenere il lavoro invece dei tuoi concorrenti.

  2. citazione su base "tempo e materiali". Questo è un contratto 'rolling' in cui pagano il tempo necessario, indipendentemente da quanto a lungo o da ciò che vogliono. Vogliono più cose, nessun problema, lo strumento continua a funzionare.

L'opzione 2 è la migliore per te, ma non necessariamente per il cliente. Se improvvisamente inizi a caricarli molto di più per lo stesso tipo di modifiche che noteranno, perderai l'attività o perderai la loro buona volontà. Se la tua strategia di sviluppo agile funziona bene, e ottengono cambiamenti più velocemente (e quindi più economici), accadrà il contrario.

Se non puoi optare per la seconda opzione e molte aziende semplicemente non sono impostate per tali contratti a tempo indeterminato in quanto non possono facilmente budget per loro, allora dovrai stimare quanto tempo impiegare, fatturarle di conseguenza e prendi il colpo se non puoi consegnare (o prendi i soldi se lo fai!)

    
risposta data 05.05.2016 - 09:49
fonte
0

Bene, in un modo o nell'altro si tratta di quanto sia accurata la stima del lavoro in questione. E come gestisci il rischio.

Suggerirei di avere processi separati per modifiche minori e modifiche importanti. Mods minori, tuttavia, si decide di definirli, potrebbero essere fissi i cambiamenti di prezzo, (indipendentemente dalle ore lavorate).

Le mod principali avrebbero una struttura di addebito più complessa, che potrebbe essere negoziata con il cliente. Supponiamo che tu abbia un contratto a prezzo fisso per il progetto, quindi il prezzo del contratto sarà accettato in modo da accettare il rischio di un superamento del progetto. In alternativa, se addebiti a ore, il cliente sta trasportando più rischi.

Potresti provare un costo anticipato stimato (ad esempio un numero fisso di ore) e quindi una tariffa oraria ridotta. Le modifiche alle specifiche saranno addebitate in aggiunta al prezzo originale.

    
risposta data 04.07.2016 - 16:52
fonte

Leggi altre domande sui tag