comunicação, abordagem realista

5

Eu trabalho para uma empresa de arquitetura e engenharia de médio porte, nosso subgrupo se concentra no desenvolvimento de soluções de tecnologia para engenheiros, mapeadores e gerentes técnicos. Então, nós somos pesados em aplicativos baseados em desktop para GIS e Civil / Env Engenharia (alguns web). A empresa vende os serviços que nossos Engenheiros e Mapeadores produzem e nossa equipe desenvolve ferramentas que os ajudam a serem mais produtivos, eficientes e ajudam a agregar valor às suas decisões e produtos, NÃO vendemos a tecnologia.

Estamos passando por dificuldades de crescimento onde, inicialmente, costumávamos ser extremamente responsivos e poderíamos rapidamente criar protótipos de aplicativos para engenheiros, o que imediatamente trazia economia no orçamento. Essa mentalidade funcionou para nós no passado. Mas este ano nós ganhamos um contrato enorme e nossa base de clientes basicamente quintuplicou (5 vezes?). O que estamos descobrindo é que essa cultura de prototipagem rápida está nos prejudicando, onde os gerentes de projetos começaram a esperar tempos de resposta curtos para desenvolvimento de ferramentas e ferramentas robustas de produção pronta para todos os nossos engenheiros e analistas de GIS. Nós crescemos organicamente e agora parece que estamos lidando com essas questões se parece que temos que reduzir nossa velocidade para mais estabilidade.

Isso é uma troca legítima? Existe uma win-win? Como é que se empurra o engenheiro, o gerente de projeto e o analista quando eles são nossos clientes, eles nos financiam e, no entanto, precisamos ser capazes de reagir e dizer-lhes que, se querem estabilidade, precisam ser realistas em relação a prazos?

Isso não é o Microsoft Word, é um software GIS especializado e modelos de engenharia com uma tonelada de componentes de interoperabilidade para outros modelos padrão do setor, eles não são ferramentas à prova de idiotas, eles precisam de informações e só podemos testar coisas .

Alguém já lidou com dores de crescimento semelhantes? Recomendações / conselhos sobre uma postura de comunicação, livros, blogs?

    
por ved 18.10.2010 / 22:11
fonte

2 respostas

5
Primeiro de tudo, eu acho que a idéia básica de desenvolvimento e entrega rápida é boa e se você puder mantê-la ótima, faça isso (é a essência do Movimento Ágil).

A questão é porque você tem problemas agora? É o problema que você não pode entregar tão rápido porque você tem mais clientes para compartilhar seu tempo? O problema é que os novos funcionários não podem produzir novos códigos com rapidez suficiente?

Meu palpite pessoal é que você descobriu que "o talento não escala" e que agora você tem poucos programadores experientes para fazer o que você fez antes para mais clientes.

EDIT: Se assim for, você precisa reconhecer este fato, pois é impossível lançar mais pessoas no problema para manter a escala ( lei de Brooks ). Suas pessoas experientes precisarão orientar novos aprendizes, e isso levará algum tempo.

    
por 18.10.2010 / 22:39
fonte
1

Este é basicamente um problema de gerenciamento, não um problema de software. Você precisará contratar mais pessoas para lidar com a nova demanda. Você provavelmente também começará a construir uma equipe de QA, pelo menos informalmente. Dependendo da sua linha de produtos, integração contínua & testes unitários contínuos podem ser viáveis.

    
por 21.10.2010 / 01:35
fonte