Quando dovrei rifiutare di apportare una modifica richiesta?

3

Lavoro sul lato software di un'azienda che fornisce hardware personalizzato con software in esecuzione su di esso. Spesso l'hardware non è progettato bene. In questi casi, spesso mi viene chiesto prima di risolvere il problema - ovviamente il sintomo è sempre "il tuo software si è bloccato" o qualcosa del genere.

Recentemente abbiamo avuto un altro di questi incidenti in cui l'alimentazione su una linea USB non è affidabile e causa il malfunzionamento di un dispositivo USB. Ciò causa un problema di usabilità in una delle nostre applicazioni. Il top management mi ha chiesto di gestirlo meglio - monitora continuamente il dispositivo USB, e se scompare, riavvia o prova a ripristinarlo. Non è garantito che nessuna di queste soluzioni risolva nulla.

In definitiva, la vera soluzione è correggere l'affidabilità del dispositivo dal lato hardware. Potrei migliorare le prestazioni, ma non al 100%, e ovviamente userò il mio già limitato tempo per ingannare il codice e aggiungere un altro thread di monitoraggio dei dispositivi.

Quindi, con tutto ciò che ho detto, come posso prendere una buona decisione su quando dire che questa deve essere una correzione hardware e solo una correzione hardware? Posso approcciare questo quantitativamente e proporre una sorta di test sì / no definitivo? Sono sicuro che non sia così facile.

    
posta reuscam 11.03.2011 - 15:21
fonte

3 risposte

5

Lo guarderei in questo modo. Il che aggiunge più valore all'azienda dal punto di vista della gestione. Probabilmente a loro non importa se il codice è gonfio o se non è perfetto al 100% vogliono fare meno lavoro per fare soldi. L'hardware di riparazione è in genere molto più costoso della modifica del codice. Se riesci facendo in modo che le tue modifiche lo rendano abbastanza buono da vendere senza ingenti somme di denaro, allora vorranno cambiare la tua parte. Se cambi non lo renderà abbastanza buono da guadagnare, dovresti aggiornarlo e dire che dobbiamo sistemare l'hardware.

    
risposta data 11.03.2011 - 15:27
fonte
1

Per usare un'analogia con il costruttore di automobili: Volvo, Mercedes, BMW e Lexus probabilmente risolverebbero l'hardware. Altri potrebbero dire, aggiustarlo ora e sistemare l'hardware prima del prossimo lotto / modello. Il resto riparerà semplicemente il software perché è abbastanza buono dai loro bassi standard.

Questo è il motivo per cui un'azienda deve stabilire un'identità in modo che tutti possano prendere decisioni in linea con quell'obiettivo. "Avremo il miglior prodotto ingegnerizzato nel nostro settore." contro "Falla funzionare".

Basare la tua raccomandazione nel contesto di ciò che l'azienda sta cercando di essere.

    
risposta data 11.03.2011 - 15:34
fonte
1

Il tuo lavoro come sviluppatore è di fornire soluzioni e fornire conoscenze tecniche . Se sono possibili più soluzioni possibili, valutare i costi, i benefici e i rischi di ciascuna e presentare le valutazioni al proprietario del prodotto. Per decidere quale soluzione implementare è il lavoro del proprietario del prodotto . Hai un po 'di spazio per giocare in come hai presentato i fatti e le stime, ma non cercare di piegare troppo le regole.

Naturalmente tutti vorremmo implementare soluzioni "perfette" dal nostro punto di vista. Imparare a tenere in considerazione il punto di vista del business e degli utenti è una competenza importante per i programmatori, che ci aiuta a fornire soluzioni migliori ai nostri clienti.

A volte (di solito di solito) il proprietario del prodotto è a conoscenza di fattori che non lo sono. Come altri hanno notato, una soluzione hardware può essere molto più costosa di una patch software. Oppure potrebbe essere totalmente fuori discussione a causa di alcuni problemi (politici o tecnici) con il produttore dell'hardware.

    
risposta data 11.03.2011 - 16:02
fonte

Leggi altre domande sui tag