Mi sembra di essere ripetutamente bloccato in una situazione in cui le date di rilascio non sono basate su qualcosa di tecnico, ma perché qualcuno in Sales si è impegnato con un cliente da allora. Sulla base delle discussioni con gli amici in fase di sviluppo presso altre società, la stessa cosa sembra accadere.

"Ecco il set di funzionalità di commit ed ecco la data di rilascio di commit", ed è difficile argomentare perché a questo punto ci sono soldi da cavalcare, e questo vince su tutto.

In generale, c'è un modo per respingere questo? Se non fosse per questa versione, che dire in futuro? Il problema che ho è che l'unico modo in cui vedo un modo per farlo, e cioè facendo il meglio che posso, ma rilascia il software "così com'è", per così dire.

Non voglio rilasciare software pieno di bug poiché è il mio nome allegato, ma fare settimane di 80 ore per mesi alla volta conferma semplicemente la data di rilascio impostata in modo arbitrario.

modifica: per la cronaca, non sto facendo 80 ore settimanali ora, mi viene in mente solo ciò che sarebbe necessario per coprire le funzionalità previste entro la data di rilascio.

Smetti di fare le settimane da 80 ore. Questo è un rinforzo positivo . Poiché stanno ottenendo il prodotto in tempo con i costi previsti, continueranno a farlo, indipendentemente da ciò che ti fa.

Se non riescono a pianificare correttamente i tempi, allora è colpa della direzione. Non tuo.

Lasciali perdere alcune scadenze.

In generale, c'è un modo per respingere questo? Se non fosse per questa versione, che dire in futuro?

Certo, c'è: Lasciateli fallire male con questo approccio. Nulla insegna oltre a fallire.

Fai una stima tu stesso prima di iniziare e mostraglielo . Quindi fai del tuo meglio, scrivi un buon codice, smetti di compensare la loro stupidità con il tuo tempo libero e quando si lamentano in seguito, ricorda loro la stima del tempo che hai mostrato loro, sulla base di principi ingegneristici.

E farai meglio a iniziare a farlo con il progetto attuale .

Se continuano a incolparti per il problema, è meglio iniziare a cercare un nuovo lavoro, dal momento che nulla li convincerà che sono il problema.

Come ripensamento, penso che questa domanda in realtà meriti un collegamento alla famosa storia di EA come appare in uno dei libri di Joel: EA: The Human Story .

Ciò si verifica generalmente a causa di un incentivo perverso: i venditori vengono pagati su commissione, mentre il personale di produzione viene pagato con uno stipendio. I venditori hanno diverse leve con cui lavorare: caratteristiche, costi e data di consegna. Hanno un forte disincentivo a ridurre i costi, perché in genere ciò riduce la loro commissione, quindi tendono ad aumentare le funzionalità di UP e la data di consegna (in termini di essere precedenti). Spingeranno quelli più in alto possibile per chiudere l'affare.

Prova a vederlo dal loro punto di vista, solo per un momento. Hanno anche una famiglia da sfamare - e se la differenza tra la chiusura di una vendita a cui ho lavorato per mesi è solo tagliare alcune settimane del programma, allora è una tentazione incredibile, soprattutto se non lo faccio capisco davvero cosa significhi.

La tentazione è di dire "sempre così, e sempre così sarà". Ma un posto in cui ho lavorato aveva almeno una soluzione PROPOSTA, se non implementata ... un manager infine alzò le mani e disse: "se gli straordinari dei programmatori vengono utilizzati per chiudere una vendita, allora dovrebbero ricevere una parte di la Commissione." Non è stato implementato, ma avrebbe allineato gli incentivi di tutti più da vicino ... i programmatori sarebbero stati entusiasti di conoscere una nuova funzionalità che doveva uscire in pochissimo tempo, perché avrebbero anticipato la commissione, e il i venditori sarebbero MENO adatti a creare tali circostanze, perché avrebbero meno probabilità di lavorare a loro vantaggio.

Il team di sviluppo deve essere consultato su queste decisioni o non uscirai mai da quel ciclo. Se non gestisci il team, uno dei tuoi manager di linea deve sostenere il team di sviluppo. Se fanno parte del problema, potresti prendere in considerazione altre opzioni di assunzione.

