ElectroYou

Per me va bene. Non c'è alcuna fretta. Il progetto o i progetti d'esempio possono partire su qualsiasi sezione del forum. Se la cosa procede bene si trasferisce tutto in una nuova sezione dedicata.

Ieri ho chiesto a Steve come si deve fare per creare un gruppo di lavoro efficiente (mentre eravamo a pranzo) perché so bene quanto se ne intenda di organizzazione.
Mi ha anticipato qualcosa ma, molto gentilmente, mi ha invitato nel suo ufficio per qualche breve consiglio stasera, dopo l'orario di lavoro.

Se interessa posso postare quanto mi dirà.
Nella speranza di essere utile.

Ciao,
Pietro.

PS: maaaa.... una curiosità... i fisici possono far parte di un gruppo di progettisti?

Pietro, con la prima frase hai attirato la mia curiosità.
Con la seconda hai la mia completa attenzione.

A me l'idea piace molto , bravo brabus, ultimamente sei un vulcano !

Io partecipo più che volentieri anche se so bene che per sviluppare progetti elettronicamente un minimo complicati le mie conoscenze non sono sufficienti.
Una mano effettivamente più valida potrei darla per quel che riguarda il lato pratico, dalla costruzione delle schede prototipali ai vari inscatolamenti (se necessari) al disegno e realizzazione di particolari meccanici per dare ai progetti una veste il più professionale possibile.
Anche se si tratta di aspetti marginali più costruisco circuiti più mi rendo conto che poi alla fine per passare da un bel progetto ad una bella realizzazione di strada da fare ne rimane.

Ho sempre sperato che prima o poi questa comunità trovasse la strada per riuscire a collaborare in progetti che andassero oltre il "semplice" hobbie. Vedendo il livello e le diverse caratteristiche di chi partecipa direi che i presupposti per far qualcosa di buono ci siano tutti... per me non resta che provarci !

Allora, eccomi arrivato al mio momento serale per me stesso, grazie al quale posso relazionarvi circa i consigli che ho avuto.
C'è molta roba (ma ho preso appunti, he he he) e spero di riuscire a rendere il tutto con precisione. Ci provo.

Premetto che, come è ovvio che sia, questi consigli che ho ricevuto, seppur provenienti da una persona con una esperienza ventennale di direzione di una squadra tecnica, sono... consigli.
Siamo quindi liberi di seguirli o no, in tutto o in parte. Nessuno si deve (ci mancherebbe) sentirsi vincolato.

Dopo aver spiegato brevemente quello che vorremmo fare mi sono stati spiegati dei passi, ognuno dei quali va progettato, cioè pensato con attenzione e per il quale va prodotta documentazione (di cui parleremo dopo).
Capisco che possa essere noioso ma è indispensabile.
La prima frase che mi è stata detta mi ha subito ricordato una frase scritta da DarwinNE: dell'organizzazione nella progettazione non se ne capisce il bisogno (e soprattutto perché va fatta così) finché non ci si rende conto che questo modus operandi è essenziale.

Come prima cosa bisogna decidere di cosa ci occuperemo: la risposta "tutto, abbiamo esperti per tutto" oppure "di circuiti hobbistici" oppure "di tutto quello ci frulla per la testa seppur ragionevole" non va bene. Non è possibile progettare dal circuito in alta frequenza al circuito di elettronica di potenza e dal microcontrollore al circuito unicamente analogico.
Una azienda grande ha un suo settore di interesse, non progetta di tutto.
Dobbiamo decidere di stare dentro un quadrato, che all'inizio deve essere molto modesto perché il problema iniziale è creare la squadra, non i progetti, e per questo serve tempo, molto più di quello che potremmo mai immaginare.
All'inizio dobbiamo scegliere progetti semplici e vedere come si comporta la squadra e modularla in funzione delle sue caratteristiche.
Con il tempo si potrà poi allargare il quadrato verso i progetti più complessi e che quindi richiedono una più stretta collaborazione tra le diverse competenze.
Il primo progetto è la squadra, non il circuito.

