PM ha optato per una configurazione troppo complessa che nessuno ha esperienza con [chiuso]

Di recente ho avviato un progetto che non sembrava troppo difficile da realizzare, il concetto era un'applicazione abbastanza semplice che doveva accettare input ogni tanto (forse 10 volte al giorno), e provare a eseguire alcune operazioni su di essi e raccogliere tutti i risultati alla fine. Questa applicazione otterrebbe quindi un portale Web front-end che i clienti potrebbero utilizzare per visualizzare i risultati, non esattamente la scienza missilistica.

Per questo inizialmente ho fatto un uso intelligente delle librerie di concorrenza integrate di Python ( ThreadPoolExecutor) e ho usato una libreria di facile utilizzo per il front-end (ho scelto Flask perché è facile per i principianti ed è relativamente facile da mantenere e testare).

Una volta a metà del progetto, il PM ha dichiarato che dovevamo utilizzare le funzionalità di coda dei messaggi di terze parti anziché i thread e che dovevamo implementare il bilanciamento del carico, ciò che alla fine è accaduto è che alla fine abbiamo iniziato a lavorare con Celery, Redis, RabbitMQ, Nginx, uWSGI e un sacco di altri grandi servizi di terze parti con cui nessuno ha avuto alcuna esperienza reale.

Alla fine questo ha portato a un sacco di spaghetti code, compiti non verificabili (a causa della complessità delle librerie di terze parti, l'applicazione di patch al codice non funzionava nemmeno) e un sacco di mal di testa perché nessuno sapeva nemmeno quale fosse il valore aggiunto di questi servizi .

Prima di dire "Sì, dovresti usare quei servizi", tieni presente che nessuno sa come usarli o sa anche cosa fanno oltre a introdurre il codice afflitto dalle condizioni di gara.

Cosa dovrei fare al riguardo? A questo punto sarebbe semplicemente troppo costoso tornare a quello che avevamo e il PM è impegnato a utilizzare questi servizi, anche se il prodotto finale è ora peggio di quanto non fosse all'inizio. C'è qualche utilità nel discuterne con lui? Chiedo più tempo? O la dura risposta, sono semplicemente troppo stupido per il mio lavoro?

Una volta a metà del progetto, il PM ha dichiarato che dovevamo utilizzare le funzionalità di coda dei messaggi di terze parti anziché i thread e abbiamo dovuto implementare il bilanciamento del carico

Questa non è una cosa appropriata per un PM per "dichiarare" unilateralmente. Due motivi:

1. Le decisioni di progettazione dovrebbero essere prese da una risorsa tecnica e solo in risposta agli NFR . Quindi, cortesemente, chiedi al tuo PM se c'è un nuovo NFR e se per favore potresti avere dettagli.

2. Se un NFR viene introdotto a metà del progetto, probabilmente dovrebbe essere fatto tramite un controllo delle modifiche . Il controllo delle modifiche è molto importante dal punto di vista della governance; sarebbe non solo un input per le vostre esigenze, ma è anche un input importante per i casi di test del QA, la distribuzione delle operazioni e il manuale di supporto e (qui è la parte davvero importante) il programma del PM . Se il nuovo requisito introduce più lavoro, il team di sviluppo dovrebbe avere l'opportunità di comunicare nuove stime di sviluppo e il PM dovrà decidere se può convivere con la nuova data, aggiungere più risorse o respingere gli stakeholder che hanno introdotto l'NFR.

Ora, se esiste davvero un NFR in buona fede e non c'è modo di aggirarlo, potrebbe anche essere appropriato richiedere risorse nuove o diverse che abbiano familiarità con le tecnologie che vengono introdotte o richiedere un budget di formazione per alcuni dei tuoi esistenti risorse. Quindi c'è anche un aspetto di costo .

Se parli la lingua del PM - programma e costi - penso che otterrai più trazione che parlare di come gli sviluppatori si sentono sul design risultante. Quelle cose hanno un impatto reale.

Un PM dovrebbe conoscere meglio che introdurre cose come questa al volo senza governance, senza controlli e senza consenso. Se semplicemente non lo capiscono, potrebbe essere necessario passare alla gestione dei prodotti o alla gestione dei programmi, poiché sta mettendo a rischio inutilmente la qualità e la pianificazione.

Quello che sarebbe stupido è lasciarsi marciare la morte .

Quello che stai descrivendo è che hai perso la sensazione critica. Non c'è alcun senso di controllo e nessun modo chiaro per tornare ad esso.

L'ultima cosa che dovresti fare è lavorare sodo, tenere la testa bassa e soffrire piano fino a quando non ammettono finalmente che il progetto è destinato.

Quello che dovresti fare è pensare molto a ciò che hai ogni diritto di aspettarti.

Se vogliono che tu usi tecnologie che non capisci, dovresti aspettarti del tempo per impararle. Non vergognarti di ciò che non sai. Usa la tua ignoranza come un randello. Quando ti chiedono di usare qualcosa, chiedi perché. Non accettare "perché". Non accettare le "migliori pratiche moderne". Non accettare le "capacità di scala" senza ottenere aspettative reali, verificabili.

Per testamento intendo che DEVONO dirti quante richieste al giorno / ora / minuto vogliono che sia in grado di fare. Chiarisci che intendi costruire qualcosa per esercitare questo sistema in base a tali specifiche.

In questo modo puoi utilizzare una prova gratuita di 30 giorni per dimostrare che vale l'ultima cosa che vogliono wiz bang o se stai meglio attenendoti a ciò che già sai.

Ora tieni a mente. Non sono gli strumenti che hanno introdotto il codice afflitto dalle condizioni di gara. Ragazzi l'hai fatto. Devi imparare COME l'hai fatto in modo da poterlo annullare.

E no. Non è troppo costoso tornare a quello che avevi. Il Primo Ministro non può avere ciò che vuole solo chiedendolo. Devi respingere finché non puoi utilizzare efficacemente ciò che il PM desidera o dimostrare che non è ciò di cui il progetto ha bisogno.

Seriamente, arrendersi a questo è poco professionale e mortale per il progetto.

Sono stato qui amico. Più di una volta Ti fa sentire stupido. Non è proprio così. Ti sei appena perso.

Parla con il Primo Ministro. Onestamente. Disporre tutto. Mostra che sei disposto a imparare ma non vuoi essere preso in giro. Mai e poi mai progettato o codice basato sulla fede. Fai in modo che il PM ti mostri come fare ciò che vogliono. Non far finta di capire quando non lo fai. Non dire che sarà fatto quando non lo farà. Se hai intenzione di credere in qualcosa, credi in te stesso. Devi essere disposto a dire NO.

Se il problema persiste, ripristina il curriculum perché ne avrai bisogno presto. In un modo o nell'altro.

Questo dovrebbe davvero essere su workplace.stackexchange.com, perché il problema non è in realtà una domanda di sviluppo software, ma sulle relazioni sul posto di lavoro.

Se sei sicuro che il tuo approccio semplice avrebbe funzionato e prodotto un risultato di lavoro piuttosto rapidamente, allora il tuo PM è una forza distruttiva nella tua azienda che dovrebbe essere rimossa. Scopri come portare la notizia al di sopra di lui: che la tua squadra aveva una soluzione semplice e funzionante che aveva fatto buoni progressi e per motivi che nessuno può spiegare al tuo PM ti ha costretto a tentare una soluzione molto più complessa, usando una moltitudine di strumenti che nessuno conosce, nessuno capisce, nessuno sa se sono utili e quella decisione insondabile del tuo PM ti ha causato tutti i problemi e ha causato il ritardo del progetto e il mancato funzionamento.

Non conoscendo il contesto e la strategia di prodotto perseguita dalla direzione, è difficile rispondere obiettivamente alla domanda.

Ecco alcuni argomenti oggettivi. È comunque possibile che non sia quello che ti aspettavi:

• " Tenete a mente che nessuno sa come usare questi prodotti ancora ".
• L'uso esclusivo di strumenti e tecniche perfettamente conosciuti garantirà un'elevata produttività. Ma limiterà considerevolmente la capacità di innovare. In alcuni mercati, potrebbe essere fatale per il tuo prodotto. Ad esempio, quasi 30 anni fa, ho proposto di utilizzare Windows 3.0 per sviluppare una nuova versione di un prodotto CAD con esito positivo in MS-DOS. Il product manager ha obiettato che questo non era un ambiente comprovato, che sarebbe troppo complesso e troppo difficile da imparare per il team e, comunque, che " Windows non sarà mai un ambiente tradizionale " ... Ti faccio indovinare il successo di il suo prodotto 2 anni dopo.
• È tutta una questione di costi e benefici. Il costo della sperimentazione rispetto al vantaggio di una scalabilità e implementabilità assicurato da una terza parte che ha esperienza con installazioni enormi e carico di lavoro pesante.
• Gli svantaggi dell'aggiunta di una nuova tecnologia possono essere attenuati, con l'adeguata formazione o il supporto / coaching iniziale da un consulente esperto.

In definitiva, la scelta economica è responsabilità del responsabile del prodotto. Discutere con lui i pro e i contro, per assicurarsi che prenda una decisione ben informata e non sottovaluti la complessità aggiunta. E se rimane sulla sua strada, cerca di ottenere il meglio: non hai nulla da perdere e, nel peggiore dei casi, avrai una nuova tecnologia nel tuo CV.

Esistono due approcci alle librerie di terze parti (e altri componenti):

1. Usane il maggior numero possibile
2. Usane il minor numero possibile

Il mio approccio è (2). Sembra che anche il tuo approccio sia (2), ma al project manager piace l'approccio (1).

Esistono tre modi per gestire questa situazione. O lasci che il PM faccia quello che vuole il PM, cerchi di convincere il PM a cambiare l'approccio alle biblioteche di terze parti, oppure voti con i piedi e selezioni un altro lavoro.

Se vuoi convincere il Primo Ministro a cambiare approccio, considera questi argomenti:

• È tempo di imparare. Ogni libreria esterna richiede tempo per l'apprendimento, quando un programmatore competente può scrivere la funzionalità desiderata, specialmente se una vasta libreria è stata scelta solo per fare una cosa molto semplice che potrebbe essere fatta in poche centinaia di righe di codice.
• Sostituibilità.Se disponi di una libreria esterna, come puoi assicurarti che se il suo sviluppo viene interrotto, puoi sostituirlo con un'altra libreria simile? La mia soluzione è quella di evitare le librerie esterne ogni volta che posso e ogni volta che non è possibile, scrivo un semplice wrapper per astrarre la parte dell'interfaccia di programmazione che desidero. Di solito l'interfaccia che desidero è molto più semplice dell'interfaccia offerta dalla libreria. Quindi il mio codice accede alla libreria esterna solo attraverso questo wrapper, facilitando le sostituzioni. Costruire l'intera applicazione su un framework è un grande no-no. Servlet? Sì, sono qui da molto tempo e continuano ad essere qui per il prossimo futuro. Motori template? Sì, anche se non sono esattamente sostituibili (di solito ne scegli uno e rimani con quello), il valore che apportano è enorme, quindi seleziona con attenzione - e tieni presente che quando cambi i template engine, puoi avere due template engine nella stessa applicazione ma di solito non puoi avere due framework nella stessa applicazione. Apache Struts? No, i framework vengono di moda e passano rapidamente di moda, e di solito non è possibile avere due framework nella stessa applicazione.
• Versione inferno. Selezionando una libreria esterna, è necessario aggiornarla per evitare vulnerabilità della sicurezza e aggiornarla potrebbe rompere le cose. I componenti ben progettati (come Java JRE) sono compatibili con diverse versioni, ma la mia esperienza è che la maggior parte delle librerie è una schifezza a causa dell'imponente inferno della versione. Inoltre, il componente X potrebbe richiedere Z versione 1 e il componente Y potrebbe richiedere Z versione 2 e potrebbe non essere possibile collegare Z versione 1 e Z versione 2 nella stessa applicazione.
• Vulnerabilità di sicurezza. Selezionando una libreria esterna, aumenta il numero di vulnerabilità della sicurezza facilmente sfruttabili rispetto all'applicazione. Alcuni potrebbero sostenere che il codice sviluppato internamente assomigli alla sicurezza attraverso l'oscurità, ma poi direi che è ancora una forma di sicurezza.
• Problemi di licenza. Ogni libreria esterna impone la propria licenza su parti del programma. Ad esempio, le librerie GPL non possono essere utilizzate in programmi non GPL e anche le librerie LGPL richiedono la distribuzione del codice sorgente insieme ai binari, il che può richiedere notevoli quantità di larghezza di banda.
• Tempo di avvio dell'applicazione. Ogni grande libreria esterna rallenta il tempo di avvio dell'applicazione. Scrivendo una libreria semplice e snella internamente, è possibile velocizzare molto il tempo di avvio dell'applicazione.
• Impronta di memoria. Avendo X che richiede Y che richiede Z che richiede A che richiede B, è necessario contemporaneamente X + Y + Z + A + B nella memoria. Implementando solo l'equivalente di X, chiamiamolo X ', internamente, hai solo bisogno di X' nella memoria. E di solito l'impronta di memoria di X 'è inferiore all'impronta di memoria di X.
• Rischio di bug. Più righe ci sono nel componente esterno, maggiore è il rischio che si verifichi un bug che sarà difficile da correggere a causa dell'enorme quantità di codice che è necessario comprendere. Se lo fai internamente, di solito lo fai con meno righe di codice (per fare esattamente ciò di cui hai bisogno, nient'altro) e, quindi, un minore rischio di bug.
• Personalizzazione. Se scrivo query SQL da solo, so come appare la query e quanto bene si comporta su un determinato motore di database e dato set di indici. Se, d'altra parte, la query SQL è scritta da un componente esterno, non so nulla delle sue prestazioni. Lavoravo in un'azienda in cui ogni pagina web impiegava diversi secondi per essere recuperata. Sospettavo che la causa fosse la libreria Hibernate che usavano recuperare automaticamente troppi dati dal database quando tutto ciò di cui avevi bisogno era un oggetto e non tutti gli elementi relativi a questo particolare elemento. Ho lasciato l'azienda prima di scoprire la vera causa della lentezza, perché non mi piaceva l'approccio all'uso di un numero enorme di librerie esistenti.

