Como liderar um projeto de desenvolvimento sem conhecimento técnico

Eu fui um desenvolvedor prático durante toda a minha carreira e adoro trabalhar com código. Sempre me ressenti do líder da equipe, que tem pouca ou nenhuma experiência em relação a uma tecnologia específica e ainda insiste em uma determinada implementação.

Agora me encontro do outro lado do espelho. Sou o desenvolvedor líder de um cliente gordo a ser implementado em C #, no entanto, meu conhecimento é na construção de aplicativos Web Java. Embora eu saiba que posso aproveitar os padrões de design e os paradigmas de OO em qualquer idioma, estou perdido quando se trata de padrões de codificação, ferramentas de ciclo de vida do projeto e procedimentos de liberação / distribuição. Não tenho dúvidas de que posso aprender o básico em um mês ou dois, mas há certas experiências que só podemos reunir com o tempo.

O que devo fazer e como evitar me tornar o líder do projeto que eu odiava quando estava desenvolvendo?

Honestamente, não importa quanta experiência você tenha com uma tecnologia, meu conselho é o mesmo: não imponha decisões de tecnologia àqueles que terão que viver com elas enquanto você estiver ocupado gerenciando.

Seja honesto com você mesmo. Aposto que o motivo pelo qual você odiava esses gerentes anteriores não era porque eles não tinham a base de conhecimento a partir da qual tomar decisões, foi porque eles impuseram decisões e nunca lidaram com as conseqüências.

Isso se aplica se você nunca tocou no .NET antes ou se é o desenvolvedor mais especialista da equipe. Seu trabalho agora é gerenciar, não tomar decisões técnicas.

Gerenciar pode, dependendo do nível de habilidade de seus desenvolvedores, significar aconselhá-los quando eles solicitarem. "Você analisou o Spring.NET?" (observe a falta de instrução lá) é uma coisa perfeitamente boa a dizer. Além disso, "procure no Google o que o resto do mundo está fazendo, não somos os primeiros a enfrentar esse problema".

Em alguns aspectos, como um desenvolvedor Java experiente, você pode estar em uma posição melhor do que a maioria para isso. A maioria das estruturas e tecnologias Java possui um equivalente análogo no .NET. Então você não precisa dizer "Aqui está a melhor coisa para usar", você pode dizer "Eu usei isso em Java, você conhece um equivalente .NET?"

Também incentive muitas conversas dentro da equipe. Organize reuniões semanais de discussão técnica. Tudo que você precisa é de informação, no final; você precisa saber quais decisões foram tomadas e por quê. Você não precisa tomar essas decisões para a equipe.

Tive alguns bons gerentes / líderes de equipe que sabiam muito pouco sobre a tecnologia, e alguns dos meus piores gerentes foram aqueles que pensaram que sabiam tudo.

Para ser um líder, se você tem pessoas razoavelmente competentes, o principal é ser capaz de julgar sua competência e julgamento e dar a cada um o máximo de latitude possível, mantendo os "patos selvagens" na tarefa e os "mal" competidores "ocupados com atividades" seguras ", mas produtivas. Certifique-se de que todos estejam marchando para o mesmo baterista.

Seu maior desafio provavelmente é manter a alta gerência sob controle. Eles querem relatórios, agendas e marcas de verificação, e você precisa descobrir o que eles querem e como falsificá-los razoavelmente bem. (Bem, não exatamente "falso", mas produza documentação que os satisfaça sem consumir seu tempo ou o tempo de sua equipe.)

Você não foi escolhido por suas habilidades de codificação em C # e, a menos que esteja escrevendo código desde o início, não importa se você conhece C # ou não. Você precisa começar a pensar em um nível superior:

• Que habilidades cada pessoa de sua equipe traz para a mesa?
• Quais componentes são críticos para o sucesso do projeto?
• O que você precisa produzir além do código real? (Testes? Documentação?)
• Como você reunirá requisitos, se ainda não o fez?
• Como você e sua equipe abordarão o processo de design?
• Você sabe que é importante ter um padrão de codificação, mas você pode confiar na sua equipe para descobrir exatamente qual padrão eles querem seguir.
• Como você pode detectar problemas cedo?

Algumas dessas coisas podem passar para o território de gerenciamento de projetos, mas como desenvolvedor líder, você trabalhará em estreita colaboração com o gerente de projetos nessas e em outras questões.

Por todos os meios, aprenda a trabalhar eficazmente em C # o mais rápido possível. Lembre-se de que sua função é ver além da sintaxe e dos detalhes da estrutura e olhar para o quadro geral.

Tome as mãos na abordagem. Comece usando um primer C # simples e escreva algum código. Tente algumas coisas básicas que você saberia fazer com os olhos vendados em outro idioma.

