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

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

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

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

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

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