Nessun altro nel mio team si preoccupa dell'ottimizzazione, cosa devo fare?

Joe Strazzere

2017-01-26 22:44:36 UTC

view on stackexchange narkive permalink

Poiché si tratta di una produzione interna, il mio datore di lavoro è anche il cliente ed è soddisfatto del prodotto finale, quindi dovrei semplicemente dimenticare i problemi e contrassegnare il progetto come completo?

C'è un detto che dice "fai affari come si fanno gli affari".

Sei un imprenditore. Gli appaltatori fanno quello che gli viene detto di fare.

Ottimizzazione delle prestazioni, SEO, accessibilità, internazionalizzazione, manutenibilità, sicurezza, ecc. sono tutti importanti, ma sempre soggetti alle decisioni dei proprietari del prodotto.

Hai sollevato il questione da considerare e, si spera, ha spiegato le ramificazioni della loro decisione. Se hai un rapporto di sintesi del progetto, potresti menzionarlo lì.

È ora di contrassegnare questo progetto come "completato" e passare ad altre attività.

produrre un sito web lento
è contro i miei principi blockquote>
In qualità di appaltatore, sei libero di accettare o rifiutare un incarico in base ai tuoi principi. Una volta accettato il contratto, i principi del cliente sono quelli importanti.

Sì, sembra l'opzione giusta, non fare mai lavori che non ti viene chiesto di fare

@AlanSutherland Google non ha iniziato a punire i siti Web a caricamento più lento, in modo che non vengano visualizzati in alto nell'elenco dei risultati?Se è troppo lento, probabilmente non verrà visualizzato a meno che non si cerchi specificamente il sito Web.Potrebbe valere la pena parlarne con loro e potrebbe aiutarli a respingere la priorità di queste cose se è male.Sapere che qualcosa è brutto potrebbe essere irrilevante per loro, ma ora potrebbero conoscerne l'impatto.

Non sono d'accordo sul punto di vista dell'appaltatore.Come professionista non si dovrebbe mai accettare di pubblicare un sito Web gonfio che carica 12 secondi.

