Software Manager que hace que los desarrolladores hagan la Gestión de proyectos

Pareces un ingeniero de software.

Un gerente de proyecto se centra más en el estado del proyecto en general y en la asignación de recursos de manera eficaz para garantizar que se cumplan los hitos y en el momento adecuado. También eliminan obstáculos y ayudan a los recursos del proyecto a centrarse en sus funciones de trabajo específicas.

Escribir y mantener el diseño y la documentación técnica es una parte importante de ser un ingeniero de software y es apropiado para su función. Demasiado de algo bueno puede ser malo (consulte Analysis Paraylsis ).

  

Él considera que el diseño es primordial, la codificación es "simplemente escribiendo el diseño"

Si el gerente del proyecto considera que los documentos de diseño son primordiales, espera que los documentos se puedan entregar en el proceso. No es un tiempo perdido de su parte si él considera que son lo suficientemente importantes como para asignarle el 80% de su tiempo.

  

no debería llevar demasiado tiempo y "todo el código debe escribirse antes de que el hardware esté listo".

Esta es una ilusión y es una visión anticuada del estilo de Waterfall sobre cómo funciona el desarrollo de software. Invariablemente nunca es tan limpio, no importa cuánto diseño y preparación dedique. Sin embargo, en esa nota, debe tener especificaciones de hardware claras y entornos de prueba adecuados y simulaciones de hardware simuladas para que su código interactúe, pero, de nuevo, el mundo real está desordenado.

La gestión de proyectos es increíblemente fácil en un mundo perfecto. Sin embargo, el mundo no es perfecto, no importa cuánto desees, por lo que la gestión real de proyectos es increíblemente difícil. Por eso les pagan mucho dinero.

  

(2) No entiende la diferencia entre una Central y un amp; Control de versiones distribuidas.

¿Por qué debería importarle? ¿Cómo afecta a los hitos? No lo hace.

  

3) No entiende el código y quiere entender cada error y su solución propuesta

Su objetivo es trabajar con software y el suyo también debería serlo. No necesita entender el código, pero sí tiene que entender los problemas que impiden que el software funcione. Una vez que los dos estén de acuerdo en este nivel básico, su meta mutua lo ayudará a trabajar juntos de manera más efectiva.

  

(4) La verificación debe ser realizada por el desarrollador y la validación por el Probador.

¿Qué está mal con este sentimiento? Los evaluadores en el rol de control de calidad deben preocuparse por la validación de características y requisitos. Los desarrolladores deben hacer todo lo posible para verificar y probar su trabajo antes de que se realice la prueba.

  

Realmente no me gusta crear documentos, quiero resolver problemas y escribir código.

Si prefiere ser un simple programador, quizás debería hablar con su jefe sobre esto y ver si hay un mejor papel para usted en el proyecto. Alguien necesita escribir y mantener la documentación técnica, por lo que quizás uno de los otros desarrolladores pueda ayudarlo con algunas de estas tareas para que no pierda el 80% de su tiempo escribiendo documentación.

  

En mi experiencia, crear documentos de diseño solo ayuda en cierta medida, nunca es la solución para un código mejor o más rápido.

Esto es cierto en su mayoría ... pero solo si los diez desarrolladores pasan el 80% de su tiempo escribiendo documentación técnica que nadie leerá jamás. Este es un enorme anti-patrón de gestión en el que he vivido antes. Si descubre que está haciendo la mayor parte de la documentación para el equipo, entonces no parece justo que se le niegue el derecho a realizar más trabajos de codificación.

El hecho es que la mejor documentación técnica es el propio código.

  

Siento que al jefe realmente no le importa hacer mejores productos, sino solo ser un buen gerente a los ojos de la gerencia

Siento que a le importa porque el producto es su departamento y si los proyectos y las funciones no se completan y los clientes no están contentos, entonces la alta gerencia no lo cuidará mucho. El problema es que su perspectiva sobre las mejoras de calidad necesarias no coincide con la suya y la alta gerencia, y la percepción de los clientes de lo que sienten es importante.

Trate de comprender lo que es realmente importante para el producto, ya que si bien puede aumentar la eficiencia de un proceso tres veces, si pasa una semana entera haciendo esto, es a costa de otra característica importante que el cliente está demandando. .