Fai attenzione soprattutto se una libreria si definisce un framework . Ciò significa che la libreria richiede di costruire l'intera applicazione su se stessa. In genere non è possibile avere due framework nella stessa applicazione; combatteranno tra loro senza coesistere pacificamente. Libreria di utilità di sviluppo Web? Sì, per favore, ce ne sono troppo pochi. Se trovo mai una libreria migliore di quella che uso ora, posso usare la nuova libreria trovata nel nuovo codice continuando a usare la vecchia libreria nel vecchio codice. Framework di sviluppo Web? Un grande clacson NO!

Penso che il tuo PM miri a un sistema difficile da gestire che produrrà molti lavori di manutenzione mentre è attivo, quindi ti garantirà le tue entrate.

Personalmente, sembra che tu sia bloccato con Python, dimentica Python per un po ', non scrivere codice in Python per un anno, imparare cose nuove, vedrai che ci sono altre lingue che possono fare lo stesso, e probabilmente meglio.

Come altri hanno già detto, impara gli strumenti prima di iniziare a scrivere codice con loro. Forse suggerirebbe che sarebbe utile valutare insieme lo stack necessario, basandosi sulla ricerca di diversi strumenti che sembrano adatti all'attività. O forse chiedere come è arrivato a quella lista, avrebbe potuto avere l'aiuto di qualcuno che è aggiornato.

