¿Debo proponer un gran cambio como recién llegado?

He estado trabajando en el departamento de TI de una empresa (relativamente) pequeña durante 2 meses.

Recientemente, el jefe de otro departamento (que es un antiguo desarrollador) me dijo que sería bueno que empezáramos a usar algunas metodologías de programación modernas, como pruebas automatizadas e integración continua. Como soy el único que tiene algo de experiencia en el tema, me propuso dar algunas presentaciones a mis compañeros y tratar de introducir los conceptos a mi equipo. Sin embargo, como pertenece a otro departamento, su palabra no tiene valor "oficial". Tendría que proponer estos cambios yo mismo a mi jefe.

Estoy preocupada por dos motivos:

  1. Estos son grandes cambios. Escribir pruebas automatizadas para código heredado es una tarea lenta y difícil.

  2. Estas metodologías requieren cierta disciplina. Como recién llegado, será difícil imponer esta disciplina a todo el equipo. Si mi jefe solo me brinda un apoyo a medias, me temo que puedo encontrarme en una situación desagradable con mis colegas superiores.

Ser el único "poseedor del conocimiento" es un arma de doble filo. Me haría precioso, pero también me daría una gran responsabilidad, tal vez demasiada después de solo 2 meses aquí.

¿Que sugieres?

¿Qué cargo ocupa en el departamento de TI? ¿Desarrollador, Senior, etc.?
@NikolaiDante Simplemente desarrollador. No existe una diferencia formal junior/senior, pero hay desarrolladores que han estado trabajando aquí durante casi 10 años.
¿Qué es más lento y doloroso, escribir pruebas automatizadas una vez, o 50 veces, la ejecución manual de un antiguo código heredado que intenta probar uno de sus cambios?
Una pregunta más, no creo que ser nuevo afecte esta pregunta, no es que no quieras hacerlo porque eres nuevo, sino porque no quieres que se convierta en tu responsabilidad, ¿es correcto o no? En caso afirmativo, podemos editar la pregunta para que sea más general y atraiga más respuestas.
¿Ha hablado con sus compañeros de equipo acerca de considerar estos cambios?
@RhysW Una de las razones por las que tengo miedo de esta responsabilidad es que soy nuevo. Creo que eliminar esta parte de la pregunta daría una imagen incompleta del problema.
@RhysW, la realidad nunca es una elección entre "escritura única de pruebas automatizadas" frente a "pruebas manuales 50x". Llegar al punto de implementar correctamente las pruebas automatizadas donde no ha existido antes es un proceso MUY LARGO con un ROI a largo plazo. Requiere cambios profundos en la organización y cualquier tipo de cambio es particularmente difícil de lograr para los recién llegados.
@Angelo estuvo de acuerdo, sin embargo, cuando el proyecto no va a ninguna parte, aún puede llevar menos hacerlo que volver a enseñar y hacer manualmente las pruebas para cada cambio, cada vez que alguien nuevo se une a la empresa.
"me dijo que sería bueno": esto implica que solo te hizo una sugerencia, no un requisito explícito o ¿me equivoco? En cualquier caso, no veo por qué no tener una discusión con él primero sobre los pros y los contras.
Habiendo pasado por cambios en la metodología, permítanme asegurarles que para impulsar dicho cambio se requiere un patrocinador con suficiente autoridad para impulsar el cambio. El efecto dominó de un cambio de metodología organizacional es amplio.
CI debería ser una fruta al alcance de la mano si utilizan un sistema de control de versiones moderno (como git). Gitlab es bueno.
No creas que eres el único que conoce alguna metodología. Probablemente casi todo el mundo lo sabe y decidió que no vale la pena el esfuerzo.

Respuestas (9)

No tomaría muy en serio la sugerencia del jefe de otro departamento. No sé por qué te habló a ti y no a tu jefe (o a la gerencia superior), pero en realidad no suena bien (incluso podría haber una razón por la que no habló directamente con tu jefe). Como mencionó en su pregunta, estos cambios están lejos de ser triviales. Requieren una planificación e implementación serias, y tales decisiones no se pueden tomar sobre la marcha solo porque alguien piensa que sería bueno (incluso si esa persona es un ex desarrollador que ahora es jefe de departamento).

