comunicazione, approccio realistico

5

Lavoro per una società di architettura e ingegneria di medie dimensioni, il nostro sottogruppo si concentra sullo sviluppo di soluzioni tecnologiche per ingegneri, mappatori e responsabili tecnici. Quindi siamo pesanti su app basate su desktop per GIS e Civil / Env Engineering (alcuni web). La società vende i servizi che i nostri ingegneri e mappatori producono e il nostro team sviluppa strumenti che aiutano a renderli più produttivi, efficienti e contribuiscono ad aggiungere valore alle loro decisioni e prodotti, NON vendiamo la tecnologia.

Stiamo attraversando crescenti dolori in cui inizialmente eravamo estremamente reattivi e potevamo rapidamente prototipare app per ingegneri che hanno immediatamente portato a un risparmio di budget. Quella mentalità ha funzionato per noi in passato. Ma quest'anno abbiamo vinto un grosso contratto e la nostra base clienti è sostanzialmente quintuplicata (5 volte?). Quello che stiamo scoprendo è che questa cultura della prototipazione rapida ci sta danneggiando, dove i project manager hanno iniziato ad aspettarsi brevi tempi di risposta per lo sviluppo degli strumenti e robusti strumenti pronti per la produzione per tutti i nostri ingegneri e analisti GIS. Siamo cresciuti in modo organico e ora sembra che stiamo affrontando questi problemi se sembra che dobbiamo ridimensionare la nostra velocità per una maggiore stabilità.

È un compromesso legittimo? C'è una win-win? Come si fa a respingere l'ingegnere, il project manager e l'analista quando sono i nostri clienti, ci finanziano e tuttavia dobbiamo essere in grado di respingere e dire loro che se vogliono stabilità devono essere realistici sugli intervalli di tempo?

Questo non è Microsoft Word, si tratta di software GIS specializzati e di modelli di ingegneria con una tonnellata di componenti di interoperabilità per altri modelli standard del settore, non sono strumenti di prova idiota, hanno bisogno di input informati e possiamo solo testare le cose così tanto .

Qualcuno ha avuto a che fare con simili crescenti dolori? Consigli / consigli su una posizione di comunicazione, libri, blog?

    
posta ved 18.10.2010 - 22:11
fonte

2 risposte

5

Prima di tutto penso che l'idea di base di sviluppo rapido e consegna sia soddisfacente e se puoi mantenerla così bella, fallo (è l'essenza del Movimento Agile).

La domanda è perché hai problemi ora? Il problema è che non puoi consegnare più velocemente perché hai più clienti per condividere il tuo tempo? Il problema è che i nuovi dipendenti non possono produrre abbastanza velocemente un nuovo codice?

La mia ipotesi personale è che hai scoperto che "il talento non scala" e che ora hai troppo pochi programmatori esperti per fare ciò che hai fatto prima per più clienti.

EDIT: Se è così, devi riconoscere questo fatto, poiché è impossibile inviare altre persone al problema per mantenere il ridimensionamento ( legge di Brooks ). I tuoi esperti avranno bisogno di guidare nuovi apprendisti e ci vorrà del tempo.

    
risposta data 18.10.2010 - 22:39
fonte
1

Questo è fondamentalmente un problema di gestione, non un problema software. Dovrai assumere altre persone per gestire la nuova domanda. Probabilmente inizierai anche a costruire una squadra di QA, almeno in modo informale. A seconda della linea di prodotti, integrazione continua e amp; il test dell'unità continua potrebbe essere fattibile.

    
risposta data 21.10.2010 - 01:35
fonte

Leggi altre domande sui tag