Gli sviluppatori non dovrebbero aver paura di imparare a usare nuove librerie, framework, tecnologie, ecc. Questa è una parte fondamentale della descrizione del lavoro di uno sviluppatore ed è perfettamente ragionevole per qualcuno suggerire che il team lavori con cose di terzi che nessuno ha esperienza con, o addirittura richiedere che il team lo faccia se sono in grado di prendere decisioni tecniche autorevoli per il team.

Tuttavia, non è ragionevole aspettarsi che tu possa semplicemente estrarre una nuova tecnologia (e tanto meno diverse nuove tecnologie contemporaneamente) nel tuo stack e continua a fare progressi. Tempo significativo avrebbe dovuto essere programmato per apprendere i dettagli del nuovo approccio e capire un buon design per incorporare i nuovi pezzi, durante i quali non ci si aspetterebbe progressi reali sul prodotto reale (dalle persone che fanno questo lavoro di apprendimento / progettazione , che può essere o meno l'intero team, anche se in caso contrario è necessario che ci sia più tempo programmato lungo la strada per le persone che hanno imparato a trasferire le conoscenze al resto del team). Questo è il costo per apportare questo tipo di grande cambiamento. L'apprendimento di nuove tecnologie fa parte del lavoro dello sviluppatore, ma non è qualcosa che accade solo con un costo a tempo zero.

Sembra che non sia successo dalla domanda. Le persone si sono immerse nel tentativo di realizzare in qualche modo buone implementazioni su tecnologie che loro stessi non capivano. Naturalmente il codice risultante è terribile.

Cerca di convincere il tuo Primo Ministro che la società dovrà dedicare più tempo a questo. O arriverà ora sotto forma di arresto, apprendimento e valutazione delle nuove tecnologie, elaborazione di una buona progettazione e pulizia dell'attuale pasticcio di implementazione. O arriverà sotto forma di più tempo sprecato in bug, manutenzione, sviluppo più costoso, ecc.

È impossibile stabilire se le scelte tecniche descritte nella domanda (bilanciamento del carico, code dei messaggi, ecc.) Siano effettivamente appropriate. Non credo che "nessuno del team ha esperienza di lavoro con questo prima" è un buon motivo per escludere assolutamente una decisione, ma lo fa aumentare il costo di breve periodo di prendere questa decisione (che possono alterare la " migliore "decisione per il contesto), e se il tuo PM non lo sta prendendo in considerazione e si aspetta che la squadra diventi immediatamente produttiva come lo sarebbero le persone esperte, allora dovresti respingere per questi motivi; stabiliranno programmi di progetto altamente irrealistici, che non sono nel migliore interesse di nessuno.