"Gli appaltatori fanno quello che gli viene detto di fare" - Questo dovrebbe essere affermato più chiaramente.Gli appaltatori fanno ciò che accettano di fare nel contratto.Generalmente ciò non include nulla oltre a prendere indicazioni su _ cosa_ dovrebbe essere fatto;qualcuno che prende indicazioni su _ dove, quando e come_ fare qualcosa verrebbe probabilmente visto come un dipendente piuttosto che come un appaltatore (può essere un'importante distinzione legale in alcune località).Detto questo, a meno che il contratto non includa esplicitamente l'ottimizzazione (oa meno che non sia vago al punto da dire semplicemente "costruisci un sito web"), sì, l'OP non dovrebbe preoccuparsene.

@Juris Un imprenditore esprime le proprie obiezioni, quindi fa come viene detto.Possono non essere d'accordo, ma se vogliono essere pagati lo fanno comunque.

Sono anche un costruttore di siti web;secondo le statistiche, se un sito web impiega più di 5 secondi per caricarsi, i clienti se ne vanno.Sono spesso sensibili alla perdita di denaro, questi tempi costano i soldi ai tuoi clienti!Hai fatto del tuo meglio, ma puoi fare così tanto da solo, ma se c'è un budget di riserva, puoi migliorarlo molto (voglio dire, 12 secondi ?!) Che migliorerà il reddito a lungo termine.

Aggiungo alla risposta che è ancora legittimo sollevare dubbi, possibilmente in forma scritta.In questo modo dovresti sentirti moralmente meglio e non avere problemi quando il cliente si renderà conto del problema e cercherà di incolpare qualcun altro.

@Juris: ma non è il sito web dell'appaltatore e gli è stato esplicitamente rifiutato il permesso di renderlo più veloce.Anche un'obiezione di principio a questo punto non può essere altro che "togli il mio nome dal progetto" - tranne per il fatto che il nome dell'appaltatore probabilmente non è mai stato sul progetto in primo luogo.Non puoi semplicemente accedere e modificarlo senza autorizzazione, professionalmente o legalmente.Se a un appaltatore viene detto di intraprendere un'azione positiva che considera non etica e non ha accettato nel contratto, certo, può rifiutarla.Ma in questo caso gli viene detto di non fare nulla.

@Juris No. Una persona altamente autorizzata dovrebbe rifiutarsi di ** accettare ** un lavoro sciatto.Una volta che un contratto è stato preso, deve essere adempiuto.Cambiarlo dopo la firma è ** la cosa più ** non professionale da fare.

@Juris Stai assumendo che il capo lo rilascerà nel suo stato attuale.È una pratica di sviluppo molto standard ottenere tutte le funzionalità fondamentalmente funzionanti e quindi refactoring.Se la società pensa che il tempo dell'appaltatore * in questo momento * sia meglio speso per aggiungere nuove funzionalità, è una chiamata di direzione ed è poco professionale (e potenzialmente motivo di licenziamento) ignorare tale decisione di gestione.Una buona pratica sarebbe quella di aumentare i CR per capire che ciò sarà richiesto in futuro, ovviamente.

Come nella risposta e per di più, assicurati di esprimere le tue preoccupazioni e di ottenere le risposte per iscritto, così almeno non ti morderà in futuro.

@Agent_L - Sono d'accordo.Una volta accettato il contratto, sei impegnato.

enderland

2017-01-26 22:44:11 UTC

view on stackexchange narkive permalink

e sono soddisfatti del prodotto finale

In quanto appaltatore, devi imparare che mentre il tuo cliente potrebbe fare ogni sorta di cose stupide, la decisione di farlo quelle stupide cose sono in ultima analisi una loro responsabilità.

Il tuo compito è consigliarli e assicurarti che comprendano i costi e i benefici di tali decisioni.

Non solo per consigliarli, ma per documentare esattamente chi hai consigliato, qual è stato esattamente il tuo consiglio e quale è stata esattamente la loro risposta.Forse il tuo capo ti dà un verbale "Nah, mi sembra a posto", ma non è la stessa cosa che crei una segnalazione di bug correttamente compilata e il tuo capo lo imposta su "chiuso - non risolverà" con un commento di "12sil tempo di caricamento non è un problema ".Oppure, se il tuo capo non è stupido, saprà che l'ottimizzazione può avvenire in un secondo momento, quindi la imposterà su "in sospeso" e tu potrai riprenderla più tardi.Potrebbe essere più importante ora aggiungere funzionalità che farlo perfettamente.

@graham se hai prodotto un documento non richiesto che diceva che non sei d'accordo con le mie decisioni e lo volevi a verbale, avrei trovato un motivo per uscire dal tuo contratto e darti un pessimo riferimento.Quel documento non avvantaggia nessuno, e nella migliore delle ipotesi serve come prova che ti sbagliavi, nel peggiore dei casi sembra come puntare il dito e sabotaggio.

@IDrinkandIKnowThings Se un ingegnere che lavora con me ha riscontrato un problema, non è riuscito a documentarlo e non è riuscito a documentare che è stata presa una decisione di gestione per non lavorarci, non assumerei mai più quell'ingegnere e consiglierei che nessun altro lo faccia.Non si tratta di essere in disaccordo con la decisione, si tratta di capire che * c'è * un problema e la decisione che è stata presa al riguardo."Nel registro", poiché la segnalazione di un bug / problema è * fondamentale * per essere un ingegnere competente e lavorare come una squadra, perché sono gli "sconosciuti" che ti uccidono.

Direi inoltre che fornire un documento di questa natura potrebbe essere utile se il cliente cerca di tornare con ripercussioni legali e / o finanziarie dicendo che non hai svolto un buon lavoro.Puoi indicare che li hai informati dei problemi per cui ti stanno facendo causa e che è stata loro la decisione di non farli affrontare da te o da nessun altro.Il cliente decide di risolvere il tuo contratto su di esso?È facile da spiegare ai futuri datori di lavoro e qualsiasi manager che lo consideri un problema è probabilmente un manager per cui non vuoi lavorare comunque.

@Graham - Il problema avrebbe dovuto essere documentato prima che l'ingegnere venisse da te.Non è responsabilità degli ingegneri prendere decisioni o tenere traccia delle decisioni prese.Questa è la responsabilità della direzione.

@IDrinkandIKnowThings È responsabilità dell'ingegnere documentare il problema.È responsabilità del * team * documentare quale decisione è stata presa al riguardo.Non è affatto insolito che i manager prendano decisioni in una riunione e gli ingegneri completino il tracciamento dei problemi.L'unico vero lavoro della direzione è prendere la decisione.Tutto il resto è scartoffie e chi lo fa è interamente in palio.L'unica cosa importante è che * qualcuno * si occupi dei documenti.

@Graham - Va bene se è così che funziona la squadra.È una pessima idea presumere che ogni squadra funzioni in quel modo.È anche una cosa da dire 2-1-2017 - Problema presentato e un altro da inserire 2-1-2017 Graham ha deciso che questo problema non era importante e dovremmo semplicemente ignorarlo.

@IDrinkandIKnowThings è d'accordo, ma in tal caso, se il manager non sta documentando le proprie decisioni, è necessario contattare CYA.Potrebbe essere semplice come un'email che dice "Graham, solo per confermare che sto mettendo in attesa CR8373 dopo la nostra conversazione precedente".Oppure registralo nella CR.Il tuo commento di pagliaccio è ovviamente poco professionale, ma è perfettamente valido dire "2-1-2017 Metti in attesa, poiché Graham dice che questo non è attualmente richiesto".

Attengo la mia dichiarazione originale.Non è professionale.

Konstantin Petrukhnov

2017-01-27 02:16:28 UTC

view on stackexchange narkive permalink

PageSpeed: 3/100, tempi di caricamento di quasi 12 secondi, la home page è di 8 MB

E le risposte qui suggeriscono di lasciarla così com'è. Per esempio. "Sei un appaltatore. Gli appaltatori fanno quello che gli viene detto di fare."

FORZA!

PageSpeed: 3/100, carica tempi di quasi 12 secondi, la home page è di 8 MB

Solo una risposta dice che il sito web è cattivo, ma cerca ancora di incolpare l'autore :)

Penso che è un pessimo sito web e dovrebbe essere migliorato. Come hai segnato, molte cose non sono molto difficili da ottimizzare. Il mio suggerimento è: fai ciò in cui credi. A volte può costarti il lavoro, ma davvero, vuoi di nuovo questo tipo di progetto?

Evidenzierei i problemi più volte attraverso conversazioni, e-mail, wiki, ecc. Informa su di loro tutti i livelli di colleghi (cliente e capo). Potresti usare una sorta di tabella con colonne: Problema (noto anche come rischio), Perché non va bene, Suggerimenti su come risolvere, Quali passaggi sono stati presi per risolvere.

In questo modo non si tratta solo di spiegare il problema, ma di dare un percorso chiaro per risolverlo. Se il cliente non vuole accettare / risolvere questi problemi, è alla sua destra e dovresti rispettarlo. Ma sta a te prendere sul serio ogni progetto, o semplicemente "fare qualunque cosa e passare a quello successivo". Personalmente, mi piacerebbe vedere più persone con buoni principi e coraggio per aggiustare le cose quando a nessuno importa.

Potresti rispondere a un'altra semplice domanda: vuoi essere un ingegnere o un robot, chi fa quello che gli è stato detto di fare?

Esattamente.Se sei un professionista, il tuo lavoro deve essere alla pari, qualunque cosa accada.

Esattamente.Anche gli appaltatori, non solo i dipendenti possono essere (e dovrebbero aspirare ad essere) [artigiani] (http://manifesto.softwarecraftsmanship.org/).

`Evidenziavo i problemi più volte attraverso le conversazioni` Beh, l'ultima volta che ci ho provato, ero solo considerato un cazzone (letteralmente).Mi dispiace tanto ma non sono d'accordo con quello.Ora preferisco considerare che non lavoro con persone stupide, spiego il problema una volta, se mi viene detto di andare avanti, non è più un mio problema.Inoltre, prendendo un'iniziativa indesiderata, se rompi qualcosa che "funziona", ti assumerai la piena responsabilità.

@Walfrat Nel caso del PO, devono aver documentato le loro preoccupazioni (e le ragioni per le quali dovrebbe essere di preoccupazione per l'azienda).Non tanto perché qualcuno si aspetta che ciò faccia la differenza, ma per coprire le spalle dell'OP, se la società alla fine si sveglia e cerca di causare problemi "perché l'OP ha creato un sito lento" o - se richiesto da un futuro (potenziale) datore di lavoro per dimostrare il lavoro precedente - l'OP ha un contatore a "OMG che è così lento".

@TripeHound Sono d'accordo con il fatto che semplicemente non sono d'accordo con il fatto di evidenziare * più * volte.Fallo una volta, se rifiutano e puoi documentare ulteriormente, fallo una seconda volta con tutto documentato, se non ascolteranno, non è più un tuo problema.

Erik

2017-01-26 22:44:56 UTC

view on stackexchange narkive permalink

Poiché si tratta di una produzione interna, il mio datore di lavoro è anche il cliente ed è soddisfatto del prodotto finale, quindi dovrei semplicemente dimenticare i problemi e contrassegnare il progetto come completo?

Sì. C'è solo un vero standard per l'ottimizzazione, ed è "le persone che lo usano sono soddisfatte delle prestazioni?".

In questo caso dicono di sì, quindi è praticamente tutto.

Resta da vedere se gli utenti finali effettivi ne saranno soddisfatti o se il tuo datore di lavoro ne sarà ancora soddisfatto tra poche settimane, ma fintanto che è a conoscenza dei tuoi suggerimenti e dice che è bene, questo è tutto ciò che puoi fare.

È lo stesso di quando il datore di lavoro ti chiede di implementare funzionalità che pensi non funzioneranno; sono il cliente e se ignoreranno i tuoi suggerimenti, dovrai accettarli e farlo come vogliono loro.

Oltre a questo, documenta le tue preoccupazioni e chiedi al tuo capo di confermare che non sono importanti.CYA, sempre

Non ho mai incontrato nessun essere umano felice con un tempo di caricamento della pagina di 12 secondi.

@JoeStrazzere OP ha affermato di poterlo fare davvero a buon mercato.Ecco perché sospetto che OP abbia fatto un lavoro davvero scadente nel comunicare questo problema.È solo pesce.Di solito ci si aspetta che gli appaltatori facciano le loro cose, ma i buoni appaltatori tendono a far andare meglio le cose stando in giro, quindi lo sto incoraggiando.

sì, poiché il sito non è per qualcosa come il tempo di caricamento dell'e-commerce non è fondamentale

@AlanSutherland puoi provare a pubblicare una domanda come "È accettabile un tempo di caricamento di 12 secondi per i siti Web rivolti ai non consumatori?"a ux.stackexchange.com e guarda il diluvio di odio ben citato per un tale suggerimento alimentarsi. Gli studi dimostrano (penso di aver imparato questo su ux.SE) che gli utenti si distraggono dal compito che stavano cercando di svolgere a meno diun'attesa di 10 secondi.Quindi il tuo sito web è in un certo senso letteralmente inutilizzabile al momento.

@AlanSutherland disclaimer, ho passato la maggior parte della mia carriera a sviluppare siti web b2b.E settimane ottimizzandoli da cose come 5 secondi a 2 secondi (da molto lento a lento).

hehe si lo so, è spaventosamente lento e per questo perderemo visitatori

@djechlin: L'OP ha!

@LightnessRacesinOrbit Sono d'accordo che nessun essere umano sarà felice con un tempo di caricamento di 12 secondi.La mia ipotesi è che il cliente non guarderà questo sito da solo e quindi non capisce quanto sarà problematico.

@Erik: È possibile che il cliente abbia tutte le intenzioni di risolvere questo problema, ma vuole mantenere l'OP lontano dal problema con qualsiasi mezzo necessario.Potrebbero esserci problemi politici, o OP potrebbe essere un appaltatore difficile, o qualcosa del genere.Non lo sappiamo davvero :)

@LightnessRacesinOrbit potrebbe essere.Ho sperimentato solo il primo, io stesso.

@Erik: Sì, immagino di star scherzando, ma tutto è possibile!

Dogs

2017-01-27 03:41:34 UTC

view on stackexchange narkive permalink

Dai voce alle tue preoccupazioni sulla performance. Se le prestazioni potrebbero peggiorare con l'aumentare del set di dati, assicurati che lo sappiano. Se si espandono a più uffici e hanno una latenza più elevata / un canale più lento tra di loro e le risorse, assicurati che lo sappiano. Documenta tutte le ovvie correzioni alle prestazioni. Quando scopriranno che avevi ragione, probabilmente sarai la prima persona a cui si rivolgeranno per risolvere il problema.

Non venderli più del necessario

Alla fine della giornata, sono un business. L'attivazione di alcune ottimizzazioni ragionevoli probabilmente costerà un numero elevato di ore a due cifre, e si tratta di una grossa fetta di denaro per risolvere qualcosa che con ogni probabilità non ha un impatto reale sulla loro attività in questo momento.

Una volta il programma è disponibile da un po 'di tempo e ha dimostrato di soddisfare i requisiti funzionali in modo affidabile e di risolvere le esigenze aziendali, potrebbero essere più disposti a iniziare a investire per renderlo più veloce. Quando non ci sono bug e la lamentela più grande degli utenti è che "è lento", e i manager sono stufi di sentirlo, dovresti divertirti abbastanza per renderlo più veloce.

Non credo che costerà "un numero elevato di ore a due cifre".8 mb significa che c'è qualcosa di terribilmente sbagliato e probabilmente potrebbe essere ridotto alcune volte in un paio d'ore.Inoltre, il PO ha già dichiarato di aver preparato e offerto risorse migliorate che sono state ignorate.

Preparare e distribuire manualmente le cosiddette risorse "ottimizzate" non fa bene a nessuno.La build dovrebbe ottimizzare il loro sito per loro, in modo che le ottimizzazioni siano permanenti.Realisticamente, l'implementazione, il test e il rilascio delle ottimizzazioni non sono "poche ore" di lavoro.E se fosse semplice come "qui, fammi copiare e incollare queste risorse ottimizzate per te", letteralmente nessuno nell'intero universo direbbe di no a questo.Ci sono più di poche ore di lavoro da fare, o sarebbe stato approvato, fatto e finito, e non saremmo qui seduti a rispondere a questa domanda.

DepressedDaniel

2017-01-27 10:11:48 UTC

view on stackexchange narkive permalink

Ho chiesto se potevamo almeno comprimere le immagini e minimizzare il CSS / JS ma il resto del team non è preoccupato.

Bene, ti sei avvicinato male a questo. I tempi di caricamento di 12 secondi non possono essere causati da un eccesso di CSS / JS. Avevi solo bisogno di comprimere le immagini per risolverlo, il che potrebbe richiedere solo 15 minuti, ma hai provato a intrufolarti nella minificazione CSS / JS, che è molto più lavoro perché devi modificare anche il processo di compilazione per il sito.

Fondamentalmente, sei venuto fuori come un fanatico dell'ottimizzazione, anche se è vero che il sito ha un grosso problema di prestazioni. Il tuo supervisore avrebbe dovuto avere l'intelligenza di prendere metà della tua proposta.

Proverei a lanciare un'altra proposta che riguarda solo la ricompressione delle immagini e sottolineare come il lavoro coinvolto sia minimo ma farà un mondo di differenza per l'usabilità del sito.

user42272

2017-01-26 23:06:16 UTC

view on stackexchange narkive permalink

Poiché si tratta di una produzione interna, il mio datore di lavoro è anche il cliente ed è soddisfatto del prodotto finale, quindi dovrei semplicemente dimenticare i problemi e contrassegnare il progetto come completo?

No, ovviamente no. Hai costruito un prodotto terribile e di conseguenza sei un imprenditore superfluo. Sei stato assunto per la tua esperienza nella creazione di un sito web che devi ancora utilizzare.

Non hai letteralmente pubblicato alcuna informazione su come hai tentato di sollevare questo problema , quindi ovviamente devi farlo prima che qualcuno possa aiutarti. Il dialogo è fondamentale e non ho idea se hai idea di come procedere, ma immagino che se lo facessi potresti produrre dettagli specifici di questa lotta. Quindi per favore completa la tua domanda con cosa è andato bene e cosa è andato male quando hai sollevato questa discussione e proviamo di nuovo.

Sicuramente hai più informazioni sul perché loro "non se ne preoccupavano. " Anche come appaltatore senza autorità, devi avere qualche idea sul fatto che sono tecnicamente ignoranti, sviluppano per un cliente in uno spazio dove non c'è concorrenza, hanno idee sbagliate su quanto sia costoso comprimere CSS, ecc. Se non hai idea, devi ascoltare e prestare maggiore attenzione.

Gli appaltatori fanno semplicemente le loro cose; i buoni imprenditori fanno magicamente le cose bene intorno a loro e vengono ricompensati di conseguenza. I buoni imprenditori tendono ad avere pochi percorsi di carriera: vengono convertiti a tempo pieno, i loro contratti vengono estesi a volte anche per più soldi, sviluppano un buon curriculum e buona reputazione che approda a contratti futuri. Ottenere un risultato positivo mentre manca l'autorità è solo una normale abilità aziendale, niente di più, niente di meno, e mi dispiace vedere altre risposte che scoraggiano farlo così fortemente.

Preferirei avere il tuo curriculum includere "il capo impedito di fare una scelta sbagliata nonostante la mia mancanza di autorità" alla fine che no.

questo è stato uno sforzo di squadra, il progetto è iniziato prima che io mi unissi.Ho fornito file sorgente minimizzati, immagini compresse ecc. Ma non vengono utilizzati.Ho discusso i problemi faccia a faccia, via e-mail e slack con gli altri sviluppatori di FE e BE.Cordiali saluti, il mio contratto è stato prorogato in modo così chiaro che il cliente non mi considera "superfluo" o il prodotto "terribile"

@AlanSutherland perché non gli interessa?

Non sono sicuro, non ho forzato la questione perché credo che sarebbe scortese data la mia posizione.Può essere solo il caso dello sviluppo interno che gli standard siano rilassati, il mio background è stato con agenzie i cui clienti richiedono standard elevati

@AlanSutherland "forzare il problema" sarebbe davvero scarsa capacità di dialogo.Un tempo di caricamento di 12 secondi dovrebbe essere accettabile durante la trasmissione su Marte e ritorno, ma certamente da nessuna parte sulla terra.

Risulta chiaro dalla domanda perché a loro non importa: è un'applicazione interna utilizzata dai loro dipendenti e solo dai loro dipendenti, e considerano accettabile per i loro dipendenti aspettare così a lungo.

@jmoreno che non chiarisce affatto le cose.Non fa che addensare il mistero.Il tempo di caricamento di 12 secondi è * decisamente * inaccettabile per le applicazioni interne.Soprattutto se è economico migliorare poiché l'OP è un suggerimento.Cosa sta succedendo qui dove il capo lascia scorrere un tempo di caricamento di 12 secondi?Non ne ho idea.

È improbabile che i tre suggerimenti che menziona per miglioramenti economici producano un grande miglioramento (comprimi immagini, css e js, ma dovrebbero essere tutti memorizzati nella cache dal browser).Anche se i loro dipendenti impiegano più tempo per usarlo, lo trovano accettabile.Forse non è usato molto.

Una volta ho ereditato una pagina mal progettata che restituiva più di 65 MB di HTML (non immagini, HTML) che richiedeva pochi minuti per caricarsi ** e ** impediva la pubblicazione della pagina da un server più recente.La decisione al momento era di lasciare solo quella pagina su quel server e non risolvere il problema.Non ricordo esattamente quanto tempo sia passato prima che mi fosse dato il permesso di aggiustarlo, ma gli anni sembrano giusti.Non era una priorità.

brainwash

2017-01-27 04:10:12 UTC

view on stackexchange narkive permalink

Sono in ritardo alla festa e sono d'accordo con quello che dicono tutti, ma penso che non sia sempre una buona idea lasciare le cose "come sono".

Prepara una presentazione in cui può rubare alcune diapositive che mostrano che i tempi di caricamento = meno visite = meno soldi. Puoi utilizzare uno di questi per iniziare:

https://blog.kissmetrics.com/loading-time/

https: / /moz.com/blog/how-website-speed-actually-impacts-search-ranking

Non ho verificato queste fonti ma ricordo un discorso in Google I / O dove ha mostrato che tempi di caricamento più elevati allontanano gli utenti, penso che al momento in cui hanno introdotto gli Strumenti per sviluppatori di Chrome - scheda Controllo.

In qualità di appaltatore sei anche responsabile di suggerire cose che i dipendenti interni potrebbero essere troppo annoiati per preoccuparsi ma finiscono per influenzare la reputazione e i profitti dell'azienda. Sei anche responsabile di farti ascoltare. L'azienda non ha colpa qui, semplicemente non capisce il problema.

Certo, hai fatto il tuo lavoro e puoi tornare a casa, ma se riesci a venderti in un modo migliore potresti ricevere consigli migliori , se lo fai in modo costruttivo.

Penso che ti sei perso era un prodotto interno.Quindi il tuo argomento è leggermente fuori posto.

In-house non significa che non sia pubblicamente visibile.L'OP ha scritto "sito web aziendale", quindi presumo che sia l'interfaccia per i loro clienti.Tuttavia, resto ancora sul fatto che se SAPETE qualcosa è giusto, dovreste spingere per ottenerla.Ho avuto problemi simili con sicurezza, prestazioni, flessibilità e alla fine si è dimostrato utile e tutti ne hanno visto i vantaggi, anche se è stata una battaglia in salita.

Ha detto che "il datore di lavoro è anche il cliente", ma sì, sono d'accordo a spingerlo comunque.

@FrançoisGautier ha dichiarato nei commenti (ora rimossi) che il sito web è pubblico.Progetto interno significa semplicemente che l'azienda ha sviluppato il proprio sito Web, non che sia un sito per uso interno.

Džuris

2017-01-27 05:29:53 UTC

view on stackexchange narkive permalink

Se qualcuno si accontenta di una pagina che carica 12 secondi, si sbaglia.

Sii schietto e dì al tuo capo, ai colleghi o a chiunque altro che queste dimensioni e il tempo di caricamento sono completamente inaccettabili e che a quanto pare non hanno la competenza per giudicare cose del genere. Di 'loro che sei un professionista ed è la tua conclusione professionale che questo progetto non è stato completato e c'è più ottimizzazione su cui lavorare.

Spiega che tale tempo di caricamento è un danno per l'esperienza degli utenti e rendere il sito Web inutilizzabile per lo scopo originale (per servire [..inserire qui ..] al pubblico). Spiega che è la tua opinione professionale che il sito web è inutile e deve essere ottimizzato.

Rivolgersi a chi parlava di te come imprenditore ...

Nel giorno in cui Michelangelo è stato assunto dipingere il soffitto della Cappella Sistina. Immagina che il suo capo gli dica "Ehi Mike, i lavoratori qui hanno già disegnato un paio di santi, devi solo fare alcuni ritocchi finali e firmare il tuo nome ... non preoccuparti troppo, va bene così com'è! Ignora il mano a tre dita di Gesù, finiamo il progetto e andiamo avanti ". Ovviamente Mike non sarebbe d'accordo. Non so come sia andata ma so che ha trascorso 4 anni a dipingere lì e ha tenuto il suo lavoro all'altezza.

Ora immagina te stesso. Supponi di dover cercare presto un nuovo lavoro. Come andrà il colloquio?

- Puoi mostrare il lavoro che hai fatto?

- Ah beh, era principalmente su progetti interni o non pubblici. Bene, avevamo il sito web dell'azienda.

- Certo, mostralo!

- Ah, ma devo dirti che non è ancora ottimizzato ...

- Eppure? Sembra uscito dal 2006. Aspetta, si sta ancora caricando? Perché diavolo è così spaventosamente lento?

- Beh, uh ... Sapete, i miei colleghi, a loro non importava molto dell'ottimizzazione ... Il capo era soddisfatto e ha detto che avremmo dovuto passa al progetto successivo ...

Nota: potresti anche essere licenziato seguendo il mio consiglio e ti farai sicuramente dei nemici, ma è quello che farei io. Spiegherei che gli altri non hanno la più pallida idea di come dovrebbe essere fatto e dovrei assumere la guida di questo progetto. Non sono mai stato licenziato o punito per cose del genere. Potresti anche ottenere un po 'di rispetto :)

Non credo che mostrare il capo guadagnerebbe rispetto all'OP ...

L'effettivo utilizzo finale della pagina web deve essere preso in considerazione qui.Hai ragione che il caricamento lento sarebbe "spaventoso" per un sito web rivolto al pubblico in cui la perdita di spettatori significa perdita di entrate.Ma questo era interno.I dipendenti sono PAGATI per utilizzare la pagina web.I responsabili hanno deciso di non spendere altri soldi per l'ottimizzazione dell'appaltatore.Va bene, è così che funzionano le applicazioni software "aziendali". Hai mai utilizzato "Enterprise Business Suite" di Oracle?Non farlo.Qualcuno come te avrebbe un attacco di cuore.

@teego1967 In realtà sei abbastanza sul punto, sono in rapporti di odio reciproco con quel capolavoro di Oracle.Ma penso che tu abbia perso una cosa (e assumendo il contrario) - OP ha dichiarato nei commenti che il sito è ** pubblico non interno **.