Leia sobre estilo e convenção de programação. Você deve encontrar isso em parte na sua cartilha de qualquer maneira, mas também pode usar produtos como StyleCop e Resharper para aplicar regras de estilo que você não conhece. Isso efetivamente o treinará muito rapidamente para fazer as coisas de uma maneira comumente aceita, a fim de evitar problemas na compilação do seu software.

Seja você mesmo e aplique o conhecimento de design que você já possui. O básico é essencialmente o mesmo, independentemente do idioma. Onde haverá diferenças, a forma como os idiomas diferem em termos de estrutura será bastante mínima, e muito disso se tornará aparente muito rapidamente à medida que você cria um ou dois aplicativos de teste.

Se há coisas óbvias que você não sabe, seja iminente. Sua equipe respeitará a honestidade mais do que simplesmente se intrometer sem uma pista. Tome decisões bem informadas e fundamentadas e sempre reserve alguns minutos para considerar sua resposta. Você precisará ser assertivo sem tentar dominar e não poderá deixar sua falta de conhecimento em uma área parecer uma reflexão sobre sua capacidade de liderar a equipe. Liderança implica orientação, mas a orientação não significa que você também não pode mostrar vontade de aprender algo novo.

Se você pensa assim e realmente se preocupa, já evitou o risco de se tornar esse tipo de líder de projeto. É um tipo de personalidade totalmente diferente que se atreveria a tomar decisões sem o conhecimento adequado. Apenas mantenha uma mente aberta para o que seus colegas de trabalho lhe dizem e crie e incentive uma cultura de diálogo e troca de informações em sua equipe.

Parece que existem algumas questões em jogo aqui.

A tecnologia usada no projeto que você lidera e o processo que governa o desenvolvimento desse projeto.

Você é o líder da equipe ou um desenvolvedor líder? Um desenvolvedor líder também faz um pouco do trabalho de design e desenvolvimento. Portanto, a única maneira de contornar isso é apenas desmontar e aprender a nova tecnologia .

Se você está realmente liderando a equipe, precisará confiar nela e deixá-los dirigir a maior parte da direção técnica do projeto. Obviamente, conceitualmente, você será capaz de manter a direção na direção certa.

Os processos que governam o desenvolvimento do projeto devem estar principalmente implementados . É apenas uma questão de ler sobre eles, entendê-los e executá-los.

Caso contrário, negocie com seu chefe para obter um mentor para ajudá-lo a implementar algum processo de desenvolvimento. Isso é muito importante. Ele falhará rapidamente se o processo não estiver no lugar e for ad hoc.

Boa sorte!

A oportunidade vem de vez em quando .. Agarre-a .. Eu diria, tente aprender o básico do C #. Obtenha algum tutorial on-line, tente trabalhar nele. inicialmente, seria difícil aprender o novo conceito; depois, quando sua primeira tarefa terminar, você terá alguma confiança nele.

Pense positivo, tente executar tarefas difíceis, depure seu próprio código e tenho certeza que você o dominará ..

Não perca sua oportunidade.

Acho que se você tem um bom grupo de desenvolvedores de .Net, há muito conhecimento na equipe que talvez você precise explorar para começar. Há muita semelhança entre Java e .Net de que o que você já sabe pode realmente se aplicar mais ou menos diretamente. A importância é saber o que é importante para acertar neste projeto e os riscos envolvidos. Comunique-se com sua equipe sempre que necessário. As práticas de engenharia de software evoluem ao longo de um projeto, por isso pode ser difícil ter uma "melhor prática" muito cedo no projeto.

Eu meio que tive o reverso da sua experiência, onde recebi uma equipe muito verde de graduados que não são do campo relacionado a software. Embora eu tenha todo o motivo para estipular o que precisa ser feito (eu estava empregado), em vez disso, procurei prática para nos movimentar e muito treinamento e discussão para evoluir nossa prática de engenharia de software. Aprendi muitas coisas da equipe no caminho e estamos quase entregando nosso primeiro projeto interno depois de mais de um ano no trabalho!

Estou perdido quando se trata de padrões de codificação, ferramentas de ciclo de vida do projeto e procedimentos de liberação / distribuição.

Encontre um produto de código aberto que use a mesma tecnologia que você usará.

Se possível, encontre um que seja de alguma forma semelhante ao domínio do problema. Isso não é tão importante quanto encontrar um projeto com a mesma tecnologia e atualizações ativas.

Faça o download do código de trabalho deles. Leia-o.

Descubra quais ferramentas eles usam. Usa-os.

Descubra como criar e liberar o projeto de código aberto. Construa e libere.

Um projeto de código aberto (com vários colaboradores) ilustrará as melhores práticas.

Não tenho dúvidas de que posso aprender o básico em um mês ou dois, mas há certas experiências que só podemos reunir com o tempo.

Verdade.

Aprenda com a comunidade de código aberto.