Todos queremos lucir bien ante los ojos de nuestro superior. No hay nada de malo en eso, es la naturaleza humana ser egoísta. Este es un hecho de la vida.

Hasta cierto punto, estoy de acuerdo con su gerente de proyecto. El desarrollo de software va más allá de las características de codificación. :-)

Dada su situación, acudiría a él y le explicaría que sus solicitudes están tomando el 80% de su tiempo, y trataré de entender por qué es importante para él que dedique este tiempo a mantener la documentación en lugar de desarrollarla (lo que va más allá de la codificación). ).

FYI, Atlassion , una compañía de software, tiene una proporción de 13 desarrolladores para una persona de control de calidad y la mayoría de las pruebas (planificación y la ejecución) es realizada por los desarrolladores. Aprendí esto durante una de sus presentaciones en Agile 2012 y nuestros equipos que actualmente intentan emular esta práctica.

Sin embargo, también hablaría con su jefe de proyecto si él estaría abierto para probar Scrum como una metodología que ayude a que todo el equipo avance. Dada tu descripción, no creo que estés usando Scrum.

Al igual que usted, me sentí extremadamente frustrado al mantener planes que estaban cambiando constantemente y un enfoque ligero de Scrum me ayudó a superar esta frustración.

Los equipos más destacados en mi experiencia fueron aquellos que enfrentaron la menor cantidad de procesos necesarios para realizar su trabajo. En algún punto, el proceso adicional comienza a quitarle la calidad al producto. Si el control de calidad comienza a fallar errores porque están más preocupados por conseguir el papeleo fuera del camino, y DEV no está codificando las características o corrigiendo errores porque están escribiendo documentación, entonces tiene un problema. Sin embargo, descubrir si este es realmente el caso en su empresa es una pregunta altamente localizada que solo las personas de su equipo pueden responder (no nosotros).

Hay algo en lo que tu jefe está muy equivocado, y es el hecho de que tienes muy poco control de calidad y no pruebas de unidad. Un error creado por adeveloper es, por definición, un descuido de su parte. Esperar que los desarrolladores siempre prueben sus propias características y, además de tener pocas pruebas, es un problema de proceso. El control de calidad puede ser reemplazado por pruebas automatizadas dependiendo de su dominio hasta cierto punto, pero si no tiene ninguno de los dos, es probable que deje que los errores se deslicen (y eso suele costar más que encontrarlos antes).

Además, desde una perspectiva empresarial estricta, contratar QA es más barato que contratar desarrolladores. Podrá cubrir más terreno para el dinero gastado si los equipos tienen una buena relación QA / DEV.

Las implementaciones de CMMI que he visto o que he escuchado directamente han sido todas de proceso y documentación; Sus jefes creen que la documentación debe ser lo suficientemente detallada para hacer que la implementación sea trivial implica que su expectativa es similar.

Si está recibiendo una parte desproporcionada de la redacción / mantenimiento de la documentación, es razonable solicitar una distribución más equitativa. Si los otros desarrolladores tienen documentación similar a los índices de codificación y desea pasar la mayor parte de su tiempo escribiendo código; puede ser el momento de considerar la búsqueda de un nuevo empleador.

Está hablando de sistemas médicos ... por lo que la seguridad es primordial, y por lo tanto, la documentación (específicamente la trazabilidad) es esencial.

Un probador parece un poco ligero, pero aparte de eso, sí, usted es responsable de garantizar que la documentación esté en su lugar.

Mi experiencia en el mundo médico es limitada, pero en el mundo aeroespacial / de defensa tenemos Do-178B (ahora C) que prescribe un modelo de ciclo de vida que especifica la documentación y el nivel de pruebas necesario (según la criticidad de la seguridad [ más específicamente, el nivel de garantía de diseño del software), y en el mundo de la automoción tenemos ISO26262 que hace lo mismo.

Si la documentación no está en su lugar, el producto no se certifica.

Pero lo importante es trabajar con la documentación requerida para mejorar su producto ... no intente aplicar ingeniería inversa a la documentación como una idea posterior, ya que no tiene ningún propósito en el mundo real.