Come negoziare con un'azienda per sviluppare software? [chiuso]

La negoziazione non è un gioco.

I heard in retail one side gets lawyers to put in as much things as possible and the other removes as much as possible.

False.

In a different industry I heard distributors or publishers will promise large % of royalties however you'll never see them even if the product has done well.

False.

Ecco cosa succede.

Hai dei requisiti, loro fanno un'offerta per soddisfare quei requisiti. Dovrebbero specificare il tempo e il denaro richiesti. Puoi accettarlo o puoi rifiutarlo.

Se accetti, va bene. Ti è piaciuta la loro offerta. E 'stato abbastanza completo da averlo capito e hai fiducia che consegnerà.

Se rifiuti, farai bene a suggerire miglioramenti che potrebbero fare nella loro offerta. Può essere che il tuo "miglioramento" sia impossibile o imprudente o cattivo affare. Potrebbe anche essere che il tuo "miglioramento" è una modifica ai tuoi requisiti originali che riduce l'ambito o riduce il rischio o in qualche modo rende più economico per loro costruire quello che vuoi.

Questo è tutto. Non c'è "negoziazione" come si sente in politica o controversie di lavoro o articoli di riviste di economia della gente.

È semplicemente una conversazione sulle tue esigenze e sulla loro offerta.

Una politica cattiva è una richiesta di proposta, una proposta e una passata di accettazione / rifiuto finale. Questo è comune nei governi e alcune aziende cercano di seguire questo modello. È una buona politica pubblica ma un cattivo affare. È il più equo e imparziale per tutti gli offerenti. È essenziale per operazioni governative trasparenti. Le aziende non hanno bisogno di questo livello di trasparenza, se qualità, servizi o prodotti sono adatti per le aziende.

Una politica migliore è una conversazione prolungata in cui discuti il possibile ambito di lavoro e sia tu che il venditore agisci responsabilmente nella definizione di un ambito che ti offre ciò che hai bisogno , non quello che pensavi di volere. Quindi puoi ottenere un prezzo responsabile e pianificare ciò che effettivamente hai bisogno .

Ho scritto molte proposte per molte aziende che hanno una sola lista di requisiti che sono ridicolmente vaghi e tuttavia completamente "richiesti". Quando suggeriamo che alcuni dei più bizzarri vagabondaggi siano abbandonati, trattano questo come una riluttanza a scrivere una proposta "completa" da parte nostra.

Quando negozi con loro, cerca di ottenere un prezzo fisso per quello che vuoi. Nella mia esperienza, le aziende hanno la tendenza a sottovalutare il lavoro necessario e non si ha il controllo su come ottengono il lavoro svolto. A volte, se pensano che sia facile o che tu sia un cliente "più piccolo", metteranno i giovani programmatori sul compito o non ne faranno la loro massima priorità. Se fanno pagare una tariffa oraria, questo può finire per costare un sacco di soldi.

Avere una descrizione concreta di esattamente ciò che si desidera. Assicurati di darti una timeline e controllala attentamente per assicurarti che abbia senso. Di nuovo, cerca di ottenere un prezzo fisso per il risultato finale. Assicurati che esista un contratto che specifichi esattamente quali sono le tue aspettative. Una buona compagnia dovrebbe cercare di fare tutto il possibile per ottenere la tua attività, quindi assicurati di essere coerente con le tue esigenze.

Spero che questo aiuti!

I. Bozza. Prima di tutto fai una buona idea di ciò che vuoi. Le funzioni future potrebbero non essere chiare, ma dovresti avere un'idea molto buona su ogni parte di ciò che vuoi scritto ora. Discutere con i manager / designer del proprio appaltatore. Spesso hanno alcune ottime idee e una migliore idea di cosa potrebbe desiderare il cliente rispetto al cliente. Ovviamente l'ultima parola appartiene a te, ma queste persone spesso sanno "cosa funziona", "cosa è fattibile" "che cosa è la strada rispetto al budget" e "ciò che altri hanno provato e semplicemente non ha funzionato".

II. Buone specifiche Questo è l'80% del successo.

