¿Esta lista de comportamientos de gestión realmente atrae a los desarrolladores de software? [cerrado]

8

Encontré esta lista de comportamientos de gestión ( http://suven.posterous.com/dos-and-donts-leading-software-development-te ).

Creo que tiene algunas gemas, pero no estoy 100% en algunas de ellas. Los marqué con cursiva y mi nombre.

¿Usted, como desarrollador de software, piensa que estos son atractivos? ¿Cuáles tres serían sus elementos TOP "tengo que tenerlos" de su gerencia?

No

  • No escales equipos verticalmente agregando más personas

  • No cree un equipo con más de 10 personas.

  • No llame a las personas recursos, no es genial y es realmente ofensivo

  • No asuma que las personas en los equipos son intercambiables.

  • No compares equipos entre ellos cuando resaltes debilidades

  • No lanzar equipos uno contra el otro

  • No cree plazos falsos

  • No fuerce la estandarización de herramientas y procesos entre los equipos (creo que este puede ser discutido para algunas situaciones - Todd)

  • No contrate gerentes de producto que no tengan idea sobre el desarrollo de software

  • No utilice exclusivamente los KPI para conducir sus equipos (no solo es ineficaz, sino que los desarrolladores encontrarán formas de manejar las métricas de KPI: "¿Desea líneas de código? ¡Tengo sus líneas de código!" - Todd)

  • No obligue a sus equipos a trabajar horas extras, incluso pedir está obligado a crear tensión.

  • No asumas que el doble de personas equivale a la mitad del tiempo

Hacer

  • Escale horizontalmente creando más equipos de aproximadamente 5-8 personas

  • Tener una visión para el producto y el equipo.

  • Aprecie que cada equipo es diferente, así que asigne proyectos de manera adecuada

  • Motive a sus equipos (Wow, ese es uno resbaladizo y difícil de definir. Estoy de acuerdo con el sentimiento, pero es como decir "Sé efectivo" sin pautas. -Todd)

  • Permitir que las personas se muevan entre equipos

  • Tener sesiones para discutir la visión, estrategia, tecnología y proceso del producto.

  • Involucre al equipo al determinar el nombre del equipo / producto

  • Permita que sus equipos tomen sus propias decisiones, especialmente si son ellos los que tienen la experiencia

  • Involucre a su equipo en cualquier decisión que afecte cómo o en qué trabajan

  • Fomentar una metodología de desarrollo que coincida con el equipo y el proyecto.

  • Preste atención al plan de desarrollo personal de cada individuo.

management Todd Williamson
fuente
44
Con lo que realmente tengo un problema es involucrar al equipo con el nombre del producto. Este es un tema sobre el cual todos tienen una opinión, pero en realidad hay personas en marketing (o al menos en departamentos de marketing decentes) que saben más sobre esto que solo tener una opinión. Si desea que se respeten sus habilidades, también debe respetar las habilidades de los demás.
Jon Hopkins el
¡Esta lista es fantástica! ¿De qué novela de ciencia ficción es esta?
Rob

Respuestas:

2

Supongo que esta lista realmente atrae a los desarrolladores de software porque valida su propia imagen como divas creativas mimadas en lugar de solucionadores de problemas difíciles (un là Winston Wolf) y espera ser tratada profesionalmente como resultado.

También sospecho que si mejoramos las técnicas de desarrollo de software hasta el punto en que nuestro comercio fuera certificable como el de arquitectos, abogados, profesionales médicos y similares, estaríamos en mejores condiciones para dirigir cómo se gestionan los desarrolladores de software.

Huperniketes
fuente
1
Parece haber una dicotomía entre la percepción de los desarrolladores que tienen de sí mismos frente a los gerentes. Creo que en ambos casos debes mirar a los desarrolladores como individuos y reconocer las diferencias individuales más de lo que necesitas para hacer generalizaciones generales sobre un grupo. Creo que tiene razón acerca de las técnicas mejoradas, pero no creo que alguna vez vea una certificación general aceptada universalmente. Los que están disponibles están basados ​​en proveedores o están enfocados en un tipo particular de desarrollo.
Todd Williamson
3
Los estereotipos, o generalidades generales, son parte de nuestros procesos de pensamiento. Es por eso que se utilizan sistemas de estereotipos, como títulos de trabajo y programas de certificación (como títulos universitarios). Pero la certificación de una industria no es para gestionar las diferencias entre individuos, sino el proceso para producir productos particulares.
Huperniketes
Sospecho que si fuera posible mejorar las técnicas de desarrollo de software hasta el punto en que nuestro oficio fuera certificable (por ejemplo, un conjunto de reglas de "ideal conocido"), entonces también sería posible escribir software que desarrolle software (usando el mismo " ideal conocido "conjunto de reglas) y nuestro oficio sería inútil.
Brendan