Antes de tomar cualquier acción, debe hablar con su jefe. Tenga una conversación uno a uno y cuéntele a su jefe sobre esta sugerencia. Trate de abstenerse de mostrar una actitud específica (demasiado ansioso o entusiasta). Hable acerca de su confusión acerca de esto. Esto ayudará a aclarar la situación, así como a mostrar tu profesionalismo y actitud hacia tu trabajo y tu jefe.

Editar: algunas aclaraciones sobre los comentarios. Lo que quiero decir es que no deberías sumergirte en esta tarea sin discutirla primero con tu jefe. No quiero decir que no necesites hacer sugerencias o tratar de mejorar algo, es completamente diferente a sumergirte en un trabajo que alguien sin autorización cree que deberías hacer.

Exactamente, no parece que lo hayan contratado para mejorar el proceso actual mediante la implementación de estas cosas, así que no sienta que es su responsabilidad. Está bien presentarlo a tu jefe como una idea, pero no te hagas cargo solo porque alguien que no sea tu jefe haya mencionado que podría ser una buena idea.
Hablado como un verdadero incondicional de "Así no es como lo hacemos aquí".
Rara vez se contrata a personas solo para mejorar el lugar de trabajo para los demás, pero todos tienen la capacidad de sugerir mejoras en el flujo de trabajo por sí mismos, no hace falta decir que no esperaría que alguien no discuta un problema solo porque no le pagan por ello, ¿verdad? El tipo encontró una forma de mejorar su trabajo, la única razón por la que quiere hablar con su jefe al respecto es porque no fue contratado para hacerlo, pero quiere llamar la atención de las empresas.
@RhysW, vea mi edición. creo que no me entendiste bien
Disculpas SuperM, mi comentario en realidad estaba dirigido a @Huntmaster, por error no lo etiqueté
@RhysW, no me malinterprete, no estoy diciendo que no vacíe la papelera porque está llena y usted no es el custodio, o que no corrija un error en el código en el que está trabajando por casualidad. Anteriormente había dicho que estaba bien pasarlo a su jefe. Estoy diciendo que no sienta la necesidad de asumir un proyecto de cambio de proceso significativamente grande, de todo el departamento, como su deber porque alguien lo sugiere. De lo que está hablando no es de unas pocas horas aquí o allá, está cambiando la forma en que trabaja cada uno de su equipo e imponiendo una estructura y cierto nivel de disciplina sobre todos ellos. Eso es un gran problema.

Las otras respuestas han dado muchos buenos consejos sobre cuándo, si y cómo hacer cambios. Pero retroceda un poco: usted es un recién llegado a una organización, se ha identificado que tiene nuevos conocimientos y se le ha pedido que proporcione información.

El próximo paso lógico aquí es que haga una presentación sobre las tecnologías relevantes -- una charla de "cosas que he aprendido", en otras palabras, como la charla que le daría a sus compañeros de trabajo después de regresar de una conferencia en la que aprendido un montón de cosas. Hacer recomendaciones sería prematuro sin importar cuánto tiempo haya estado allí; el primer paso en cualquier consideración de cambio es la educación. Estás en condiciones de educar. Haz eso primero y luego a ver qué pasa.

Llevo más de una década en mi empresa actual. He visto a mucha gente venir con nuevas ideas, cosas en las que no estábamos al tanto porque ese no ha sido nuestro enfoque. Los que entran y dicen "tenemos que hacer X" desde el principio, por lo general, no han obtenido tracción; por otro lado, los que han dicho "aquí hay algunas cosas que he aprendido sobre X" sí lo han hecho.

Esa es una forma astuta y astuta de hacer que la gente piense en la dirección necesaria...
@DeerHunter exactamente. Un nuevo empleado no está en la mejor posición para presionar, pero cualquiera puede inspirar . (Y, según mi experiencia, los mejores líderes son mucho más inspiradores que dictadores).
Estoy de acuerdo, la forma en que lo expresas es muy importante. Tienes que evitar sonar como si fueras un sabelotodo o acusarlos de estar desactualizados. Les muestra las cosas con las que trabajó y cómo le ayudaron allí, y luego, con suerte, comenzarán a juntar 2 y 2 y se darán cuenta de que les ayudará a resolver los problemas que tienen.

El tiempo es fundamental para sugerir cambios importantes. Lo primero que debe hacer es tener una buena reputación con sus compañeros de trabajo y jefe actuales. A los dos meses no tienes antecedentes con ellos, esperaría a que los tengas. Es más probable que se acepten más cambios como la solución a un problema que está ocurriendo en este momento. Entonces, el momento de sugerir escribir pruebas unitarias es justo después de que se rompiera algo importante en la producción que podría haberse evitado si existieran las pruebas.

Por lo tanto, redacte sus propuestas en términos comerciales (calidad mejorada, costos más bajos, etc.) y consérvelas hasta que sea el momento adecuado. Entonces sácalos. Y recuerda, no trates de hacer demasiado a la vez. Elija la propuesta que tenga más probabilidades de ser aceptada como la primera que presente. Tener éxito en una propuesta le da más credibilidad cuando sugiere los cambios que probablemente sean más difíciles de aceptar para los demás.

También empieza a buscar aliados, otras personas que puedan apoyar los cambios que te interesa proponer. Es más fácil lograr que las cosas sean aceptadas si los demás no se oponen a la idea. Si tiene personas que han estado allí durante mucho tiempo, recuerde que probablemente crearon el sistema actual y están interesados ​​en él. Tendrá que trabajar más duro para lograr que acepten el cambio. También lea un poco sobre la resistencia al cambio. Todas las organizaciones tienen esto y ayuda a entenderlo y comprender por qué ocurre y cómo tratarlo políticamente.

Sugiero comentarlo con su jefe; específicamente, pregunte sobre los problemas que (eventualmente) ve. "Oye, ¿por qué se rompió nuestra construcción?" Eso le da a su jefe la oportunidad de darle una idea de la postura técnica, comercial y quizás política de ese tema en particular.

Si desean que se solucione, pero no saben cómo, sugiérales que se solucione a través de la integración continua en muchas empresas.

Si lo descartan como nada, tal vez te muerdas la lengua.

Si fruncen el ceño y dicen 'suenas como el jefe en ese otro departamento', entonces sabes sobre el campo minado político.

Y, en general, es mejor vender estas cosas como soluciones de "mejores prácticas" a los problemas, en lugar de cambiar lo que cree que se debe hacer por cambiar.

Esperar hasta que surja un problema puede ser costoso cuando se interrumpe una implementación y cuesta unos cientos de millones a un cliente debido a la falta de servicio. Nunca hay nada de malo en discutir las mejoras antes del problema.
@RhysW - Poppycock. Si el chico nuevo entra y presiona por mejoras sin saber el problema que está solucionando, o el panorama político, fácilmente podría poner a la gente en contra de las mejoras. Las mejoras solo benefician a la empresa si se implementan.
Precisamente por eso no está de más llamar la atención de su jefe. Si puede resolver el problema, el jefe lo empujará, si no puede, el jefe le dirá que no funcionará y le explicará por qué. En el mejor de los casos, resolvió un problema, en el peor de los casos, aprendió algo nuevo sobre el sistema y por qué su solución no funcionará. no veo ninguna desventaja
@rhysw: ¿De verdad crees que el jefe del otro departamento no habló con el jefe del OP al respecto? He visto esto media docena de veces. Un jefe de departamento atrasado rechaza los intentos de mejora como cambio por cambiar, o por despecho político, o por simple ignorancia del impacto que causa el atraso. Dado que el contacto directo falló, el otro jefe de departamento está tratando de subvertir el cambio en el departamento. Hacer que el OP mencione esto directamente o de forma calurosa destruiría rápidamente ese proceso.
Estás haciendo muchas suposiciones basadas solo en tus experiencias, esto no siempre es cierto.
+1 por el enfoque cauteloso. Mi caso particular resultó ser una simple falta de tiempo para organizar una reunión entre los 2 gerentes. Ahora el problema está resuelto, pero sus puntos siguen siendo válidos en general.

La esencia de mi respuesta es: Averigüe si esta es una tarea realista, que le gustaría hacer y si es buena para su carrera profesional. Si no, busque un nuevo trabajo.


Como ya se sugirió, también sugeriría hablar primero con su jefe. Y de una manera más informal a sus colegas para obtener una mejor "evaluación" sobre cómo se sentirían acerca de estos cambios. Además, lee entre líneas. Si dice "sí", pero no está realmente de acuerdo, significa "sí, pero no".

Además, trata de hacerte una idea de cómo piensan sobre los cambios en general y los conceptos/ideas/mentalidad de las cosas que quieres proponer. ¿Cómo lidian con la deuda técnica? ¿Mantienen el código a largo plazo, lo refactorizan, etc.? ¿Tienen experiencia en código abierto? Entonces, ¿hacen revisiones de código?

Busca oraciones como:

  • "Siempre lo hemos hecho así"
  • "Nunca rompa un sistema en funcionamiento"
  • "No tenemos tiempo para esto"
  • "Eso ya lo intentamos pero tuvimos problemas/no funcionó..."

Si el jefe no está (totalmente) a bordo O si los colegas tienen serias objeciones, al menos consideraría buscar un nuevo trabajo (especialmente si es joven) En su próxima entrevista de trabajo, haga preguntas específicas para ver si la cultura de desarrollo es una buen ajuste para ti.

No me refiero a salir cada vez que hay un problema. Es decir, vete si hay una resistencia insuperable al cambio y te quedarás estancado asimilando una cultura y una práctica de desarrollo que no es buena para ti personalmente ni para tu carrera profesional.

Por un lado, manejar este cambio sería una gran experiencia para ti y probablemente se vería bien en tu currículum. Sin embargo, la pregunta es ¿qué posibilidades hay de que tenga éxito?

¿Por qué digo esto?:

  • Parece que su departamento y sus colegas se están quedando atrás en cosas que usted considera importantes y que son fundamentales para escribir un código bueno y estable.
  • ¿Hay alguien allí que tenga más experiencia que tú (en este o en otros campos?). ¿De quién aprenderás?
Aquí está la peor objeción: "Le dijimos esto a nuestro jefe repetidamente y él no quiso saber nada de eso". Si el jefe acepta la sugerencia de usted después de rechazarla varias veces, es un hombre marcado.

Hubiera sugerido que el gerente de este otro departamento lo hablara con su jefe. Si el jefe de otro departamento quiere que su departamento haga algo, no es del todo apropiado colocar la carga de la decisión en ningún miembro de su departamento (especialmente no en un miembro relativamente nuevo como usted) fuera del jefe de departamento/gerente de alto nivel.

¿Puedo preguntar por qué mi respuesta fue rechazada? Esta es la política que sigo en los raros casos en que ocurre algo así, y creo que me interesa entender por qué tal curso de acción podría ser malo.
Desde mi perspectiva, no hay nada de malo en la respuesta real, pero el otro jefe nunca hizo que fuera una tarea oficial para él, suena más como si el otro jefe mencionara en una discusión que X habría sido bueno, y si el OP estuvo de acuerdo, entonces ' aquí hay un camino para hacerlo 'haciendo un powerpoint y yendo al jefe
@RhysW ahh, ya veo. Editaré mi respuesta.

Piense en 4 movimientos por delante

"Una persona es inteligente. Las personas son animales tontos, asustadizos y peligrosos y lo sabes".

Si bien un individuo puede ser una herramienta racional con visión de futuro para la mejora, las organizaciones por lo general no lo son.

Si desea implementar estas mejoras, la pregunta importante no es preguntarse si debe proponer estos cambios, sino cómo proponer estos cambios con la mayor probabilidad de éxito.

La perspectiva lo es todo

Aprender cómo tiene que ver con la perspectiva. ¿Quién tiene realmente el poder para implementarlo? ¿Qué caballos tienen en la carrera? ¿Cuál es su objetivo? ¿Cuáles son los problemas potenciales que enfrentarán si intentan implementarlo?

Estas son las cosas más importantes que debe saber, pero por lo general no son evidentes para las personas que acaban de unirse a la organización. Es por eso que muchos empleados nuevos que presionan por cambios amplios y radicales se sienten frustrados por la aparente irracionalidad del sistema en su conjunto: no pueden ver la racionalidad de cada uno de los actores en ese sistema.

Ganar perspectiva vs. Ganar confianza

No a todos les importa lo que quiere su gerente, o cómo está configurada la organización, o cuál es la mejor manera de implementar un cambio que atraviese los departamentos (es un trabajo realmente tedioso), así que si ganar perspectiva no es lo tuyo, puedes ir al otro lado. ruta y trata de ganarte la confianza.

Ganarse la confianza de alguien con la perspectiva significa que pueden formar una sociedad con usted donde le permiten manejar el aspecto técnico mientras manejan el aspecto político para implementar el cambio. La clave para generar confianza es que también debe confiar en la persona políticamente apta con perspectiva, ya que está limitado en lo que puede hacer por lo que puede hacer que la organización acepte.

