Essa lista de comportamentos de gerenciamento realmente atrai os desenvolvedores de software? [fechadas]

8

Encontrei esta lista de comportamentos de gerenciamento ( http://suven.posterous.com/dos-and-donts-leading-software-development-te ).

Eu acho que tem algumas gemas, mas não sou 100% delas. Eu marquei aqueles com itálico e meu nome.

Você, como desenvolvedor de software, acha que isso é atraente? Quais três seriam seus itens principais "precisam ter" em sua administração?

Não

  • Não dimensione equipes verticalmente adicionando mais pessoas

  • Não crie uma equipe com mais de 10 pessoas

  • Não chame os recursos das pessoas, não é legal e é realmente ofensivo

  • Não assuma que as pessoas nas equipes são intercambiáveis

  • Não compare equipes entre si ao destacar pontos fracos

  • Não jogue times um contra o outro

  • Não crie prazos falsos

  • Não force a padronização de ferramentas e processos entre as equipes (acho que este pode ser discutido em algumas situações - Todd)

  • Não contrate gerentes de produto que não tenham idéia sobre o desenvolvimento de software

  • Não use exclusivamente KPIs para orientar suas equipes (não apenas é ineficaz, mas os desenvolvedores encontrarão maneiras de conduzir as métricas de KPI - "Você quer linhas de código? Eu tenho suas linhas de código!" - Todd)

  • Não force suas equipes a trabalhar horas extras, mesmo pedir é criar tensão

  • Não assuma que o dobro das pessoas é igual à metade do tempo

Faz

  • Faça a escala horizontalmente, criando mais equipes de cerca de 5 a 8 pessoas

  • Tenha uma visão para o produto e equipe

  • Aprecie que cada equipe é diferente, portanto, aloque os projetos adequadamente

  • Motive suas equipes (Uau - essa é escorregadia e difícil de definir. Eu concordo com o sentimento, mas é como dizer "Seja eficaz" sem diretrizes. -Todd)

  • Permita que as pessoas se movam entre equipes

  • Realize sessões para discutir a visão, estratégia, tecnologia e processo do produto

  • Envolva a equipe ao determinar o nome da equipe / produto

  • Permita que suas equipes tomem suas próprias decisões, especialmente se tiverem conhecimento

  • Envolva sua equipe em qualquer decisão que tenha impacto sobre como ou no que eles trabalham

  • Incentive uma metodologia de desenvolvimento que corresponda à equipe e ao projeto

  • Preste atenção ao plano de desenvolvimento pessoal de cada indivíduo

management Todd Williamson
fonte
4
O que eu realmente tenho um problema é envolver a equipe com o nome do produto. Este é um assunto sobre o qual todos têm uma opinião, mas na verdade existem pessoas no marketing (ou pelo menos em departamentos de marketing decentes) que sabem mais sobre isso do que apenas ter uma opinião. Se você deseja que suas habilidades sejam respeitadas, também respeite as habilidades dos outros.
Jon Hopkins
Esta é uma lista incrível! De que romance de ficção científica é esse?
21714 Rob

Respostas:

2

Meu palpite é que essa lista realmente atrai desenvolvedores de software porque ela valida sua auto-imagem como divas criativas mimadas, em vez de solucionadoras de problemas difíceis (como Winston Wolf) e espera ser tratada profissionalmente como resultado.

Eu também suspeito que, se aprimorássemos as técnicas de desenvolvimento de software a tal ponto que nosso comércio fosse certificável como o de arquitetos, advogados, profissionais médicos e afins, estaríamos mais aptos a orientar como os desenvolvedores de software são gerenciados.

Huperniketes
fonte
1
Parece haver uma dicotomia entre a percepção dos desenvolvedores que eles têm de si mesmos versus os gerentes. Penso que em ambos os casos, você precisa olhar para os desenvolvedores como indivíduos e reconhecer as diferenças individuais mais do que para fazer generalizações abrangentes sobre um grupo. Acho que você está certo quanto a técnicas aprimoradas, mas não acho que você verá uma certificação universal que seja universalmente aceita. Os que estão lá fora são baseados em fornecedores ou estão focados em um tipo específico de desenvolvimento.
Todd Williamson
3
Estereótipos, ou generalidades amplas, fazem parte de nossos processos de pensamento. É por isso que sistemas de estereotipagem, como cargos e programas de certificação (como diplomas universitários), estão em uso. Mas a certificação de uma indústria não é para gerenciar diferenças entre indivíduos, mas o processo para produzir produtos específicos.
Huperniketes 15/10/10
Suspeito que, se fosse possível melhorar as técnicas de desenvolvimento de software até o ponto em que nossa embarcação fosse certificável (por exemplo, um conjunto de regras "ideal conhecido"), também seria possível escrever um software que desenvolva software (usando o mesmo " ideal conhecido "conjunto de regras) e nossa arte se tornaria inútil.
Brendan