Un altro errore grossolano è quello di creare una squadra ad hoc per il progetto che poi si cambia al cambiare del progetto. Così faremmo solo casino.
Bisogna creare sottosquadre specializzate per i diversi argomenti, dentro le quali si segue anche una gerarchia (abbiamo persone a sufficienza, ma esistono squadre di anche solo due persone che seguono comunque una struttura scalabile e pronta all'espansione).
All'interno del design team ci va un gruppo che si occupi di analogica, uno di digitale, uno di bassa frequenza, uno di potenza, uno di alta frequenza ecc. ecc... e non il gruppo "progetti semplici" o "progetti con il Pierin", perché cosa sia un progetto semplice non lo sa nessuno e un progetto col Pierin può spaziare anche sull'analogica o sull'alta frequenza.
All'inizio ci potrebbero essere anche solo i due o tre gruppi fondamentali(es. il gruppo di analogica, il gruppo di digitale e il gruppo di sviluppo firmware/software), che col tempo e col crescere delle esigenze potrebbero aumentare (per esempio col tempo nasce il gruppo di bassa frequenza e il gruppo di potenza dal gruppo di analogica e il gruppo di PIC e di ARM dal gruppo di digitale).
Il trucco è di pensare in grande (cioè in modo scalabile) fin da subito, ma con modestia (chi parte a razzo finisce a c...) facendo piccoli progetti con l'obiettivo di creare la squadra e non il progetto.
Pensare in modo scalabile significa che dobbiamo costruire una struttura che possa espandersi nel tempo senza dover essere ripensata man mano che cresce.

Quindi:
Creare una squadra di progettazione è un progetto molto impegnativo senza il quale il team non può lavorare. E' come costruire un circuito indispensabile che andrà a far parte degli strumenti di laboratorio. Se l'alimentatore da laboratorio funziona male ogni circuito avrà dei problemi. Ogni progetto (se finirà) richiederà un tempo eccessivo di sviluppo e produrrà risultati scarsi, a fronte di un impegno immenso. Avremo cioè una efficienza che fa pena, con conseguente surriscaldamento di tutti i componenti (arrabbiature!)
Ognuno deve avere il suo ruolo, soprattutto per impegnarsi in diversi progetti contemporaneamente, cosa che è richiesta ad un gruppo avviato. Nessun progetto deve essere troppo semplice e quindi fatto fare da un gruppo non preposto al suo sviluppo.
Facciamo un esempio estremizzato: stiamo portando avanti 3 progetti per i quali il gruppo di elettronica di potenza si trova a dover fare tre alimentatori. Il primo richiede un LM 317, il secondo è un inverter di una certa potenza e il terzo è un flyback. L'errore è delegare l'LM317 (di cui il gruppo di elettronica di potenza conosce cose che magari gli altri non sanno, per quanto possa sembrare strano) al gruppo, per esempio, di digitale ("è semplice, ce lo facciamo da noi") perché questo distoglie attenzione dalle cose di cui si occupa il gruppo di digitale facendo perdere tempo al gruppo di digitale e al gruppo di potenza ("voi sapete perché stavolta non va? di solito funzionava sempre..."), mentre non ne toglierebbe al gruppo di elettronica di potenza se lo avesse fatto da subito ("a fronte delle richieste di corrente che avete usate l'alimentatore ad LM317 che abbiamo già progettato per il circuito XXX"). Al gruppo di potenza una cosa del genere richiede pochissimo tempo, che è tempo ottimizzato per tutti.
In pratica questo è un consiglio svolto a sfruttare gli esperti di un settore sempre, comunque e dovunque.
Un'altra conseguenza non ovvia di questo modo di pensare è che più si va avanti nel progetto e più è difficile e costoso correggere gli errori. Se si scopre che il progetto con l'LM 317 funzionicchia, ma non è affidabile, quando sono stati venduti da EY 1000 kit (e non lo si è scoperto prima perché più o meno andava) e succede, come conseguenza di questo difetto, che su anche solo il 30% dei kit si è bruciato il Pierin, chi ha costruito il kit (acquistandolo) chiederà che gli venga mandato un Pierin gratis. Sapendo che un Pierin costa indicativamente 15€, abbiamo creato un guaio che costa 4500€.
4500€ non è forse molto per EY, chissà, ma ricordiamoci che è stato creato da un LM317
Questo, quando succede, nelle ditte, ha come conseguenza l'immediata ricerca del responsabile.
Se è stato progettato dal gruppo di digitale che però ha chiesto consiglio al gruppo di potenza succede che i due gruppi si faranno la guerra scaricandosi il barile l'un l'altro. Che casino! E sempre per un misero LM 317
Notate che ho solo considerato le spese relative al Pierin bruciato e non quelle relative alla patch del kit malfunzionante, che ovviamente andrà implementata non per 300 ma per 1000 kit ("cosa ce ne facciamo adesso di quei 3000 PCB sbagliati che abbiamo fatto produrre? Per la patch possiamo dare delle istruzioni o è troppo complicata e dobbiamo ritirare tutte le schede indietro?")
Per quando semplice possa essere il circuito, l'alimentatore a LM317 va fatto progettare a chi lo sa fare davvero. In qualunque ditta l'ultima cosa che interessa a tutti è quanto possa essere semplice da progettare quello specifico circuito. A tutti interessa mandarlo al gruppo giusto (che è l'unico al quale interessa la difficoltà del circuito, ma per ben altri motivi...)

Adesso vado a dormire, domani parlerò del secondo aspetto importante.
L'organizzazione all'interno dei gruppi e la documentazione.

'notte.
Pietro.

Grazie Pietro.

Ho cercato di scorgere i dettagli in quanto scrivi, e mi trovi, ovviamente, in pieno accordo su tutto.

Questa esperienza va vista anche come palestra per il nostro team; se la gestione sarà corretta potremo davvero portare avanti l'idea senza trasformarla in un lavoro vero e proprio.

Non dimentichiamo infatti che la natura libera e spontanea che regna nel forum deve essere rispettata, altrimenti dovremmo assumere gente e pagarla (giustamente).
Dunque prima di parlare di kit (e di soldi) dovrà passarne di acqua sotto ai ponti...
In ogni caso dovremo stabilire accuratamente le condizioni del servizio, le garanzie, le responsabilità, etc. E' l'unico modo di evitare brutte sorprese, che alla fine scottano e lasciano con la solita frase in bocca: "Ma perché non ci abbiamo pensato prima!?!". True story!

1) In merito alla complessità del progetti: se un progetto naufraga perché è diventato troppo impegnativo... beh pazienza, il target doveva essere più realistico. Tutto contribuisce a perfezionare le nostre abilità di leader, ovviamente a patto di essere ben disposti a trarre insegnamento dai fatti.
Per questo, ancora una volta, ribadisco il concetto che anche tu hai espresso: partiamo con qualcosa di piccolo.

2) Progettazione della progettazione: tema storico, che ha animato le discussioni con i miei colleghi in parecchie serate. Stesse conclusioni, mi trovi in accordo pieno. Ottima l'idea di creare team dedicati: gli analogici, i digitali, gli RF, i firmwaristi, etc.

