¿Cómo puedo sugerir un mejor proceso sin convertirme en "el tipo que hace este proceso"?

Soy un programador junior. He notado algunos problemas últimamente que creo que podrían resolverse con un servidor de integración continua (CI). Planeo ir a mi gerente en un futuro cercano y decirle algo como "Hemos tenido estos problemas, así es como nos ha afectado, con Jenkins nunca más tendríamos que lidiar con algo como esto. ¿Puedo obtener un servidor Jenkins? para que pueda configurar algunos CI para estos proyectos?"

Mi temor es que la próxima vez que alguien tenga un problema relacionado con CI, la respuesta será: "JETM instaló un buen sistema para nosotros; ve a hablar con él". Y cinco años más tarde me convertí en el chico DevOps.

Odio hacer trabajos relacionados con DevOps. Estoy feliz de hacer lo correcto y configurar la infraestructura para que los proyectos de mi equipo funcionen sin problemas, pero no deseo una responsabilidad significativamente mayor en ese sentido de la que planeo ser voluntario.

¿Cómo puedo acercarme a sugerir la mejora y dejar en claro que no deseo ser "el tipo Jenkins"?

(Nota para lectores no técnicos: CI es integración continua. Jenkins es una herramienta común para hacer CI).

¿Tal vez hay miembros del equipo a los que también les gustaría configurar Jenkins, que solo necesitan aliento y no temen convertirse en un tipo devops?
¿Ya tienes un tipo de "DevOps" en tu equipo? ¿Es el problema más grande de lo que está percibiendo? ¿Quizás su propuesta debería estar más en la línea de "necesitamos que este tipo de tareas se asignen a alguien" en lugar de simplemente solucionar este problema?
@dwizum No tenemos a nadie haciendo operaciones de desarrollo actualmente.

Respuestas (3)

Tienes que decidir cuánto estás dispuesto a aceptar del desagradable trabajo adicional.

Eres un programador. Eso significa que hay una gran cantidad de trabajos secundarios que naturalmente se acumulan en el trabajo. La gente va a querer que hagas trabajo de CI y trabajo de prueba y trabajo de documentos y trabajo de base de datos. Pueden terminar tratando de empujarlo hacia la gestión de proyectos, la seguridad informática y/o la redacción de propuestas. Cuanto más de estos esté dispuesto a hacer, y cuanto más esté dispuesto a hacerlos, más valioso será como empleado. Para cada uno de ellos, querrá configurar el control deslizante en su mente.

1 - Podrías decidir que amas Thing X y quieres convertirlo en el foco de tu carrera. Para hacer eso, expresas un interés verbalmente, lo estudias en casa y te ofreces como voluntario abierta y entusiastamente cada vez que está disponible. (no es lo que quieres en este caso)

2 - Podrías decidir que estás de acuerdo con Thing X, y no te importa que te lleven en esa dirección si eso es lo que se requiere. Para hacer eso, admita esto abiertamente, ofrézcase como voluntario cuando parezca la persona adecuada para el trabajo y asegúrese de mantenerse actualizado.

3 - Podrías decidir que estás bien haciendo esto, pero no quieres que se convierta en lo que haces. Para hacer esto, reconozca la voluntad y la capacidad, acepte un nivel razonable de tareas (cualquiera que sea razonable para usted, a menudo se expresa mejor como un porcentaje del total de horas de trabajo), deje en claro que tiene límites (en voluntad y/o aptitud), y empuja hacia atrás cuando intentan empujarte demasiado lejos.

4 - Podrías decidir que no estás en absoluto dispuesto a hacer la cosa X. Para hacer esto, niégate rotundamente a reconocer que tienes alguna habilidad en ella bajo ninguna circunstancia.

