'Se superate B0 siete licenziati': il CEO di Intel lancia un ultimatum ai suoi ingegneri

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/cpu/se...ri_153859.html

Lip-Bu Tan, CEO di Intel, ha introdotto una direttiva interna radicale: i chip devono superare il tape-out alla revisione A0, senza necessità di ulteriori iterazioni correttive. Chi non rispetta la soglia B0 rischia il licenziamento. Una svolta culturale che punta a ridurre i cicli di sviluppo e migliorare la disciplina ingegneristica interna.

Click sul link per visualizzare la notizia.

[s0nnyd3marco]

Visione puramente finanziaria, che non portera' a progetti fatti meglio ma a prodotti con bug nascosti sotto il tappeto.

[Ago72]

Originariamente inviato da s0nnyd3marco

Visione puramente finanziaria, che non portera' a progetti fatti meglio ma a prodotti con bug nascosti sotto il tappeto.

Può essere, ma vista l'esperienza più che ventennale nell'industria dei semiconduttori, potrebbe anche non esserla.

[Darkon]

Originariamente inviato da s0nnyd3marco

Visione puramente finanziaria, che non portera' a progetti fatti meglio ma a prodotti con bug nascosti sotto il tappeto.

Sinceramente se devi fare tante correzioni tali da arrivare a B0 il problema è a monte.

Significa essere partiti con un prodotto non adeguatamente revisionato e ottimizzato.

Tra l'altro una pessima immagine anche per l'azienda perché se io compro e poi viene fuori che quel chip ha avuto bisogno di X revisioni e che io che l'ho preso presto lo prendo in quel posto francamente girano parecchio le scatole.

In ambito retail la quasi totalità nemmeno se ne accorge ma in ambito aziendale specie in entità di un certo livello e con policy importanti è roba che fa girare le scatole.

[ZeroSievert]