3) Scalabilità in primis. Più o meno siamo tutti "di passaggio" nel forum, dunque dovremo fronteggiare nuovi arrivi e abbandoni: è normale. Direi di evitare di assegnare incarichi troppo specifici e gravosi, col rischio di avere un single point of failure nel team.

4) Documentazione. Io ero progettista, di quelli col saldatore sempre in mano e le carte dappertutto. Lo ero due anni fa, oggi mi occupo di tutt'altro, e ho davvero scoperto l'importanza di una frase in più o in meno in un documento. A dirla tutta, è mia responsabilità decidere se la frase vada messa o no, e all'inizio non ci dormivo la notte. Oltre ad essere di vitale importanza per il progetto, la documentazione costituisce poi il database del nostro know how, e (se ben fatta) diventa una miniera di soluzioni che semplificano notevolmente il lavoro nei progetti futuri. Mi interesso particolarmente agli aspetti di validazione della documentazione, spesso trascurati.

Sono davvero curioso di leggere le tue prossime righe.

Ti ringrazio davvero.
Questa mattina ho dovuto tenere la bambina perché mia moglie non c'era, quindi non potevo mettermi a scrivere. Adesso che mia moglie è arrivata facciamo pranzo e poi c'è l'appuntamento settimanale delle pulizie di casa, quindi, finalmente, avrò un po' di tempo per scrivere.

Bear with me

Ciao,
Pietro.

Eccomi!
Parliamo quindi ora della organizzazione all'interno dei vari gruppi.