En general, a menos que seas un programador increíble, no querrás intentar ir con el #4 en todo. Tener cierto grado de flexibilidad y disposición para adaptarse es realmente útil para convencer a los líderes de que eres un jugador de equipo. Parece que, en su caso particular, desea elegir el n. ° 3, lo cual es genial, pero el hecho es que no es seguro. Depende de que su gerencia realmente se preocupe por sus preferencias y/o de su capacidad para decirles "no" de vez en cuando.

Entonces... suponiendo que su gestión sea razonablemente sensata/útil, solo tiene que presentarlo de forma clara. CI es algo que no disfruta, pero puede decir que en este caso particular podría ahorrar mucho tiempo y energía perdidos configurando esta cosa. Está dispuesto a realizar el esfuerzo de configuración (aunque no le guste) y el esfuerzo de mantenimiento (esperemos que sea mínimo) (esto es necesario) por el bien de la empresa, pero lo contrataron como programador y es importante para ti que sigas siendo un programador. Entonces, prepárate. Seis meses después, cuando intentan imponerle más trabajo de CI del que está de acuerdo (por mucho que sea), tiene que retroceder y decirles que no está satisfecho con el grado en que está se hizo cargo de su trabajo. Reconozca que si la situación de gestión es lo suficientemente tóxica, es posible que deba renunciar.

Eso es realmente todo lo que puedes hacer... en cualquiera de esas cosas.

Me gusta esta respuesta. En mi experiencia, Jenkins da un impulso moderado a la eficiencia todos los días, pero también puede volverse muy necesitado en momentos inoportunos. Puede que no me guste si un colega empujó a Jenkins al equipo, pero luego quiso desaparecer cuando algún problema de permisos desagradable o la versión de TLS no coincidía o lo que fuera que asomaba su fea cabeza. Y me he preguntado antes si Jenkins realmente hace suficiente extra (por ejemplo, en comparación con solo tener scripts de compilación) para justificar su cuidado y alimentación. Probablemente lo haga en algunas tiendas/situaciones, pero no en otras. Por mi parte, no evangelizaría por ello.

Mi temor es que la próxima vez que alguien tenga un problema relacionado con CI, la respuesta será: "JETM instaló un buen sistema para nosotros; ve a hablar con él".

Sí. Eso pasará. En su mayor parte, es algo bueno porque significa que tienes muchos aportes para prevenir cosas estúpidas y también aumenta tu visibilidad.

Sin embargo, hablando como el tipo que configuró el servidor de CI antes y que lo está haciendo de vez en cuando, no es un trabajo de tiempo completo. Algunas semanas cada pocos años.

Si realmente está en peligro de convertirse en un trabajo de tiempo completo, entonces recuerde la frase, "esta es una habilidad básica que su equipo debe tener. Tengo un trabajo de día. Me encantaría enseñarte a pescar, pero no lo hago". No tengo tiempo para pescar por ti".

Si encuentra que cada vez utiliza más su tiempo en esto, déjele claro a su líder de proyecto (y/o gerente) que su proyecto está siendo mordisqueado hasta la muerte por desviarse de otros proyectos. Lo mismo que de costumbre si te encuentras siendo robado por otros proyectos u otros gerentes.

Whoa, Ninja'ed dos veces.
El suyo tiene la ventaja de una experiencia personal directamente aplicable.

Si se pone de moda y la gente lo está utilizando, lo mejor para la empresa es desarrollar sus propios procesos. Como mínimo, eso implicaría obtener más personas con privilegios administrativos y suficiente conocimiento para que no se convierta en un cuello de botella: si está de vacaciones y una compilación se atasca, ¿a quién recurrirán?

Si desea ser proactivo, sugiera un período de prueba con un "traspaso" en caso de éxito. El traspaso consiste en que al menos una, mejor dos personas, se introduzcan en el sistema hasta el punto en que se sienta cómodo convirtiéndolas en administradores y archivando las notas que tomen en algún lugar donde se puedan encontrar más tarde, en caso de que la empresa necesite traer más personas. hasta la velocidad.