È agile un buon adattamento quando si presenta contro altri venditori? [duplicare]

Question

È agile un buon adattamento quando si presenta contro altri venditori? [duplicare]

#1 da (4 voti)

1

Stiamo cercando sempre più agile nella mia azienda, ma penso che funzioni meglio per alcuni progetti rispetto ad altri.

Abbiamo un prodotto che è tutto nostro e controlliamo la tabella di marcia. Questo è ovviamente perfetto per l'agile.

Tuttavia, gran parte del nostro lavoro comporta l'inserimento di una proposta o un'offerta contro altri fornitori per lo sviluppo personalizzato. In genere i clienti si aspettano documentazione su ciò che possono aspettarsi e vogliono conoscere il budget in anticipo. È davvero adatto per un processo agile? Negoziati contrattuali e documentazione sono dalla parte sbagliata del manifesto agile ma sono anche parte integrante del tentativo di conquistare nuovi affari.

Ovviamente tu e io sappiamo che le specifiche non possono mai accuratamente refelct ciò che gli utenti realmente vogliono. Nella migliore delle ipotesi sarà corretto all'80% e alla fine ci saranno richieste di cambiamento. Sappiamo anche che le stime saranno difficili da ottenere, ma quando si ha a che fare con grandi corps, vogliono sempre un costo fisso e il piccolo venditore si assume il rischio se supera il budget. Ovviamente alla fine devono pagare i cambiamenti quindi non è un budget fisso, ma come convincere un cliente di questo quando altri venditori promettono di poterli consegnare?

Quindi, da un lato, un processo agile darebbe un prodotto finale migliore ma dall'altro, se non si produce documentazione e un budget fisso, sarà difficile conquistare il business.

Ci sono esempi di agile funzionamento in questo ambiente?

agile

posta Ben Thurley 17.12.2015 - 12:31

fonte

1 risposta

Leggi altre domande sui tag agile

Mescolando OOP e Non-OOP Che cosa scelgo se uso il codice sorgente da un progetto GPL2 e un altro codice sorgente dal MIT?

score 4 · Answer 1

Stimare e fare offerte è una cosa, fare in modo che il contratto sia l'attività di manager, addetti alle vendite e avvocati, ma il modo in cui sviluppi il software dopo aver ottenuto il contratto è un problema separato. E i requisiti (inizialmente) scritti nel contratto e il prezzo dovrebbero IMHO non dipendere dalla metodologia di sviluppo. Il tuo contratto potrebbe essere parzialmente diverso perché quando pianifichi uno sviluppo agile, vuoi impegnare il cliente alla partecipazione, ma questo non è direttamente correlato agli altri punti.

Supponiamo che tu abbia negoziato un prezzo di 4 mesi di impegno per lo sviluppo, hai stipulato un contratto molto dettagliato e inizi a sviluppare una cascata. Ti attieni esattamente alle parole del contratto e, dopo tre mesi di sviluppo, consegni la prima versione. Ora è la prima volta che il cliente vede ciò che otterrà, nota gli errori / le diverse interpretazioni possibili del contratto e scopre che metà del prodotto deve essere buttata via o completamente ridisegnata per trasformare il prodotto in qualcosa di utilizzabile - molto più lavoro di un mese. Nel migliore dei casi siete entrambi d'accordo sui fraintendimenti e create un nuovo contratto, nel peggiore dei casi il cliente prova a biasimarvi per tutte le incomprensioni e cerca di ottenere tutte le modifiche per il prezzo originale.

Ora paragona questo approccio ad un approccio più "agile": inizi anche con un contratto, forse non così dettagliato, forse esattamente come dettagliato come prima, ma vale anche quattro mesi di sforzi di sviluppo. Dopo due settimane di sviluppo, fornisci la prima versione e il cliente ti fornisce un feedback tempestivo su come hai soddisfatto i requisiti. Quindi puoi confrontare molto presto il feedback con il contratto. Se necessario, è possibile rinegoziare con il cliente se ha introdotto nuovi requisiti sul tavolo. Probabilmente ci saranno altri requisiti del cliente che risultano "non così importanti come scritti nel contratto". Possono avere una priorità molto bassa, e non li sviluppi con ogni minimo dettaglio, e il cliente probabilmente acconsentirà a questo.

Quindi in entrambi i casi fai una prima offerta e una stima, e in entrambi i casi dai al cliente una documentazione "cosa può aspettarsi di ottenere" in anticipo. La differenza in "Agile" ti dà molte più possibilità di reagire presto ai desideri dei clienti, abbinare meglio lo sforzo stimato e adattare il contratto o la documentazione (in accordo con il cliente), se necessario.

Nota, in entrambi i casi, è possibile che tu abbia scritto troppi requisiti nel contratto per le ore di lavoro stimate, che è sempre un rischio - citando Nils Bohr, "La previsione è molto difficile, specialmente se riguarda il futuro ". Lo sviluppo agile, tuttavia, aiuterà (si spera) a non sprecare troppe ore in più per lo sviluppo del prodotto completamente sbagliato.