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

22

Lavoro in un'azienda di medie dimensioni ma con una forza IT molto piccola.

L'anno scorso (2011), ho scritto un'applicazione molto popolare tra un grande gruppo di utenti finali. Abbiamo raggiunto una scadenza alla fine dello scorso anno e alcune funzionalità (chiamerò funcA da ora in poi) non sono state aggiunte all'applicazione desiderata alla fine. Quindi, questa applicazione è in esecuzione dal vivo / produzione dalla fine del 2011, potrei aggiungere senza problemi.

Ieri un intero gruppo di utenti finali ha iniziato a lamentarsi del fatto che funcA che non era mai nell'applicazione non funziona più. La nostra priorità in questa azienda è che se un'applicazione viene rotta, deve essere risolta prima dei progetti prioritari.

Ho confrontato codice e query e non vi è alcuna differenza dal 2011, che è proofA. Sono stato quindi in grado di convincere uno degli utenti finali ad ammettere che non ha mai funzionato proofB, ma da allora quell'utente finale è tornato indietro e ha detto che funzionava in precedenza ... Credo che l'orda degli utenti finali si sia assimilata sua. Ho anche rivisto le mie note per questo progetto che ha requisiti e aggiornamenti quotidiani riguardanti il progetto che afferma in particolare, "funcA non raggiunto a causa di vincoli temporali", proofC.

Ho parlato con molti di loro e posso vedere dove potrebbero essere confusi in quanto sono molto lontani da un background di programmazione, ma so anche che sono abbastanza intelligenti da agire in un gruppo al fine di bypassare gli ordini di priorità del progetto al fine di ottenere funzionalità che desiderano semplificare il loro lavoro.

La parte peggiore è che ora il gruppo pensa che si stia avvicinando e il mio capo e il capo dell'IT stanno effettivamente iniziando a crederci, anche se non ci sono modifiche al codice o alla query. Per quanto riguarda la revisione dello stato della logica, è molto semplice e secco fino al punto in cui 1 = 1, funcA non funzionerà.

Quindi, questa è la fine della descrizione del mio scenario, ma sto cercando di non essere fortemente influenzato dalle mie metriche delle prestazioni a causa di ciò che mi avrebbe sostanzialmente spostato per risolvere un problema di produzione che non esiste che probabilmente subentrerà 1 mese.

project-management requirements maintenance

— Utente Smith
fonte

1

Non siamo un forum nel senso tradizionale della parola, siamo un sito di domande e risposte che cerca domande rispondenti. Rants, polling e discussioni non sono generalmente adatti al nostro formato.

— maple_shaft

12

@maple_shaft: non sono d'accordo. Questa è una domanda seria alla ricerca di un modo per affrontare un problema reale che si verifica quando si tratta di, diciamo, utenti finali meno che indizi. L'abbiamo visto tutti e ne siamo rimasti frustrati, vero? Quindi le idee su come gestire tali scenari sono molto adatte al formato di questo sito.

— Mason Wheeler,

1

Non è possibile che ci sia una risposta a questa domanda? Chi guarderà gli osservatori?

— Utente Smith

2

A beneficio di altri che leggono questo, questo caso rappresenta un'altra lezione per quelli di noi che credono che la documentazione sia secondaria e che i requisiti di canto non siano importanti.

— NoChance,

1

"niente è cambiato" ultime parole famose.

— JeffO,

18

Le controversie su fatti facilmente osservabili sono in realtà abbastanza facili da risolvere: basta osservare i fatti. Se dico "c'è un albero con legno viola fuori dalla mia casa", chiunque sia in grado di venire a casa mia può verificare la verità o la menzogna della mia affermazione.

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

Dai loro una copia della versione precedente se non ne hanno ancora una, e inseriscile in LiveMeeting, e mostragli come usavano FuncA. Se non riescono a farlo, allora (si spera) si rendono conto che dopotutto non era lì e se ne vanno dal caso, o almeno provano una tattica diversa per implementarlo. (E assicurati di ottenere qualcuno dal management o dal PM su LiveMeeting.)

— Mason Wheeler
fonte

Hanno mostrato uno screenshot di prova che posso spiegare ma è solo parziale, quindi i dettagli dello scenario sono quelli che dicono di non essere veramente definiti tramite lo screenshot. Fondamentalmente, ciò che si riduce è che MGMT non è molto consapevole della logica e a questo punto è la parola di un intero reparto contro un programmatore umile. (Anche la versione precedente è la stessa dell'implementazione iniziale avvenuta nel 2011)

— Utente Smith

3

@UserSmith: ecco perché ho detto di usare un LiveMeeting. È più difficile confondere ciò che sta accadendo quando devi effettivamente eseguirlo con le persone che guardano.

— Mason Wheeler,

1

Questa risposta fornisce una definizione di prova molto migliore rispetto a "l'utente finale lo dice" o "Ho letto il codice". Fermati e ricorda le ultime 10 volte che come programmatore eri completamente sbalordito potresti essere così sbagliato nonostante fissassi 1 = 1 nel codice (quando avrebbe dovuto essere 1 == 1, ad esempio). Se pensi alla prova in termini di "lettura del codice" come un essere soggetto a errori, francamente le tue metriche delle prestazioni dovrebbero subire un colpo. @MasonWheeler ti ha proposto un'epistemologia più accurata e accattivante, ti spetterebbe a seguirla.

— djechlin,

Nelle trattative c'è un detto "Se devi difenderti, hai già perso". I fatti di prova sono l'ultima forma di difesa - di norma, meglio non farlo a meno che non venga chiesto, anche in questo caso, mantenere se breve - meno è di più.

— mattnz,

1

Contrassegnato come risposta probabilmente la risposta più concreta. Anche se avevo già tenuto riunioni dal vivo prima di pubblicare questa domanda. In più uno ne aveva un altro paio che erano parzialmente buone risposte. Onestamente a questo punto non mi importa delle mie metriche, è più il fatto che la struttura fondamentale della nostra organizzazione IT è in uno stato di caos che ciò sta accadendo e ciò mi preoccupa.

— Utente Smith

13

Questo non è un problema che può essere affrontato in base ai fatti: se ci provi, perderai credibilità.

Innanzitutto, accetta che il software sia "rotto", in quanto non fa ciò che gli utenti vogliono che faccia. Ora, accetta che gli utenti hanno il diritto di fare in modo che il software faccia quello che vogliono che faccia - questo è quindi il software. Quindi quello che abbiamo è un software difettoso e un ingegnere che rifiuta di ripararlo .....

Di conseguenza, se il sistema che gestisci per stabilire le priorità, questi utenti non possono riparare il loro software passando attraverso i canali normali, quindi utilizzano canali laterali e aumentano le mezze verità più in alto nella catena alimentare per cercare di manovrare il sistema, in nel frattempo, facendo sembrare cattivo il tuo KPI (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 benefico se non lo fanno. Tuttavia, hanno un certo controllo su quanto succede - meglio che gli piaci.

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

A meno che tu non riesca a sistemare il sistema o imparare a giocare in ufficio in modo molto rapido, game over: perdi.

Nota: nessuna di queste discussioni coinvolge Dead line, discussioni su bug vs feature, chi sta pagando ecc. Questi sono i fatti - e i fatti non contano (beh, in qualche modo lo fanno, ma possono essere manipolati in così tanti modi .... ) in politica d'ufficio.

— mattnz
fonte

1

Come si può perdere crediblity se si può PROVE esso?

— Thomas Eding,

3

@ThomasEding La credibilità nel mondo degli affari dipende più da come gli altri ti percepiscono che dai fatti. Se diventi un bersaglio, nessuna quantità di fatti ti proteggerà. Quanti sviluppatori di rockstar hai incontrato truffe complete? Ho incontrato più di quanto avrei mai voluto ammettere.

— maple_shaft

2

Concordo con buona parte di questo, è sicuramente una forma di politica dell'ufficio. Quando incontrassi una situazione, pensavo che il primo modo di agire sarebbe stato quello di occuparmi dei fatti, quindi mi perdevi lì, ma sarei d'accordo con i clienti che arrivano prima in secondo luogo fino a quando non sei licenziato. +1 per un diverso approccio alla situazione. +1

— Utente Smith

2

Mai lamentarsi, mai spiegare. Discutere ti fa sembrare debole. L'ascolto di richieste educate è buono. Dire che discuterai della loro richiesta con il tuo capo per la priorità è buono. Se si discute, quindi fare ciò di cui hanno urlato, rafforza il loro comportamento spiacevole. Se aumentano, il potere di posizione del tuo capo rafforza la cortesia. Il tuo capo può spiegare diplomaticamente la sua scelta per il tuo tempo. Dimostra anche che non sono il tuo capo. Quando affronti il problema con calma con il tuo capo, potresti sentire parole come "non ti preoccupare, ho le spalle". Rimani concentrato, crea il prodotto, gli arresti si fermeranno.

— Sviluppatore:

@thomas Chiedi a qualsiasi innocente accusato se un crimine particolarmente immorale ....

— mattnz,

9

A livello organizzativo, percepisco un problema.

Esiste una gerarchia che comprende il responsabile IT e il tuo capo. Se la tua organizzazione è tradizionale (non sembra agile), sei una risorsa e loro sono gestori delle risorse. Hai un lavoro a tempo pieno chiamato sviluppo software. Se gli utenti finali richiedono direttamente funzionalità, impostano le priorità e cercano di gestire il proprio tempo, i dirigenti sono ridondanti. Possono essere responsabili nei confronti degli utenti finali, ma se stanno facendo il loro lavoro, sei responsabile nei loro confronti e devono proteggerti dal passare dalla modalità sviluppatore focalizzata alla modalità sviluppatore difensivo .

Alcuni punti per impostare il contesto della mia risposta:

Gli sviluppatori di software non sono viaggiatori nel tempo, quindi i risultati devono essere giudicati per quello che sono, non per quello che avrebbero potuto essere.
Se una funzione rientrava in una specifica dei requisiti, in una pianificazione ed è stata data priorità al lavoro completato, potrebbe esserci un reclamo legittimo. Altrimenti, qual è la giustificazione per renderti responsabile?
La tua punizione, se meritata, deve provenire dalla tua catena di comando. Proprio come il marketing e le vendite non gradirebbero se lo sviluppo del prodotto rimproverasse i clienti, la maggior parte delle organizzazioni ha i responsabili dei prodotti per ricevere l'ira (e gli elogi) dei clienti e trasmetterli attraverso i canali.
I responsabili di prodotto possono creare relazioni estremamente difficili se si crogiolano nel calore delle parti di successo dei progetti, ma riescono a spezzare la frusta solo quando affrontano gli 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 al di sopra della media.
Risolvere il problema in modo equo e produttivo richiede che le persone rimettano le dita della colpa in tasca e facciano un piano per andare avanti.

Sarai in grado di svolgere un lavoro di qualità molto migliore con una motivazione migliore se sei apprezzato invece di essere la capra in un processo che dovrebbe essere il capo dell'IT. È il modo giusto e il modo produttivo. Spero che sarai gestito in quel modo, e in futuro, spero che gestirai gli altri in quel modo.

— DeveloperDon
fonte

DevDon, vorrei che questo fosse con la risposta n. 1 poiché penso che questa sia una grande parte del nostro problema .... la nostra struttura IT per questo scenario è estremamente casuale. +1

— Utente Smith

1

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

— ddyer
fonte

Naturalmente questo è vero, ma quando l'utente finale scopre di poter manipolare il sistema in questo modo, la mia azienda sarà in una grave inclinazione verso il basso se questo continua poiché le risorse verranno utilizzate in questo modo rispetto all'utilizzo per la strategia aziendale complessiva direttive che guideranno davvero i profitti dell'azienda.

— Utente Smith

0

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

Dovrebbe esserci una traccia di documenti cartacei. Un documento di formazione che mostra come utilizzare l'applicazione. Una specifica funzionale che delinea ciò che è stato sviluppato. Se una funzionalità non è stata inclusa, dovrebbe esserci documentazione anche su quella. Qualcuno avrebbe dovuto firmare dicendo di accettarlo.

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

Se non hai questa documentazione ... allora temo che dovrai mordere questo. Consideralo una lezione di vita. Alla fine della giornata, i tuoi utenti sono i tuoi clienti e, come si suol dire, il cliente ha sempre ragione. Elaborare come aggiungere questa funzione e quanto tempo ci vorrà. Tieni un incontro e dì qualcosa sulla falsariga di "I nostri record mostrano che questa funzione non è mai stata implementata, ma possiamo prenderla vita in x settimane. Dovremmo andare a testa in giù?

E per l'amore di tutto ciò che è santo .... ottenere la documentazione di cui hai bisogno per dimostrare che è stata approvata.

— Tyanna
fonte

Sì, sono stato l'unico a lavorare a questo progetto. C'è una documentazione con aggiornamenti quotidiani che ho chiamato proofC nella mia domanda.

— Utente Smith

@UserSmith ~ Ho pensato che significasse più di un aggiornamento quotidiano dello stato. Non è proprio la documentazione di cui stavo parlando. Qualcuno ha firmato il prodotto finale? Esiste una formazione o documentazione relativa all'applicazione che hai fornito all'utente finale o al detentore del palo?

— Tyanna,

Sfortunatamente no. C'è stato allenamento ma un periodo di allenamento molto breve. Esiste la documentazione dell'applicazione ma non copre la mancanza di questa funzionalità presente. Gli aggiornamenti quotidiani sono fondamentalmente uno strumento di journal che usiamo per descrivere descrizioni iniziali, giornaliere e finali di ciò che è accaduto con un progetto.

— Utente Smith