Manager continua a cambiare la specifica dei requisiti dopo ogni demo [chiuso]

21

Sfondo del mio ambiente di lavoro

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

C'è nessuno che capisce la complessità di ciò che mi viene chiesto di implementare. Al punto che se io semi-hardcode nessuno lo saprebbe.

Nel test di Joel abbiamo ottenuto un punteggio incredibile 0.

I problemi

  • Il manager e talvolta altri "senior" continuano a modificare le specifiche dei requisiti. Modifiche che, se si esegue una buona progettazione e non "correzioni" disomogenee, richiedono modifiche nel progetto sottostante.
  • C'è assolutamente nessuno che guarda al codice (probabilmente perché nessuno sa come, o anche se dovrebbe essere fatto) il che significa che nessuno sarà mai in grado di:
    • Apprezza 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 senso grammaticalmente ma non ha senso in nessun altro modo.
  • Non si sente, si comporta o lavora come una società di software.

La domanda

Che cosa dovrebbe essere fatto? Soprattutto per quanto riguarda l'assenza di qualcuno che vorrebbe sottolineare miglioramenti nel mio codice.

Aggiornamento

Rispondere alla domanda di HLGEM (e forse ad altri) su ciò che ho fatto per provarlo e risolverlo. Mi sono offerto di creare Redmine e introdurre il controllo del codice sorgente a tutti. Ho detto che raccomanderei distribuito (git o mercurial) ma parlerò anche di quelli centralizzati e lasceremo decidere al team. La risposta è stata che le cose sono state fatte e saranno fatte entro poche settimane. Non l'ho visto e non sono a conoscenza se altre parti dell'azienda lo usano.

    
posta Jungle Hunter 31.08.2011 - 11:58
fonte

10 risposte

30

La versione breve :

Esegui.

La versione un po 'più lunga :

Se il manager non sa come eseguire un progetto, e se l'anziano lo segue, allora non avrai più possibilità di aggiustare le cose.

Per gestire i progetti software, un manager deve capire qualcosa sul software. Se i dirigenti non lo fanno, devono prima imparare. Quali sono le tue possibilità di persuadere i dirigenti e i senior che hanno sbagliato tutto? Quali sono le possibilità che insegni loro qualcosa?

Sono stato in una situazione simile una volta (solo che non c'era nessun anziano). Ho smesso dopo un anno terribile, e non ho mai guardato indietro (tranne che per il disgusto).

    
risposta data 31.08.2011 - 12:27
fonte
17

...keep changing the requirement specification. Changes which, if good engineering be done and not patchy "fixes", require change in the underlying design.

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.

A lot of jargon is used which makes sense grammatically but fails to make any sense any other way.

Di nuovo, non sembra così poco familiare; -)

There is no one who understands the complexity of what I am asked to implement.

Neanche tu? Se lo capisci, allora c'è una persona nello specchio che lo capisce. Quindi la tua responsabilità per il benessere della tua azienda è probabilmente più pesante di quanto suggerisca il tuo titolo formale. Se capisci i problemi e il tuo manager no, allora è tua la responsabilità di chiarire le cose alla direzione in modo che possano dirigere correttamente la società. Potrebbe essere ragionevole supporre che i manager più vicini dovrebbero essere tecnicamente competenti (non necessariamente competenti come te - mentre sono manager, 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, prendi in considerazione l'implementazione degli articoli del test di Joel. Sebbene gli articoli da 5 in su richiedano una maggiore cooperazione con la direzione, gli articoli 1-4 sono tali da poter essere impostati 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 idioti incompetenti, e fare qualcosa di buono da un tale disastro potrebbe essere troppo per chiunque. Devi valutare tu stesso la situazione.

    
risposta data 31.08.2011 - 12:14
fonte
15

In uno dei commenti dici che questo è il tuo primo lavoro. I manager spesso non sono tecnici da nessuna parte tranne un negozio di software dedicato nella mia esperienza. Questo fa parte della vita, ci si abitua.

Piangi e piangi perché non c'è nessuno che possa apprezzare l'eleganza delle tue soluzioni. Il vero problema qui non è che non c'è nessuno ad apprezzare 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 reali capacità. Senza un mentore, non c'è nessuno che ti aiuti a pratiche migliori. Se non c'è nessuno lì per guidarti, quindi unisciti ai gruppi di utenti locali, partecipa attivamente e ricevi qualcuno che ti aiuti. Ancora meglio, questo ti aiuterà a trovare un lavoro migliore alla fine.

Hai totalizzato uno zero nel test di Joel? Se sei l'unico programmatore (e suona da ciò 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 recensioni di codice? Tutti i nostri sviluppatori fanno una revisione del codice, non è una funzione di gestione soprattutto quando i manager 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à fino a quando non avranno qualcosa. Poi si rendono conto che non è ciò di cui hanno bisogno. Ecco perché Agile è nata proprio perché i vecchi metodi non gestivano bene quel cambiamento.

Imposta il bug tracking anche se la gestione non vuole inserire i dati stessi. Sii responsabile per l'inserimento di nuovi bug / funzionalità come qualcuno li menziona a te. Aiuta davvero essere in grado di dire al manager quando vuole una modifica che ti sono state assegnate altre 27 cose e qui c'è la lista, che vuoi spostare nella lista delle priorità per accogliere questo nuovo cambiamento. Aiuterà in fase di revisione perché sarà possibile contare il numero di correzioni di bug e funzionalità implementate. Se tutti non lo usano, 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, gli altri saranno più interessati. Se pensi che ci sia troppo lavoro per una persona, il bug tracker ti aiuterà a dimostrarlo.

Non mostrare dimostrazioni lucide! Le demo dovrebbero apparire come se fossero scarabocchiate su una penna su un foglio di carta. Più l'interfaccia è levigata e più la persona non tecnica pensa che sia finita.

Anche se nessuno saprebbe se ad esempio non segui le best practice e il codice semi_hard, lo saprai e ti ritroverai in cattive abitudini. Questo non ti servirà bene nel tuo prossimo lavoro. Quindi fai le cose nel modo più vicino possibile alle circostanze. Assicurati di scrivere dei test (considera solo questo come parte del tempo di sviluppo e dedica il tempo necessario per farlo in qualsiasi stima tu dia la gestione anche se non dici specificamente che fa parte della stima) e usa quei test per assicurarti le modifiche successive non infrangono qualcos'altro.

Devi considerarlo un'opportunità inestimabile per crescere e migliorare. Hai più libertà nella codifica attuale di quella che molte persone hanno in quella fase della tua carriera. Considerate quindi questa un'opportunità per creare un portfolio di progetti implementati con successo. Quando andrai a cercare il prossimo lavoro, essere in grado di evidenziare tali traguardi come il controllo del codice istituita, il monitoraggio dei bug, il numero X di implementazioni di progetti di successo, ecc, ti farà emergere dal resto.

Hai anche una grande opportunità qui per imparare come 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 fare questo 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 il dominio aziendale in modo da essere convincente quando parli con loro. Impara a parlare in termini di benefici per l'azienda e profitto. Fai delle stime per ogni attività che ti viene assegnata e anche se non corrispondono alla gestione del waht ti dà, 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 della gestione, saranno più propensi ad ascoltare quando dici che la stima è troppo bassa. Ma per prima cosa bisogna costruire un track record di entrambe le stime più accurate e, soprattutto, la capacità di fornire i progetti e farli funzionare. Ancora una volta questa è una buona abilità da avere mentre ti muovi nella tua carriera.

Soprattutto non essere passivi e aspettarsi che i miglioramenti arrivino dall'alto.

    
risposta data 31.08.2011 - 15:49
fonte
6

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

Se non vuoi andartene e / o non parlerai con nessuno, allora dovrai trovare qualcosa da te. Se nessuno in azienda conosce il tuo codice, come dovrebbe sapere il tuo manager che soddisfi i requisiti? Sto solo dicendo.

    
risposta data 31.08.2011 - 12:10
fonte
4

Parla al tuo manager e ai senior di questo. Spiega i tuoi problemi e suggerisci soluzioni. Prepara un po 'il discorso per conoscere il messaggio generale che vuoi trasmettere.

Dopo il talk, dagli un po 'di tempo . Vedi se le cose cambiano o no. In caso contrario, prova ad implementare le modifiche personalmente e mostra al gestore e agli anziani i risultati positivi delle modifiche .

Se il discorso non aiuta e le tue modifiche vengono respinte, devi valutare per te stesso quanto ti piace lavorare in quel posto. 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.

    
risposta data 31.08.2011 - 12:07
fonte
3

Il tuo problema è che i sistemi di bigliettazione e il controllo della versione sono argomenti TECNICI e dovresti farlo indipendentemente dall'input di un manager non tecnico. Questo dovrebbe essere assunto come una buona pratica dal punto di vista tecnico e se non hanno questa configurazione, dovresti prenderti cura di te per farlo accadere.

Non puoi aspettarti che un manager non tecnico comprenda i vantaggi del monitoraggio dei difetti, del controllo del codice sorgente e dell'integrazione continua. Questo è il motivo per cui non sono tecnici, non dovrebbero sapere 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 un 4 a un 8 solo perché sono andato a farli e non ho chiesto il permesso.

Il tuo gruppo ha bisogno di un strong leader tecnico e nessuno è arrivato al piatto.

Controlla link che hanno un'edizione per la comunità che svolge un eccellente lavoro di gestione dei progetti Agile e tracciamento dei difetti. Questo da solo aumenterà il tuo punteggio Joel e ti costerà NESSUN tempo o spazio sul server da configurare.

    
risposta data 31.08.2011 - 12:58
fonte
2

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

Le modifiche ai requisiti saranno sempre presenti e il tuo compito è quello di abbracciarle, che è uno dei principi base di sviluppo agile :

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Ma adattarsi ai mutevoli requisiti significa seguire anche altri principi agili. A livello manageriale, questo significa che il manager deve essere in grado di presentare in modo trasparente al cliente che tutti questi cambiamenti hanno un costo: o l'ambito del progetto deve essere modificato per rispettare le scadenze, o le scadenze devono essere spostate (quest'ultimo non è raccomandato). / p>

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

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

Questi sono alcuni passaggi che assolutamente devi fare e probabilmente dovrai farlo tu stesso:

  • tu devi avere un sistema di controllo della versione (impiega un giorno a configurarlo per un piccolo team)
  • tu devi avere gli script di compilazione per assicurarti di poter creare spesso le versioni (abbastanza veloce da configurare anche)
  • tu devi utilizzare i test unitari automatizzati (questo è un modo di codificare e determina radicalmente l'intero progetto, quindi potrebbe essere difficile aggiungerli nel bel mezzo di un progetto strettamente accoppiato)
  • potresti anche configurare un sistema di integrazione continua per garantire build e test automatici, oltre a 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 può servire come sistema di tracciamento dei bug di un povero uomo (un po 'estremo, ma ehi). E non ci sono scuse per non avere script di build.

Inoltre, prima di rilasciare dichiarazioni su compromessi ambito / scadenza, qualcuno deve anche fare previsioni su quanto tempo impiega una determinata funzione. Questo di solito viene fatto in "giorni ideali" in un mondo agile, il che significa che dovresti fare del tuo meglio per predire lo sforzo relativo di ciascuna caratteristica, e quindi usare la tua effettiva velocità di codifica per vedere quanto hai previsto ( e scala la "curva" di conseguenza).

    
risposta data 31.08.2011 - 16:33
fonte
1

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

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

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

La soluzione è:

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

2 - Educa il manager in caso di guasti del software causati da cattiva gestione - Stai lontano dai dettagli tecnici. Puoi trovare alcuni esempi su google.

    
risposta data 31.08.2011 - 12:35
fonte
0

Especially regarding there being no one who would point out improvements in my code.

Non potresti provare a impostare le revisioni del codice in modo che ci siano persone che guardano il codice? Ci sono convenzioni e standard che potrebbero aiutare a dare al codice una struttura? Questo presumerà che tu non sia l'unico sviluppatore lì, naturalmente.

Mentre sei probabilmente in un posto meno che bello, sembra che funzioni alla fine? I progetti vengono completati e le cose vanno avanti? Le cose stanno andando? Il Duct Tape Programmer potrebbe essere l'articolo di Joel che potresti voler leggere.

    
risposta data 31.08.2011 - 16:24
fonte
0

Opzione 1 - di 'loro' con tutte le modifiche che stai apportando a questo progetto, al momento della distribuzione, il sistema funzionerà molto lentamente 'o' il cliente non sarà in grado di capirlo '. I tuoi manager non si preoccupano del codice degli spaghetti ma si preoccupano del cliente. Indica loro il problema in termini di ciò che comprendono, non in termini di scrittura del codice.

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

    
risposta data 05.09.2011 - 02:09
fonte

Leggi altre domande sui tag