Come gestire questa situazione sfortunatamente non ipotetica con gli utenti finali?

Le dispute su fatti facilmente osservabili sono in realtà abbastanza facili da risolvere: osserva i fatti. Se dico "c'è un albero con legno viola fuori casa mia", chiunque può venire a casa mia può verificare la verità o la falsità della mia dichiarazione per se stessi.

Se si lamentano che FuncA era presente nel prodotto e utilizzato per lavorare in una versione precedente e ora non funziona, e non pensi che sia mai stato nel prodotto, chiedi loro di dimostrarlo. (Oppure, in parole più gentili, dì qualcosa come "abbiamo problemi a riprodurre il problema. Potresti aiutarci qui?")

Fornisci loro una copia della versione precedente se non ne hanno ancora uno e caricali in un LiveMeeting e chiedi loro come usavano usare FuncA. Se non riescono a farlo, allora (si spera) si rendono conto che non era lì dopotutto e se ne sono discostati, o almeno provare una tattica diversa per farlo implementare. (E assicurati di far entrare qualcuno dal management o dal PM sul LiveMeeting.)

Questo non è un problema che può essere affrontato sui fatti - se ci provi, perderai credibilità.

In primo luogo, accetta che il software sia "rotto", in quanto non fa ciò che gli utenti vogliono che faccia. Ora, accetta che gli utenti abbiano il diritto di fare in modo che il software faccia ciò che vogliono: ciò che è il software è quindi. Quindi quello che abbiamo è un software difettoso e un ingegnere che si rifiuta di ripararlo .....

Di conseguenza, se il sistema viene eseguito per impostare le priorità, questi utenti non possono correggere il software passando attraverso i normali canali, quindi utilizzano canali laterali e metà verità crescenti nella catena alimentare per cercare di manovrare fuori il sistema, nel frattempo, rendendo il tuo KPI aspetto male (la tua preoccupazione principale dovrebbe essere i clienti, non i tuoi KPI) - I tuoi KPI sono considerati "danni collaterali" se ti piacciono, o un effetto collaterale se non lo fanno. Tuttavia, hanno un certo controllo su quanto accade - meglio che ti piacciono.

Quindi quello che sta succedendo è che il sistema è rotto e tutti stanno cercando di manipolare le cose per ottenere quello che vogliono. Vogliono una funzione e tu vuoi mantenere i tuoi KPI puliti.

A meno che tu non possa aggiustare il sistema o imparare a giocare alla politica dell'ufficio molto velocemente, il gioco finisce: perdi.

Nota: Nessuna di queste discussioni comprende Dead lines, bug vs feature discussion, chi paga ecc. Questi sono Fatti - e i fatti non contano (beh, si comportano in qualche modo, ma possono essere manipolati in così tanti modi. ...) in politica d'ufficio.

Organizzazione, percepisco un problema.

Esiste una gerarchia che include il responsabile IT e il tuo capo. Se la tua organizzazione è tradizionale (non sembra che sia Agile), sei una risorsa e sono gestori di risorse. Hai un lavoro a tempo pieno chiamato sviluppo del software. Se gli utenti finali richiedono direttamente funzionalità, stabiliscono le priorità e cercano di gestire il tempo, i manager sono ridondanti. Potrebbero essere responsabili nei confronti degli utenti finali, ma se stanno facendo il loro lavoro, sono responsabili nei loro confronti e devono proteggerti dall'uscire dalla modalità sviluppatore focalizzato in < modalità> sviluppatore difensivo .

Alcuni punti per impostare il contesto della mia risposta:

• Gli sviluppatori di software non sono viaggiatori del tempo, quindi i risultati devono essere giudicati per quello che sono, non per quello che avrebbero potuto essere.
• Se una funzione si trovava in una specifica dei requisiti, una pianificazione ed era stata assegnata la priorità al lavoro completato, potrebbe esserci un reclamo legittimo. Altrimenti, qual è la giustificazione per ritenerti responsabile?
• La tua punizione, se meritata, deve provenire dalla tua catena di comando. Proprio come il marketing e le vendite non vorrebbero che lo sviluppo del prodotto sgridasse i clienti, la maggior parte delle organizzazioni ha i responsabili di prodotto per ricevere collera (e lode) dei clienti e trasmetterli attraverso i canali.
• I product manager possono creare relazioni estremamente difficili se si crogiolano nel calore di parti di progetti di successo, ma si limitano a schioccare la frusta solo quando si rivolgono agli sviluppatori.
• Se hai consegnato un prodotto funzionale con un anno di lavoro, e ci vuole un mese (o due) per aggiungere la funzionalità desiderata, da quello che ho visto nel nostro settore, la tua stima era superiore alla media.
• Risolvere il problema in modo equo e produttivo richiede che le persone mettano le dita della colpa nelle loro tasche e facciano un piano di avanzamento.

Sarai in grado di fare un lavoro di qualità migliore con una motivazione migliore se sarai apprezzato invece di essere la capra in un processo che dovrebbe possedere il responsabile IT. È il modo giusto e il modo produttivo. Spero che sarai gestito in quel modo e, in futuro, spero che gestirai gli altri in questo modo.

In caso di fallimento della realtà come questo, la cosa migliore è andare avanti. Invece di discutere del passato, parla di come farlo funzionare e di quanto sarà facile o difficile. Non importa se il problema è risolto o implementato per la prima volta. Se la gestione vuole A fatto prima che B lo faccia così.

Sei l'unico dev per aver lavorato a questo progetto? Sembra che tu abbia risposto a qualcuno mentre realizzi il progetto. Dov'è quella persona in tutto questo? Dov'è la documentazione per il progetto che dice cosa è stato consegnato?

Dovrebbe esserci una scia di documenti. Un documento di formazione che mostra come utilizzare l'applicazione. Una specifica funzionale che descrive ciò che è stato sviluppato. Se una funzione non è stata inclusa, dovrebbe esserci anche una documentazione. Qualcuno dovrebbe aver dovuto firmare dicendo che lo accettano.

Non dovrebbe essere la tua parola contro la loro, dovrebbe essere tutto nella documentazione.

Se non hai questa documentazione ... allora temo che dovrai morderlo. Consideralo una lezione di vita. Alla fine della giornata, i tuoi utenti sono i tuoi clienti, e come dice il proverbio: il cliente ha sempre ragione. Disegna come aggiungere questa funzione e quanto tempo ci vorrà. Avere un incontro e dire qualcosa sulla falsariga di "I nostri record mostrano che questa funzione non è mai stata implementata, ma possiamo ottenerla in x settimane. Dovremmo andare a testa?

E per l'amore di tutto ciò che è santo ... prendi la documentazione che ti serve per dimostrare che è stata approvata.