Entonces, ¿debería proponer un cambio como recién llegado?

Esta pregunta depende totalmente de dos cosas:

  1. ¿Está buscando un impacto a corto plazo o un éxito a largo plazo con esta empresa?
  2. ¿Tiene talento técnico o político?

Impacto a corto plazo

Si tiene una orientación técnica, entonces puede crear algo que funcione muy bien como un proyecto paralelo en la medida en que su jefe no pueda negar su efectividad. Hace muchas lunas, trabajé en control de calidad para algún software y escribí un software de prueba automatizado que eliminó la necesidad de hacer mi trabajo (programé mi trabajo para que no existiera). Su jefe tendrá problemas para decir que el software de prueba automatizado es una mala idea cuando tiene un historial comprobado de éxito.

Si tiene una orientación política, puede pasar algunas semanas averiguando cuál es el papel de su jefe en la organización y cuánto le permitirá salirse con la suya, y luego pedirle que le permita hacer un proyecto paralelo dentro de la organización. reino que sabes que te permitirá hacer (ya que no causará daño a nadie más). Esto le permitirá crear algo que desee crear, generar confianza con su jefe y permitirle desarrollarlo en un futuro cercano.

Impacto a largo plazo

Si busca el éxito a largo plazo, no propondría un gran cambio. En su lugar, trabajaría en generar confianza (si está orientada técnicamente) o perspectiva (si está orientada políticamente) para poder aprovechar eso y ponerme en una posición para hacer un cambio más grande más adelante.

De todos modos...

Cuidado con las minas terrestres políticas. La gente de otros departamentos que sugiere que propongas cambios radicales huele a oportunismo político y me grita "Peligro Will Robinson" . Hable con su gerente y descubra lo que está pensando. Le guste o no, su gerente tendrá un gran impacto en el cambio que puede implementar, y llegar a comprenderlo (o lograr que confíe en usted) es una buena idea.

Al mismo tiempo, es una mala idea molestar al gerente en otro grupo también. Así que tendría cuidado de no usar esta oportunidad para quedar bien con su jefe haciendo que el gerente quede mal.

Encontraría una muestra de código en particular que sea particularmente compleja o propensa a romperse y configurar las pruebas automatizadas para ese código. Predicar con el ejemplo. Si hay sistemas que tienen problemas de calidad inusualmente significativos, ofrezca usar sus metodologías para probarlos. En lugar de decir 'todos deberíamos hacer esto', 'hagan esto' por su cuenta y dejen que algunos de los beneficios se acumulen antes de promoverlo más ampliamente.

A menos que te trajeron específicamente para hacer cambios, entonces creo que es demasiado pronto para que el chico nuevo les diga a todos que lo que están haciendo está mal. Muchas veces, cuando una empresa está haciendo algo que la sabiduría convencional cree que está mal, resulta que hay razones válidas para hacerlo de esa manera. Si no conoce la historia de cómo las cosas llegaron a donde están y resulta que el cambio no es realmente práctico debido a problemas específicos de la empresa/proyecto, entonces pierde credibilidad precisamente en el momento en que se supone que debe estar construyendo su credibilidad.

Mi consejo para cualquiera que sea nuevo es que primero mire, escuche, aprenda y, lo más importante, construya su credibilidad. Quién sabe, si haces lo que te digo quizás aprendas algo. Hay ocasiones en las que descubrirá que la sabiduría convencional no es la adecuada para la situación particular de su empresa. Es muy posible que la forma en que lo están haciendo sea más fácil/mejor/más adecuada para sus tareas, una vez que te acostumbres. Incluso si lo están haciendo mal, si tus compañeros de trabajo confían en ti, entonces convencerlos de que cambien se vuelve cientos de veces más fácil que tener a alguien nuevo que les diga que lo han estado haciendo mal todo este tiempo.

Mientras tanto, si realmente quiere introducir cambios, vea lo que puede hacer para obtener una configuración solo para usted. Tal vez alguien más sienta curiosidad por lo que estás haciendo y le guste lo que hiciste, y se lo mostrará a alguien más y crecerá sin mucho esfuerzo de tu parte. Como mínimo, habrá descubierto cómo hacer que sus cambios funcionen en esa empresa en particular cuando llegue el momento en que sea apropiado comenzar a impulsar sus cambios.