La responsabilità senza autorità non ha senso: una soluzione tecnica?

Question

Mio padre dice sempre " La responsabilità senza autorità non ha senso " ;.

Tuttavia, trovo che come sviluppatori, restiamo bloccati in situazioni tutto il tempo in cui siamo:

• Responsabile di garantire che il software sia "privo di bug", ma non ha l'autorità per implementare un sistema di tracciamento dei bug
• Responsabile del rispetto delle scadenze del progetto, ma non può influenzare i requisiti, la qualità o le risorse del team (le tre parti della gestione del progetto)
• ecc.

Ovviamente ci sono un sacco di cose che potresti dire per aggirare questo problema: trova un nuovo lavoro, combatti con il capo, ecc.

Ma che dire di una soluzione tecnica a questo problema? Cioè, che tipo di cose di codifica puoi fare da solo senza dover convincere una squadra a correggere alcuni di questi problemi - o che tipo di strumenti puoi usare per dimostrare perché i bug non tracciati ti fanno male , che le scadenze non vengono rispettate a causa di problemi di qualità e come è possibile utilizzare questi strumenti per ottenere più "autorità" senza dover essere il capo?

---

*** Un esempio: il capo viene da te e dice " Perché ci sono così tanti bug !!?!? " - la maggior parte di noi direbbe " Non abbiamo un buon sistema per rintracciarli! " ;, ma questo di solito è visto come una scusa nella mia esperienza. Quindi, se potessi indicare un rapporto (i gestori adorano i rapporti) e dire " Vedi, ecco perché " ;?

Answer 1

Tutto quello che puoi fare è fare del tuo meglio, non pensare che la chiave per un software di successo sia solo nelle tue mani, nella tua parte di squadra e non devi essere responsabile di tutto.

Ovviamente ti trovi in ??un ambiente che influisce negativamente sul tuo software, ma non puoi cambiare tutto il suo comportamento, quindi ti consiglio di iniziare con il tuo, iniziare a lavorare in una squadra con i tuoi bug, scadenze, requisiti, qualità e risorse non preoccuparti del resto del pasticcio, ma cerca di essere il migliore nel tuo lavoro.

Lavorare come un team autonomo di uno che mostra al tuo capo i tuoi piani e riporta i tuoi progressi, chiedendo più risorse quando ne hai bisogno e mostrandogli come i tuoi piani vengono influenzati quando te li dà o no.

Puoi trovare ulteriori consigli al riguardo nelle PSP e TSP articoli di wikipedia

Dopo aver mostrato al tuo capo un buon lavoro e aver rispettato le tue scadenze, sicuramente si fiderà di te di più e lascerà che alcune delle tue idee scorrano sull'intero team.

Answer 2

Non hai bisogno di un sistema di tracciamento dei bug, hai bisogno di test automatici: unit test o altro. È possibile impostare test automatici con un Makefile. Puoi sempre trovare percorsi bloccati dalla direzione, ma ciò non significa che non ci siano cose che puoi fare entro i limiti del tuo lavoro. Naturalmente, la risposta potrebbe essere "trova un altro lavoro". Se non riesci a trovare un altro lavoro ora, impara alcune abilità in modo che tu possa.

Answer 3

La semplice risposta è: puoi iniziare a utilizzare gli strumenti da solo.

Migliora il tuo lavoro . Se le persone vogliono che tu aggiusti il ??codice, digli di presentare un bug. Mostra loro come. Assicurati che possano farlo senza installare nulla. Vogliono un aggiornamento dello stato? Di 'loro di controllare il bug. Ti chiedono una modifica del codice che hai fatto? mostrare loro come effettuare una query della cronologia del controllo del codice sorgente. o semplicemente mostrali sulla tua scatola. Inizia a mostrare loro queste cose funziona .

E quando hai bisogno degli stessi risultati da loro, richiedi che facciano le gambe. Quando non riesci a trovare le modifiche nel controllo del codice sorgente, chiedi loro di iniziare a diffondere manualmente le loro revisioni dai nastri di backup. Non fare il loro lavoro, o il lavoro di controllo del codice sorgente e tracciamento dei bug, per loro.

E, soprattutto, quando applichi questa pressione tra pari, sii gentile con esso . Mosche e miele e tutto il resto.

Se non lo ottengono, puoi continuare a essere l'unico sviluppatore professionista nella tua azienda o gruppo. O almeno ti aiuterà a riempire il tuo curriculum: "esperienza nell'impostazione e nell'insegnamento ad altri in CVS e FogBugs per migliorare la qualità del prodotto" e simili.

Answer 4

Per quanto riguarda gli strumenti specifici per dimostrare che i bug non tracciati stanno danneggiando la capacità del team di produrre un codice di qualità, qui hai un fermo-22 poiché hai bisogno di qualcosa per tracciare i bug prima di poter mostrare il loro effetto. Non puoi misurare ciò che non puoi monitorare. Quindi cosa fare?

Come esempio analogo, recentemente abbiamo avuto un membro del nostro team che pensava che il modo in cui facevamo le revisioni del codice via e-mail fosse assurdo. Quindi, ha trovato uno strumento open source, lo ha installato sulla sua scatola, ha fatto in modo che alcuni membri del nostro team di mentalità aperta lo provassero per un po ', quindi lo ha dimostrato al nostro team leader. Nel giro di poche settimane ha avuto l'opportunità di dimostrarlo a tutti i nostri team. Il nuovo ragazzo stava influenzando l'intera compagnia. Ho sentito molte storie di questa adozione di uno strumento in stile guerriglia.

Il trucco sta nell'identificare chi ha l'autorità per prendere la decisione, scoprire ciò che apprezzano e raccogliere prove sufficienti che ciò che si desidera implementare darà loro ciò che apprezzano.

Per uno sguardo più ampio su come condurre dal centro, o dal basso, di un'organizzazione, dai un'occhiata a The 360 ??Degree Leader di John Maxwell .

Answer 5

Se vuoi un rapporto sulla qualità e sul suo impatto sulla produttività, ecco il meglio: http://itprojectguide.blogspot.com/2008/ 11 / cappero-jones-2008-software-quality.html Caper Jones ha qualche libro in uscita e si presenta ancora alle conferenze. Al di fuori di un IDE valido, un gruppo di sviluppatori / IT necessita del controllo del codice sorgente (VSS, SubVersion, ecc.) E del rilevamento dei problemi

Answer 6

Se a un commercialista viene chiesto di produrre un insieme di account senza utilizzare la doppia iscrizione e non bilanciare, nessuno si aspetterebbe che il commercialista lo faccia.

Comunque la doppia entrata è stata in uso standard dai contabili dal 13 ° secolo circa.

Ci vorrà molto tempo prima che, come professione, abbiamo una pratica standard che è così radicata che uno lavorerà senza di loro.

Quindi, mi dispiace, mi aspetto che dovremo affrontare questo tipo di problema per molti l'anno a venire.

Answer 7

Ci scusiamo per non aver risposto direttamente alla tua domanda, ma ...

Sono fermamente convinto che il fallimento a cui ti riferisci sia di comunicazione, e spetta a noi come professionisti sviluppare le nostre capacità comunicative al punto in cui siamo abbastanza rispettati e abbastanza fidati da sfruttare l'autorità di cui abbiamo bisogno per migliorare il nostro lavoro ambienti e processi come suggerisci.

In breve, non credo che esista una soluzione tecnica in grado di risolvere tutti i problemi creati da una scarsa comunicazione sul posto di lavoro.

Semmai, la tecnologia ha causato l'attrito della comunicazione diretta faccia a faccia.

Mi dispiace, sono di nuovo su una tangente - sentiti libero di downmod.

Answer 8

Solo con il codice puoi mantenere in ordine i tuoi file sorgente, ben commentati, mantenere basso il numero di bug con i test. Ma avrai bisogno di strumenti esterni per tracciare progressi e bug (bugzilla, yoxel, trac, gantt diagram tools, Mylyn for Eclipse, un blog, qualunque cosa). In questi casi le persone, la disciplina, le buone abitudini e la leadership sono la forza schiacciante, nessuno strumento software e nessuna offerta individuale può vincere da solo.