Si segue una (a me finora sconosciuta) teoria strana chiamata PAEI, che è l'acronimo di Producer, Administrator, Entrepreneur, Integrator (o Interoperative).
Ogni figura PAEI è presente all'interno di un gruppo o se i gruppi sono troppo piccoli è presente all'interno di un cluster di gruppi affini (es. potenza e analogica o ARM e digitale)
Vediamo cosa fanno le varie figure nei gruppi.
P: Producer. Ovvero partiamo dalla fine. Finalmente abbiamo un progetto e pensiamo che possa funzionare! Chi ne costruisce un prototipo su millefori? Chi lo testa? Chi evidenzia problemi di misure sul PCB? Il Producer! (o i producer) Egli/loro è/sono esperto/i di testability (e alle volte curiosando ho visto documentati dei difetti che non avrei mai immaginato ci potessero essere...). E' un tecnico di laboratorio esperto che fa gran parte del lavoro manuale e documenta difetti ed errori che si possono notare solo avendo un prototipo in mano. Non ha affatto un compito banale. Se ci sono più tecnici che lavorano insieme si elegge un referente, di solito il più esperto. Ovviamente è specializzato nella costruzione e nella testabilità dei circuiti di cui si occupa il gruppo (un P di alta frequenza ha delle competenze molto diverse da un P di bassa frequenza, per esempio).
A: Administrator. Gli amministratori di un progetto (o meglio della parte del progetto che spetta a quel gruppo) sono coloro che lo coordinano dal punto di vista organizzativo. Si preoccupano di stabilire quanto tempo allocare (es. LM317: 2 ore, Flyback: 1 settimana) e quante risorse destinare ai vari progetti che il gruppo deve portare avanti. Si preoccupano di trovare i fondi (interni, esterni, sponsorizzati ecc...), di destinarli, di studiare il prezzo che può avere un kit e quando sia il momento giusto per proporlo. Il più esperto è un dirigente. In genere si relaziona spesso con il senior design engineer, di cui parlo al punto seguente.
E: Entrepreneur. Questo è il settore che, nel mio piccolo, conosco meglio. Nelle ditte gli E vengono anche chiamati TC: Technical Core. Sono i progettisti, coloro che studiano le specifiche di un sistema, ne trovano la soluzione tecnica e la progettano, quelli che pensano il circuito, i creativi. I più matti, insomma (ma si divertono taaanto) . Il progettista capo è di gran lunga la figura più importante di tutto il gruppo; è il "Chief" senior design engineer. In genere è un ingegnere con esperienza ventennale o giù di lì. Purtroppo (per coloro che gli sono sottoposti) è una delle figure più importanti e meglio pagate di tutta l'azienda, ha il compito di supervisionare i progetti dal punto di vista tecnico e controllare che funzionino perfettamente (soprattutto il proprio, pensano tutti...e poi, no, non gli scappa mai nulla...). Ogni tanto i vari progetti sono sottoposti a design review, un martirio meeting dove il senior design engineer valuta dal punto di vista critico gli schemi elettrici prodotti, non risparmiandosi gentili critiche costruttive ("questo schema lo butti nel cesso, va bene?? Non funziona, vedi, il transitor TR1..."). Tuttavia durante una riunione di questo tipo si discute sul progetto e chiunque può costruttivamente intervenire. L'obiettivo teorico finale è avere un progetto insensibile a qualunque tipo di malfunzionamento.
Le regole del gioco sono che ciò che viene deciso in design review non si cambia fino alla prossima design review, altrimenti è il caos. (se poi emerge un problema particolarmente importante si schedula un'altra design review, ma è l'eccezione. In questo modo si ha l'intero gruppo di tecnici che pensa allo stesso tavolo concentrandosi sul problema. Si prendono delle decisioni operative e poi, finita la riunione, si lavora per eseguirle). Sono davvero utili.
In genere i senior design engineer e gli administrator dei vari gruppi si riuniscono in privato, ad inizio progetto, per stabilire quanto si voglia fare, le specifiche, i costi e i tempi di sviluppo. Si riuniscono poi anche verso metà e fine progetto. Su quello che si dicono si hanno solo voci incontrollate, di solito.
I: Integrator. Supponiamo di dover fare un progetto complesso, deciso dai vari A ed E "in chief" di tutti i gruppi: per esempio un televisore. Esso avrà una parte di alimentazione, che andrà al gruppo di elettronica di potenza, una parte di alta frequenza che andrà ai campisti, una parte audio e bassa frequenza che andrà agli analogici, una parte di calcolo che andrà ai microcontrollisti, una parte di EMC ecc. ecc...
Gli elettronici di potenza chiedono "dobbiamo progettare l'alimentatore: quante tensioni vi servono? ripple max? Che correnti? Quanto sono impulsive le correnti che chiedete? per quanto tempo? Con le sollecitazioni date dai carichi, quanto deve essere la tolleranza entro la quale le tensioni di alimentazione si spostano?" L'integrator si occupa di reperire queste informazioni che servono al gruppo per progettare, andando dagli altri gruppi (i microntrollisti dicono che hanno bisogno di 5V e 3.3V, 5V+-5%, 3.3V+-3%, le correnti sono circa 2A per la 5V e 1A per 3.3V. Le correnti possono passare da 10uA a 1A in 20us. Gli analogici hanno bisogno di 12V in duale con una corrente di 3A, ripple max di 200mV. I campisti invece vogliono...). In pratica è l'anello di congiunzione tra i vari gruppi, semplifica le esigenze multiple. Anche se può non sembrare, ha un compito di complessità pari a quella delle altre figure e che dura per tutto il progetto, non solo all'inizio (le specifiche cambiano ).

Mi è stato detto che dare la possibilità a tutti di intervenire su qualunque aspetto crea solo caos, forse (ma ne dobbiamo discutere) è meglio fare dei gruppi chiusi di sviluppo.
Un'altra cosa sulla quale mi sono state fatte delle raccomandazioni è quella di tenere d'occhio i tempi. Un progetto che non finisce mai e che accumula continui ritardi stufa chiunque e fa perdere interesse.
Il fatto che siamo un gruppo di amici appassionati e che facciamo le cose per il piacere di farle non significa che non ci debba essere un controllo sui tempi.

Veniamo ora alla documentazione.
Produrre documentazione in modo efficiente, corposa e facilmente recuperabile al momento opportuno è indispensabile e molto difficile.
Personalmente devo produrre una relazione tecnica di modifiche (o di implementazione se il progetto è nuovo) e una di raccomandazioni d'uso per ogni cosa che faccio o che modifico. Avessi cambiato anche solo di un bit uno script.
Sulla prima pagina della documentazione che produco deve esserci un identificatore unico per ogni progetto, che è una sigla corrispondente ad un codice progetto (che mi viene dato all'inizio), un codice che indica il mio settore di attività specifica, poi segue una matricola che identifica chi scrive (io) una sigla che indica la versione del documento e la data della modifica in formato YYYYMMDD. Tutti questi dati, sempre nella prima pagina, vengono scritti anche testualmente.
Esempio:

AVCVD12233BHG
QQ345
E12RT3
1.2.3
20132109

Progetto : Forno a microonde Fantatron-EY
Attività : Simulazione comportamento magnetron a stress termici, modifiche tecniche a script Mathematica
Referente : io
Versione : 1.2.3
Data revisione: 21/09/2013

Questo lavoro viene fatto da tutti i PAEI di tutti i gruppi, per tutti i progetti.
Per ogni progetto l'A (admin) di ogni gruppo produce anche un documento sul flusso del progetto (quante persone hanno partecipato al progetto e come si chiamavano, come contattarle in futuro, se ci sono state delle sostituzioni, dove abbiamo comprato i componenti, quanti ne abbiamo comprati, quanto tempo hanno impiegato ad arrivare ecc. ecc...)
La mole di dati che ne consegue viene organizzata da dei software specifici (di cui, ammetto, non ne so molto). Questo è il know how aziendale.

E' fondamentale documentare qualunque cosa (proprio qualunque), non importa quanto piccola, e conservare qualunque documento venga prodotto (fosse anche un singolo file excel per calcolare una piccola tabella di look-up da mettere in un microcontrollore).
La regola d'oro è che, purtroppo, quello che oggi sembra troppo ovvio e scontato sarà assolutamente oscuro ed incompresibile tra un mese.

Non dovrei aver dimenticato nulla.
Ora non resta che discutere, magari per chiarire punti che ho trattato male o troppo velocemente o, perché no, ragionare su punti che nessuno ha ancora ben chiari!

Pietro.

Molto interessante, PietroBaima!

Da parte mia, nel mio piccolo mi sono interessato molto ai metodi agili per lo sviluppo del software (si dirà così in italiano?):

http://en.wikipedia.org/wiki/Agile_software_development

Le tecniche sono varie (e dopotutto l'idea è quella di scrivere software e non produrre un circuito), ma l'idea di base è quella di cercare di arrivare molto in fretta ad un prodotto usabile, per permettere di scoprirne i difetti "sul terreno" e correggerli in maniera altrettanto rapida.
A mio avviso, è un metodo che funziona bene con progetti portati avanti da relativamente poche persone, e con attenzione perché bisogna comunque avere un po' di lungimiranza e fare scelte progettuali che avranno ripercussioni sul lungo termine.

Quanto PietroBaima dice sulle Design review mi fa pensare a quello che è consigliato anche dai metodi agili di sviluppo software, ovvero che ci siano più persone a guardare in maniera attenta e critica (ma non malevola) il codice scritto, perché i problemi vengano alla luce.