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

12

Soy un desarrollador de software que trabaja en una empresa de sistemas integrados. Tenemos un Gerente de Proyecto, que se encarga de la programación general del proyecto (incluyendo electricidad, calidad, software y fabricación), por lo que su programación de software es muy breve.

También tenemos un administrador de software, que es mi jefe. Me hace escribir y mantener la programación del software, los documentos de diseño (diseño de alto y bajo nivel), SRS, gestión de cambios, planes e informes de verificación, gestión de lanzamientos, revisiones y, por supuesto, el software.

Solo tenemos un Ingeniero de Pruebas para todo el equipo de software (10 miembros), y en un momento dado, hay un par de proyectos en marcha.

Estoy gastando el 80% de mi tiempo haciendo estos documentos. Mi jefe proviene de un proceso de fondo, y cree que lo que necesitamos es una mejor documentación para mejorar el software:

  1. Considera que el diseño es primordial, la codificación es "simplemente escribiendo el diseño", no debería llevar demasiado tiempo y "todo el código debe escribirse antes de que el hardware esté listo".
  2. No entiende la diferencia entre una Central y una amp; Control de versión distribuido, incluso después de que le dijimos que es más fácil colaborar con un modelo distribuido.
  3. No entiende el código y quiere entender cada error y su solución propuesta.
  4. La verificación debe ser realizada por el desarrollador y la validación por el Probador. Sin embargo, nuestra verificación solo verifica si la implementación es correcta (no escribimos pruebas unitarias, nunca se considera en el programa), y la validación es una prueba de caja negra, por lo que faltan las pruebas de unidades.

Estoy realmente confundido.

  1. ¿Soy responsable de mantener todos estos documentos? Me hace sentir que estoy haciendo el Software Project Management, en esencia. Estoy de acuerdo con la documentación técnica, pero creo que el programador no debe hacer la planificación / planificación.
  2. Realmente no me gusta crear documentos, quiero resolver problemas y escribir código. 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.
  3. Siento que al jefe no le importa realmente hacer mejores productos, sino solo ser un buen gerente a los ojos de la gerencia.

¿Qué puedo hacer? Durante todo este año he programado 3 meses de codificación real, el resto se dedicó a crear documentos y esperar informes de errores de los clientes.

    
pregunta gnat 29.11.2012 - 16:45

5 respuestas

19

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.

    
respondido por el maple_shaft 29.11.2012 - 17:09
6

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.

    
respondido por el David S. 29.11.2012 - 17:05
4

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.

    
respondido por el MrFox 29.11.2012 - 18:47
2

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.

    
respondido por el Dan Neely 29.11.2012 - 21:18
2

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.

    
respondido por el Andrew 05.12.2012 - 07:13

Lea otras preguntas en las etiquetas