Il gestore continua a modificare le specifiche dei requisiti dopo ogni demo [chiuso]


21

Contesto del mio ambiente di lavoro

Il mio manager non ha alcuna conoscenza o conoscenza di computer o software. È molto probabile che non abbia visto il codice in nessuna forma (nemmeno da una distanza fisica di 10 piedi o meno) nella sua vita.

Non c'è nessuno che capisce la complessità di ciò che mi viene chiesto di attuare. Al punto che se avessi un semi-hardcode nessuno lo avrebbe saputo.

Sul test di Joel segniamo un punteggio incredibile 0.

I problemi

  • Il manager e altre volte "senior" continuano a modificare le specifiche dei requisiti. Modifiche che, se viene eseguita una buona progettazione e non "correzioni" irregolari, richiedono una modifica del progetto sottostante.
  • Non c'è assolutamente nessuno che guardi il codice (probabilmente perché nessuno sa come farlo, o anche se dovrebbe essere fatto), il che significa che nessuno sarà mai in grado di:
    • Apprezzo la complessità del problema o l'eleganza della soluzione.
    • Suggerisci miglioramenti all'approccio.
    • Apprezzo la qualità del codice.
    • Indica dove è possibile migliorare il codice.
  • Viene usato un sacco di gergo che ha un senso grammaticale ma non ha alcun senso in nessun altro modo.
  • Non si sente, si comporta o funziona come una società di software.

La domanda

Cosa dovrebbe essere fatto? Soprattutto per quanto riguarda il fatto che non ci fosse nessuno che segnalasse miglioramenti nel mio codice.

Aggiornare

Per rispondere alla domanda di HLGEM (e forse di altri) su cosa ho fatto per provare a risolverlo. Mi sono offerto di configurare Redmine e introdurre il controllo del codice sorgente a tutti. Ho detto che consiglierei distribuito (git o mercurial) ma parlerò anche di quelli centralizzati e lascerò decidere la squadra. La risposta è stata che le cose sono state fatte e lo saranno entro poche settimane. Non l'ho visto né so se altre parti dell'azienda lo usano.


36
per prevenire la risposta ovvia: CORRI !!
keppla,

3
A meno che non ci sia qualcosa di importante che non ci stai dicendo di iniziare a cercare un nuovo lavoro.
Zaccaria K

11
"Il manager e talvolta altri" senior "continuano a modificare le specifiche dei requisiti." Bene, avere una specifica ti farebbe segnare un 1 nel test di Joel. : P
R. Martinho Fernandes,

11
Nessuna organizzazione ottiene meno di 2 nel Joel Test esclusivamente a causa di manager non tecnici. Ci sono un certo numero di cose che tu e altri membri tecnici del team potete fare senza il contributo di manager non tecnici per aumentare il vostro punteggio. Non hai scuse per dare la colpa esclusivamente al gestore.
maple_shaft

6
Sembra che tu abbia anche il team di vendita come gestore del software, mi dispiace.
Wildpeaks

Risposte:


30

La versione corta :

Correre.


La versione un po 'più lunga :

Se il manager non sa come gestire un progetto e se il senior lo segue, allora non hai quasi nessuna possibilità di sistemare le cose.

Per gestire progetti software, un manager deve capire qualcosa sul software. Se i manager non lo fanno, devono prima imparare. Quali sono le tue possibilità che tu possa convincere il tuo management e i tuoi senior che hanno sbagliato tutto? Quali sono le possibilità che insegnerai loro qualcosa?

Una volta mi sono trovato in una situazione simile (solo che non c'erano senior). Ho smesso dopo un anno terribile, e non ho mai guardato indietro (tranne con disgusto).


3
+1 per questa citazione: "Se il manager non sa come eseguire un programma e se il senior lo segue, allora non hai quasi alcuna possibilità di sistemare le cose."
maple_shaft

17

... continua a modificare le specifiche dei requisiti. Modifiche che, se viene eseguita una buona progettazione e non "correzioni" irregolari, richiedono una modifica del progetto sottostante.

Sembra il mondo reale. Questo succede sempre, ovunque. Sì, fa schifo, ma è sopportabile con una sorta di atteggiamento agile. Inoltre, una misura della bontà del software è la sua malleabilità. Prendilo come una sfida.

Viene usato un sacco di gergo che ha un senso grammaticale ma non ha alcun senso in nessun altro modo.

Ancora una volta, non sembra così sconosciuto ;-)

Nessuno capisce la complessità di ciò che mi viene chiesto di attuare.

Neanche tu? Se lo capisci, allora c'è una persona allo specchio che lo capisce. Quindi la tua responsabilità per il benessere della tua azienda è probabilmente più pesante di quanto il tuo titolo formale suggerisca. Se capisci i problemi e il tuo manager non lo fa, è tua responsabilità chiarire le cose alla direzione in modo che possano dirigere correttamente l'azienda. Potrebbe essere ragionevole presumere che i tuoi dirigenti più vicini dovrebbero essere tecnicamente competenti (non necessariamente competenti come te - mentre sono manager, tu sei l'esperto - ma almeno un po 'competente), ma se ovviamente non lo sono e potresti aiutarli, perché no?

Una semplice soluzione di fuga è quella di cambiare compagnia. Ma come un'altra opzione, considera l'implementazione degli articoli del test Joel. Sebbene gli articoli a partire da 5 richiedano una maggiore cooperazione con la direzione, gli articoli da 1 a 4 sono tali da poterli semplicemente impostare senza chiedere a nessuno.

Detto questo, nessuno qui a SE può conoscere la tua situazione esatta. È possibile che tu sia in una compagnia affollata da cretini incompetenti, e ricavare qualcosa di buono da un tale casino potrebbe essere troppo per chiunque. Devi valutare tu stesso la situazione.


Che dire di qualcuno che mi fa notare i miei torti? Aiutandomi a migliorare e imparare.
Jungle Hunter

4
@Jungle Hunter: Sarebbe ovviamente più facile essere in un'azienda in cui tutto è stato prontamente creato, tutti stanno già seguendo tutte le migliori pratiche immaginabili ecc. In modo che tu possa essere solo l'apprendista e imitare gli altri. Ma potresti anche migliorare e imparare molto assumendoti la responsabilità ed essendo te stesso attivo nel migliorare la tua azienda. Migliorare e apprendere è in definitiva nelle tue mani. Altre persone possono aiutare, ma il tuo capo non deve essere uno di loro.
Joonas Pulakka,

Si hai ragione. Sto cercando di migliorare, ma penso che i miei sforzi siano visti più come lamentarsi che tentare di migliorare. Sinceramente i miei sforzi sono entrambi, ma vediamo se riesco a convincerli a vedere la seconda metà - tenta di migliorare.
Jungle Hunter

@Jungle Hunter: vedo, il confine tra lamentarsi e migliorare può essere confuso . Ma non fa mai male inclinarsi verso il lato costruttivo.
Joonas Pulakka,

4
@Joonas: Sono stato in aziende in cui ho introdotto VCS, revisioni del codice, tenuto seminari in C ++ e quant'altro, per migliorare la qualità del codice. E sono stato in una società praticamente come descritto dall'OP. Se è un caso senza speranza, devi ammettere la sconfitta e cercare un lavoro in cui la tua lotta viene premiata permettendoti di avere successo.
sabato

16

Dici in uno dei commenti che questo è il tuo primo lavoro. I gestori spesso non sono tecnici da nessuna parte tranne un negozio di software dedicato nella mia esperienza. Questo fa parte della vita, abituati.

Piangi e piagnucoli perché non c'è nessuno che apprezzi l'eleganza delle tue soluzioni. Il vero problema qui non è che non c'è nessuno che apprezzi l'eleganza delle tue soluzioni, ma che non c'è nessuno che ti insegni che le tue soluzioni non sono così buone come pensi. Praticamente tutti i nuovi programmatori sopravvalutano le loro capacità reali. Senza mentore, non c'è nessuno che ti aiuti a migliorare le pratiche. Se non c'è nessuno lì a farti da mentore, allora unisciti ai gruppi di utenti locali, partecipa attivamente e porta qualcuno lì a farti da mentore. Ancora meglio, ciò ti aiuterà a trovare un lavoro migliore alla fine.

Hai segnato uno zero nel test Joel? Se sei l'unico programmatore (e suona da quello che hai scritto che sei), perché non stai usando il controllo del codice sorgente? Cosa ti sta impedendo? Se non sei l'unico programmatore, perché non c'è nessuno che possa fare le revisioni del codice? Tutti i nostri sviluppatori eseguono la revisione del codice, non è una funzione di gestione soprattutto quando i gestori non sono tecnici.

I requisiti cambiano praticamente in tutti i posti. Le esigenze aziendali cambiano continuamente e i non programmatori spesso non riescono a visualizzare ciò che il programma farà finché non vedranno qualcosa. Quindi si rendono conto che non è quello di cui hanno bisogno. Ecco perché Agile è nata davvero perché i metodi più vecchi non gestivano bene quel cambiamento.

Imposta il tracciamento dei bug anche se la direzione non vuole inserire i dati da soli. Sii responsabile dell'immissione di nuovi bug / funzionalità quando qualcuno li menziona. Aiuta davvero essere in grado di dire al manager quando vuole un cambiamento che ti sono state assegnate altre 27 cose ed ecco la lista, quale vuoi che io scorra verso il basso l'elenco delle priorità per accogliere questa nuova modifica. Aiuterà al momento della revisione perché sarai in grado di contare il numero di correzioni di bug e funzionalità implementate. Se non lo usano tutti, almeno puoi farlo per il tuo lavoro. Se non ti consentono di installare alcun software, utilizza un foglio di calcolo Excel. Prendi qualche iniziativa. Una volta che puoi mostrare i risultati, altri saranno più interessati. Se pensi che ci sia troppo lavoro per una persona, il bug tracker ti aiuterà a dimostrarlo.

Non fornire demo dall'aspetto lucido! Le demo dovrebbero apparire come se fossero scarabocchiate a penna su un pezzo di carta. Più l'interfaccia è raffinata, più la persona non tecnica pensa che sia finita.

Anche se nessuno saprebbe se non segui le migliori pratiche e il codice semi_hard per esempio, lo saprai e ti imbatterai in cattive abitudini sciatte. Questo non ti servirà bene nel tuo prossimo lavoro. Quindi fai le cose il più vicino possibile al modo giusto nelle circostanze. Assicurati di scrivere i test (considera questo come parte del tempo di sviluppo e dedica il tempo a farlo nelle stime che dai alla gestione anche se non dici specificamente che fa parte del preventivo) e usa questi test per assicurarti le modifiche successive non rompono qualcos'altro.

Devi vederlo come un'opportunità inestimabile per crescere e migliorare. Hai più libertà nella codifica effettiva di molte persone in quella fase della tua carriera. Quindi considera questa un'opportunità per creare un portafoglio di progetti attuati con successo. Quando vai a cercare quel lavoro successivo, essere in grado di evidenziare risultati come il controllo del codice sorgente istituito, il monitoraggio dei bug istituito, il numero X di implementazioni di progetti di successo, ecc., Ti farà distinguere dal resto.

Hai anche una grande opportunità qui per imparare a gestire le aspettative verso l'alto. Questo è askill che ti tornerà utile per il resto della tua carriera. Non hai nulla da perdere nel provare a farlo qui, le cose non sono già buone. Ma puoi imparare le abilità politiche che ti aiuteranno in posti migliori in seguito. Impara a fare un'analisi costi-benefici. Impara a capire meglio il dominio aziendale in modo da poter essere convincente quando parli con loro. Impara a parlare in termini di vantaggi per l'azienda e profitto. Fai delle stime per ogni compito che ti è stato assegnato e anche se non corrispondono a ciò che la gestione ti sta dando, tieni traccia di ciò che hai stimato e di ciò che è effettivamente necessario per migliorare la tua capacità di stimare il lavoro. Una volta che puoi dimostrare che le tue stime sono state storicamente più accurate di quelle gestionali, saranno più propensi ad ascoltare quando dici loro che la stima è troppo bassa. Ma devi creare un track record prima di entrambe le stime più accurate e, soprattutto, la capacità di consegnare i progetti e farli funzionare. Ancora una volta questa è una buona abilità da avere man mano che avanzi nella tua carriera.

Soprattutto non essere passivo e aspettarsi che il miglioramento arrivi dall'alto.


1
Questa risposta ha parti molto utili. E alcune cose che ritengo errate nel comprendere la mia situazione. Come, menziono entrambi i casi, nessuno da apprezzare quando va bene. Nessuno da segnalare quando ho sbagliato. Uso il controllo del codice sorgente, ma in un team di 2-3 nessuno lo fa. Il codice, quando viene condiviso, viene condiviso utilizzando pendrive e Airdrop. Se stai leggendo il commento, penso di aver anche menzionato che ho installato Redmine sul mio laptop che finisce per essere utilizzato solo da me. E lo stesso con Git. Ho cercato di implementarli per tutti. Il mio livello, appena uscito dal college. Senior dovrebbe codificare ma non lo fa.
Jungle Hunter

Prenderò il consiglio di costruire un track record. Ricorderò che ho più libertà sul palco che in generale. Potrei imparare a gestire le aspettative e altre capacità politiche e trasversali.
Jungle Hunter

3
Smetti di dare loro il codice su pendrive. Se vogliono il tuo codice, digli che è nel controllo del codice sorgente e mostra loro come usarlo.
Hugo,

1
@JungleHunter Quando ti chiedono il tuo codice, dì loro che sei a metà strada attraverso una modifica che non verrà eseguita, ma possono ottenere l'ultima versione stabile dal controllo del codice sorgente.
Kirk Broadhurst,

1
@HLGEM "Piangi e piagnucoli"? Troppo duro, downvoting solo per quello.
Ben H

6

Se fossi in te, proverei a trovare un altro lavoro. Perché? Penso che tu sappia che, sfortunatamente, il tuo manager è, beh, "non buono". Dovresti provare a risolvere alcune cose con il tuo manager.

Se non vuoi andartene e / o non parlerai con nessuno, allora dovrai trovare qualcosa da solo. Se nessuno in azienda è a conoscenza del tuo codice, come può il tuo manager sapere che hai i requisiti? Sto solo dicendo.


Guarda solo una demo. Diciamo, cambiamo questo in questo modo e quello in quel modo. E poi c'è un diluvio di gerghi.
Jungle Hunter

2
@Jungle, non farei quasi nessun lavoro nelle demo, dal momento che sono destinate a cambiare selvaggiamente una volta che le vede. Sembra innanzitutto una persona visiva. Hai provato a redigere schermate di diversi casi d'uso per lui? Questo può essere molto più semplice da assemblare rispetto ai prototipi funzionali.
maple_shaft

@maple_shaft: penso sia un'ottima idea.
Jungle Hunter,

1
@maple_shaft: o forse invece di consegnare molto in anticipo, consegna solo verso la fine. ;)
Jungle Hunter

1
Consigli sul lavoro da parte di una

4

Parla con il tuo manager e con gli anziani di questo. Spiega i tuoi problemi e suggerisci soluzioni. Prepara un po 'il discorso in modo da conoscere il messaggio generale che vuoi trasmettere.

Dopo il discorso, dagli un po 'di tempo . Vedi se le cose cambiano o no. In caso contrario, prova a implementare le modifiche da solo e mostra al manager e agli anziani i risultati positivi delle tue modifiche .

Se il discorso non aiuta e le modifiche vengono ignorate, devi valutare tu stesso quanto ti piace lavorare in quel luogo. Sì, il lavoro potrebbe essere cattivo, ma forse la paga è buona e hai solo un tragitto di 5 minuti? Gli aspetti positivi del tuo lavoro superano quelli negativi? Io no, inizierei a cercare un nuovo lavoro.


1
Ho parlato. Mi sono offerto di impostare un sistema di ticketing, un controllo della versione di introduzione ma a lui non importa. O capisci. O entrambi. Gli ho chiesto di parlargli di avere specifiche affidabili e lui è d'accordo. Lo cambia comunque. Non è guidato dai dati. (Oh e rimosso l'enfasi sul testo dalla mia domanda.)
Jungle Hunter

2
@Jungle: quindi esegui al più presto.
sabato

1
Sono d'accordo con sbi, se non avessi già chiesto di essere abbattuto, avresti potuto legittimamente uscire e farlo da solo. Hai già perso la stanza e se fossi nella tua situazione, inizierei a cercare.
maple_shaft

3

Il tuo problema è che i sistemi di ticketing e il controllo della versione sono questioni TECNICHE e dovresti farlo indipendentemente dall'input di un manager non tecnico. Questo dovrebbe essere assunto tecnicamente come una buona pratica e se non lo hanno impostato, dovresti prenderlo su te stesso per farlo accadere.

Non puoi aspettarti che un responsabile non tecnico comprenda i vantaggi del rilevamento dei difetti, del controllo del codice sorgente e dell'integrazione continua. Questo è il motivo per cui non sono tecnici, non dovrebbero saperlo o preoccuparsene, sono esperti di dominio e conoscenza del business. L'unica cosa che dovrebbero fornire è la direzione e i requisiti di alto livello.

Ho anche un manager non tecnico ed è stato in grado di aumentare il punteggio di Joel Test da 4 a 8 solo perché ci sono andato e li ho fatti e non ho chiesto il permesso.

Il tuo gruppo ha bisogno di un leader tecnico forte e nessuno ha fatto un passo avanti.

Dai un'occhiata a http://community.rallydev.com/ hanno un'edizione della community che fa un ottimo lavoro di gestione dei progetti Agile e rilevamento dei difetti. Solo questo aumenterà il tuo punteggio Joel e non ti costerà NESSUN spazio o tempo del server per la configurazione.


Sì! Questo è il problema principale. Non abbiamo un leader tecnico forte.
Jungle Hunter

2

Se questo è un piccolo negozio in cui tu e gli altri "senior" siete fondamentalmente le uniche persone che codificano, allora in realtà potrebbe essere vostra responsabilità indicare al manager cosa deve essere fatto per soddisfare il "Joel Test".

I cambiamenti nei requisiti saranno sempre presenti e il tuo compito è quello di abbracciarli, che è uno dei principi di base dello sviluppo agile :

Sono benvenute le mutevoli esigenze, anche in fase avanzata di sviluppo. I processi agili sfruttano il cambiamento per il vantaggio competitivo del cliente.

Adattarsi al mutare delle esigenze significa anche seguire altri principi agili. A livello di gestione, ciò significa che il manager deve essere in grado di presentare in modo trasparente al cliente che tutte queste modifiche comportano un costo: o l'ambito del progetto deve essere modificato per rispettare le scadenze o le scadenze devono essere spostate (quest'ultima non è consigliata).

Se si tratta di una sorta di progetto in cui il tuo manager è colui che soddisfa tutti i requisiti, allora dovresti comportarti come se fosse il tuo cliente agile e spiegare loro la stessa cosa (portata <--> compromessi di scadenza ).

Ma a livello di sviluppatore in una piccola azienda, direi che è tua responsabilità garantire che la parte di codifica sia conforme alle raccomandazioni agili.

Questi sono alcuni passaggi che devi assolutamente fare, e probabilmente dovrai farlo da solo:

  • si deve avere un sistema di controllo di versione (prende un giorno a configurarlo per una piccola squadra)
  • si deve avere script di build per garantire che è possibile effettuare rilasci spesso (piuttosto veloce da configurare anche)
  • è necessario utilizzare i test di unità automatizzati (questo è un modo di codificare e detta radicalmente l'intero progetto, quindi potrebbe essere difficile aggiungerli nel mezzo di un progetto strettamente accoppiato)
  • potresti anche impostare un sistema di integrazione continua per garantire build e test automatizzati, nonché test funzionali e GUI (che sono un po 'più difficili da scrivere)

Ricorda che puoi avere un repository SVN localmente sul tuo computer. Un semplice elenco TODO potrebbe servire da sistema di tracciamento dei bug di un uomo povero (un po 'estremo, ma ehi). E non ci sono scuse per non avere script di compilazione.

Inoltre, prima di fare qualsiasi dichiarazione sui compromessi relativi a portata / scadenza, qualcuno deve anche fare previsioni su quanto tempo impiegherà una determinata funzione. Questo di solito viene fatto in "giorni ideali" nel mondo agile, il che significa che dovresti fare del tuo meglio per prevedere lo sforzo relativo di ciascuna funzione, quindi utilizzare la tua velocità di codifica effettiva per vedere quanto hai previsto (e ridimensionare la "curva" di conseguenza ).


Per "vantaggio competitivo del cliente" è la chiave. Più tardi oggi gli ho chiesto perché lo fa, dice, per impressionare il cliente. : |
Jungle Hunter

Ho git / mercurial in atto per me stesso. Ma faccio i test manualmente adesso. Dovrei esaminare i test unitari automatizzati.
Jungle Hunter

1

Penso che manchino livelli di responsabilità nella tua squadra. Dovrebbero esserci un project manager, un analista di sistemi, un analista di business e sviluppatori. Il ruolo di Project Manager è responsabile della definizione e dell'applicazione della strategia di comunicazione cliente-progetto (tra le altre attività).

I manager non sono tenuti a comprendere il codice o le complessità. La necessità di comprendere risorse, costi e rischi.

Le versioni del codice sorgente, la qualità del codice, la complessità, ecc. Sono responsabilità del PM o dello sviluppatore senior.

La soluzione è:

1-Definire la struttura del team di progetto e le loro responsabilità

2-Educare il manager in caso di guasti del software causati da cattiva gestione - Stare lontano dai dettagli tecnici. Puoi trovare alcuni esempi cercando su Google.


"Stai lontano dai dettagli tecnici." Proverò a resistere. ;) Grazie per la segnalazione.
Jungle Hunter

0

Soprattutto per quanto riguarda il fatto che non ci fosse nessuno che segnalasse miglioramenti nel mio codice.

Non potresti provare a impostare recensioni di codice in modo che ci siano persone che guardano il codice? Ci sono convenzioni e standard che potrebbero aiutare a dare una certa struttura al codice? Questo presume che tu non sia l'unico sviluppatore lì ovviamente.

Mentre sei probabilmente in un posto non eccezionale, sembra che stia funzionando alla fine? I progetti vengono realizzati e le cose stanno andando avanti? Le cose vengono fatte? Il programmatore del nastro adesivo sarebbe l'articolo di Joel che potresti voler leggere.


Ho pensato di far cambiare il mio team a uno che ha persone che possono vedere il mio codice. Oppure prova a metterti in contatto con la gente lì per rivedere il mio codice. Come ho detto nelle domande, in questo momento non c'è nessuno che possa farlo.
Jungle Hunter

0

Opzione 1: dire loro "con tutte le modifiche che state apportando a questo progetto, quando lo implementeremo, il sistema funzionerà molto lentamente" o "il cliente non sarà in grado di capirlo". I tuoi manager non si preoccupano del codice spaghetti ma si preoccupano del cliente. Poni loro il problema in termini di ciò che comprendono, non in termini di scrittura del codice.

Opzione 2: dai loro quello che vogliono. Quando si lamentano di qualcosa che dici "ma è quello che hai chiesto"


Prima di "correre", farò esattamente questo. Se vogliono cambiare, farò loro sapere che non è un piccolo cambiamento qua e là, quindi ci vorrà molto più tempo. Quando il cliente non sembra felice, non avranno nulla di cui lamentarsi perché ho dato loro quello che volevano.
Jungle Hunter

@jungle hunter - Non tutti hanno la possibilità di lasciare il lavoro, a volte devi trascendere la situazione. Ho trovato il modo migliore per gestire la follia è di riaccendere i matti. Solo i pazzi possono discutere contro la loro follia. in bocca al lupo.
jqa,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.