Come salvare un progetto giovane e morente?

Questo problema può essere dimostrato al project manager in termini molto non tecnici. Metti il tuo sito in una finestra del browser di fronte al PM e chiedigli di giocare con esso per 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 di sviluppo specializzate per capire perché è cattivo, ma può vedere da solo come utente di un sito web generale che è. 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 non vola, vai dal proprietario. Il proprietario è un tipo da soldi, ma sarà in grado di vedere molto presto un sito lento che nessuno visiterà == senza soldi. Configura la stessa dimostrazione e prima che la prima pagina venga caricata dovrebbe chiamare ENTRAMBI il PM e il Piombo sul suo tappeto più ricco.

Se sei preoccupato per un ragazzo che fa ondate, allora ottieni più di uno sviluppatore disposto a esprimere le sue preoccupazioni. Onestamente, in una società piatta come la tua, se il prodotto che stai sviluppando è una bomba, sei senza lavoro se parli o taci. Quindi, osservandolo in questo modo, non hai nulla da perdere se non un paio di settimane o mesi extra con la compagnia. Se questo è un problema, pianifica alcuni "appuntamenti dal dentista" e cerca un nuovo impiego prima di trasmettere le tue preoccupazioni, quindi se perdi questo lavoro inizi il prossimo lunedì.

Supponendo che le tue affermazioni siano accurate, hai un Lead Developer che è incompetente e un Project Manager che è incompetente (almeno nella misura in cui non è in grado di valutare le abilità del team). Belle. Hai esattamente le stesse opzioni degli sviluppatori di ogni squadra in tutto il mondo.

1. Lavori senza occuparti dello stato di salute dell'azienda.

2. Cerca lavoro altrove.

3. Fornisci suggerimenti ragionevoli a Lead, PM e Owner e spera che vengano adottati.

Sei libero di fare qualsiasi combinazione di quanto sopra contemporaneamente.

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

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 effetti ti fa sembrare un piagnucolone. Se si desidera aggiungere valore, è necessario indicare la soluzione e sviluppare il business case per passare alla soluzione. Quindi puoi indicare il problema con una soluzione corrispondente. Una demo potrebbe anche fare molto per dimostrare la tua soluzione. Ovviamente, questo può significare fare un lavoro nel tuo tempo libero, ma tutto dipende da quanto sia importante anche per te.

Ho lavorato in una situazione simile, in cui lo sviluppatore principale che era in realtà un partner della società aveva creato il "nucleo" del software e con l'eccezione di un amico intimo che lavorava direttamente con lui, altri sviluppatori non erano autorizzati 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 questo modo. Come risultato, i dropdown esistenti sono stati creati selezionando "DISTINCT" dalle tabelle nel database, anziché avere una tabella separata.

Ci sono state un certo numero di patch difettose che galleggiavano perché il team di implementazione doveva completare il lavoro e il prodotto non funzionava immediatamente. Queste patch hanno causato tanti problemi quanti sono stati risolti e sono stati personalizzati (hackerati) per ogni installazione.

Il mio approccio consisteva nel prendere una piccola parte delle specifiche che il core non supportava e scrivere una patch piccola, buona e generica per questo. Qualcosa che ha soddisfatto il team di implementazione, ma non è stato così 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 avrei ascoltato e implementato ulteriori adattamenti per sostenerli, erano felici e dalla mia parte. Ci è voluto un altro mese prima che lo sviluppatore principale accettasse la patch, ma una volta 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 modo di pensare delle persone, soprattutto se hai bisogno di mantenere una relazione civile con loro. Ma se ti avvicini correttamente, puoi ottenere rispetto senza insultare il tuo capo.

Spero che ti aiuti!

Sembra il business, o almeno il progetto andrà presto a un certo punto. Prima di smettere, cercherò di allontanarmi da esso il più rapidamente possibile, ad es. volontario / richiesta di lavoro su altri progetti in corso. Si spera che col tempo, trascorrerai meno tempo in questo disastro e più su altri progetti che hanno la possibilità di lavorare. Non vuoi essere pensato 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 molto che la risposta sia "Sì" ... e quindi, devi parlare. È necessario documentare l'architettura corrente e quindi (con buoni dati imperiali), mostrare in che modo il prodotto non soddisfa le aspettative relative alle prestazioni. Dici che i tuoi colleghi sanno che si comporta male - beh ... e il cliente? Cosa stanno dicendo? Utilizzare uno strumento di misurazione delle prestazioni e determinare cosa sta richiedendo così tanto tempo. Molti strumenti andranno anche giù per mostrarti quanto tempo impiega ogni chiamata di funzione. Da tutti questi dati, dovresti avere munizioni sufficienti per parlare con il tuo project manager e il responsabile tecnico del perché le cose non sono come dovrebbero e come alcuni importanti refactoring potrebbero essere necessari per portare il prodotto alla massima velocità.

Quindi (solo dopo aver parlato con il PM e dirigere), questo dovrebbe essere sufficiente per iniziare a fare alcune modifiche. Se il PM non è convinto a quel punto, allora devi decidere se questo è davvero un posto dove vuoi essere. Se è così, allora forse un incontro con il proprietario. Altrimenti, prepara il curriculum.

Assicurati di documentare ogni passaggio.

In termini tecnici sono d'accordo con i suggerimenti di cui sopra. D'altra parte, ritengo che sia più simile a un problema di relazione piuttosto che a un problema tecnico.

Se vuoi prendere la strada giusta, parlare con lo sviluppatore principale sarà una scelta adatta. Comunque non parlerei nell'ufficio. Avere un caffè all'aperto renderà le cose un po 'informali e rilassate.

Se non funziona, puoi provare a parlare con il PM e poi con il proprietario.

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

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

Se hai escluso la rete, andrei con il suggerimento di KiethS e chiedo al PM di aprire la pagina.

Sarebbe possibile riportare i problemi a un livello misurabile e 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, presumo che ci sia un requisito di prestazioni da qualche parte nelle specifiche, qualcosa di semplice come "pagina da caricare entro 1 sec". Qualcosa di simile è misurabile e non può essere confutato. Se la causa principale di questo problema è l'architettura dubbia, il project manager e / o il proprietario dovrebbero intervenire per forzare alcune modifiche.

In caso contrario, hai un problema sistematico nella tua azienda in cui l'analisi iniziale è stata eseguita male e non c'è abbastanza processo per prendere questo tipo di problemi. Prendi in considerazione l'idea di saltare la nave!