In generale, le vendite non dovrebbero impegnarsi in nulla senza l'accettazione da parte del Product Management, che ovviamente dovrebbe consultare il team di sviluppo per le tempistiche. Non ci sono davvero buone scuse per aggirare questo in una grande o piccola azienda perché alla fine il team di vendita prenderà un po 'di calore per sotto-consegna (sia in termini di qualità che di portata).

Questo è quasi una cosa universale nelle aziende più piccole in quanto hanno una maggiore necessità di concludere un accordo. Fino a quando non sono stato coinvolto in riunioni di vendita presso la mia azienda, ero amareggiato per questo, ma posso almeno capire come e perché succede un po 'di più.

I clienti lo vogliono velocemente e molti faranno di tutto per ottenere. Questo incoraggia le vendite a rispettare gli impegni puntuali solo per ottenere qualcosa firmato. Un contratto firmato è oro perché puoi acquisire capitale o credito usando uno. A volte è meglio rispettare una scadenza piuttosto che nulla su cui lavorare affatto.

Altre volte, se si tratta di un mercato caldo e ci sono molti concorrenti, la società ha un bisogno imminente di ottenere un prodotto più veloce di tutti gli altri. Una società più grande o una con più capitale può sempre assumere più risorse, una più piccola non può.

Dove è scadente è quando le scadenze sono veramente artificiali ed è spinto dalle vendite e dalla direzione a garantire grandi bonus per se stessi.

Non prendere l'abitudine di lavorare più di 45 ore a settimana, fa male alla salute e viene prima di tutto.

Ho lavorato su entrambi i lati della casa. Ricorda che senza gli addetti alle vendite non ci sarebbero lavori o progetti a valle.

Come combattere l'eccessivo impegno di vendita : stimare, quindi prendere almeno un multiplo del 130% (pianificare sempre un contingenza minima del 30%). Fornire e documentare tale preventivo. Renditi conto che le tue stime di sforzo saranno ridotte nel processo di vendita. Va bene, basta che la direzione ritiri dal contratto di licenza / vendita / commissione qualsiasi riduzione di quelle ore. Se sei una società pubblica, questo diventa complicato con VSOE , ma fino a quando non colpisci le persone di vendita con responsabilità contrattuale in anticipo durante il loro processo di vendita, diventerà la tua responsabilità in seguito.

Ci sono molte strategie che puoi usare, ma di solito avrai bisogno dell'approvazione o del buy-in da parte della direzione.

1. Paga gli sviluppatori agli straordinari a un ritmo maggiore. Lavorare ore extra non è poi così male quando guadagni molti soldi extra. E se inizia a influire sulla gestione dei profitti dell'azienda, si eserciterà una pressione sulle vendite per fare una migliore stima del lavoro.

2. Pagare i venditori in base al profitto anziché alle vendite lorde. Ogni ora di lavoro che non includono nella loro stima influisce negativamente sulla loro commissione.

3. Limita il numero di ore che gli sviluppatori possono lavorare a 40 (o qualunque sia la settimana lavorativa standard nella tua parte del mondo).

4. Fai lavorare gli addetti alle vendite ogni ora in cui lavorano gli sviluppatori. Se vogliono che lavori ore extra per portare a termine il loro progetto, devono esserci anche loro. Trova qualcosa di utile da fare per loro, come scrivere documentazione o produrre copie calligrafiche e illuminate a mano di Design Patterns e The C ++ Standard Template Library .

5. Chiedi agli sviluppatori di stimare ogni lavoro anziché lasciare che i venditori lo facciano. Almeno in questo modo hai la possibilità di rendere il programma più ragionevole. Questa non è un'ottima soluzione, anche se ... gli sviluppatori sono spesso terribili nel valutare il lavoro richiesto. Anche se la stima è ragionevole, eventi imprevisti possono impedirti di colpire il tuo obiettivo. Inoltre, tendiamo tutti a non lavorare all'inizio di un lungo progetto con la stessa urgenza che facciamo con l'avvicinarsi della scadenza. Questi sono i fattori che motivano i brevi cicli di sviluppo sostenuti dai sostenitori di Agile.

