Esta é uma questão clássica em empresas que têm um componente de desenvolvimento de software em seu trabalho, sejam empresas de software ou não. Eu luto com isso o tempo todo.
Tendo desenvolvedores envolvidos no suporte à produção
Prós
- Combate síndrome de "desenvolvimento no vácuo" . É valioso ganhar exposição sobre como os usuários usam o aplicativo. Até que eu finalmente vi isso como um desenvolvedor jovem, eu não sabia que desenvolvedor de UI ruim eu era. Tudo o que eu me importava era codificar e não design, análise ou a perspectiva do usuário.
- Os desenvolvedores que não são tão bons quanto eles acham que podem ser humilhados (embora não haja garantia de que você obterá esse benefício; alguns desenvolvedores são realmente alheios, egoístas e teimosos).
- Os desenvolvedores ganharão conhecimento de domínio . Isso é fundamental para que seus desenvolvedores se tornem, eventualmente, melhores em identificar e preencher as lacunas da fase de análise de negócios (supondo que haja alguma).
- Bom apoio é um ponto de marketing. Se você fizer isso bem, os clientes vão gostar disso. E um desenvolvedor completo com habilidades de comunicação e conhecimento de domínio é capaz de fazer isso bem. No entanto, eu ainda preferiria que os aplicativos fossem de qualidade alta o suficiente para não precisarem de suporte. Qualidade superior é a sua própria forma de suporte ao cliente (e também um ponto de marketing).
Contras
- Fator de interrupção . Esta é a falha número um de misturar o trabalho de projeto e o trabalho de suporte, mas nenhum. Os projetos interferem no suporte e o suporte interfere nos projetos. Os projetos dependem de estimativas e progresso, o apoio é imprevisível e pode envolver urgência improvisada. Os projetos são baseados em cronograma e o suporte é baseado em interrupção. Não é uma combinação feliz e muito frustrante para os desenvolvedores lidarem.
- Nem todo mundo é bom em suporte . Alguém que tenha menos experiência com o aplicativo ou empresa, ou alguém cuja personalidade ou habilidades de comunicação sejam de tal forma protegidas contra o acesso do usuário, pode não funcionar bem no suporte.
- Uso ineficiente de recursos . Frank Shearar observou nos comentários que um desenvolvedor que faz um suporte trivial pode ser mais caro do que uma tecnologia de suporte de nível um.
Na minha experiência, a maioria dos desenvolvedores não gosta de suporte. Tendo servido tanto no projeto quanto no apoio, posso simpatizar. Ao ter que fazer as duas coisas ao mesmo tempo, o fator atenuante é, muitas vezes, horas extras, geralmente não pagas, para lidar com emergências de suporte e ainda fazer os prazos do projeto. Os gerentes de projeto adoram horas extras não pagas porque isso significa fazer datas sem custar mais dinheiro, mas para os desenvolvedores, é apenas uma grande tigela de sucção.
No entanto, também acredito que, se os desenvolvedores fizessem um trabalho melhor criando sistemas confiáveis e intuitivos, teriam menos suporte. Então isso cria um estranho argumento circular para misturar os dois. O que eu acho que você deveria fazer se tiver que fazer as duas coisas é encontrar maneiras de evitar que isso seja simultâneo.