Concordo con chi dice che non e' una buona strategia minacciare i propri dipendenti di licenziamento se i progetti hanno bisogno di una revisione correttiva. Cosi' spinge solo gli ingegneri a nascondere la polvere sotto il tappeto e ad adottare approcci poco innovativi e conservativi per evitare magagne (= tempi piu' lunghi per arrivare al tape-out e prodotti meno performanti). Tutte cose che un'azienda come Intel non si puo' permettere.

L'approccio giusto sarebbe analizzare i motivi per cui un determinato prodotto ha necessitato di troppe revisioni e ottimizzare i processi per limitare lo stesso problema in futuro.

[Final50]

Originariamente inviato da Ago72

Può essere, ma vista l'esperienza più che ventennale nell'industria dei semiconduttori, potrebbe anche non esserla.

Il punto è la minaccia del licenziamento, mi pare sacrosanto che ci cerchi di migliorare il processo se è evidente che non sta funzionando o che a livello finanziario/societario serve un miglioramento, ma il punto è non è quello che cerchi di raggiungere ma come stai cercando di raggiungerlo.
Minacciare il licenziamento porterà le persone a fare carte false pur di non far saltar fuori errori o doverli ammettere creando un pessimo clima aziendale dove invece di riflettere e lavorare sugli errori li si nasconde... oppure si allunga la fase di progettazione e/o analisi prima di arrivare ad A0 perchè sicuramente nessuno ci vorrà rimettere il culo.

[Maury]

Originariamente inviato da Final50

.. oppure si allunga la fase di progettazione e/o analisi prima di arrivare ad A0 perchè sicuramente nessuno ci vorrà rimettere il culo.

Ed è la via assolutamente da preferire, meglio fare le cose per bene che dover continuamente mettere mano al progetto. È questo che il CEO Intel punta. Evidentemente ha visto troppa leggerezza nel gestire il tutto, infatti non è normale che Intel abbia tutti questi problemi lato revisioni.

[Piedone1113]

Originariamente inviato da ZeroSievert

Concordo con chi dice che non e' una buona strategia minacciare i propri dipendenti di licenziamento se i progetti hanno bisogno di una revisione correttiva. Cosi' spinge solo gli ingegneri a nascondere la polvere sotto il tappeto e ad adottare approcci poco innovativi e conservativi per evitare magagne (= tempi piu' lunghi per arrivare al tape-out e prodotti meno performanti). Tutte cose che un'azienda come Intel non si puo' permettere.

L'approccio giusto sarebbe analizzare i motivi per cui un determinato prodotto ha necessitato di troppe revisioni e ottimizzare i processi per limitare lo stesso problema in futuro.

Guarda che non ha detto che l'A0 deve essere pronto per il giorno x.
Quello che chiede è che l'A0 sia già un prodotto finito e non un beta.
Meglio 6 mesi di revisioni sul progetto che 3 revisioni profonde .
Rifare le maschere, ricalibrare la catena e dopo pochi test ti accorgi che serve un B0 invece che un A1, e magari subito dopo rendersi conto che le modifiche preano ( o mettono in evidenza) problemi ad altra parte del chip tale da ridefinire un C0. Una volta le revisioni era dettati da 2 fattori fondamentali: affinamento e maturazione del processo produttivo, interventi marginali sul chip ( magari necessari per via del pp migliore)

[ZeroSievert]

Originariamente inviato da Piedone1113

Guarda che non ha detto che l'A0 deve essere pronto per il giorno x.
Quello che chiede è che l'A0 sia già un prodotto finito e non un beta.
Meglio 6 mesi di revisioni sul progetto che 3 revisioni profonde .
Rifare le maschere, ricalibrare la catena e dopo pochi test ti accorgi che serve un B0 invece che un A1, e magari subito dopo rendersi conto che le modifiche preano ( o mettono in evidenza) problemi ad altra parte del chip tale da ridefinire un C0. Una volta le revisioni era dettati da 2 fattori fondamentali: affinamento e maturazione del processo produttivo, interventi marginali sul chip ( magari necessari per via del pp migliore)

Va bene. Ma il punto rimane che se minacci il licenziamento se emerge la necessità di fare altre revisioni, spingi le persone a spazzare la polvere sotto il tappeto.

[Piedone1113]

Originariamente inviato da ZeroSievert

Va bene. Ma il punto rimane che se minacci il licenziamento se emerge la necessità di fare altre revisioni, spingi le persone a spazzare la polvere sotto il tappeto.

ed ha ragione, una revisione profonda da A0 a B0 significa che qualcosa di grave è sfuggito ( altrimenti si sarebbe parlato di un A1), ma una rev C0 significa che quel difetto è rimasto inosservato a ben 2 revissioni pre produzione ( ES e QS) ed a due revisioni sul prodotto finito.

[ZeroSievert]

Originariamente inviato da Piedone1113

ed ha ragione, una revisione profonda da A0 a B0 significa che qualcosa di grave è sfuggito ( altrimenti si sarebbe parlato di un A1), ma una rev C0 significa che quel difetto è rimasto inosservato a ben 2 revissioni pre produzione ( ES e QS) ed a due revisioni sul prodotto finito.

Quindi, invece di capire come e perché il processo di revisione non ha funzionato, licenziamo in tronco. Ok..

[Maury]

Originariamente inviato da ZeroSievert

Quindi invece di capire come e perché il processo di revisione non ha funzionato, licenziamo in tronco. Ok..

Vuol dire che ora si avanza di step solo se è tutto a posto, con il tempo necessario ad ottenerlo, sino ad ora sembra che si avanzasse anche in presenza di situazioni tragicomiche.

[Giuss]

Originariamente inviato da ZeroSievert

Quindi, invece di capire come e perché il processo di revisione non ha funzionato, licenziamo in tronco. Ok..

E poi che facciamo? Assumiamo al loro posto altri programmatori che ovviamente non conoscono il prodotto e ricominciano da zero

[ZeroSievert]

Originariamente inviato da Giuss

E poi che facciamo? Assumiamo al loro posto altri programmatori che ovviamente non conoscono il prodotto e ricominciano da zero

Tra le altre cose. Come se trovare ingegneri di un certo livello fosse semplice. O come se non ci volesse un sacco di training a rendere un nuovo dipendente produttivo.

[Darkon]

Io capisco tutto quanto e non dico che tanti commenti non siano anche giusti eh.

Ma quando in maniera costante arrivi a certe revisioni è evidente che c'è qualcosa che non va e non certo qualcosa che risolvi facilmente.

Ora dubito che questa dichiarazione verrà applicata 1 a 1 come se non ci fosse un domani. Probabilmente era più che altro un monito per dire che è l'ora di abbozzarla con un certo tipo di atteggiamento e di metodo di lavoro.

Intel d'altra parte o ricomincia a fare roba decente o muore.

[ZeroSievert]

Originariamente inviato da Darkon

Io capisco tutto quanto e non dico che tanti commenti non siano anche giusti eh.

Ma quando in maniera costante arrivi a certe revisioni è evidente che c'è qualcosa che non va e non certo qualcosa che risolvi facilmente.

Ora dubito che questa dichiarazione verrà applicata 1 a 1 come se non ci fosse un domani. Probabilmente era più che altro un monito per dire che è l'ora di abbozzarla con un certo tipo di atteggiamento e di metodo di lavoro.

Intel d'altra parte o ricomincia a fare roba decente o muore.

Si peró Darkon, proprio perché non é una cosa che risolvi facilmente IMHO dubito che una soluzione semplicistica come quella descritta nell'articolo sia utile.

Capisco licenziare per negligenza o bassa produttività. Ma quello descritto dall"articolo sembra piú uno scaricabarile di responsabilità del management sul personale tecnico.

Se io, pur seguendo i processi aziendali, faccio un danno all'azienda, é colpa mia o del processo in questione?

[Darkon]

Originariamente inviato da ZeroSievert

Si peró Darkon, proprio perché non é una cosa che risolvi facilmente IMHO dubito che una soluzione semplicistica come quella descritta nell'articolo sia utile.

Capisco licenziare per negligenza o bassa produttività. Ma quello descritto dall"articolo sembra piú uno scaricabarile di responsabilità del management sul personale tecnico.

Se io, pur seguendo i processi aziendali, faccio un danno all'azienda, é colpa mia o del processo in questione?

Ma penso che siano dichiarazioni come dicevo forse in maniera troppo criptica che siano più che altro dichiarazioni per la stampa e una sorta di dichiarazioni d'intenti nel senso che ovviamente salvo colpe grave nessuno verrà licenziato ma che c'è un cambio di passo e che certe cose dovranno essere evitate.

Dubito fortemente che inizieranno a fare licenziamenti di massa visto anche che non è che siano messi benissimo e che certe figure professionali non le trovi come niente fosse da assumere.

[Piedone1113]

Originariamente inviato da Darkon

Ma penso che siano dichiarazioni come dicevo forse in maniera troppo criptica che siano più che altro dichiarazioni per la stampa e una sorta di dichiarazioni d'intenti nel senso che ovviamente salvo colpe grave nessuno verrà licenziato ma che c'è un cambio di passo e che certe cose dovranno essere evitate.

Dubito fortemente che inizieranno a fare licenziamenti di massa visto anche che non è che siano messi benissimo e che certe figure professionali non le trovi come niente fosse da assumere.

E se la minaccia è invece rivolta ai coordinatori delle sezione che fanno si a scaricabarile se la mia implementazione ha problemi con la tua?

[Darkon]

Originariamente inviato da Piedone1113

E se la minaccia è invece rivolta ai coordinatori delle sezione che fanno si a scaricabarile se la mia implementazione ha problemi con la tua?

Che ti devo dire... difficile risponderti tutto può essere. Rimango dell'idea che comunque a quel livello prima di licenziare non ci pensano una ma 100 volte.

[Piedone1113]

Originariamente inviato da Darkon

Che ti devo dire... difficile risponderti tutto può essere. Rimango dell'idea che comunque a quel livello prima di licenziare non ci pensano una ma 100 volte.

Certo che non licenzi così per bizza: un ceo ha sotto solo i direttori e qualche caporeparto strategico, certamento non saprà chi ha sbagliato, ma sicuramente chi non ha vigilato e organizzato le cose.
Se un reparto batte la fiacca il ressponsabile, e di riflesso il colpevole, non è certo il singolo membro del reparrto, quanto piuttossto il capo reparto e direttamente sopra di lui il capo sezione fino al direttore. Se nel progetto della cpu ci ssono dei problemi sulla cache il principale responsabile è il capo progettista di quel reparto ( ok adesso lo chiamano coordinatore, ma anche i bidelli oggi li chiamano collaboratori..) sempre se non si sia attenuto alle linee guida del progetto.
Non è che chi progetta una parte crea un manufatto a se stante, ma la tessera di un puzzle che deve incastrarsi con le tessere vicine.