6. Adotta un approccio "agile" e rifiuta di impegnarsi. Andando agile richiederà molto più coinvolgimento del cliente, ma può anche dare al cliente una maggiore flessibilità, perché essi non devono necessariamente impegnarsi in anticipo per la forma finale del progetto sia. All'inizio le vendite potrebbero non essere contente di ciò, ma potrebbero cambiare la loro sintonia quando si rendono conto che può offrire molte opportunità di vendere più lavoro.

Penso che la soluzione meno interessante sia qualsiasi cosa che faccia apparire male il team di vendita agli occhi di potenziali clienti. Il team di vendita è il volto dell'azienda. Farli apparire male fa male all'intera azienda e potrebbe non risolvere il problema - potrebbero sentirsi come se avessero bisogno di fare un affare ancora migliore per il cliente per ritrovare la propria fiducia.

Smettere

Ci sono già molti suggerimenti sensati nelle risposte, che si spera possano aiutare a risolvere questa relazione disfunzionale. Ma alla fine, si decide quanto si desidera lavorare.

È facile essere costretti dai colleghi a lavorare troppo. Ma stai sacrificando la tua vita personale quando lo fai.

Ecco cosa puoi fare:

• Di 'al tuo capo: "Ho dovuto lavorare molto più straordinariamente di quanto non voglia qui. Da ora in poi, non lavorerò più di X ore al mese".
• Come altri hanno suggerito, stimare quante ore ci vorranno prima. Ricorda loro che "al limite di X ore al mese, probabilmente non finirò entro la scadenza". Metti questo in una email per riferimento futuro.
• Fai riferimento a quell'email quando la scadenza scade. "Vedi? Come previsto, non siamo riusciti a rispettare questa scadenza in orario di lavoro ragionevole."
• Se continuano a spingerti a fare gli straordinari e tutti gli sforzi di comunicazione falliscono, esci.

Esperienza personale

Ho lasciato il mio ultimo lavoro perché facevo sempre gli straordinari e mi chiedevano sempre di lavorare di più. Ho detto chiaramente nella mia intervista di uscita che mi piacevano un sacco di cose sul lavoro, ma non vedevo la fine degli straordinari in vista.

Ho anche espresso chiaramente quel desiderio nella mia intervista per il mio nuovo lavoro e mi è stata data una risposta entusiasta. Sono rimasti fedeli alla loro parola: raramente mi viene chiesto di fare gli straordinari qui.

Il mio ex datore di lavoro ha un alto tasso di turnover degli sviluppatori e sta trovando più difficile reclutare in questi giorni perché hanno la reputazione di lavorare troppo. Forse il costo aggiuntivo del reclutamento e della formazione insegnerà loro una lezione. In caso contrario, non è un mio problema.

Per prima cosa ricordiamo che generalmente tutti abbiamo un lavoro per supportare le offerte che i ragazzi delle vendite fanno piuttosto che costruire un'arte di programmazione tecnicamente perfetta. Se non fanno le offerte non hai un lavoro.

Detto questo, il trucco è trovare il modo di lavorare con le vendite per rendere tutti belli. I processi in cui il team tecnico può almeno esprimere un'opinione sulle proposte prima che escano dalla porta è la chiave. Anche trovare modi creativi per gestire la compensazione aiuta molto: se le vendite devono "dare la mancia" all'ingegneria quando l'ingegneria subisce enormi straordinari facendo funzionare un programma irrealistico, sembra ridurre drasticamente la frequenza dei progetti della marcia della morte.

Questo è qualcosa che devi portare al tuo manager (ci sono manager di sviluppo, giusto?) E spiegare il problema. È un cambiamento che deve avvenire a livello organizzativo: le vendite devono ottenere acquisti dallo sviluppo prima di assumere impegni e, prima che ciò accada, devono ottenere quella direzione dai loro capi.

Non c'è niente che tu possa fare per far sì che il cambiamento avvenga, ma dovresti sicuramente portarlo al tuo manager.

Oltre a cercare di cambiare la cultura (buona fortuna), ogni volta che arrivano da te con una scadenza che non puoi rispettare, rispondi - con i numeri. Suddividi il progetto e mostra loro la tua stima del tempo. Se è un progetto di sei settimane, diglielo. Se è stato promesso al cliente in quattro settimane, non puoi farlo e devi divulgare tali informazioni il più rapidamente possibile. Si spera che i vostri venditori siano in grado di tornare dal cliente e impostare aspettative migliori o lavorare con voi per elaborare un set di funzionalità accettabile più piccolo da consegnare entro la linea temporale promessa, con le funzionalità aggiuntive da aggiungere in seguito.

Modifica per aggiungere: non lasciare che esprimano il tuo preventivo. Sii fiducioso che sia corretto e atteniti ad esso. Essi potranno provare a contrattare con voi, ma non li lascia.

Un suggerimento che non è ancora emerso : retrospettive .

Non dire "no, non sto facendo gli straordinari", ciò incoraggia sempre gli altri sviluppatori a entrare e farti sembrare cattivo.

Ma dite chiaramente al vostro management che ogni volta che dovete fare più di 40 ore alla settimana per svolgere un lavoro, tutti i soggetti coinvolti nel progetto dovrebbero sedersi in una stanza dopo la consegna del prodotto , capire cosa è andato storto e cosa possiamo fare per impedire che accada di nuovo. O, meglio ancora, ogni progetto dovrebbe avere una retrospettiva per discutere di cosa è andato bene e cosa è andato storto.

Se hai ragione e i commessi sono troppo impegnati, questo diventerà molto chiaro molto rapidamente. Ma non anticipare la conclusione e non essere contraddittorio prima del fatto. Parlane in termini di cose che la tua squadra può fare per consegnare in tempo senza lavoro straordinario.

Non sai mai, potresti persino trovare miglioramenti ai tuoi processi che possono rendere più fattibile la stima del venditore.

Non c'è assolutamente modo di combatterlo del tutto. La natura stessa delle vendite è eccessiva. Come rappresentante di vendita sei lì per far scomparire magicamente i potenziali problemi del cliente. I buoni rappresentanti delle vendite esagereranno solo leggermente, quelli cattivi causeranno un grande imbarazzo.

Qualunque cosa tu faccia causerà solo un aggravamento o una tensione tra il personale del prodotto e il personale di vendita (almeno). Puoi sforzarti molto per evitare gaffs davvero cattivi da parte dei tuoi rappresentanti di vendita, ma alla fine della giornata gli sviluppatori e i rappresentanti di vendita vengono pagati dallo stesso conto bancario. La tua azienda avrà successo o fallirà come unità, quindi iniziare una guerra civile con le vendite non aiuterà.

Se hai uno o più rappresentanti di vendita che si imbarazzano abitualmente, la gestione delle vendite si occuperà del problema. Come sviluppatore, non avrai il coraggio di fare nulla al riguardo, quindi dovresti concentrarti sulla consegna del miglior prodotto possibile con il tempo e le risorse che ti danno.

È difficile rispondere senza conoscere la struttura della tua azienda.

Alcuni strumenti generali per aiutare sono:

• Hanno concordato (ma i responsabili, non le vendite) controlli di qualità
• Avere una tabella di marcia del prodotto (interna ed esterna)

Avendo concordato i controlli di qualità , hai un motivo trainato dal business per non essere in grado di rilasciare software difettoso. Potrebbe essere necessario convincere i tuoi capi perché questo è importante (speriamo di no), ma c'è molta letteratura là fuori per aiutare in questo.

Avendo una tabella di marcia del prodotto , le vendite sanno cosa possono e non possono promettere ai clienti. Se vogliono cambiare la roadmap, devono alzarla con il Product Manager / Project Manager / Development Manager o chiunque altro lo cambi.

Se promettono qualcosa a un cliente che non è già stato concordato, sfortuna. Speriamo che la vostra tabella di marcia si basi sui dati di mercato sulle esigenze dei clienti. "Cosa proponete esattamente che cadiamo da queste altre 8 caratteristiche ad alta priorità di cui abbiamo prove che le esigenze della nostra base di clienti?"

Infine, come già previsto, non funzionano settimane 80 ore. Non stai nemmeno aiutando l'azienda facendo questo perché li stai solo aiutando a scavare un buco più profondo.

No

Ho provato a fare una risposta di due lettere e lo stack non me lo ha permesso ... ma la risposta è

No

Il che, non è del tutto vero se possiedi / gestisci l'azienda, ovviamente. Se ti trovi in quella posizione, puoi trascinare il team di vendita dalle orecchie e "parlare". Se, tuttavia, e come sospetto, tu sia solo una persona "modesta", l'unica soluzione è lamentarti "UP" della catena di comando. Detto questo, la mia esperienza è stata che nelle aziende in cui ciò accade, il management è consapevole della situazione e non gliene importa.

Mostra loro questa immagine (o questa ) e dì loro che stai lavorando con un triangolo impossibile.

  ·-----------------------·
 / \                       \
·   \   ·-------------------·
 \   \   \                 /
  \   \   \-----------·   /
   \   \   \     /   /   /
    \   \   \   /   /   /
     \   \   \ /   /   /
      \   \   /   /   /
       \   \ /   /   /
        \   ·   /   /
         \     /   /
          \   /   /
           \ /   /
            ·---·

In qualsiasi progetto, se risolvi due angoli di questi tre:

• Tempo
• Scopo
• Qualità

... quindi il terzo è l'unico flessibile. Ciò che rende impossibile sono le aspettative. Se correggono sempre il tempo troppo breve e l'ambito di applicazione troppo grande, la qualità ne soffrirà sempre. In un progetto agile, tutti e tre gli angoli sono più o meno flessibili.

(Dichiarazione di non responsabilità: escludo il fattore costo dal tradizionale triangolo del progetto e trasformo la qualità in un angolo. Il tempo è il costo nei progetti software.)

Spero che tu riesca ad arrivare a una gestione del progetto più agile.

Alcune ottime risposte qui già. Aggiungerò semplicemente che non dovresti essere spinto a rispettare le sue scadenze a tuo danno. Inoltre, avrei sicuramente una parola con il venditore e gli ricorderei che se lui promette troppo e la società non può mantenere le sue promesse, allora (e la società) non ci si fiderà in futuro, perdendogli commissioni future (e forse il suo lavoro), quindi è nel suo interesse essere realistico (cioè consultare il personale di programmazione) in modo che acquisisca fiducia nell'azienda. A breve termine potrebbe guadagnare non realisticamente, ma a lungo termine perderà danneggiando la sua reputazione con clienti, datore di lavoro e futuri datori di lavoro con riferimenti errati.

Mentre i venditori comprendono il denaro più di ogni altra cosa, parla con lui in questi termini.

Con lo sviluppo Agile vediamo consulenti che vendono punti per ~ 1000-1500 ciascuno. Se è possibile modificare il processo di vendita nel punto in cui devono vendere in base alla scala dei punti, il team di vendita sarà costretto a lavorare con il team di sviluppo per elaborare stime ragionevoli.

Tutto si riduce a un punto critico; Se non ritieni di poter sostenere il ritmo necessario per rispettare il programma promesso dalle vendite, non impegnarti nel lavoro. Se le vendite superano, non è un tuo problema, finché non accetti il ​​lavoro. POI è il tuo problema. Ricorda al tuo capo che tutti i venditori devono fare è dire di sì e ottengono l'assegno; sei quello che effettivamente mantiene le promesse, quindi se dici che non funzionerà, il tuo capo dovrebbe ascoltare. Se hai la sfortuna di avere un manager che ascolta la sua forza vendita più della sua forza di sviluppo riguardo a ciò che è e non è possibile, allora hai il PHB Dilbert-esque e dovresti aggiornare il tuo curriculum.

Questa è una ragione per cui mi piace Agile; il team di sviluppo è coinvolto nel processo dalle discussioni sulla progettazione iniziale. È possibile calibrare un "punto" da entrambe le estremità; il team di sviluppo decide (esplicitamente o empiricamente) approssimativamente la quantità di ore-uomo di sviluppo inerente a un punto, che il management può quindi utilizzare per calcolare i punti alla settimana, i punti al mese, ecc. che portano a un valore in dollari. A quel punto, il tuo team di vendita dispone ora di cifre relative al costo e al tempo richiesti per gli attuali livelli di personale per ottenere l'attuale portata. Se superano il profitto una volta che hanno quei numeri, sono fuori di testa.

Specifica il lavoro dopo che te lo danno e fai sapere loro quanto tempo ci vorrà. Quindi, quando si alzano a parlare, diglielo.

"Mi dispiace che tu abbia preso questo impegno, ma date le risorse a mia disposizione ci vorranno X ore per il completamento"

Fallo ogni volta ... ha funzionato per me.

Fondamentalmente dire loro che possono averlo veloce, economico e buono, scegline due.

In realtà c'è un modo - un modo reale, non una banalità vuota - ma potrebbe non piacerti.

Chiedi a qualcuno del team di sviluppo di partecipare al processo di vendita .

Ora ovviamente hai bisogno di qualcuno con buone capacità di persone, qualcuno che i venditori non saranno mortificati nel portare avanti la corsa. E questa persona deve avere un'ampia comprensione dei tipi di lavoro che svolgi. Essi non hanno bisogno di essere un ninja codice, hanno solo bisogno di una comprensione mite di codifica in generale, e il processo di sviluppo, in particolare, ed essere ragionevolmente buono a stimare lavoro.

Questo è davvero un lavoro per un analista aziendale o project manager. C'è un motivo per cui questi lavori pagano così bene in molte aziende; combinano due set di abilità molto importanti e distinti. Se non hai un BA o un PM reale ma hai uno sviluppatore o un architetto senior con abilità sociali, possono farlo anche loro.

È inoltre necessario fornire linee guida chiare per i venditori. In effetti, tu (come nel tuo team di sviluppo) stai inviando qualcuno a negoziare per tuo conto. Se non dai loro alcun parametro, negozeranno semplicemente ciò che sembra buono per loro. Ecco perché dai sempre loro dei parametri.

Una volta capito la portata del progetto, capire quanto tempo che si desidera avere per la costruzione, il collaudo, modifiche di ambito, e così via, oltre a una certa quantità di tampone, quindi dare loro quel numero insieme a un "minimo autorizzato" - la più basso si può forse andare prima di mettere il progetto in grave pericolo. Aspettati che anche loro superino quel numero di un certo importo, quindi rendi il tuo minimo un po 'più alto di quello che deve essere.

Siate certi che la loro gestione sta facendo la stessa cosa. Il responsabile delle vendite non desidera che i dipendenti delle vendite vendano affari non redditizi. Stanno camminando in ogni negoziazione con un intervallo di numeri corrispondenti alla redditività target e alla redditività minima.

Potresti non essere i loro manager, ma se documenti tutto questo per iscritto prima ancora che inizino a negoziare, allora sei su un terreno molto più solido con i vertici quando le persone iniziano a fare domande sul perché il progetto è in ritardo. Ma non si tratta solo di CYA; il team di vendita onestamente non ha idea di quanto tempo ci vorranno determinate cose e tu stai facendo loro un favore fornendo loro informazioni complete.

Un'altra cosa: non aspettarti che il team di vendita coinvolga il tuo team solo per il gusto di farlo. È necessario anche il buy-in da parte del responsabile delle vendite e dei dirigenti. In realtà non dovrebbe essere troppo difficile da ottenere, se ci si avvicina da una prospettiva di rischio. Non vuoi vendere fallimenti, vero? Pensa al costo per la reputazione dell'azienda. Pensa al costo di una causa . Qualcuno tecnico deve far parte di qualsiasi trattativa prima di poter firmare qualsiasi accordo.

E se davvero, onestamente, non riesci a vendere la gestione dell'idea, allora potrei suggerire di trovare un nuovo datore di lavoro? Perché il tuo potrebbe non essere in giro molto più a lungo comunque.

Disaccordi come questo sono normalmente causati da una mancanza di comunicazione. O non capiscono la pressione che ti stanno esercitando o non capisci cosa ti stanno davvero chiedendo. In entrambi i casi, per risolvere il problema, è necessario comprendere la situazione dall'altro punto di vista.

Hai mai provato a vendere software? Potrebbe non sembrare la migliore risposta a molti sviluppatori, ma fino a quando non avrai provato, sarà difficile vedere l'attività dal punto di vista delle vendite. Se sei un grande sviluppatore, scrivi qualcosa che vuoi davvero scrivere e vendilo. Potresti vedere che hanno alcuni punti validi o potresti non averlo!