¿Es poco profesional decirle a mi gerente no técnico que estoy documentando en lugar de escribir pruebas, refactorizar, etc.?

Trabajo en una pequeña empresa con otros 4 desarrolladores. Esencialmente todos los proyectos son proyectos en solitario.

Nuestro gerente tiene una sólida experiencia en ventas, pero puede escribir "hola mundos".
Conoce palabras como servidor, front-end, back-end, base de datos.
Nos dice lo que el cliente ha pedido y es nuestro trabajo hacerlo realidad.
Le informamos sobre las tareas que hicimos y cuánto tiempo dedicamos a ellas.

Según tengo entendido, mi gerente entiende la documentación de la siguiente manera:

  1. Lo más probable es que sea un wiki o un pdf, pero puede ser una descripción de un problema, etc. Es algo que se puede leer.
  2. La intención de la documentación es facilitar el trabajo del desarrollador. Para permitirles producir valor comercial más rápido.

No comprende cómo se puede dedicar tiempo a nombres de clases/métodos, control de versiones, automatización, etc.

Veo que subestima significativamente el valor que el código limpio, las pruebas automatizadas y las canalizaciones de CI/CD pueden tener para otros desarrolladores. (Aunque como mencioné, tenemos proyectos en solitario, pero nos duele cuando necesitamos tomar el control de otros proyectos).

Entonces, en lugar de informar que pasé 2 días para refactorizar y obtener el aspecto "el cliente no pagó por eso", solo le digo que escribí la documentación durante 2 días.

¿Es poco profesional guardarme detalles que de otro modo me pondrían en la misma batalla otra vez?

No me importaría compartir detalles si él pregunta y asumiré la responsabilidad de todo el trabajo que he hecho.

"Entonces, en lugar de informar que pasé 2 días refactorizando y obteniendo el aspecto de 'el cliente no pagó por eso', solo le digo que escribí la documentación durante 2 días". Existe el riesgo de que se entere y explote "en gran medida" por la supuesta violación acumulada de la confianza.
Sí, esa es mi preocupación. Me pregunto si llega ese momento, ¿puedo hacer un caso de documentación (para dev) == [wiki, pruebas, código legible, ...]
Entonces, refactorizaría solo en proyectos pagados. Si la parte de contabilidad necesita un mantenimiento pagado por un cliente, entonces es hora de refactorizarlo para facilitar el mantenimiento. Y la refactorización pagada por el cliente: después de todo, indirectamente obtiene los beneficios. ¿Pero refactorizar 2 días fuera de cualquier presupuesto? Nah, demasiado difícil de ocultar.
Sí, es poco profesional mentirle a su gerente.
@Paparazzi ¿Entonces ves esto como una mentira directa?
Lo siento si no lo ves como una mentira. Apuesto a que tu jefe lo haría.
@Paparazzi Gracias. Hice esta pregunta porque mi intención es crear valor comercial y ayudar a la empresa, pero por otro lado, definitivamente no voy a mentir.
Y existe la preocupación de refactorizar fuera del proceso. ¿Se revisaron los cambios de código, QA los aprobó? ¿Qué pasos se tomaron para asegurarse de que la refactorización no cambiara el funcionamiento de algo? ¿Ejecutó un conjunto completo de pruebas de regresión? Me disgustaría muchísimo que alguien hiciera cambios no autorizados en el código base.

Respuestas (4)

No estoy seguro de llamarlo poco profesional porque está tratando de hacer el trabajo que cree que es necesario, pero a largo plazo sería mejor para todos los desarrolladores trabajar para que su gerente comprenda los beneficios comerciales de mantenible. código.

A corto plazo, si siente que tiene que ocultarlo, no creo que la documentación sea un buen lugar. La documentación es más comprensible para su gerente que su código y si se toma mucho tiempo en la "documentación", se reflejará mal en usted y también existe el problema si se entera. Sería mejor tener en cuenta el esfuerzo de refactorización y prueba como parte del desarrollo de las características. Su cliente y gerente esperan un software de calidad y todo esto es parte de la entrega, no es una tarea separada.

De hecho, si no tiene un gerente que pueda comprender el aspecto técnico, debe intentar comprender el aspecto comercial. Desde un punto de vista comercial, trabajar en algo que ya funciona parece extremadamente inútil. Incluso las pruebas automatizadas parecen inútiles. Quiero decir, si funciona, funciona, ¿verdad? ¿Por qué pasar días escribiendo cosas extra? Así que dígale, desde un punto de vista comercial, por qué hace estas cosas. (aceleración de los tiempos de desarrollo, reducción de errores y posible tiempo de inactividad y/o daño financiero/de reputación, etc.). Pero también tenga en cuenta que el aspecto comercial a veces puede superar al aspecto técnico.
+1 solo incluya pruebas, etc. en su definición de finalización de una tarea determinada.

Sí, es poco profesional mentir a sus gerentes.

Usted y su equipo deben programar una reunión con su gerente y explicarle muy claramente los beneficios de tener un código limpio y usar herramientas como el control de versiones o la integración continua. Debes hablar de dinero porque ese es su lenguaje. No intentes comenzar un discurso técnico con él, solo habla en términos de ahorro de tiempo (menos trabajo) y eficiencia (más trabajo en menos tiempo). Si puede convencerlo, será gratificante tanto para su equipo como para la gerencia.

No es profesional mentirle a su gerente.

Si no consideras que es una mentira, agregaría que ocultar información sobre lo que has estado haciendo durante otros 2 días es más importante que un detalle y es casi tan malo como mentir.

Su gerente siempre debe entender en qué está trabajando en todo momento.

Si cree que la refactorización es necesaria, entonces es su trabajo explicar qué es y qué implica. Su trabajo es entonces decidir si deberías estar trabajando en ello o no.

Sí, es poco profesional porque hay varias suposiciones en su declaración, que solo se pueden verificar hablando abiertamente sobre el tema.

  1. Asumes que tus gerentes están subestimando el valor del código limpio.
  2. Usted asume que tiene tanta información sobre su empresa que puede determinar cuál es un buen uso de su tiempo.
  3. Asumes que el trabajo que haces en realidad proporcionará un beneficio a la empresa.

Si está equivocado acerca de cualquiera de estas suposiciones, cualquier reacción negativa resultante será únicamente su culpa.

Si tiene razón en sus suposiciones, hacer el trabajo en secreto seguirá siendo contraproducente. O revelas lo que has hecho y pierdes la confianza de tu jefe, o no revelas lo que has hecho y refuerzas la suposición de que su forma de hacer las cosas es la correcta.

Si realmente está convencido del problema, plantee oficialmente sus inquietudes a su gerente. Haga un powerpoint, obtenga algunas referencias, muestre los pasos que se pueden tomar (y qué efecto tendrán en términos económicos) y, sobre todo, prepárese para repetir todo lo anterior durante el tiempo que sea necesario para convencer a las personas.

¿Es poco profesional decirle a mi gerente no técnico que estoy documentando en lugar de escribir pruebas, refactorizar, etc.?
RespuestasAquíPolítica de privacidad1y, 0v