Odio avere team di supporto e team di sviluppo.
Quando ciò accade gli sviluppatori iniziano a guardare in basso alle persone di supporto (è un ruolo meno affascinante). Le persone vengono etichettate come suppport e quindi non possono tornare a fare lo sviluppo, dove tendono ad essere la paga e le promozioni migliori.
Inoltre, il team di sviluppo non sente il dolore dei propri errori (che è fondamentale per migliorare!) e tende a ripetere le stesse cose ripetutamente che il team di supporto finisce per aggiustare. Ciò finisce con il pensare che siano grandi sviluppatori (non hanno mai sentito il contrario) e il team di supporto pensa di essere degli idioti.
L'altro svantaggio è che lo sviluppatore originale può spesso trovare e correggere un bug in un sistema complesso più veloce di una persona di supporto che deve aggiornarsi su cosa è stato fatto e perché prima di risolverlo. Inoltre, ho visto spesso che le persone di supporto rompono le cose di più perché non capivano il perché di qualcosa in primo luogo. Ciò è particolarmente vero quando si hanno sviluppatori che fanno semplicemente ciò che viene loro richiesto senza metterlo in discussione o respingere una cattiva richiesta. Quindi, quando il cliente chiede qualcosa che è in conflitto con un altro requisito di cui non è a conoscenza perché non funzionava in quella parte del sistema, la modifica è stata apportata e qualcosa che prima non funzionava più. È vero che questo può accadere anche quando lo staff di sviluppo originale supporta ma è meno probabile che abbiano più internalizzazioni e informazioni interne.
Non vedo il problema come ridurre al minimo il tempo di amministrazione per gli sviluppatori, ma più come farli fare il lavoro amministrativo necessario a tutti! Penso che nella pianificazione del lavoro, si dovrebbe pianificare solo 6 ore al giorno di tempo produttivo. Devi tenere conto delle ferie, dei doveri della giuria, del lavoro amministrativo, delle riunioni, ecc. E se pensi di ottenere 8 ore al giorno per determinare la tua scadenza, hai già una scadenza che non sarà soddisfatta o chiederai al tuo le persone a lavorare per gli straordinari continui o non concedere loro il tempo libero necessario per ricaricarsi. Uno sviluppatore stanco è uno sviluppatore inefficiente. Non progettare di costringere le persone a lavorare sfinite.
Suggerisco che se la tua applicazione è centrata sul database, dovresti avere diversi sviluppatori di database (non DBA ma persone che scrivono database basati su database e database di progettazione, in particolare persone con conoscenze di ottimizzazione delle prestazioni). La tua applicazione funzionerà meglio se hai queste persone fin dall'inizio nella fase di progettazione. Dovrai anche leggere il refactoring del database e impostare un processo in cui le modifiche al database possono essere fatte correttamente quando necessario.
Un designer della GUI del contratto è bello avere in giro pure. Questo tipo di designer spesso non è necessario a tempo pieno, ma è utile avere qualcuno che conosci che puoi assumere quando viene eseguita una riprogettazione dell'interfaccia utente.
Un buon analista di business è un must. Un cattivo può distruggere un progetto e la squadra. Non tenere un analista cattivo più a lungo del necessario per elaborare i documenti per licenziarlo. Questa persona può fare più male a un progetto di chiunque altro. Aggiungerà mesi e anni ai progetti che cercano di aggirare la spazzatura che gli sviluppatori dedicano al lavoro e ti ritroveranno a spingere i rilasci che funzionano ma che non fanno ciò che è necessario rovinando la tua credibilità.