Non devi progettare tutto da solo, ma non aspettarti che queste persone ti guardino magicamente in testa e sappiano cosa vuoi. Diranno ciò che mancano e che dovrai compilare. Anche se sembra banale o poco importante per te, solo umorizzali, meglio avere troppi dettagli che non abbastanza. Quando ottieni l'ambito completo del progetto, prova a mantenerlo fisso. Ci sono poche cose più distruttive per la produttività rispetto alle specifiche che cambiano costantemente. I programmatori, a loro volta, non si occupano di questo, ma il tempo aumenterà, il prezzo aumenterà e la qualità del prodotto finale diminuirà. Quindi pianifica con largo anticipo, in modo completo e competente, per quanto riguarda ciò che vuoi, cerca di mantenere le modifiche successive al minimo e tutto sarà abbastanza felice. Se non si è sicuri delle parti del progetto, modularizzare - "questa è una funzionalità che verrà richiesta in un secondo momento", "attualmente sconosciuto / non definito" è perfettamente a posto e migliore di qualcosa di definito a metà. Ciò consente ai programmatori di lasciare i ganci per l'estensione senza intaccare il codice per qualcosa che non sanno esattamente come scrivere. "Basta farlo in qualche modo, mostrami come funziona e ti dirò se è quello che volevo" è l'approccio peggiore di sempre.

III. Deadline.

Organizza una scadenza ragionevole e mantieni il tempo di riserva 2x. Lo scherzo comune sta scrivendo il primo 90% dell'app prende il 90% del tempo assegnato. Scrivere il restante 10% richiede molto più di un secondo. Questo è vero, poiché il supporto / debug occupa almeno altrettante risorse della creazione. Aspettatevi che la scadenza scenda, scivolano sempre, non fatevi prendere dal panico, perdonate ma mantenete una certa pressione. E ricorda di includere il contratto di assistenza nell'affare.

IV. Licenza.

Prestare attenzione alla licenza. Puoi commissionare il lavoro sul tuo codice e acquistarlo tutto, codice base, copyright e tutto - che sarà più costoso ma assicurerà migliori profitti e minori costi a lungo termine. Oppure puoi ordinare l'app ma solo acquistare la licenza, la società di software mantiene il copyright e possono vendere l'app ad altri. Tuttavia, organizzare aggiornamenti e supporto nel contratto. Questo può essere saltato con un software affidabile e affidabile, non con qualcosa di appena scritto. Non acconsentire all'infinito slittamento dei prezzi a causa della riduzione delle scadenze, ma anche di non punire troppo le scadenze slittanti. È meglio se il progetto è finito in ritardo rispetto a quando imposti la distribuzione di un prodotto incompleto.

V. Supervisione.

Rimani in contatto, richiedi versioni di test, rimani aggiornato con i progressi, consulta periodicamente le versioni di test del programma per vedere se ciò che viene creato è ciò che desideri. Pochissime persone possono scrivere specifiche perfette. È molto improbabile che tu possa I programmatori scriveranno sulle specifiche, ma ciò che hai scritto potrebbe non essere esattamente quello che volevi, quindi informale meglio se stanno andando nella direzione sbagliata. Alcune cose potrebbero sembrare fattibili molto più facilmente in un altro modo rispetto a quello che intendevi. Ascolta, ripensa, accetta se ha senso. Alcune cose possono sembrare molto più difficili o impossibili, quindi sii pronto a sacrificarle o a rimandarle per le versioni future. E per quanto tu possa essere tentato di aggiungere funzionalità nei luoghi in cui ritieni che ti piacerebbe, rimandalo alla prossima versione. Bugs devono essere menzionati con calma. Si verificano e dovrebbero essere corretti, è normale. Le violazioni delle specifiche nei pezzi finiti devono essere perseguite in modo aggressivo. Questo è qualcosa che non dovrebbe accadere. (a meno che, ovviamente, la parte assegnata sia "non ancora implementata" o "work in progress").

VI. Deployment.

Non aspettarti che il 100% della produttività salti durante la notte. Sentiti fortunato se il sistema inizia a funzionare anche il primo giorno. Ci saranno errori Devono essere corretti. I dipendenti saranno lenti a riprendere il nuovo sistema. Dopo alcune settimane o un mese, tutto dovrebbe essere risolto per rendere il funzionamento più fluido con persone abbastanza abili da rendere possibile l'identificazione dei colli di bottiglia. Falli correggere nel primo aggiornamento, insieme a tutti i (numerosi) bug che scoprirai. Aspettatevi un'applicazione funzionante e perfettamente funzionante entro mezzo anno dalla distribuzione.