Durante lo sviluppo di un nuovo sistema - dovrebbe lo schema db sempre essere discussa con le parti interessate? [chiuso]

https://stackoverflow.com/questions/398881

29-08-2019
|

Domanda

Sono diversi strati / livelli al di sopra delle persone coinvolte nel progetto che sto per descrivere.

Il requisito generale è per un sistema di gestione basato sul web problema. Il sistema è una piccola parte di un progetto molto più grande.

Il pm di piombo ha un pm tecnologia che dovrebbe gestire questa parte del progetto. Il pm di piombo mi ha chiesto se è normale che le informazioni di aiuto per non essere nel contesto in cui è stato richiesto l'aiuto. Il pm di piombo era fornire un feedback sul sito e ha voluto le finestre di dialogo modale e quali messaggi di errore e mi ha voluto dare un'occhiata. Sto guardando il sistema e sto pensando ...

una nuova applicazione è stata sviluppata in fusione fredda!?!?
l'applicazione ha estremamente povero convalida dei dati
Nella pagina di convalida dei dati app naviga lontano dal form di inserimento dati
l'aiuto pagina dell'app naviga lontano dalla forma
lo schema db non è stata discussa tra il committente e il pm
lo schema db non è stato discusso perché non esiste
c'è una pagina di menu - vale a dire una volta che si accede ad una pagina, si deve tornare al menu principale e poi andare alla pagina successiva che si desidera
il pm di piombo non sa quello che il DBMS è ...
c'è un pm tecnologia e lei non sa quello che un DBMS è ...
il pm di piombo ha voluto sparare il pm tecnologia per lungo tempo, ma il pm Tech è protetta ...
il pm di piombo ha suggerito che la funzionalità desiderata esatto esiste in diversi progetti di proprietà (molti dei quali sono open source - bugtracker, bugzilla, ecc.), Ma il pm tecnologia e dev non voleva ascoltare

Ho due domande?

Devo

sparare il dev?
sparare il pm tecnologia e la persona proteggerla?
sparare il pm di piombo?
scaricare e configurare bugtracker / bugzilla per loro e poi il fuoco tutti?
scaricare e configurare bugtracker / bugzilla per loro e poi andare a bere una birra per dimenticare i miei dolori?

e non è SOP per lo schema db da discutere e rigorosamente pensato per molto presto nel progetto?

EDIT:

Ho usato per lavorare con una vasta gamma di clienti con livelli diversi di conoscenze tecniche (e l'intelligenza). Ho sempre discusso lo schema db con gli stakeholder. Se loro non sapevano che cosa fosse uno schema, li avrei insegnato. Se non hanno avuto lo sfondo per capire, sarei ancora discutere lo schema con loro - anche se non si sono resi conto che stavamo parlando dello schema. Nella maggior parte dei progetti sono stato direttamente coinvolto nella, i dati è la parte più importante del sistema. Accuratamente hashing il modello schema / dominio è stato fondamentale nel raggiungere una buona comprensione del sistema e ciò che le cose si può fare e riferito. Ho grande considerazione per le opinioni dei manifesti su SO. E 'interessante notare che il mio approccio non è il solito corso.

A proposito - la cosa triste è che il progetto utilizza i fondi contribuente e la parte IT è una collaborazione con una prestigiosa università ... il dev e pm tecnologia sono dipendenti a tempo lungo - non sono inesperti. Trovo particolarmente triste quando so persone intelligenti e laboriosi che sono senza lavoro e persone come queste sono impiegati.

Quando ero più giovane, mi segnalo questo tipo di inettitudine a monte della catena e si aspettano azioni appropriate. Ora che sono a monte della catena, trovo non mi voler micro-gestire le responsabilità di altre persone.

La mia decisione era quella di avere due birre e tornare a mie responsabilità ...

Soluzione

I dati dovrebbero essere discusso con le parti interessate, assolutamente sì. Lo schema DB NON deve essere discussa con le parti interessate, tranne in circostanze particolari, in cui gli attori sono tutti "savvy database".

Così come si può discutere i dati senza discutere la DB Schema? Questo è l'uso principale che ho trovato per entità-relazione (ER) diagrammi, e il modello ER in generale. Un sacco di progettisti di database tendono a trattare ER come una versione annacquata della modellazione relazionale dei dati (RDM). Nella mia esperienza, può essere usato molto più proficuo, se non si pensa a come annacquato RDM.

Che cosa è una differenza tra ER e RDM? In RDM, un molti a molti richiede una scatola di derivazione nel mezzo. Questa scatola di giunzione contiene chiavi esterne che collegano la scatola di giunzione ai partecipanti nella relazione molti a molti.

In ER, se applicato rigorosamente, scatole di derivazione sono inutili in molti a molti rapporti. Basta indicare la relazione come una linea, e indicare la possibilità di "molti" ad entrambe le estremità della linea. In realtà, diagrammi ER non hanno bisogno di chiavi esterne a tutti. Il concetto di legame per mezzo di chiavi esterne può essere lasciato fuori dalla discussione con la maggior parte degli utenti.

La normalizzazione dei dati è del tutto irrilevante per ER diagrammi. Un diagramma ER ben costruito avrà molto poco ridondanza dannoso in essa, ma questo è in gran parte serendipità e non il risultato di un'attenta pianificazione.

Le "entità" e "relazioni" in uno stakeholder orientato diagramma ER dovrebbero includere solo le entità che sono capiti dagli esperti in materia, e non includere entità o relazioni che vengono aggiunti nel corso della progettazione del database logico.

I valori che si terrà in un database e servito su richiesta possono essere collegati agli attributi, e gli attributi possono a loro volta essere collegato sia a soggetti o le relazioni tra le entità. Inoltre, attributi possono essere legati ai domini, l'insieme dei possibili valori che ogni attributo può assumere. Alcuni valori memorizzati nei database, come chiavi esterne, dovrebbero essere lasciati fuori discussioni con la maggior parte le parti interessate.

Le parti interessate che comprendono i dati hanno generalmente una comprensione intuitiva di questi concetti, sebbene i termini "entità", "relazione", "attributo", e "dominio", possono essere a loro sconosciuta. I soggetti interessati che non capiscono i informatica Argomento richiedono un trattamento speciale.

La bellezza dei modelli e diagrammi ER è che possono essere utilizzati per parlare di dati non solo nei database, ma anche come i dati vengono visualizzati in forme che gli utenti possono vedere. Se avete le parti interessate che non capiscono le forme e formano compilare, il mio suggerimento è che si cerca di tenerli lontani da computer, se è ancora possibile.

E 'possibile trasformare un diagramma ER ben integrato in uno schema relazionale moderatamente ben costruito da un processo abbastanza meccanico. Un processo di design più creativo potrebbe comportare uno schema "migliore" che è logicamente equivalenti. Alcuni attori tecnici hanno bisogno di capire lo schema relazionale e non semplicemente il diagramma ER. Non mostrare lo schema relazionale per le persone che non hanno bisogno di saperlo.

Altri suggerimenti

Bene, la prima cosa, per rispondere alla tua domanda: no no, mille volte NO! Gli utenti non sono persone che se ne discuta db schemi con; in generale, si sarebbe pure discutere calcolo con una mucca. Anche se hanno il background tecnico, per quanto riguarda la prossima volta che i requisiti cambiano; dovrebbero essere coinvolti nella aggiornamento dello schema?

Più in generale, questo suona come un caso in cui i conduttori tecniche lasciare che il problema uscire contatto con i "clienti" o le parti interessate. Se sei stato chiesto di realtà fix il problema, io suggerirei è necessario costruire un prototipo GUI di qualche tipo, magari anche solo uno storyboard, e camminare attraverso che . allora avrete un'idea di dove stanno le cose.

Avanzate : sì, sarebbe normale per discutere lo schema di DB all'interno del progetto. Direi che si ha bisogno di pensare seriamente a un po ', ehm, maggiore consulenza con i conduttori.

estesa più : Capisco il tuo punto, ma la cosa è che lo schema del database è un dettaglio di implementazione. Siamo così abituati a banche dati ci lasciamo perdere le tracce di questo, e finisce con le applicazioni che, beh, assomigliano a banche dati. Ma il database non è quello che fornisce valore per il cliente; è se il cliente può fare le cose che vogliono. Se si legano i modi in cui il cliente vede l'applicazione per gli schemi DB, allora si legarli ad un'implementazione; un cambiamento, come ad esempio denormalizing un tavolo al fine di rendere un sistema più efficiente, diventa qualcosa che si deve mostrare al cliente. Meglio per mostrare loro le osservabili, e mantenere questi dettagli a noi stessi.

Ma ho il sospetto che stiamo avendo uno scontro terminologia, anche. Sarei stato d'accordo con te su "modello di dominio." Se, per lo schema db, vuoi dire solo quelle tabelle e relazioni visibili nella vista dell'utente del sistema, i "casi d'uso", se volete, allora saremmo concordando.

Bene, per prima cosa, probabilmente dovrebbe rivedere con molta attenzione il rapporto tra il pm tecnologia e il suo sponsor. Mi sorprende che tu dici il pm tecnologia è protetto quando più tardi implica si può sparare il protettore. O lei è, o lei non è protetto. Se si può sparare il protettore, poi lei non è protetto.

Così suona come nessuno è protetto, e peggio - NO-ONE sta comunicando. Mi consiglia il seguente: chiamo un incontro con il pm di piombo, il pm tecnologia e il dev. Una volta insieme, chiedere a ciascuno a sua volta: "senza fare riferimento nulla, se non il vostro lavoro (vale a dire non si può incolpare qualcun altro per tutta la durata di questo esercizio), mi dica in 5 minuti o meno il motivo per cui non dovrei sparare oggi"

Mi rendo conto che questo è un consiglio estrema, ma vi ho descritto una soluzione ORRIBILE ad un classico problema. Ogni aspetto di questo progetto e il "codice", determinando suona come un disastro. Probabilmente avrebbe dovuto avere una mano maggiore nella supervisione di questo pasticcio, ma non l'hai fatto (per qualsiasi motivo). Mi rendo conto che si dovrebbe aspettare professionisti incaricati a livello di PM a fare meglio di questo.

Da qui la mia raccomandazione per una grave shake-up della squadra. Una volta che si mette la paura della disoccupazione una tabella (e mi piacerebbe dire loro che si sta scrivendo la mancata comunicazione per ciascuno), poi chiedere loro di inviare piani di miglioramento della comunicazione immediata PLUS calendari dettagliati per fissare il disordine dal fine della settimana.

Poi scendere il proprio bum perché sei ora il PM LEAD-guida di questo progetto.

Se si forma e tirare fuori un ritorno su questo disastro, poi lentamente iniziare ad aumentare di nuovo le loro responsabilità. Se no ... c'è sempre una porta.

Saluti,

-R

il pm di piombo ha suggerito che l'esatto funzionalità desiderata esiste diversi progetti proprietari (diversi dei quali sono open source - bugtracker, Bugzilla, ecc), ma la tecnologia e pm dev non voleva ascoltare.

Se questo è vero, dire al pm vantaggio di essere più assertivo; poi dirgli / lei a installare Bugzilla e da fare con esso. Se il pm tecnologia e dev non ascoltavano a causa della testardaggine, hanno bisogno di un po 'di chat ...

In entrambi i casi, direi che hai un problema con la vostra organizzazione ... Quante migliaia di dollari sono stati persi a causa di un caso di "non sviluppati qui"? Tuttavia, dato che ha raggiunto il punto di realizzazione, ci sono problemi più a monte rispetto al livello di sviluppo ...

Per quanto riguarda discutere lo schema db con tutti, direi di no. Tutti coloro che possono contribuire positivamente deve essere coinvolto dopo che i requisiti di applicazione sono stati raccolti.

Wow, suona come un disastro. Permettetemi di affrontare i punti al fine di massima:

In primo luogo, le persone sviluppano in lingue che trovano comodo. Se qualcuno è comunque confortevole in un ambiente più vecchio quando esistono alternative molto meglio, è un segno sicuro che hanno poco appetito per l'acquisizione di abilità.
La convalida dei dati impedisce alle persone di andare troppo lontano giù un percorso solo per scoprire che è un vicolo cieco. La mancanza di convalida significa che lo sviluppatore non sta pensando all'utente. Inoltre, è non qualcosa appiccicato alla fine ... semplicemente non funziona in questo modo.
"finestre di dialogo" Web non possono essere "modale", nel senso che si sta pensando. Tuttavia, è abbastanza facile da pop-up una finestra aggiuntiva. Aiuto su una pagina dovrebbe quasi sempre utilizzare una finestra pop-up di questo tipo.
La convalida dei dati dovrebbe MAI navigare lontano dalla pagina in cui vengono inseriti dati - questa è la progettazione di interfacce utente orribile.
Lo schema di DB è una specie di l'ultimo dei vostri problemi. Se lo sviluppatore è responsabile per la consegna funzionalità ed è chiaramente competente progettazione dello schema dei dati, non mi pare fondamentale per discutere le sfumature dello schema con il PM di piombo. E ' dovrebbe essere discusso tra i vari soggetti interessati a livello di codice e deve essere in grado di gestire le esigenze del lavoro. Tuttavia, la cosa importante dal punto di vista del PM non è lo schema, quanto gli aspetti operativi. Naturalmente, se non si ha fiducia nella capacità dello sviluppatore di costruire un buon schema db, tutte le scommesse sono spenti.
Se sul serio non sai cosa i DBMS è, si può avere un serio problema. Hai uno standard? Se tutti gli altri nel progetto esteso sta usando MS SQL Server e questo ragazzo ha scelto Oracle, come si fa a trasferire know-how e il personale all'interno o all'esterno di questo progetto? Questo è un segno di un'organizzazione fuori controllo.
Ci sono due ragioni per ignorare prodotti proprietari alternativi. In primo luogo, essi non possono veramente soddisfare le vostre esigenze. In secondo luogo, il PM tecnologia e sviluppatori possono semplicemente essere Featherbedding o impegnati in qualche brutta giustificazione 'non inventato qui' per lo spreco di risorse. Il problema è che non si rischia di avere abbastanza conoscenza, al tuo livello, di conoscere la differenza tra i due.
Per quanto riguarda la cottura il Dev ... è possibile per aiutarlo con la sponsorizzazione di alcuni formazione supplementare? Se questa persona è altrimenti un buon impiegato e conosce bene il vostro business, sarei molto riluttanti a sparare loro, quando tutto quello che serve è una spinta nella direzione giusta.
Il PM tecnologia suona come lei davvero non sta facendo il suo lavoro. Lei è la persona logica a sottolineare i difetti che sto scrivendo e che spingono per il miglioramento. La vera domanda, vis a vis la sua posizione, è se si può imparare ad essere un avvocato migliore per i vostri interessi organizzativi.
Il PM di piombo sembra troppo passivo pure. I commenti fatti sopra per quanto riguarda la tecnologia PM si applicano anche qui.
Se bugtracker, ecc funziona davvero, allora avrebbe senso di seguire questa strada. Tuttavia, si potrebbe desiderare di essere un po 'più cauto su sparare persone.

Prima di tutto, sono d'accordo con Charlie Martin sullo schema di db.

In secondo luogo,

Sembra che lo sviluppatore del progetto è molto verde - è questa la sua / il suo primo lavoro di programmazione? Se è così, vorrei sparare solo il dev se il loro curriculum dice qualcos'altro.

Non so come coinvolto in vantaggio / PMS tecnologia dovrebbero essere in un progetto, ma suona come la responsabilità è dev> Tech pm> piombo pm. Se questo è il caso, allora il pm tecnologia completamente cadere la palla. Si consiglia di scoprire perché la palla è stata abbandonata e fuoco / mantenere la sua base a questo, ma un lavoro raffazzonato del genere è il tempo rimprovero in cui lavoro.

Infine, imho, la roba "protezione" è B.S. -. È necessario premiare e rimproverare le persone in base alla loro qualità e valore, non chi la zia è

In bocca al lupo! Cheers!

Wow. Sento il tuo dolore.

Sembra a me come se la prima causa del problema è la techPM che è "protetto". Perché è lei protetto e da chi? una volta ero su un progetto in cui la segretaria del ceo divenne il primo analista di business e poi (dopo che ha smesso) il responsabile del progetto, perché avevano una relazione. Non sapeva che lingua abbiamo programmato e requisiti di pensiero erano una perdita di tempo. Dal momento che lei era protetta da qualcuno più in alto possibile per l'organizzazione, l'unica vera soluzione era quella di guardare altrove per l'occupazione.

Lei sembra pensare di lei e il suo protettore si può sparare in modo che possa essere qualcuno inferiore a voi, ma al di sopra del PM di piombo in modo che non poteva fare nulla, ma si può? Sì, si dovrebbe sparare loro due.

Il PM di piombo può o non può essere salvabile a seconda di chi era il protettore. Avrebbe potuto essere tra l'incudine e il martello dove sapeva che cosa fare, ma a causa della natura del rapporto tra il pm tecnologia e il suo protettore era in grado di esercitare alcuna influenza su di lei e le persone che hanno riferito a lei. Ero in quella posizione una volta in cui due dei miei capi avevano una relazione con uno dei miei subordinati e crea ogni sorta di caos organizzativo (che è il motivo per cui il protettore deve essere licenziato così come il PM Tech). Dategli il beneficio del dubbio e discutere con lui come avrebbe avrebbe gestito le cose in modo diverso se il pm tecnologia e il suo protettore erano fuori strada. Se ti piace quello che si sente, si può tenerlo, ma organizzativo è necessario intervenire e fare in modo che sia chiaro questa persona è responsabile e nessuno sarà permesso di ignorarlo. Una volta che un piombo ha perso l'autorità, può solo tornare indietro con il forte sostegno dalla gestione.

Vorrei anche sedersi con il piombo e lo sviluppatore e spiegare esattamente che cosa è inaccettabile nel progetto nella sua forma attuale. Se lo sviluppatore si sente in grado di prendere la direzione dal piombo (si assumendo decidere di tenerlo) o è in grado di adattarsi a un nuovo modo di fare business o non riesce a capire il motivo per cui il codice così com'è è inaccettabile, tagliare le perdite e sbarazzarsi di lui pure. Una nuova persona è in grado di lavorare meglio per il piombo, se è recuperabile in ogni caso, perché non avrà una storia di ignorarlo.

Io non necessariamente pensare che lo schema del db deve sempre essere condiviso con le parti interessate. La maggior parte della gente non sa cosa fare con questo genere di informazioni. Se stai cercando di fare in modo che il prodotto si adatta alle esigenze, i requisiti dovrebbero essere chiaramente definite in anticipo e verificati in tutto lo sviluppo del progetto.

In caso di problemi con il dev, che è solo par per il corso. Qualcuno più degno di fiducia avrebbe dovuto essere trovata. Se hai assunto un povero coder, che è stato il tuo errore.

Ci sono alcune possibili soluzioni:

Ottieni un codificatore migliore. Che sarà lui odio lavorando attraverso tutto il codice male, ma si spera che sarà lui a slug attraverso di esso fino a che non ha fatto. Speriamo che sei disposto a pagare lui un buon prezzo.
Tenere il coder e fargli risolvere il tutto. Assumere un nuovo PM che lo può gestire meglio. Questo coder conosce il suo codice meglio e potrebbe richiedere meno tempo per lui di solo migliorarlo. Nel lungo periodo, è meglio non tenere una cattiva coder sul libro paga in modo perderlo quando hai finito.
succhiare in su, comprare una birra per tutti gli interessati e ricominciare con opensource. Avrete probabilmente ancora bisogno di un PM tecnologia per gestire il software. Avrete anche a dimenticare di fare qualsiasi cosa su misura in quel punto. Forse un imprenditore potrebbe gestire questo.

In entrambi i casi, si sta andando perdere dei soldi. Dovrebbe probabilmente mantenere un occhio più vicino sulle cose la prossima volta.

io tendo a pensare in questo modo. Lo schema del database è lì per supportare requisiti di archiviazione dati dell'applicazione. Quali dati l'applicazione ha bisogno di memorizzare sarà determinato dalle esigenze dell'utente finale. Se non sei consultare l'utente finale per i propri requisiti per l'applicazione che si sta, ovviamente, a capo di guai, ma a patto di avere una buona maniglia sulle loro esigenze (e probabilmente le future esigenze), allora lo schema del database è una decisione tecnica che può essere realizzato dal team di progetto, senza input diretto da parte dell'utente finale / cliente.

L'utente finale è improbabile per capire la complessità di tabelle, campi, normalizzazione, ecc, ma capiranno "il sistema ha bisogno di fare xyz". Parla con gli utenti finali in una lingua che comprendono, e lasciate che il vostro team di prendere le decisioni tecniche adeguate.

La mia domanda è circa il rapporto tra il pm di piombo e protettore del pm tecnologia: ha il vantaggio pm hanno buone ragioni per temere ritorsioni da parte del protettore? E 'del tutto possibile che si sentiva in grado di fare nulla fino a quando la situazione è abbastanza grave che era chiaramente importante per le persone al di sopra del protettore. In tal caso, egli non merita un trattamento più duro.

Il pm tech è evidentemente incompetente nel suo lavoro, e il suo protettore è più interessato a favorire la sua di ottenere il lavoro svolto. Questo mi fa pensare che hanno bisogno di essere affrontati in qualche modo, come minimo con un discorso circa l'importanza di ottenere vero e proprio lavoro svolto, al massimo sparando entrambi.

Il dev è probabile accovacciato, cercando di sopravvivere politicamente, dato il clima che hai delineato. Non posso dire abbastanza circa il dev per dare qualche consiglio.

Quindi, se la vostra descrizione e le mie incredibili poteri psichici mi hanno dato un quadro chiaro e preciso:

Proteggere il pm di piombo da ritorsioni, e dirgli di abbandonare tutte le CRUD e implementare una soluzione off-the-shelf. (Se non può selezionare uno se stesso in modo affidabile, non dovrebbe essere pm piombo.)

disciplinare il pm tecnologia e il suo protettore. Davvero non vogliono avere persone distruggendo la produttività aziendale in quel modo.

Il dev 'responsabilità del pm di piombo. Lasciare le cose come stanno. Non microgestire più di quanto si deve. Avere un paio di birre. Torna al tuo lavoro abituale.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow