Come gestisci i clienti che chiedono modifiche dei dati manuali nel database? [duplicare]

3

Recentemente ho iniziato a lavorare su un'applicazione legacy che francamente non fa tutto ciò che dovrebbe. Manca un sacco di funzioni, ha a malapena qualsiasi capacità di amministrazione e non controlla la metà dei dati che dovrebbe.

In quanto tale, è molto facile per gli utenti fare qualcosa di stupido e rimanere bloccati. "Ops, ho aggiunto questo elemento del tipo sbagliato a questo coso e ora non mi consentirà di rimuoverlo" . In effetti, l'applicazione avrebbe dovuto verificarlo, ma consentito aggiungere l'elemento sbagliato. E ora, quando si tratta di eliminare l'oggetto sbagliato, diventa estremamente protettivo e si rifiuta di rimuovere qualsiasi cosa.

Il problema è che i clienti (che in realtà sono utenti all'interno dell'azienda) non si preoccupano molto di questo. Hanno bisogno dell'applicazione per contenere i dati del mondo reale come dovrebbero, quindi chiedono agli sviluppatori di "ripararli" modificando i dati. In questo esempio, l'eliminazione dell'elemento sbagliato. In altri casi, riassegnerà gli articoli a diversi genitori, correggendo vari valori, ecc ...

Dato che l'applicazione non ha quasi nessuna GUI di amministrazione, tutto finisce per essere eseguito direttamente nel database (augh!), mettendo a rischio ancora più problemi down-the-line a meno che tu non sappia esattamente come funziona ( che nessuno fa davvero considerando la massiccia applicazione).

In definitiva, sembra che il database sia diventato un enorme file di Excel che si modifica giorno per giorno ai capricci dei clienti, a causa di errori dell'applicazione.

È ovvio per me che la correzione dell'applicazione per evitare situazioni del genere dovrebbe essere la priorità, ma sembra che i clienti preferiscano chiedere un sacco di nuove funzionalità invece che siano accettate come tali.

Che cosa può fare uno sviluppatore in una situazione del genere? È persino possibile rifiutare le modifiche di DB in favore di sistemare le cose? Ci sono così tanti bug che sembra che non aspetteranno mai che a lungo ...

    
posta leokhorn 28.07.2014 - 13:54
fonte

2 risposte

8

Poiché non sei nella posizione di cambiare la politica, ciò che tu e i colleghi dovete fare è:

  • Documenta il costo della politica: la quantità di tempo che impieghi a fare correzioni nel DB anziché svilupparlo,
  • Documenta il rischio della politica: il numero di volte in cui una correzione nel DB ha avuto conseguenze impreviste e quanto gravi erano
  • Documenta qualsiasi altra conseguenza negativa: logoramento degli sviluppatori, perdita di fiducia degli utenti ecc.

e presentalo ai tuoi diretti dirigenti (non vuoi essere visto andare a testa alta da nessuno in questo tipo di ambiente). In un mondo ideale avrai già un sistema di supporto che tiene traccia di questo genere di cose, ma presumo che il tuo mondo sia lontano dall'ideale! Potrebbe far sì che qualcuno abbia un senso, non lo è, ma così facendo hai adempiuto a tutte le tue responsabilità nei confronti dell'azienda.

Se dopo questo, non cambia nulla, allora temo che tu debba accettare il posto di lavoro disfunzionale e scrollarti di dosso tutti i fallimenti, o andare avanti. Quando si verificherà l'inevitabile crisi, una copia di quanto sopra scritto per lo meno ti coprirà le spalle.

    
risposta data 28.07.2014 - 14:19
fonte
3

Ho visto la stessa identica situazione, e ciò che abbiamo fatto è stato l'assegnazione di una sola persona per eseguire solo la correzione dei dati .

In questo modo i clienti hanno ottenuto rapidamente i propri requisiti di correzione dei dati e il resto degli sviluppatori, liberati da tale onere, ha potuto correggere l'app più rapidamente.

Una volta risolti tutti gli errori che generano dati errati, la persona assegnata alla correzione dei dati è stata nuovamente assegnata allo sviluppo / mantenimento.

È proibitivo, quindi un battlefront alternativo potrebbe essere (basato sull'esperienza di vita reale):

  • Crea script di motricità che rilevano dati errati ancor prima che l'utente ti chiami
  • Crea script che semplificano diversi tipi di correzione dei dati
  • Crea trigger che rifiutano inserimenti o aggiornamenti non validi (che possono anche aiutare a ricreare i bug), fino a quando i bug sono corretti
risposta data 28.07.2014 - 15:17
fonte

Leggi altre domande sui tag