Il personale di vendita deve interferire nell'analisi e nella progettazione delle applicazioni?

Ciò che vedi come interferenza potrebbe semplicemente essere il tentativo di mettere a nuovo i requisiti nuovi e / o modificati. Il tuo esempio del problema del colore è un ottimo esempio di questo.

Tuttavia, i tuoi altri esempi potrebbero essere visti come interferenza, specialmente nel modo in cui li hai formulati.

Quello che devi fare è organizzare riunioni periodiche per discutere la direzione e il design del prodotto, ma devi farli indicare i loro requisiti come requisiti per gli utenti finali ("l'utente deve essere in grado di selezionare tutti i loro widget") o requisiti di vendita ("dobbiamo essere in grado di mostrare questi dati come grafico a torta") anziché come dettagli di implementazione. In generale non dovrebbe importare come si implementa qualcosa finché serve al suo scopo.

Ci saranno momenti in cui il requisito corrisponde a uno specifico dettaglio di implementazione - ad es. mostrando una gerarchia come un albero.

Assolutamente.

L'intero punto di mischia è ottenere il feedback dei proprietari del prodotto alla fine di ogni sprint per assicurarti di costruire le cose giuste.

Il direttore delle vendite dovrebbe non interromperti nel mezzo di uno sprint. Ma quando fai la presentazione alla fine dovrebbe essere lì e dovresti essere scrivere difetti per ognuno dei suoi reclami (si comporta come la voce dell'utente).

Poi, quando hai le tue riunioni di pianificazione dello sprint, questi difetti dovrebbero avere la priorità con il resto del backlog del prodotto e portati nello sprint backlog come ritenuto opportuno. Nota che il responsabile delle vendite dovrebbe anche far parte della priorità del backlog del prodotto (a discrezione dei proprietari del prodotto). MA NON parte della pianificazione sprint.

Gli ingegneri sono notoriamente cattivi nell'implementare le interfacce per gli utenti (si pensa in modo diverso al proprio utente). Il team di vendita deve vendere il prodotto e presumibilmente sa cosa vende. Il suo consiglio sul layout dell'interfaccia utente (come appare non come è implementato) dovrebbe probabilmente essere considerato migliore del tuo, a meno che tu non abbia un esperto di UI dedicato nel team o stai copiando qualche altra interfaccia comune che è ben nota e utilizzata (in questo caso meglio essere in grado di mostrarlo in uso).

Nota: questo è anche un modo utile per interrompere ripetutamente l'aggiornamento della stessa cosa. Crea un oggetto backlog per questo. assicurati che il proprietario del prodotto lo abbia visto se non sono d'accordo o pensa che il responsabile delle vendite sia errato e che dovrebbe essere annotato nell'elemento del backlog e l'oggetto chiuso. Se il direttore delle vendite ora lo riporta di nuovo, puoi indicarlo all'elemento del backlog dicendo che questo argomento è già stato discusso e deciso.

Idealmente i tuoi requisiti dovrebbero provenire da il cliente, ma il personale di vendita è anche una preziosa fonte di feedback e il fatto che il personale di vendita sta canalizzando le loro richieste attraverso il responsabile vendite (e non solo sommergendoti con richieste individuali) suggerisce che stanno cercando di essere utili per il processo e non semplicemente interferendo.

Il personale di vendita funge da collegamento tra il cliente e il team di sviluppo? Se è così, allora il personale di vendita sta facendo il suo lavoro. Il personale di vendita è anche un consumatore del software? Quindi dovrebbero essere in grado di fornire un feedback sul design. Se stai facendo le cose nel modo giusto, dovresti essere mangiare il tuo cibo per cani comunque.

Detto questo, le decisioni sul design non dovrebbero essere prese dal personale di vendita. Il personale di vendita è solo una delle parti interessate; dovrebbero essere in grado di influenzare, ma non dettare, il processo di progettazione.

Dovresti ascoltare i tuoi venditori; sono quelli che devono ascoltare i clienti per dire loro perché il tuo software è buono o cattivo, e come dovrebbe essere cambiato, perché stanno parlando con i clienti tutto il tempo, quindi sono teoricamente nella posizione migliore per fornire suggerimenti costruttivi .

Incoraggia i tuoi venditori a fornire feedback validi e attuabili; cambiare il colore di un'etichetta in fuschia potrebbe non essere il miglior uso del tempo di chiunque, ma rivalutare l'intera combinazione di colori basata sul feedback dei clienti che lo schema generale è difficile da leggere potrebbe essere.

In Scrum, solo il proprietario del prodotto può decidere cosa verrà costruito e in quale ordine. Pertanto, dovresti semplicemente indirizzare le richieste di modifica all'ordine di acquisto in modo da poterle prioritarizzare nel backlog come al solito.

Detto questo, non vi è nulla di sbagliato nell'input da parte del reparto vendite o da chiunque altro. Probabilmente incontrano molto gli utenti e hanno informazioni preziose di cui potresti beneficiare. Alla fine, spetta al tuo PO gestire (e manipolare) le richieste di funzionalità, da parte dei clienti, del team o delle vendite.

Mi sembra che le vendite non siano adeguatamente rappresentate / integrate nel processo di sviluppo. Sono uno stakeholder? Se non lo sono, è probabile che i loro input / preoccupazioni vengano incanalati attraverso uno stakeholder. Tuttavia, è possibile che debbano essere una parte interessata a pieno titolo.

In definitiva, come sviluppatori, la nostra responsabilità è la progettazione tecnica di un prodotto (e la sua implementazione). Il resto del design non è la nostra area di responsabilità. Mancando un disegno (non necessariamente solo grafico) riempiremo il vuoto, perché dobbiamo. Tuttavia, ciò non significa che sia il miglior design per il prodotto.

Se le modifiche a questo disegno sono un problema, allora deve essere esaminato e affrontato. Forse lo sviluppo deve indicare i vuoti che devono essere riempiti prima che inizi il lavoro. Forse lo sviluppo deve fornire una certa variabilità. Forse i problemi devono essere affrontati prima. (Forse i problemi non vengono affrontati correttamente.) Forse le vendite devono comprendere l'impatto delle loro richieste di modifica.

Una preoccupazione che ho è che hai formulato questa domanda in modo contraddittorio. Sono le vendite che porteranno i soldi per pagare questo sforzo di sviluppo. La mentalità può essere molto diversa, ma dobbiamo trovare un modo per cooperare o non ci sarà nulla da vendere.

C'è una differenza tra intromettersi / interferire e dare suggerimenti. C'è anche una differenza tra preziosi suggerimenti e inutili.

Se ti stai interrompendo attivamente mentre lavori al codice, ciò equivale a interferire o interferire. In tal caso, hai tutto il diritto di far uscire il venditore dalla tua faccia. Inoltre, se le tue decisioni vengono indebolite da continue assunzioni alle riunioni, se l'addetto alle vendite si sforza di indebolire la tua autorità o di mettere in discussione la tua competenza, questo è certamente inaccettabile.

Tuttavia, se stai semplicemente ascoltando molte opinioni quando presenti qualcosa, questo non è d'intromissione. È solo un consiglio sgradito, come quello che sentiresti da un amico seduto sui mobili del tuo ponte mentre beve la tua birra mentre ti guardo barcollare su una scala mentre dipingi la tua casa.

È abbastanza probabile che il venditore sia ben intenzionato e vuole solo ciò che pensa sia il migliore per il cliente, anche se i suggerimenti sembrano sciocchi o capricciosi.

Facendo suggerimenti, il tuo venditore potrebbe suggerire debolezze nel tuo modello di progettazione o interazione. Oppure possono semplicemente avere la loro ascia personale da macinare.

Se ci sono solide giustificazioni per i cambiamenti, vale la pena provare a trovare un modo per rispondere al feedback, anche se la tua implementazione effettiva non finisce letteralmente incorporando le specifiche del suggerimento; è possibile che imparerai qualcosa se ascolti. Tieni a mente che le parole usate in quei suggerimenti potrebbero non riferirsi al problema reale; sono solo un proxy di un problema di fondo che non è stato ancora adeguatamente compreso.

Ho partecipato a riunioni in cui un dirigente desiderava manipolare il numero di pixel a sinistra rispetto al controllo invece di discutere su quale logica di business doveva esserci, e abbiamo certamente trovato che non era un buon uso del suo tempo o del nostro . Ma ho anche ascoltato le persone che si lamentavano dell'aspetto di qualcosa o di quale tipo di controllo è stato usato ed è stato davvero un reclamo indiretto su come ha funzionato qualcosa, non come sembrava. Tieni presente che gli utenti di solito non sanno cosa vogliono fino a quando non lo hanno ricevuto; se pensi che il tuo venditore sia un proxy per un utente, c'è una buona probabilità che soffra dello stesso problema.

Quindi non sentirti obbligato ad accettare ogni suggerimento, ma non essere così veloce da respingere ogni parola che esce dalla bocca del tuo venditore.