Come competere su un progetto con poche specifiche per evitare la marcia della morte della squadra [chiuso]

https://stackoverflow.com/questions/1370425

21-09-2019
|

Domanda

Sto stimando tempi e costi per una soluzione software semi-complessa, che non ha requisiti specifici per circa il 75% delle funzionalità.Vorrei comunque fare una stima quanto più corretta possibile, ottenendo dati aggiuntivi dal cliente.Ci saranno ancora parti che potrebbero non essere in grado di svilupparsi, poiché ci sono troppe dipendenze con altri prodotti/tecnologie e mancanza di definizione.Ho anche un programma molto serrato per produrre questa stima.

Ci saranno anche altri contendenti su questo progetto.Il cliente si aspetta a prezzo+durata (e probabilmente anche le funzionalità) e so che tutti se ne andranno.So che è impossibile, ma ditelo agli addetti al marketing.Un altro problema è che parlo con un intermediario e non direttamente con il cliente. Posso avere fiducia solo con gli intermediari, ma non con il cliente decisivo. Il che è un problema completamente diverso.

Quali esclusioni di responsabilità/informazioni posso non inserire nel mio piano prezzi/contratto? uccisione team con questo progetto, quindi quando il progetto inizia a rallentare (in termini di costi/tempo/funzionalità) saremo coperti con una sorta di pagamento.Naturalmente mi piacerebbe essere pagato tramite sprint o rilasci in relazione al tempo, ma dubito che il cliente possa convincersene.Sono sicuro che possiamo terminare questo prodotto prima della scadenza e creare anche un ottimo prodotto, ma come posso convincere il cliente a credermi?

Domanda

Cosa posso fare per ottenere questo progetto ed evitare marcia della morte situazione allo stesso tempo?

Qualsiasi suggerimento è benvenuto!

MODIFICARE:Risultato

Alla fine noi (io e il mio collega) abbiamo convinto il cliente che avevamo bisogno di almeno una settimana per valutare il prodotto.Così abbiamo fatto.Abbiamo anche spinto (e ottenuto) uno spazio per un incontro di alcune ore con il cliente per chiarire eventuali domande sui requisiti in sospeso.Così abbiamo fatto.L'incontro si è svolto dopo aver redatto la prima bozza di preventivo, quindi eravamo sicuri di avere tutte le domande per evidenziare dettagli che erano stati completamente fraintesi o troppo vaghi per una stima.Spero che riusciremo ad ottenere il progetto, perché per noi significherebbe 8 mesi di lavoro a tempo pieno, più una paga ragionevole.Lo sapremo tra circa una settimana e mezza.

Naturalmente ho anche sottolineato che il modo in cui forniremo questo prodotto li porterà esattamente dove vogliono essere con un prodotto che sarà effettivamente quello che volevano.E anche che ci impegniamo solo sul prezzo e sul tempo, ma non sulla funzionalità, perché è e sarà soggetta a modifiche.Penso che abbiamo fatto una buona impressione.

Soluzione

Benvenuti nel mondo dei servizi di sviluppo a prezzo fisso :-)

Tecniche per vincere questo progetto ed evitare allo stesso tempo la situazione della marcia della morte:

Non sottovalutare un progetto.Fai un'offerta per ciò che ritieni che il progetto richiederà e aggiungi una percentuale per le cose che potrebbero andare storte.
Se ti manca il 75% dei dettagli, è probabile che il progetto sarà significativamente diverso da quanto ti aspetti attualmente.Documentare alcune ragionevoli ipotesi di dettaglio all'interno dello schema del lavoro definito.Quando il progetto inizia effettivamente e i dettagli non corrispondono al presupposto, hai l'opportunità di negoziare i costi per le modifiche.A quel punto, potresti anche essere in una posizione migliore per sapere quanto sei sopra/sotto e tentare di compensare con questa quotazione.
Il tuo obiettivo in un SOW (dichiarazione di lavoro) dovrebbe essere quello di definire dettagli sufficienti in modo da darti l'opportunità di rinegoziare il costo delle modifiche quando ne saprai di più sul progetto.Scrivili come positivi, per quanto possibile.Nota, è improbabile che le persone che comprendono effettivamente il progetto leggano o capiscano il SOW... Baso questo sul punto che ti vengono forniti pochi dettagli da citare.Ciò significa che non si tratta di una vendita consultiva e nessuna delle parti è realmente concentrata sulla costruzione della soluzione "giusta".
Se riesci a ottenere un contratto come T&M (tempi e materiali), fantastico.Dubito che lo otterrai o non riuscirai a ottenerlo senza alcune restrizioni che essenzialmente vanificano lo scopo di un T&M.I tuoi potenziali clienti lo considerano come se accettassero tutti i rischi legati alle tue capacità.
Si spera che tu non sia il primo nella tua azienda a farlo.Scopri, storicamente, come sono stati i progetti e i tassi di risultato tipici.Molti gruppi di sviluppo software addebitano una tariffa oraria significativamente più alta del costo... ma i loro preventivi tendono ad essere inferiori e non in base alle ore effettive.I clienti spesso discutono più sugli orari/giorni che sul preventivo effettivo.Le imprese tendono ad essere abituate a pagare tariffe orarie elevate.
Calcola il margine atteso del tuo dipartimento (il profitto che devi ottenere dal lavoro).Questo può aiutarti a capire quanta "marcia della morte" potresti dover affrontare quando il tuo progetto fallisce.
Nella SOW specificare il livello di dettaglio che sarà richiesto in una specifica prima di iniziare il lavoro.Sebbene Agile e altri processi focalizzati sul cliente adottino un approccio orientato alla ricerca della soluzione migliore, non sono progettati per mantenere i costi sotto controllo in un ambiente di offerta fissa.Dovrai adottare un approccio a cascata rispetto ai requisiti e quindi creare in modo agile in modo da poterti adattare lungo il percorso.La specifica, come il SOW, ti darà l'opportunità di fatturare le modifiche.Anche se al cliente questo non piacerà, ciò farà sì che l'onere e i rischi associati ai requisiti ricadano su di lui e non sul tuo team.

Tieni presente che per avere successo con queste trattative, è necessario un team di gestione, vendita e gestione del progetto di supporto.Se non lo hai, sei tenuto a essere sempre in "Marche di morte". Anche se rinunci alla qualità, al processo, ai test e ad altri articoli, scoprirai che non c'è mai abbastanza tempo per un progetto.

Altri suggerimenti

In questo contesto economico, ci sono molte aziende che competono per un piccolo lavoro.Qualcuno è destinato a fare loro un'offerta molto dolce che lo farà

Non essere in grado di consegnare,
Uccidi la loro squadra con, o
Entrambi.

Quando non riescono a consegnare al prezzo concordato, inizieranno a ridurre la qualità per consegnare qualcosa ed essere pagati.

La tua sfida è presentare questo fatto al tuo potenziale cliente in modo professionale e convincerlo che lavorerai molto duramente per fornire a un costo ragionevole, ma anche per fornire esattamente ciò di cui hanno bisogno.Il fatto che torni indietro per maggiori dettagli e il metodo con cui ti avvicini al progetto (agile...ma assicurati di spiegare loro il vantaggio aziendale) aiuta a garantire che alla fine otterranno ciò di cui hanno veramente bisogno.

Ricorda, vogliono ricevere il software di cui hanno bisogno al prezzo più basso possibile.

Convincili che consegnerai esattamente alle loro esigenze e che il tuo prezzo è ragionevole.

MODIFICARE:

Affrontare la situazione degli intermediari.Penso che la migliore linea d'azione sarebbe quella di inviare un elenco di rischi insieme alla tua offerta come cortesia nei confronti del cliente.Un po' come dare loro un avvertimento su quali sono i limiti del loro progetto.Questo ti costerà un po' di lavoro in anticipo, ma penso che potrebbe aiutarti a vincere il progetto.

hai due opzioni

fare la migliore ipotesi e raddoppia o triplica la tua stima (probabilmente la concorrenza sta facendo la stessa cosa).

spiegare al cliente che non è possibile fare un'offerta per un lavoro del genere e dirgli che tutti gli altri che gli danno un preventivo fisso probabilmente non sono del tutto sinceri.

Alla fine, se non riesci a guadagnare con il lavoro, non ha senso provarci.

Personalmente preferisco quest'ultima soluzione: una comunicazione schietta e onesta con i tuoi clienti ti porterà più lontano di quanto possa mai fare qualsiasi trucco con le offerte.

Alcune cose a cui direi che dovresti pensare:

Presupposti: Non è possibile aggiungere alcuna clausola di esclusione della responsabilità, ma è necessario colmare le lacune nei requisiti con presupposti sensati e documentarli.Niente di grave o spaventoso, solo una sezione nelle specifiche/offerta con un elenco di punti elenco che dicono ciò che presumevi fosse vero e che mancava (ad es.i dettagli degli utenti verranno estratti utilizzando LDAP e non verrà scritta alcuna schermata di amministrazione per coprire l'amministrazione dell'utente).

Ciò ti dà chiarezza nella stima poiché ora hai un ampio margine su cui lavorare, ma significa anche che se il cliente torna con cose molto diverse hai una base equa per iniziare a parlare di aumentare le richieste di modifica e variare il costo.In alternativa potrebbero tornare durante le trattative dicendo che questa ipotesi o quella non è vera e tu hai maggiori informazioni.

Fuori ambito: Un caso specifico di ipotesi: elenca le cose che non includi (ad es.Non esisterà alcuna integrazione con il sistema X).Anche in questo caso ciò consente di avere una portata completa e una motivazione ragionevole per costi potenzialmente variabili in una fase successiva.

Le ipotesi e le ipotesi fuori campo sono particolarmente applicabili quando le cose vengono menzionate di sfuggita ma non realmente seguite, o per cose che si dice potrebbero attendere una seconda fase.Queste sono spesso le cose che il cliente crede vengano fatte come parte del progetto principale, ma il team di progetto no.

Si spera che la completezza e l'intuizione dei presupposti e dell'ambito definiti contribuiscano a ispirare fiducia anche nel cliente finale.

Contingenza: È complicato, ma dovresti aggiungere contingenza in due modi:

(1) per rischi specifici.Per cose che potrebbero significare che qualcosa richiede più tempo di quanto hai stimato, inserisci un importo per coprire quello ponderato in base alla possibilità che ciò accada.Somma tutto questo e questa è la tua contingenza di rischio.

(2) Le cose accadono per contingenza: succedono cose imprevedibili sui progetti IT.Aggiungere tra il 10% e il 20% per coprirlo.

Il fatto che tu nasconda o meno la contingenza ai tuoi commerciali e al cliente dipende dalla tua relazione, ma se viene rimossa devono capire cosa significa (essenzialmente supererai la corsa).

Comprendere la relazione tra impegno e costo: In qualità di tecnologo, il tuo ruolo è fornire una stima dell'impegno in base alle informazioni di cui disponi.È quindi necessario comunicarlo con ipotesi, livello di contingenza e così via al team commerciale che può convertirlo in un valore monetario.La cosa che deve essere chiara con loro è che se vogliono ridurre i costi ciò non cambia lo sforzo.

Ci sono un sacco di buone ragioni per annotare il costo per il cliente (per costruire una relazione, perché ti ritroverai con cose che puoi riutilizzare in seguito e così via), ma le persone devono capire che, a meno che l'ambito non cambi, lo sforzo rimane il lo stesso: la riduzione deriva dal profitto.

Ho un articolo sul blog che potrebbe contenere alcuni suggerimenti per te:

http://pm4web.blogspot.com/2009/06/surviving-under-resourced-project.html

uno degli altri poster qui ha ragione.ci sarà sempre qualcuno che offrirà un prezzo più basso per ottenere il lavoro.e lo sviluppatore ne soffrirà in seguito (ad es.dover fare molto lavoro gratuito per soddisfare il cliente).

alcuni clienti devono avere questa esperienza prima di capire che non è possibile realizzare progetti IT a buon mercato senza pagare una sorta di prezzo.

Scegli il realismo.Evita di promettere troppo, quindi concentrati su questo.

Molti clienti là fuori sono stati scottati da offerenti irrealistici che non riescono a mantenere quanto promesso.

Sottolineare la necessità di uno sprint delle specifiche.Trasmettere un focus sulle funzionalità principali e sull'impegno a fornire piuttosto che una miniera di funzionalità.Offrire una fase di sviluppo primaria per fornire le funzionalità principali.

Comunicare la potenza e la sicurezza dell'approccio agile.Attribuisci al cliente la capacità di vedere il buon senso.

In breve:Sforzati di sembrare realistico e serio (più dei tuoi concorrenti).La cosa più importante alla fine per ogni cliente serio è non il prezzo, ma la certezza che il prodotto verrà consegnato nei tempi e nel budget previsti.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow