Come salvare un progetto giovane e morente?

Sto pubblicando questo in modo anonimo perché non voglio avere potenziali problemi.
Ho un grosso problema
Di recente mi sono unito a una squadra che ha meno di un anno. Sono qui da un mese al progetto iniziato. La struttura aziendale si presenta così:

• Proprietario (non tecnico)
  • Project Manager (non tecnico)
    • Lead Developer (tecnico, ma non all'altezza)

Questo progetto è un sito Web che utilizza ASP.Net per il quale lo sviluppatore principale ha progettato un'architettura orribile per. Dovrai prendere la mia parola, ma in sostanza, il modo in cui siamo tenuti a creare pagine Web ci sta fornendo tempi di caricamento di 3+ ​​minuti su una singola pagina Web su VPN in modalità Debug.

È cresciuto fino al punto in cui altri colleghi concordano sul fatto che trascorrono più della loro giornata aspettando il caricamento delle pagine rispetto allo sviluppo reale.

Ora il grosso problema è questo. Il Project Manager non conosce la tecnologia e la ammette. Ha dichiarato espressamente di fidarsi del Lead Developer per fare le scelte giuste sull'architettura dell'applicazione.

Nessuno nella squadra sa quale sarebbe l'opinione dei proprietari, ma tutti hanno paura di fare ondate in questa economia (me stesso in particolare).

Cosa faresti?

Questo problema può essere dimostrato al project manager in termini non tecnici. Metti il ​​tuo sito in una finestra del browser di fronte al PM e chiedigli di giocarci un po '. Dopo circa due caricamenti di pagina, lo sviluppatore principale dovrebbe essere chiamato sul tappeto, se le cose vanno male come dici tu.

Il PM potrebbe non avere le conoscenze specialistiche di sviluppo per capire perché è male, ma può vedere da solo come utente di un sito Web generale. Altri siti che mostrano informazioni simili si caricano in una frazione del tuo tempo e il tuo si sta caricando sulla rete locale dal server nella stanza successiva.

Se questo non vola, allora vai al proprietario. Il proprietario è un ragazzo di soldi, ma sarà presto in grado di vedere quel sito web lento che nessuno visiterà == niente soldi. Prepara la stessa dimostrazione e prima che la prima pagina venga caricata dovrebbe chiamare ENTRAMBI il PM e il Lead sul suo tappeto molto più ricco.

Se sei preoccupato per un ragazzo che fa le onde, allora ottieni più di uno sviluppatore disposto a esprimere le loro preoccupazioni. Onestamente, in un'azienda piatta come la tua, se il prodotto che stai sviluppando è una bomba, sei senza lavoro, se parli o stai zitto. Quindi guardandolo in quel modo, non hai altro da perdere se non un paio di settimane o mesi in più con la compagnia. Se questo è un problema, fissa alcuni "appuntamenti dal dentista" e cerca un nuovo impiego prima di esprimere le tue preoccupazioni, quindi se perdi questo lavoro inizi il prossimo lunedì.

Supponendo che le tue dichiarazioni siano accurate, hai uno sviluppatore principale che è incompetente e un responsabile di progetto che è incompetente (almeno nella misura in cui non può valutare le capacità del team). Belle. Hai le stesse opzioni esatte degli sviluppatori di ogni squadra in tutto il mondo.

1. Lavori senza preoccuparti della salute dell'azienda.

2. Cerca lavoro altrove.

3. Fornire suggerimenti ragionevoli a Lead, PM e Owner e sperare che vengano adottati.

Sei libero di fare qualsiasi combinazione di quanto sopra contemporaneamente.

Se vuoi assicurare in modo aggressivo la salute del progetto, dovrai lavorare con gli altri sviluppatori per trovare un nuovo framework nel tuo tempo libero e dimostrare al resto del team perché è superiore e il vecchio lavoro dovrebbe essere abbandonato a favore di esso.

Ho lavorato in una situazione simile, in cui lo sviluppatore principale che era in realtà un partner dell'azienda aveva creato il "core" del software e, ad eccezione di un amico intimo che ha lavorato direttamente con lui, ad altri sviluppatori non è stato permesso di toccare il nucleo.

I "poteri che sono" hanno anche creato regole come ogni modulo potrebbe avere solo una tabella di database, perché è più pulito in quel modo. E di conseguenza, i menu a discesa esistenti sono stati creati selezionando "DISTINCT" dalle tabelle nel database, anziché avere una tabella separata.

C'erano un certo numero di patch difettose che fluttuavano perché il team di implementazione doveva eseguire il lavoro e il prodotto non funzionava immediatamente. Queste patch hanno causato tanti problemi quanti sono stati corretti e sono state personalizzate (hackerate) per ogni installazione.

Il mio approccio era quello di prendere una piccola parte delle specifiche che il core non supportava e scrivere una piccola, buona e generica patch per essa. Qualcosa che ha soddisfatto il team di implementazione, ma non è stato minaccioso come "Dobbiamo cambiare completamente il nostro modo di pensare". A causa dell'animosità tra il team di implementazione e gli sviluppatori principali, ci sono voluti mesi per convincere il team di implementazione che il mio approccio era migliore dei loro hack. Ma una volta hanno visto che li avrei ascoltati e implementato ulteriori aggiustamenti per supportarli, sono stati felici e dalla mia parte. Lo sviluppatore principale ha impiegato un altro mese per accettare la patch, ma una volta che l'ha fatto ha davvero aperto la comunicazione tra tutti noi su modi migliori per progettare altre parti del sistema.

Non è mai una strada breve per cambiare il pensiero delle persone, soprattutto se è necessario mantenere un rapporto civile con loro. Ma se lo approcci nel modo giusto, puoi ottenere rispetto senza insultare il tuo capo.

Spero possa aiutare!

Risposta e soluzione molto semplici. Sembra che tutti siano a conoscenza del problema. Quindi, andare in giro sottolineando il problema non ha alcun valore per nessuno. In realtà ti fa sembrare un piagnucolone. Se si desidera aggiungere valore, è necessario indicare la soluzione e creare il business case per passare alla soluzione. Quindi è possibile evidenziare il problema con una soluzione corrispondente. Una demo farebbe molto per dimostrare la tua soluzione. Ovviamente, questo può significare fare un lavoro nel tempo libero, ma tutto dipende da quanto sia importante anche per te.

Prima di tutto, ti consiglio vivamente di assicurarti dei tuoi fatti in quanto si tratta di un problema di architettura dell'applicazione e non di qualcosa nella configurazione VPN. Ho visto VPN mal configurate causare questo esatto problema. Sai per certo che l'app è così lenta all'interno dell'ufficio?

Se hai escluso la rete, vorrei seguire il suggerimento di KiethS e chiedere al PM di aprire la pagina.

Sembra che il business, o almeno il progetto finirà presto ad un certo punto. A corto di smettere, proverei ad allontanarmi da esso il più rapidamente possibile, ad es. volontariato / richiesta di lavoro su altri progetti in corso. Spero che nel tempo trascorrerai meno tempo in questo disastro e più in altri progetti che hanno la possibilità di funzionare. Non vuoi essere considerato come "il ragazzo che ha lavorato al progetto che non ha funzionato". Si tratta di proteggere la tua reputazione.

Il proprietario desidera un buon prodotto o no? Sospetto fortemente che la risposta sia "Sì" ... e quindi, devi parlare. È necessario documentare l'architettura attuale e quindi (con buoni dati imperiali), mostrare come il prodotto non soddisfa le aspettative di prestazione adeguate. Dici che tutti i tuoi colleghi sanno che funziona male - beh ... che dire del cliente? Cosa stanno dicendo? Utilizzare uno strumento di misurazione delle prestazioni e determinare cosa sta impiegando così tanto tempo. Molti strumenti ti mostreranno anche quanto tempo impiega ogni chiamata di funzione. Da tutti questi dati, dovresti avere abbastanza munizioni per parlare con il tuo project manager e il capo tecnico sul perché le cose non sono come dovrebbero e su come potrebbero essere necessari alcuni importanti refactoring per rendere il prodotto veloce.

Quindi (solo dopo aver parlato con il PM e il comando), questo DOVREBBE bastare per iniziare ad apportare alcune modifiche. Se il PM non è convinto a quel punto, allora devi decidere se questo è davvero un posto dove vuoi essere. In tal caso, probabilmente un incontro con il proprietario. In caso contrario, prepara quel curriculum.

Assicurati di documentare tutto in ogni fase del processo.

In termini tecnici concordo con i suggerimenti sopra. D'altra parte, ritengo che sia più un problema di relazione che tecnico.

Se vuoi seguire la strada giusta, parlare con lo sviluppatore principale sarà una scelta adatta. Non vorrei parlare in ufficio però. Bere un caffè fuori renderà le cose un po 'informali e più rilassate.

Se il problema persiste, puoi provare a parlare con il PM e poi con il proprietario.

Se nessuno funziona, ti consiglio di cercare un nuovo lavoro.

Onestà - e più tatto che puoi raccogliere.

Inizia con lo sviluppatore principale e procedi verso l'alto se necessario. Cerca di coinvolgere i lati migliori della loro personalità - Se conduci agli sviluppatori piace risolvere problemi / Mi piace per salvare la giornata / I Mi piace essere efficienti / ecc. hanno avuto successo in passato come motivazione aggiuntiva.

Se non stai facendo alcune onde, probabilmente sei morto nell'acqua.

Sarebbe possibile riportare i problemi a un livello misurabile e in modo non tecnico in modo che il project manager e il proprietario possano capire.

Ad esempio, hai menzionato il tempo di caricamento lento di 3+ ​​minuti, suppongo che ci sia un requisito di prestazioni da qualche parte nelle specifiche, qualcosa di semplice come "pagina da caricare entro 1 sec". Qualcosa del genere è misurabile e non può essere confutato. Se la causa principale di questo problema è l'architettura non corretta, il project manager e / o il proprietario dovrebbero intervenire per forzare alcune modifiche.

Altrimenti, hai un problema sistematico nella tua azienda in cui l'analisi iniziale è stata eseguita male e non c'è abbastanza processo in atto per rilevare questo tipo di problemi. Valuta di saltare la nave!

I veri uomini parlano senza risentimento o emozione. Questo è il trucco.

L'unico motivo valido per cui qualcuno potrebbe essere arrabbiato con te per aver parlato, è se ti senti risentito:

LO SVILUPPATORE PRINCIPALE NON HA ALCUNA INDICE COSA FA. Sapevo che sarebbe successo, ma nessuno mi ha ascoltato bla bla bla.

mentre

Il modello di codice è sbagliato perché è difficile da mantenere e rallentare. Dobbiamo essere strategici riguardo a questo progresso e risolvere questi due problemi.

Il primo è una battaglia da distruggere, il secondo è una battaglia per la pace e, a lungo termine, ti farà guadagnare il rispetto che una persona ottiene per essere onesto.

Se il capofila del progetto lo considera immediatamente, cosa che sicuramente potrebbe considerare, potrebbe essere licenziato, quindi semplicemente dire,

Non ritenermi responsabile di cose che non ero responsabile dell'implementazione. Sono solo sincero.