Esiste un nome per quando un team di vendita promette irresponsabilmente funzionalità inesistenti? [chiuso]

La pianificazione eccessivamente ottimistica è il termine usato da Steve McConnell nel suo libro Rapid Development . Usa anche il termine wishful thinking .

McConnell scrive (con prove a sostegno) che un programma eccessivamente ottimistico rende effettivamente il progetto più tardi.

Ho avuto una brutta esperienza con una pressione programmata una volta. Un cliente non era soddisfatto di una tempistica, anche se era in linea con progetti simili. Abbiamo assunto un programmatore di contratto con la speranza di ridurre la tempistica. Il cliente ha aggiunto molte altre funzionalità. (Non c'è stata la recensione di "hey, il progetto sta impiegando troppo tempo e ora vuoi più funzionalità?") Il programmatore di contratto non era buono come speravamo, e ho passato molto tempo a correggere bug e problemi di progettazione.

Non voglio più rivivere quell'esperienza quanto più posso aiutarla.

Sì, dovresti cercare modi creativi per aiutare il team di vendita e la direzione a rispettare i loro impegni. Le vendite pagano il tuo stipendio.

Sì, dovresti essere educatamente e fermamente parlare di programmi non realistici. L'orario potrebbe non cambiare, ma hai fatto quello che potevi. Lo devi alla tua gestione per dare loro la tua migliore opinione professionale, anche quando non è quello che vogliono sentire.

"Normale"

Tieni presente che i team di vendita sono lì per ... vendere il prodotto che hai scritto. Si stanno naturalmente adattando alla domanda dei clienti e alle funzionalità di vendita di cui hanno bisogno i loro (e i vostri!) Clienti. vuoi davvero far questo; significa che le entrate stanno arrivando e che il tuo prodotto è adeguato alle esigenze del mercato.

Noterò che questo può essere correlato al vapor-ware, in cui le cose sono promesse e promesse ma mai consegnate. Ma c'è una sfumatura dietro quel termine che non è applicabile alla tua domanda.

È solo un problema quando i programmi di consegna non sono definiti chiaramente o quando il team di vendita promette troppo su ciò che può essere consegnato. E mentre ciò crea stress per gli sviluppatori coinvolti nell'implementazione di queste visioni, alla fine non è il loro problema da risolvere. La gestione superiore e la gestione dello sviluppo del prodotto devono collaborare con la direzione delle vendite per definire quando è possibile pubblicizzare le funzionalità per la vendita e quali programmi possono essere utilizzati. L'impegno eccessivo offusca l'immagine dell'azienda ed è giustamente un problema da risolvere per la dirigenza.

In generale, gli sviluppatori (e le vendite ...) amano vedere un approccio Design => Sell => Develop alle vendite e al marketing. Lo sviluppo ha un'idea di cosa potrebbe essere frustato ai potenziali clienti e Sales ha un'idea di quando l'idea XYZ potrebbe effettivamente essere consegnata se il potenziale cliente è interessato.

Ci sono casi in cui vedrai Sell => Design => Build , e questo percorso ha maggiori probabilità di causare problemi al team di sviluppo. Da un lato, se il team di vendita comprende veramente il codice base *, questo può essere un percorso efficace per i nuovi contratti. D'altra parte, c'è una maggiore possibilità di sopravvalutare ciò che può effettivamente essere consegnato in un ragionevole periodo di tempo. La tua domanda richiama alcuni dei tasti per determinare quanto bene questo approccio funzionerà.

* _{Sì, conosco la risposta cinica di "che non succede mai". Ma può accadere quando uno dei fondatori di un'azienda era altamente tecnico e si è trasferito in un ruolo trainando più vendite. C'è anche un intero ramo del personale "Vendite tecniche".}

Questo è un tipo di anti-pattern organizzativo . Ho sentito alcuni termini per questa pratica:

• Sviluppo orientato alle vendite
• Programmazione orientata alla vendita
• Coding sul sedile dei pantaloni

Anche se non c'è nulla di fondamentalmente sbagliato in questo, e occasionalmente può essere molto buono per il business, se usato troppo rapidamente degenera in una serie di problemi ben noti: feature bloat , grande palla di fango , pulsanti magici , ecc.

La mia organizzazione chiamerebbe questo violazione di un porto sicuro o vendita basato su dichiarazioni lungimiranti .

Ogni comunicato stampa e presentazione di vendita viene fornito con un estratto conto sicuro, che si riassume in: "Prendi le tue decisioni di acquisto in base alle nostre funzionalità attuali, poiché non garantiamo la consegna su funzionalità che non sono ancora state rilasciate." I nostri venditori sono obbligati a non promettere mai nuove funzionalità in una determinata data, e se lo fanno, lo fanno in contraddizione con la dichiarazione di approdo sicuro.

Come lo descrivi, non c'è niente di sbagliato in questa tecnica di vendita.

Diventa simile alla caratteristica creep quando il team di vendita promette cose che non possono essere consegnate nel lasso di tempo in cui le promettono.

Quando ciò accade, il processo di sviluppo del software può spesso cadere nel dimenticatoio, le cose devono essere consegnate rapidamente e ciò può portare a

• codice errato
• cattivo design
• non abbastanza (o no!) test

Purtroppo, questo è molto comune.

Il cinico di me vuole dire "consulenza", ma non è del tutto giusto, perché ci sono molti consulenti che sono onesti.

È incredibilmente comune nella consulenza software vendere qualcosa che non hai ancora costruito, specialmente se stai facendo progetti su campi verdi su misura. Molte organizzazioni vendono servizi di consulenza sul proprio prodotto, che includono sempre personalizzazioni o funzionalità esclusive (SAP, Microsoft Dynamics, Microsoft SharePoint, ecc.).

Mi sembra che tu stia affrontando la frustrazione derivante dall'avere venditori che sono troppo disconnessi dal team tecnico. Ci sono molti modi per migliorare questa situazione, ma uno che stiamo iniziando nel mio posto di lavoro è "sessioni di apprendimento" in cui diverse persone insegnano al resto della squadra il loro lavoro. Gli sviluppatori possono conoscere le vendite e le sfide al loro interno; I venditori possono conoscere le sfide dello sviluppo del software. Un'altra tecnica è quella di far sedere il venditore presso le persone di cui vendono i servizi. Abbatte i confini "noi contro loro" e incoraggia tutti a giocare per la stessa squadra.